微调 vs. RAG 知识注入：工程师经常搞错的决策框架

一家金融科技团队花了三个月时间，根据其内部合规文档（数千份监管 PDF、政策更新和程序指南）对模型进行了微调。结果差强人意。模型仍然会对具体的规则编号产生幻觉。它忘记了最近的政策变化。而唯一真正重要的指标（即顾问是否足够信任它的答案从而停止反复核对）几乎没有变化。两周后，另一个团队在同样的文档语料库上构建了一个 RAG 流水线。顾问们在一周内就开始信任它了。

微调团队并没有犯技术错误。他们犯了一个定义性错误：他们试图用一种行为修改工具来解决知识检索问题。

这种困惑无处不在。当团队希望模型“了解更多”时，他们会选择微调；当他们希望“更准确的答案”时，他们会选择 RAG。但实际的区别更为深远，搞错这一点会导致双方在工程时间上浪费数月。

参数化 vs. 检索：这些工具解决不同的问题

微调修改了模型的权重——即在训练期间固化在神经网络中的参数化记忆。当你进行微调时，你并不是在教模型去查阅资料；你是在重塑其内部表示，从而使其表现出不同的行为。这意味着它学习了词汇、推理模式、输出格式和领域术语。它并不能像数据库存储记录那样可靠地学习单个事实。

RAG 将知识保持在外部。文档存储在向量数据库或搜索索引中；模型在查询时检索相关内容，并根据读取的内容综合出答案。模型的权重保持不变。所有“新知识”都存在于模型之外，无需触及训练流水线即可检索和更新。

这种区别驱动了所有的下游权衡。微调在改变模型的推理和沟通方式方面非常出色。RAG 在让模型准确访问其未经训练的特定信息方面非常出色。

大多数团队犯的错误是将“模型不了解我们的文档”（检索问题）与“模型在我们的领域表现不正确”（行为问题）混为一谈。这些问题需要不同的解决方案。

为什么微调在文档记忆方面会失败

如果你希望模型能够回想起大量语料库中的特定事实——合同条款编号、API 参数名称、确切的政策阈值——微调会让你失望。原因有以下几点。

首先，事实在神经网络中的存储方式与在数据库中的存储方式不同。模型并不维护一个查找表；它压缩统计模式。对 10,000 份 PDF 进行微调并不会让它拥有 10,000 份可检索的文档——它只会赋予它在 Token 序列上的偏移概率分布。特定的事实要么被不可靠地编码，要么根本没有被编码，而基础模型产生看似合理的幻觉细节的倾向却保持不变。

其次，微调在处理稀有或长尾知识方面表现极差。比较这两种方法在不太常见的事实知识上的研究表明，在事实很少出现在训练数据中的情况下，RAG 的表现远超微调。信息越晦涩，微调失败的可能性就越大——而这恰恰是知识注入最重要的地方。

第三，微调后的模型会立即过时。每次文档更新时，你要么重新训练（昂贵且缓慢），要么接受模型只了解昨天的规则。对于任何更新频率较高的内容——定价、政策、法律文本、产品规格——微调都会产生 RAG 所没有的新鲜度问题。

实践总结：如果你的问题是“模型不了解我们的文档”，请使用 RAG。如果你的问题是“即使有了正确的信息，模型的行为也不正确”，那才是微调的候选方案。

微调在什么时候真正胜出

微调在特定的、定义明确的场景中体现了其价值。

RAG 无法满足的延迟要求。 一个典型的 RAG 流水线在每次查询时会增加 200–500 毫秒：嵌入生成、向量搜索、上下文组装，然后是推理。微调消除了所有这些步骤——只需要通过一个已经了解该领域的模型进行一次前向传播。如果你正在构建语音 AI、实时代码补全或任何对 100 毫秒以下延迟有要求的交互式产品，RAG 的检索开销就会成为一个真正的限制。对于没有数据库可供查询的边缘部署，微调也是正确的选择。

检索开销累积的高流量系统。 在每月 1 亿次查询的情况下，向量搜索、嵌入 API 调用以及来自检索上下文的额外 Token 的单次请求成本会不断累积。无论流量大小，微调模型的推理成本都是固定的。如果你计算了每次查询的成本，并且检索开销在你的推理预算中占很大比例，那么微调的前期成本是可以很好地摊销的。

一致的输出格式强制执行。 微调在训练模型始终发出结构化输出方面非常可靠——例如特定的 JSON Schema、固定的引用样式、领域专用的文本模式。RAG 可以在提示词中注入少样本示例来引导格式，但微调直接将行为编码到模型中。对于医疗编码、结构化报告生成或任何必须符合严格规范的输出任务，微调比单纯的提示词工程能产生更一致的结果。

领域词汇和推理模式。 当你的领域需要专门的术语、推理模式或基础模型系统性出错的推理风格时，微调能以提示词无法实现的方式重塑模型行为。法律推理、科学计数法、财务建模惯例——这些都是受益于权重更新的行为转变，而不是文档注入。

共同点是：当问题在于模型如何思考，而不是它知道什么时，微调就会胜出。

为什么两者结合很少产生叠加效应

直觉上的做法是两者兼顾：先在领域数据上进行微调，然后部署在 RAG 架构中。在实践中，这确实有效，但收益通常不像团队预期的那样具有叠加性。

