从资料到回答：理解 RAG 的完整流程

上一篇我们从一个最小 Agent 出发，认识了工具、检索和记忆。这次，我们聚焦其中的检索增强生成（Retrieval-Augmented Generation，RAG），从“什么时候需要它”开始，逐步看它怎样准备资料、检索内容、生成回答，并判断效果好不好。

本文参考 Microsoft Learn 的 RAG 基础概念单元整理。我们之前的 Java Demo 也会作为对照：它完成了文档切分和简单匹配，但还没有使用嵌入向量或向量索引。

什么时候会用到 RAG？

判断什么时候需要 RAG，可以先看大模型自身的三类限制：

• 知识边界：模型不会自动知道企业内部资料、私有文档或刚刚上传的文件。
• 知识时效性：模型训练时学到的信息可能已经过时，也不一定包含最新制度、产品变化或业务数据。
• 可验证性：模型可能给出听起来合理的回答，却没有可靠来源支持，用户也难以核对依据。

当问题受到这些限制影响时，就可以考虑使用 RAG：先从可信、已授权且尽量保持最新的资料中检索依据，再让模型根据这些内容回答。例如员工问“海外出差住酒店最多能报销多少？”，系统先查公司的差旅制度，并在回答中提供可核对的来源。

如果只是简单常识或计算，模型本身就能可靠回答，通常没必要额外检索。RAG 也会增加数据准备、检索、延迟和费用。

RAG 的整体框架：三个核心步骤

RAG 可以概括为三个连续步骤：先检索相关资料，再把资料加入提示词，最后让大模型依据上下文生成回答。

第一阶段：准备资料，建立索引

检索只能找到已经整理并放进搜索系统的资料。正式回答问题前，RAG 系统需要先构建索引。这个阶段通常在资料新增或更新时运行。

1. 选择并处理数据来源

资料可以来自产品手册、制度、网页、数据库或客服工单。系统要加载内容、提取文字和结构，并清理重复页眉、导航文字等无关内容。还可以补充标题、来源链接、类别、更新时间和访问权限等元数据，方便后续筛选、追溯和权限控制。

资料质量会影响后面的检索和回答：重复、过时或互相矛盾的内容会让结果变差；权限信息也要保留，确保用户只检索到自己有权查看的资料。

2. 把文档切分成片段

文档通常太长，不能每次都整篇交给模型，因此会切成较小的文本片段（chunks）。片段要有足够上下文，同时聚焦在一个主题上。太大片段会带入无关内容、占用更多上下文；太小则可能把标题、定义或条件拆散。相邻片段有时会少量重叠，避免重要信息刚好落在切分边界两侧。

例如，差旅制度可以按章节切成机票、酒店、餐饮和市内交通。用户问酒店额度时，系统只需检索酒店相关片段，不必把整份制度都交给模型。

3. 生成嵌入向量

嵌入模型把文本转换成一组数字向量，用来表示文本的语义。意思相近的文字，即使使用不同的词，向量通常也更接近。比如“酒店住宿标准”和“住一晚最多能报多少”，用词不同但语义相近。

建立索引时，用嵌入模型处理文档片段；用户提问时，通常还要用同一个嵌入模型处理问题，再比较向量。嵌入模型负责把内容变成便于比较的向量，生成式大模型则负责根据提供的内容组织回答。

4. 建立并维护索引

索引或向量数据库保存文本片段、对应向量和元数据，供后续搜索。索引可以支持关键词检索、向量检索或两者结合的混合检索。新增资料要加入，已修改的内容要更新，失效的内容要移除，所以数据准备不是一次性的任务。

换嵌入模型或向量维度后，通常要重新生成文档向量并重建索引，保证文档和用户问题仍能在同一种向量表示下比较。

第二阶段：检索资料，生成回答

当用户提问时，RAG 应用会在运行时执行一条链路：

检索：找出够用的证据

使用向量检索时，系统会用与建索引时同类的嵌入模型，把用户问题也转换成向量，再和文档片段的向量比较。比如“海外会议住酒店能报多少”可能匹配标题为“国际住宿费用”的条款，即使用词不完全相同。

