持续研究项目管理实践笔记

我之前也踩过这个坑，Ollama的11434是原生API，不是MCP协议，直接填到serverURL肯定连不上。MCP这边一般得用类似mcp-server-ollama的桥接服务，或者自己写个适配层把Ollama的接口转成MCP能识别的格式。你可以先确认下mcp.json里配的是不是stdio启动的本地server，而不是直接指HTTP地址。模型类型倒没啥限制，qwen2.5:7b完全能用，问题基

我也踩过这坑，Qwen2.5对角色标记确实敏感，但顺序比标记更重要。我的经验是把检索片段放最前面，用明确标签包住，历史对话按时间倒序紧跟其后，当前问题单独放最后并加一句“仅根据以上资料回答”。关键信息别在user里重复，容易让模型以为你在改问题，单独搞个“已知事实”块反而更稳。不过长上下文超过8k后它还是会漂，建议先截断历史再塞检索，别硬堆。

这个坑我太熟了，之前做合同信息抽取也是被表格和指代搞得头大。其实你观察到的“越调越细反而过拟合”是很真实的现象，因为few-shot示例本身就在给模型强烈的格式暗示，它会把注意力放在模仿示例结构上，而不是真正去理解语义边界。我的经验是别指望纯靠Prompt解决所有边界情况，模型在不确定时天然倾向于“填一个看起来合理的”，这是它的生成机制决定的，不是加一句“返回null”就能压住的。比较实际的做法是

我也踩过这个坑，后来发现根子往往不在LLM，而是检索出来的片段本身就有一堆语义相近但没用的内容，把真正关键的挤到后面去了。可以试试在rerank之后再做个去重或者MMR，把相似度太高的片段剔掉，只留信息互补的。另外prompt里可以明确让它先列出每个片段的关键点再回答，强制它过一遍全部上下文，比单纯说“请关注所有片段”管用。

我们之前A10上跑7B也遇到过这问题，后来用FP8量化加chunked prefill，10并发延迟稳在3秒左右，效果挺明显。你这场景其实瓶颈在prefill挤占decode，开连续批处理能缓解不少。张量并行对低并发收益不大，反而多卡通信有开销，不如先把量化做了。50人内部用，建议再加个请求队列限流，别让瞬时并发打满。

加个全局max_rounds兜底，再让每个Agent带个“认输”信号，搞不定就直接抛给人工。

我之前也踩过这个坑，工具调用超时直接把整个Agent搞崩了。后来在工具函数外面包了一层tenacity做指数退避重试，简单配置一下max_attempts和wait就行，比自己在Agent层面处理省心多了。不过要注意区分哪些错误值得重试，像网络超时这种可以，但参数校验失败就别傻傻重试了，得让Agent自己拿到错误信息去调整。

“答非所问但召回里有正确文档”这个现象太典型了，我上个月刚踩过一模一样的坑。你描述的情况大概率不是embedding或者chunk的锅，因为Top-5已经命中了，说明检索阶段基本及格。真正的问题往往出在生成阶段——LLM拿到5个chunk之后，可能被其中某个语义相近但主题不同的片段带偏了，尤其是“报销”和“请假”在向量空间里距离可能很近，都是HR流程类。建议先把prompt里的上下文顺序和标注方式

遇到过，我现在的做法是核心逻辑用大白话说清楚，格式和角色设定只在必要时加一两句。你堆的那些“专家模式”“step-by-step”其实很容易让模型把注意力放在表演上，而不是解决问题。我一般会先让它跑一版最简单的，再根据具体偏差去补约束，而不是一开始就把prompt写死。

LoRA秩32对8B模型做工具调用微调其实不算离谱，但alpha=64有点猛了，容易让模型过拟合到训练集里那些参数模板上，泛化到真实请求就乱编字段。我建议先降到秩16、alpha32试试，另外训练数据里最好混一些负样本，比如空参数、非法工具名，让它学会拒绝而不是硬编。还有个坑是MCP的schema描述没进prompt的话，模型只能靠记忆猜参数，幻觉率会高很多。

我之前也踩过这个坑，拆得太碎确实会让每个步骤都在重复交代背景，后来我改成全局系统提示词定好输出风格和角色，每个步骤只写“这一步要干什么、输入是什么、输出格式是什么”，冗余少了很多。但这里有个前提，就是全局提示词得足够稳定，不然它一变，所有步骤的输出都会跟着漂。调试的话我一般会把每个步骤的输入输出都打日志，然后固定前一步的输出去单独调后一步，不然真的很难定位是哪个环节的问题。还有一个挺关键的点，步骤

我也踩过这个坑，当时用Claude Desktop接MCP做内部知识库，文档一改检索就开始胡说八道。后来发现关键不是向量库本身，而是MCP那边得有个明确的“文档生命周期”概念，光靠资源订阅通知还不够。我的做法是在MCP server里维护一个文档指纹表，每次文档变更时触发一次删除加重新嵌入，而不是只做增量upsert。但这样有个问题，如果文档量大的话每次全量重嵌成本挺高的，所以后来改成按chunk

我最近也踩过类似的坑，后来改成按条款结构切，比如以“第X条”为边界，再限制单chunk不超过300 tokens，效果比硬切好不少。bge-small确实有点吃力，你可以先试bge-base，3090上跑推理问题不大，large再配量化也能撑。重排序不用一上来就上交叉编码器，先用向量召回top20再用轻量rerank模型筛一遍，社区项目完全够用。

多步任务还是拆成固定流程吧，让模型只负责单步，别指望它自己记住全局。

我也遇到过类似情况，感觉7B这个尺寸对system prompt的注意力确实不太够，尤其对话一长就容易被后面的内容带跑。你试试把角色描述压缩得更短更硬核一点，比如“银行客服，亲切，≤50字”，别写太多解释性的话，反而更容易被模型抓住。另外few-shot确实有用，但别放完整多轮，放两三个“用户问+理想回复”的短例子就够了，太长会挤占上下文。还有个偏方是在每轮回复前用括号再提醒一句角色，虽然土但挺管

我之前也踩过这个坑，把所有历史扔一个collection里检索，结果就是越聊越乱，top_k拿回来的全是些“好的”“嗯嗯”这种废话。后来我的做法是短期和长期分开两个collection，短期就存最近N轮原始对话，检索时直接按时间倒序取，根本不用向量相似度，因为上下文本来就该是连续的。长期记忆则走另一条路，先做一轮摘要或者抽取事实，只把值得记的信息写进去，这样噪声少很多。至于时间衰减，Chroma确

我去年底也在公司内部搞过类似的东西，当时用的是Qwen2.5-7B加LlamaIndex，向量库最后选了Qdrant，跑在docker里资源占用比Milvus小不少，而且它那个Python客户端跟LlamaIndex集成基本就是几行代码的事。中文检索这块其实主要看embedding模型，我当时用bge-m3，Qdrant和Chroma出来的召回差距不大，但Qdrant在过滤元数据那块确实顺手很多。

temperature设0.1确实不能保证完全确定，因为采样本身还有随机性，而且vLLM默认的top_p是1，等于没截断，尾部那些低概率token还是有机会被抽到。你可以试试temperature=0加上top_p=1，或者直接开greedy decoding，那样同输入基本就锁死了。另外few-shot示例的顺序和格式影响挺大的，模型很吃这个，建议把示例固定成一套模板，别每次拼prompt时顺序

验证集反弹基本就是过拟合了，试试加dropout或者早点停，别光盯着loss。

换SGD后动量缓冲会额外占显存，而且没开checkpoint的backward，第三个epoch碎片攒够了就炸。