生产级智能体研究笔记

50万条1536维不算大，IVF_FLAT召回率跟暴力差这么多有点奇怪。先检查下建索引和查询时embedding是不是同一套归一化流程，OpenAI的向量本身是归一化的，如果你入库前又做了一次或者查询时没做，余弦就会飘。另外nprobe调大试试，nlist设个4096，nprobe拉到64以上，如果还不行那可能是Milvus的metric_type设错了。rerank能提精度但救不了召回，召回不够

光靠prompt里写1234真的很难让模型老实，它本质上是概率生成，不是执行代码，你越强调顺序它有时候越叛逆。我现在的做法是把意图判断单独拆成一个轻量调用，先拿到结构化结果再走后续流程，等于用代码把步骤锁死。另外你说的脑补缺失信息，可以在prompt里明确要求信息不全时必须追问，而不是自己填。Agent框架确实需要外面加一层状态机或者路由逻辑，别指望prompt全包了。

几万条文档用bge-m3跑出3-4秒确实偏慢，先确认下是不是每次查询都在重新加载模型或者没做batch，正常FAISS检索应该是毫秒级的。缓存这块MCP本身没内置，可以在工具层自己加个LRU或者用query的hash做key，重复查询直接返回省掉embedding开销。换pgvector或milvus对几万条数据提升有限，瓶颈大概率在embedding推理上，可以试试onnx量化或者换bge-sm

试试明确说“只输出diff”或者干脆要求它用注释标出改动行，比说“别动”管用多了。

我最近也在踩这个坑。经验是别指望一个prompt搞定多步推理，拆成子任务调用反而更稳，每一步只让模型做一件事，中间结果落盘再喂给下一步。另一个管用的是强制引用，让模型每给一个结论都带上检索片段编号，没编号就重试，这样编数据会少很多。还有个小技巧是在工具返回里加个字段标明“数据来源”，模型看到空值就不敢乱编了。

说实话你十几万条数据就卡，多半是embedding维度太高加上没做量化，bge-m3出来就是1024维，Chroma本地模式扛不住很正常。个人项目真没必要上Milvus那套分布式，先看下官方文档里hnsw的efConstruction和M参数调了没，实在不行试试Qdrant的本地模式，docker单机起一个也不麻烦。延迟跟召回率不是二选一，小项目里bge-m3的召回上限远高于你数据量带来的瓶颈，先

说实话你这个现象我太熟了，之前调法律文本也卡在1.8附近死活不动。先说结论，大概率不是基座模型中文能力的问题，llama3的中文底子做指令微调够用了，重点还是数据结构和训练策略的匹配。一万条问答对看着不少，但中文法律这种垂直领域，如果答案里大量重复法条表述或者固定句式，模型很容易学到“抄模板”而不是“推理”，loss降不下去就是它在犹豫要不要背下来。我建议你先抽几十条训练样本看看loss是不是在个

试试把工具数量拆成独立子Agent，单次循环只处理一件事，别让LangChain一口气决策太多步。

我之前也踩过这个坑，后来干脆把State拆成两个子模块，research_result和draft分开维护，只在最后汇总时合并，别让写作Agent直接读研究Agent的中间变量。另外LangGraph的StateGraph本身支持Reducer，可以用add_node之间显式声明哪些字段要覆盖哪些要追加，比手动塞dict清晰很多。如果你流程固定，试试用Pydantic定义严格schema，跑完校验

我跑7B模型写代码也碰到过类似情况，参数名被偷偷改掉真的挺烦的。后来我发现把temperature调低到0.1以下，然后配合把函数签名放在user消息里而不是system里，情况会好不少。还有个土办法是直接在prompt里写“如果改了参数名，代码直接报错”，有时候吓唬它一下反而管用。不过说实话，7B的指令跟随上限就在那，要求太精细的话可能真得上14B或者用带代码微调的版本。

你那个思路没错，MCP里prompt就该当函数用，变量留好，别把上下文当硬盘使。 动态拉取才是正解，硬塞长指令模型反而抓不住重点，跟写代码一个道理。

检索不准先别调参，重点查下embedding模型和查询改写，试试把用户问题先做意图压缩再检索。 调参解决不了语义漂移，你该看看chunk之间是不是缺上下文关联，加个rerank模块比堆top_k管用。

base64塞JSON确实笨重，建议MCP里只传元数据或文件引用，实际数据走对象存储或gRPC拉取，代理转发到Triton更灵活。

说实话你这情况我太熟了，之前调一个垂直领域模型也卡在loss平台期，症状几乎一模一样。我觉得大概率不是学习率的问题，你这范围已经试得挺合理了，问题更可能出在数据上——论坛帖子那种口语化表达和标点符号滥用，对LLaMA这种预训练模型来说就是纯噪声，它去拟合这些不规则模式时很容易陷入局部最优。你提到生成的回答开始复读标点，这其实是个信号，说明模型在尝试模仿训练数据里那些奇怪的格式，而不是真正理解指令。

固定500字符对技术规范这种密集信息文档太粗糙了，建议按章节或语义边界切分试试。混合检索确实值得加，关键词能兜住向量召回漏掉的长尾术语。

遇到过类似的坑，小模型对few-shot的依赖度其实挺高的，但示例质量比数量重要。你选的示例可能太“像”真实对话了，模型容易记住字面，不如试试把示例里的实体和表达方式抽象化，比如用占位符代替具体产品名。另外7B模型对格式很敏感，你可以把指令改成“按以下分类规则判断，不要参考示例中的具体措辞”试试。温度0.1没问题，但max_tokens 128对意图识别可能不够，输出长一点给模型更多思考空间。

我一般拿它当结对编程的实习生看，重构建议会听，但每个改动都得自己把边界条件捋一遍。尤其是事务和懒加载这种隐性状态，AI根本看不见，你让它写单测它也是先编个能过的版本。我现在有个笨办法：让它先给方案，我口头问三个“如果这里返回null会怎样”，答不上来就自己改。工具脚本随便飞，核心逻辑还是自己手写稳当。

说实话这次中兴确实让我有点改观，OEX超节点强调协同而不是单纯堆算力，这个思路在分布式训练里挺关键的，毕竟卡间通信瓶颈往往比算力本身更致命。不过全栈这事真不是光靠一家能成的，我自己做AI落地时最深的感觉就是，系统层和模型层的适配调试极其耗时，中兴要是能让第三方框架直接跑在AIOS上不用魔改，那才算真有戏。另外手机和机器人这块，生态伙伴的开放程度才是决定能不能规模化的问题，不然容易变成自嗨。

只存embedding省空间但检索回来没上下文，还是得带原文，不然LLM根本不知道这段记忆在说啥。

正常，transformers那边默认没开flash attn的话显存就是很浪费，量化后长上下文质量8K内基本无感。