企业 AI 智能体：微调模型 vs RAG 何时使用哪种

「我们该用 RAG 还是微调？」是企业团队在构建 AI 智能体时最常问的问题。这个问法本身就把事情设成了非此即彼的二选一，而在绝大多数情况下，真正的答案是「两者都用，各自负责不同的部分」。

问题之所以反复出现，是因为两种方案在工作原理、成本结构和擅长的场景上确实截然不同。任何企业智能体部署都得把这些取舍想清楚，本地部署尤其如此：这里做的是基础设施决策，回头再改的代价远高于换一个 API 密钥。

本指南把两种方案正面对比，给出一套决策框架，并说明大多数生产级企业智能体实际采用的混合模式。

两种方案各自如何工作

检索增强生成（RAG）

RAG 在生成之前加入一个检索步骤。当用户向智能体发出查询时：

查询被嵌入为向量表示
在向量库中检索相似的文档块
取回相关性最高的前 k 个文档块
这些文档块与查询一起放进模型的上下文窗口
模型基于取回的内容生成回复

模型本身的权重不会因为这些企业数据而发生任何改变，数据是在推理的那一刻被临时取用的。知识存放在向量库里，而不在模型权重中。

优势：

适应快速变化的数据：更新向量库之后，下一次查询就会用上新信息
数据变动时无需重新训练模型
自带来源溯源：可以知道模型用了哪些文档
数据访问可以按查询逐次控制（按用户权限、部门、密级过滤）

劣势：

检索质量不稳定，取回无关的文档块就会得出错误答案
上下文窗口的容量有上限，限制了模型一次能纳入考虑的信息量
无法把领域内的规律内化下来，模型对每一次查询都是彼此独立地处理
切块带来的损伤：被切散到不同块里的信息可能无法完整还原
增加延迟：检索步骤耗时 5-50ms，具体取决于向量库规模和配置

微调

微调是用领域数据去训练模型，通过修改模型权重，把领域内的规律、术语和行为规则内化到模型里面。

准备训练数据，也就是能体现期望行为的输入/输出对
用这些数据训练模型（出于效率考虑通常用 LoRA 或 QLoRA）
模型权重被更新，以反映训练数据中的模式
推理时，模型直接从内部知识生成回复，无需检索

优势：

行为稳定：对相似的查询，模型每次的回应方式都一样
推理更快：省掉检索步骤，只剩生成
不依赖向量库，推理架构更简单
内化领域知识：术语、格式、推理路径都成为模型的一部分
更擅长遵守复杂的行为规则，例如语气、格式、判断标准

劣势：

不重新训练，知识就会过时（而一次重训要花数小时到数天）
没有内建的来源溯源，模型不会说明某个结论是从哪里学来的
需要准备训练数据，也就是能体现正确行为的标注样本
存在过拟合的风险：训练样本太少，或者训练轮数过多，都会让模型变得脆弱
想改掉单个事实也得重新训练一遍

决策框架

企业智能体什么时候该用 RAG、什么时候该用微调、什么时候两者都上？决策表如下：

判断维度	RAG	微调	两者结合
数据频繁变动（每周或更快）	首选	差：很快过时	RAG 管事实，微调管行为
输出格式必须一致	各次查询之间会飘	首选	微调管格式，RAG 管内容
需要来源引用	内建	原生不支持	由 RAG 提供引用
延迟敏感（<200ms）	增加检索延迟	首选	取决于架构
知识库较小（<1,000 篇文档）	简单，效果也好	只为记事实而微调属于杀鸡用牛刀	RAG 就够用
知识库庞大（10 万篇以上文档）	检索质量下降	塞不进训练数据	两者都需要
领域专用术语	能检索到，但可能用错	内化术语	微调管语言，RAG 管事实
行为一致性	随检索到的上下文波动	一致	微调管行为
敏感数据受限	可以排除在向量库之外	永久留在模型权重里	由 RAG 做受控访问
多步智能体工作流	可用但慢（每步都要检索）	工具调用快且稳定	微调管工具调用，RAG 管知识

RAG 更合适的场景

知识快速变化

