大模型的知识在训练结束那一刻就定格了。问它训练截止日期之后发生的事，它不知道，也没法知道，但它通常不会承认，而是用流畅自信的语气编一个答案。研究数据显示，简单摘要任务的幻觉率可以低到 1%，复杂任务上则能超过 58%。
这不是软件缺陷，而是架构层面的限制：大模型把知识压缩在几十亿甚至上千亿个参数里，训练一结束，这些权重就不再变化。模型不知道自己不知道什么，遇到知识盲区就用编造来填补。RAG（Retrieval-Augmented Generation，检索增强生成）针对的正是这个问题：不把知识塞进模型，而是在每次提问时把相关资料检索出来喂给模型。模型保持不变，数据随时更新，每个回答都能追溯到出处。
本文素材来自 System Design Newsletter 的深度长文，作者是后端与 AI 工程师 Eric Roby。站内此前发过一篇偏动手的《RAG 知识库问答系统怎么搭》，讲具体怎么建；这一篇管原理，解释每个环节为什么这么设计，两篇互为补充。
大模型的知识困境
模型的一切知识都来自训练时抓取、处理、压缩进参数的数据，截止日期之后的世界它一概不知：新产品上线、昨天的安全事故、今早刚改的内部制度，都在它的盲区里。对客服、法务分析、企业内部搜索、合规审查这类对准确性敏感的业务，拿不到最新信息的模型会直接成为风险源。
图：大模型的知识困境与三条出路
长上下文与微调的局限
最直接的想法是暴力解决：把所有资料都塞进提示词。如今不少模型的上下文窗口（Context Window）已经超过一百万 token，看起来放得下很多东西。但这条路有三个问题。
成本首当其冲，token 按量计费，每次提问都携带整个知识库，预算很快会被烧穿。容量也有硬上限，一百万 token 装不下一家中大型企业的全部文档和数据库。第三个问题最容易被忽视：上下文越长，模型的表现反而下降。斯坦福和 UC 伯克利的研究发现，大模型对长上下文的利用呈 U 形曲线，关键信息放在开头或结尾时表现最好，埋在中间时准确率明显下滑。Liu 等人的多文档问答实验里，把关键信息放在 20 篇文档的中部，部分模型的准确率跌到了 25% 左右。往提示词里堆更多上下文，并不能保证模型用得上这些信息。
微调（Fine-tuning）是另一条常见思路：拿预训练模型在自有数据上继续训练，让它学进新知识或新行为。这条路在实践里制造的问题比解决的多。它需要 GPU 算力、机器学习专业能力和精心准备的训练数据，一轮训练要几天到几周；更麻烦的是，训练出来的只是一个快照，底层数据一变，微调模型立刻过时。
两条路都堵住之后，需求本身就清楚了：在每次查询时，把恰当的信息在恰当的时机递给模型，并且不动模型本身。这就是 RAG。
RAG 的定义与工作循环
RAG 是一种架构模式，而非某个具体产品。最贴切的类比是开卷考试：闭卷考试的学生只能靠记忆答题，对应标准大模型，推理能力再强也只能用参数里存的东西；开卷考试的学生推理能力相同，但答题前可以翻书，这就是 RAG。
正式定义出自 2020 年 Patrick Lewis 团队（Facebook AI Research 与伦敦大学学院）的论文：RAG 模型把预训练语言模型的参数化记忆，与一份外部知识索引构成的非参数化记忆结合起来，由神经检索器负责访问后者。更新知识只需要换掉检索索引，不需要任何人重新训练模型。
落到工程上，RAG 是一个三步循环：用户提问；系统从外部知识库里检索最相关的内容片段；问题和检索到的内容一起交给大模型，由它基于这些资料生成回答。整个过程不改动模型，改动的只是模型每次看到的材料。
核心机制：Embedding 与语义检索
整套体系的地基是 Embedding（向量嵌入）：把文本转换成稠密数值向量，通常是 1536 维或 3072 维的浮点数组，向量的位置编码了文本的含义。含义相近的词句，即便用词完全不同，在向量空间里也会靠得很近。
一个典型例子：“怎么重置密码？”和“我登录不上账号了”没有一个词相同，转成向量后却几乎重合，用余弦相似度、点积或欧氏距离一算，距离非常小。这对 RAG 是决定性的：系统按含义找内容，而不是按关键词匹配，用户的问法和文档原文措辞对不上也能检索到。
离线管线：数据摄取五步
图：RAG 的两条管线，共用同一个向量库
一个 RAG 系统由两条管线组成：离线的数据摄取管线负责把资料准备好，在线的检索生成管线负责回答问题。
摄取管线在有新数据时运行：文档新增或更新、数据库发生变化、按每晚或每周的固定周期，乃至检索质量下降、新数据源接入，都是常见的触发时机。它分五步：
- 加载文档：从 PDF、数据库、API、wiki、Slack、Confluence 等各种来源拉取内容，LangChain 和 LlamaIndex 这两个框架为常见数据源提供了现成连接器。
- 分块（Chunking）：把文档切成语义完整的片段。这是整条管线里杠杆最大的一步，切法直接决定检索质量，起步阶段的调优时间优先投在这里最划算。
- 向量化：用 Embedding 模型把每个分块转成向量。
- 入库：向量存进为相似度检索优化过的向量数据库。
- 元数据标注：给每个分块打上来源、时间戳、类别、访问权限等标签，后续的过滤、答案溯源和权限控制都依赖它们。
在线管线：从提问到生成
用户提问后，问题先被转成向量，用的必须是摄取阶段同一个 Embedding 模型，查询和文档必须落在同一个向量空间里，这是硬约束。工程上的推论是：中途换 Embedding 模型，整个知识库的向量都要重建，选型时要当成一次性决定来对待。
接着做相似度检索，拿查询向量和库里的向量比对，取最相似的 Top-K 条。检索策略有三种：
- 稀疏检索（Sparse Retrieval）：BM25 一类的统计方法，按词频和逆文档频率给关键词的精确匹配加权，擅长命中必须一字不差的内容。
- 稠密检索（Dense Retrieval）：基于向量的语义检索，措辞不同也能找到概念上相关的内容。
- 混合检索（Hybrid Search）：两种都跑，再用 RRF（Reciprocal Rank Fusion，倒数排名融合）合并结果，在两个榜单上都靠前的文档会被抬升。
对中文知识库，混合检索是更稳妥的默认选择：产品型号、命令行报错、专有名词这类精确字符串，纯向量检索容易失手，需要关键词通道兜底；而稀疏检索一侧的效果又依赖中文分词质量，选型时要一并验证。
检索结果还可以再过一道重排序（Re-ranking）：交叉编码器（Cross-Encoder）把查询和每篇候选文档拼在一起打分，能捕捉到普通双编码器漏掉的细粒度相关性。代价是延迟，每条候选都要过一遍模型，候选数量多时用户能明显感觉到变慢，延迟敏感的场景要在质量和响应速度之间做取舍。
最后是生成。系统把三部分拼成最终提示词：系统提示词（告诉模型扮演什么角色，比如“你是客服助手”）、检索到的内容片段（比如从公司政策文档里抽出的两段退款条款）、用户的原始问题（原样保留，不做改动）。模型基于提示词里的事实作答，而不是依赖训练记忆。回答还能附上出处，比如“依据员工手册 3.2 节”，用户能核对答案从哪来。可溯源是 RAG 相对微调最大的优势之一。
RAG 与微调的分工
多数团队面对的第一个选择题是 RAG 还是微调。逐项对比如下：
| 对比项 | RAG | 微调 |
|---|---|---|
| 数据新鲜度 | 实时（重建索引即可） | 训练完即开始过时 |
| 成本 | 前期投入低，按查询付费 | 前期投入高（GPU/TPU 训练） |
| 搭建周期 | 几小时 | 几天到几周 |
| 透明度 | 可引用出处 | 黑盒 |
| 数据变更时 | 只重建变过的文档索引 | 整体重新训练 |
| 机器学习门槛 | 很低 | 较高 |
| 通用能力 | 模型不动，能力保留 | 有遗忘既有能力的风险 |
| 适合场景 | 动态知识、需要溯源 | 调整模型行为、文风、语气 |
关键在于两者是互补关系。微调改的是模型的行为、文风和输出格式，不适合用来灌知识；RAG 管知识，不改模型。成熟的生产系统通常两者都用：先微调让模型稳定输出某种结构化 JSON 格式，再用 RAG 填充最新数据。
RAG 与长上下文的配合
上下文窗口在持续变大，但它替代不了 RAG。RAG 每次只取最相关的 5 到 20 个分块，单次查询更便宜，命中也更准，而且能在百万级的文档库里检索，长上下文再大也有 token 上限。前面提到的“中间信息丢失”研究同样支持这一点：检索出少量高相关片段，比塞一大段上下文让模型自己找，效果更好。
两者配合的方式是：先用 RAG 把最相关的 20 个分块找出来，再靠长上下文一次性装下并处理它们。
传统 RAG 与 Agentic RAG
上面描述的三步循环是传统 RAG：检索一次，拿到什么用什么。第一次检索结果不好时，它没有任何补救手段，只能硬着头皮生成。
Agentic RAG 在检索层上加了一个会推理的智能体，由它决定每个查询怎么处理：可以改写查询、串联多轮检索、在多个知识库之间挑选，也可以判断某个问题不需要检索、直接回答。还是用学生打比方：传统 RAG 是查一页书就下笔，Agentic RAG 是翻几本书、对不上的地方回头重读、交叉验证之后才动笔。
| 对比项 | 传统 RAG | Agentic RAG |
|---|---|---|
| 查询处理 | 单次检索 | 多步迭代检索 |
| 纠错能力 | 无，检到什么用什么 | 可重新检索、改写查询、换数据源 |
| 复杂度 | 低，好搭好调试 | 高，需要智能体编排层 |
| 适合场景 | 简单问答、固定文档集 | 复杂查询、多来源推理 |
| 延迟 | 低（单次检索） | 高（多轮检索） |
代价同样摆在明面上：多轮检索意味着延迟和 token 消耗成倍增长。简单的知识库问答用传统 RAG 就够了，Agentic RAG 适合多来源、需要推理串联的复杂查询。
生产级 RAG 的多步管线
演示级和生产级 RAG 的差距，主要在检索前后的处理环节。生产系统通常把管线扩展成六步：
- 查询意图解析：先判断用户要什么，是事实型提问、对比，还是摘要请求，再据此选择检索策略和知识库。
- 查询改写：把口语化的问题改写成更利于检索的形式，比如“为什么我的应用这么慢”改写成“应用性能瓶颈的原因与解决方案”。
- 检索：按前述流程取回相关分块。
- 联网搜索：内部文档不够用时，部分系统会补一轮实时网页搜索获取最新信息。
- 重排与过滤：对结果打分、过滤、重新排序。
- 生成：模型基于全部上下文产出回答。
国内落地的选型参考
原文的技术栈默认以 OpenAI 生态为参照，国内落地时有几处需要换算。
Embedding 模型：OpenAI 的 text-embedding 系列 API 在国内无法直接访问。开源侧可以看智源的 BGE 系列，中文检索效果在公开评测上长期靠前，支持本地部署；商用侧阿里、字节等厂商都有 embedding API 可选。前面说过换模型要重建全部索引，这个决定在选型时要一次定准。
向量数据库：Milvus 是国产开源项目，社区和文档都比较成熟；数据量不大时，PostgreSQL 加 pgvector 插件就能起步，不必一上来就引入独立的向量库组件。
适用边界也要想清楚。知识库总量只有几万字、内容又不常更新的场景，直接把全文塞进提示词比搭一套 RAG 更划算，毕竟摄取管线、向量库、检索调优都是持续的维护成本。RAG 的价值在数据量大、更新频繁、需要答案可溯源的场景才能兑现。至于检索和生成质量怎么量化评估，可以参考站内《LLM 评估怎么做》一篇给出的指标体系。
© 版权声明
文章版权归作者所有，未经允许请勿转载。
