01. RAG 详解

版本：v1.1
最后更新：2026-07-06
适用对象：希望系统理解 RAG 原理、架构、检索优化、评测与企业落地的开发者和产品技术负责人

1. 什么是 RAG

RAG 是 Retrieval-Augmented Generation 的缩写，通常译为“检索增强生成”。

一句话解释：

RAG 不是让模型凭记忆回答，而是先从外部知识库检索证据，再让模型基于证据生成答案。

一个典型 RAG 回答过程可以写成：

text

User Question
 -> Query Understanding
 -> Retrieval
 -> Rerank / Filter
 -> Context Assembly
 -> Generation
 -> Citation / Verification

RAG 的关键不是“把文档塞给模型”，而是：

找到正确证据
控制证据质量
让模型忠实使用证据
对答案和引用进行评估

如果没有检索、排序、上下文构造和评测，只是把几个文档片段拼进提示词里，严格来说还不能算一个可靠的 RAG 系统。

2. RAG 的论文背景

RAG 这个名字来自论文 Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks。这篇论文的核心思想是把两类能力结合起来：

能力	含义	优点	局限
参数化记忆	模型权重里学到的知识	推理速度快，语言能力强	知识可能过时，难以追踪来源
非参数化记忆	外部文档、索引、数据库	可更新、可追溯、可扩展	依赖检索质量和数据治理

论文里的 RAG 模型会先检索相关文档，再把检索结果和问题一起交给生成模型。它解决的是一类知识密集型任务：问题的答案往往依赖外部事实，而不是只靠语言模式就能稳定回答。

这给工程实践带来一个很重要的启发：

模型不应该承载所有知识，知识应该放在可更新、可审计、可检索的外部系统里。

3. 为什么需要 RAG

只靠模型自身回答，会遇到几个现实问题。

3.1 私有知识缺失

模型不知道企业内部文档、工单、制度、项目记录和最新产品资料。

3.2 知识更新慢

模型训练完成后，参数中的知识不会随着你的业务文档自动更新。

3.3 缺少证据链

很多企业场景不能只要一个答案，还要知道：

答案依据哪份文档
文档版本是什么
是否符合权限范围
出错后能否追溯

3.4 长上下文成本高

把所有资料都放进上下文窗口，通常会遇到：

token 成本高
延迟高
噪音多
模型注意力被稀释

3.5 幻觉风险

没有证据约束时，模型容易生成看似合理但无法验证的内容。

RAG 的价值就是把“回答问题”变成一条可观察、可优化的链路。

4. RAG 的核心心智模型

可以把 RAG 看成三个系统的组合。

text

Knowledge System
 -> Retrieval System
 -> Generation System

4.1 Knowledge System

负责知识从哪里来、如何清洗、如何更新、如何授权。

它包括：

文档源
解析器
chunking 策略
metadata
权限模型
版本管理

4.2 Retrieval System

负责把用户问题映射到候选证据。

它包括：

query 改写
embedding
关键词检索
向量检索
metadata filter
hybrid search
reranking

4.3 Generation System

负责把证据转成最终答案。

它包括：

prompt assembly
answer policy
citation policy
refusal policy
structured output
answer verification

RAG 做不好时，问题可能出现在任何一层。只调最后的 Prompt，通常只能解决一小部分问题。

5. RAG 的两条主链路

RAG 不是只有在线问答阶段，它至少有两条链路。

5.1 离线索引链路

离线链路负责把文档变成可检索资产。

text

Document Sources
 -> Ingestion
 -> Parsing
 -> Cleaning
 -> Chunking
 -> Metadata Enrichment
 -> Embedding
 -> Indexing
 -> Quality Check

每一步都可能影响最终答案。

环节	常见问题	影响
Ingestion	文件重复、版本混乱、权限丢失	检索结果脏或越权
Parsing	PDF 表格丢失、标题层级丢失	证据不完整
Cleaning	去掉了关键字段或保留太多噪音	召回不准
Chunking	切太碎或切太大	语义断裂或噪音过多
Metadata	来源、时间、权限缺失	难过滤、难追溯
Embedding	模型不匹配、未重建索引	召回质量差
Indexing	删除和更新不及时	过期内容被召回

5.2 在线查询链路

在线链路负责把用户问题转成答案。

