RAG 是什么？从检索增强生成到可靠 AI 应用
很多人第一次接触 RAG，会把它理解成“给大模型接一个向量数据库”。这个理解只说对了一部分。
RAG 的全名是 Retrieval-Augmented Generation，中文通常翻译为“检索增强生成”。它的核心思想很简单：模型回答问题之前，先从指定的外部资料中找到相关内容，再把这些内容放进上下文，最后根据资料生成答案。
所以，RAG 不是重新训练一个模型，而是给模型增加了一套可以检索、更新和审计的外部记忆。
为什么需要 RAG？
大语言模型的知识主要存在模型参数里。这种知识适合回答通用问题，但在以下场景会遇到限制：
- 企业内部的产品手册、合同、流程和数据库不在模型训练资料中。
- 公司的资料会持续更新，而重新训练模型成本高、周期长。
- 用户需要看到答案依据，不能只接受一个没有来源的结论。
- 某些内容涉及权限，客服或员工只能读取自己有权访问的资料。
- 模型可能会把“不知道”说成听起来很合理的答案，也就是常说的幻觉。
RAG 把“知识”和“推理”拆开。知识放在可以更新的资料库中，模型负责理解问题、组织证据和表达答案。资料更新后，通常只需要重新处理受影响的文件，不需要重新训练整个模型。
RAG 的基本工作流程
一个典型的 RAG 系统可以分成两个阶段。
第一阶段：建立知识索引
首先收集资料，例如 Markdown、PDF、网页、数据库记录、工单和 API 返回的数据。然后系统会：
- 清理格式、去除重复内容，并保留标题、来源、权限和更新时间等 metadata。
- 把长文档切成适合检索的小片段，这一步叫 chunking。
- 使用 embedding 模型把每个片段转换成向量。
- 把向量、原文片段和 metadata 写入向量数据库或搜索引擎。
切片不是越小越好，也不是越大越好。太小会失去上下文，太大则会让检索结果包含很多无关内容。比较可靠的做法是按照标题、段落和语义边界切分，并为片段保留文档名称、章节、版本和权限信息。
第二阶段：回答用户问题
用户提出问题后，系统会：
- 把问题转换成搜索查询。
- 在索引中找到最相关的若干片段。
- 必要时用关键词检索、向量检索或 reranker 重新排序。
- 检查权限，过滤用户不能读取的资料。
- 把问题、检索结果和回答规则一起放入 prompt。
- 让模型基于这些证据生成答案。
- 返回引用来源，或者在证据不足时明确说不知道。
可以把它简化成这个公式：
用户问题 + 相关资料 + 回答规则 → 模型答案
这里最关键的一点是：模型看到的资料必须真的相关、完整并且属于当前用户可以访问的范围。RAG 的质量上限，往往先由检索质量决定，再由模型的表达能力决定。
RAG、微调和长上下文有什么区别？
这三种方法经常被混在一起，但解决的问题不同。
RAG
RAG 适合知识经常变化、需要引用来源、需要控制权限的内容。它的优点是更新快、容易追溯，也可以让同一个模型服务不同知识库。
微调
微调更适合改变模型的行为、格式、语气或特定任务能力。例如让模型稳定地输出某种 JSON 格式，或者学习一个行业的分类方式。微调并不等于把所有最新业务资料安全地存进模型，而且模型学到的内容也不一定容易被逐条删除或引用。
长上下文
长上下文可以一次性把大量内容放进模型，但成本、延迟和噪声会随着输入增加。长上下文不是检索的替代品。对于大量文档，先找到真正相关的资料，再使用合适长度的上下文，通常更可控。
实际项目常常会组合使用：RAG 提供最新事实，微调改善输出行为，长上下文处理一个需要整体阅读的短资料集合。
什么决定 RAG 的实际效果？
1. 资料解析比向量数据库更重要
如果 PDF 的表格、标题、页码和图片文字在解析时丢失，后面的 embedding 再好也无法恢复。生产系统应该记录原始文件、解析结果、版本号和处理错误，方便重新索引。
2. 检索不应该只依赖一种方法
向量检索擅长找到语义相近的内容，关键词检索擅长处理产品编号、错误代码和专有名词。很多业务场景更适合混合检索，再通过 reranker 选择最终片段。
3. metadata 和权限必须参与检索
“找到相关资料”不代表“这个用户可以看到资料”。租户、部门、文档状态、有效期和访问权限应该在检索阶段过滤，而不是把所有结果交给模型后才补救。
4. Prompt 要求模型尊重证据
一个实用的规则是：只使用提供的资料回答；资料不足时说明不足；不要把推测写成事实；尽可能指出来源。这样不能保证模型永远正确，但能让错误更容易被发现。
5. 评估不能只看最终答案
RAG 至少要分别评估：
- Retrieval recall：正确资料有没有被检索出来。
- Ranking quality：最有用的片段是否排在前面。
- Answer faithfulness：答案是否真的由资料支持。
- Citation accuracy：引用是否对应答案中的事实。
- Latency and cost：检索与生成是否满足业务要求。
- Permission safety：是否可能泄露其他用户或租户的资料。
如果答案错了，必须知道是“没有找到资料”“找到了错误资料”“模型误读资料”，还是“权限过滤失效”。只看一个总分，很难定位问题。
RAG 与 AI Agent、MCP 的关系
RAG 通常负责“找知识”，AI Agent 负责“决定下一步做什么”。
例如，一个企业 Agent 可能先通过 RAG 查找采购政策，再通过 MCP 工具查询订单状态，最后根据权限调用审批或通知工具。这里的知识检索、实时数据查询和实际操作应该分开设计：
- RAG：读取经过索引的文档和知识库。
- MCP 工具：访问实时系统或执行有副作用的操作。
- Agent：根据任务规划步骤，并决定何时调用哪一个能力。
- Harness：提供权限、超时、日志、重试和人工接管机制。
不要把所有东西都塞进一个大 prompt。清晰的工具边界和可观察的中间结果，通常比“让模型自己想办法”更可靠。
常见误区
第一，认为接入向量数据库就自动拥有高质量 RAG。实际上，资料解析、切片、metadata、权限和评估都可能成为瓶颈。
第二，认为 RAG 可以消除所有幻觉。RAG 能提供证据，但模型仍可能忽略证据、错误总结或把多个版本混在一起。
第三，忽略资料版本。旧版政策和新版政策同时被检索出来时，模型可能给出矛盾答案。应该保留版本、发布日期和生效状态，并在检索时明确过滤。
第四，把用户输入直接当成可信指令。文档本身也可能包含 prompt injection。系统应该把检索内容视为“待分析资料”，而不是可以覆盖系统规则的命令。
第五，没有设计“找不到答案”的路径。高质量系统应该允许回答“目前资料不足”，并告诉用户需要补充什么，而不是为了显得聪明而猜测。
一个可靠 RAG 项目的检查清单
开始开发前，可以先确认：
- 资料来源、负责人、更新频率和权限边界是否明确。
- 文档解析是否保留标题、表格、页码、版本和来源。
- chunking 是否符合内容结构，而不是机械按字符截断。
- 是否同时考虑关键词检索和语义检索。
- 是否在检索前后都做权限和租户隔离。
- 是否记录 query、检索片段、模型答案和引用，保护好敏感信息。
- 是否准备了真实问题集，分别测试检索、答案、引用和延迟。
- 是否有资料过期、索引失败、模型超时和人工接管的处理流程。
总结
RAG 可以理解成一条连接“外部知识”和“大模型表达能力”的工程管道。它的价值不在于把一个数据库接到模型旁边，而在于让系统能够用正确的资料、在正确的权限范围内、以可追溯的方式回答问题。
如果只是做一个简单 Demo，向量检索可能已经足够。但如果要把 RAG 用到企业知识库、客服、ERP 或 AI Agent，就必须把资料生命周期、混合检索、权限控制、评估、成本和故障恢复一起设计。
最后记住一句话：模型负责生成答案，检索系统负责提供证据，工程系统负责保证这两件事安全、可验证、可恢复。