高级 RAG

高级 RAG

基础 RAG（检索一次 → 生成）在简单问答上够用，但面对复杂问题——问得不清、跨多文档、需要多跳推理、多轮追问——就开始失灵。本页讲高级 RAG 的五个发力方向：查询处理、多路召回、知识图谱（GraphRAG）、Agentic RAG、多轮对话检索，以及支撑它们取舍的 RAG 评测体系。检索技术原理见 检索技术，RAG 整体框架见 RAG 基础。

查询处理

检索的第一步不是搜，而是把问题处理成「好检索的问题」。用户的问题往往简短、含混、带口语，直接拿去检索经常搜不中：

• 查询改写：把问题变清晰——展开缩写（「报销」→「费用报销流程」）、纠错（错别字、大小写）、补全意图（「报销怎么走」→「公司差旅费用报销的申请流程是什么」）。做法可让 LLM 先改写再检索（多一次生成调用），或内置规则（术语表、同义词表，零延迟但维护成本高）
• 多查询（multi-query）：一个问题拆成多个检索式，分别检索再合并结果。例：「对比 A 和 B 方案」拆成「A 方案的优缺点」「B 方案的优缺点」——单次检索很难同时命中两边
• HyDE：先让 LLM 基于问题生成一段假设答案，再用这段答案去检索。假设答案比问题更长、更接近文档语言，往往能命中更相关的块（HyDE 论文）；代价是多一次生成调用，且假设答案本身可能编造，适合「问题短、文档长」的场景

意图分类与检索路由

查询处理的高级形态是先分类意图，再按意图选检索策略：简单事实问题直接基础检索；对比问题走多查询；「有没有/是不是」类确认问题可以轻检索 + 快模型；深层分析问题才升级 Agentic 循环。意图分类可用小模型或规则做，分类准确率本身要评测——分类错了，后面全白搭。这也呼应产品视角里的「复杂度只出现在值得的地方」：路由让简单问题保持便宜，把预算留给难题。

改写示例

三种方法的成本与收益

组合与取舍

三者可以组合（改写 + 多查询是常见搭配），但每加一层都要用评测集验证收益。何时值得加：先测基线——如果评测集显示「直接检索的命中率已经够高」，查询处理就是纯增成本；如果 badcase 大量集中在「问得不清、搜不中」，优先上查询改写与多查询，HyDE 按延迟预算再决定。

多路召回与融合

单检索器有固有盲区，多路召回 = 多个异质检索器各跑各的，融合排序，让一路的盲区被另一路补上：

• 向量检索：语义相似，覆盖「换说法」
• BM25 关键词：精确术语，覆盖型号/编号/人名
• 知识图谱检索：实体与关系，覆盖「关联类」问题（见下节）
• 元数据过滤：按权限、时间、文档类型预过滤，缩小候选集——不是打分路，但能大幅提升融合质量

为什么多路能救单路盲区

不同路的错误相关性几乎不重叠：向量路对「A1000」和「A100」的混淆，关键词路不会犯；关键词路对同义词的盲区，向量路不会犯。融合后「至少一路命中」的概率远高于任何单路。直觉例：问题「SOP-42 号文件规定的最长审批时限」——向量路命中「审批时限管理规定」的语义块，关键词路精确命中「SOP-42」，两路合并后答案来源齐全；只跑任何一路都会缺一半。

融合后处理：去重与多样性

多路融合后、进入生成前，还有两道常规处理：

• 去重：不同路可能召回同一个块（向量路与关键词路都命中），融合排序后按块 id 去重，避免同一内容占多个上下文席位
• 多样性控制：若 top-k 被同一文档/同一主题的块霸占，按文档或章节做「至少保留 N 个不同来源」的配额，防止生成只看到单一视角——尤其回答「对比/总结」类问题时，多样性直接决定覆盖度

融合评分示意（RRF）

候选块同时被向量路（第 2 名）与关键词路（第 5 名）命中：

1

score = 1/(2+2) + 1/(5+2) = 0.25 + 0.143 ≈ 0.39

只有一路命中（第 10 名）的块：score = 1/(10+2) ≈ 0.083。两路都命中的块显著胜出——「多路双保险」的优势直接体现在融合分数上。

各路配置参考

代价：每路都要建索引、每次查询多跑一路，延迟与维护成本上升。所以多路召回与查询处理一样，要用评测集证明「单路确实不够」再加——先单路出基线，badcase 归类后，哪类盲区明显再补哪一路。