text

Question
 -> Normalize / Rewrite
 -> Retrieve
 -> Rerank
 -> Filter
 -> Build Context
 -> Generate Answer
 -> Validate / Cite

在线链路的核心目标是：

用尽量少、尽量准、可追溯的证据支持回答。

6. 文档解析与清洗

RAG 系统的上限经常由文档处理决定。

6.1 文档解析要保留结构

企业文档里，结构信息往往比正文还重要。

应该尽量保留：

标题层级
表格
列表
代码块
图片说明
页码
章节路径
更新时间
来源链接

如果解析后只剩一坨纯文本，检索和引用都会变难。

6.2 清洗不是越干净越好

清洗的目标不是把文本变短，而是保留对回答有价值的信息。

应该移除：

重复页眉页脚
无意义水印
大量导航菜单
广告和噪音

应该谨慎保留：

表格字段名
编号
产品型号
法条条款
错误码
时间和版本

这些内容对语义模型不一定显眼，但对企业问答往往是关键。

7. Chunking 为什么决定下限

Chunking 是把长文档切成检索单元的过程。它决定了检索系统能看到什么粒度的知识。

7.1 切太大的问题

一个 chunk 里包含太多主题
相似度被平均掉
top-k 召回里噪音增多
放进上下文后占用大量 token

7.2 切太小的问题

缺少前后文
表格或流程被切断
标题和正文分离
模型拿到证据却无法完整回答

7.3 常见切分策略

策略	适合场景	风险
固定长度切分	快速原型、纯文本	容易切断语义
滑动窗口	需要保留上下文	重复内容多，成本上升
按段落切分	文档结构清晰	段落长度不稳定
按标题层级切分	手册、制度、知识库	依赖解析质量
语义切分	长文、主题变化明显	实现复杂，需要评测
表格专用切分	财务、产品、合同	需要保留列名和行语义

7.4 推荐做法

更稳的做法通常是：

保留标题路径，例如 一级标题 > 二级标题 > 当前段落。
每个 chunk 带上来源、页码、更新时间、权限等 metadata。
对表格、代码、FAQ 使用专门切分策略。
用评测集调 chunk size 和 overlap，而不是凭感觉。

8. Embedding 与向量索引

Embedding 会把文本转成向量，使语义相近的文本在向量空间里更接近。

OpenAI Embeddings 文档把 embedding 描述为文本相关性的数值表示，可用于搜索、聚类、推荐、异常检测和分类等任务。放到 RAG 里，它主要承担语义检索的基础表示。

8.1 Query embedding 和 document embedding

典型向量检索会分别处理：

文档 chunk embedding：离线生成并写入索引
用户 query embedding：在线生成，用来查找相似 chunk

8.2 选择 embedding 模型要看什么

维度	说明
语言覆盖	是否支持中文、英文或多语言
领域适配	是否适合代码、法律、医疗、客服等语料
向量维度	影响存储、检索速度和成本
成本	入库和查询都会产生调用或算力成本
更新策略	换 embedding 模型通常需要重建索引

8.3 常见坑

文档用一个 embedding 模型，查询用另一个模型。
embedding 模型更新后没有重建历史索引。
把过长、过杂的 chunk 直接做 embedding。
忽略中文分词、英文缩写、产品编号等精确匹配问题。

9. 检索方式：关键词、向量、混合检索

RAG 检索不是只有向量检索。

9.1 关键词检索

关键词检索适合：

产品型号
错误码
人名
项目名
条款编号
精确字段

它的短板是对同义表达、口语化问题和抽象概念不够友好。

9.2 向量检索

向量检索适合：

语义相近表达
用户问题和文档措辞不同
概念型查询
自然语言问答

它的短板是可能召回“语义相关但业务不相关”的内容，尤其在专有名词和编号场景里。

9.3 混合检索

OpenAI File Search 文档说明，文件搜索会同时使用语义检索和关键词检索，并基于 vector stores 管理文件内容。这也反映了真实 RAG 系统的常见方向：混合检索通常比单一路径更稳。

典型混合检索链路：

text

Query
 -> Keyword Search
 -> Semantic Search
 -> Merge Candidates
 -> Metadata Filter
 -> Rerank
 -> Context Assembly

混合检索的关键不是“多加一个搜索方式”，而是让不同信号解决不同问题。

