从一份文档到一个回答——RAG到底经历了什么

从一份文档到一个回答：RAG 到底经历了什么？

第一次接触 RAG 时，我看过不少介绍。有些文章上来就是向量、召回率和重排序，细节很多，却很难先建立整体认识；另一些文章只用一句"给大模型外挂一个知识库"带过，听懂了比喻，却仍然不知道一份文档最后是怎样变成答案的。

如果把文档解析、切片、向量化、检索、重排序和评估全部展开，每一部分都足以单独写一篇文章。所以这一篇先不钻进工程实现，而是回答一个更基础的问题：当用户提出问题后，RAG 到底经历了什么？

这也是我学习 RAG 后，对整个流程的一次重新梳理。文章的结构参考了 Datawhale 的 All-in-RAG 项目，但不会逐个罗列工具，而是尝试用一条完整链路，把各个模块为什么存在讲清楚。

先从一个大模型不知道的问题说起

假设一家公司的内部手册里写着：

X2 型设备长按右侧圆形按钮三秒后，会进入手动调节模式。

现在员工问大模型："X2 型设备怎么进入手动调节模式？"

一个通用大模型大概率不知道答案。原因并不复杂：这可能是一款内部产品，相关资料从未进入它的训练数据；即使进入过，说明书也可能已经更新。模型不知道并不可怕，真正麻烦的是它有时会根据语言规律，生成一个听起来很像答案的答案。

这便是 RAG 想解决的问题之一。

RAG 的全称是 Retrieval-Augmented Generation，检索增强生成。它的基本思路是：在大模型回答之前，先从外部知识库里找到与问题相关的资料，再把这些资料连同问题一起交给模型，让模型依据证据组织答案。

如果用一句大白话来解释，RAG 很像一场开卷考试：

大模型负责理解题目、阅读材料和组织语言；
检索系统负责从一堆资料中翻到正确的那几页；
知识库负责保存可供查阅的材料。

所以，RAG 并不是让模型凭空"学会"了新知识，而是让它在回答当前问题时，能够临时查阅相关证据。

这也决定了 RAG 特别适合知识经常更新、内容属于企业内部，或者回答需要给出出处的场景。提示词可以约束模型怎样回答，却无法凭空补充提示词里没有的事实；微调更擅长调整模型的行为、风格和特定任务能力，也通常不被当作一个可以随时更新的知识库。实际项目中三者可以配合使用，不能简单地说哪一种永远成本最低、效果最好。

同时需要提前说明：RAG 能降低一部分由知识缺失造成的错误，但不能消灭幻觉。资料可能没有被正确解析，相关片段可能没有被检索出来，模型也可能曲解已经找到的证据。RAG 的价值，是把"完全依赖模型记忆"改造成一条可以检查、评估和优化的证据链。

一条完整的 RAG 链路

从整体上看，RAG 可以分成两条链路：一条负责提前准备知识，另一条负责在用户提问时查找并使用知识。

这里所说的"离线"并不代表数据永远不变，而是这些工作通常不在一次用户请求的实时链路中完成。新增文档、文档更新或模型更换后，系统仍然可以定期或增量地重新处理数据。

下面沿着这张图，看一份文档是怎样一步步走向最终答案的。

第一站：把文档变成可处理的内容

真实世界里的资料很少整整齐齐地躺在纯文本文件中。它们可能是 PDF、Word、Markdown、网页，也可能包含表格、图片、页眉页脚和多级标题。

因此，第一步不是立刻切片，而是先解析文档。MinerU、PyMuPDF4LLM 等工具可以帮助提取不同格式中的内容。这里更准确的说法是"文档解析或内容提取工具"，而不是把它们笼统地称为向量数据库或 RAG 系统本身。

解析的目标也不只是得到一大段纯文本。一个更有用的中间结果，通常还要尽量保留：

标题与章节层级；
页码、文件名、作者和更新时间；
表格的行列关系；
图片、图注与正文的对应关系；
内容在原文中的位置。

这些信息一般作为元数据跟随文本块保存。它们不一定全部交给大模型，却可以用于过滤检索结果、展示引用和追溯原文。

例如，手册中的那句话可能被整理成这样的结构：

text 复制代码

正文：长按右侧圆形按钮三秒后，设备进入手动调节模式。
产品：X2
章节：3.2 操作模式
页码：第 12 页
版本：2026.08