知识图谱与 GraphRAG

向量检索把文档看成「语义块流」，但块与块之间的关联是隐性的——「A 依赖 B」「C 由 D 负责」这类关系，跨块检索经常答不出来。知识图谱把知识显式化为「实体-关系-实体」三元组（如「差旅费—归属—财务部」），检索时沿关系行走，天然支持关联与多跳问题。

• 实体/关系抽取：从文档中抽实体（人、组织、产品、术语）与关系，可让 LLM 批量抽取，人工/规则校验；抽取质量决定图谱质量，实体对齐（「财务部」与「财务管理部」是不是同一个）是主要工作量
• 图检索：命中一个实体后，检索其「周围」（一跳/两跳邻居及其上的文档块），把相关子图对应的原文块送进生成——「差旅费」命中后沿关系找到「财务部」「报销流程」「预算科目」，比向量路单点命中信息量大得多
• 微软 GraphRAG：面向「全局性问题」（「这套系统的整体架构是怎样的」「各部门职责怎么划分」）——先抽取实体关系建图，再用社区检测把图分成社区、为每个社区生成摘要，查询时先定位相关社区再取其摘要（GraphRAG 论文、微软 GraphRAG 仓库）

建图流程（GraphRAG 风格）分四步

1. 实体关系抽取：LLM 从每个文档块抽三元组（实体、关系、属性），带来源引用
2. 实体对齐融合：合并指称同一实体的不同写法（「财务部」「财务管理部」→ 一个实体），去重
3. 社区检测：在图结构上做社区划分（如 Leiden 算法），把关联紧密的实体聚成社区
4. 社区摘要：为每个社区生成摘要文本（本地/全局两级），检索时按问题定位社区

社区摘要的粒度

GraphRAG 的摘要分两级：本地（local）——每个社区一个摘要，回答「社区内部」的问题（某部门内部职责）；全局（global）——跨社区聚合摘要，回答「整体」的问题（整个公司怎么运转）。粒度选择决定回答颗粒度与成本：全局摘要更贵（一次要聚合所有社区），只在「全局性问题」触发时用；日常查询走本地摘要 + 实体子图即可。

与向量检索的对比

适用判断

适合「关联 / 多跳」问题（依赖关系、对比、影响分析），成本明显高于向量检索（建图要抽取与校验，图存储与检索要额外组件，增量更新也比向量索引复杂）。问题形态以「孤立事实查询」为主的知识库，先不要上 GraphRAG——评测集里出现稳定的「跨实体关联」类问题时再引入。增量更新要点：文档变更时只重抽受影响文档的三元组，别全图重建。

GraphRAG 的代价明细

• 建图成本：每篇文档都要过一遍 LLM 抽取（token 成本 × 文档数），实体对齐还需人工/规则校验
• 存储与查询：图数据库或图存储组件，社区摘要也要占存储；查询走「定位社区 + 取摘要」，比纯向量检索多一跳
• 维护成本：文档更新要增量重抽、重新对齐；实体错抽会以「错误关系」的形式污染后续所有查询——建图质量直接决定 GraphRAG 生死，比向量库的「错块」严重得多
• 评估成本：多跳/全局问题的答案标注比单事实难，评测集建设更贵

这些成本只有在「关联类问题占比高」时才划算；占比低时，向量检索 + 查询改写通常够用。

Agentic RAG

基础 RAG 是「检索一次 → 生成」的直线；Agentic RAG 把检索变成决策循环：检索什么、检索结果够不够、要不要换个方式再检，由模型（或路由逻辑）动态决定。

1
2
3
4

问题 → [规划] 需要哪些信息？ → [检索] 选检索器/查询词
         ↓                        ↓
      答案 ← [生成] ← 资料够了？ ← [评估] 检索结果够吗？
                ↑                  不够 → 改写查询 / 换检索器 / 深入子章节

• 先查目录再查章节：文档量大时，先检索目录/大纲定位到章节，再深入检索该章节——把一次大海捞针变成两次定位，命中率与成本都更优（「检索规划器」把大任务拆成子检索）
• 检索-反思-重检索：第一轮检索结果进入生成前，先判断「这些资料够不够回答问题」——不够就换查询词、换检索器重检（Corrective RAG 的思路：训练/构造一个检索质量评估器，低质结果触发修正检索，见 CRAG 论文）；生成后反思「回答是否被资料支持」，不支持则修正或注明不确定性（Self-RAG 的思路：模型生成时对「检索到的内容是否相关、回答是否被支持」自评，见 Self-RAG 论文）
• 结合工具调用：检索作为工具之一，与计算器、数据库查询、API 调用等组合——Agent 框架把「检索」接入决策循环，与 Agent 架构与多智能体 的规划-执行模式同构；多智能体形态下还可以拆「检索规划器 + 检索执行器 + 答案合成器」分工，各司其职、各自可测

