RAG（检索增强生成）
复核范围（2026-10-03）
本页讨论文本 RAG 的基础机制与工程检查清单，不评选最新产品。机制、混合检索和评测维度分别回查原始论文与官方文档；架构、权限、版本管理和实践顺序属于本页的工程建议，不是论文已经证明的通用性能保证。未重跑论文实验。
当前结论
RAG 将外部检索结果与语言生成结合，为使用领域资料、更新知识和追溯证据提供条件；收益取决于语料、检索与生成质量。原始 RAG 论文研究的是参数化模型与非参数化检索存储的结合，并不保证任意应用都会更准确。原始论文（v4）
工程上，它不只是“接一个向量数据库”，还需要考虑内容治理、索引、召回、排序、上下文构造、生成、引用和持续评测。
RAG 可能降低无依据生成，却不能自动保证正确。排查时应检查上游问题：资料缺失、分块破坏语义、查询表达不匹配、权限过滤过晚，或正确证据在排序和上下文拼装中丢失；这里不声称这些问题有跨系统统一的发生率排序。
范围与边界
RAG 适用于知识变化快、内容私有或领域长尾、答案需要引用的任务。下列情况不一定需要 RAG：模型已稳定掌握且不要求溯源的常识；可由结构化数据库精确查询的问题；或资料本身不可信、无权访问。
RAG 与其他能力的分工：
- 搜索负责找到候选材料，RAG 还要把证据组织进生成链。
- Fine-tuning 可以改变行为，也能注入知识；对频繁更新、要求引用的资料，可优先评估外部检索。微调与 RAG 并不互斥，原始 RAG 工作本身就包含微调。
- Memory 保存用户或任务状态，不等同于共享知识检索。
- Tool Use 可直接查询数据库或 API；RAG 适合非结构化与半结构化证据。
端到端架构
知识源
→ 解析、清洗、权限和版本元数据
→ 按语义结构分块并建立多路索引
→ Query 理解、改写与过滤
→ 词法 + 向量 + 结构化召回
→ 去重、重排和权限复核
→ 组织上下文并绑定引用
→ 生成答案或明确拒答
→ 记录反馈，进入离线与在线评测内容与分块
分块应尊重标题、段落、表格和代码边界，并保留文档、章节、时间、权限和来源标识。固定长度只是基线；块过小会丢语境，过大则稀释相关信号。
文档更新时需要稳定 ID、内容哈希和删除传播。否则索引会同时保留旧版本，生成层无法判断哪个事实有效。
混合召回
词法检索适合精确术语、代码、名称和数字；向量检索可召回语义相近但措辞不同的内容；结构化过滤可表达领域、时间、权限和类型约束。Azure AI Search 的官方实现把全文与向量结果融合；这支持两类检索互补的设计理由，但不意味着加入混合检索必然提升每个数据集。官方说明
Query 可按需要做实体识别、时间约束、多查询扩展或问题分解，但每一步都会增加延迟和偏移风险。改写后的 Query 应与原始意图一起保留，便于诊断。
重排与上下文
召回解决“可能相关”，重排解决“哪些最值得进入有限窗口”。需要同时考虑相关性、来源质量、时效、互补性和重复度。最终上下文应让每个事实能回到具体证据，而不是只给模型一袋无序片段。
生成与拒答
生成层应区分证据支持的事实、合理推断和未知。找不到足够证据时，明确说明缺口比借模型先验补全更可信。引用必须真正支持相邻结论，而不是只证明“读过某篇文档”。
分层评测
Ragas 原始论文区分答案对上下文的忠实度、答案相关性和上下文相关性。下表在这个区分之上，加入检索排序与业务端到端指标，属于本页的评测组织方法，并非 Ragas 原论文的完整指标清单。忠于上下文也不等于上下文中的事实真实。Ragas 论文第 3 节
三层指标不能互相替代：
| 层 | 核心问题 | 常用指标 |
|---|---|---|
| 检索层 | 相关证据是否进入候选集并排在前面？ | Recall@k、MRR、nDCG |
| 生成层 | 答案是否忠于给定证据？ | faithfulness、citation precision、context use |
| 端到端层 | 用户问题是否被正确、完整且高效地解决？ | correctness、coverage、拒答质量、延迟、成本 |
必须同时记录失败归因。例如答案错误可能是“语料中没有”“未召回”“重排丢失”“模型忽略”或“证据冲突”；只看总分无法指导修复。
数据集设计
评测集应来自真实任务分布，并覆盖：
- 简单事实、跨段整合、多跳和时间敏感问题。
- 无答案、歧义、冲突来源和权限受限问题。
- 中文术语、缩写、别名、代码与数字查询。
- 文档、表格、图片和视频等实际模态。
- 已知线上失败和高价值长尾问题。
真实 Query 更贴近生产，但采集与标注昂贵且会漂移；合成 Query 易扩展、易控制，却可能继承生成模型的分布偏差。实践上应以真实样本为锚，用合成数据补覆盖，并冻结“语料版本—索引配置—评测集版本”三元组。
产品与方案比较
比较黑盒 AI 搜索和可观测 RAG 时，应分开报告：
- 默认配置的开箱体验。
- 相同语料和预算下的对齐配置。
- 能否观察召回、重排、引用和拒答过程。
- 权限、数据驻留、更新延迟和运营成本。
可观测方案更容易定位 faithfulness 问题；黑盒产品可能体验更完整，但失败原因和数据边界更难审计。不存在脱离场景的单一“最佳 RAG”。
常见失败模式
- 语料没有 canonical 版本，重复和过期内容同时召回。
- 只做向量检索，精确名称、数字和代码召回不稳。
- 权限在生成后才过滤，敏感片段已经进入上下文。
- 评测只用合成的简单事实问答，线上长尾完全缺席。
- 以引用数量代替引用支持度。
- 用调优后的最佳成绩代表默认产品能力。
- 只优化 Recall，导致上下文冗余、延迟和生成质量恶化。
- 索引更新没有删除传播，失效事实长期残留。
实践顺序
- 定义用户问题、可信来源和拒答边界。
- 建立可版本化语料、权限与稳定 provenance。
- 用词法检索做可解释基线，再加入向量和重排。
- 创建包含无答案与权限样本的 golden queries。
- 分开测检索、生成与端到端，记录失败归因。
- 用真实反馈补测试集，持续监控时效、成本和漂移。
- 只有在离线提升能转化为端到端价值时才增加复杂度。
进入专题
- Agent 中的检索：AI Agent
- 上下文组织：Context Engineering
- 通用评测：LLM 评估
- 联网搜索：联网搜索评测
- 本库的检索方法：Wiki Hybrid Search