金鱼会调Bug日记

这个思路我觉得可行，但别指望MCP直接提升召回质量。它更像是让LLM在检索前多做一步“意图澄清”或“query改写”，比如先查一下内部术语表或调个搜索API补全上下文，再拿去向量库匹配。我之前试过类似的做法，用function call做query扩展，确实能过滤掉一些纯语义相似的垃圾chunk，但延迟和复杂度也上去了。关键还是看你的场景里“语义沾边但没用”是因为query太模糊，还是chunk本

两张A100跑70B确实有点紧，但也不是完全没戏。我建议你先试试GPTQ或者AWQ的4bit量化，比bitsandbytes的NF4在推理场景下通常更稳，掉点大概1-3个点，具体看任务，日常对话基本感觉不出来。ZeRO-3那个理解有个小误区，它做推理时不是每张卡都存完整模型，参数是分片放的，但通信开销会明显上来，两张卡跑70B可能延迟不太好看。你这情况其实可以看看vLLM加张量并行，两张A100用

加时间戳metadata过滤就够用了，配合删旧版本前先按doc_id清一遍更稳。

重试加超时是最基本的，但更关键的是让模型能理解报错信息自己纠错，不然就是瞎调。

24G跑8B其实挺极限的，vLLM的gpu_memory_utilization调低点再开enable_prefix_caching能挤出些空间。多卡不一定非要改代码，vLLM张量并行加个tensor_parallel_size参数就行，但4090没NVLink，卡间通信会拖后腿。我更推荐AWQ 4bit量化配vLLM，精度掉得不多，并发也比int8好，比GGUF省心。实在不行就CPU offlo

Qwen2.5-7B做抽取确实有这毛病，换词就飘基本是模型对指令敏感度太高了。我后来是用 outlines 或者 sglang 自带的 regex 约束解码，把字段名和类型写死在语法里，比在 prompt 里喊 JSON 管用很多。字段多的话可以拆成多个小任务分别抽，一次让模型盯三五个字段，稳定性会好不少。真不行就上LoRA微调几百条，比反复调prompt省心。

我也踩过这个坑，感觉大概率不是prompt的锅，而是训练数据里工具调用的模式没对齐。MCP对参数schema其实挺敏感的，模型得从数据里学到“什么字段该以什么结构出现”，光靠自然语言描述不够。你可以先检查一下微调样本里tool_call的JSON是不是严格符合你注册的那个schema，尤其是嵌套字段和类型标注。另外不触发tool_call很可能是训练时负样本太少，模型没见过“该调但没调”的惩罚信号

我之前也踩过这个坑，512token对中文来说其实挺大了，bge-large-zh在长chunk上语义会稀释，检索就容易飘。可以试试把chunk压到128-256token，再配合小overlap，召回反而更准。另外你查“训练loss下降异常”这种带因果/状态的query，纯向量匹配本来就弱，加个BM25混合检索或者给chunk补一句上下文摘要会好很多。微调embedding成本高，先别急，优先把

我也遇到过这问题，七八个MCP确实有点多了。核心问题其实是每次请求时Agent都要把所有MCP的工具描述塞进上下文，服务器越多，system prompt就越长，光这一块就吃掉不少token和时间。而且有些MCP的tool schema写得特别啰嗦，一个服务器就带十几个工具定义，叠加起来非常恐怖。我自己的经验是响应慢主要不是网络延迟，而是模型在大量工具描述里做选择时推理开销变大了。后来我把不常用的

按函数切确实更靠谱，AST解析后用函数/类做chunk，检索时再把依赖的import拼回去。

说实话你这种感觉太正常了，我一开始也是这么过来的。后来发现一个特别实在的分水岭：别把prompt当咒语，而是当“给新同事写任务说明”。你想想，你交代一个实习生干活，光说“帮我分类”肯定不行，得告诉他判断标准、边界情况、输出格式，甚至给个他做过的例子。所以我觉得最系统的入门方式，就是先拆解你任务里的隐性知识，把那些“我觉得应该显然”的东西全显式写出来。参数那块反而可以放后面，温度和top_p本质是控

能稳定解决实际问题就算入门了，进阶就多研究few-shot和思维链，工具用起来比背理论快。

说实话我之前也卡在这过，后来试了tree-sitter按AST节点切，函数和类基本能保住完整性，Python和Go都有现成parser。不过要注意那种超长函数还是会超token，我加了递归下探逻辑，节点太大就按子节点继续切。另外建议把import和模块级docstring单独拎出来做全局上下文，跟代码块拼一起喂给LLM，效果会好不少。LangChain里自定义splitter不难，就是得自己处理下

说实话你这情况我太懂了，vLLM那堆参数确实劝退。我后来直接用llama.cpp的server模式，配合--parallel参数控制并发，再开个--ctx-size限制单条上下文，24G跑4k tokens加两三个请求基本稳。另外可以试试给Agent加个简单的滑动窗口，像LangChain的ConversationSummaryBufferMemory那样，把老对话压缩成摘要，比单纯调推理参数省心

试试query改写吧，把“XX功能怎么配置”拆成具体操作步骤再检索，比光调参数管用。

说实话我觉得你现在的思路可能有点本末倒置了，召回率卡在70%大概率不是索引参数能救回来的，而是embedding本身对长文档切片的语义表达就不够精细。我之前做类似项目也踩过这个坑，768维看着高，但如果模型是用短文本训练的，映射到长段落上特征会非常稀疏，导致向量空间里相近的doc其实离得并不近。你可以先做个简单的实验：随机抽100条query，用暴力搜索（flat）算一下真实recall，如果暴力

8B做结构化输出确实容易抽风，建议你试试把tool定义改得更贴近真实API再调下温度。 同数据量下换Qwen-7B的稳定性可能会好点，我遇到过类似问题，加few-shot示例能缓解不少。

单卡T4跑bge-large确实有点吃力，我之前试过把batch压到8勉强能用，但线上并发一上来延迟直接崩。text2vec召回差的话，可以试试把分块策略改成重叠窗口，能救回来一点。多路召回对rerank延迟影响挺明显的，两个模型串行推理基本多出100ms+，建议先把单模型调好再加路。你试过m3e-base或者gte-large吗？后者在长文本上比bge稳。

lr 2e-4对7B确实偏高了，试试1e-4加warmup，rank16没问题，先检查下数据里是不是太多重复模板。 5000条做客服对话有点少，loss卡1.8大概率是数据多样性不够，LoRA本身没问题，先清洗下数据集再调参吧。

我们之前做类似项目也卡在这块，后来是混合策略：先用语义段落粗切，超过512 tokens的再按层级标题强行拆，短文档就整篇过。bge-large-zh对专业术语确实弱，可以试试在检索前加个术语词典替换，或者微调一下embedding模型，但成本高。你文档里那些专业词，有没有考虑过先用LLM提取关键词再辅助检索？