基础 RAG vs Agentic RAG

循环的预算与失败模式

• 设上限：最大检索轮数（如 2-3 轮）、单轮超时、总延迟预算——防止「检索不到就无限重试」把延迟拖爆
• 失败模式：循环本身会累积错误——每轮评估判错（把够的当不够、把不够的当够）都会带偏结果；评估器（LLM-as-judge）的准确率要单独测
• 可观测性：记录每轮「规划 → 检索 → 评估」的决策轨迹，badcase 归因时能回放

什么时候值得

• 值得：复杂多步问题（「按季度汇总各团队成本变化」）、多文档对照、需要多轮工具交互的深度问答——一次检索拿不全，循环有收益
• 不值：简单问答（「报销流程是什么」）——检索一次就够，Agent 化只是纯增延迟与失败点

多轮对话中的检索

多轮场景下，用户第 N 轮的问题往往依赖前 N-1 轮的上文（「那它呢？」「具体多少钱？」）。检索如果只拿本轮问题去搜，必然失焦：

• 历史压缩：把上文对话摘要进检索上下文——「用户是 HR，一直在问报销制度，本轮问『那它呢』」→ 展开为「HR 询问报销制度中提到的某条款的细节」。压缩用 LLM 做，注意控制摘要成本；简单场景也可只拼接最近几轮的问题文本（最近 2-3 轮通常信息量最大）
• 检索上下文追踪：监控话题漂移——用户从「报销」跳到「年假」，检索应该以新话题为准，而不是继续沿用旧话题的上下文；实现上可显式维护「当前话题 + 关键实体」状态，每轮更新。话题切换的检测信号：本轮问题的实体与上文完全不重叠、用户用了新的主题词
• 引用在多轮中的连续性：第 1 轮引用了第 34 条，第 2 轮说「那它的例外呢」——理想体验是引用编号延续（「仍是第 34 条」），不要每轮从零编号；跨轮引用要能回溯到最初的那次检索来源

会话状态与检索记忆

多轮对话的检索质量，本质上取决于会话状态管得好不好：

• 维护「当前话题 + 关键实体」状态：每轮更新（用户提到新实体 → 状态更新；话题切换 → 重置），检索输入 = 本轮问题 + 状态摘要
• 引用上轮检索结果：把上一轮命中的文档作为本轮的「候选优先项」——追问通常围绕上一轮的内容展开，直接复用能省一次检索
• 状态过期与清理：超过 N 轮或话题明显切换后，旧状态要丢弃，避免「十轮前的检索结果还在污染当前问题」
• 状态可视化：把「系统理解你正在问什么」展示给用户（「当前话题：报销制度」），既改善体验，也让话题漂移可发现

实现方案对比

产品侧建议与 RAG 基础 一致：把「本轮问题 + 上文摘要 + 上轮命中的文档」一起作为检索输入，并限制轮次内的话题漂移；多轮对话是检索失焦的重灾区，评测集里必须包含多轮追问样本（追问、改问、指代三类各配几条）。

多轮评测样本怎么设计

多轮检索的评测比单轮难：样本不是「问题 → 应命中块」，而是「对话历史 + 本轮问题 → 应命中块」。建议三类各配几条：

• 追问（「那额度呢」→ 应沿用上轮话题，命中额度相关块）
• 改问（换话题 → 应命中新话题的块，且不再命中旧话题块）
• 指代（「它」「那个条款」→ 应解析回上轮实体）

每类都标注「应命中的块」与「应丢弃的旧话题块」——后者衡量话题切换是否正确重置，这是多轮检索最容易静默失败的点。

多模态与检索

资料库不只有文本：产品手册里的截图、制度里的流程图、培训视频——多模态检索让检索直接作用在图像与视频内容上：

