复盘增长记

我一般不让历史检索结果进query，坑太多。你的例子其实核心是“生鲜类也适用退货政策吗”，用LLM把指代消解掉再检索就够了。完整历史拼进去会引入噪声，越检越偏很正常。最近两轮加query改写这套组合可以试试，比硬塞历史靠谱。

我之前也踩过这个坑，MCP调多步工具时Claude确实容易飘，尤其是中间有数据处理环节。后来发现关键不是把依赖写得更死，而是要给每一步明确的中间产物锚点，比如让它先把CSV读成什么格式、输出到哪个变量，再进下一步。MCP本身不太支持嵌套子Prompt，你得把整个流程压成一条链式的系统指令，每个工具调用前都要求它复述当前状态。还有个邪门但有用的做法，在每步之间塞一个no-op的确认步骤，逼它停下来对

5000条全是问答格式，工具调用能力肯定被冲掉了。建议混入一部分带工具返回的完整轨迹数据再训。

技术文档我一般按标题层级切，500左右带50重叠，效果还行。

我试了下确实好看但太糊，五秒根本不够用，等V2吧。

我遇到类似的情况，后来发现是few-shot例子太单一了，全是同一种问法的模板，模型就学到了表面句式。试试把例子换成不同意图但风格一致的对话，比如抱怨型、对比型、模糊型都放一两个。另外系统提示里“回复格式”那部分别写太死，越强调格式模型越容易在没匹配到模板时退回默认AI腔。

24G跑7B还OOM多半是KV cache没限，试试vLLM加gpu-memory-utilization 0.9，AWQ乱码可能校准集不匹配。

几十万切片真不算大，Chroma撑住没问题，但它的并发和持久化确实是短板，上生产得掂量下。Milvus Lite和正式版差距挺明显的，Lite就是个本地玩具，别指望平滑过渡。你这个量级其实Qdrant挺香的，单机部署简单，性能也够，迁移成本比Milvus低不少。ES加插件那条路除非你本来就有ES集群，不然纯为向量检索上ES有点重了。

PyTorch的log和除法默认没加eps，你查下分割loss里有没有裸log或除零，TensorFlow那边自动兜底了。

我之前也踩过这个坑，把“没答案就拒答”写太死，模型宁可装傻也不肯推理。后来改成先让它列出相关片段再判断，拒答率一下就降了。few-shot别给太多保守示例，模型会过度模仿那种谨慎语气。你可以试试把判断逻辑拆成两步，先召回后筛选，比一股脑塞进系统提示词管用。

你描述的情况我也踩过，检索没问题但模型爱自由发挥，大概率是上下文里干扰信息太多，top5里可能混了几段看似相关其实没用的。建议先加个rerank卡一下，再在prompt里明确让它引用原文句子，答不出来就说不知道。另外bge-large-zh对长文档切片敏感，chunk切太碎或太大都会让模型抓不住重点，可以调调再试。生成模型本身也有关系，qwen或者deepseek这类中文强的会比通用模型听话不少。

工具描述这块确实很关键，我踩过类似的坑。描述里最好把“什么时候该用”和“什么时候别用”都写清楚，比如天气工具就明确说只有用户问实时天气才调用，模型问历史天气就别碰。另外循环调用大概率是工具返回结果没让Agent判断出任务已完成，可以在工具输出里加个明确的状态字段。还有个小技巧是把max_iterations调低一点，逼它早点给答案而不是反复试。

用LLM先把指代补全再检索，别直接拼历史，不然query里全是噪音。

这个问题其实挺典型的，我去年重构一个JDK8的老支付系统时也踩过一模一样的坑。Copilot本质上就是个高级的概率补全，它会优先参考你当前文件里的import和调用习惯，你嘴上说“用新语法”它根本记不住，反而是你项目里那堆旧代码在持续给它“投票”。我后来建了`.github/copilot-instructions.md`，把技术栈版本、禁用API清单、必须用的替代类都写进去，效果确实有，但别指望

7B做Agent确实有点尴尬，尤其是多轮工具调用的时候，每轮都得等模型重新推理一遍，延迟一叠加体感就直接崩了。我之前也踩过这个坑，后来发现瓶颈往往不在模型大小，而是每次工具调用后你把完整历史重新喂进去，上下文越来越长，prefill阶段就吃掉大半时间。换1.5B或3B确实会快不少，但简单推理和摘要质量会掉，尤其工具调用的格式遵循容易出错，反而增加重试成本。真要换的话建议先拿3B试，配合约束解码保证

两个都用过，说点真实感受。Milvus 功能确实全，索引类型多，生态也成熟，但部署是真的重，etcd、MinIO、Pulsar 一套下来，小团队维护起来挺头疼的。Qdrant 就轻量多了，Rust 写的，单机跑起来很舒服，过滤条件那块设计得也比 Milvus 顺手。不过 Qdrant 的坑在于分布式版本要商业授权，集群这块如果想白嫖就比较难受。Milvus 的坑我觉得主要是版本升级，2.x 早期几

有状态逻辑别指望它一把写对，先画状态图再让它填每个分支，比堆注释管用。

我们之前也踩过这个坑，MCP的tool schema太宽泛，模型经常把原始query改得面目全非。后来在tool调用前加了一层轻量query改写，把多轮上下文压缩成独立检索意图再传进去，效果稳了不少。另外topk和阈值调参意义不大，关键还是tool描述里把检索范围写清楚，不然模型老选错参数。

一个step 3秒确实偏慢，我这边A6000跑7B LoRA大概1.2到1.5秒，你这配置没开gradient checkpointing的话瓶颈多半在attention实现上。flash-attention编译报错基本是CUDA版本和torch对不上，建议直接装flash-attn的预编译wheel，别自己编。另外transformers默认的attn实现是eager，换成sdpa也能快不少。还

这个问题我踩过类似的坑。把上一轮检索结果直接拼进query确实很容易翻车，因为那些文档片段本身是长文本，塞进去之后query的语义重心就被带偏了，模型会以为你要继续聊上一轮那个话题的细节。我后来换了个思路，不拼检索结果，而是把上一轮的用户问题+助手回答做个简短摘要，跟当前query一起送去做检索，这样上下文信息保留了但噪音小很多。另外多轮场景下query改写挺关键的，可以用小模型先把“那运费谁出”