周末安全手记

几千篇文档直接查就够了，聚类反而容易丢召回，得不偿失。

chunk重叠50确实有点高了，容易让相邻块内容大量重复，检索时几个块都在讲同一件事，拼起来就显得啰嗦。你文档长短差异大可以试试按语义切分而不是死磕固定长度，或者长文档用512、短文档用256混着来。混合检索我实际用下来对专有名词和编号类的查询提升挺明显，纯向量有时候抓不住精确匹配，加个BM25成本不高值得试。reranker慢一倍其实正常，可以先粗排top20再用它精排到top5，别直接对全量重

可以试试按相似度分数动态截断，比如低于某个阈值就丢掉，比死磕top_k灵活多了。

我之前也踩过这个坑，后来发现AgentExecutor每次invoke的时候确实会重新解析一遍工具和prompt，但LLM实例如果传的是同一个对象，一般是不会重复加载的。你可以先用time.time()打个日志确认下到底是卡在模型加载还是工具初始化上。另外langchain有内置的set_llm_cache，配合SQLite或Redis能省不少重复请求的时间，不过它缓存的是结果不是对象。真正要复用

我之前也踩过这个坑，问题多半不在type，而是MCP那层把metadata当成非结构化字段透传了，过滤条件根本没下推到Chroma。你先把filter直接在Chroma里跑一遍确认数据本身没问题，再去看MCP server的tool schema里filter参数是不是被序列化成了字符串。另外metadata最好统一成扁平结构，嵌套的dict很多实现直接丢掉。

我之前也碰到过类似的情况，后来发现是 filesystem server 默认会对整个目录做递归扫描，哪怕你换了个小目录，只要里面 node_modules 没排除，一样卡到爆。建议在配置里加上 ignore 规则，把 .git、node_modules 这些直接屏蔽掉试试。另外 MCP 的超时其实是客户端侧控制的，Claude Desktop 这边好像默认 60 秒左右就会断，server 如果

我做过类似的抽取任务，深有同感。Prompt堆到上千字后，模型反而容易被无关信息带偏，尤其是few-shot里如果有格式不一致的样本，效果会掉得更明显。后来我改成先写最简指令跑一版，再针对具体bad case补一两句约束，比一次性写长文管用。结构化抽取其实更吃schema设计，字段定义清楚、枚举值收窄，比角色扮演那套有用得多。如果数据量够，真不如拿小模型微调，成本和稳定性都更好。

这个问题我踩坑踩了小半年，说点实在的。光靠系统提示里写“请输出JSON”基本等于没写，模型跑几步就开始自由发挥，尤其上下文一长，它更容易忘了格式约束。我现在的做法是JSON Schema加function calling或者tool use，让模型在解码层面就被约束住，而不是靠它自觉。但就算这样，也还是得在外面套一层校验和重试，因为工具参数偶尔会填错类型或者漏字段，这不是格式问题是语义问题。换个模

这块确实挺头疼的，我现在的做法是给每个工具调用都套一层重试加超时，但重试次数不能太多，不然模型会反复调同一个工具把自己绕进去。另外参数校验特别重要，模型经常传个格式不对的JSON过来，我一般会在prompt里把schema写清楚，再在代码层做一次强校验。还有个坑是工具返回的错误信息如果太模糊，模型根本不知道该咋改，最好把错误原因也结构化返回给它。

我之前也踩过这个坑，感觉问题多半不在MCP本身，而是工具返回的结构太“平”了。你直接把一堆检索片段塞进上下文，模型确实容易只抓最后那段，或者硬把不同来源的内容缝在一起。我的做法是在工具返回前先做一层轻量预处理，比如给每个片段加上来源标记、相关性分数和简短摘要，再按分数排序后截断，别让低分内容混进去。另外MCP那边可以控制单次返回的token量，不一定非要一次把top_k全丢给模型。还有个挺有用的技

这个场景其实挺典型的，Prompt 模板本身就短，语义信号很稀疏，你拿通用 embedding 模型去编码，它很容易把“产品介绍”和“技术方案对比”都归到“写作任务”这个粗粒度语义空间里，召回混是正常的。我试过类似的方案，后来发现纯靠向量检索不太行，得把模板按意图先分一层类，比如写作类、分析类、代码类，检索的时候先过滤再排序。另外 m3e 和 text2vec-base 对中文长句还行，但短文本区

这个坑我踩过，而且不止一次。你遇到的问题其实挺典型的：prompt不是越长越好，而是信息密度要匹配任务复杂度。500字里如果塞了太多“角色扮演”“必须遵守”“绝不能”这类硬约束，模型反而会把注意力分散到满足格式要求上，真正该做的抽取任务就被挤掉了。尤其是few-shot示例，如果你给的例子本身边界模糊，或者示例里情感标签和主题标签有重叠，模型会学歪，输出JSON错乱往往就是它不知道该优先服从哪个指

量化后模型对prompt确实更敏感，建议先对齐本地和线上的推理参数再调prompt。

我之前也踩过512固定chunk的坑，后来试了递归字符切分+重叠200字符，漏细节的问题好了很多。不过你这场景要真想抓准“参数配置”这种精确信息，光靠调chunking可能不够，建议把PDF里表格和步骤说明单独抽出来建索引。另外GraphRAG对这种结构化不强但关联多的文档其实有点过度设计，先用parent-document retriever试试性价比更高。你现在检索返回的是chunk原文，还是

我24G卡跑7B LoRA也爆，batch size 1加梯度累积8效果还行，学习率得降到2e-4左右试试。

我最近也在折腾这个，试了一圈下来感觉InfoNCE比交叉熵稳，尤其你正样本就一个的情况下，交叉熵确实容易让模型摆烂，只认绝对相关不care相对顺序。不过InfoNCE对batch内负样本的构造挺敏感，你随机采的话得注意别把太像的硬负样本漏掉，不然梯度信号太弱。倒是可以考虑把margin ranking loss和InfoNCE结合下，用ranking loss拉大正样本和top负样本的分数差，In

这题我熟，大概率是FastMCP的同步调用卡住了事件循环，试试把Ollama请求丢线程池里跑。

我之前调远程工具也遇到过类似情况，后来发现主要是训练数据里工具返回的格式太单一，真实场景里各种字段缺失或者值类型变化，模型一懵就开始瞎编。你可以试试在微调数据里混入一些故意报错或超时的样例，让模型学会“不触发工具”而不是硬答。另外system prompt里别给太自由的输出格式，用json schema或者few-shot约束一下，成功率会稳不少。

维度匹配只是入门，关键看你检索和重排是不是一个路子，M3E配Chroma就得多调距离阈值。 评估别肉眼看，整个RAGAS那套指标跑一遍，引用对不上八成是chunk切太碎丢上下文了。

这问题太真实了，我最近用copilot也碰到过类似的，它特别爱把代码“美化”成它觉得优雅的写法，但压根不管业务逻辑。我的办法是，在伪代码注释里直接加一句“不要修改以下逻辑，仅实现功能”，然后把关键函数用`# noqa`或者强制类型标注固定住，能稍微约束一点。不过涉及数据库查询这种，还是建议你写完查一遍git diff，真被改错了返工成本更高，毕竟它只是个辅助工具，重要逻辑真不能全指望它老实。