长期关注战略增长记

先把数据里的错别字和脏样本过一遍，客服场景答非所问多半是数据里噪声太多，LoRA本身不背这个锅。

表格数值老丢的话，先看看chunk切分有没有把表格拦腰截断了，技术报告里表格跨页很常见，切散了模型根本拼不回来。我之前也踩过这坑，后来改成按结构化块切、把表头带上，命中率好了不少。Prompt里可以试试让它先列出表格行再逐行对齐，比笼统说“注意表格”管用。还有指标混淆的问题，可能得在模板里把模型名和指标绑成固定格式输出，别让模型自由发挥。

法律这种任务确实容易翻车，我之前做合规问答也遇到过类似情况。感觉问题可能不全在prompt上，top3召回虽然准，但片段之间的信息可能不完整或者有歧义，模型就容易自己脑补。可以试试在prompt里明确要求它先引用原文再给结论，格式上逼它落地到检索内容。另外system prompt别写太泛，针对法律场景加一句“条文编号和内容必须与上下文一致”会稳一些。

我之前也踩过这个坑，后来发现关键不是让LLM瞎改写，而是给它明确的改写目标，比如让它把口语化query转成关键词密集的检索式，同时保留原始query一起做多路召回，效果稳不少。另外embedding模型本身对长句和疑问句就不太友好，改写时去掉“怎么样”“请问”这类词其实挺有用的。你说的LLM改写不稳定，可以试试限制它只能做同义替换和关键词提取，别让它自由发挥，不然语义漂移太严重了。

这个坑我也踩过，感觉核心问题不在流程分几步，而在于工具返回的数据和检索内容在上下文里是“平铺”的，模型分不清哪段来自哪。我后来做的一件事是给每个来源打显式标签，工具返回统一包一层结构化字段，比如{"source":"tool_inventory","value":...}，检索片段也带自己的source标记，然后在提示词里明确要求引用时必须带上source，生成答案时按source区分语义。另外工

我前段时间也碰到过类似的情况，后来发现是 Claude Desktop 那边默认超时时间设得比较短，server 其实还在处理但客户端已经断了。你可以看下 MCP 的配置里有没有 timeout 相关的参数，把它调大一点试试。另外官方 filesystem server 在大目录下遍历确实会慢，换个 node_modules 少点的目录对比一下就知道是不是这个原因了。

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

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

刚入门，这个对我帮助很大。

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

我理解是MCP把检索、embedding、rerank这些打包成一个标准接口，客户端就不用各自实现一遍了。并发写入确实是个坑，chroma的MCP封装我记得默认是单进程的，多个客户端同时写会锁住，读倒是还好。生产环境更建议把写入和查询分开部署，或者直接用服务端模式而不是本地MCP。你们那边QPS大概多少，量大了估计得自己重写一层。

我之前也踩过这个坑，大概率不是配置写错了，而是Claude Desktop启动MCP server的方式跟你手动跑脚本不一样。它是以子进程方式拉起来的，继承的环境变量非常干净，Ollama那个host地址如果只在你shell的profile里设了，子进程里根本读不到，就会一直卡在请求上直到超时。你可以试试在server代码里显式指定base_url，别依赖环境变量。另外还有个隐蔽的点，stdio模

我之前也踩过一模一样的坑，拿bge-large-zh在医疗问答上微调，结果检索top10命中率直接掉了七八个点，当时人都麻了。后来复盘发现最大的问题就是负样本，随机采的负样本太“简单”了，模型学到的判别边界跟你实际检索场景完全不匹配，反而把原来预训练学好的语义空间给带偏了。hard negatives确实更管用，但也不能太hard，得是那种语义相近但实际不相关的，比如同一条法律条文下的不同解释，或

Qwen和Llama对温度确实敏感度不一样，我这边Qwen1.5也是0.7左右最稳，Llama系普遍得压到0.3以下才不飘。few-shot老被忽略的话，试试把格式约束放到system里或者用JSON mode强约束，光靠示例模型经常装看不见。结构化输出我现在基本不硬调prompt了，直接上outlines或者vLLM的guided decoding，省心太多。

数据重复率查过没？GitHub爬的代码重复度很高，建议先去重再喂给模型。

几百条数据微调7B模型做rerank，这个量级感觉不太够，LoRA很容易过拟合到标注集的分布上，loss降不代表排序能力真的学到了。你有没有单独拿一个held-out的测试集看过NDCG或者MRR？如果训练集和测试集切分有重叠或者同源，指标会骗人的。另外LLM做rerank常见的坑是它倾向于给流畅但无关的文档打高分，尤其你的标注如果只标了相关性没做hard negative挖掘，模型学不到细粒度区

我之前也踩过这个坑，用的也是Chroma，后来是相似度阈值加时间衰减一起上的。具体做法是写入前先检索top1，如果cosine相似度超过0.95就直接更新那条记录的时间戳和元数据，不新增。光靠哈希去重对“换种说法问同一件事”基本没用，LLM摘要又太慢还容易丢细节。相似度阈值调太低会误合并，我一般放在0.92到0.96之间试，再配合一个短期窗口内的去重就够了。

多步Agent的Prompt确实不能靠堆约束，越堆越容易互相打架。我现在的做法是把每一步拆成独立节点，每个节点只负责一件事，输出格式用JSON schema卡死，这样前一步跑偏后面还能靠校验兜住。评估这块别想着一上来搞全自动，先攒几十条真实badcase，每次改完Prompt手动跑一遍对比，比啥框架都管用。另外工具描述本身也很关键，参数含义写清楚比在System Prompt里反复强调有用得多。

工具描述越详细模型越容易纠结，试着精简下描述、加个调用次数上限，超时多半是死循环了。

我都是先在Composer里圈定要改的文件范围，不然它老去动store。你这情况八成是提示词没框住上下文。