缓存偶尔抽风观察员

AI写的测试我都是当草稿用，跑之前必手动过一遍mock逻辑，不然坑太多。

跨章节问题只靠向量召回确实容易翻车，500字粒度对“预算+负责人”这种多跳信息本来就不友好。你可以先别急着换embedding，拿几条bad case把切分后的chunk打出来看，大概率是答案被切散了。加个bge-reranker做二阶段重排，召回top20再精排，通常比调top_k管用。另外Milvus里如果只存单向量、没做metadata过滤，也可以考虑按章节标题补点结构化字段辅助召回。

我前阵子也踩过差不多的坑，bge-small-zh在中文短查询上确实有点吃力，尤其你们内部文档如果术语多、缩写多，它经常抓不住重点。chunk调小不一定有用，反而可能把“报销流程”这种完整语义切碎了，导致每个块都缺上下文。你说的返回“出差申请”，很可能是这两块在文档里本来就挨着，embedding区分不开。加reranker我觉得值得试，bge-reranker-base或者m3e-reranke

多Agent抢显存这事我们也踩过，后来把模型推理统一收口到一个共享的推理服务，Agent只负责编排和调工具，显存问题基本就没了。上下文丢失建议查一下是不是每个Pod各自持有会话状态，换成Redis或Postgres做集中存储会稳很多。通信开销大可以试试用消息队列异步串起来，别让Agent之间同步等待。框架的话LangGraph对多Agent状态管理比裸LangChain顺手，可以看看。

我也遇到过，后来把“不知道”改成“根据已有信息无法确认”就好多了，模型对否定指令确实不太敏感。

我们之前也踩过这个坑，后来发现光调切片参数解决不了根本问题。现在做法是先用小模型对每个chunk做摘要再入库，检索时同时走原文和摘要两路，命中率提升挺明显。重排序一定要加，bge-reranker-base跑一遍成本不高，但能把top5的准确率拉高一大截。另外可以试试按语义切而不是按字数切，用embedding相似度找断点，比固定窗口稳很多。

混合技术栈那部分我也踩过坑，跨框架时它确实容易犯迷糊，建议先看实测再吹。

20个epoch还在2.3确实不太对劲，AG_NEWS上正常两三个epoch就该看到明显下降了。先别急着调超参，重点查一下[CLS]那个位置是不是真的拿到了有效梯度——很多人套模板时mask写错了，padding位置没挡住，注意力全被pad token吸走了。另外确认下label和logits维度对不对齐，AG_NEWS是4分类，别不小心按二分类的loss在跑，那loss卡在ln4附近就说得通了。

这个问题其实挺典型的，我前段时间也踩过类似的坑。光靠把架构文档塞进prompt基本没用，因为模型的注意力机制天然就偏向当前编辑的文件，上下文窗口再大也架不住它“懒得看”。我的经验是得把依赖关系显式地做成结构化的东西，比如用tree-sitter解析出调用图，再压缩成精简的邻接表喂给Agent，比自然语言描述管用得多。另一个思路是别指望一次重构整个调用链，改成让Agent先输出一个影响面分析清单，你

加个BM25混合检索再重排，纯向量对专有名词就是容易飘，换Milvus也救不了语义。

先别急着换embedding，几千页PDF的技术手册，问题大概率出在切分和解析上。PDF转文本经常丢表格和标题层级，chunk切出来语义都是碎的，再好的模型也救不回来。建议先把解析结果dump出来看看，再试试按标题结构递归切分，别用固定字数硬切。bge-large-zh在中文上确实比ada-002强，但得等你把文档质量这关过了再换，不然提升有限。

bge-reranker配上粗排召回挺稳的，我们线上就这么干，top20粗排再精排到5条效果明显好很多。

把每步结果强制写进下一轮prompt里，别指望模型自己记住。ReAct能帮上忙，但关键还是状态得显式传递。

光靠提示词不够稳，建议直接用工具调用的JSON schema约束模型输出，比反复强调格式靠谱多了。

5000条医疗数据确实偏少，建议先做领域预训练再微调，不然模型根本没学到医学术语。

Ollama跑7B做多步工具调用确实容易卡，换vLLM或试试Qwen2.5的function calling微调版会稳很多。

我们之前也踩过这个坑，后来改成用pdfplumber先把表格区域单独抠出来，转成HTML再按行切，跨页表格用它的table设置做合并，比markdown稳不少。但说实话纯表格检索还是得配个结构化字段，比如把表头当元数据挂到每个chunk上，不然向量化后数值和单位照样对不上。如果预算够，搞个轻量多模态模型兜底复杂表格确实省心，就是推理成本得算清楚。你们现在chunk大概切多大？表头信息有单独存吗？

说实话你这个来回横跳的经历我太熟了，去年做多智能体编排的时候也踩过一模一样的坑。其实核心问题不在框架本身，而在于你把“原型迭代”和“生产部署”这两件事绑在同一个技术选型上了。PyTorch动态图调试确实舒服，AutoGen这些框架生态也偏向它，但TensorFlow Serving的稳定性优势主要体现在高并发推理和版本管理上，跟Agent这种需要频繁改逻辑的场景其实不太搭。我后来是这么干的：训练和

我也遇到过这个情况，本地跑7B模型和网页版确实像两个东西，尤其是指令遵循这块差得挺明显。网页版大概率背后有更强的模型或者经过RLHF调优，本地开源版很多时候只是基座加轻量微调，对格式指令的理解本来就弱一些。量化确实有影响，q4和q8在提取类任务上差距能看出来，但更关键的还是Prompt写法——小模型特别吃“结构化提示”这套，你光说“提取三点”它容易跑偏，得把输出格式框死，比如直接让它按“1. 2.

7B做NL2SQL确实有点吃力，尤其涉及多表关联时表名幻觉挺常见。我之前试过CodeQwen-7B，比通用版Qwen2.5强一些，但复杂查询还是会翻车。你可以先查一下是不是schema太长没塞进上下文，或者试试把建表语句直接放进prompt里，比few-shot更管用。另外langchain有个sql agent的模板可以参考，不过别期望太高，14B以上才比较稳。