RAG 还是微调？真实客户项目教会我们的选择之道

几乎每次企业 AI 相关的对话，都会在头一个小时内走到同一个岔路口。客户有一个在演示中表现出色的大语言模型，但它不了解客户的产品、政策，也不懂客户惯用的写作方式。会议室里有人会问：我们应该用自己的数据微调模型，还是围绕它构建检索增强生成（RAG）系统？

坦率地说，这个问题通常问得不对。RAG 和微调解决的是不同的问题。把两者当作相互竞争的选项，往往会让团队花上几个月时间、消耗大量 GPU 预算，最终却解决了错误的问题。以下是我们在实践中做出选择的方法，以及我们见过的成功与失败案例。

先弄清楚模型缺少什么

模型在业务任务中给出糟糕的答案时，通常是缺少两类信息之一。

它缺少知识。它不知道最新的价目表、2025 年供应商合同中的条款，也不知道上个月刚上市产品的故障排查步骤。这是事实层面的问题。

它缺少合适的行为方式。它掌握的信息足够多，却无法按照你的要求作答。它不遵循指定的输出格式，语气不对，误读内部代码，或者无法完成范围明确、需要反复执行的任务，例如将工单归入你的 40 个类别。这是技能层面的问题。

RAG 是解决第一个问题的工具，微调则是解决第二个问题的工具。我看到的大多数困惑，都源于试图用微调来教会模型事实。

为什么微调不是补充知识的好办法

人们很容易以为，只要用自己的文档训练模型，它就会“了解”这些文档。但在实践中，模型对文档风格的掌握远比对其中事实的掌握可靠。Microsoft 的研究人员针对知识密集型问题直接比较了这两种方法，发现RAG 的表现始终优于无监督微调，无论是模型训练时见过的事实，还是全新的事实，都是如此。

此外还有实际问题。事实会发生变化。每当政策或产品目录更新，经过微调的模型就会过时，直到再次训练才会更新。可追溯性也会丧失：微调模型给出某个数字时，你无法指出它来自哪份文档。对于保险和医疗保健领域受监管的客户而言，仅这一点通常就足以让讨论到此为止。

RAG 最早由 Lewis 等人在2020 年的论文中提出，它将知识保留在模型之外。用户提问时，系统会检索相关段落，并将其作为上下文传给模型。更新知识只需更新索引，无须重新训练模型。而且，每个答案都可以标注来源。

我们的一家物流客户就是个很好的例子。客户希望即时了解货物所在位置以及缺少哪些文件。这些信息每隔几分钟就会变化。无论怎样训练，都无法让模型始终掌握最新信息。因此，我们构建的助手会在用户提问时，从实时追踪数据和物联网数据中生成答案，而不是依赖记忆。检索是唯一可行的设计方案。

微调真正发挥作用的场景

微调并未过时，只是适用范围比人们预想的窄。以下三种情况，我们会考虑采用微调：

• 严格且重复的输出格式。如果模型每天必须数千次生成相同结构的输出，例如按照固定的 JSON 架构从发票中提取字段，那么微调后的小模型往往比通过提示词驱动的大模型更可靠，成本也低得多。
• 领域语言。有些领域使用的简写会被基础模型误读。物流状态代码、临床缩写和内部产品代码都是常见例子。适度微调就能解决这个问题。
• 大规模应用中的成本和延迟。任务明确后，微调后的小模型可以取代大型通用模型。LoRA 等方法让这一做法变得经济可行，因为训练时只需调整一小部分额外权重，而不是整个模型。

请注意，这些情况没有一种与事实有关。它们关注的是教会模型如何执行一项你已经充分了解的任务。

大多数 RAG 故障都出在检索环节

每当有团队告诉我“我们试过 RAG，但没效果”，问题通常不在模型，而在检索环节。模型的表现取决于提供给它的段落，最多只能和这些段落一样好。

以下改进虽然不花哨，却很有效：

• 按语义切分，而不是按字符数切分。每 500 个字符切分一次合同，会把条款从中间截断。按章节和标题切分，则能保留完整上下文。
• 为每个文本块补充上下文。如果不知道“上限为 30 天”适用于哪项政策，这个文本块就毫无用处。Anthropic 报告称，在建立索引前为每个文本块添加简短的文档上下文，也就是他们所说的上下文检索，可将检索失败率降低 49%；与重排序结合使用时，降幅可达 67%。
• 结合关键词搜索和向量搜索。向量搜索擅长理解语义，但不擅长处理零件编号等精确术语。混合搜索则能兼顾两者。
• 单独测试检索效果。整理一组真实问题及其已知正确的来源段落，并在评估最终答案之前，测量正确段落是否出现在排名靠前的结果中。

何时同时使用两者

在实际生产中，效果最好的系统往往会结合两者。RAG 提供事实信息，经过少量微调的模型则负责处理格式、语气和领域语言。研究也朝着同一方向发展：加州大学伯克利分校提出的 RAFT 方法会专门对模型进行微调，使其更善于利用检索到的文档，并忽略无关文档。

但先后顺序很重要。我们几乎总是先构建 RAG，衡量它的不足之处，然后才决定是否值得进行微调。如果一开始就微调，就意味着还不知道真正的差距在哪里，便先为训练付费。

简单决策清单

1. 这项任务是否依赖每季度变动不止一次的事实？使用 RAG。
2. 用户或审计人员是否需要知道答案的来源？使用 RAG。
3. 问题是否出在答案的格式、语气或用词，而非事实内容？考虑微调。
4. 这是否是一项范围较窄、运行量很大的任务，且成本或速度很重要？考虑微调较小的模型。
5. 你是否单独衡量过检索质量？如果没有，先做这件事，再进行其他工作。

要点

RAG 和微调并非相互竞争的方案。前者为模型提供正确信息，后者则塑造模型的行为。先弄清楚你实际面对的是什么问题，在责怪模型之前先改进检索；并且要等系统运行起来后，再考虑是否值得进行微调，而不要把它当作让系统运行起来的捷径。