如果底层信息每周或每月都在变，例如药品数据库、监管指引、价格信息、政策文件，那么 RAG 是唯一可行的路子。对更新得这么频繁的数据做微调，意味着要不停地重新训练，成本高昂，运维上也很复杂。

**示例：**一个把交易与现行监管指引逐条比对的合规智能体。法规每季度更新一次，RAG 取回的始终是当前版本；换成微调，就得每季度重训一轮。

需要来源溯源

在受监管行业，智能体的回答必须能追溯到具体的源文档。「政策规定 X（来源：员工手册 v3.2，第 4.1 节，2026 年 1 月更新）」经得起审计。一个微调模型给出的「政策规定 X」没有出处，审计时无从查证。

RAG 天生具备这个能力：检索步骤会记录用到了哪些文档，也可以要求模型把它们引用出来。

受访问控制的知识

如果不同用户应该看到不同的信息，例如按部门划分的政策、按角色开放的机密文档，RAG 可以在检索环节做过滤。向量库查询能带上元数据过滤条件，把检索范围限制在该用户有权访问的文档之内。

微调无法承担访问控制这件事，因为知识已经落在模型权重里，任何一个调用这个模型的用户都能拿到它。

微调更合适的场景

输出格式必须一致

如果智能体每次都必须按特定格式产出，例如 SOAP 病历、合同风险摘要、结构化事件报告，微调比 RAG 可靠。格式要求属于行为层面的问题，也就是模型该怎么写，而非它该用哪些信息。行为模式能被微调编码进权重，检索则只负责把内容送到模型面前。

**示例：**一个必须按院方特定模板产出 SOAP 病历的临床文书智能体。用 1,000 份格式正确的病历做微调，模型就学会了这套模板。RAG 也许能检索到范例病历，但模型的输出格式仍然会飘。

工具调用的可靠性

对企业智能体来说，工具调用是最核心的能力：智能体需要用正确的参数去调用正确的函数。用 500 个以上的工具调用样本做微调，模型就能掌握你自己的工具 schema、参数格式和判断逻辑。什么时候调哪个工具、传什么参数、边界情况怎么处理，都会被模型内化。

工具调用是一种行为模式，靠查资料学不会，所以 RAG 在这件事上很难稳定奏效。

方案	工具调用准确率（企业工具）
通用模型（无 RAG、无微调）	40-55%
上下文中带工具文档的 RAG	60-75%
用 200 个工具调用样本微调	80-88%
用 500 个以上工具调用样本微调	88-95%
微调 + RAG 提供动态参数	90-97%

领域术语与推理

如果智能体工作在法律、医疗、金融、工程这类专业领域，微调会把该领域的词汇、缩写、推理习惯和行业惯例一并内化。不必再向模型解释 NKDA 是什么，或者「重大不利影响」在法律上有特定含义，它在训练中就已经学会了。

RAG 能检索到含有领域术语的文档，但模型若没有在这些术语上训练过，仍然可能理解错或用错。

RAG 失效的场景

有一些企业场景，即便数据准备得很扎实，RAG 的表现依然很差：

跨多份文档的复杂综合

当一个答案需要综合 5-10 份不同文档里的信息、而每份文档只贡献整体图景的一角时，RAG 就开始吃力了。检索步骤取回的是一个个文档块，这些块彼此之间是什么关系，得靠模型自己拼出来。如果这层关系在取回的文本里体现得不明显，模型就可能拼错。

**示例：**尽职调查分析需要把财务报表里的一项负债、诉讼披露里的一桩未决诉讼，以及收购协议里相关的赔偿条款串到一起。三种文档类型，三个文档块，一份连贯的分析。RAG 负责把块取回来，能否正确串起来则看模型的发挥。

微调在这里帮得上忙，因为模型在训练时见过这类跨文档综合的样本，已经学到了其中的推理路径。

内化的判断力

有些企业任务所需要的判断力是查不到的，只能从长期的经验里慢慢长出来。一个看过 1,000 份合同的审阅者会形成直觉，知道哪些条款是常规的、哪些不寻常。这种直觉不写在任何文档里，它是长期接触之后沉淀下来的模式。

微调能把这种经验性判断编码进模型。RAG 在这里无从下手，因为世上并没有一份记载着这种判断力本身的文档可供检索。

