知识库用微调还是RAG？5个判断维度

很多团队搭企业知识库时，第一反应是「把资料喂给模型微调一下」。跑完一轮才发现：模型对答如流，却会一本正经地编出早已废止的条款。这不是模型不行，是路线选错了。

先分清：你要的是「知识」还是「行为」

微调改变的是模型的行为模式——说话风格、输出格式、领域术语的使用习惯、任务的拆解方式。它很难可靠地「记住」具体事实，而且事实一更新就得重训。

RAG（检索增强生成）解决的是知识供给——把最新文档检索出来放进上下文，模型只负责组织语言。知识更新变成改文档，而不是改模型。

一句话：事实归 RAG，风格归微调。

5 个判断维度

1. 知识更新频率：政策、价格、产品参数经常变 → RAG。术语规范、写作风格几年不变 → 可考虑微调。

1. 是否需要引用来源：法务、医疗、客服场景要求回答能指到「哪份文件的第几条」→ RAG 天然带出处，微调几乎做不到可追溯。

1. 数据与标注成本：RAG 的前期成本在文档清洗与切分；微调需要成百上千条高质量问答对，标注往往比训练更贵、更慢。

1. 任务形态：开放问答 → RAG；固定格式抽取、分类、改写、语气统一 → 微调收益明显。

1. 维护能力：RAG 要有人持续管切分策略、索引和重排；微调要有人管数据版本与回归测试。谁长期在线，谁才有资格上线。

一条决策路径

• 知识会变、要溯源 → 先做 RAG，别犹豫。

• 答案对但「味道不对」（太啰嗦、格式乱、术语不专业）→ 先改提示词，再考虑微调。

• 检索总是搜不到 → 问题出在切分和 embedding，不在模型，别急着微调。

• 任务高度固定、输入输出格式稳定、调用量大 → 微调小模型性价比最高。

• 两者都想要 → 走混合：RAG 管事实，微调管行为。

混合方案：微调只做三件事

如果最终走混合路线，微调模型不需要「懂业务」，它只需要在三个环节发力：

1. 查询改写：把「上个月那个退款的事」改写成检索友好的查询词。

1. 重排：对召回的 20 条片段做相关性排序，把最该看的 5 条挑出来。

1. 输出约束：强制按固定结构回答、标注引用编号、在没有依据时明确说「未找到」。

这三件事的共同点是：任务边界清晰、容易造训练数据、效果能用指标衡量。相比让模型背下整本手册，难度低一个量级，收益却直接体现在最终答案质量上。

落地四步，先建评估集

第一步：建一份 50～100 条的真实问题集。 从客服工单、群聊记录里捞，每条配标准答案和应引用的文档出处。这份评估集是你后面所有决策的裁判，没有它，任何方案对比都是感觉。

第二步：跑通基线 RAG。 用现成的向量库加基础切分先跑一遍，记录准确率、引用正确率、拒答率三个数。

第三步：定位瓶颈。 把失败样本分三类——检索没召回、召回但答错、答对但格式差。前两类改切分和重排，第三类才是微调的战场。

第四步：只在第三类上做微调。 用 LoRA 起步，拿评估集做回归，确认没有把原来的能力带崩再上线。

写在最后

选型的关键不在于哪个技术更高级，而在于你清楚自己要解决的是「模型不知道」还是「模型不会说」。前者用检索，后者用微调。把这两个问题混在一起讨论，团队会在几周内同时做两件做不好的事。