大模型落地的时候，企业内部讨论最多的一个问题就是：“我们是先把 RAG 这条链路吃透，还是直接花钱花人开始微调自己的模型？”我这两年接触过不少想落地大模型应用的团队，几乎每个项目启动会都会绕回到这个岔路口。今天这篇就围绕这个真实决策场景展开，讲清楚 RAG 和微调分别解决什么问题、各自的能力边界在哪、先做哪一个更稳，以及实操时的参数怎么定、坑怎么躲。
1. 先亮观点：这本质上是“知识路线”之争，不是技术噱头之争
1.1 企业在第一个岔路口最常犯的错
先给结论：如果你的目标是让业务系统尽快跑起来，先打通 RAG 的完整链路和评估闭环，再根据检索解决不了的那部分问题，决定要不要微调。这个顺序不是我拍脑袋定的，而是从投入产出比和调试难度两个维度对比出来的。
不少技术负责人一听到“私有化部署、领域定制”就直接想到微调，觉得不训一个自己的模型就不好意思跟领导汇报。结果呢，数据标注搞了三个月，训练完的模型上线后发现，新进来的线上文档它根本不知道，回答的知识仍然停留在训练截止时间，该胡说还是胡说。然后回过头来再补检索、再做向量库，等于把 RAG 的活重新干了一遍，时间和预算全花在试错上。
反过来，也有团队先上了 RAG，检索链路搭得粗糙，分块策略随意切，向量库干净度也没核查，最后出来的答案上下文混乱、引用错乱，就把 RAG 一棒子打死，觉得“还是微调靠谱”。其实这属于没吃到 RAG 的红利，就把工具给否了。两种极端我都见过，问题都出在没搞清楚工具对应的问题域。
1.2 RAG 和微调应对的是两种不同性质的“缺陷”
我们用最直白的方式区分：RAG 解决的是模型“不知道、没学过”的外部知识问题，微调解决的是模型“知道但做不到、做不好”的行为习惯问题。
举个例子，你的模型是基座模型或者通用对话模型，企业内部有一批最新的工艺规范文档，模型根本没见过这些内容，你问它“产线B的冷却温度上限是多少”，它只能靠通用知识瞎编。这时候你把文档切好、建好索引、检索到相关片段再让模型基于片段作答，问题立刻缓解。这就是 RAG 的典型价值，补知识。
但你如果发现模型回答问题时总是啰嗦一大堆、不按企业格式要求输出、或者对行业黑话理解得不够自然，比如把“打胶”理解成“涂抹胶水”而不是生产线语境下的“点胶工艺”，那 RAG 帮不了太多，这属于任务行为和表达习惯层面的问题，得靠微调去校准。
把这两类混在一起，团队就会在错误的环节做大量无效投入。判断标准一句话：只要答案里的信息是“存在但拿不到”，优先走 RAG；只要答案是“模型行为本身不符合预期”，才考虑微调。
2. 先吃透 RAG：全链路远不是“向量检索+生成”两个词那么简单
2.1 一条完整的 RAG 链路应该长什么样
很多人理解的 RAG 是：文档切块 → 向量化 → 存向量库 → 检索 top-k → 拼接给大模型。这个理解没错，但太粗。真正企业级的 RAG 链路至少包含七个环节：文档接入与清洗、分块策略、向量化模型选择、混合检索、重排、上下文组装、生成与引用校验。
哪个环节掉链子，最终答案质量都会打折。尤其是前三个环节，它们发生在“模型看到 prompt 之前”，很多人忽略它们的权重。
规范做法是先做文档清洗。我见过太多团队拿到 PDF 直接往上切，结果页眉页脚、表格错位、目录页全被切进去了，检索回来的片段里一半是噪音。清洗的目标是去掉无关元信息，还原正文结构，表格要转成带表头的文本描述。这一步没有现成的模型能帮你“理解”你的文档，得用正则规则加人工抽检结合。
接着是分块策略。这里有个经验值供参考：通用文本从 500-800 个字符切起，带重叠窗口 50-100 个字符；代码和技术手册可以按章节结构切；表格类内容最好整块保留，不要硬按字符切。字符数不是拍脑袋定的，它取决于你的向量模型最大输入长度和你业务问题的典型长度。比如你用的嵌入模型支持 512 token，那单块超过 512 token 就会被截断，后半段信息等于白存。换算一下字符数再定块大小，比照着网上的默认值抄靠谱得多。
2.2 决定检索质量的，往往不是模型，而是前处理
企业内部经常出现一种情况：换一个更大的向量模型，检索效果没提升多少，但把文档分块策略从“固定字符切”改成“按语义段落切”之后，命中率涨了十几个点。这是因为文档的语义完整性比向量模型的精度更影响召回。
我习惯把分块和检索评估绑定在一起做。先在测试集上跑一轮，统计命中率（hit rate）和前 10 条结果的 MRR。具体做法：准备 50-100 组问答对，每条问题都标注了标准答案所在的原文段落，然后分别用不同分块参数跑检索，看标准答案段落在检索结果前 10 中的出现比例。这个动作能非常直观地暴露分块问题。
再说混合检索。企业文档里的术语、编号、型号，用向量检索经常查不准，因为向量相似度擅长语义匹配，不擅长精确匹配。举个例子，用户问“型号 X7B 的维护周期”，如果你的文档里写的是“X7B 建议每 500 小时维护”，向量检索可能把“X7B”和“X7B Pro”混在一起。这时候加上 BM25 关键词检索，把精确匹配的权重拉起来，再做一个结果融合，效果会稳很多。RAG 项目走到后期，混合检索几乎成了标配。
重排（rerank）环节同样关键。初检索从向量库捞回 top 50，重排模型再精排到 top 5，最终生成时只拼接这 5 段。用 cross-encoder 类型的重排模型，比单纯依赖向量相似度排序，相关性准确率普遍能提升 10%-20%。代价是要多一次模型推理，但在企业场景下这个算力开销完全值得。
2.3 “吃透”到什么程度才算及格
按我自己的标准，一套 RAG 系统及格线有三条：
- 测试集命中率不低于 85%；
- 生成答案时能稳定引用到正确文档片段，而不是看着像那么回事但引文对不上；
- 针对同一个问题的多轮追问，答案不漂移、不前后矛盾。
这三条达不到，先别急着谈微调。因为如果检索都拿不回正确上下文，即使微调出再听话的模型，它也是在没有正确答案的原料上做发挥，属于巧妇难为无米之炊。
3. 什么时候该训自己的模型：微调的真实能力边界
3.1 微调能改变什么，不能改变什么
微调最核心的作用是“行为塑造”，不是“知识注入”。很多人有一个误区，认为微调就是把企业知识灌进模型参数里，训完模型就自带企业知识了。这个想法很危险，因为：第一，知识会过期，训进参数里的知识无法实时更新；第二，训练数据的知识密度如果不够，微调很容易过拟合到少量样本上，让模型背下个别答案而不是学会推理。
微调真正擅长的是这些事：统一输出格式和语气、让模型学会特定领域的表达习惯、把长文本回答压缩成结构化表格、让模型在给定上下文中“更听话”地遵守指令要求、修复某个高频出现的错误行为模式。比如模型总爱在回答末尾加一句免责声明，导致客服场景体验很差，微调 500 条样本往往就能纠正过来。
所以决策时问自己一个问题：如果我把一个完美检索到的上下文片段直接塞给未经微调的基座模型，它的输出结果是不是已经符合业务要求了？如果符合，那根本不需要微调，问题出在检索；如果上下文给齐了还是答得不像样，那才轮到微调上场。
3.2 企业微调最容易走偏的一步：训练数据
在企业微调项目里，训练数据的重要性超过模型大小、训练时长、参数设置。我观察到的普遍现象是，团队花了一周时间搭训练环境，然后花了三天随便攒了一批问答对丢进去训练，最后训出来的模型要么把训练数据里的错误知识当成真理，要么在无关问题上输出变得诡异。
推荐的做法是严格控制数据规模和构成。行为微调不需要海量数据，1000 条高质量样本就能看到明显变化，3000-5000 条足够覆盖大多数企业场景。关键不是数量，而是样本能不能覆盖你关心的“边界情形”。比如你要模型学会按三段式输出方案建议，样本里就必须包含客户提问的各种变体：直接问的、绕弯子的、带错别字的、上下文含糊的，这些边界比一百条一模一样的标准问答管用得多。
训练数据构造还有一个容易忽略的地方：每一条样本都要同时包含“输入”和“标准输出”，并且标准输出必须能回答输入中的问题。很多人做微调数据时只改语气不改内容，模型学到的是“换个说法”，而不是“按规范做”。数据做完了还要抽检，至少人工过一遍其中 20% 的样本，确认没有内容错误，否则错误会作为“知识”被模型记住，上线后非常难纠正。
3.3 LoRA 与全参微调取舍：参数与算力怎么定
预算有限的企业团队，我建议直接从 LoRA 开始。它只训练一小部分低秩矩阵参数，显存占用小、训练速度快，而且效果在大多数行为塑造场景下都不输全参微调。只有当你的任务是让模型进入一个完全不同的领域语言空间、需要大规模改变模型能力时，才考虑全参。
实操参数给个参考。我用 LoRA 微调 7B 级模型时，常用配置：秩 r=16，alpha=32，学习率 5e-5 到 1e-4，训练轮数 2-3 轮，batch size 视显存而定但建议总体样本除以步数的比例适中，避免大步数过拟合。
算力估算有个简单方法：一次完整训练需要的总样本量约等于训练轮数乘以样本数，大概在 5000 到 15000 条范围内。以 7B 模型为例，LoRA 训练一条 1024 token 的样本，单卡 A100 40G 大概需要 10-20 步每批次，总共跑完 2 个 epoch 约 5000 条数据，耗时大概在半天到一天半之间。如果只有消费级显卡，比如单张 4090，数据量控制在 2000 条以内，也能在两三天内完成一轮实验。这个量级的算力门槛远没有网上说的那么吓人，真正的成本在数据整理，在人力。
4. 决策框架：判断“先 RAG 后微调”的具体方法
4.1 先用业务问题分类表做初判
我做了一个比较实用的三分法，启动项目时直接把业务需求往里面套，基本几十分钟就能确定大方向：
| 业务表现 | 判断结论 | 优先动作 |
|---|---|---|
| 回答依赖最新/企业内部文档且答案常常编造 | 知识缺失 | 优先 RAG，不微调 |
| 内容基本正确但格式混乱、风格不对、不遵守指令 | 行为偏差 | 先 RAG 后视情况微调 |
| 知识全且行为好，但特定场景推理逻辑弱 | 能力不足 | 才考虑较大规模微调/继续训练 |
| 知识老但不便频繁更新，且需要保密不外传 | 混合型 | RAG 负责知识 + 微调负责行为 |
这个表的逻辑是：先把“不知道”和“做不到”分开，再按成本从低到高排优先级。RAG 的迭代成本显著低于微调，因为它不用重新训练，改改分块、换换检索参数就能看到效果变化。如果一开始就直奔微调，等于把低成本手段跳过，直接上重武器。
4.2 用可量化指标确定“吃透”的标准，而不是凭感觉
很多团队做 RAG 评估凭主观感觉，觉得“回答看起来还不错”就算过了。这在企业内部会埋雷，因为演示场景表现好和全量业务数据表现好，经常是两回事。
我的建议是搭一个最小评估集。从真实业务问题里采样 100 个问题，其中 30 个是高频热门问题、30 个是长尾冷门问题、20 个是带干扰项的问题（比如用户问法模糊、包含多个主体）、20 个是跨文档问题。针对每个问题，人工标注正确答案所在的文档片段。然后定义三个线上指标：
- 命中率：标准片段出现在检索结果中的比例，目标 85% 以上；
- 生成答案的引文命中率：生成内容引用的片段确实是答案依据的比例，目标 90% 以上；
- 格式合规率：输出格式符合业务模板的比例，目标 95% 以上。
这套评估跑完，你就能很清楚地说：RAG 链路已经达到业务基线，剩下不足的是模型行为问题，可以进入微调阶段了。
4.3 微调之后的模型如何与 RAG 协作，而不是互斥
即便决定微调，也不要把它当成替代 RAG 的方案。工程上更稳妥的架构是：检索仍由 RAG 链路负责，微调后的模型作为“生成器”被调用，两者分工。微调后的模型拿到检索回来的上下文片段，按照企业规定的语气和格式生成答案。这样既有新知识又有好行为，两边各干各擅长的事。
具体部署上还有一个细节：微调后的模型建议设置一个“权限边界”，即如果检索回来的上下文置信度低于某个阈值，就让模型明确回答“根据现有资料无法确认”，而不是强行编造。这个行为可以通过在微调数据里专门加一批“无答案样本”来训练，比如输入问题配一个不相关上下文片段，标准输出是“未找到相关资料”。别小看这个细节，它能显著降低企业场景下模型幻觉引发的事故概率。
5. 实操案例复盘：从 RAG 基线到微调校准的一次完整推进
5.1 模拟项目背景与第一轮动作
为了方便说明，我模拟一个典型项目：某制造类企业要让内部助手回答设备维修手册和工艺规范的问题。手册约 800 页，格式以 PDF 为主，包含大量表格和技术参数。业务方最初的诉求是“直接训练一个懂维修的模型”。
我介入后的第一件事是叫停微调，改成先搭 RAG。文档清洗阶段花了大约 3 个工作日，重点处理了表格转文本和图注清理。分块策略先按章节结构粗切，再对长章节按 600 字符重叠 80 字符二次切分。嵌入模型用的是开源的通用文本向量模型，向量库直接采用开源向量数据库组件，重排阶段加了一个 cross-encoder 模型。
第一轮跑完，测试集命中率只有 62%，MRR@10 大约 0.41。排查发现两个问题：一是表格转文本后，表头和表体分离，检索时经常只召回表体而丢失字段名，导致语义不完整；二是型号名称的精确匹配不够，用户问“X7B”的时候，检索回来的经常是“X7B+”。这两个问题都不是模型效果不够，全在预处理和检索策略层面。
针对第一个问题，我改了表格处理逻辑，把表头字段拼进每一行再存向量。针对第二个问题，我加了 BM25 混合检索并配置了精确匹配权重。第二次迭代后命中率拉到 84%，MRR@10 到 0.63，带上重排之后最终命中率稳定在 88%。生成的答案已经能做到“引用正确片段、内容基本准确”，但业务方反馈还是有问题：回答太啰嗦，一个简单问题经常输出五六行文字，客服场景根本没法用。
5.2 第二轮动作：带着明确的“行为缺陷清单”去微调
这个“太啰嗦、格式不对”正是典型的行为缺陷。我们已经通过 RAG 把知识问题解决得差不多了，剩下的问题清楚指向微调。
数据准备阶段从线上日志里采样了 1200 条真实问题，由两名懂业务的标注人员按统一模板写出标准答案，要求答案不得超过 80 字、必须包含结论、不能带免责声明。其中特意加入了 150 条“查无资料”的负样本和 80 条用户表述含混的难样本。训练采用 7B 级开源模型配 LoRA，r=16，alpha=32，学习率 8e-5，训练 3 个 epoch。单卡环境下跑了不到一天。
微调后的模型接入原有 RAG 链路实验，效果非常明显：格式合规率从 41% 升到 89%，平均回答长度从 180 字降到 75 字。更重要的是，由于训练数据里包含了“查无资料”的负样本，模型在遇到检索置信度不高的上下文时，更倾向于如实说“未找到相关资料”，而不是硬编答案。整体这一轮走下来，最大的体会是：微调不是为了回答得“更聪明”，而是为了回答得“更听话、更规范”。
6. 常见问题与排查心得：这些坑早踩早明白
6.1 检索命中率上不去的排查顺序
如果测试集命中率低于 80%，先别动模型。按这个顺序查：
- 原始文档清洗是否到位：页眉页脚、特殊符号、扫描件 OCR 错字，这些噪音对向量检索的干扰超乎想象；
- 分块大小是否适配向量模型：块太大截断丢信息，块太小语义不完整；
- 检索 Top-K 是否合理：K 从 5 调到 20 观察命中率变化，找到拐点；
- 是否做了混合检索：纯向量模式下型号、编号类精确匹配经常翻车；
- 重排模型是否引入：不重排的话，top 5 里可能混着两个不相关片段，稀释了生成质量。
这套顺序查完还不行，再怀疑向量模型选型。实测下来，通用向量模型在企业专业文档上差异没有想象中大，把前四个环节做好比换模型划算得多。
6.2 微调后模型“学坏”了怎么处理
微调后常见两个“学坏”方向：一是过度学习训练数据，模型开始反复输出某个固定答案，无论上下文怎么变；二是产生幻觉式自信，对没见过的问题也理直气壮编答案。
第一个问题，优先检查是不是训练轮数多了、数据里重复样本太多。把 epoch 降到 2，并且做数据去重，通常能缓解。第二个问题，靠负样本和“拒答样本”来修正。如果修正不了，还要检查是不是微调样本里混入了少量错误标注，这种错误数据会被模型强化记忆，等上线后变成高频错误来源。
6.3 成本账怎么算才不亏
最后算一笔实在的账。一套 RAG 链路的基础设施成本：向量数据库可以复用开源组件，嵌入和重排模型用开源权重，主要成本在开发人力和文档清洗，大致是一个工程师一到两周的工作量。微调的成本大头不在算力而在数据：1200 条高质量标注数据，两个标注人员约一周，算上训练和评估，整体大约三到四周的团队投入。
我个人的体会是，绝大多数企业场景并不需要从头训一个大模型，先吃透 RAG 能把 80% 以上的知识类问题解决掉，剩下的行为偏差用轻量级微调去校准。这条路省钱、省人、还容易扩展，后续知识更新只需维护文档索引，不用反复重新微调。如果你正在这个决策点徘徊，从 RAG 评估开始永远不会错，哪怕最后还是要微调，你也会比直接微调多出一套能衡量改进的基线。