到这里，我们只是把资料整理成了系统能继续加工的形态，还没有真正开始检索。

第二站：为什么不能把整本书直接塞进去？

假如把一本几百页的手册完整交给大模型，不仅上下文会很长、成本会增加，真正有用的信息也容易被大量无关内容淹没。因此，文档通常会被拆成更小的检索单元，这一步叫作 Chunking，也就是文本分块或切片。

常见策略包括：

分块策略	基本做法	更适合的情况
固定长度分块	按字符数或 Token 数切分，并保留一定重叠	快速建立基线，文本结构不明显
递归字符分块	优先按段落、句子等边界逐层切分	普通长文本，希望尽量保持语句完整
文档结构分块	按标题、章节、条款或表格切分	Markdown、说明书、规章制度等结构清晰的资料
语义分块	根据相邻内容的语义变化决定边界	主题转换明显，且能够接受更高处理成本

切片并不是越小越精确，也不是越大信息越完整就越好。

片段太小，可能把问题和答案拆开。例如"长按按钮三秒"留在一个块里，"进入手动调节模式"却落在下一个块里；片段太大，又会混入大量无关信息，影响检索和生成。重叠区域可以缓解边界截断，但重叠过多也会带来重复召回和存储浪费。

所以分块策略没有一个适用于所有文档的标准答案。它至少要同时考虑文档结构、用户问题的粒度，以及后续模型一次能够有效阅读多少上下文。

第三站：让"意思相近"变得可以计算

切片完成后，系统需要判断哪些文本块和用户问题更相关。关键词匹配可以找到相同词语，但用户的说法不一定和原文完全一致。

例如原文写的是"进入手动调节模式"，用户可能问"怎样自己控制设备"。两句话用词不同，意思却相近。为了比较这种语义关系，可以使用 Embedding 模型，把文本映射为一串数值，也就是稠密向量。

Embedding 并不只是把文本变成"计算机能读的格式"。更准确地说，它把文本中的语义信息映射到一个向量空间，使系统能够用距离或相似度比较两段内容。一般情况下，语义越接近，向量也越接近。

文档块入库时使用什么 Embedding 模型，查询时就要使用相同或兼容的模型配置，包括模型版本、向量维度和文本预处理方式。否则，两边产生的向量不在同一套坐标体系中，也就失去了直接比较的意义。

向量生成后，还需要建立索引并保存文本、向量和元数据。常见选择包括 Milvus、Chroma，以及 PostgreSQL 配合 pgvector。FAISS 也经常出现，但它更准确的定位是向量相似度搜索与索引库，并不等同于一套完整的生产数据库。

选择哪一种工具，不能只看文档数量。还要考虑数据是否需要持久化、是否有复杂的元数据过滤、并发量有多大、如何备份，以及团队是否能够维护它。学习或验证想法时，本地轻量方案往往已经够用；系统规模扩大后，再根据实际瓶颈升级即可。

至此，知识准备完成了。原始文档已经变成许多带有来源信息、能够被搜索的文本块。

第四站：问题进来以后，系统怎样找到证据？

当用户问"X2 型设备怎么进入手动调节模式"时，在线链路开始运行。

系统可以直接检索原问题，也可以先做查询处理。例如，补全被省略的对象、把口语改写得更明确，或者把一个复杂问题拆成几个子问题。HyDE 也是一种查询增强方法：先生成一段假设性答案，再用它帮助检索相关文档。

这些方法都是可选的优化手段。简单清晰的问题不一定需要改写，错误的改写反而可能带偏原意。

接下来，系统开始召回候选文本。常见方式有三种：

稠密向量检索：擅长发现语义相近、用词不同的内容；
关键词检索：擅长匹配产品编号、人名、术语和精确字符串；
混合检索：结合两者的结果，兼顾语义和精确匹配。

这里常见的 Top-K，表示从检索结果中取相关度最高的 K 个候选片段。它是一个检索参数，并不是系统新生成的一类数据。K 太小可能漏掉证据，K 太大则可能把噪声一起交给模型。

第一轮召回通常强调"别漏掉"，但它给出的排序不一定足够准确。于是一些系统会增加 Reranker，重排序模型：它逐一判断"这个问题和这个候选片段到底有多相关"，重新计算分数，把更有价值的内容排到前面。