一项针对农业领域问答的研究发现，仅靠微调准确率提升了约 6 个百分点，仅靠 RAG 提升了约 5 个百分点，而将两者结合（RAFT —— 检索增强微调）累计提升了约 11 个百分点。这看起来是叠加的。但看看这种混合模式到底做了什么：微调教会了模型领域词汇和推理模式；RAG 提供了即时事实。这两者的贡献没有重叠 —— 它们解决了不同的缺陷。如果团队试图用这两者来修复同一个缺陷（例如，同时使用微调和 RAG 都希望提高事实准确性），通常只能看到 RAG 带来的改进，而看不到微调部分的改进，因为微调最初就不是为了解决事实准确性问题。

此外还存在干扰风险。如果你的微调模型从一个文档库中学到了某些行为，而你的 RAG 流水线又从该文档库的更新版本中检索内容，模型内置的假设可能会与它在推理时读到的内容发生冲突。模型可能会自信地合成旧的微调模式，而不是遵从检索到的文本，尤其是在冲突比较微妙的情况下。

还有运维开销的争论。运行 RAG 的微调模型需要同时维护训练流水线、模型版本控制和检索基础设施。协作成本是真实存在的。如果团队在没有明确理由的情况下将两者结合，最终会导致复杂度最大化，并且在出现性能下降时权责不明。

这种混合模式的高效版本应该是：针对行为和推理风格进行微调，将 RAG 用于事实基础和时效性。保持这些角色的独立性。不要为了解决同一个问题而同时应用这两种工具，并寄希望于它们能产生叠加效应。

决定路径选择的三个信号

在开始任何一项之前，请按顺序检查这三个信号。

信号 1：数据更新频率。 你的知识多久更新一次？如果答案是每天或每周 —— 比如定价、新闻、政策更新、产品目录 —— RAG 是必选项。在频繁更改的数据上微调模型是“自讨苦吃”：你的模型还没发布就已经过时了。如果你的核心知识在数年内保持稳定（基础领域推理、专业的职业判断），微调才值得探索。

信号 2：你到底想解决什么问题？ 通过你当前的模型运行三到五个真实的失败案例。对于每个失败，问自己：如果现在将相关文档注入提示词，模型能正确回答吗？如果可以，那么你面临的是检索问题 —— RAG 会有帮助。如果即使面前有相关上下文，模型仍然回答错误，那么你面临的是行为问题 —— 这是微调的候选场景。许多团队发现 80% 的失败案例是检索失败，剩下的 20% 是行为问题。这种划分会告诉你应该在哪里投入。

信号 3：延迟和流量需求。 你的 p95 延迟预算是多少？你的成本预测在当前流量 10 倍的情况下是否依然成立？如果你的产品要求亚秒级（低于 100ms）响应，或者你的单次查询成本在大规模下难以为继，RAG 的检索开销就会成为一个硬性约束。微调通常是实时应用的唯一路径。如果你的延迟目标是以秒为单位，且流量适中，RAG 通常是风险较低的切入点。

如何进行客观的基准测试

最常见的基准测试错误是使用同一个文档库中提取的静态测试集来评估这两种方法。这会系统性地高估微调的性能（因为模型是在这些文档上训练的），并低估 RAG 的性能（因为在干净的基准测试集上的检索质量比在杂乱的生产查询中要好）。

客观的基准测试需要三点：

• 使用生产级查询，而不是你在构建系统时编写的查询。真实用户的问题通常描述不充分，包含错别字，使用非规范术语，并且会以你意想不到的方式组合出现。如果有实际流量，请从中采样；如果没有，请通过红队演练生成对抗性查询。

• 在留存文档上进行测量 —— 即在评估期间既不出现在微调语料库中，也不出现在检索索引中的文本。这测试了模型是能够泛化还是仅仅记住了内容。

• 针对你实际的失败模式进行比较，而不是总体的准确率。如果你的问题是针对稀有实体的事实召回，那就专门测量这一点。如果你的问题是输出格式合规性，那就测试这一点。总体的基准测试分数会掩盖这两种方法产生分歧的地方。

一个有用的启发式法则是：如果你在生产环境中前 90% 的查询是普通用户利用公开信息就能回答的，那么 RAG 可能会表现良好。如果你前 90% 的查询需要综合处理任何检索文档中都未涵盖的领域专长，那么微调更为合适。

默认的起点

对于大多数面临知识注入问题的团队来说，RAG 是正确的第一步。它的设置成本更低，迭代周期更快（添加文档后立即测试），知识保持新鲜，且故障模式更具可解释性 —— 你可以检查检索到了什么，以及模型为什么以那种方式回答。当 RAG 表现不佳时，其中的差距通常清晰地指向了要么需要更好的检索，要么是真正的行为缺陷。

微调是在已经运作良好的基础上的乘法器，而不是跳过 RAG 的捷径。在进行全量微调之前，先从 LoRA 或 QLoRA 等 PEFT 方法开始；如果问题在使用参数高效方法后仍未改善，那么全量微调几乎永远无法解决它。当你进行微调时，要明确你正在编码的行为改变是什么 —— 不是“更多领域知识”，而是“一致的输出格式”或“适合我们领域的推理风格”。

做对这件事的团队并不一定在技术上更先进。他们只是在选择工具之前，愿意花 30 分钟诊断实际故障模式的人。