临床推理链

在医疗领域，临床推理常常沿着很长的逻辑链展开：症状 → 鉴别诊断 → 检查 → 缩小鉴别范围 → 选择治疗方案。这条链要求医生始终把完整的推理背景放在脑中。为 RAG 把临床指南切块会打断这些推理链，模型取回的是一条条孤立的建议，缺少完整的逻辑上下文。

用完整的临床推理样本做微调，能把这些链条保留在模型权重里。

混合方案（大多数生产级智能体的实际做法）

最有效的企业智能体会把两种方案结合起来：

微调负责：

领域语言和术语
输出格式的一致性
工具调用行为
决策模式
行为规则（语气、风格、升级标准）

RAG 负责：

当前的事实信息
来源引用
受访问控制的知识
高频更新的数据
具体的政策和流程细节

混合方案如何运转

先用领域数据微调基础模型：工具调用样本、格式样本、行为样本
推理时，微调后的模型接收来自向量库的检索上下文
模型用内化的领域知识，正确理解这些检索到的内容
输出把学到的行为（格式、语气、工具调用）与当前事实（来自 RAG）结合起来

**示例：**一个法律合同审阅智能体：

用 500 份合同审阅样本微调 → 掌握了律所的风险标准、偏好的条款措辞和输出格式
在合同审阅手册和条款库上做 RAG → 取回具体的现行标准和已获批的替代方案
结果：格式统一、依据当前律所标准、并附有来源引用的分析

少了微调，模型可能检索到正确的手册章节却用得前后不一；少了 RAG，模型可能套用过时的手册标准。两者合在一起，才能产出可靠、及时、格式规范的输出。

两条路径各自的数据准备

两条路径都从同一批企业原始文档出发，分岔点出现在数据准备这一步。

RAG 数据准备流程

Raw Documents → Parse → Clean → Deduplicate → Chunk (semantic) → Add Metadata → Embed → Index in Vector Store

关键质量指标：

**检索准确率（hits@10）：**对一组测试查询，正确的源文档是否出现在前 10 条结果里？目标：85% 以上
**文档块相关性：**每个取回的块是否真的包含回答该查询所需的信息？目标：70% 以上
**去重率：**重复或近似重复的块被清掉了多少？目标：消除 95% 以上的重复内容

微调数据准备流程

Raw Documents → Parse → Clean → Select Training Examples → Label with Domain Experts → Format as Training Pairs → Validate → Train

关键质量指标：

**标注准确率：**抽查已标注样本，第二位审核者认可的比例是多少？目标：95% 以上
**覆盖度：**训练集是否覆盖了智能体将会遇到的各类场景？目标：覆盖 80% 以上的常见场景
**一致性：**对相似的输入，标注是否一致？目标：标注者之间达成 90% 以上的一致

共用的数据准备

两条路径在上游共享同一套准备工作：

步骤	目的	对 RAG 的影响	对微调的影响
文档解析	从源格式中抽取文本	有	有
文本清洗	去除样板内容，修复编码	有	有
去重	清掉冗余内容	有	有（避免在重复内容上训练）
PII/PHI 检测	识别敏感数据	有（脱敏或打标）	有（训练前脱敏）
元数据抽取	标注来源、日期、类型	有（支持过滤检索）	有（支持分层抽样）
质量评分	评估文本质量与完整性	有（剔除低质量的块）	有（剔除低质量的样本）

这套共用流程正是 Ertas Data Suite 这类工具价值最大的地方：同一套数据准备工作流，同时供给你的 RAG 知识库和微调数据集。

如何做决定

对大多数企业智能体部署来说，可以直接按「微调管行为，RAG 管知识」来落地。

如果只能先做一样：

先做 RAG：核心需求是回答关于企业文档的问题，而且数据变动频繁
先做微调：核心需求是可靠的工具调用和一致的输出格式
两者都规划：要构建的是员工每天都会用的生产级智能体

为本地部署所做的基础设施投入，对两种方案同样适用。无论走哪条路，模型都是在本地运行的。RAG 需要向量库，微调需要训练流水线，而数据准备流程同时供给两者。