RAG vs 微调：企业聊天机器人该选哪个？

「能不能把我们的文档训练进 ChatGPT？」这是企业客户最常提出的需求之一。这个问题听起来合理，但它往往混淆了两种截然不同的技术路径。多数情况下，企业真正需要的不是「训练」，而是检索增强生成（RAG）。

本文用通俗的语言拆解两种方案的原理、适用场景与成本结构，并给出一个五问决策清单，帮你在把聊天机器人推向客户之前做出正确选择。

核心结论速览

• RAG 改变的是模型能看到什么，微调改变的是模型怎么表现。
• 如果机器人需要根据你的文档、政策或产品数据来回答，从 RAG 开始。
• 微调擅长风格、格式和狭窄的重复性任务，不擅长保持事实的时效性。
• 大多数生产级助手使用的是 RAG 加一份精心编写的系统提示词，真正需要微调的极少。
• 无论选哪条路，先建一套评测集——否则你无法判断方案是否有效。

一句话说清区别

大型语言模型已经掌握了大量世界知识，但对你的退款政策、价格表或上周的产品更新一无所知。弥补这个差距有两条路：

RAG 在用户提问的瞬间，从你自己的内容中检索相关段落，连同问题一起交给模型。模型基于「刚刚看到的内容」作答。

微调 则是在成百上千条示例对话上继续训练模型，让它学会一种模式：某种语气、某种格式、某种分类方式。

模型缺知识，用 RAG；模型缺行为，用微调。

RAG 的实际工作流程

1. 准备内容：文档、帮助中心文章、PDF 和数据库记录被切分成小段落（chunk）。
2. 建立索引：每个段落被转化为嵌入向量（embedding），存储到向量索引中。如果你已经在用 PostgreSQL，pgvector 扩展通常就够用了。
3. 检索：用户提问时，系统找出最相关的段落。将关键词搜索与向量搜索结合（混合搜索），效果通常优于单独使用任一种。
4. 生成：问题和检索到的段落一起送入模型，附带指令如「仅根据这些来源回答并引用出处」。
5. 引用：答案链接回它使用的段落，方便用户和团队核查。

当文档发生变化时，只需重新索引改动的文件，无需重新训练。这正是 RAG 适合每周甚至每天更新内容的原因。

嵌入向量（embedding） 是把一段文本映射成的一串数字（通常几百到上千维），语义相近的文本在向量空间中距离更近。检索时系统把用户问题也转成向量，再找出距离最近的若干段落。向量索引 则是为快速完成这种「最近邻搜索」而建立的数据结构，常见实现包括 HNSW、IVF 等，它们用近似算法在海量向量中做到毫秒级返回，代价是牺牲一点召回精度。混合搜索 指同时运行关键词检索（如 BM25）和向量检索，再把两路结果融合排序：关键词擅长命中专有名词、型号、编号，向量擅长理解同义改写和自然语言意图，两者互补能显著减少「明明有答案却检索不到」的情况。分块（chunk） 的大小和重叠策略也会直接影响检索质量，段落太大会稀释语义、太小则丢失上下文。

微调的实际工作方式

微调是在已有模型基础上，用你的示例继续训练：一个输入加一个理想输出，反复多次。模型会更好地、更一致地产生那类输出，且提示词可以更短。

它不擅长的是存储可信赖的事实。一个微调过的模型仍可能信心十足地说出旧价格，而每次事实变化，你都得重建训练数据并重新训练。这也是为什么 Anthropic 等厂商建议客户先做好提示工程和检索，再考虑微调；OpenAI 的官方指南同样推荐先尝试提示工程。各提供商的产品和价格变动频繁，做出承诺前请查阅其最新文档。

RAG 与微调全维度对比

维度	RAG	微调
最适合	基于自有、变化中的内容作答	统一语气、格式或狭窄任务
保持事实时效	重新索引改动的文档	用新示例重新训练
引用能力	天然支持：答案指向源段落	不内置
所需数据	现有文档	数百到数千条精选示例
首版上线时间	数天到数周	数周，主要在准备数据
主要持续成本	检索加每次回答更长的提示词	训练运行及每次训练后的评测
对错误答案的控制	强：限制回答仅来自检索源	较弱：事实存在模型内部
访问权限控制	过滤每个用户可检索的内容	困难：训练进去的内容都在模型里