10. Query 改写与查询理解

用户问题通常不是天然适合检索的。

10.1 为什么要 query 改写

常见用户问题：

太短：报错 500
太口语：这个咋弄
有指代：刚才那个配置怎么改
多意图：帮我查价格，顺便看能不能退款
缺上下文：审批规则是什么

直接拿这些 query 做检索，效果往往不稳定。

10.2 常见改写方式

改写方式	示例
补全上下文	把“这个配置”改成具体配置名
拆分多意图	价格问题和退款问题分开检索
生成关键词	从自然语言里提取错误码、产品名、条款号
多查询扩展	同一问题生成多个等价检索 query
语言归一	中英文术语、缩写、别名统一

10.3 改写的风险

query 改写可能引入新错误。

所以要记录：

原始 query
改写后的 query
检索结果
最终答案

否则线上排障时很难知道问题出在哪里。

11. Reranking 与上下文构造

初始检索通常只是找候选集，不能直接把候选全部塞给模型。

11.1 reranking 解决什么

reranking 的目标是重新排序候选证据，让真正有用的片段排到前面。

它通常用于：

初始召回较多
混合检索需要统一排序
top-k 命中但高价值内容不靠前
需要压缩上下文

11.2 上下文构造要做什么

Context assembly 不是简单拼接，它至少要考虑：

去重
排序
来源标记
权限过滤
token 预算
证据完整性
相邻 chunk 补全
引用编号

推荐格式：

text

<context>
[doc_id: A, title: ..., section: ..., updated_at: ...]
内容片段...

[doc_id: B, title: ..., section: ..., updated_at: ...]
内容片段...
</context>

这样模型更容易引用来源，系统也更容易做回溯。

12. 生成阶段：Prompt 不是补救一切的魔法

RAG 的生成 Prompt 应该明确三类规则。

12.1 证据边界

text

只能基于提供的 context 回答。
如果 context 不足以回答，请明确说明资料不足。
不要编造文档中没有的政策、数字、链接、负责人或版本。

12.2 输出结构

text

## 答案
[直接回答]

## 依据
- [引用 doc_id 和关键片段]

## 不确定点
- [没有则写“无”]

12.3 冲突处理

text

如果不同资料存在冲突：
1. 优先使用更新时间更近的资料。
2. 明确说明冲突来源。
3. 不要自行合并成一个看似确定的结论。

生成阶段的核心不是让答案更长，而是让答案忠实、可验证、可追踪。

13. 引用与可追溯

RAG 里的引用不是装饰，而是生产系统的审计能力。

13.1 好引用应该满足什么

能定位到文档
能定位到章节或页码
能知道文档版本
能看到更新时间
能确认用户是否有权限访问

13.2 常见引用问题

问题	原因
引用存在但答非所问	模型没有真正使用证据
引用到错误文档	检索排序或上下文拼接问题
引用粒度太粗	chunk 和 metadata 设计不足
引用无法打开	来源链接或权限同步失败

如果引用不能帮助排查和复核，它就只是“看起来可信”。

14. RAG 评测：必须拆开看

RAG 评测至少要分为检索层和生成层。RAGAS、ARES 等研究和工具也都强调：RAG 评估不能只看最终答案，而要分别关注上下文相关性、答案忠实性、答案相关性等维度。

14.1 检索层指标

指标	关注点
Recall@k	正确证据是否进入前 k 个结果
Hit Rate	是否至少命中一个有效证据
MRR	第一个正确证据排在多靠前
nDCG	排序质量是否合理
Context Precision	放进上下文的片段有多少真正有用
Context Recall	所需证据是否被上下文覆盖

14.2 生成层指标

指标	关注点
Faithfulness	答案是否忠实于证据
Answer Relevance	答案是否回答了用户问题
Citation Accuracy	引用是否支撑答案
Completeness	是否覆盖问题所需关键点
Refusal Quality	证据不足时是否正确拒答
Safety	是否泄露敏感信息或越权内容

14.3 最小评测集

建议先准备 50-100 条样本：

常规问答
精确编号查询
多文档综合问题
证据不足问题
文档冲突问题
权限边界问题
过期文档问题
容易误召回的问题

每条样本要记录：

