一只小鹿偶尔重构日记

4-bit量化确实会掉点，尤其7B这个级别，指令遵循能力本来就比GPT差一截。我试过同样的模板，Qwen2.5得把步骤拆得特别细，最好给个例子让它照着抄，不然就容易跑偏。另外温度调低点（0.3左右）对写文案这种任务会稳很多，你可以试试。

几十条数据确实少了点，微调小模型做工具调用至少得几百条高质量样本，而且格式一定要严格统一，比如所有字段名、类型都得完全一致，不然模型很容易学歪。另外可以试试在训练时把system prompt里也固定写好参数格式，让模型每次都看到相同的约束。LoRA rank值也可以调大一点试试，我遇到过16比8效果明显更好。

你这个情况我也遇到过，特别是年份数字这种精确信息，纯向量检索确实容易跑偏。我自己试下来，觉得混合检索挺关键的，就是向量+关键词（比如用BM25）一起上，Milvus现在也支持这种混合模式，能明显提升对数字、年份这类硬匹配的召回。另外你提到query扩展，这个我试过，效果看场景，比如用LLM把“2023年营收”扩展成“2023年总收入、年度营收数据”再检索，能覆盖更多写法，但别扩得太宽，否则噪声也大

几百条对话就卡的话，大概率不是MCP的锅，而是你每次查询前全量向量化导致的——相当于每次对话都要重算一遍所有历史，当然越来越慢。试试把向量化放到写入阶段而不是查询阶段，入库时就存好向量，查询只用相似度搜索。关于遗忘逻辑，我习惯在工具里加个时间戳字段，按天或按会话数做滑动窗口删除，或者用LRU策略定期清理旧向量，比手动清空灵活很多。嵌入模型选all-MiniLM-L6-v2这类轻量的就行，太重反而拖

这个思路确实有意思，让模型自己当编排者而不是被编排，感觉比固定流程灵活多了。不过我有点担心，如果模型在运行时自己写的逻辑出了bug或者陷入死循环，这种“安全执行器”要怎么及时兜底？毕竟开放任务里不确定性太大了，光靠框架层限制可能不够。

隐私牌当噱头容易，但真要拿技术落地，得看推理速度和成本能不能打。