提示工程 是在不改变模型权重的前提下，通过系统提示词、少样本示例、输出格式约束来引导模型行为的方法，成本最低、迭代最快，因此被各家厂商列为首选。系统提示词 是每次对话都置于最前面的隐藏指令，用来定义角色、语气、边界和「找不到就说不确定」等规则。相对地，微调 因为更新了模型权重，会带来两个隐性成本：一是需要为每个新版本重新跑评测，二是多个任务若共用同一模型可能互相干扰，实践中常需要为不同任务维护独立的适配器（如 LoRA），再按需加载。理解这条从「提示工程 → RAG → 微调」由轻到重的梯度，是判断投入顺序的关键。

五问决策清单

1. 答案是否依赖你文档或系统中的事实？→ RAG。
2. 这些事实是否每季度变动超过一次？→ RAG。
3. 用户是否需要看到答案来源？→ RAG。
4. 你是否已经尝试过清晰系统提示词加优质示例，并测量过仍然失败？→ 此时才考虑微调。
5. 任务是否狭窄且重复，比如把工单高频路由到二十个类别？→ 微调（或更小的微调模型）可能值得投入。

何时两者都需要

客服助手可能用 RAG 提供答案，用微调模型生成符合你品牌风格的回复。根据实际经验，一份强有力的系统提示词加几个示例就能解决大部分风格问题。从那里开始，只有在真实测试题上能证明存在差距时，才加入微调。

LoRA（低秩适配） 等参数高效微调方法只训练一小部分附加参数，显存占用和成本远低于全量微调，因此更适合中小企业按任务、按品牌分别训练小型适配器。它与 RAG 并不冲突：RAG 负责把正确的事实放进上下文，LoRA 负责让输出契合语气与格式。需要注意，适配器同样会「记住」训练数据中的内容，若训练样本里含敏感信息，仍存在泄露风险，因此权限敏感的字段不应进入微调数据集。

生产级聊天机器人的必备能力（演示版会跳过）

做一个 RAG 演示只要一个下午，但能面向客户的聊天机器人需要更多：

• 评测集：50 到 200 个带有已知优质答案的真实问题，每次改动后运行，以判断调整是改善还是恶化。
• 权限感知检索：如果员工无权打开某文档，助手也不能引用给它看。
• 内容新鲜度管线：新增和编辑的文档自动重新索引，删除的文档从索引中移除。
• 「我不知道」与人工转接：检索不到相关内容时，机器人应如实说明并提供人工入口，而不是猜测。
• 日志与反馈：对答案点赞或点踩，并有复盘差评的机制。
• 隐私规则：明确哪些个人数据可以发送给模型提供商，并核查其数据保留条款。

评测集 之所以先于技术选型，是因为它把「感觉回答变好了」变成可比较的数字。常见做法是准备 50–200 个有标准答案的真实问题，用「检索是否命中正确段落」和「最终答案是否正确」两个指标分别度量——前者定位检索问题，后者定位生成问题。权限感知检索 通常通过给每个分块打上访问控制标签，在检索阶段就按用户身份过滤，而不是先检索再屏蔽，避免模型在上下文里看到不该看的内容。内容新鲜度管线 则一般依赖增量索引：新增或修改的文档重新嵌入，删除的文档同步移出索引，否则助手会持续引用已作废的政策。

成本由什么驱动

具体价格因提供商而异且变化频繁，但成本驱动因素相对稳定：

成本驱动	RAG	微调
一次性投入	对内容做一次嵌入	准备数据并运行训练
每次回答	问题加检索段落的 token	问题的 token（提示词通常更短）
内容变化时	仅嵌入改动过的文档	重建示例并重新训练
工程投入	数据摄入、检索质量、评测	数据整理、训练、评测

对多数企业而言，最大的开支项是工程时间而非 API 账单。这也是从简单方案起步、持续测量的另一个理由。

常见问题

RAG 会把我的数据训练进模型吗？

不会。使用 RAG 时，你的文档存储在你自己的索引中，每次提问只发送相关段落。底层模型不会被重新训练。

AI 提供商会用我的数据训练模型吗？

包括 OpenAI 和 Anthropic 在内的主要 API 提供商声明，默认不会用企业 API 数据训练模型。消费者应用与 API 的条款不同且会变化，请阅读你所选提供商的最新数据使用政策。

我需要单独的向量数据库吗？

不一定。如果你已经在运行 PostgreSQL，pgvector 扩展能处理很多工作负载。专用向量数据库在极大规模或特殊搜索需求下才有必要。

RAG 聊天机器人能读取 PDF、Google Drive 或 Notion 吗？

可以。每个来源需要一个连接器来提取文本并保持索引更新。扫描版 PDF 需要先做文字识别（OCR）。

如何防止聊天机器人编造内容？

指示它仅根据检索来源回答、展示引用、在未找到相关内容时返回「我不知道」，并在每次发布前用评测集测试。