用户问题
期望答案
必须命中的证据
允许使用的文档范围
不允许出现的内容
失败类型标签

15. RAG 常见失败模式

失败类型	表现	根因	修复方向
覆盖失败	知识库没有答案	文档缺失或未入库	补文档、补同步流程
解析失败	原文有答案但索引里没有	PDF、表格、标题解析丢失	改解析器和结构保留
切分失败	召回片段不完整	chunk 太小或切断上下文	调整 chunk 和 overlap
召回失败	有答案但没搜到	embedding、query、索引问题	query 改写、混合检索
排序失败	找到了但排很后	rerank 不足或权重不合理	reranking、权重优化
过滤失败	正确内容被过滤掉	metadata 或权限过滤过严	检查过滤规则
上下文污染	塞了很多无关片段	top-k 过大、去重不足	压缩、去重、阈值
消费失败	证据在上下文里但答案错	prompt 弱或模型没遵守证据	强化证据规则和引用
引用失败	答案对但引用错	引用生成和证据绑定弱	显式 doc_id、引用校验
权限失败	用户看到不该看的内容	权限未进入检索过滤	权限前置过滤
更新失败	召回旧政策	索引没有增量更新	版本和重建机制

这张表比“模型答错了”更有行动价值。

16. 优化 RAG 的推荐顺序

当 RAG 效果不好时，不建议直接去调 Prompt。更稳的顺序是：

看原始知识是否覆盖答案。
看解析后文本是否保留关键信息。
看 chunk 是否完整表达语义。
看 metadata 是否能支持过滤和追溯。
看检索是否命中正确证据。
看 rerank 是否把关键证据排到前面。
看上下文是否噪音过多。
看 Prompt 是否约束证据使用。
看模型是否适合当前任务。
把失败样例加入回归集。

很多团队会跳过前 7 步，直接改提示词。这样偶尔能修好一个样例，但很难让系统整体变稳。

17. RAG、Fine-tuning、长上下文怎么选

方案	适合解决	不适合解决
RAG	私有知识、可更新知识、证据引用	固定风格学习、深层行为对齐
Fine-tuning	输出风格、任务模式、格式习惯	高频变化的知识更新
长上下文	少量长材料临时分析	大规模知识库长期检索
Prompt Engineering	任务定义、输出约束、流程控制	缺失知识或检索质量差

一个实用判断：

知识经常变，优先 RAG。
行为要稳定，考虑 fine-tuning。
材料少但长，考虑长上下文。
输出不稳定，先检查 Prompt 和结构化输出。

这些方案经常组合使用，而不是互斥。

18. 企业 RAG 的权限与安全

企业 RAG 最大的风险之一不是答错，而是越权召回。

18.1 权限过滤要前置

权限不能只在答案生成后处理。更稳的做法是：

text

User Identity
 -> Allowed Scopes
 -> Retrieval Filter
 -> Candidate Documents
 -> Answer Generation

也就是说，用户无权访问的文档不应该进入候选集。

18.2 metadata 必须支持权限

常见权限字段：

tenant_id
department_id
document_acl
sensitivity_level
owner_team
valid_from
valid_to

18.3 安全边界

RAG Prompt 还要处理：

prompt injection
文档里的恶意指令
敏感信息泄露
跨租户召回
外部链接伪造

尤其要注意：文档内容不是系统指令。来自文档的“忽略上面的规则”等文本应该作为被检索内容，而不是更高优先级的指令。

19. 成本与性能优化

RAG 的成本通常来自四块：

文档入库和 embedding
向量库与索引存储
在线检索和 rerank
生成模型 token

19.1 常见优化方式

优化点	做法
入库成本	增量索引、去重、只重建变化文档
检索成本	metadata 过滤、缓存热门 query
上下文成本	top-k 控制、去重、压缩、相邻 chunk 按需补全
生成成本	小模型预处理、大模型生成、结构化输出减少重试
延迟	并行检索、异步 rerank、流式输出

19.2 不要为了省 token 破坏证据

压缩上下文要谨慎。

如果压缩导致：

删除关键限定条件
删除表格列名
删除版本信息
删除否定词

答案质量会明显下降。

20. 一个可落地的 RAG 最小架构

如果从零做一个企业知识库 RAG，可以先做下面这套最小架构。

text

