深夜低代码实验室

这个问题我也遇到过，挺烦人的。Cursor默认会参考大量开源代码，那些代码里framer-motion和lodash出现频率太高，模型就养成了习惯。光在prompt里说“别用”确实不太管用，因为它的上下文窗口里没有足够强的约束信号。我后来在项目根目录加了个.cursorrules文件，里面明确写清楚项目技术栈和禁用依赖清单，效果明显好很多。另外建议你把package.json打开让Cursor索引

我之前也遇到过类似问题，后来换了方案。

这个现象挺常见的，Recall涨了但端到端掉，大概率是负样本构造太“软”了——你的negative可能都是同领域但不同答案的文档，模型学到的只是“领域内区分”，没学到“相关性区分”。可以试试加一批跨领域的真负样本，或者用in-batch negative时控制下batch内同质化程度。另外三个epoch可能过拟合了，BGE-M3这种底座微调一两轮往往就够了，训太多反而把通用语义空间搞塌了。

多轮tool call确实容易让KV cache膨胀，因为每轮工具返回的结果都会拼进上下文，vLLM默认不会主动回收这些块。你可以试试开`--enable-prefix-caching`，再看看`--max-num-seqs`是不是设太高了，并发一多显存就压不住。另外Agent场景下最好限制历史轮数或者做上下文摘要，不然每轮都全量prefill，显存涨是必然的。我之前跑类似配置时把`gpu-mem

写得挺好，建议补充一些性能数据。

有没有更详细的教程推荐？

学到了，感谢分享！

大概率是推理时system prompt和训练模板没对齐，LangGraph那边的工具注入格式也得跟训练时一模一样才行。

我遇到过类似情况，后来发现是角色设定把模型的注意力带偏了。你让它当法务专家，它就真去“分析”合同了，反而忽略了你要的纯提取任务。提取类需求其实更像填空题，指令越直接越好，加人设等于给它加了戏。我现在只在需要判断或润色时才加角色，纯抽取就直接说清楚要什么字段、什么格式。

感觉像是ReAct把历史对话带偏了，试试清空记忆再单独测新文档，看能不能召回。

我之前也踩过这个坑，改写后反而把原query里的关键实体给丢了。GPT-4特别爱自作主张地“优化”措辞，结果跟知识库里的术语对不上，向量空间里就飘走了。你试试把prompt改成只做同义词扩展、别动原句结构，或者干脆用query+改写各检索一次再做融合。bge-small对短文本敏感，改写后句子变长反而可能稀释了核心词权重，这个也得留意。

几万条片段Chroma完全够用了，持久化没问题，性能也没网上说的那么不堪，真正坑的是并发和分布式场景。Milvus那套etcd+minio+pulsar的架构，个人项目部署纯属给自己找罪受，杀鸡用牛刀。其实可以看看Qdrant，单机docker一条命令就起来，性能比Chroma强不少，API也清爽，以后要扩也顺。真到数据量爆炸那天再迁Milvus也不迟，向量库这块迁移成本没想象中那么高。

我也遇到过这情况，后来改成先自己把组件骨架和state逻辑手写出来，再让AI补样式和重复代码，它就没法带偏了。关键是别让AI在你还没想清楚之前就动手，Tab补全太顺手反而容易偷懒。还有个笨办法，把AI建议当code review看，不直接接受，先问自己它为什么这么改。慢慢就形成习惯了，AI还是打字员，思路得自己攥着。

两个人维护确实别碰重框架，我们后来直接用OpenAI SDK加个简单路由，反而稳得多。

我现在的做法是工具定义只放System里，但会在每轮User消息末尾加一句极简的“可用工具：xxx”，相当于做个提醒锚点，实测多轮后调用准确率明显好一些。全塞User里token确实扛不住，而且模型容易把工具说明当成任务上下文来理解。结构化的话可以试试把工具签名压缩成一行JSON Schema，System里只留这一份，别写大段自然语言描述。

我也踩过这坑，后来用Send API拆子图才理顺，全局state共享太容易读到脏数据了。

我一般把硬约束抽成结构化字段每轮显式带上，比塞历史靠谱多了。

500条确实少了点，风格类任务建议至少2000条起，不然模型学不到稳定模式。

合规优先的话BGE-large基本够用，ada那点精度差距在FAQ场景感知不明显，不值得冒险。

MCP本身不管状态，session_id得自己传到工具参数里，内部按sessionId做存储分区就行。 我做过类似的，在server层加个dict存sessionId做key的上下文，多用户串不了，Redis都不需要。