RAG基础与系统架构：重新理解检索增强生成

2023 年 6 月,哥伦比亚特区联邦法院收到一份由律师提交的法庭文书,其中援引的六个先例被法官逐条核验后认定至少五个从未存在。这是 ChatGPT 首次在严肃法律场景中"编造判例"的高曝光事件,几乎同一时间,某大型科技公司发生员工将私有源代码粘贴至 ChatGPT 进行排错的泄密事故,某头部金融机构在内部知识助手上线三个月后紧急下线,因为模型给出了错误的合规结论且无人能定位问题出处。这些事故的共同点不是 LLM 本身的能力缺陷,而是把 LLM 当作"无所不知的知识库"来用——而它本质上是一个训练数据快照上的概率性模式补全器。

理解这一点,是讨论 RAG 工程体系的起点。RAG(Retrieval-Augmented Generation,检索增强生成)不是某一个具体算法,也不是某一类模型的别名,而是一整套让大模型与外部知识源协同工作的工程范式。本章的目标是建立这份范式的"地图":从大模型的固有局限出发,论证 RAG 的核心价值;再把一个生产级 RAG 系统的全貌拆成离线与在线两条链路;最后通过一次端到端的 Hello-RAG,把所有抽象概念落地为可运行的代码,作为后续章节的入口。

1.1 大模型的四个工程挑战

在企业级 AI 落地过程中,任何把 LLM 直接当作问答系统使用的方案,几乎都会在四个维度上同时受挫。这四个挑战不是技术爱好者的设想,而是从 2022 年底到 2024 年中,数千个生产事故复盘后形成的共识。

挑战一:训练数据的知识截止与时效性衰减。主流大模型的训练数据有明确的截止日期,GPT-4 Turbo 的原始知识截止于 2023 年 4 月,Gemini 1.5 Pro 的训练数据覆盖到 2024 年初,Claude 3.5 Sonnet 的截止日期为 2024 年 4 月。这意味着模型对截止日期之后发生的事件、产品发布、价格调整、政策变更、法规修订等几乎一无所知。在企业场景里,这一限制被放大得尤为明显——一家公司的产品手册可能每周迭代,一家律所的判例库每天新增数百条,一家券商的研究报告每天产出上百篇。把这些动态信息塞进模型权重,既不现实也不经济。

挑战二:领域知识的结构性缺失。即便是通用大模型,面对企业内部知识(私有代码库、未公开的财报、定制化业务流程、垂直行业规范)时,信息密度几乎为零。模型可以流畅地讨论半导体行业的供需关系,但无法回答"我们公司 Q3 库存周转天数"这种问题;模型可以解释什么是应收账款融资,但无法基于本机构当前的授信额度与历史违约率给出具体的风控建议。领域知识的缺失不是"模型不够聪明",而是训练数据中根本不存在这些内容——而这部分知识恰恰是企业 AI 落地价值最高的资产。

挑战三:幻觉生成与事实性错误。LLM 在缺乏确切信息时倾向于"编造一个看起来合理"的答案,这种现象被称为幻觉(Hallucination)。幻觉分为两类:一是"事实性幻觉",即生成的内容与客观事实不符;二是"忠实性幻觉",即生成内容与给定上下文矛盾。2023 年 Stack Overflow 临时封禁 ChatGPT 生成的内容,原因是大量用户提交了看似正确实则经不起推敲的代码答案;2024 年某医疗 AI 助手在临床试点中给出错误的药物相互作用建议,引发监管部门的紧急质询。幻觉不会随着模型规模线性下降,OpenAI 在 GPT-4 的技术报告中明确指出,"模型越大,产生更流畅也更难以察觉的幻觉的风险越高"。

挑战四:推理过程不可追溯。传统信息系统的核心契约之一是"可审计性":每一笔交易有日志,每一个结论有依据。而 LLM 默认只输出最终答案,不附带推理路径与事实溯源。在金融、医疗、法律、政务等高合规要求的场景中,这种"黑盒输出"是致命的——无法定位答案来源意味着无法定责、无法复核、无法质证。欧盟 AI Act 在 2024 年正式生效的条款中,明确要求"高风险 AI 系统必须提供决策依据的可追溯记录",这从监管层面把"可解释性"从工程最佳实践升格为合规义务。

这四个挑战互相耦合,共同把通用 LLM 推离了"开箱即用"的范畴。但值得注意的是,这并不意味着 LLM 本身的能力被否定——模型的语言理解、指令遵循、逻辑推理能力仍然是当前最强的。问题在于,我们需要一种机制,让模型的"通用智能"与"领域事实"在运行时被动态地缝合起来,这就是 RAG 的核心动机。