• 图文混合库：图片先经视觉模型生成描述（caption），描述文本进向量库参与检索；命中后把图片原文连同描述一起给模型——「图搜文字描述、答时看图」是最易落地的形态
• 多模态 embedding：CLIP 类模型把图像与文本映射到同一向量空间，可用文本直接检索图像（「找一张报销流程图」）；代价是多模态 embedding 的文本侧效果通常弱于专用文本模型，常需与文本路混合
• 视觉问答（VQA）化：检索命中图片后，多模态模型直接看图回答——「这张图里报销限额是多少」，能力边界见 多模态理解
• 适用判断：资料库图片占比低时，人工补描述即可，不值得建多模态管线；图片是核心资产（设计规范、流程图、票据样本）才考虑

多模态检索同样遵守本页所有取舍原则：先测基线，badcase 归因，评测证明必要再上。

RAG 评测体系

端到端指标：RAGAS 四件套

RAGAS 是面向 RAG 系统的自动评测框架（RAGAS 论文、RAGAS 文档），经典四件套从「检索 → 生成」全链路打分：

计算直觉：以忠实度为例——把回答拆成若干论断，逐一问 judge「这个论断能否由检索上下文支持」，支持的占比即忠实度；其余指标同理，由 LLM-as-judge 在「问题 + 检索上下文 + 回答」上批量打分。所以四件套是同一批样本上算出来的，检索与生成两个环节的错误被拆开定位——忠实度低说明生成侧问题（模型无视资料），上下文指标低说明检索侧问题（召回差）。

组件级评测

端到端指标不能告诉你「坏在哪一环」，组件级评测补上定位能力：

• 检索组件：命中率、召回@k、MRR、NDCG（定义见 检索技术 的「检索评估」）
• 生成组件：把「固定检索结果」喂给不同提示词/模型，测忠实度与答案相关性——隔离生成侧变量
• 引用组件：引用正确率（引用的来源是否真的支撑论断），单独统计

组件级与端到端的关系：端到端看「整体好不好」，组件级看「哪一环坏了」——每次改动先跑端到端看有没有变好，再跑组件级定位变化来源。两者对不上（端到端变差但组件级都好的时候），往往是评测集样本本身的问题（标注质量、分布漂移）。

评测集构建要点

• 覆盖五类：常见问题、长尾问题、应拒答问题、跨文档问题、多轮追问（与 RAG 基础 的评测集口径一致）
• 每条样本的标注分三层：标准答案（人工）、应命中的块 id（人工）、引用应指向的文档（人工）——三层标注对应三条指标线
• 规模 30-50 条起步，随反馈闭环扩充；LLM-as-judge 定期人工抽检校准（判断器可能偏爱冗长或自带立场）

指标怎么选、阈值怎么定

• 指标选择看产品形态：客服问答主看忠实度（幻觉代价高）；资料检索工具主看上下文指标（检索是全部价值）；深度分析助手还要盯答案相关性（答所问）
• 阈值从基线来：先把当前版本在评测集上跑一遍，取各指标分数作为基线；新改动与基线对比，设定「下降超过 X 个点就拦截」的回归红线（如忠实度 -0.05 拦截）
• 指标之间要会读：忠实度与上下文相关性同时低 → 检索没喂对；忠实度低但上下文高 → 生成无视资料；都高但答案相关性低 → 问题理解或提示词问题——四件套一起看才能定位
• 警惕单一指标的过拟合：只盯忠实度可能换来「复读机」式回答——所以相关性类指标必须同时看

失败模式枚举与修复对照表

阈值与监控

• 上线前：评测集跑出基线（如 faithfulness ≥ 0.85、hit rate ≥ 0.8），作为回归红线
• 上线后：抽样监控端到端指标 + 无命中率（检索空结果比例）+ top-1 相关率（人工抽检），低于阈值报警
• 每次改组件（换模型、改提示词、调切块）都跑评测集对比——「感觉变聪明了」不算数，指标曲线才是

演进路径与选型决策

把本页所有方案收拢成一张演进地图：

1
2
3
4
5
6

第 0 级：基础 RAG（BM25 + 向量 + RRF + 提示词约束）→ 建评测集，出基线
第 1 级：切块/embedding/索引调参 → rerank 精排          → 大多数产品到此为止
第 2 级：查询处理（改写/多查询/HyDE）→ 多路召回          → 「问不清/搜不中」类问题
第 3 级：多轮检索（历史压缩/话题状态）                    → 对话型产品
第 4 级：GraphRAG / Agentic RAG                          → 关联多跳/复杂多步问题
第 5 级：多模态检索                                       → 图文混合资料库

决策要点回顾：

