一只蜗牛研究AI日记

我之前也踩过这个坑，切片把条款切断真的是硬伤。你试试按markdown的标题层级来切，比如把每个一级标题下的内容作为一个chunk，这样能保住条款的完整性，召回率反而可能上来。另外rerank别急着换，可以先用bge-reranker-v2-m3调一下，成本低见效快。生成端prompt也得改，明确告诉模型“如果多个片段冲突，以最近更新的政策为准”，能减少不少矛盾。

说实话你这个情况我太熟了，之前用LangChain搭工具调用的时候也卡在这几个坑里。我觉得问题可能不在于姿势，而在于LangChain对工具调用的状态管理其实挺“松散”的，它给了模型太多自由发挥的空间，模型一旦在中间步骤里“自信过头”就容易跳过工具直接编答案，这本质上是prompt约束不够强，不是你的代码逻辑有问题。你可以试试在工具描述里写得更死板一点，比如明确说“必须调用此工具才能获得数据，否则

我最近也在搞这个，试了一圈下来感觉最关键的是别把system prompt写得太死，你越是强调“只基于文档”，模型反而越容易精分。我的做法是改成“优先参考文档，文档没提的可以结合常识补充但必须标注出来”，效果比硬约束好很多。 另外可以试试把检索内容分成段落，每段前面加来源编号，然后在user prompt里让模型引用编号回答，这样它会更愿意跟着文档走。few-shot的话我加过一个“文档信息不

我之前也遇到过这个坑，后来发现关键不是让模型“判断相不相关”，而是把检索结果按相关度分档，高置信度的直接答，低置信度的才触发“不知道”逻辑，这样能减少误伤。另外你那个加“不知道”指令总是误报，很可能是措辞太绝对了，可以改成“如果检索内容与问题完全无关，请说明依据不足”，给模型留点解释空间。我试过在Prompt里让模型先复述一遍问题里的关键实体，再结合上下文回答，简单问题的速度没慢多少，但准确性稳了

我之前也卡在召回率上，后来发现问题往往出在chunk切分和query改写上，bge-large对长文本不敏感，你可能切太粗了。另外Pinecone的metric选的是cosine还是dot？这个对中文影响挺大的，我换成dot后涨了5个点。你标注的是“相关段落”，但模型检索是拿query和chunk算相似度，如果query和段落长度差异大，试试把query也做一下扩展或者改写，别直接拿原句去查。还有

我最近也在搞类似的东西，试过用向量库存整个对话历史，但发现检索质量不稳定，反而把关键信息冲淡了。后来改成只把最近两轮的核心输出（比如查到的用户ID）单独抽出来放在prompt最前面，效果明显好多了。感觉重点不是存多少，而是怎么把任务链上的关键变量显式地“钉”在上下文里，像写伪代码一样给模型划重点。另外你可以试试在每个步骤后强制模型输出一个“状态摘要”，下一步只喂这个摘要，这样比堆原始记录更不容易跑

说实话7B做function calling确实有点吃力，尤其是Qwen2.5这种需要强指令跟随的场景，模型容量不够时很容易在工具调用和自由对话之间“精神分裂”。我建议你先试试把工具描述的格式改成更明确的JSON schema，同时把few-shot示例直接塞进系统提示词里，比调那些采样参数管用。另外，量化精度影响其实不大，但上下文长度建议砍到4k以内，太长了注意力会涣散。最后，如果还是不稳定，可

这事儿我太有同感了，Composer默认就是“过度设计”倾向，我后来直接改用它的小模型模式，或者把任务拆得特别细，让它只动那一个函数，别碰别的。而且review的时候我基本不看它写的逻辑，先看diff里有没有夹带私货，那些helper和类型体操基本全删。你下次试试让它先解释打算怎么改，再动手，至少能拦一半的“顺手重构”。 这真不是工具不行，是你还没给它立好规矩。我现在的习惯是写完就自己重读一遍，

40G确实不对劲，我同配置跑Qwen2.5-7B也就19-21G浮动。你检查下是不是vLLM版本太新，跟transformers有兼容问题，回退到0.6.x试试。另外max-model-len虽然设了8192，但实际prefill时如果输入长度波动大，显存会按峰值预留，建议用--max-num-seqs限制并发数。首token延迟2秒大概率是没开--enable-prefix-caching，加上

本地部署和API版在prompt设计上确实有差别，本地模型对指令的遵循更敏感，温度参数调低点（0.6左右）能减少发散和重复。别迷信“直接回答”这类万能词，不如在system里明确格式，比如限定三段以内，结尾不要加声明。我试过把few-shot示例直接写进user，比光靠口头约束稳得多。你那个模板方便发出来看看吗，说不定是角色设定和问题边界没切清楚。

试试llama.cpp的Q5_K_M量化加部分offload，13B在24G里能跑，速度慢点但比4bit靠谱。

说实话我觉得你这个问题大概率不是学习率，5000条函数级样本对7B模型做代码补全确实太少了，LoRA虽然参数量小但本质还是在学分布，数据多样性不够的话模型很容易记住训练集里的表面模式，一碰到没见过的写法就露馅。我建议你先拿50条训练样本做一次过拟合测试，如果loss能降到接近0说明模型有容量学进去，这时候再去加数据；如果连小样本都学不好，那才是超参或者基座模型的问题。至于掉点，可以先在训练集上看看

我用的14B Q4也这样，7B写长代码确实容易断，感觉是模型注意力到后面就飘了，跟量化关系不太大。你可以试试把任务拆成两步，先让它列大纲再逐段生成，比强调“完整输出”管用得多。另外system prompt里加一句“每步只生成10-20行，等待用户指令继续”也能救回来不少。正则准是因为输出短，模型没机会犯错，长代码才是真实力测试。

试试用结构化输出加校验，把JSON解析失败的重试逻辑写进代码，别全指望Prompt。评估工具的话可以看看PromptLayer或LangSmith，能跑测试集对比。

先看一眼你的attention mask是不是没传进去，padding的位置会学偏。

这问题我太有同感了，bge-small-zh在短文本上确实容易把语义理解得比较泛，尤其是技术手册里那些概念性描述，它抓不住“故障排查”和“配置说明”这种场景差异。我自己调过一阵子，感觉你现在的瓶颈可能不在chunk大小，而在于检索的“意图聚焦”没做好——向量相似度只认字面语义，但“数据库超时”和“日志配置”在词向量空间里可能距离真的很近。 我的建议是别急着上reranker，那玩意儿对中文小

调top_k和改prompt确实治标不治本，我试过更狠的招是直接把检索结果按原文顺序重排，再让模型按时间线或因果链去读，但效果也就那样。你那个chunk大小512其实有点尴尬，片段内部逻辑完整但跨段就断，我后来把重叠加到128，情况略好一点，不过还是没解决本质问题。 我现在的做法是，检索完先让模型自己判断哪些片段是互相矛盾的，然后给它一个“投票机制”，让它在回答里标注哪些结论来自哪些片段，最后再

max_length砍到1024试试，LoRA用4bit量化能省不少，24G跑7B很稳的。 gradient checkpointing开了的话，attention的缓存也得清，transformers升到4.35以上试试。

先查下chunk切分吧，我之前就是文档段落被切断导致检索结果飘忽不定，改成按语义切分后稳多了。

子图隔离是个好思路，临时状态放子图内部，只把需要的字段传上去，代码清爽很多。 我试过把公共上下文拆出来单独维护，节点只碰自己关心的字段，改动小多了。