1.2 RAG 的核心价值:从静态知识到动态增强

如果用一句话概括 RAG 解决上述四个挑战的方式,那就是:把模型从"依赖参数记忆知识"转换为"在回答前主动检索外部知识"。这种范式转变带来四个层面的核心价值。

价值一:动态知识注入,突破训练截止的限制。RAG 的检索源可以是任何支持实时更新的存储系统——向量数据库、全文检索引擎、关系数据库、API 端点。当企业产品手册更新、新法规生效、研究报告发布时,只需要让检索源同步更新,所有引用这些知识的问答立刻获得最新答案,无需重新训练模型。这种"知识与模型解耦"的架构,使知识更新延迟从"按月/按季"的再训练周期压缩到"按分钟"的索引刷新周期。

价值二:领域适配,激活企业私有资产。企业知识资产——产品文档、技术规范、客户案例、内部 SOP、合规手册——是 LLM 真正落地产生业务价值的"燃料",但它们从未进入任何公开模型的训练集。RAG 通过把这些资产向量化后存入可检索的索引,使模型在回答企业相关问题时能够"看见"这些原本不可见的事实。从架构上看,RAG 把企业从"被动消费公开知识"升级为"主动生产私有知识,并通过 LLM 实现自然语言访问"。

价值三:可解释性,通过引用建立信任。RAG 系统在生成答案时,通常会附带"引用来源"——即从检索结果中标注答案的具体出处。这天然地把"可解释性"嵌入到答案结构中:用户不仅能看到"是什么",还能看到"为什么"与"出自哪里"。在合规场景中,引用机制本身就是审计证据;在客服场景中,引用机制可以显著降低用户的信任成本(用户可独立核实答案真实性);在研究场景中,引用机制让答案可被进一步追溯与精读。

价值四:低成本知识更新,经济性优势明显。对比一下三种知识更新路径的成本:微调一个 7B 模型在百万级语料上的全参数训练,单次成本约 2-10 万美元(取决于 GPU 时长);继续预训练(Continual Pre-training)的成本更高;而把同一份语料做嵌入并存入向量数据库的端到端成本,通常在数百到数千美元量级,且支持增量更新。更重要的是,微调后的模型在几个月内又会因为新数据而陈旧,而向量索引可以做到准实时刷新。从 TCO(Total Cost of Ownership)角度,RAG 在"知识频繁更新"的场景中具有结构性优势。

需要强调的是,RAG 与 LLM 本身是"协同关系"而非"替代关系"。RAG 提供的是"事实层",LLM 提供的是"理解与表达层"。一个高质量的 RAG 系统,本质上是把"检索器的事实精度"与"生成器的语言能力"在同一答案中融合——这正是后续章节要展开的全部工程问题。

1.3 系统架构总览:离线流水线与在线链路

一个生产级 RAG 系统的全貌,可以拆解为两条相互独立又彼此耦合的链路:离线索引流水线(Offline Indexing Pipeline) 与 在线检索生成链路(Online Retrieval-Generation Pipeline)。离线链路的职责是把原始语料加工成可被高效检索的索引;在线链路则负责响应用户查询,完成"检索-生成"的一次完整调用。两者通过共享的索引存储(通常是向量数据库)进行解耦。

下图给出了一次完整 RAG 调用涉及的全部核心模块,以及它们之间的数据流转关系:

```mermaid flowchart LR subgraph OFF["离线索引流水线"] D1[原始文档库<br>PDF/Word/HTML/DB] --> D2[文档解析<br>Layout/OCR] D2 --> D3[文档切块<br>Chunking] D3 --> D4[向量化<br>Embedding] D4 --> D5[索引构建<br>HNSW/IVF] D5 --> D6[(向量数据库<br>+ 元数据)] D6 --> D7[检索评测<br>Recall/NDCG] end

subgraph ON["在线检索生成链路"] Q1[用户查询] --> Q2[查询理解<br>Rewrite/HyDE] Q6[(向量数据库<br>+ 元数据)] --> Q3 Q2 --> Q3[向量检索<br>Top-K] Q3 --> Q4[重排序<br>Cross-Encoder] Q4 --> Q5[上下文组装<br>Prompt 构建] Q5 --> Q8[LLM 生成<br>含引用] Q8 --> Q9[答案<br>+ 引用来源] end ```