• 每级升级的前提是上一级 badcase 归因明确，且评测集验证本级的收益
• 层级越高，延迟、成本、失败点越多——「只在评测证明必要时增加复杂度」（Building Effective Agents）
• 产品形态决定终点：客服问答做到第 2 级即可；企业知识分析助手可能走到第 4 级；第 5 级只在资料确实多模态时考虑

常见问题 FAQ

• HyDE 会不会把假设答案的幻觉带进检索？ 会，所以 HyDE 生成的答案只用于检索、不直接进回答；评测发现「检索被带偏」时就回退
• GraphRAG 和知识图谱是同一个东西吗？ 知识图谱是数据结构，GraphRAG 是微软提出的「建图 + 社区摘要 + 全局问答」方法论；可以只做图检索不做社区摘要
• Self-RAG 和 CRAG 选哪个？ 两者都做「检索质量自评」：Self-RAG 偏生成侧自反思，CRAG 偏检索侧修正（重检/降级）；实践上常取其思路而不是整套框架
• 多轮检索必须用 LLM 压缩历史吗？ 不一定：拼接最近几轮 + 显式话题状态是零成本方案，先试简单的
• Agentic RAG 的评估器怎么测？ 把「检索结果 + 判断」做成小评测集，单独测评估器准确率；评估器不准，整个循环都是空中楼阁
• RAGAS 分数低说明产品差吗？ 不一定：RAGAS 是相对评测工具，分数用于对比与回归；先定基线再谈好坏

产品视角

• 复杂度的代价：查询改写、多路召回、GraphRAG、Agentic RAG……每一层都带来延迟、成本与新的失败点。Anthropic 官方工程博客的原则值得写进团队规范——「只在评测证明必要时增加复杂度」（Building Effective Agents）：先做最简单的检索基线，badcase 在评测集上归类，哪类失败占比高才上对应的那一层复杂度，每加一层都用评测集验证收益

  复杂度分层决策：

  1. 基线：BM25 + 向量检索 + RRF，出评测集基线
  2. badcase 归类：检索不到？答非所问？引用错？多轮失焦？
  3. 按占比逐层加：切块/embedding 调参 → rerank → 查询处理 → 多路/图谱 → Agentic
  4. 每层验证：同评测集前后对比，收益不显著就回退

• 知识新鲜度与权限的放大效应：高级 RAG 组件越多，知识治理的杠杆越大——查询改写会把问题引向新知识，GraphRAG 会沿关系链把权限边界外的实体牵出来，Agentic 循环可能把多个权限级别的资料同时拉进上下文。权限过滤必须在每一路检索前生效，新鲜度要按组件监控（索引同步时间、图更新周期），层级越多越要审计「谁看到了什么」

  权限放大案例

  员工问「公司今年的成本预算」——查询改写把它展开成「各部门成本预算明细」；多路召回里图谱路沿「成本预算—归属—部门」关系链，把包含薪酬数据的内部文档也拉进了候选；若图谱路检索前没做权限过滤，回答就可能泄露高权限内容。每一路检索都要过滤，不是只有主向量路过滤——高级 RAG 的每一层复杂度，都要配一层权限与审计。

  • 评测先于扩展：上高级方案之前，先建评测集跑通基线指标；高级方案上线后，端到端 + 组件级指标都要回归。复杂问题可以分级路由：简单问答走基础 RAG（快、便宜），评测显示「一次检索明显不够」的问题才升级到 Agentic/图谱路线——让复杂度只出现在值得的地方

来源说明

本文为原创整理，主要依据以下权威来源（截至 2026-08-23 均已核实可达，引用日期 2026-08-23）：

1. HyDE 论文（arXiv 2212.10496）——假设文档嵌入，先生成假设答案再检索
2. GraphRAG 论文（arXiv 2404.16130）与微软 GraphRAG 仓库——实体关系建图、社区检测与摘要
3. Self-RAG 论文（arXiv 2310.11511）——检索-反思-生成的自反思机制
4. Corrective RAG 论文（arXiv 2401.15884）——检索结果质量评估与修正检索
5. RAGAS 论文（arXiv 2309.15217）与 RAGAS 文档——端到端评测指标（faithfulness、answer relevancy、context relevance、context precision）
6. Anthropic 官方工程博客：Building Effective Agents——「只在评测证明必要时增加复杂度」原则

发现错误？想一起完善？ 在 GitHub 上编辑此页！
本页面贡献者：AI-PM Wiki Team
本页面的全部内容在 CC BY-SA 4.0 和 SATA 协议之条款下提供，附加条款亦可能应用