端到端RAG工作流：检索增强生成的工作原理

检索增强生成（Retrieval Augmented Generation，RAG）是一种人工智能架构模式，它在推理时将大语言模型与外部知识源连接起来，使模型能够生成超越其静态训练数据的准确、上下文感知的响应。RAG系统不是依赖预训练期间编码的知识，而是针对每个用户查询从外部数据库中检索相关文档，并将这些内容注入到生成前的LLM提示中。结果是生成式AI系统能够基于经过验证的来源产生准确、特定领域的答案，而无需在底层知识发生变化时重新训练整个模型。

LLM常常因知识截止日期而提供过时的答案，并且无法访问专有的内部文档或实时的外部数据源。RAG直接解决了这一限制。超过60%的组织正在积极开发基于AI的检索工具，这反映了从仅依赖模型记忆到动态连接AI与包含内部文档、产品文档和当前数据的实时知识库的根本转变。

本指南将介绍完整的RAG工作流——从架构组件和数据摄入到混合检索、提示设计、评估和部署——并为构建生产级RAG管道的团队提供实用指导。

RAG架构的关键组件

RAG系统包含四个主要组件：存储外部知识的知识库、为每个查询找到相关文档的信息检索组件（检索器）、将检索到的上下文组装成LLM提示的集成层，以及生成最终响应的生成器（LLM）。每个组件都可以独立优化，整个管道的质量受限于最薄弱的环节——高质量的LLM无法弥补持续检索不相关文档的检索器。

检索器和向量数据库

检索器接收用户查询，将其转换为可比较的表示形式，并从知识库返回最相关的文档。检索器质量是RAG输出质量的单一最大决定因素。向量数据库存储文档块的数值表示——称为嵌入——从而支持大规模快速相似性搜索。与基于精确值匹配的关系数据库不同，向量数据库使用余弦相似度等距离度量来查找语义上与查询最接近的文档。

生成器和编排层

生成器是接收增强后提示（用户原始问题与检索上下文相结合）并生成最终响应的大语言模型。编排层将所有组件连接成一个连贯的RAG管道，处理提示组装、对话历史和错误处理。LangChain和LlamaIndex等框架提供了常见的编排原语，而Databricks等平台则为全栈提供托管基础设施。

数据源和外部知识

RAG系统的有效数据源范围很广：关系表中的结构化数据、PDF和Markdown文件中的非结构化文本、内部文档（如工程手册和HR政策）、产品文档以及外部知识库。领域特定数据——即直接与用户可能提出的问题相关的内容——应首先摄入并最仔细维护。内部数据，包括专有研究和内部文档，在RAG实现中能产生最具防御性的优势，因为这些知识是任何公共LLM都未曾训练过的。

选择数据源时的实际问题在于相关性密度：索引文档中实际能在响应真实查询时被检索到的比例。高相关性源能证明嵌入和索引的计算和财务成本是合理的；低相关性源则会增加检索器必须过滤的噪声，从而降低检索质量。

多个数据源可以合并到一个RAG系统中——例如，将产品文档库与实时客户数据库配对——只要摄入管道将每个源归一化为一致的文本格式。团队应记录每个索引源的数据血缘，以便任何检索文档的起源都能追溯到其权威来源，从而在受监管行业中实现审计和合规工作流。

嵌入模型和向量存储

选择嵌入模型

嵌入模型是一种专门的语言模型，它将文本转换为数值表示——高维向量，这些向量编码语义含义。当用户提交查询时，相同的嵌入模型将该用户输入转换为可比较的向量，从而能够在查询与所有存储的文档嵌入之间进行数学比较。摄入时使用的嵌入模型必须与查询时使用的完全相同。

模型选择涉及表示质量、向量维度、推理延迟和财务成本之间的权衡。通用模型如bge-large-en生成1024维向量，可在多种领域使用。针对技术文本微调的领域特定嵌入模型通常在狭窄的检索任务中优于通用模型。嵌入模型将原始文本转换为使向量相似性搜索成为可能的数值表示。

嵌入模型还可以根据其处理与待检索文档措辞不同的查询的能力进行评估——这种属性称为跨语言或释义鲁棒性。在企业环境中，用户以对话方式提问而文档以正式方式撰写时，这种语义桥梁至关重要。在提交生产索引运行之前，使用代表性样本的真实用户查询测试嵌入模型，可以防止后续对整个语料库进行代价高昂的重新嵌入。

