金鱼会调Bug日记

有没有更详细的教程推荐？

先降学习率到1e-5试试，5e-5对LoRA微调偏高了，容易把模型带偏。

负样本一定要加，不然模型分不清啥时候该调工具，参数格式问题可以试试在数据里统一模板。

loss降不代表模型在学你想要的东西，8000条数据里如果套话回复占比高，模型很容易学到“安全但废话”的模式。建议先抽查一下训练集的输出格式，看看具体诊断建议是不是被稀释了，或者数据里本来就混了不少类似“建议就医”的模板回复。另外LoRA的rank和alpha可以试试调小一点，有时候capacity太大会让模型倾向于记忆通用安全回复而不是领域细节。我之前做法律问答也踩过这个坑，后来把数据里模糊回答

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

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

这个思路我觉得可行，但别指望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那样，把老对话压缩成摘要，比单纯调推理参数省心