文档源
 -> 文档同步任务
 -> 解析与清洗
 -> chunk + metadata
 -> embedding + 索引
 -> 检索 API
 -> rerank / filter
 -> answer prompt
 -> 引用输出
 -> 日志与评测回流

20.1 最小字段设计

每个 chunk 至少建议有：

json

{
  "chunk_id": "string",
  "document_id": "string",
  "title": "string",
  "section_path": ["string"],
  "source_url": "string",
  "page": 1,
  "updated_at": "datetime",
  "tenant_id": "string",
  "permission_scope": ["string"],
  "content": "string"
}

20.2 最小日志设计

每次问答至少记录：

json

{
  "question": "string",
  "rewritten_query": "string",
  "retrieved_chunk_ids": ["string"],
  "used_chunk_ids": ["string"],
  "answer": "string",
  "citations": ["string"],
  "latency_ms": 0,
  "failure_type": null
}

没有日志，就很难复盘 RAG 失败。

21. RAG 上线检查清单

数据与索引

文档来源是否明确
是否有增量同步机制
是否保留标题、表格、页码和来源
是否有 chunk_id、document_id、updated_at
embedding 模型变更后是否能重建索引

检索与排序

是否支持关键词和语义检索
是否支持 metadata 过滤
是否按 query 类型评测
是否能观察 top-k 结果
是否有 rerank 或阈值策略

生成与引用

是否要求只基于 context 回答
证据不足时是否能拒答
是否输出引用
引用是否能定位到原文
是否能处理文档冲突

权限与安全

权限过滤是否发生在检索前或检索中
用户无权文档是否不会进入候选集
是否处理 prompt injection
是否记录敏感访问日志

评测与运维

是否有固定评测集
是否分开评估检索和生成
失败样例是否回流
是否有版本和回滚机制
是否监控成本、延迟和拒答率

22. 学习和实践路线

建议按下面顺序学习和落地：

先理解 RAG 的检索增强思想。
学 Embeddings 和向量数据库。
做一个最小知识库问答原型。
加入 metadata、来源、权限和引用。
建立最小评测集。
优化 chunking 和混合检索。
加 rerank、query 改写和上下文压缩。
建立失败复盘和回归机制。

如果跳过评测，RAG 很容易长期停留在“demo 感觉不错”的阶段。

23. 推荐搭配阅读

24. 参考资料

以下资料在 2026-07-06 检查时可访问：

论文与研究

Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks: https://arxiv.org/abs/2005.11401
Dense Passage Retrieval for Open-Domain Question Answering: https://arxiv.org/abs/2004.04906
RAGAS: Automated Evaluation of Retrieval Augmented Generation: https://arxiv.org/abs/2309.15217
ARES: An Automated Evaluation Framework for Retrieval-Augmented Generation Systems: https://arxiv.org/abs/2311.09476

官方文档

OpenAI Retrieval Guide: https://developers.openai.com/api/docs/guides/retrieval
OpenAI File Search Guide: https://developers.openai.com/api/docs/guides/tools-file-search
OpenAI Embeddings Guide: https://developers.openai.com/api/docs/guides/embeddings
OpenAI Structured Outputs Guide: https://developers.openai.com/api/docs/guides/structured-outputs

25. 一句话总结

RAG 是一套把外部知识、检索系统和生成模型组合起来的工程方法。它的难点不在“会不会把文档塞进 Prompt”，而在文档流水线、检索质量、上下文构造、证据引用、权限安全和评测闭环是否足够扎实。

01. RAG 详解 ​

1. 什么是 RAG ​

2. RAG 的论文背景 ​

3. 为什么需要 RAG ​

3.1 私有知识缺失 ​

3.2 知识更新慢 ​

3.3 缺少证据链 ​

3.4 长上下文成本高 ​

3.5 幻觉风险 ​

4. RAG 的核心心智模型 ​

4.1 Knowledge System ​

4.2 Retrieval System ​

4.3 Generation System ​

5. RAG 的两条主链路 ​

5.1 离线索引链路 ​

5.2 在线查询链路 ​

6. 文档解析与清洗 ​

6.1 文档解析要保留结构 ​

6.2 清洗不是越干净越好 ​

7. Chunking 为什么决定下限 ​

7.1 切太大的问题 ​

7.2 切太小的问题 ​

