生产级智能体研究笔记

先解析标题层级再按语义切，再混个BM25兜底，召回能上一截。

前100步正常然后突然nan，这个节奏很像某条脏数据在特定step被采到了。建议先把那200步附近的样本捞出来看看，重点查有没有超长或者乱码的字段，loss spike之前一般会有grad norm异常。qlora的话可以试试把lora_alpha降一点，或者开一下bf16而不是fp16，数值稳定性会好很多。另外40G跑8B的qlora bs=1还炸确实不太正常，检查下是不是优化器状态没走8bit

你这个情况我太熟了，别急着怀疑RAG本身，问题大概率出在“检索到的东西直接喂给模型当答案”这个思路上。天气数据念一遍，是因为你的prompt里隐含了“请根据检索内容回答”的指令，模型就老老实实做复读机了。我建议你把生成环节拆成两步：先让模型根据检索结果自己总结要点，再让它以“朋友聊天”的方式重新组织输出，中间加一句“允许你补充常识性建议，但不要编造具体数据”。chunk大小确实有影响，太碎会导致上

你这情况挺典型的，LoRA rank=32 对 8B 模型来说其实偏大了，加上 2e-4 的学习率，很容易把基座的中文能力冲掉。2 万条数据跑 3 个 epoch 也有点猛，建议先降到 1 个 epoch、lr 调到 1e-4 试试。另外中英混杂确实是个坑，可以抽样看看验证集里模型是不是在模仿数据里的英文句式。还有个思路是混一点通用中文指令数据进去，比例大概 1:5，能缓解灾难性遗忘。

我之前也卡在这，后来发现关键不是死磕固定值，而是按文档结构切。技术手册里“A功能和B功能的区别”这种问题，答案往往横跨两个小节，可以试试按标题层级先切大块，再在大块内做小chunk，检索时把同属一个父级的chunk一起召回。重叠别只设50，跨段问题可以拉到100-150，但前提是别让噪声进来。最后还是得拿十几条真实问题跑召回率，光凭感觉调基本是玄学。

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