基础RAG流程解析：从原始文档到精准答案的生成过程。
基础检索增强生成流程的工作原理：数据清洗、分块处理、嵌入模型、向量搜索、提示词设计、评估方法以及常见的故障点。
来源: Building a Basic RAG Pipeline: A Practical Guide to Retrieval-Augmented Generation
语言模型有个奇怪的习惯：即便没有相关事实，它们也会表现得十分自信。如果你询问公司内部政策、上个月发布的产品手册、晦涩的法律文件或是昨天的支持工单，这些模型很可能根本不知道答案。更糟糕的是，它们可能会编造一些看似合理的内容来掩盖无知。
检索增强生成技术，通常简称为RAG，是解决这一问题的标准方法。通过RAG流程，模型可以在需要时查询外部知识。并非所有信息都必须存储在模型的内存中，因为系统会搜索可信的知识库，提取最相关的段落，并以此为基础生成答案。简而言之，原本只能依靠记忆工作的“闭卷式助手”变成了可以查阅外部资料的“开卷式助手”。
这一方法因2020年一篇关于面向知识密集型自然语言处理任务的检索增强生成研究论文而受到关注，该论文将生成模型与用于搜索外部文档集的检索器相结合。研究的核心发现是，模型内置的知识与外部信息可以相互补充：模型提供语言处理能力，而检索器则提供最新、具体的细节信息。
一个基本的处理流程分为两个阶段。索引阶段负责将文档准备好以供搜索。响应阶段则接收用户的提问，获取相关内容并将其作为上下文传递给模型。这听起来很简单，但每个阶段都暗含着影响最终结果的决策。系统出问题往往并非因为模型本身性能不佳，而更多是因为它检索到了错误的文档、内容片段杂乱无章、提示语模糊不清，或是系统无法承认自己没有答案。
以下内容将从基础层面逐步阐述这一概念。
RAG在实践中的作用
这个基本流程包含四个步骤：用户提出问题，系统在知识库中搜索，最匹配的段落被纳入模型的提示语中，最后模型利用这些获取到的上下文来给出答案。
想象一下，有位顾客想知道一台翻新的笔记本电脑在20天后是否仍可退货。普通的聊天机器人可能会根据一般的零售习惯来猜测。而RAG聊天机器人则可以查询真实的退货政策，找到关于翻新产品的条款并据此回答。如果政策规定翻新笔记本电脑的退货期限为14天，机器人就能确认这一点；如果政策中对翻新笔记本电脑未作说明，机器人就不应自行编造规则。
这就是其核心所在：先检索，再生成。检索功能将海量信息缩小为几条有用的证据，而生成功能则将这些证据转化为有用的回复。如果运用得当，RAG能够提升事实准确性，让答案更易于核实，并且无需重新训练模型即可更新系统所掌握的信息。
选择知识来源
每个信息处理流程都始于需要检索的资料来源。常见的候选资料包括公司文档、产品手册、帮助中心文章、PDF文件、合同、研究论文、会议记录、数据库记录、代码文档以及支持工单。
来源数量最多并不一定意味着最佳。一套有序、整洁且最新的文档通常比大量过时的文件更有用。RAG无法改善劣质的资料来源，因此过时、模糊或相互矛盾的文档会生成同样过时、模糊或矛盾的答案。
在为任何资料建立索引之前，先思考一些实际问题会有所帮助：
- 这些信息是否准确且最新？
- 谁是这些信息的所有者？
- 所有用户都有权查看它们吗？
- 是否存在重复或冲突的版本？
- 表格、图片、脚注或法律条款是否需要特殊处理？
一个规模小且维护良好的知识库是个不错的起点。对于第一个项目，先选择一个明确的应用场景，比如关于员工手册的问题或产品常见问题解答，等运行顺利后再逐步扩展。
文档的清理与准备
原始文件很少可以直接用于检索。PDF文件可能存在断行的问题。网页则包含菜单、Cookie提示条、广告以及每页都会重复出现的页脚内容。内部文档的标题可能缺乏足够的上下文信息，而电子表格则可能将关键细节隐藏在以纯文本形式难以辨识的列中。
清洗过程会将杂乱的内容转化为可检索的文本。这包括去除冗余内容、保留标题、提取表格、将所有内容转换为统一格式以及添加元数据。元数据尤其有用，因为当文本包含文档标题、作者、日期、所属部门、产品版本、链接、访问权限或章节标题等信息时，其价值会大幅提升。
将像“退货必须在14天内提出”这样的简单内容与添加了标签的内容进行比较：标题为“翻新笔记本电脑退货政策”，章节为“退货期限”，最后更新时间为2026年3月，正文则说明翻新笔记本电脑必须在到货后14天内提出退货申请。第二种形式能为检索工具和模型提供更多信息，同时也便于后续的引用和筛选。
将文档拆分为片段
语言模型和检索系统通常无法一次性处理整本书、手册或政策文档库。它们更擅长处理被称为“块”的较短文本片段。
分块是整个流程中最为关键的部分之一，因为检索是在块级别进行的。如果块过大，答案可能会淹没在无关文本中；如果块过小，系统检索到的片段可能缺乏足够上下文而无法给出正确答案。理想的块大小应足以包含一个完整的概念，同时又不会过于庞大以至于难以聚焦。
对于以文本处理为主的系统，开发者通常从几百字左右的块开始，并根据实际效果进行调整。有些系统会使用重叠的块，以避免在段落边界处丢失上下文，例如当一个标题结束一个块的同时，它引用的政策文本又开启了下一个块。
在可能的情况下，分块应遵循文档结构。按照章节、标题、段落或问答对进行分割通常比按固定字符数切割更有效，而不同类型的文档，如退款政策、故障排除指南和科学论文，可能都需要各自不同的处理方法。
许多基础系统正是在这方面默默地取得成功或失败。模型只能根据所接收的内容进行回答，因此缺乏上下文的零散片段甚至会让强大的模型也陷入困境。
生成嵌入向量
在完成清洗和分块之后，每个片段都会被转换成嵌入向量，即意义的数值表示。从技术上讲，它是一个向量，也就是一组用于捕捉文本语义信息的数字。含义相似的文本在向量空间中往往彼此靠近，这使得系统能够根据意义进行搜索，而不仅仅依靠精确的关键词。
假设问题是关于需要多长时间才能退回翻新过的电脑，而文档中说明只要在送达后14天内提出请求，就可以退回翻新后的笔记本电脑。传统的关键词搜索可能会忽略“退回”与“退货”之间的关联，或是“电脑”与“笔记本电脑”之间的联系。基于嵌入的搜索则更有可能发现这些关联。
这种语义匹配机制解释了为何在开放领域问答中密集检索变得如此重要。2020年的密集段落检索研究表明，通过学习得到的密集表示能够在多个开放领域问答的检索基准测试中超越强大的BM25基准模型。
在基本的处理流程中，你会将每个文本片段嵌入到知识库中。当用户提出问题时，也会将其嵌入，并与存储的片段嵌入进行比对，从而找出最相似的结果。
在向量数据库中存储嵌入向量
这些嵌入向量需要一个支持搜索的存储空间，而这正是向量数据库或向量存储的作用。它负责保存每个片段的嵌入向量、原始文本以及任何有用的元数据。在处理问题时，它会找出那些嵌入向量与问题最接近的片段。
对于原型系统，使用本地存储或内存存储即可。而实际生产环境则可能需要使用托管型向量数据库、支持向量的搜索引擎，或是具备向量搜索功能的数据库扩展。选择何种方案应基于系统的规模、速度、成本、过滤需求、安全性以及文档更新频率等因素来决定。
应将其视为检索引擎的一部分，而不仅仅是存储容器。良好的元数据过滤能带来显著效果。关于欧洲退款政策的问题不应检索到其他地区的政策。如果用户只能查看自己部门的人事文件，那么在内容传递给模型之前，检索系统就必须确保这一点。
这很重要，因为当访问控制不严时，RAG可能会导致信息泄露。不能依赖模型在检索后隐藏受限内容，最安全的做法是根本不让这些受限资料被检索到。
检索相关内容片段
当用户提出问题时，回答过程便开始了。系统会将问题嵌入向量存储中并搜索，然后返回匹配度最高的片段。从业者将此称为top-k检索，其中k表示返回的片段数量；top-5则表示返回匹配度最高的五个片段。
选择k值需要权衡。检索的信息过少，答案可能会遗漏关键细节；检索的信息过多，则会导致提示信息杂乱、成本高昂或令人困惑。更多的上下文并不总是更好，但更好的上下文确实更有帮助。
许多基础系统从向量相似度搜索开始，这种方式在处理与含义相关的问题时表现良好，但并非完美无缺。有些查询依赖于确切的单词、编号、名称、日期、错误代码或法律术语，在这些情况下关键词搜索比单纯的向量搜索更有效。
正因如此，混合搜索变得很受欢迎。它将向量搜索与全文本关键词搜索相结合，并整合两者得到的结果。例如，Azure AI Search将混合搜索描述为同时运行这两种搜索方式的单个查询，然后通过互反排名融合技术来整合排序后的结果。简单来说，系统可以通过含义和确切措辞两种途径找到答案。
向量搜索是一个合理的起步方式。如果用户经常输入产品代码、政策标题、法律条文或错误信息，那么可以考虑采用混合方法。
构建提示词
获取到相关片段后，需将其放入模型的提示词中，该提示词应明确说明上下文、用户的问题以及期望模型完成的任务。一个简单的RAG提示词可以指示模型利用所提供的上下文来回答问题，仅依赖其中的信息，当上下文中没有答案时说明不知情，并在可能的情况下注明来源的标题或章节。随后再列出已获取的片段和问题。
这些说明非常重要，因为模型本身具备通用知识。若没有明确的指导，它可能会将检索到的事实与自身的假设混为一谈。这种情况有时可以接受，但对于客服机器人、法律助手、医疗工具或政策辅助工具而言，模型应当始终以给定的证据为依据。
OpenAI的提示工程文档将RAG定义为从向量数据库或文件搜索中获取相关上下文，并将其添加到生成请求中。表述方式很关键：它能让模型将检索到的文本视为应当依赖的依据。
一个编写良好的提示还能帮助处理不确定性，让模型能够说明所提供的文档无法回答该问题。这样的回复虽然不如自信的猜测那么吸引人，但却实用得多。
生成答案
现在，语言模型会生成最终答案，也就是用户实际看到的内容。该答案应当清晰、有依据且具体明确。除非被要求，否则不应直接输出检索到的原始文本。它应该用自然语言进行解释，提及重要的限制条件，并在可能的情况下注明来源。
一个很好的例子是：“翻新的笔记本电脑必须在送达后14天内退回。政策中并未提及20天退换的例外情况，因此根据现有政策，20天后提出的退换申请将不符合条件。”这样的回答之所以有效，是因为它首先说明了规则，再将其应用到用户的实际情况中，且在来源资料没有提供例外时并未虚构例外存在。
注明来源也能增加价值，因为这能让用户验证答案，而不仅仅是依赖模型。让人工智能的回答可追溯是RAG最具实际意义的优势之一。
评估整个流程
在任何人依赖RAG系统之前，都应对其进行测试。一个常见的错误是只检查最终答案。更好的做法是分别评估信息检索和内容生成环节：首先确认检索器是否找到了正确的文本片段，然后再判断模型是否正确使用了这些片段。
一个简单的评估集会将真实用户问题与正确的来源文本及预期答案配对。对于每个问题，都要检查检索结果中是否包含对应的文档。如果正确的文本片段从未传递给模型，就很难得到可靠的答案。
之后还需审查生成的答案。它是否符合上下文？是否添加了无人支持的论点？是否针对真实问题并引用了正确的来源？当现有文档不足以回答问题时，它是否承认了这一点？
Claude RAG手册建议分别评估检索流程和端到端系统，而非仅凭对答案质量的模糊印象来做判断，这一建议即便在小型项目中也值得遵循。
一个基本的评估流程可以涵盖以下方面：
- 检索准确性，即是否找到了正确的段落。
- 真实性，即答案是否有检索到的上下文作为支撑。
- 完整性，即是否包含了所有重要细节。
- 引用质量，即引用的资料是否确实相关。
- 延迟时间，即生成答案所需的时间。
- 成本，即所消耗的令牌数和检索调用次数。
- 用户满意度，即问题是否得到解决。
RAG首次使用时很少能做到完美。通过评估可以找出需要改进的地方，无论是分块处理、元数据、检索、提示词、重排序还是源文档本身。
基本流程的常见问题
流程的初始版本通常表现得既令人振奋又暴露出严重缺陷。典型的问题包括：
- 分块处理不佳。虽然有相关的内容被提取出来，但完整答案并未包含在其中。
- 检索噪声。会返回一些看似相关但实际上无法回答问题的段落，这种情况多发生在查询范围过广、表述模糊或包含大量常见于多份文档中的词汇时。
- 信息过时。虽然更新比重新训练更简单，但前提是知识库必须保持最新。仍留在索引中的旧文档仍可能被检索到。
简单的架构
这种适合初学者的设计采用两阶段流程。在索引阶段，文档会被收集、清洗、分割成块，再与原文及元数据一起存储在向量数据库中。在回答阶段，则将用户的问题进行嵌入处理，检索出最相关的文本块，必要时对其进行过滤或重新排序，随后将这些内容放入提示词中，让语言模型根据该上下文给出答案。
简而言之：文档先被分割成块，再转换为嵌入向量并存储在向量数据库中；问题则转化为查询嵌入，通过检索系统获取相关上下文，最后由大语言模型基于该上下文生成答案。
LangChain和LlamaIndex这类框架提供了用于加载文档、构建索引与检索器，以及将这些检索器与语言模型相连的工具。LangChain的文档说明指出，检索功能可通过加载器和向量存储来利用用户自己的知识库。而LlamaIndex则将RAG视为预先对数据建立索引，这样在调用大语言模型之前就能获取相关的上下文。
学习这一技术并不需要复杂的系统。一个小型原型仅需五个组成部分：文件夹中的若干文档、一个嵌入模型、用于存储向量的地方、一个检索器以及一个聊天模型。关键在于理解每一步的原理，而非将整个流程视为黑箱。
优秀流程的关键所在
一个优秀的处理流程不仅仅是检索文本。它还能找到正确的文本，以模型可使用的形式呈现，并给出与证据相符的答案。最出色的系统具备一些共同特点：使用干净且最新的数据源，进行细致的分块处理，保留元数据，在必要时同时通过语义和精确度进行检索，提供清晰的指令与引用，分别评估检索与生成环节，在文本进入模型之前保护敏感数据，以及具备承认自身无知的能力。
因此，优秀的RAG技术远不止是一项人工智能功能，它融合了知识管理、搜索、产品设计以及安全性等多方面要素。
下一步该做什么
一旦简单的处理流程能够正常运行，还有多种升级方案可供选择：
- 添加混合搜索功能，以便通过语义和精确关键词进行检索。
- 增加重新排序步骤，让第二个模型对检索到的内容进行审核并重新排序。
高级配置还包括引入智能代理、多步骤或基于图谱的检索、针对结构化数据库的查询、图像与文本间的检索，以及针对特定领域的重新排序功能。最新调研表明，该领域正从简单的RAG技术向模块化系统发展，在这种系统中，检索、生成和增强是相互独立的灵活组件，而非单一的固定流程。即便如此，基础处理流程依然是核心。首先找到相关证据，将其传递给模型，再依据这些证据来验证答案的准确性。
为何值得学习
RAG之所以流行，是因为它解决了实际需求。企业、研究人员、开发人员及团队早已将宝贵的知识存储在文档、数据库、手册、工单和笔记中，而仅靠语言模型无法可靠地获取这些知识。RAG为模型提供了查询信息的方法。
其实现流程其实很简单：准备文档、将其拆分、嵌入并存储各部分内容、检索所需信息，最后让模型基于这些信息给出答案。真正的关键在于细节，包括数据源质量、分块处理、检索方式、提示词设计、评估标准以及安全性等。虽然基础流程并非智能助手的最终形态，但它仍是实现更实用、更具时效性且更为可靠的AI的最直接途径。RAG并非要求模型成为无所不知的预言家，而是为其提供“借书证”，并教会它如何有效利用图书馆资源。