可以把两步理解为：先从整座图书馆里快速找出二十本可能相关的书，再认真比较其中哪几页最能回答问题。重排序经常有效，但不是装上就一定提升；候选数量、延迟、模型能力和具体数据都会影响结果，最终仍要通过评估验证。

第五站：检索结果还不是最终答案

检索和重排得到的是证据片段，不是可以直接交付给用户的答案。系统还要把用户问题、选中的片段和回答要求组装成提示词，再交给大模型生成。

一个简化后的提示词可能表达这样的要求：

text 复制代码

请只依据下面的资料回答问题。
如果资料不足，请明确说明无法从现有资料中判断。
回答时标注资料来源。

问题：X2 型设备怎么进入手动调节模式？
资料：长按右侧圆形按钮三秒后，设备进入手动调节模式。
来源：《X2 使用手册》3.2 节，第 12 页。

大模型最后生成：

长按设备右侧的圆形按钮三秒，即可进入手动调节模式。来源：《X2 使用手册》3.2 节，第 12 页。

从表面看，这只是一个很短的回答；从系统内部看，它已经经历了文档解析、结构保留、文本分块、向量化、索引、查询处理、召回、重排序、上下文组装和生成。

这也是我现在对 RAG 最直观的理解：它不是一个单独的模型，而是一条把原始资料加工成可用证据，再把证据交给大模型的流水线。

最后一个问题：怎样知道 RAG 做得好不好？

仅凭"这次回答看起来不错"，很难判断系统是否可靠。回答错误时，也不能立刻认定是大模型不够聪明，因为问题可能早在解析或检索阶段就出现了。

为了稳定评估，通常需要准备一份测试集，也常被称为黄金数据集。它不只是"问题加标准答案"，还可以包含：

用户问题；
应该命中的文档或文本块；
能够支持答案的关键证据；
参考答案；
无法回答的问题，用来测试系统是否会拒绝瞎猜。

评估时最好把检索和生成分开看：

评估对象	想回答的问题	常见指标或方法
检索	正确证据有没有被找回来？	Recall@K、Hit Rate
排序	正确证据是否排在前面？	MRR、nDCG
生成	回答是否忠于证据、切题且完整？	Faithfulness、Answer Relevance、人工或领域专家检查

Ragas 等工具可以辅助评估回答与检索上下文之间的关系，但它不是一个替代所有测试的万能分数。自动指标、检索指标和人工抽查结合起来，才能更接近真实效果。

几个容易混淆的地方

走完整条链路后，有几个结论值得单独记住：

**RAG 不等于向量数据库。**向量库只是整条链路中的一个组件。
**检索到"相似内容"不等于找到了"足够的证据"。**语义相关与能够回答问题是两回事。
**切片不是越小越好，Top-K 也不是越大越好。**它们都需要结合实际问题和评估结果选择。
**加入重排序不代表效果一定提升。**所有优化都应该用固定测试集验证。
**RAG 不能彻底消除幻觉。**更可靠的系统还要保留来源、约束生成，并在证据不足时允许模型说"不知道"。
**最终答案不好，要分阶段排查。**先确认知识是否被正确处理，再看证据有没有被召回，最后才看模型有没有正确使用证据。

写在最后

在真正接触文档入库和切片之后，我逐渐发现，RAG 的难点并不只在于"找一个向量数据库，再接一个大模型"。原始资料的质量决定了系统能拥有什么知识；切片和索引决定了这些知识以什么形态被保存；检索与重排序决定了正确证据能不能来到模型面前；提示词和生成模型则决定了证据能不能被忠实地表达出来。

任何一环出现问题，最终答案都会受到影响。

因此，与其把 RAG 看成一个神奇的"知识外挂"，我更愿意把它理解成一套证据流转机制：**先整理知识，再寻找证据，最后依据证据回答。**理解了这条主线，之后再学习各种解析工具、分块策略、Embedding 模型、混合检索和评估框架时，就能知道每项技术究竟在解决哪一个环节的问题。

这一篇先画出地图。接下来，我会从目前接触最多的文档入库和文本分块开始，继续拆解每个模块：不同格式的文档应该怎样解析，元数据为什么重要，分块的长短和边界又会怎样影响最后的检索结果。

参考资料

Patrick Lewis 等，Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
Datawhale，All-in-RAG
Ragas，RAG evaluation framework