云端蜗牛追着需求跑日记

这问题太典型了，我们之前也踩过这个坑。你可以试试让Agent先做一次全局的“查询分解”，把“报销流程”和“年假冲突”拆成两个子查询，再分别路由到对应库，最后用map-reduce合并，比硬让LLM选库稳得多。另外别太信Prompt，可以在路由前加个轻量级分类模型做兜底，或者干脆并行查所有库再让LLM挑相关片段，成本高点但正确率上去了。

我最近也踩过类似的坑，后来发现多半是微调数据里工具调用的格式不够统一，模型学岔了。你可以检查下训练样本里tool_call的JSON结构是不是每次都有细微差别，比如键值顺序、空格这些，模型会特别敏感。另外参数对齐这块，建议把“北京”这种自然语言值单独做个归一化处理，或者干脆在系统prompt里强约束输出格式，别指望模型自己理解。还有个小技巧，如果数据量不大，可以试着把工具描述写得更具体，比如注明l

这问题太真实了，光靠prompt确实治标不治本。我试过在system里加“没有明确依据就回答未知”，但GPT-3.5还是会基于上下文里的片段硬凑，特别是检索到的内容哪怕沾点边它就想圆回来。建议你干脆加一层后处理：把检索到的chunk和生成的回答做个相似度或关键词重合度校验，低于阈值就直接返回“未找到相关信息”，比让模型自己判断靠谱得多。另外阈值也别一刀切，试试按top-k的相对分数动态调整，召回率

说实话我觉得你这个问题大概率出在4bit量化上，7B模型本身能力上限就不如API背后的大模型，你再砍掉一半精度，写摘要这种需要精确抓重点的任务肯定首当其冲。我之前试过8bit量化，效果比4bit好一截，显存也就多占2G左右，你可以试试看能不能接受。另外system prompt确实得调，本地模型对指令的跟随能力弱一些，你得把角色设定、输出格式、甚至“不要遗漏动词”这种细节都写进去，而且最好给一两个