7.3 常见切分策略 ​

7.4 推荐做法 ​

8. Embedding 与向量索引 ​

8.1 Query embedding 和 document embedding ​

8.2 选择 embedding 模型要看什么 ​

8.3 常见坑 ​

9. 检索方式：关键词、向量、混合检索 ​

9.1 关键词检索 ​

9.2 向量检索 ​

9.3 混合检索 ​

10. Query 改写与查询理解 ​

10.1 为什么要 query 改写 ​

10.2 常见改写方式 ​

10.3 改写的风险 ​

11. Reranking 与上下文构造 ​

11.1 reranking 解决什么 ​

11.2 上下文构造要做什么 ​

12. 生成阶段：Prompt 不是补救一切的魔法 ​

12.1 证据边界 ​

12.2 输出结构 ​

12.3 冲突处理 ​

13. 引用与可追溯 ​

13.1 好引用应该满足什么 ​

13.2 常见引用问题 ​

14. RAG 评测：必须拆开看 ​

14.1 检索层指标 ​

14.2 生成层指标 ​

14.3 最小评测集 ​

15. RAG 常见失败模式 ​

16. 优化 RAG 的推荐顺序 ​

17. RAG、Fine-tuning、长上下文怎么选 ​

18. 企业 RAG 的权限与安全 ​

18.1 权限过滤要前置 ​

18.2 metadata 必须支持权限 ​

18.3 安全边界 ​

19. 成本与性能优化 ​

19.1 常见优化方式 ​

19.2 不要为了省 token 破坏证据 ​

20. 一个可落地的 RAG 最小架构 ​

20.1 最小字段设计 ​

20.2 最小日志设计 ​

21. RAG 上线检查清单 ​

数据与索引 ​

检索与排序 ​

生成与引用 ​

权限与安全 ​

评测与运维 ​

22. 学习和实践路线 ​

23. 推荐搭配阅读 ​

24. 参考资料 ​

论文与研究 ​

官方文档 ​

25. 一句话总结 ​

01. RAG 详解

1. 什么是 RAG

2. RAG 的论文背景

3. 为什么需要 RAG

3.1 私有知识缺失

3.2 知识更新慢

3.3 缺少证据链

3.4 长上下文成本高

3.5 幻觉风险

4. RAG 的核心心智模型

4.1 Knowledge System

4.2 Retrieval System

4.3 Generation System

5. RAG 的两条主链路

5.1 离线索引链路

5.2 在线查询链路

6. 文档解析与清洗

6.1 文档解析要保留结构

6.2 清洗不是越干净越好

7. Chunking 为什么决定下限

7.1 切太大的问题

7.2 切太小的问题

7.3 常见切分策略

7.4 推荐做法

8. Embedding 与向量索引

8.1 Query embedding 和 document embedding

8.2 选择 embedding 模型要看什么

8.3 常见坑

9. 检索方式：关键词、向量、混合检索

9.1 关键词检索

9.2 向量检索

9.3 混合检索

10. Query 改写与查询理解

10.1 为什么要 query 改写

10.2 常见改写方式

10.3 改写的风险

11. Reranking 与上下文构造

11.1 reranking 解决什么

11.2 上下文构造要做什么

12. 生成阶段：Prompt 不是补救一切的魔法

12.1 证据边界

12.2 输出结构

12.3 冲突处理

13. 引用与可追溯

13.1 好引用应该满足什么

13.2 常见引用问题

14. RAG 评测：必须拆开看

14.1 检索层指标

14.2 生成层指标

14.3 最小评测集

15. RAG 常见失败模式

16. 优化 RAG 的推荐顺序

17. RAG、Fine-tuning、长上下文怎么选

18. 企业 RAG 的权限与安全

18.1 权限过滤要前置

18.2 metadata 必须支持权限

18.3 安全边界

19. 成本与性能优化

19.1 常见优化方式

19.2 不要为了省 token 破坏证据

20. 一个可落地的 RAG 最小架构

20.1 最小字段设计

20.2 最小日志设计

21. RAG 上线检查清单

数据与索引

检索与排序

生成与引用

权限与安全

评测与运维

22. 学习和实践路线

23. 推荐搭配阅读

24. 参考资料

论文与研究

官方文档

25. 一句话总结