检索可以通过元数据过滤、混合检索和重新排序来改善。混合检索同时利用关键词匹配与语义相似；重新排序会把更相关的候选片段排在前面；限制结果数量，则避免把弱相关或重复内容都塞进提示词。

系统要找的不是最多的内容，而是足以支撑答案的最少资料。实际中通常先取前 K 条，再通过测试调整 K 值和分数门槛；相关度分数只是参考，并不自动保证答案完整。

增强提示词：把依据交给模型

应用会把系统规则、用户问题和检索片段组合起来，并要求模型依据所给资料回答；如果资料里没有答案，要说明证据不足；如果有来源信息，则附上出处。

检索到的文档是待参考的数据，不是新的系统指令。文档里可能出现“忽略之前规则”等文字，应用应明确要求模型不要让资料内容覆盖系统规则。

生成：给出有依据、可核对的回答

模型根据增强后的提示词生成回答。应用最好同时展示来源标题、章节或链接，让用户核对答案依据。这样的回答称为有依据的回答（grounded response），但不代表绝对正确：检索结果可能不完整，模型也可能误解资料，资料本身还可能过时。

当没有足够证据时，系统应承认没找到，而不是猜测。在医疗、法律、财务等高影响场景，还需要人工复核。

第三阶段：评估 RAG 是否有效

RAG 是一条由检索和生成组成的流水线。回答听起来流畅，并不能证明整个系统工作良好。评估时要分开检查：检索是否找对资料，以及模型是否正确使用资料。

评估检索

• 相关性：检索片段是否在回答问题？
• 覆盖度：完整回答所需的信息是否都找到了？
• 排序：最有用的片段是否排在前面？
• 权限与时效：用户是否有权看这些资料？资料是否仍有效？

如果正确资料没有被检索到，单纯修改生成提示词通常解决不了问题。应检查资料质量、切分边界、元数据、查询处理方式、检索策略和排序。

评估生成

• 有依据：回答中的每个关键说法都能在资料中找到支持吗？
• 相关与完整：是否直接回答问题，并覆盖必要信息？
• 引用质量：引用的来源是否确实支持对应说法？
• 合理表达不确定性：资料不足时是否避免猜测？

自动系统怎样评估？

系统不会凭感觉知道答案好不好。通常需要先准备一组代表性测试问题，为每题标记正确来源片段和可接受答案，再自动记录检索结果和模型回答。规则检查适合金额、编号等明确字段；另一个模型也可以按标准评估回答是否有依据、是否完整。

例如问“海外住宿额度是多少”，如果测试集中标注的正确来源是《差旅制度》的“海外住宿”章节，就可以检查这段是否出现在前几条检索结果中。若检索正确、回答却把 500 元说成 800 元，问题可能出在生成；若正确条款没找到，则先排查检索。

“回答符合检索资料”不一定等于“事实正确”，因为来源自身也可能错或过期。高影响场景需要可信参照和人工抽查。

平衡质量、延迟与成本

检索并处理更多片段，可能提高信息覆盖度，但也会增加提示词长度、响应时间和费用。内容太多还可能让模型难以聚焦。因此要通过评估找到适合当前场景的检索数量、排序和提示词设置，而不是默认片段越多越好。

上线后持续观察用户哪些问题没答上、引用是否可靠、检索是否变慢，以及知识资料是否过期。资料、模型、提示词或检索参数变化后，都应重新评估。

回到我们的 Demo

之前的 Java Demo 从 HTML 中提取文本、切成片段，并用字符相似度为片段打分，再把匹配结果和问题一起发给模型。这展示了 RAG 的基本思路，但还没有使用嵌入模型或向量索引。

如果继续升级，可以先替换字符匹配：用嵌入模型分别处理文档片段和问题，再用向量相似度检索；随后添加来源元数据、混合检索、重排序和自动评估。每次升级都用同一组测试问题比较，才能知道改动是否真的有效。

参考资料

Microsoft Learn：Introduction to retrieval-augmented generation concepts

Microsoft Learn：RAG evaluation guidance