离线索引流水线的五个阶段。第一阶段是文档解析(parsing):从 PDF、Word、HTML、Markdown、数据库记录等异构数据源中抽取结构化文本与版式信息。这一阶段的难点在于,PDF 内部往往包含多栏布局、表格、图片、公式、页眉页脚,简单的文本抽取工具(PyPDF2、pdfplumber)会丢失大量结构信息;生产系统通常需要结合 PyMuPDF、Unstructured、Marker、Tesseract OCR 等工具,并对抽取后的内容做版式恢复与表格重建。第二阶段是文档切块(chunking):把长文档拆分为适合嵌入与检索的语义单元。切块粒度直接决定检索质量——过粗会引入噪声,过细则破坏语义完整性。第三阶段是向量化(embedding):使用预训练的文本嵌入模型(BGE、M3E、OpenAI text-embedding-3、Qwen3-Embedding 等)把每个 chunk 转换为高维稠密向量(通常为 768-3072 维)。第四阶段是索引构建(indexing):把向量及其元数据写入支持近似最近邻(ANN)检索的索引结构,常见的索引算法包括 HNSW、IVF-PQ、ScaNN。第五阶段是检索评测:通过人工标注的 query-document 相关性数据,系统性地评估检索召回率(Recall@K)与排序质量(NDCG@K),为后续调优提供反馈信号。

在线检索生成链路的六个阶段。第一阶段是查询理解(query understanding):对用户输入进行改写、扩写、纠错,必要时通过 HyDE(Hypothetical Document Embeddings)等技术生成"假设性答案"以提升检索匹配度。第二阶段是向量检索:基于查询向量在向量数据库中检索 Top-K 个最相似的 chunk,这里的 K 通常在 4-20 之间,需要根据生成模型的上下文窗口大小与召回目标进行调优。第三阶段是重排序(reranking):使用精度更高的 Cross-Encoder 模型对初筛结果重新打分排序,把真正相关的 chunk 推到前面。重排序阶段的引入是 RAG 系统从"能跑"到"好用"的关键转折点,因为双塔向量检索在精度上有天然瓶颈,而 Cross-Encoder 的精度通常高 10-30%。第四阶段是上下文组装:把重排序后的 Top-K 个 chunk 与系统提示、用户查询拼接为 LLM 的输入上下文,这里需要处理上下文窗口限制、token 预算分配、引用标记注入等问题。第五阶段是 LLM 生成:由生成模型基于组装后的上下文产出最终答案,并显式标注引用来源。第六阶段是后处理:对生成结果做引用解析、合规过滤、敏感词脱敏、格式校准等。

两条链路的耦合点与延迟分布。从时序角度看,一次 RAG 调用的端到端延迟主要由四段构成:网络传输(10-50ms)、检索阶段(50-300ms,取决于向量库规模与索引算法)、重排序阶段(50-200ms,取决于 Top-K 大小与 Cross-Encoder 复杂度)、LLM 生成阶段(500-3000ms,取决于上下文长度与模型规模)。在生产实践中,一个典型调用的 P50 延迟约为 1.2-2.0 秒,P99 延迟约为 3-5 秒。检索与重排序阶段合计通常占总延迟的 20-30%,LLM 生成占 60-70%。这种延迟分布意味着,优化 RAG 系统不能只盯着某一个环节——降低 LLM 生成延迟(如使用更小的模型、开启流式输出、使用 speculative decoding)与提升检索质量(更高召回、更准排序)是两条互相独立又同等重要的优化路径。

离线与在线两条链路通过向量数据库进行解耦:离线链路的更新频率通常是"准实时"(分钟级)或"批量"(天/周级),而在线链路对延迟的要求是"毫秒级响应"。这种解耦带来的工程好处是巨大的——离线链路的索引重建、模型升级、实验切换都不会直接影响在线服务的可用性,只需要通过蓝绿发布、影子流量、灰度切换等机制进行平滑过渡。

1.4 RAG 与微调、Long Context、Prompt Engineering 的对比与组合

RAG 不是企业 AI 落地的唯一选项,把它与另外三种主流范式放在同一张图里看,才能准确定位它的能力边界与适用场景。