分块策略和索引

大型文档在嵌入前必须分割成较小的块，因为嵌入模型的上下文窗口有限，且较小的块能提供更精确的检索。块大小直接影响输出质量：块太小会丢失周围上下文，块太大会稀释与用户问题最相关的特定段落。常见策略包括按令牌数量进行固定大小分割，以及带有重叠边界的句子边界分割，以减少关键上下文落在边界上的风险。

嵌入后，向量被存储并在向量存储中建立索引。使用HNSW等算法的向量索引对嵌入进行组织，以实现大规模近似最近邻搜索，将检索从对所有嵌入的线性扫描减少到亚毫秒级查找。

信息检索与混合搜索

语义搜索——大多数RAG系统的支柱——找到与用户查询含义最接近的文档，自然处理改述和同义词。Databricks AI Search实现了语义向量搜索，并自动从Delta表同步，使知识库无需手动重新索引即可反映新数据。

纯语义搜索在精确匹配查询方面存在已知弱点：特定错误代码、版本号或命名实体。混合搜索通过结合语义向量搜索和BM25关键词搜索（一种在精确和罕见词匹配方面表现出色的概率词频模型）来解决此问题。并行运行两个搜索路径，并使用倒数排名融合合并结果，可在更广泛的查询分布上提高检索效率。

一个重排序步骤可以进一步改善结果：使用交叉编码器模型根据查询对每个检索到的文档进行评分，并重新排序结果，使最相关的文档排在前面。诸如重排序之类的检索方法能显著提高精度，并且在LLM上下文窗口限制可传递给生成器的文档数量时尤为有价值。

相似性阈值增加了最终质量门控：相关性分数低于最低截止值的文档应被完全过滤掉，而不是作为低质量上下文传递给生成器。传递不相关的上下文比不传递上下文更糟糕——它会消耗上下文窗口，并增加LLM在生成响应中将正确与错误信息混合的风险。设置保守阈值并随时间监控过滤率是一种无需架构更改即可维持检索质量的直接方法。

RAG如何工作：从摄入到生成

RAG工作流遵循五个连续阶段，将用户的问题转化为基于事实的准确响应。

阶段1：摄入并归一化外部数据

RAG管道从数据摄入开始。原始文档被加载到ETL管道中，该管道清理和归一化文本——删除样板文件、标准化空白、从表格和代码中提取结构化内容。数据湖仓架构在统一治理下集中摄入结构化和非结构化内容，使其成为RAG知识库的自然基础。

阶段2：分块、嵌入和索引

清理后的文档被分割成块，每个块通过嵌入模型生成向量，结果嵌入连同原始文本和元数据（文档标题、日期、来源URL）写入向量存储。元数据支持过滤检索——限定结果仅包含特定日期范围内或特定用户角色可访问的文档。RAG需要持续更新以保持数据相关性；生产系统需要自动化管道，检测更新后的源文档并按计划或事件驱动触发重新嵌入。

阶段3：检索相关文档

当用户提交查询时，RAG系统使用相同的嵌入模型将用户输入转换为向量表示，并查询向量存储，执行相似性搜索，返回最相关的top-k个文档块。k值——检索多少个块——需要在检索覆盖率和上下文窗口消耗之间权衡，并且必须针对目标LLM进行调优。

阶段4：增强LLM提示

检索到的文档被组装成增强后的提示。典型结构首先放置系统指令（“仅根据提供的上下文回答用户问题。如果在上下文中找不到答案，请说出来。”），然后是检索到的文本块，最后是用户的原始问题。将最相关的文档放在前面有助于提高注意力，特别是对于容易受到“中间迷失”现象影响的模型，该现象中靠近开头和结尾的上下文比中间内容获得更多关注。

阶段5：生成最终响应

生成器接收增强后的提示并产生最终响应。后处理可以进一步优化输出，例如格式化或添加引用。一个生产级RAG系统还必须包含反馈循环，收集用户对响应的评价以持续改进检索和生成质量。

通过遵循这个端到端工作流，组织可以构建不仅准确而且可解释、可信且易于更新的AI系统，充分利用实时知识的全部力量，而无需承受持续重新训练模型的负担。