保持好奇产品修炼册

加元数据过滤比换模型靠谱，先按任务类型打个标，召回后再筛一遍准没错。

fp16震荡大概率是loss scaling没调好，可以试试bf16或者torch.cuda.amp的grad scaler，效果会稳很多。另外7B模型单卡40G跑全参微调确实紧张，就算开齐了gradient checkpointing和ZeRO stage2也可能爆，建议先看看是不是padding token太多导致的，用dynamic padding或者把max length设小点能省不少显存

这问题我也踩过坑，核心其实是工具调用时的上下文隔离没做好。我试过在提示词里明确把知识库结果和工具输出分成两个独立区块，并让Agent优先信任知识库里的结构化信息，幻觉少了很多。另外可以试试给工具输出加个强制校验层，比如价格字段如果出现库存数就直接报错，逼Agent重新推理。流程上建议把检索结果作为系统消息固定住，工具调用只做增量补充，别让Agent有权限去覆盖或拼接已有上下文。

调过同样问题的人表示，embedding模型质量确实影响挺大，但你这情况更像是切块策略和查询意图不匹配。比如“Python多线程”和“环境安装”在语义空间里可能距离本来就近，建议试试先做基于关键词的粗筛，再对候选集做向量重排，能过滤掉不少无关结果。另外HNSW参数一般不用动，除非你数据量上了百万级。

试试用向量数据库存历史记录，每次query时自动检索相关进度塞进prompt，比手动更新省事多了。

这个问题我最近也踩过类似的坑，折腾了两天才找到原因。我觉得大概率不是prompt写错了，而是参数对齐这块容易出问题——MCP对工具调用的格式要求特别严格，尤其是参数名和参数值的结构必须完全匹配训练数据里的写法。比如你提到的“city:北京”，如果微调数据里都是这种带key的格式，但模型在推理时直接输出纯文本，那多半是训练时没有把工具调用的输出格式作为强制约束来学习。 我自己的经验是，可以试试在微

感觉不是embedding的问题，你本地测试准但线上翻车，大概率是分块策略和query预处理没对齐。线上请求五花八门，可能带了冗余关键词或乱码，试试在检索前加个简单的query重写或清洗。另外FAISS在CPU模式下索引重建可能有线程安全问题，你检查下是否每次请求都重新加载了索引，或者改用HNSW参数调低efSearch值看看。