| 维度 | Prompt Engineering | RAG | Fine-tuning | Long Context | |---|---|---|---|---| | 核心机制 | 在提示中注入指令与示例 | 运行时检索外部知识 | 把知识/能力写入模型参数 | 把全部上下文塞进输入窗口 | | 知识更新成本 | 极低(改 prompt) | 低(更新索引) | 高(再训练) | 极高(每次重新输入) | | 知识容量上限 | 受上下文窗口限制 | 几乎无上限 | 受模型参数量限制 | 受上下文窗口限制(目前最大 1M-2M) | | 事实精度 | 取决于 prompt 质量 | 取决于检索质量 | 取决于训练数据 | 取决于输入内容 | | 推理能力调整 | 弱 | 弱 | 强 | 无 | | 输出风格定制 | 中等(通过示例) | 弱 | 强 | 中等 | | 可解释性 | 低(无引用) | 高(自带引用) | 低 | 中等(可见原文) | | 实施门槛 | 极低 | 中等 | 高 | 低 | | 单次调用成本 | 极低 | 中等(+检索成本) | 中等(+推理成本) | 高(长上下文定价高) | | 典型延迟 | < 1s | 1.5-4s | 1-3s | 5-30s(超长上下文) |

何时选择 RAG。当任务的知识源是"动态的、大容量的、需要可追溯的",RAG 是首选。典型场景包括:企业内部知识问答(产品手册、SOP、合规文档)、客服系统的实时产品咨询、研究领域的文献综述、法律与医疗的条文检索。这些场景的共同特征是知识需要持续更新、答案需要附带引用、检索范围远超单次上下文窗口。

何时选择 Fine-tuning。当任务的核心诉求是"让模型学会某种特定的推理模式、输出格式或语言风格",而不仅是提供事实知识时,微调更合适。例如:把模型训练成"始终按 JSON Schema 输出结构化答案"、"用特定客服话术与用户沟通"、"掌握某垂直行业的推理范式"(如医学诊断的鉴别树)。微调擅长"能力注入",不擅长"知识注入"——这一点在 2024 年的实践中已成为广泛共识,把整个企业知识库塞进模型参数的做法,无论成本还是效果,都被 RAG 完胜。

何时选择 Long Context。Gemini 1.5 Pro 支持 1M-2M token 的上下文窗口,Claude 3.5 Sonnet 支持 200K,这让"把整本书/整份年报塞进 prompt"成为可能。Long Context 适用于以下场景:用户上传单份文档并要求基于全文的问答;需要跨章节的全局推理;或者在 PoC 阶段快速验证模型对特定长文档的理解能力。但 Long Context 不适合做"知识库级别的检索"——一方面,长上下文的推理成本与延迟随长度非线性增长(Anthropic 与 Google 的研究都指出,模型在长上下文中存在"迷失中间"现象,即对位于上下文中间的段落关注度显著降低);另一方面,长上下文无法做到 RAG 那种"实时增量更新"的灵活性。在生产环境中,Long Context 通常作为 RAG 的补充手段(如在 RAG 召回候选后,使用长上下文做精读),而非独立方案。

何时选择 Prompt Engineering。Prompt Engineering 是所有方案的底层基础,不是替代方案。它解决的是"如何更好地表达任务"的问题,与 RAG、微调是正交关系。一个优秀的 RAG 系统必然搭配精心设计的 prompt(例如 CoT、ReAct、Self-Consistency 等技术),脱离了 prompt 工程的 RAG 系统就像一台没有 UI 的发动机——能力在,但用不起来。

组合策略:RAG + 微调的协同范式。在生产系统中,RAG 与微调经常被组合使用。一种典型的组合方式是:用微调塑造模型的"输出风格与推理范式"(如"始终按三段式输出:背景/分析/建议"),用 RAG 提供"事实层"(如"当前最新的合规要求")。另一种组合是用微调做"领域适配"——在通用基座上先用领域语料做继续预训练,让模型先理解领域语义,再做 RAG 检索,此时的检索精度会显著高于通用基座。还有一种组合是用 RAG 提供"实时反馈信号"——基于用户反馈自动生成微调数据,形成"用户反馈→数据回流→微调→RAG"的闭环。

理解这些边界与组合方式,有助于工程师在面对具体业务问题时,做出"用最少成本解决问题"的判断。RAG 不是银弹,但它是当前"知识密集型"问题最经济有效的工程解法之一。

1.5 Hello-RAG:用 LangChain 搭建第一个原型

理论铺垫到此,接下来用一段不超过 50 行的代码,搭出一个能跑通的最小 RAG 原型。这个原型不是为了生产部署,而是作为后续章节的"参照物"——每当我们引入新的优化技术时,都能以这个原型为基准评估提升幅度。

```python import bs4 from langchain_community.document_loaders import WebBaseLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.vectorstores import FAISS from langchain_openai import OpenAIEmbeddings, ChatOpenAI from langch