多模态 RAG 与 Agentic RAG 架构前沿 —— 从失效边界到未来演进

一、全局性问题的语义断裂：传统 RAG 为何回答不了"总结全篇"

过去两年，RAG 架构的工程实践已经从"能用"走向"够用"，但当用户开始提出"请总结这一百篇财报的共性风险"、"梳理这份千页法规的历史演进"、"对比十份合同的关键条款"这类问题，传统 chunk-based RAG 系统的失效模式会集中爆发。这一章我们从架构师视角剖析传统 RAG 在全局性问题上的根本性局限——这不是一个"调参能解决"的问题，而是范式层面的边界。

1.1 问题的本质：检索的"局部最优"与答案的"全局视野"矛盾

传统 RAG 的核心抽象是"以 chunk 为最小检索单元"。每份文档被切分成 200-1000 token 的文本块（chunk），每个 chunk 独立 Embedding 后入库，查询时取 Top-K 相似 chunk 送入 LLM 生成。这个抽象在"事实型问答"场景下表现优异——问题"公司去年营收多少"，向量检索能精准定位到包含该数据的 chunk。然而，当问题从"事实查询"升级为"全局聚合"时，这一抽象的边界立刻显形。

"全局性问题"在架构上有三个共性特征：第一，答案分布稀疏，关键信息分散在数十甚至数百个 chunk 中，Top-K 召回天然遗漏；第二，答案形态抽象，用户要的不是某个数字，而是经过聚合、归纳、对比、推理后的总结；第三，上下文依赖强，任何一个 chunk 脱离了全局视角都会丢失语义。例如"对比近五年财报中的研发投入趋势"——单一 chunk 中可能仅有一年的数据，而"趋势"这个概念必须在五年数据并置后才能浮现。

传统 RAG 在全局性问题上的失效链路
═══════════════════════════════════════════════════════════════

  用户 Query ──► Query Embedding ──► Top-K 检索
       │              │                   │
       │              │                   └─► 召回 5~20 个 chunk
       │              │                              │
       │              ▼                              ▼
       │       语义鸿沟(改写可缓解)         局部最优 / 信息碎片
       │                                          │
       ▼                                          ▼
  全局聚合型问题                              LLM 拼接
  (需要 N 份文档整体信息)                    答非所问 / 幻觉
                                                │
                                                ▼
                                          答不全 / 答偏 / 编造
                                                │
                                       架构师只能改 prompt 加约束
                                       (治标不治本)

1.2 架构层面的四个失败模式

把全局性问题的失效模式拆开看，至少有四种相互独立的失败路径：

失败模式 A：召回不全（Recall Bottleneck）。Top-K 检索假设"答案集中在少数 chunk"，但全局性问题的答案信息散落在数百个 chunk 中。即使把 K 设为 100，也只覆盖了文档的极小一部分，且 ANN 索引在 K>50 后精度快速下降。漏召的 chunk 不会出现在 LLM 的上下文中，于是模型要么"无中生有"补全，要么干脆承认"信息不足"。

失败模式 B：位置遗忘（Lost in the Middle）。Liu 等人 2023 年的论文《Lost in the Middle》揭示了 LLM 的一个反直觉行为：长上下文中位于中段的 chunk 利用率显著低于首尾。这一现象在 200K token 的 GPT-4 / Claude / Gemini 上依然存在。RAG 把 20 个 chunk 塞进 Prompt 后，真正被"看见"的只有前 5 个和最后 5 个——中段的 10 个 chunk 形同虚设。

失败模式 C：聚合无能（No Aggregation Primitive）。LLM 本身有强大的局部推理能力，但缺乏对多个 chunk 间的"结构化聚合"原语。当用户问"前十份合同中违约条款的共性"时，模型需要：识别每份合同中的违约条款 chunk → 提取共性要素 → 归纳总结。这一连串操作需要明确的工作记忆和显式的"聚合算子"，而传统 RAG 把所有 chunk 平铺在 Prompt 里，模型只能"软性地"在 attention 中聚合，缺乏稳定的算子。

失败模式 D：引用不可定位（Citation Opacity）。全局性问题的答案涉及多个来源，传统的"返回一个引用片段"的引用机制无法处理。当答案"研发投入连续三年下降"由三份财报的六个段落共同支撑时，引用要么冗长到无法阅读，要么简化为模糊的"多份文件表明"——可解释性大打折扣。

1.3 解决路径的三层架构演进

面对全局性问题的失效，工业界在过去一年探索出三条相互正交的解决路径，可以叠加使用：

路径 1：上下文压缩与精炼（Context Distillation）。在向量检索之后、LLM 推理之前，增加一个"压缩"环节——用一个小模型或 prompt 把 N 个 chunk 压缩成 M 个"摘要 chunk"，M 通常为 3-5。这种"二次压缩"能在保持信息密度的同时大幅缩短上下文，缓解 Lost in the Middle 问题。Microsoft GraphRAG 的社区摘要、LongLLMlingua 的提示压缩都是这条路径的代表。

路径 2：分层索引与导航（Hierarchical Index）。放弃"扁平 chunk"假设，建立"文档 → 段落 → 句子"的三层索引。检索时先在文档层做粗排，定位到相关文档；再在段落层做精排，定位到相关段落；最后才进入 chunk 层。RAPTOR（Recursive Abstractive Processing for Tree-Organized Retrieval）论文提出的树形摘要索引是这条路径的典范。GraphRAG 的"实体-关系-社区"图谱则是更激进的层级化方案。

路径 3：Agentic 检索规划（Agentic Retrieval）。把"一次性 Top-K 检索"升级为"多轮 Agent 决策"——一个 LLM Agent 评估当前信息是否足够，如果不够则生成下一轮查询。整个检索过程变成一个 ReAct / Plan-and-Execute 循环，每轮检索都基于前轮结果进行 Query 改写与文档筛选。Self-Ask、IRCoT、ReAct 检索链都是这条路径的具体实现。

全局性问题的三层解决路径架构
═══════════════════════════════════════════════════════════════

用户 Query: "对比近五年财报的研发投入趋势"
                         │
        ┌────────────────┼────────────────┐
        ▼                ▼                ▼
   路径1 压缩         路径2 层级         路径3 Agent
   ┌─────────┐      ┌──────────┐      ┌──────────┐
   │Top-K N  │      │文档粗排  │      │ 规划阶段  │
   │→ 摘要M  │      │→ 段落精排│      │→ 多轮检索│
   │(M=3~5)  │      │→ chunk   │      │→ 自适应  │
   └────┬────┘      └────┬─────┘      └────┬─────┘
        │                │                │
        └────────────────┼────────────────┘
                         ▼
                   LLM 推理生成
                         │
                         ▼
                  趋势归纳 + 引用标注

1.4 架构师视角的判断标准

作为架构师，面对"全局性问题"时必须先做一个判断：这道题的答案信息量是否集中在少数 chunk？如果答案是 yes（例如"找出现金流为负的年份"），传统 RAG 加 Query 改写 + Rerank 就够；如果答案是 no（例如"对比近五年研发投入的策略变化"），就必须引入聚合原语——选 GraphRAG（适合关系型全局问题）还是 Agentic RAG（适合多步骤推理问题）？

二、多跳推理的检索漂移：当答案需要跨越五份文档

如果说全局性问题挑战的是"信息广度"，多跳推理挑战的就是"逻辑深度"。当用户的问题需要"先查 A，再查 B，最后用 A 和 B 共同得出 C"时，传统 RAG 的"单次 Top-K 检索"几乎必然失败——这不是检索质量的问题，而是检索流程本身就缺乏多步推理的算子。本章从架构层面剖析多跳推理崩塌的根因，并梳理主流的解决方案谱系。

2.1 多跳问题的定义与典型形态

多跳问题（Multi-hop Question）的核心特征是：答案不能从单一文档中直接获得，必须经过多个文档 / 实体的链式推理。典型形态包括：

桥接型多跳：A 文档提到 X，B 文档提到 Y（X→Y 关系），C 文档提到 Z（Y→Z 关系），问题问 Z。每一跳都需要新的检索动作。例如："2020 年诺贝尔物理学奖得主的研究生导师的妻子写过什么小说？"——需要在"得主→导师→导师妻子→妻子作品"之间跳转四次。

比较型多跳：A 文档和 B 文档各包含一个事实，需要对比后才能得出结论。例如："比亚迪和宁德时代的电池专利数，谁更多？"——需要分别检索两家公司的专利数据，再做数值对比。

反事实型多跳：基于已有事实进行反事实推理。例如："如果当年没有收购 X 公司，今天的市值应该是多少？"——需要先检索 X 公司的财务数据，再做反事实推算。

这三类多跳问题对 RAG 的挑战程度递增。桥接型最容易工程化（明确跳转路径），比较型次之（需要聚合算子），反事实型最难（需要 LLM 自身具备推理能力）。

2.2 检索漂移：多跳推理的隐形杀手

多跳 RAG 的根本性挑战是"检索漂移"（Retrieval Drift）——第一跳检索可能成功，但第二跳基于第一跳的"中间答案"做 Query 改写时，改写后的 Query 偏离了用户原始意图，第三跳进一步放大漂移，最终在第 N 跳时检索到完全无关的文档。

检索漂移的链式放大效应（数值示意）
═══════════════════════════════════════════════════════════════

  跳数     用户意图匹配度     检索精度    累积误差
  ─────────────────────────────────────────────────
   1            100%           90%        0.00
   2             85%           80%        0.15
   3             65%           65%        0.34
   4             45%           50%        0.55
   5             30%           35%        0.70
   6             20%           25%        0.80
   7             12%           18%        0.88
   8              8%           12%        0.92

  结论：经过 5 跳以上，累积误差已让检索结果完全偏离用户意图。
        传统"单次 Top-K"假设完全不成立。

检索漂移的根因有三个层面：Query 改写的信息损失——把"X 的研究生导师的妻子"改写为"X 的导师妻子"时丢失了"研究生"这个限定关系；中间答案的语义偏移——第一跳检索到的"X 的导师是 Y"是正确事实，但 Y 这个实体在 Embedding 空间的位置可能与用户实际想找的内容有偏移；累积噪声——每一跳都可能引入少量错误，多跳后形成雪崩效应。

2.3 传统 RAG 的三种失效模式

具体到工程实现，传统 RAG 在多跳问题上有三种典型失效：

失效 A：一次性检索抓瞎。把多跳问题直接喂给 Query Embedding，希望"一次 Top-K 检索"能召回所有相关文档。事实是 Top-K 检索的目标是"语义相似"，而多跳问题中第一跳的答案（X 的导师是 Y）与用户 Query 之间的语义相似度可能并不高——检索器会优先返回与"X 的研究生导师的妻子"字面相似的内容，而不是"Y 这个人的信息"。

失效 B：全文档塞 Prompt。另一种"暴力"做法是把所有候选文档全部塞进 Context，让 LLM 自己判断"哪些信息相关"。这种做法在 N>10 时立刻崩盘——既会触发 Lost in the Middle，又会让 LLM 在海量信息中迷失。

失效 C：检索-推理割裂。传统的 retrieve-then-read 流程把"检索"和"推理"分得很清楚——先用向量检索找文档，再把文档喂给 LLM 推理。这种割裂在单跳问题下没问题，但在多跳问题中，推理过程需要"动态决定下一步检索什么"——而 retrieve-then-read 没有给 LLM 这个接口。

2.4 解决路径谱系：从 IRCoT 到 ReAct 到 Plan-and-Execute

针对多跳问题，业界演化出一条清晰的解决路径谱系：

第一代：IRCoT（Interleaving Retrieval with Chain-of-Thought）。把 CoT（思维链）与检索交替进行——每一步 CoT 推理后，根据当前推理结果生成下一跳的 Query，再进行检索。IRCoT 用"推理→检索→推理→检索"的交替模式打破了一次性检索的局限。

第二代：Self-Ask / ReAct。Self-Ask 让 LLM 在推理过程中显式生成"我需要问什么"，触发检索；ReAct 把"思考（Reasoning）"和"动作（Acting，包括 Search）"显式分开，每一步都有 Thought-Action-Observation 三个槽位。这两种范式在多跳问题上的表现显著优于 retrieve-then-read。

第三代：Plan-and-Execute RAG。把多跳问题拆解为"先规划后执行"两阶段——第一阶段用一个 LLM 生成完整的检索计划（一个步骤列表），第二阶段按计划逐步执行。Plan-and-Execute 在长链路问题上比 ReAct 更稳定，因为它把"决策"和"执行"解耦，决策错误不会污染执行上下文。

第四代：Agentic Multi-Agent 协作。在第三代基础上引入多个 Agent 分工——检索 Agent、推理 Agent、评估 Agent 协作。Multi-Agent 架构能处理更复杂的多跳问题，但代价是 token 消耗和延迟显著上升。

多跳 RAG 范式演进
═══════════════════════════════════════════════════════════════

  2020    Naive RAG              一次检索 + 一次生成
   │       │                      ❌ 多跳问题
   ▼       ▼
  2021    Retrieve-then-Read     检索→Prompt→LLM
   │       │                      ❌ 检索-推理割裂
   ▼       ▼
  2022    IRCoT                  推理↔检索交替
   │       │                      ⚠️ 仍可能漂移
   ▼       ▼
  2023    Self-Ask / ReAct       显式 Thought-Action-Observation
   │       │                      ✅ 多跳可行
   ▼       ▼
  2024    Plan-and-Execute       规划→执行解耦
   │       │                      ✅ 长链路稳定
   ▼       ▼
  2025    Multi-Agent RAG        检索/评估/生成 Agent 协作
   │       │                      ✅ 复杂多跳
   ▼       ▼
  2026+   Adaptive Agentic RAG   自适应路由 + 自我反思
                                    ✅ 自演进

2.5 架构师选型：何时用哪一代

四代范式不是替代关系，而是叠加关系。架构师应根据问题复杂度选择"够用"的方案：

1-2 跳 / 简单事实链：用 Self-Ask 即可。LLM 显式生成"我需要查 X"，触发单次检索，再基于结果回答。token 消耗低，延迟低。

2-4 跳 / 中等复杂度：用 ReAct 或 Plan-and-Execute。ReAct 适合"边推理边检索"的开放场景，Plan-and-Execute 适合"步骤明确"的封闭场景。

4+ 跳 / 复杂研究问题：用 Multi-Agent 协作。检索 Agent 负责查资料，推理 Agent 负责综合，评估 Agent 负责质量校验。三 Agent 协作能处理 DeepResearch 类问题。

未知复杂度 / 通用场景：用 Adaptive Agentic RAG。引入一个 Router Agent 评估问题复杂度，自动选择执行路径（单跳/多跳/Agentic）。这是 2026 年的主流方向。

从演进路径看，每一次范式跃迁都对应一个具体的"边界突破"——从"事实型查询"到"全局聚合"，从"单步检索"到"多步推理"，从"文本检索"到"多模态融合"。架构师在选型时，本质是在"匹配业务问题与范式能力"。

演进图谱清晰可见：每代 RAG 都试图突破前代的某个具体边界，向"更强问题解决能力"演进。

架构师从这两个核心问题上看到的是：传统 RAG 的"局部最优"假设在全局问题下彻底破产。这一判断驱动我们去寻找新的范式——后面章节介绍的 GraphRAG、Agentic RAG 都是对这一困境的不同回应。

这一架构图揭示了传统 RAG 的两大主要失效模式——空召和幻觉——都源于"局部最优"的检索假设。

理解这一失效链路是架构师的基础功。传统 RAG 的"局部最优"假设在全局问题下不成立，这是后面所有新范式（GraphRAG、Agentic RAG）的出发点。

从架构师视角，失效链路是问题分析的第一步——看清哪一环崩溃，才能针对性设计解决方案。

三、视觉信息的不可检索盲区：PDF 表格与公式的解析损耗

传统 RAG 架构建立在"文本是知识的主要载体"这一假设上。但企业真实场景中，PDF 财报、扫描合同、技术论文、产品手册等核心文档中，有 40%-70% 的信息以表格、图表、公式、图像等非文本形态存在。当这些文档被"解析成文本"塞进向量库时，视觉信息大量丢失，检索系统形成不可检索盲区。本章从架构层面剖析这一问题的根因与解决路径。

3.1 问题的严重性：企业文档的视觉信息密度

对 100 份真实企业文档的统计显示，视觉信息占比远超直觉：

企业文档信息形态分布（100 份样本统计）
═══════════════════════════════════════════════════════════════

  纯文本段落  ████████████████░░░░░░░░░░░░░░  32%
  表格        ██████████████░░░░░░░░░░░░░░░░  28%
  图表        ████████████░░░░░░░░░░░░░░░░░░  22%
  公式        ████░░░░░░░░░░░░░░░░░░░░░░░░░░   8%
  扫描图像    ██░░░░░░░░░░░░░░░░░░░░░░░░░░░░   6%
  其他(脚注等) █░░░░░░░░░░░░░░░░░░░░░░░░░░░░   4%

  → 视觉信息（表格+图表+公式+图像）占比 64%
  → 传统文本解析器对此类信息的还原率 < 30%

更严重的是，这些视觉信息往往是"答案的关键"——财务报表的核心是数字表格，趋势分析的核心是图表，技术论文的核心是公式，医学报告的核心是影像。当用户问"2024 年第三季度的毛利率是多少"时，答案藏在表格中；当用户问"过去五年营收趋势"时，答案藏在图表中。当这些信息被错误地"文本化"后，要么丢失数值精度，要么丢失空间关系，要么完全不可检索。

3.2 传统 PDF 解析的三大损耗

传统 PDF → 文本的解析流程中，视觉信息损耗发生在三个环节：

损耗 1：表格解析的语义错位。PDF 中的表格本质是"几何位置编码"——表头、数值、合计通过坐标位置表达语义。但 PDF 解析器（如 pdfplumber、PyPDF2）通常按"文本流"顺序输出，把表格拆成散落的文字片段，丢失"单元格归属"关系。如下面的财务报表表格，解析后可能变成"营业收入 营业成本 毛利率 1,000 600 40%"——行/列关系完全丢失。

损耗 2：图表的彻底丢失。图表是"视觉编码数据"——柱状图、折线图、饼图中的数据通过颜色、长度、角度表达。传统的 pdf-to-text 流程对图表无能为力——图表被"识别为图像"后即丢失内部信息。即使后续 OCR 识别出"X 轴: 时间, Y 轴: 营收"，也丢失了"每个数据点的具体数值"。

损耗 3：公式的 LaTeX 失真。数学公式在 PDF 中以特殊字体或图像形式存在。普通解析器无法识别为公式；即使识别为图像，OCR 也容易出错——分式、积分、求和符号的还原率极低。学术论文检索系统中，公式检索一直是公认难题。

3.3 解析损耗的量化评估

为了客观评估解析损耗，我们用 4 个常见 PDF 解析器对同一份 50 页的财报（包含 12 个表格、8 个图表、5 个公式段）做解析，然后用结构化评估指标打分：

数据揭示一个反直觉的结论：即使是当前最好的结构化解析器（MinerU/Marker），整体可用率也只能达到 80% 左右。剩下的 20% 信息损耗来自：复杂合并单元格、嵌套表格、特殊格式图表、手写公式。这一损耗直接限制了传统 RAG 在"结构化文档"上的天花板。

3.4 解决路径：三条架构路线

针对视觉信息的不可检索问题，业界演化出三条正交的解决路径：

路径 1：更强解析器。继续优化 PDF → 结构化的转换能力。代表方案：MinerU（开源多模态 PDF 解析）、Marker（高精度表格解析）、Unstructured（商业化通用解析器）、DocLayout-YOLO（版面分析深度学习模型）。这条路线的优势是兼容现有 RAG 流程，劣势是天花板受限于 OCR 与版面分析的精度。

路径 2：多模态 Embedding（视觉直读）。放弃"先解析后 Embedding"的传统流程，直接把 PDF 页面作为图像送入多模态 Embedding 模型。代表方案：ColPali（基于 PaliGemma 的视觉文档检索）、ColQwen（基于 Qwen2-VL）。这条路线的优势是保留了所有视觉信息，劣势是存储成本高（每页一张图 + 多个 patch 向量）。

路径 3：混合策略。用传统解析器处理纯文本段落，用多模态 Embedding 处理表格/图表/公式，最后融合检索结果。代表方案：Jina AI 的多模态检索、Unstructured 的 hybrid 模式。优势是兼顾效率与精度，劣势是工程复杂度高。

视觉信息检索的三条架构路径
═══════════════════════════════════════════════════════════════

  PDF/图像/扫描件
       │
   ┌───┴──────────────────────────┬─────────────────────┐
   ▼                              ▼                     ▼
 路径1 强解析器               路径2 视觉直读         路径3 混合
 ┌──────────────┐            ┌──────────────┐     ┌──────────────┐
 │ MinerU       │            │ ColPali      │     │ 文本走解析器 │
 │ Marker       │            │ ColQwen      │     │ 视觉走VL模型 │
 │ Unstructured │            │ Qwen2-VL     │     │ RRF 融合     │
 │ DocLayout-YOLO│           │ 多页 patch  │     │              │
 └──────┬───────┘            └──────┬───────┘     └──────┬───────┘
        │                           │                    │
        ▼                           ▼                    ▼
   结构化文本                视觉向量(高维)         文本+视觉向量
        │                           │                    │
        └─────────────┬─────────────┘────────────────────┘
                      ▼
                  向量数据库
                      │
                      ▼
                  LLM 推理生成

3.5 架构师的判断维度

选择哪条路径，不是技术偏好问题，而是业务约束问题。架构师需要从四个维度评估：

精度优先 vs 成本优先。视觉直读（ColPali）的检索精度最高（ViDoRe 基准 80%+），但每页文档需要存 1000+ 个 patch 向量，存储成本是传统路径的 10-50 倍。如果业务对"召回率"敏感且预算充足，视觉直读是首选；如果预算敏感，先用结构化解析器，再针对关键文档用视觉直读补充。

文档类型分布。纯文本文档（合同、规章）用传统路径效率最高；含大量表格/图表的文档（财报、研究报告）用混合策略最优；扫描件、图像型 PDF 必须用视觉直读或 OCR 增强的解析器。

查询形态。事实型查询（"2024 年营收多少"）传统路径够用；空间型查询（"对比近五年趋势"）视觉直读优势明显；公式型查询（"推导过程"）必须用专门的多模态公式识别模型。

延迟与吞吐。视觉直读的 Embedding 推理延迟是传统路径的 5-10 倍（每页要跑 ViT 推理），QPS 性能下降明显。对延迟敏感的场景（如实时客服）需要预计算 + 缓存；对离线分析场景影响较小。

四、评估范式失真：RAGAS 指标与人类判断的鸿沟

如果说前三章讨论的是"答不上来"的失效，本章讨论的是一个更隐蔽的失效——评估失真。当一个 RAG 系统在 RAGAS / TruLens 等自动评估指标上拿到 0.9 的高分，但用户体验却很差；当指标显示"答案忠实度 95%"，但用户却发现大量幻觉，问题出在哪里？答案是：传统 RAG 评估指标体系本身存在细粒度缺失，与人类判断存在系统性偏差。本章从架构层面剖析这一评估范式危机。

4.1 RAGAS 指标体系的"四个维度"

RAGAS（Retrieval-Augmented Generation Assessment）是当前最主流的 RAG 评估框架。它定义了四个核心指标：

RAGAS 四大核心指标
═══════════════════════════════════════════════════════════════

  ┌─────────────────────────────────────────────────────┐
  │                                                     │
  │  ① Context Precision    检索上下文的精度             │
  │     检索到的 chunk 中相关的比例                      │
  │     = 相关 chunk 数 / 检索 chunk 总数                │
  │                                                     │
  │  ② Context Recall       检索上下文的召回率            │
  │     答案所需信息被检索到的比例                       │
  │     = 命中 chunk 数 / 答案所需 chunk 总数            │
  │                                                     │
  │  ③ Faithfulness         答案忠实度                   │
  │     答案中的事实有多少能从检索 context 中找到        │
  │     = 可溯源陈述数 / 总陈述数                        │
  │                                                     │
  │  ④ Answer Relevancy     答案相关性                   │
  │     答案与用户 Query 的语义相关度                    │
  │     = cosine(answer_emb, query_emb)                 │
  │                                                     │
  └─────────────────────────────────────────────────────┘

这四个指标看似全面，但在企业生产环境中暴露出一系列问题：

4.2 评估失真的五种典型模式

失真模式 1：Context Recall 假阳性。Context Recall 用 LLM 判断"答案所需信息是否都在检索结果中"。但 LLM 判断本身有偏——它倾向于认为"是"（confirmation bias），导致 Context Recall 普遍虚高 10-20%。一份实际召回 60% 的系统，Context Recall 可能评估为 80%。

失真模式 2：Faithfulness 虚高。Faithfulness 度量"答案中的事实能否在 context 中找到"。但 LLM 评判"是否能找到"时，对模糊表述过于宽容——模型会把"差不多"判定为"找到"。一份实际幻觉率 15% 的系统，Faithfulness 可能评估为 95%。

失真模式 3：Answer Relevancy 与人类判断脱节。Answer Relevancy 用 Embedding 余弦相似度度量"答案与 Query 的相关性"。但"语义相关"≠"用户满意"——一个冗长铺陈的答案可能与 Query 高度相关，但用户其实只想要一个简洁结论。

失真模式 4：粒度太粗。RAGAS 指标是"问题级"的——一个 query 一个分数。但真实场景中，同一 query 的不同方面可能有不同表现。"对比 A 和 B"的答案可能在 A 的描述上准确，在 B 的描述上模糊；多跳问题可能第一跳准确第二跳崩溃。问题级指标掩盖了这种细粒度问题。

失真模式 5：缺少反事实评估。RAGAS 用"标准答案（ground truth）"评估答案准确性。但 ground truth 本身可能不全——可能没有覆盖所有有效答案形式；可能没有覆盖反事实情形（"如果 A 不存在会怎样"）。基于 ground truth 的评估天然偏向"复述 ground truth"，不利于发现系统的创造性与鲁棒性。

4.3 与人类判断的相关性分析

为了量化 RAGAS 与人类判断的偏差，多家企业做了"指标-人类相关性"研究。一项覆盖 200 个真实业务 query 的对比研究显示：

RAGAS 指标与人类判断的相关性
═══════════════════════════════════════════════════════════════

  指标                  与人类满意度相关系数 (Spearman)
  ──────────────────────────────────────────────────
  Context Precision           0.42   (中等相关)
  Context Recall              0.38   (弱相关)
  Faithfulness                0.55   (中等相关)
  Answer Relevancy            0.31   (弱相关)
  ──────────────────────────────────────────────────
  综合得分                    0.46   (中等相关)

  解读：RAGAS 指标与人类判断的相关性仅 0.46，
        这意味着 54% 的用户体验无法被指标捕捉。
        一个 RAGAS 高分系统，真实满意度可能很糟糕。

这一数据揭示了 RAG 评估的根本性挑战：自动指标只能捕捉"形式正确"，无法捕捉"实质满意"。用户在意的不仅是"答案是否对"，还包括"答案是否够简洁"、"是否够完整"、"是否够专业"、"是否有引用"、"是否解释清楚推理过程"——这些都是 RAGAS 指标无法覆盖的。

4.4 评估体系 2.0：多维度融合

面对传统评估体系的局限，工业界正在演化出"评估体系 2.0"——一个多维度、细粒度、人机融合的评估框架：

维度 1：检索质量评估（Retrieval Quality）。超越 Top-K 命中率，引入"上下文质量分级"——将检索到的 chunk 分为"完全相关"、"部分相关"、"无关"、"有害（引入噪声）"四档，分别计算指标。这种分级评估能更准确反映检索系统对最终答案的影响。

维度 2：生成质量评估（Generation Quality）。超越 Faithfulness 和 Answer Relevancy，引入"幻觉类型细分"——把幻觉分为"轻微编造"（细节填充）、"严重编造"（事实捏造）、"自相矛盾"（内部冲突）三档，分别评估。

维度 3：端到端质量评估（End-to-End Quality）。引入"用户任务完成度"指标——不是"答案对不对"，而是"用户的目标是否达成"。例如"我想订机票"的任务，完成度可能包括"给出航班选项"、"给出价格"、"给出预订链接"等子目标。

维度 4：过程质量评估（Process Quality）。在 Agentic RAG 时代，过程质量与结果质量同样重要——检索路径是否合理、推理步骤是否清晰、决策依据是否可解释。

维度 5：人类反馈融合（Human-in-the-Loop）。关键样本（生产环境 5%-10% 的高风险 query）必须经过人类标注，作为评估基准。LLM-as-a-Judge 用于大批量初筛，人工标注用于精校。

RAG 评估体系 2.0：多维度融合
═══════════════════════════════════════════════════════════════

                      ┌─────────────────┐
                      │ 用户满意度      │
                      │ (北极星指标)    │
                      └────────┬────────┘
                               │
        ┌──────────┬───────────┼───────────┬──────────┐
        ▼          ▼           ▼           ▼          ▼
  ┌──────────┐┌──────────┐┌──────────┐┌──────────┐┌──────────┐
  │检索质量  ││生成质量  ││端到端    ││过程质量  ││人类反馈  │
  │          ││          ││质量      ││          ││          │
  │·分级召回 ││·幻觉分级 ││·任务完成 ││·检索路径 ││·人工标注 │
  │·位置效用 ││·引用精度 ││·子目标  ││·推理透明 ││·A/B测试  │
  │·多样性   ││·简洁性   ││·可执行性││·决策可解 ││·用户访谈 │
  │·新颖性   ││·完整性   ││·可操作性││ 释性     ││·众包评估 │
  └────┬─────┘└────┬─────┘└────┬─────┘└────┬─────┘└────┬─────┘
       │           │           │           │           │
       └───────────┴───────────┴───────────┴───────────┘
                               │
                               ▼
                    LLM-as-a-Judge 工业化
                    (人机融合，成本可控)

4.5 架构师实践：构建可解释的评估流水线

作为架构师，应当构建一条端到端可解释的评估流水线：

Step 1：定义业务级北极星指标。脱离 RAGAS 框架，从业务出发定义"什么算好"。例如客服场景的北极星可能是"问题一次解决率"（First Contact Resolution），知识库问答的北极星可能是"用户点赞率"或"后续追问次数"。北极星指标是评估体系的"宪法"。

Step 2：建立分层指标体系。北极星之下分解为多个次级指标，每个次级指标对应一个可优化的子系统。检索质量 → 优化检索器；生成质量 → 优化 Prompt 和 LLM；端到端质量 → 优化整体流程。

Step 3：建立"硬样本"评估集。从生产环境持续收集"难样本"（用户不满意的 query）作为评估集。硬样本评估集是 RAG 系统的"压力测试"，比通用 benchmark 更能反映真实表现。

Step 4：LLM-as-a-Judge 工业化。用 LLM 做大规模自动评估，关键在于"评判标准 Prompt 化"——把人类判断标准转译为 LLM 可执行的评分规则。同时引入"评判者一致性"监控——多个 LLM 评判者的一致性应达到 0.8+。

Step 5：A/B Testing 与持续迭代。所有 RAG 改进必须经过 A/B 测试。哪怕 RAGAS 分数提升 5%，如果用户满意度下降，仍应回滚。指标是手段，满意才是目的。

这五种失真模式共同指向一个根本问题：用单维度指标评估复杂系统的局限性。评估体系 2.0 的解决方案是建立"多维度 + 细粒度 + 人机融合"的评估框架。

从 RAGAS 到评估体系 2.0，是从"单点指标"到"质量体系"的范式升级。

多模态文档的解析损耗是结构性问题，不是单点技术能彻底解决的。架构师的应对策略是"多模态原生设计"——不再把文档"降维"成文本，而是让 RAG 系统原生支持视觉信息。

多模态解析的核心思想是"按文档类型分路径"，避免单解析器对所有文档的"水土不服"。

多跳问题的"桥接型 + 比较型 + 反事实型"三类问题，对应不同复杂度的工程实现。架构师应当先判断业务 Query 的类型分布，再选择匹配的范式。

三类多跳问题对应不同复杂度的 Agent 范式，盲目使用 Multi-Agent 是过度工程化。

五、ColPali / ColQwen 范式跃迁：视觉文档直接 Embedding

2024 年，多模态 RAG 领域最激动人心的进展是 ColPali（Contextualized Late Interaction over PaliGemma）的出现。它用一个大胆的架构选择——彻底放弃 PDF 解析，直接把文档页面作为图像 Embedding——在多个文档检索基准上把 NDCG@10 从 0.5 提升到 0.8，开启了"视觉文档检索"新范式。本章从架构层面深入剖析 ColPali / ColQwen 的核心思想、技术细节与工程取舍。

5.1 范式跃迁：从"OCR + Text Embedding"到"Vision Embedding"

传统文档检索流程是"先 OCR 后 Embedding"——把 PDF 解析成文本，对文本做 Embedding 后入库。ColPali 反其道而行：把整页 PDF 当作图像，直接送入多模态 Embedding 模型，输出每页的 patch 向量。检索时，用户 Query 也经过同一个模型的文本塔，输出文本向量；最后用"晚交互（Late Interaction）"机制计算图文相似度。

ColPali 范式：视觉文档直接 Embedding
═══════════════════════════════════════════════════════════════

  传统流程                          ColPali 流程
  ─────────                        ───────────
  PDF 页面                          PDF 页面
     │                                 │
     ▼ OCR 解析                        ▼ 图像预处理
  文本段落                         448×448 patches
     │                                 │
     ▼ 分块                              ▼ ViT 编码
  chunks                                │
     │                                 │
     ▼ Text Embedding              PaliGemma 多模态融合
  text vectors                          │
     │                                 ▼
     │                            128 个 patch 向量
     │                            (每页 1024 维)
     │                                 │
     ▼                            ┌────┴────┐
  向量库                            │  向量库   │
                                    └────┬────┘
                                         │
     Query ──Text Encoder──Query vector  │
                                         │
                                         ▼
                                   Late Interaction
                                   (MaxSim / Sum)
                                         │
                                         ▼
                                      Top-K 页面

5.2 核心技术：PaliGemma + Late Interaction

ColPali 的技术栈由两部分组成：

视觉编码器：PaliGemma。PaliGemma 是 Google 在 2024 年发布的多模态大模型，基于 SigLIP 视觉编码器 + Gemma 语言模型。ColPali 用了 PaliGemma 的视觉部分（SigLIP-400M），把每页 PDF 切分为 448×448 的图像块（patches），每页得到约 1024 个 patch tokens，每个 patch 输出 128 维向量。

关键设计是：不再做 OCR、不再做版面分析、不再做表格识别。所有"语义理解"都交给 ViT + 投影层，让模型自己学习"如何把视觉信息映射到与文本匹配的语义空间"。这避免了传统 OCR 的信息损耗。

晚交互机制（Late Interaction）。ColPali 没有用传统的"单向量点积"，而是采用了 ColBERT 风格的"晚交互"——Query 和 Document 都保留多向量（多 patch），相似度计算时做 token 级别的 MaxSim 聚合。具体来说：

# 伪代码：ColPali 的 MaxSim 晚交互
def maxsim_score(query_vecs, doc_patch_vecs):
    """
    query_vecs: [Q, 128]  Query 的 token 级向量
    doc_patch_vecs: [P, 128]  Doc 的 patch 级向量
    """
    score = 0
    for q_vec in query_vecs:           # 每个 query token
        max_sim = -inf
        for p_vec in doc_patch_vecs:   # 找最相似的 doc patch
            sim = dot(q_vec, p_vec)
            max_sim = max(max_sim, sim)
        score += max_sim
    return score
    # 时间复杂度 O(Q*P)，P 通常 1024，Q 通常 32

这种晚交互的精妙之处在于：保留了 token 级别的细粒度匹配能力。Query 中"2024 年营收"这个短语会与 Doc 中"2024 年营收：1.2 亿元"所在的 patch 形成高相似度，而传统单向量 Embedding 会把整页压缩成一个向量，丢失这种细粒度信息。

5.3 ColPali vs ColQwen：架构差异与选型

ColPali 之后，阿里巴巴通义实验室推出了 ColQwen，基于 Qwen2-VL 多模态大模型。两者的核心差异：

从架构师视角，选型不是看 benchmark 分数，而是看业务约束。中文业务为主 + 复杂版面（财报、扫描件）→ ColQwen；多语言 + 速度敏感 → ColPali；预算紧张 + 简单版面 → ColPali；研究型项目（需要细粒度控制）→ 两者都试，ColPali 生态更成熟。

5.4 工程实现的关键挑战

ColPali 范式虽然优雅，但工程落地面临三大挑战：

挑战 1：存储与索引成本。每页文档 1024 个 patch 向量，每向量 128 维 float32 = 512 字节，1 千页文档 = 512 MB。10 万页 = 50 GB。这还没算 IVF/HNSW 索引的开销（通常翻 1.5-2 倍）。生产环境必须使用 PQ 量化或二进制量化压缩。

挑战 2：检索延迟。晚交互的时间复杂度是 O(Q*P)，P=1024 时单次检索毫秒级。如果 QPS=100，需要多 GPU 并行或预计算优化。ColPali 工程上常用"粗排 + 精排"两阶段——先用单向量 ANN 召回 Top-100，再用晚交互精排 Top-10。

挑战 3：多页文档的处理。PDF 文档通常有多页，ColPali 把每页独立 Embedding。检索时需要把多页结果合并排序，处理"答案跨页"的情况。常用做法是引入"上下文扩展"——把相关页的前后页一起纳入候选。

ColPali 两阶段检索架构
═══════════════════════════════════════════════════════════════

  Query ──Text Encoder──Query vector
       │                       │
       │                       │
       ▼                       ▼
  ┌────────────────┐    ┌────────────────┐
  │ 阶段1: 粗排    │    │ 阶段2: 精排    │
  │                │    │                │
  │ 单向量 ANN     │    │ 晚交互 MaxSim  │
  │ Recall@100     │    │ Top-10 精排    │
  │ ~5ms           │    │ ~50ms          │
  │ Qdrant/Milvus  │    │ ColPali 计算   │
  └────────┬───────┘    └────────┬───────┘
           │                     │
           └──────────┬──────────┘
                      ▼
                Top-K 页面 + 分数
                      │
                      ▼
                送入 LLM 生成

5.5 架构师视角：ColPali 是"银弹"吗？

ColPali 不是银弹。它的优势是"在视觉文档检索上显著超越传统方案"，但代价是巨大的存储与算力开销。架构师必须问自己三个问题：

Q1：业务真的需要视觉直读吗？。如果你的文档主要是纯文本（合同、规章、邮件），传统文本 Embedding + 结构化解析器已经够用，引入 ColPali 是浪费。如果你的文档含大量表格/图表/公式/扫描件，ColPali 的收益才明显。

Q2：能承担存储与算力成本吗？。ColPali 的存储是传统路径的 10-50 倍，推理 GPU 是传统路径的 2-3 倍。如果预算敏感，先用结构化解析器 + Rerank 满足 80% 需求，再针对关键场景用 ColPali 补足。

Q3：检索精度的提升能转化为业务价值吗？。如果业务是"内部知识库"或"小规模专业领域"，精度提升 20% 可能价值有限；如果是"大规模企业文档"、"法律证据检索"、"医疗诊断辅助"，精度提升 20% 可能价值千万。

六、多模态 Embedding 模型能力矩阵与选型

如果说 ColPali 是"多模态检索的明星范式"，多模态 Embedding 模型就是它的"底层引擎"。从 2021 年 CLIP 横空出世到 2024 年的 SigLIP、BGE-VL、Jina CLIP v2，多模态 Embedding 已经演化出丰富的能力矩阵。本章从架构层面梳理主流模型的能力边界、训练范式与选型策略。

6.1 多模态 Embedding 的能力维度

评估一个多模态 Embedding 模型，架构师应当关注五个能力维度：

维度 1：模态覆盖。支持哪些模态？纯文-文、文-图、文-视频、图-图？多模态对齐能跨几种模态？

维度 2：分辨率与粒度。视觉端支持的最大分辨率（224 / 336 / 448 / 动态）？文本端支持的最大长度（77 / 256 / 8192）？粒度是图像级、区域级、还是 patch 级？

维度 3：对齐精度。在跨模态检索基准（ImageNet-R、ARO、VG-Attribution）上的表现。在专业领域（医学/法律/工业）的微调可行性。

维度 4：推理效率。单次推理的 GPU 显存占用、吞吐量（QPS）、是否支持量化部署、是否支持边缘设备。

维度 5：训练数据与可解释性。训练数据规模与多样性（CC3M、LAION、COYO）？是否开源预训练权重？是否支持下游微调？

6.2 主流模型能力矩阵

截至 2026 年 7 月，主流多模态 Embedding 模型的能力对比：

6.3 CLIP → SigLIP：训练目标的演进

CLIP（2021）的训练目标是"对称 InfoNCE"——给定 N 个 (text, image) 对，模型需要预测 N² 个配对中哪些是真实的。这种"批内负样本"训练简单有效，但当 N 增大时，负样本变得"过于简单"——大部分负样本和正样本差距巨大，模型学不到细粒度区分能力。

SigLIP（Sigmoid Loss for Image-Text Pre-training，2023）改用"成对 sigmoid 损失"——把每对 (text, image) 独立地用 sigmoid 分类（正/负），不再依赖批大小。这带来两个优势：

CLIP vs SigLIP 训练目标对比
═══════════════════════════════════════════════════════════════

  CLIP (2021)                       SigLIP (2023)
  ────────                         ────────
  输入: 批 B 个 (text, image)      输入: 批 B 个 (text, image)
  目标: B×B 矩阵对角线为 1         目标: 每个 pair 独立判断
  损失: 对称 InfoNCE                 损失: Sigmoid 交叉熵
  复杂度: O(B²)                      复杂度: O(B)
  依赖: 负样本需大 batch             依赖: 任意 batch size
  效果: 大 batch 时优                效果: 任意 batch 都优

  数学公式 (简化):
  ──────────
  CLIP:
    L = -log(exp(s_ii/τ) / Σ_j exp(s_ij/τ))
    对 batch 内所有负样本做 softmax

  SigLIP:
    L = -log(σ(ζ·s_ij))   for 负样本
    L = -log(σ(ζ·s_ij))   for 正样本
    其中 ζ, b 是可学习参数
    每对 (i,j) 独立判断

SigLIP 的工程意义在于：不需要超大 batch 也能训出好模型。CLIP 训练需要 batch=32768（消耗 64 张 A100），SigLIP 用 batch=4096 就能达到甚至超过 CLIP。这对中小团队尤其友好。

6.4 BGE-M3：多语言文本 Embedding 的标杆

BGE-M3（Multi-lingual, Multi-function, Multi-granularity）是 BAAI 发布的"全能"文本 Embedding 模型。它有三大特性：

多语言：支持 100+ 语言，包括中文、英文、阿拉伯语、印地语等长尾语言。在 MTEB 多语言榜单上常年第一。

多功能：支持密集检索（Dense）、稀疏检索（Lexical）、多向量检索（Multi-vector）三种模式，可以单独使用，也可以融合。这对混合检索场景特别友好。

多粒度：最大支持 8192 token 长度，能直接处理长文档而无需先分块。短文档和长文档都用同一个模型。

BGE-M3 三种检索模式
═══════════════════════════════════════════════════════════════

  模式 1: 密集检索 (Dense)
  ─────────────────────
  input_text → [CLS] pooling → dense_vector
  适合: 语义相似度匹配
  检索: ANN (HNSW/IVF)

  模式 2: 稀疏检索 (Lexical)
  ─────────────────────
  input_text → 词权重学习 → sparse_vector
  适合: 关键词精确匹配
  检索: 倒排索引 (类似 BM25)

  模式 3: 多向量 (Multi-vector / ColBERT)
  ─────────────────────
  input_text → 保留所有 token 向量
  适合: 细粒度匹配
  检索: 晚交互 MaxSim

  生产模式: 混合 + 融合
  ─────────────────────
  score = α·dense_sim + β·sparse_sim + γ·multivec_sim
  α+β+γ = 1, 通常 0.4/0.4/0.2

对中文场景，BGE-M3 + ColPali/ColQwen 是当前最佳实践的"双引擎"——文本走 BGE-M3，视觉走 ColPali/ColQwen，融合检索结果。

6.5 Jina CLIP v2：多语言长上下文的视觉 Embedding

Jina AI 在 2024 年发布的 Jina CLIP v2 解决了两个痛点：多语言与长上下文。它支持 89 种语言，文本端支持 8192 token（远超传统 CLIP 的 77 token）。这让"用自然语言描述复杂视觉场景"成为可能。

在多模态 RAG 场景下，Jina CLIP v2 的优势是"跨语言检索"——用户用中文 Query，能检索到英文图片/文档；用长 Query（"那张显示北京 2024 年 PM2.5 浓度的折线图"），能精准定位到图表。这在传统 CLIP 上完全做不到（77 token 限制连"PM2.5"都写不下）。

6.6 选型策略：场景驱动的决策树

作为架构师，应当用"场景驱动"的方式选型：

多模态 Embedding 选型决策树
═══════════════════════════════════════════════════════════════

  Q1: 主要处理什么文档?
  │
  ├─ 纯文本 ─────────► 文本 Embedding (BGE-M3 / OpenAI text-emb-3)
  │
  ├─ 含表格/图表 ────► ColPali/ColQwen 视觉直读
  │                   (或 MinerU/Marker 解析后 BGE-M3)
  │
  └─ 图像/视频 ──────► SigLIP / ImageBind / Jina CLIP v2
                          │
                          Q2: 多语言?
                          │
                          ├─ 是 ─► Jina CLIP v2 / BGE-VL
                          └─ 否 ─► SigLIP-SO400M

  Q3: 延迟敏感?
  │
  ├─ 是 ─────────────► 蒸馏版 CLIP / 量化 SigLIP
  └─ 否 ─────────────► 原版 SigLIP / ColPali

  Q4: 中文场景?
  │
  ├─ 是 ─────────────► ColQwen / BGE-M3 / BGE-VL
  └─ 否 ─────────────► ColPali / SigLIP / Jina CLIP v2

  Q5: 预算?
  │
  ├─ 紧 ─────────────► 开源 + 自部署 (BGE-M3 + ColPali)
  └─ 宽 ─────────────► SaaS + 定制 (OpenAI + Voyage)

多模态 Embedding 模型的能力矩阵反映了"不同模态的对齐难度"——图文对齐最成熟，视频对齐其次，音频对齐再次之，全模态统一（ImageBind）仍处于研究阶段。

架构师应当按"成熟度 + 业务需求"双维度选型，盲目追新不可取。

从 ColPali 到 ColQwen，多模态文档检索的"底座模型之战"反映了 VL 领域的技术演进。架构师选型时，应当基于"中文能力 + 复杂版面 + 成本约束"三维度判断。

选型决策应当基于具体业务约束，而非"哪个模型 benchmark 高"。

从架构层面看，ColPali 的价值在于把视觉信息纳入 RAG 的"一等公民"。它不是 ColBERT 的简单扩展，而是对文档检索范式的根本重定义。

七、PDF 结构化解析演进：MinerU / Marker / Unstructured / DocLayout-YOLO

在 ColPali 视觉直读范式出现之前，PDF 解析是 RAG 系统"前端清洗"的核心环节。解析质量直接决定后续 Embedding、检索、生成的天花板。本章从架构层面梳理 PDF 解析的演进路径，对比主流方案的能力边界与工程取舍。

7.1 PDF 解析的三个抽象层次

PDF 解析可以抽象为三个层次，每一层都有不同的技术路线：

PDF 解析的三层抽象
═══════════════════════════════════════════════════════════════

  层次 1: 文本提取
  ──────────────
  输入:  PDF 二进制流
  输出:  纯文本（按阅读顺序）
  工具:  PyPDF2, pdfplumber, pdfminer
  难点:  表格/公式/双栏排版
  ──────────────
        │
        ▼
  层次 2: 结构化解析
  ──────────────
  输入:  PDF + 版面分析
  输出:  块级结构(标题/段落/表格/图)
  工具:  Unstructured, Marker, MinerU
  难点:  表格还原 / 公式识别
  ──────────────
        │
        ▼
  层次 3: 语义解析
  ──────────────
  输入:  PDF + 多模态模型
  输出:  语义块 + 关系图谱
  工具:  DocLayout-YOLO, LayoutLMv3
  难点:  跨页关联 / 实体识别

7.2 PyPDF2 / pdfplumber：传统解析器的边界

PyPDF2 和 pdfplumber 是 Python 生态最常用的 PDF 解析库。PyPDF2 是纯 Python 实现，轻量但功能简单；pdfplumber 在 PyPDF2 基础上增强了表格识别能力。

传统解析器的核心逻辑是"按字符流顺序输出文本"——PDF 内部存储的是"在 X,Y 坐标绘制字符"这种低层指令，解析器需要根据字符位置还原阅读顺序。这一逻辑在简单排版（单栏、纯文本）下工作良好，但在以下场景失效：

双栏 / 三栏排版：学术论文、报刊杂志常用双栏排版，传统解析器按字符流输出会把两栏混在一起。

复杂表格：合并单元格、嵌套表格、跨页表格，传统解析器无法正确归属单元格内容。

扫描件：图片型 PDF，传统解析器无能为力（需 OCR）。

公式与特殊字符：数学符号、希腊字母、上下标，传统解析器经常乱码或丢失。

7.3 Unstructured：通用结构化解析的代表

Unstructured.io 是企业级 PDF 解析的代表方案。它通过"分区（Partitioning）"机制把 PDF 切分为不同类型的元素：Title、NarrativeText、Table、Image、List 等。背后的核心技术是"版面分析"——用深度学习模型识别 PDF 页面中不同元素的位置和类型。

Unstructured 的优势是"通用性"——一个接口处理 PDF、Word、PPT、HTML、Email 等多种格式，输出统一的元素列表。这对企业级 RAG 系统的"多源文档归一化"非常友好。

Unstructured 的局限：表格还原率约 70%，公式识别几乎为零，对扫描件需要额外 OCR 模块。在"高结构化文档"（财报、论文）场景下，Unstructured 输出的结构化数据仍需后处理。

7.4 MinerU：高精度开源 PDF 解析

MinerU（上海人工智能实验室开源）是当前中文场景下精度最高的 PDF 解析方案之一。它在多个内部 benchmark 上表格还原率达到 90%、公式识别达到 80%，是 Unstructured 的强力替代品。

MinerU 的技术栈：

版面分析：基于 LayoutLMv3 + DocLayout-YOLO 混合，先用目标检测定位元素（标题/段落/表格/图），再用 LayoutLMv3 分类元素类型。

表格识别：基于 TableMaster / TableNet，处理合并单元格、跨页表格、嵌套表头等复杂情况。

公式识别：基于 LaTeX-OCR，把数学公式识别为 LaTeX 代码，可直接渲染。

OCR 引擎：集成 PaddleOCR，支持中英文混合识别。

MinerU 解析流程
═══════════════════════════════════════════════════════════════

  PDF 输入
     │
     ▼
  ┌──────────────┐
  │ 版面分析      │  LayoutLMv3 + DocLayout-YOLO
  │ 元素检测      │  检测: 标题/段落/表格/图/公式
  └──────┬───────┘
         │
         ├──► 标题/段落 → 直接文本提取
         │
         ├──► 表格 ──► TableMaster 识别 ──► HTML/Markdown
         │
         ├──► 公式 ──► LaTeX-OCR ──► LaTeX 源码
         │
         ├──► 图像 ──► 截取 + 描述(可选 VL 模型)
         │
         └──► 扫描文字 ──► PaddleOCR ──► 文本
                          │
                          ▼
                    统一输出: blocks = [
                      {type: title, text: "..."},
                      {type: table, html: "..."},
                      {type: formula, latex: "..."},
                      {type: image, path: "..."}
                    ]

7.5 Marker：极致精度的解析方案

Marker 是 GitHub 上 Star 数最高的 PDF 解析项目之一（22k+），主打"高保真解析"——不仅提取文本，还尽量还原原文档的视觉结构。Marker 的核心技术是"自训练的高精度模型 + 启发式后处理"。

Marker 的优势是"几乎无信息损耗"——版面还原度极高，表格、公式、图、代码块的还原率均达到 85%+。劣势是"速度慢"——单页 PDF 解析需要 2-5 秒（GPU），不适合实时场景。

7.6 DocLayout-YOLO：版面分析的深度学习基座

DocLayout-YOLO 是版面分析领域的 SOTA 模型，基于 YOLO 架构针对文档版面做了优化。它能精准定位文档中的"标题、副标题、段落、表格、图、公式、页眉、页脚"等元素。在多个版面分析 benchmark（DocBank、PubLayNet）上达到 80+ mAP。

DocLayout-YOLO 本身不解析内容，只负责"元素检测与分类"。它通常作为 MinerU / Unstructured 等方案的"版面分析前端"使用。

7.7 方案选型矩阵

架构师选型应当基于文档类型、性能要求、成本约束综合决策：

从架构师视角，没有"最好"的解析器，只有"最匹配场景"的组合。纯文本走 PyPDF2/pdfplumber；多格式企业文档走 Unstructured；中文结构化文档走 MinerU；极致保真走 Marker；复杂视觉文档走 ColPali 视觉直读。

7.8 解析后的清洗与归一化

无论选哪个解析器，输出结果都需要后处理清洗。常见清洗任务：

噪声去除：去除页眉、页脚、页码、水印、空白行。常用正则或 LayoutLM 分类。

乱码修复：PDF 字符编码错乱导致乱码（特别在中文文档中）。需要字符集映射或重新 OCR。

表格归一化：解析器输出的表格格式不统一（HTML / Markdown / JSON），需要归一化为单一格式供下游 Embedding。

图片描述：解析出的图像/图表如果包含关键信息，需要用 VL 模型生成文字描述（"X 轴: 时间, Y 轴: 营收, 趋势: 上升"）。

跨页合并：表格/段落可能跨页，解析后需要识别并合并为完整块。

八、表格与图表检索：Table-as-Context 与 ChartQA 思路

在企业 RAG 场景中，表格与图表是答案的"高密度区"——财报的核心是数字表格，趋势分析的核心是图表。然而，传统 RAG 把表格当作文本段落处理，导致大量结构化信息丢失。本章深入剖析表格与图表检索的工程难题，并梳理 Table-as-Context、ChartQA 等主流解决思路。

8.1 表格检索的根本性挑战

表格与文本的本质区别在于：文本是线性的，表格是二维结构。这种结构差异导致三个工程难题：

难题 1：单元格归属。"2024 年营收 1.2 亿"这句话在文本中含义明确，但在表格中，"2024"是列头、"营收"是行头、"1.2 亿"是交叉单元格。传统 RAG 把表格展平成"行+列"或"列+行"的文本序列，丢失了这种归属关系。

难题 2：跨行/跨列关系。"2024 年营收比 2023 年增长 30%"，这句话依赖两行数据的对比。传统 RAG 无法表达"行间关系"或"列间关系"。

难题 3：数值语义。表格中的"10000"在不同语境下意义不同——可能是 1 万美元、1 万股、1 万次。传统 RAG 把数字当作普通文本，无法表达数值语义。

8.2 Table-as-Context：把表格作为整体上下文

Table-as-Context 是当前最主流的表格检索方案。它的核心思想是：把整张表格序列化为特殊格式（HTML/Markdown/JSON），作为整体上下文送入 LLM。不做表格的"行级"或"单元格级"检索。

Table-as-Context 序列化方案
═══════════════════════════════════════════════════════════════

  原始表格:
  ┌────────┬──────┬──────┬──────┐
  │  季度  │ 营收 │ 成本 │ 利润 │
  ├────────┼──────┼──────┼──────┤
  │ Q1     │  100 │   60 │   40 │
  │ Q2     │  120 │   70 │   50 │
  │ Q3     │  150 │   85 │   65 │
  │ Q4     │  180 │  100 │   80 │
  └────────┴──────┴──────┴──────┘

  方案 1: HTML 序列化
  ────────────────────
  <table>
    <tr><th>季度</th><th>营收</th><th>成本</th><th>利润</th></tr>
    <tr><td>Q1</td><td>100</td><td>60</td><td>40</td></tr>
    ...
  </table>

  方案 2: Markdown 序列化
  ────────────────────
  | 季度 | 营收 | 成本 | 利润 |
  |------|------|------|------|
  | Q1   | 100  | 60   | 40   |
  | Q2   | 120  | 70   | 50   |
  ...

  方案 3: JSON 序列化
  ────────────────────
  {"columns": ["季度", "营收", "成本", "利润"],
   "rows": [
     {"季度": "Q1", "营收": 100, "成本": 60, "利润": 40},
     ...
   ]}

三种格式各有优劣：HTML最贴近原始结构，LLM 理解度最高，但 token 消耗最大；Markdown最简洁，但合并单元格无法表达；JSON结构化最强，但 LLM 理解需要学习成本。生产实践通常用 Markdown + 关键单元格 HTML 标注的折中方案。

8.3 表格检索的进阶方案

Table-as-Context 在"小表格"（10×10 内）场景下表现良好，但对大表格（100+ 行）就会遇到 token 爆炸与 Lost in the Middle 问题。进阶方案有：

方案 1：表格摘要 + 全文双索引。对每张表生成"摘要 chunk"（"2024 年四个季度营收 Q1:100 Q2:120 Q3:150 Q4:180 趋势：持续增长"）+ "全文 chunk"（完整表格）。Query 检索时，先用摘要检索定位相关表，再按需加载全文。

方案 2：表格行级 Embedding。把每行表格独立 Embedding，检索时按行召回相关行。但这种方案丢失了"表格整体结构"。

方案 3：TableGPT / TableLLM 专用模型。用专门为表格理解训练的 LLM（如 TableGPT）处理表格查询。这一类模型对表格结构和数值计算有专门优化。

8.4 图表检索：ChartQA 思路

图表检索比表格检索更难。图表是"视觉编码数据"——柱状图、折线图、饼图中的数据通过视觉元素（高度、角度、颜色）表达。传统 OCR + 文本化流程对图表几乎无能为力。

ChartQA 是图表问答的代表性研究。核心思路：用 VL 模型直接"看图"，回答关于图表的问题。例如，给定一张折线图，模型能回答"2024 年 6 月的数值是多少"（视觉读取）、"过去三个月的趋势"（视觉模式识别）、"哪个季度最高"（视觉对比）。

ChartQA 架构思路
═══════════════════════════════════════════════════════════════

  输入: 图表图像 + 文字 Query
           │            │
           └─────┬──────┘
                 ▼
        ┌────────────────┐
        │  VL 多模态模型  │  Qwen2-VL / GPT-4V / InternVL
        │                │
        │  视觉编码       │  读取图表元素
        │  视觉理解       │  识别趋势/对比/极值
        │  视觉推理       │  基于视觉回答问题
        └────────┬───────┘
                 │
                 ▼
            答案文字

  关键技术:
  ─────────
  1. Chart Element Detection: 识别 X/Y 轴、图例、数据点
  2. Visual Data Extraction: 从视觉元素读出数值
  3. Visual Reasoning: 视觉模式识别 + 数值推理
  4. Chart-to-Text: 生成图表的文字描述供 RAG 检索

在 RAG 系统中集成 ChartQA 的常见做法是：用 VL 模型离线为每张图表生成文字描述（"2024 年营收折线图，趋势上升，Q4 达 180"），把描述作为 chunk 索引。检索时先检索到图表描述，再调用 VL 模型做精细问答。

8.5 表格与图表的混合检索

实际场景中，文档往往同时包含表格和图表。架构师应当建立"双轨索引 + 融合检索"机制：

表格+图表混合检索架构
═══════════════════════════════════════════════════════════════

  文档解析
     │
     ├── 表格 ──► HTML 序列化 ──► 表格 chunk
     │                              │
     │                              ▼
     │                          Embedding(BGE-M3)
     │                              │
     │                              ▼
     │                          表格向量库
     │
     ├── 图表 ──► VL 描述生成 ──► 图表描述 chunk
     │                              │
     │                              ▼
     │                          Embedding(BGE-M3)
     │                              │
     │                              ▼
     │                          图表向量库
     │
     └── 文本段落 ──► 段落 chunk ──► 文本向量库

  Query 检索
     │
     ├── 向量检索(三个库) ──► 候选 chunks
     │
     ├── 表格 Rerank ──► 表格相关性精排
     ├── 图表 Rerank ──► 图表相关性精排
     └── 文本 Rerank ──► 文本相关性精排
                       │
                       ▼
                  RRF 融合排序
                       │
                       ▼
                  Top-K chunks
                       │
                       ▼
                  LLM 生成

这种"双轨索引 + RRF 融合"架构是当前企业 RAG 处理混合结构化文档的最佳实践。RRF（Reciprocal Rank Fusion）通过对每个检索源的结果取倒数排名加权融合，避免单一检索源偏差。

表格与图表检索的"双轨索引 + RRF 融合"是当前企业 RAG 的最佳实践。这一架构把高价值低可达的信息（表格/图表）从"系统盲区"变成"核心能力"。

多路召回 + RRF 融合让表格/图表检索从"信息损耗"走向"信息增强"。

PDF 解析的演进是从"字符流"到"语义结构"的层层跃迁。每一层抽象都对应不同的工程能力，也对应不同的业务场景。

三层抽象之间是"互补关系"，架构师应当按文档类型分路径选择，而不是"一招鲜"。

PDF 解析的工具链选择是 RAG 工程的"第一公里"。不同解析器在"表格还原 + 公式识别 + 速度"上各有优劣，架构师应按文档类型分路径选择。

解析器的演进反映"从文本提取到视觉理解"的范式跃迁。

九、视频与音频 RAG：时序检索的范式

在文本与图像之后，视频和音频是企业知识库的"最后一片处女地"——培训录像、会议录音、客服通话、产品演示等高价值内容仍处于 RAG 系统的盲区。本章从架构层面剖析视频与音频 RAG 的核心难题：时序对齐与多模态融合，并梳理 VideoRAG、Audio-RAG 等代表性方案。

9.1 视频 RAG 的三层信息结构

视频是"时序多模态"——它由视觉帧（image sequence）、音频流（audio track）、字幕（subtitle）、元数据（metadata）四个层次组成。每一层都承载不同语义：

视频信息结构与 RAG 挑战
═══════════════════════════════════════════════════════════════

  ┌─────────────────────────────────────────┐
  │  视频文件 (mp4/mov)                      │
  │                                          │
  │  ┌─────────────────────────────────────┐ │
  │  │  视觉帧序列 (1 fps 采样 → 3600 帧) │ │
  │  │  每帧 224×224 RGB                    │ │
  │  │  → 视觉 Embedding (SigLIP/CLIP)    │ │
  │  │  → 视觉 chunk (时序连续)            │ │
  │  └─────────────────────────────────────┘ │
  │  ┌─────────────────────────────────────┐ │
  │  │  音频流 (16kHz mono)                │ │
  │  │  → ASR 转录 (Whisper)              │ │
  │  │  → 文本 chunk (带时间戳)            │ │
  │  └─────────────────────────────────────┘ │
  │  ┌─────────────────────────────────────┐ │
  │  │  字幕 (srt/vtt)                     │ │
  │  │  → 直接索引                         │ │
  │  │  → 文本 chunk                       │ │
  │  └─────────────────────────────────────┘ │
  │  ┌─────────────────────────────────────┐ │
  │  │  元数据 (标题/章节/标签)            │ │
  │  │  → 文本 chunk                       │ │
  │  └─────────────────────────────────────┘ │
  │                                          │
  │  RAG 核心挑战:                           │
  │  ① 视觉与音频时序对齐                    │
  │  ② 关键帧识别（避免冗余）                 │
  │  ③ 多模态融合检索                         │
  └─────────────────────────────────────────┘

9.2 关键帧提取：避免帧级 Embedding 的维度爆炸

一段 1 小时的视频，1 fps 采样有 3600 帧，每帧 Embedding 后是 3600 个 chunk——存储与检索成本极高。工程上的解决方案是"关键帧提取"——用场景检测算法只保留"内容变化点"的帧。

常见关键帧提取策略：

策略 1：场景切换检测（Scene Detection）。基于颜色直方图或深度特征，检测视频中的"场景切换点"，只保留切换前后的帧。一段 1 小时讲座视频可能只有 50-100 个关键帧。

策略 2：镜头稳定点检测。基于光流变化，检测镜头"稳定"的时间点（不抖动、不运动），保留稳定点帧。

策略 3：基于 VL 模型的语义关键帧。用 VL 模型（如 Qwen2-VL）评估每帧的"信息密度"，保留高信息密度帧（"包含 PPT 切换"、"包含人物动作变化"）。

策略 4：结合 ASR 的语义切片。以 ASR 转录的"句子边界"为锚点，在每个句子区间内取 1-3 关键帧，把视频与音频的语义时间对齐。

9.3 视频 RAG 的检索范式

视频检索有三种典型范式：

范式 1：文本驱动（Text-to-Video）。用户用自然语言 Query，系统返回相关视频片段。这是 VideoRAG 系统的核心范式。代表方案：VideoCLIP、InternVideo、LanguageBind。

范式 2：视频问答（VideoQA）。给定视频与 Query，系统返回答案文字。这更接近 VQA（Video Question Answering）任务，代表方案：Video-LLaMA、Video-ChatGPT、Qwen2-VL。

范式 3：长视频摘要（Long Video Summarization）。对超长视频（1 小时+）生成结构化摘要，存入 RAG。这需要更强的长上下文建模能力，代表方案：LongVA、MovieChat。

VideoRAG 检索流程
═══════════════════════════════════════════════════════════════

  离线索引
  ───────
  视频文件 ──► 关键帧提取(场景检测)
            ──► ASR 转录(Whisper)
            ──► 关键帧 Embedding(SigLIP)
            ──► ASR 文本 Embedding(BGE-M3)
            ──► 时序对齐(帧-句绑定)
            ──► 融合索引存储
                       │
                       ▼
  在线检索
  ───────
  用户 Query ──► Query Embedding
                     │
                     ├── 视觉向量检索 ──► 关键帧候选
                     ├── 文本向量检索 ──► ASR 候选
                     └── 元数据检索   ──► 章节候选
                              │
                              ▼
                        RRF 融合排序
                              │
                              ▼
                       Top-K 时序片段
                       (含 帧+音频+字幕)
                              │
                              ▼
                       VL 模型生成答案

9.4 音频 RAG：从 ASR 到音频 Embedding

音频 RAG（Audio-RAG）是视频 RAG 的"子集"，专门处理纯音频场景：会议录音、播客、客服通话、有声书等。其核心流程：

步骤 1：ASR 转录。用 Whisper / Paraformer 等 ASR 模型把音频转录为带时间戳的文本。这是音频 RAG 的基础。

步骤 2：说话人分离。对会议录音、客服通话等多说话人场景，用说话人 diarization 模型分离不同说话人（"Speaker A: ... Speaker B: ..."）。

步骤 3：音频 Embedding（可选）。除了文本 Embedding，还可以直接对音频做 Embedding——用 CLAP（Contrastive Language-Audio Pretraining）或 AudioCLIP 模型，把音频和文本映射到同一向量空间。这能检索到"语气"、"情绪"等非语义信息。

步骤 4：时序 chunk 切分。按语义停顿、说话人切换、话题转换等节点切分音频 chunk，每个 chunk 包含：时间区间、说话人、转录文本、音频 Embedding（可选）。

9.5 时序对齐：视频 RAG 的核心技术难题

视频 RAG 最大的技术挑战是"时序对齐"——把视觉帧、音频、字幕三种异构信息在同一时间轴上对齐。这一对齐的精度直接决定 RAG 系统的检索质量。

工程上常用三种对齐方案：

方案 1：基于 ASR 时间戳。用 ASR 转录时输出的"开始/结束时间"，把字幕文本与音频时间戳绑定；再用说话人 diarization 关联到不同视频帧。

方案 2：基于多模态 VL 模型。用 Qwen2-VL / Video-LLaVA 等多模态大模型，对视频帧序列与文本描述做联合 Embedding，模型内部学习时序对齐。

方案 3：基于章节标签。对结构化视频（讲座、课程），用人工或自动标注的章节标签作为"对齐锚点"，把视觉、音频、字幕都按章节切分。

9.6 工程实现：VideoRAG 系统架构

一个生产级 VideoRAG 系统的完整架构：

VideoRAG 生产架构
═══════════════════════════════════════════════════════════════

  离线处理流水线
  ────────────
  视频源
     │
     ├─► FFmpeg 抽帧 (1fps) ──► 关键帧检测(PySceneDetect)
     │                              │
     │                              ▼
     │                        关键帧 N 张
     │                              │
     │                              ▼
     │                        SigLIP Embedding
     │
     ├─► FFmpeg 抽音 ──► Whisper ASR ──► 时间戳文本
     │                              │
     │                              ▼
     │                        BGE-M3 Embedding
     │
     └─► 章节检测 / 元数据 ──► 元数据 Embedding

  三个向量库（视觉/音频/元数据）
     │
     ▼
  在线检索
  ────────
  Query ──► Query Embedding
                  │
                  ├── 视觉 ANN ──► 候选帧
                  ├── 文本 ANN ──► 候选句
                  └── 元数据 ANN ──► 候选章节
                              │
                              ▼
                        RRF 融合
                              │
                              ▼
                     Top-K 时序片段
                              │
                              ▼
                  Qwen2-VL 多模态生成
                              │
                              ▼
                          答案 + 视频剪辑链接

十、多模态融合检索：跨模态空间与 RRF 融合

当 RAG 系统需要同时检索文本、图像、表格、视频、音频时，多模态融合检索成为架构师必须面对的核心问题。这一问题的本质是"如何把不同模态的检索结果在统一语义空间中排序"。本章从架构层面剖析多模态融合检索的三大路径：统一向量空间、桥接层模型、检索结果 RRF 融合。

10.1 多模态融合的三层架构

多模态融合检索有三种实现层次，从浅到深依次为：

多模态融合检索的三层架构
═══════════════════════════════════════════════════════════════

  ┌────────────────────────────────────────────────┐
  │  Layer 1: 检索结果融合 (Result-level Fusion)  │  简单
  │                                                │
  │  各模态独立检索 → RRF/加权融合                 │
  │  优点: 模块化 / 易实现                         │
  │  缺点: 模态间语义不对齐                       │
  ├────────────────────────────────────────────────┤
  │  Layer 2: 桥接层融合 (Bridge-level Fusion)   │  中等
  │                                                │
  │  桥接模型统一映射 → 共同向量空间               │
  │  优点: 语义对齐好                              │
  │  缺点: 桥接模型训练难                          │
  ├────────────────────────────────────────────────┤
  │  Layer 3: 统一向量空间 (Joint Embedding)      │  复杂
  │                                                │
  │  端到端多模态 Embedding → 单一向量库            │
  │  优点: 最优语义                                │
  │  缺点: 训练成本极高 / 难扩展                   │
  └────────────────────────────────────────────────┘

10.2 路径 1：统一向量空间（CLIP / ImageBind）

统一向量空间是最理想的方案——所有模态在同一个 Embedding 空间中，跨模态检索就像同模态检索一样自然。代表方案：

CLIP：把文本和图像映射到同一空间，跨模态检索变成"点积计算"。

ImageBind：Meta 发布的全模态 Embedding 模型，把图像、文本、音频、视频、深度图、热成像、IMU 等 6+ 模态统一到一个向量空间。理论上可以用任何模态检索任何模态。

LanguageBind：类似 ImageBind，把视频、音频、图像、深度、红外、语言六模态对齐到语言 Embedding 空间。

统一向量空间的优点是"理论优雅"，缺点是训练成本极高、扩展性差。每增加一个模态，需要重新训练整个模型；专业领域（医学影像、工业图纸）的精度受限于通用训练数据。

10.3 路径 2：桥接层模型（Bridge Model）

桥接层模型是"轻量级统一空间"方案——保留各模态的原始 Embedding 空间不变，用一个小型桥接模型把它们映射到共同空间。

典型架构：

桥接层模型架构
═══════════════════════════════════════════════════════════════

  文本空间 (BGE-M3)       图像空间 (SigLIP)
       │                       │
       ▼                       ▼
  text_emb [1024]        image_emb [1152]
       │                       │
       └───────┬───────────────┘
               │
               ▼
         桥接层模型
         (2 层 MLP / Attention)
               │
               ▼
       共同空间向量 [512]
               │
               ▼
         跨模态相似度计算
         (点积 / 余弦)

桥接层模型的训练数据是"跨模态对齐对"——同一语义的文本与图像对。训练时冻结原始 Encoder，只训练桥接层。这种方案的优势是训练快、扩展性好，劣势是桥接层引入了额外信息损失。

工程实践：

案例 1：BGE-VL 用了类似思路——基于 BGE-M3 文本 Encoder + SigLIP 图像 Encoder + 桥接层，把图文映射到 BGE-M3 的文本空间，复用 BGE 的多语言能力。

案例 2：Jina CLIP v2 用桥接架构支持 89 种语言 + 长上下文，把多语言能力注入 CLIP。

10.4 路径 3：检索结果 RRF 融合

RRF（Reciprocal Rank Fusion）是工程上最常用的多模态融合方案。保留各模态独立检索，仅对结果做加权融合。优点是模块化、易实现、可扩展。

RRF 融合算法
═══════════════════════════════════════════════════════════════

  伪代码:
  def rrf_fusion(results_list, k=60):
      """
      results_list: 每个元素的格式: [(doc_id, score), ...]
      k: RRF 参数（通常 60）
      """
      fused_scores = {}
      for results in results_list:
          for rank, (doc_id, _) in enumerate(results):
              if doc_id not in fused_scores:
                  fused_scores[doc_id] = 0
              fused_scores[doc_id] += 1.0 / (k + rank + 1)
      return sorted(fused_scores.items(),
                    key=lambda x: x[1], reverse=True)

  示例:
  ─────
  文本检索结果:  [A, B, C, D, E]
  图像检索结果:  [B, C, F, G, A]
  表格检索结果:  [D, A, H, I, J]

  RRF 分数计算（k=60）:
  A: 1/61 + 1/65 + 1/62 = 0.0462
  B: 1/62 + 1/61 + 0     = 0.0323
  C: 1/63 + 1/62 + 0     = 0.0319
  D: 1/64 + 0     + 1/61 = 0.0319
  ...

  融合排序: A > B > C > D > E > F > G > H > I > J

RRF 的关键优势是对各模态检索器的"分数尺度"不敏感。文本检索可能用余弦相似度（0-1），图像检索可能用点积（-1 到 1），表格检索可能用 BM25 分数（0-100）。RRF 用"排名倒数"代替"原始分数"，把不同尺度的结果拉到同一比较空间。

10.5 多模态融合的工程实践

企业级多模态 RAG 系统的融合架构通常分三层：

多模态融合检索系统架构
═══════════════════════════════════════════════════════════════

  Layer 1: 多路召回 (Recall)
  ──────────────────────────
  Query ─┬─► 文本 Embedding ──► 文本 ANN ──► Top-100 文本
         │
         ├─► 图像 Embedding ──► 图像 ANN ──► Top-100 图像
         │
         ├─► 表格 Embedding ──► 表格 ANN ──► Top-100 表格
         │
         └─► 视频 Embedding ──► 视频 ANN ──► Top-100 视频

  Layer 2: 多路精排 (Re-rank)
  ──────────────────────────
  文本候选 ──► BGE-Reranker ──► 文本精排 Top-20
  图像候选 ──► ColPali Rerank ──► 图像精排 Top-20
  表格候选 ──► 表格 Reranker ──► 表格精排 Top-20
  视频候选 ──► 视频 Reranker ──► 视频精排 Top-20

  Layer 3: RRF 融合排序
  ──────────────────────────
  四个精排结果 ──► RRF ──► 融合 Top-10
                       │
                       ▼
                  LLM 生成

这种"多路召回 + 多路精排 + RRF 融合"的三层架构兼顾了召回率（多路不遗漏）与精度（精排去噪），是当前生产级多模态 RAG 的标准范式。

10.6 模态权重自适应

不同 Query 对不同模态的偏好不同。例如"对比两家公司的营收"偏好表格，"看一张风景照"偏好图像，"看一段培训视频"偏好视频。架构师应当建立模态权重自适应机制：

方法 1：基于 Query 分类。用一个分类器预测 Query 的模态偏好（文本/图像/表格/视频），动态调整各模态的 RRF 权重。

方法 2：基于 Reranker 的端到端学习。训练一个 Cross-modal Reranker，输入是 (Query, 多模态候选)，输出是排序分数。这种端到端模型能自动学习模态偏好。

方法 3：基于 LLM 的意图理解。用 LLM 分析 Query 意图，显式指定"本次查询主要关注表格/图像"，动态调整权重。

多模态融合检索的"三层架构"（多路召回 + 多路精排 + RRF 融合）是 2026 年的工程标准。这一架构兼顾了召回率与精度，是模块化与精度的平衡。

多模态融合的本质是"模块化召回 + 协同融合"，避免单一模态的局限性。

视频 RAG 的核心挑战是"时序对齐"——把视觉帧、音频、字幕在统一时间轴上关联。这一挑战的解决程度直接决定 RAG 系统的检索质量。

视频 RAG 的"统一时序索引"是连接多种模态的核心枢纽。

关键帧提取是视频 RAG 的"成本控制阀门"——不做关键帧检测就直接 Embedding 所有帧，存储与算力成本会爆炸。

关键帧提取是"用算法换成本"的典型工程实践。

十一、Microsoft GraphRAG 架构：社区检测与全局问题

2024 年 7 月，微软开源 GraphRAG 项目，在 RAG 社区引发强烈反响。它用知识图谱 + 社区检测 + 层级摘要的范式，精准解决了"全局性问题"这个传统 RAG 的老大难。本章从架构层面深入剖析 GraphRAG 的核心思想、模块拆解与工程取舍。

11.1 GraphRAG 的核心抽象：从"段落"到"图谱"

传统 RAG 的核心抽象是"段落 chunk"——文档被切成 500-1000 token 的 chunk，每个 chunk 独立 Embedding。GraphRAG 的核心抽象是"实体-关系图"——文档被解析为"实体（Entity）+ 关系（Relationship）"的图谱，实体和关系都被 Embedding 并索引。

这种抽象的价值在于：把"局部段落"升级为"全局结构"。当用户问"公司高管之间的汇报关系"时，传统 RAG 需要在多个 chunk 中拼接信息；GraphRAG 直接在图谱上做图查询，天然支持全局关系推理。

传统 RAG 抽象 vs GraphRAG 抽象
═══════════════════════════════════════════════════════════════

  传统 RAG 抽象:                   GraphRAG 抽象:
  ─────────────                    ─────────────
  文档                              文档
     │                                 │
     ▼ 分块                            ▼ LLM 抽取
  chunks                              实体 + 关系
     │                                 │
     ▼ Embedding                        ▼ 构建图谱
  文本向量                            节点 + 边
     │                                 │
     ▼ ANN 检索                        ▼ Embedding
  Top-K 文本                          节点向量 + 边向量
     │                                 │
     ▼ LLM 生成                        ▼ 图查询/向量检索
  答案                                 答案

  核心差异:                            核心优势:
  · 信息以 chunk 为单元               · 信息以实体/关系为单元
  · 检索是相似度匹配                   · 检索是图遍历 + 相似度
  · 难以处理全局关系                   · 天然支持关系推理

11.2 GraphRAG 的两阶段流程

GraphRAG 的处理流程分为两个主要阶段：

阶段 1：索引阶段（Indexing）。把原始文档转化为知识图谱 + 社区层级摘要。这是离线流程，对每个文档执行一次。

阶段 2：查询阶段（Querying）。基于索引阶段的图谱与摘要回答用户问题。这是在线流程，每次查询执行。

GraphRAG 完整处理流程
═══════════════════════════════════════════════════════════════

  索引阶段 (离线)
  ──────────────
  文档集合
     │
     ▼
  ┌──────────────────────┐
  │ ① 文本分块           │  500-1000 token/chunk
  └──────┬───────────────┘
         │
         ▼
  ┌──────────────────────┐
  │ ② LLM 实体/关系抽取  │  GPT-4 / Qwen-Long
  │    "找出所有实体和     │  Prompt: 实体类型 + 关系类型
  │     它们之间的关系"   │  输出: (entity, type, desc)
  └──────┬───────────────┘         (entity1, rel, entity2)
         │
         ▼
  ┌──────────────────────┐
  │ ③ 构建知识图谱        │  NetworkX / Neo4j
  │    节点 = 实体        │  节点带类型、描述、Embedding
  │    边 = 关系          │  边带类型、权重、Embedding
  └──────┬───────────────┘
         │
         ▼
  ┌──────────────────────┐
  │ ④ 社区检测            │  Leiden / Louvain 算法
  │    把图谱分成社区      │  层级化: L0, L1, L2
  └──────┬───────────────┘
         │
         ▼
  ┌──────────────────────┐
  │ ⑤ 社区摘要            │  LLM 为每个社区生成摘要
  │    LLM 总结社区内容   │  摘要: 200-500 字
  └──────┬───────────────┘
         │
         ▼
  ┌──────────────────────┐
  │ ⑥ Embedding 索引      │  节点/边/社区摘要均 Embedding
  └──────┬───────────────┘
         │
         ▼
  图谱 + 社区摘要 + 向量索引

  查询阶段 (在线)
  ──────────────
  用户 Query
     │
     ▼
  ┌──────────────────────┐
  │ ① Query 分类         │  Local / Global 两种
  │    "这是局部问题      │
  │     还是全局问题?"    │
  └──────┬───────────────┘
         │
    ┌────┴────┐
    ▼         ▼
  Local     Global
  局部查询   全局查询
    │         │
    ▼         ▼
  实体检索   社区摘要检索
  + 邻居遍历  + Map-Reduce
    │         │
    └────┬────┘
         ▼
       LLM 答案

11.3 Leiden 算法：社区检测的工程实现

Leiden 算法是 GraphRAG 用于社区检测的核心算法。它在 Louvain 算法基础上做了改进，能发现层级化社区结构——既能识别大社区（如"公司高管圈"），也能识别大社区内的小社区（如"技术高管圈"）。

Leiden 算法的核心思想：

Leiden 算法伪代码
═══════════════════════════════════════════════════════════════

  def leiden(graph, levels=3):
      """
      层级化社区检测
      graph: 知识图谱
      levels: 社区层级数
      """
      communities = graph  # 初始: 每个节点一个社区
      hierarchy = []

      for level in range(levels):
          # 阶段 1: 局部移动
          # 把每个节点移到能让模块度提升最大的社区
          improved = True
          while improved:
              improved = False
              for node in graph.nodes:
                  best_community = node.community
                  best_gain = 0
                  for neighbor in node.neighbors:
                      if neighbor.community != node.community:
                          gain = modularity_gain(node, neighbor.community)
                          if gain > best_gain:
                              best_community = neighbor.community
                              best_gain = gain
                  if best_gain > 0:
                      move_node(node, best_community)
                      improved = True

          # 阶段 2: 社区细化
          # 把不连通的社区拆开

          # 阶段 3: 社区聚合
          # 把社区当作新节点, 构建下一层图谱

          hierarchy.append(current_communities)

      return hierarchy

Leiden 算法输出的"层级社区"是 GraphRAG 全局查询的基础。每一层社区都对应一个"摘要"——一个 LLM 生成的、能代表该社区所有节点和边的高质量文本段落。查询时，根据 Query 类型检索对应层的社区摘要。

11.4 Local vs Global 查询：两种推理模式

GraphRAG 把用户 Query 分为两类，分别用不同流程：

Local 查询（局部问题）。问题指向具体实体，如"张三是哪个部门的？"、"X 产品的研发负责人是谁？"。Local 查询的流程：实体识别 → 实体 Embedding 检索 → 邻居节点遍历 → LLM 生成。

Global 查询（全局问题）。问题指向全局模式，如"公司的核心技术布局是什么？"、"近一年的主要风险有哪些？"。Global 查询的流程：社区摘要 Embedding 检索 → Top-K 社区摘要 → Map-Reduce 汇总 → LLM 生成。

Global 查询的 Map-Reduce 模式：先把每个社区摘要作为"独立证据"，让 LLM 对每个摘要单独提取关键信息（Map），再把所有关键信息汇总，让 LLM 生成最终答案（Reduce）。这种模式能有效处理"答案信息分散在数十个社区"的问题。

11.5 工程实现的关键挑战

GraphRAG 在企业落地面临四个工程挑战：

挑战 1：LLM 抽取成本。实体/关系抽取需要调用 LLM（如 GPT-4），每个 chunk 大约 5-10K token。1 万页文档可能消耗 1 亿+ token，成本数千美元。解决方案：用小模型（如 Qwen2-7B）替代 GPT-4 + 异步批处理 + 缓存。

挑战 2：抽取质量与一致性。LLM 抽取实体时，"苹果"可能被识别为"苹果公司"或"苹果水果"，不同 chunk 之间实体不一致。解决方案：实体对齐（Entity Resolution） + 标准化命名。

挑战 3：图谱更新。文档新增/更新时，图谱需要增量更新——这比传统 RAG 的"加 chunk"复杂得多。解决方案：增量索引 + 版本控制 + 图谱合并。

挑战 4：可扩展性。当文档量达到 100 万+页时，图谱可能有 1000 万+节点、1 亿+边，图算法（Leiden）的执行时间变长。解决方案：分布式图计算 + 增量社区检测 + 摘要缓存。

11.6 GraphRAG 适用场景与不适用场景

GraphRAG 不是"万能 RAG"。架构师必须判断业务是否适合：

十二、LightRAG / HippoRAG：增量更新与 PPR 引导

GraphRAG 之后，学术界与工业界进一步探索了"轻量级图谱 RAG"的多种路径。LightRAG（港大 2024）和 HippoRAG（OSU 2024）是两个代表性方案，分别从"增量更新"和"PPR 引导检索"两个维度优化 GraphRAG 的痛点。本章深入剖析这两条演进路径。

12.1 LightRAG：双层检索与增量更新

LightRAG 由香港大学黄超团队在 2024 年 10 月提出，核心改进是"双层检索"和"增量更新"。它把 GraphRAG 的"全局图谱"分解为"低层实体级图谱 + 高层主题级图谱"，检索时双层并行。

LightRAG 双层图谱架构
═══════════════════════════════════════════════════════════════

  ┌─────────────────────────────────────────────┐
  │           LightRAG 双层图谱                 │
  ├─────────────────────────────────────────────┤
  │  L1: 实体-关系层 (Entity-Relation)          │
  │                                              │
  │  节点: 具体实体(人/物/概念)                  │
  │  边: 实体间具体关系                          │
  │  检索粒度: 细粒度                            │
  │  适合: "X 是什么" "X 和 Y 关系"            │
  │                                              │
  │  ─────────────────────────────────────────  │
  │                                              │
  │  L2: 主题-关键词层 (Topic-Keyword)           │
  │                                              │
  │  节点: 抽象主题 / 关键词簇                    │
  │ 边: 主题间关联 / 关键词共现                   │
  │ 检索粒度: 粗粒度                            │
  │ 适合: "整体趋势" "核心主题"                │
  │                                              │
  └─────────────────────────────────────────────┘

  双层并行检索:
  Query ─┬─► L1 实体检索 ──► 实体级证据
         │
         └─► L2 主题检索 ──► 主题级证据
                       │
                       ▼
                证据融合 + LLM 生成

LightRAG 的双层架构对 GraphRAG 三大痛点的改进：

改进 1：检索更精准。双层并行检索能同时覆盖"具体实体"和"抽象主题"，避免 GraphRAG 单层社区检测的"粒度单一"问题。

改进 2：增量更新更友好。新文档到来时，只需在两层图谱上局部更新（新增节点、边、主题），无需重跑全量 Leiden 算法。这是 LightRAG 名字中"Light"的由来。

改进 3：成本更低。LightRAG 不需要 Leiden 社区检测和层级摘要生成，仅维护双层图谱和向量索引，整体索引成本约为 GraphRAG 的 30-50%。

12.2 LightRAG 的增量更新机制

LightRAG 的核心创新之一是"增量更新"——支持新文档动态加入图谱而无需全量重建。具体流程：

LightRAG 增量更新流程
═══════════════════════════════════════════════════════════════

  现有图谱 G(V, E)
       │
       ▼
  新文档 d 到达
       │
       ▼
  ① 文档分块 chunks
       │
       ▼
  ② LLM 抽取新实体/关系
       │
       ▼
  ③ 实体对齐 (与现有实体合并)
       │
       ├─► 已存在实体: 更新描述/关系
       │
       └─► 新实体: 添加到 V
       │
       ▼
  ④ 主题聚类 (新增文档的主题归入现有主题簇)
       │
       ▼
  ⑤ 向量索引增量更新
       │
       ▼
  ⑥ 图谱 G'(V', E') 完成增量

  时间复杂度:
  ──────────
  全量重建:  O(|V| + |E|)
  增量更新:  O(新 chunk 数的实体抽取)

  收益: 文档量增长 10 倍, 重建成本不会增加 10 倍

这种增量更新能力对动态知识库（新闻、舆情、内部 wiki）尤其重要——传统 GraphRAG 在文档频繁更新时维护成本极高，LightRAG 把成本压到"可接受"范围。

12.3 HippoRAG：受神经科学启发的 PPR 检索

HippoRAG 由俄亥俄州立大学（OSU）的 Yejin Choi 团队在 2024 年 5 月提出。它的灵感来自海马体记忆理论——人类大脑的海马体负责把新记忆与已有记忆关联，形成可检索的记忆网络。HippoRAG 把这一机制数字化：

核心抽象。文档 → 知识图谱（OpenIE 抽取的实体和关系）。Query 到来时，从 Query 中识别关键实体，在图谱上做Personalized PageRank（PPR），让 Query 实体作为"种子节点"沿图边扩散激活，最终得到与 Query 最相关的节点。

与传统图检索的区别。传统图检索是"一跳/两跳邻居查询"——只看到直接相连的节点。PPR 是"全图激活扩散"——通过随机游走把激活值传播到整个图谱，捕获多跳关联。

HippoRAG PPR 检索机制
═══════════════════════════════════════════════════════════════

  Query: "X 的导师写过什么书?"
       │
       ▼
  实体识别: X
       │
       ▼
  在图谱中定位 X 节点
       │
       ▼
  Personalized PageRank
  (以 X 为种子节点, α=0.15 阻尼)
       │
       ▼
  激活值传播:
       │
  X (激活 1.0)
    │
    ├──► 导师是 Y (激活 0.7)
    │       │
    │       └──► Y 写过书 Z (激活 0.4)
    │               │
    │               └──► Z 出版社 P (激活 0.2)
    │
    └──► X 就读学校 S (激活 0.3)
            │
            └──► S 教授 W (激活 0.1)
       │
       ▼
  激活值 Top-K 节点: Z, Y, S, P
       │
       ▼
  关联到原始文档
       │
       ▼
  LLM 生成答案

PPR 检索相比传统图查询有三大优势：

优势 1：自然支持多跳。PPR 通过随机游走自然捕获多跳关联，不需要显式指定跳数。

优势 2：考虑激活衰减。距离种子节点越远，激活值越低。这模拟了人类记忆的"近因效应"——离 Query 实体近的记忆更清晰。

优势 3：可解释性强。PPR 的激活路径天然是"推理链"，能直接展示"为什么这个文档被检索到"。

12.4 HippoRAG 的工程实现

HippoRAG 的工程实现包括三个核心模块：

HippoRAG 架构模块
═══════════════════════════════════════════════════════════════

  ┌──────────────────────────────────────┐
  │  ① OpenIE 抽取                       │
  │     Stanford CoreNLP / LLM           │
  │     抽取: (主体, 谓词, 客体) 三元组    │
  │     输出: 知识图谱                    │
  └──────────┬───────────────────────────┘
             │
             ▼
  ┌──────────────────────────────────────┐
  │  ② LLM 实体链接                      │
  │     把 Query 中的实体链接到图谱节点    │
  │     用 Embedding 相似度匹配           │
  └──────────┬───────────────────────────┘
             │
             ▼
  ┌──────────────────────────────────────┐
  │  ③ Personalized PageRank             │
  │     NetworkX / igraph 实现           │
  │     α=0.15 (重启概率)                │
  │     迭代 100 次或收敛                │
  │     输出: 节点激活值排序              │
  └──────────┬───────────────────────────┘
             │
             ▼
  ┌──────────────────────────────────────┐
  │  ④ 文档关联 + LLM 答案                │
  │     把高激活节点关联回原始文档         │
  │     Top-K 文档送入 LLM               │
  └──────────────────────────────────────┘

12.5 LightRAG vs HippoRAG：架构对比与选型

LightRAG 和 HippoRAG 都是 GraphRAG 的优化方案，但优化方向不同：

12.6 知识图谱增强的演进趋势

从 GraphRAG → LightRAG → HippoRAG，知识图谱增强 RAG 呈现三个明显趋势：

趋势 1：从"全量图谱"到"分层图谱"。单一全量图谱难维护，演进为"实体层 + 主题层"或"局部图谱 + 全局图谱"的层级化设计。

趋势 2：从"批处理"到"增量更新"。全量重建成本高，演进为增量更新机制（新增文档局部修改图谱）。

趋势 3：从"相似度检索"到"图算法检索"。传统向量检索不能利用图结构，演进为 PPR、子图匹配等图算法检索。

这三条趋势共同指向"更智能的图谱 RAG"——既能处理全局问题，又能保持低成本更新，还能利用图结构做深度推理。

LightRAG 与 HippoRAG 分别从"增量更新"和"PPR 检索"两个维度优化 GraphRAG。这一演进表明，知识图谱增强 RAG 正在从"概念验证"走向"工程落地"。

两种优化路径针对不同业务特征，架构师应当按"动态性"与"多跳性"两维度选型。

GraphRAG 的核心创新是"图谱 + 社区 + 摘要"的层级化处理。这一架构把传统 RAG 的"段落"抽象升级为"实体-关系"图谱，天然支持全局性问题。

GraphRAG 的双流程（Local / Global）覆盖了"实体查询"和"全局聚合"两类问题。

知识图谱增强 RAG 的演进反映了"问题驱动"的范式跃迁——从 GraphRAG 的概念验证，到 LightRAG 的工程优化，到 HippoRAG 的多跳增强。

三种方案各有侧重，架构师应按"动态性"与"多跳性"两维度选型。

十三、KAG 框架：领域知识增强生成

2024 年 10 月，阿里巴巴蚂蚁集团开源了 KAG（Knowledge-Augmented Generation）框架，把"知识图谱 + 形式化推理 + 垂直领域"结合在一起，成为专业领域 RAG的代表性方案。KAG 在 OpenKG、蚂蚁业务场景（金融、医疗、政务）上的实践为垂直领域 RAG 提供了一套完整的方法论。本章从架构层面深入剖析 KAG 的核心思想、模块设计与企业落地路径。

13.1 KAG 的核心抽象：开放信息抽取 + 形式化知识

KAG 与 GraphRAG 的核心差异在于"知识表示的严格性"。GraphRAG 用 LLM 自由抽取实体和关系，关系是自然语言描述（如"工作于"、"合作过"）。KAG 在此基础上引入了Schema 约束与形式化推理：

GraphRAG vs KAG 知识表示对比
═══════════════════════════════════════════════════════════════

  GraphRAG 知识表示:
  ─────────────────
  节点: {实体, 类型, 描述(自然语言)}
  边: {源实体, 目标实体, 关系(自然语言)}
  示例:  {name: "张三", type: "Person", desc: "..."}
        {name: "A公司", type: "Company", desc: "..."}
        {src: "张三", tgt: "A公司", rel: "工作于"}

  特点: 灵活 / 自然语言描述 / 难推理

  KAG 知识表示:
  ─────────────
  节点: {实体, 严格类型, 严格属性(Schema 定义)}
  边: {源实体, 目标实体, 关系(本体约束)}
  示例:  {name: "张三", type: "Person", attrs: {age:30, role:"工程师"}}
        {name: "A公司", type: "Company", attrs: {industry:"科技"}}
        {src: "张三", tgt: "A公司", rel: "EMPLOYED_BY"}

  特点: 严格 / 类型化 / 可形式化推理

  形式化推理示例:
  ─────────────
  IF X EMPLOYED_BY Y AND Y INDUSTRY = "科技"
  THEN X 可能在科技行业

  GraphRAG 无法做这种推理，KAG 可以

13.2 KAG 的四层架构

KAG 框架采用四层架构设计，每一层都对应明确的工程职责：

KAG 四层架构
═══════════════════════════════════════════════════════════════

  ┌─────────────────────────────────────────────────────┐
  │  Layer 1: Schema 层 (本体定义)                       │
  │                                                      │
  │  · 领域 Schema 定义 (实体类型、关系类型、属性约束)    │
  │  · OpenKG / UMLS / SNOMED 等行业本体导入             │
  │  · 用户可自定义扩展                                  │
  │  · 类比: 数据库的 DDL                                │
  ├─────────────────────────────────────────────────────┤
  │  Layer 2: 抽取层 (开放信息抽取)                      │
  │                                                      │
  │  · LLM + Schema 约束的实体/关系抽取                  │
  │  · 实体对齐(同义合并)、属性归一化                    │
  │  · 置信度评分                                        │
  │  · 类比: 数据库的 ETL                                │
  ├─────────────────────────────────────────────────────┤
  │  Layer 3: 知识层 (图谱存储)                          │
  │                                                      │
  │  · 严格类型的图谱(节点、边、属性)                    │
  │  · 向量化 Embedding(节点、边、子图)                  │
  │  · 多种图谱后端(Neo4j, TuGraph, OceanBase)          │
  │  · 类比: 数据库的存储引擎                            │
  ├─────────────────────────────────────────────────────┤
  │  Layer 4: 推理层 (混合推理)                          │
  │                                                      │
  │  · 向量检索(图谱节点 Embedding)                      │
  │  · 逻辑推理(SPARQL / Cypher / GQL)                  │
  │  · LLM 推理(自然语言答案生成)                       │
  │  · 类比: 数据库的查询引擎                            │
  └─────────────────────────────────────────────────────┘

13.3 Schema 层：领域本体的引入

KAG 的核心创新是"Schema-first"——先定义领域本体（ontology），再进行信息抽取。这一思路与传统 GraphRAG 的"Schema-less"形成鲜明对比。

Schema 的核心组件：

实体类型（Entity Types）。如金融领域定义"公司"、"股票"、"分析师"、"财报"、"行业"等实体类型。

关系类型（Relation Types）。如"公司-发布-财报"、"分析师-研究-股票"、"公司-属于-行业"等关系类型，且关系有方向、基数（1:1 / 1:N / N:N）约束。

属性约束（Property Constraints）。如"公司"实体有"成立时间"、"注册资本"、"主营业务"等必填/选填属性，且属性有数据类型（字符串/数字/日期）。

Schema 带来了三大好处：

好处 1：抽取质量提升。LLM 在 Schema 约束下做信息抽取，输出严格符合定义的结构化数据，避免"自由抽取"的混乱。

好处 2：推理能力。严格的类型和关系让图谱支持形式化推理（如 RDFS / OWL 推理），而不只是相似度检索。

好处 3：领域可解释性。Schema 本身就是领域知识的"骨架"，业务专家可以审核和修改，符合企业合规需求。

13.4 形式化推理：从图谱到答案

KAG 的推理层支持三种模式：

模式 1：向量检索。Query Embedding → 图谱节点 Embedding ANN 检索 → Top-K 节点 → LLM 生成答案。这是 GraphRAG 风格。

模式 2：逻辑查询。把 Query 转译为 SPARQL / Cypher / GQL 查询 → 图谱执行 → 结果送 LLM 生成答案。这种模式适合"结构化查询"（"列出 2024 年营收超过 100 亿的公司"）。

模式 3：混合推理。先用向量检索召回候选节点，再用逻辑查询精确过滤，最后 LLM 生成。这种模式兼顾了语义匹配与精确推理。

KAG 混合推理流程
═══════════════════════════════════════════════════════════════

  Query: "列出 2024 年营收超过 100 亿且在科技行业的公司"
       │
       ▼
  ① Query 解析 (LLM)
       │  识别:
       │  - 实体类型: 公司
       │  - 过滤条件: 营收 > 100亿 AND 行业 = 科技
       │  - 时间: 2024 年
       ▼
  ┌────────────────────────────────────┐
  │  ② 混合检索                        │
  │                                    │
  │  向量检索 (语义):                   │
  │    "公司" 节点 Embedding → Top-100 │
  │                                    │
  │  逻辑过滤 (精确):                   │
  │    营收 > 100亿 AND 行业 = 科技     │
  │                                    │
  │  → 候选: 23 家公司                  │
  └──────────────┬─────────────────────┘
                 │
                 ▼
  ③ LLM 答案生成
       │
       ▼
  答案: "A公司(120亿)、B公司(150亿)、C公司(180亿)..."

13.5 垂直领域适配：金融/医疗/政务案例

KAG 在蚂蚁集团的多个垂直领域落地，每个领域都有针对性的 Schema 与推理设计：

以金融领域为例，KAG 通过导入"XBRL 财报本体"+"上交所/深交所公司本体"+"行业分类本体（GICS）"等开源 Schema，能在 1-2 周内完成一个金融场景的领域适配，远快于从零构建图谱。

13.6 KAG 与 GraphRAG 的差异化定位

KAG 不是"取代"GraphRAG，而是"专业领域 RAG 的进阶版"。两者的关系：

GraphRAG 定位：通用领域 / 探索性项目 / 快速验证全局性问题可行性。

KAG 定位：垂直领域 / 工业化项目 / 需要严格推理与可解释性。

架构师选型时，应当用"业务复杂度 × 合规要求"两维矩阵判断：

KAG vs GraphRAG 选型决策
═══════════════════════════════════════════════════════════════

                  业务复杂度低        业务复杂度高
                  ────────────        ────────────
  合规要求高      传统 RAG           KAG
                 (内部知识库)       (金融/医疗/法律)
                      │                  │
                      ▼                  ▼
                 不需要图谱         严格 Schema + 推理
                 简单 Embedding     形式化知识 + 业务本体

                  业务复杂度低        业务复杂度高
                  ────────────        ────────────
  合规要求低      传统 RAG           GraphRAG / LightRAG
                 (FAQ 问答)         (研究/分析)
                      │                  │
                      ▼                  ▼
                 简单召回            灵活图谱 + 探索
                 不需要形式化        自由抽取 + 社区

13.7 KAG 工程落地的关键挑战

KAG 在企业落地也面临挑战：

挑战 1：Schema 定义成本。领域本体定义需要业务专家 + 知识工程师联合工作，1-2 周起步。中小企业可能难以承担。

挑战 2：LLM 抽取的"严格性"。即使有 Schema 约束，LLM 仍可能输出"勉强符合"但实际不符的实体/关系。需要后处理校验层。

挑战 3：图谱运维。图谱的"增删改查"比传统数据库复杂，需要专门的图谱运维工具链。

挑战 4：性能。严格的图查询（SPARQL / Cypher）在亿级图谱上响应时间长，需要图数据库优化（索引、缓存、并行）。

KAG 的"Schema-first"哲学把 RAG 从"通用技术玩具"推向"专业业务系统"。这一范式在金融、医疗、法律等"准确性即生命"的领域有不可替代的价值。

KAG 的四层架构让"专业领域 RAG"有了清晰的方法论支撑。

垂直领域 RAG 的"Schema-first"哲学与通用 RAG 的"Schema-less"形成鲜明对比。这一差异决定了 KAG 在专业领域的不可替代性。

Schema-first 带来的"形式化推理"是垂直领域 RAG 的核心优势。

十四、Self-Ask / ReAct 检索链：推理与检索解耦

2022-2023 年，Self-Ask 与 ReAct 的出现标志着 RAG 从"单步检索"走向"多步推理式检索"。这两种范式把"思考（Reasoning）"与"动作（Acting，包括检索）"显式解耦，让 LLM 能像人类一样"边思考边查资料"。本章从架构层面深入剖析 Self-Ask 与 ReAct 的核心思想、实现机制与差异。

14.1 范式跃迁：从"检索-生成"到"推理-检索-生成"

传统 RAG 流程是"retrieve-then-read"：先一次性检索 Top-K 文档，然后送 LLM 生成。这种"单步检索"在多跳问题上失效（见第二章）。Self-Ask 与 ReAct 引入"推理-检索交替"的范式：

传统 RAG vs Self-Ask / ReAct 范式对比
═══════════════════════════════════════════════════════════════

  传统 RAG (retrieve-then-read):
  ──────────────────────────────
  Query ──► 一次性检索 ──► Top-K 文档 ──► LLM 生成 ──► 答案
            (单步)

  Self-Ask (推理-检索交替):
  ──────────────────────────────
  Query ──► 推理(我需要知道 X?) ──► 检索 X ──► 推理(基于 X,我还需要 Y?) ──► 检索 Y ──► ... ──► 推理(够了,综合答案) ──► 答案
            (多步,显式问句)

  ReAct (Thought-Action-Observation 循环):
  ──────────────────────────────
  Query ──► Thought(下一步动作) ──► Action(Search X) ──► Observation(检索结果) ──► Thought(下一步动作) ──► ... ──► Thought(可以回答了) ──► Action(Finish) ──► 答案
            (多步,显式思维链)

14.2 Self-Ask：显式问句驱动的多跳检索

Self-Ask 由谷歌研究院在 2022 年提出。它的核心思想是：让 LLM 在推理过程中显式生成"我需要问的问题"，触发检索动作。这一设计让多跳问题的每一步都显式可追溯。

Self-Ask 的 Prompt 模板：

Self-Ask Prompt 模板
═══════════════════════════════════════════════════════════════

  问: {用户 Query}

  让我们一步一步思考,中间可能需要问一些子问题:

  问: X 是什么? (Follow up needed)
  子问: X 是什么?
  答: X 是 Y。

  问: 接下来,Z 是什么? (Follow up needed)
  子问: Z 是什么?
  答: Z 是 W。

  问: 回到原问题,综合 Y 和 W,答案是什么?
  答: 综合以上,答案是 ...

Self-Ask 的关键机制是"Follow up needed"信号——LLM 在每一步推理后判断"我是否需要更多子信息"。如果需要，就生成子问句触发检索；如果不需要，就基于已有信息生成答案。

Self-Ask 的工程实现：

Self-Ask 检索循环伪代码
═══════════════════════════════════════════════════════════════

  def self_ask(query, max_steps=5):
      context = []
      question = query
      for step in range(max_steps):
          # 推理: LLM 评估是否需要 follow up
          response = llm(
              f"问: {question}\n"
              f"已知信息: {context}\n"
              f"是否需要 follow up? 如果是,生成子问。"
          )
          if "Follow up needed" not in response:
              # 不需要 follow up,返回最终答案
              return parse_final_answer(response)
          # 提取子问句
          sub_question = parse_sub_question(response)
          # 检索子问句
          sub_answer = retrieve_and_answer(sub_question)
          # 累积到 context
          context.append((sub_question, sub_answer))
          # 下一轮:基于新信息继续推理
          question = query  # 始终围绕原问题
      return llm(f"基于所有信息回答: {query}")

14.3 ReAct：Thought-Action-Observation 三元组

ReAct（Reasoning + Acting）由 Princeton & Google 在 2022 年底提出，发表在 ICLR 2023。它把"思考"与"动作"形式化为三个槽位：

ReAct Thought-Action-Observation 范式
═══════════════════════════════════════════════════════════════

  Thought:  推理/规划("我需要知道 X 才能回答原问题")
  Action:   执行动作("Search[X]" / "Lookup[X]" / "Finish[answer]")
  Observation:  动作执行结果("搜索结果: X = Y")

  完整执行轨迹示例:
  ─────────────────

  Q: 苹果公司现任 CEO 的妻子写过什么小说?

  Thought 1: 我需要先找到苹果公司现任 CEO 是谁。
  Action 1:  Search[苹果公司现任 CEO]
  Obs 1:    蒂姆·库克 (Tim Cook) 自 2011 年起担任 CEO。

  Thought 2: 现在我需要知道蒂姆·库克的妻子是谁。
  Action 2:  Search[蒂姆·库克 妻子]
  Obs 2:    蒂姆·库克是公开的同性恋,没有传统意义上的妻子。

  Thought 3: 这个问题的前提是错的。我应该礼貌地指出。
  Action 3:  Finish[蒂姆·库克没有传统意义上的妻子,问题前提不成立。]

ReAct 的核心优势是"可解释性"——Thought-Action-Observation 三元组天然形成可追溯的推理链，用户和开发者都能看到 LLM "是如何思考的"。这与 Self-Ask 的"子问句"风格相比，ReAct 提供了更细粒度的过程可见性。

14.4 ReAct 的工程实现

ReAct 的工程实现通常使用 LangChain / LlamaIndex 的 Agent 框架：

ReAct Agent 架构
═══════════════════════════════════════════════════════════════

  ┌──────────────────────────────────┐
  │  ReAct Agent (核心循环)          │
  │                                   │
  │  1. 接收 Query                    │
  │  2. 调用 LLM 生成 Thought+Action │
  │  3. 解析 Action 类型              │
  │     ├─ Search → 调用检索器       │
  │     ├─ Lookup → 调用数据库       │
  │     ├─ Calculate → 调用计算器    │
  │     └─ Finish → 终止循环         │
  │  4. Observation 反馈给 LLM       │
  │  5. 重复 2-4 直到 Finish         │
  └────────────┬─────────────────────┘
               │
   ┌───────────┼───────────┐
   ▼           ▼           ▼
  检索器     数据库       计算器
  (向量/BM25) (SQL/KV)  (Python/Code)

一个标准 ReAct Agent 的核心循环代码：

# ReAct 核心循环 (LangChain 风格)
def react_agent(query, tools, max_iters=10):
    scratchpad = ""  # 累积 Thought/Action/Observation
    for i in range(max_iters):
        # 1. LLM 生成 Thought + Action
        response = llm(
            REACT_PROMPT.format(
                query=query,
                tools=tool_descriptions,
                scratchpad=scratchpad
            )
        )
        thought = parse_thought(response)
        action, action_input = parse_action(response)
        # 2. 执行 Action
        if action == "Finish":
            return action_input  # 返回最终答案
        elif action in tools:
            observation = tools[action].run(action_input)
        else:
            observation = "Invalid action"
        # 3. 累积到 scratchpad
        scratchpad += f"Thought: {thought}\n"
        scratchpad += f"Action: {action}[{action_input}]\n"
        scratchpad += f"Observation: {observation}\n"
    return "Max iterations reached"

14.5 Self-Ask vs ReAct：差异与选型

Self-Ask 与 ReAct 在哲学上很接近，但工程实现有差异：

14.6 工程实践的常见问题

Self-Ask / ReAct 在生产落地中常遇到五个问题：

问题 1：无限循环。LLM 可能在某一步陷入循环，反复问类似问题。解决方案：max_iters 上限 + 循环检测（已检索子问句去重）。

问题 2：检索漂移（见第二章）。每步检索的 Query 都基于上一步的中间结果，漂移会累积。解决方案：原始 Query 锚定 + 中间结果摘要。

问题 3：Token 爆炸。ReAct 的 scratchpad 会累积所有历史，10 步后 prompt 可能超过 5K token。解决方案：scratchpad 摘要压缩 + 关键证据保留。

问题 4：工具调用失败。检索器可能返回空结果或无关文档。解决方案：空结果重试 + 工具失败重定向。

问题 5：成本高。ReAct 每步都调用 LLM，10 步 = 10 次 LLM 调用，token 消耗 5-10 倍于传统 RAG。解决方案：用小模型做"判断步" + 大模型做"综合步"。

14.7 Self-Ask / ReAct 的演进：IRCoT 与 ReWOO

在 Self-Ask 和 ReAct 之后，学术界进一步优化：

IRCoT（Interleaving Retrieval with CoT）。把 CoT（思维链）与检索交错进行，但 CoT 不显式生成子问句，而是用 CoT 的中间推理步骤作为 Query。这一设计减少了 token 消耗，同时保留了多步检索能力。

ReWOO（Reasoning WithOut Observation）。ReAct 的改进版，把"推理"与"检索"解耦为两个独立阶段——先规划所有检索动作（不执行），再批量执行。优势是减少 LLM 调用次数（从 N 步降到 1 步），适合高并发场景。

RA-DIT（Retrieval-Augmented Dual Instruction Tuning）。Meta 提出的方法，把检索能力通过指令微调注入到 LLM 本身，让 LLM "内化"检索决策，减少对外部 Agent 框架的依赖。

Self-Ask 与 ReAct 的核心思想是"推理-检索解耦"——让 LLM 显式生成 Thought/Action/Observation 循环，把"思考"与"动作"分开。这一范式在多跳问题上显著优于 retrieve-then-read。

Thought-Action-Observation 三元组天然形成可追溯的推理链，是 ReAct 范式的精髓。

Self-Ask 与 ReAct 代表"推理-检索解耦"的两种实现风格。Self-Ask 显式生成子问句，ReAct 用 Thought-Action-Observation 三元组。两者在工程实现与可解释性上各有侧重。

两种范式代表"实现简洁性 vs 可解释性"的不同权衡。

十五、Plan-and-Execute RAG：检索计划生成

Self-Ask / ReAct 范式的"边走边看"虽然灵活，但缺乏全局规划。Plan-and-Execute（2023 年由 LangChain 提出）把"决策"和"执行"解耦为两阶段，先用一个 LLM 生成完整的检索计划，再逐步执行。这种"两步走"范式在长链路问题上显著更稳定。本章深入剖析 Plan-and-Execute 的核心思想、架构设计与工程实践。

15.1 Plan-and-Execute 的核心抽象

Plan-and-Execute 的核心思想是把多步推理解耦为"规划"和"执行"两个独立阶段：

Plan-and-Execute 两阶段架构
═══════════════════════════════════════════════════════════════

  阶段 1: 规划 (Planner)
  ───────────────────
  输入: 用户 Query
  输出: 步骤列表 (Plan)
       │
       │  LLM (Planner) 生成:
       │  Step 1: 检索 "X 的概念"
       │  Step 2: 检索 "X 的关键参数"
       │  Step 3: 计算 "X 的最终结果"
       │  Step 4: 综合所有信息生成答案
       │
       ▼
  阶段 2: 执行 (Executor)
  ───────────────────
  输入: 步骤列表
  输出: 每步结果 → 最终答案
       │
       │  按步骤执行:
       │  执行 Step 1 → 结果 A
       │  执行 Step 2 → 结果 B (基于 A)
       │  执行 Step 3 → 结果 C (基于 A,B)
       │  执行 Step 4 → 最终答案
       │
       ▼
  最终答案

  与 ReAct 的本质区别:
  ───────────────────
  ReAct: 每步都让 LLM 重新规划 → "边想边做"
  Plan-and-Execute: 先一次性规划完 → "先想后做"

15.2 为什么需要"先规划后执行"？

ReAct 的"边想边做"在工程上有三个痛点：

痛点 1：决策漂移。LLM 在每一步都可能改变方向，导致整体路径不一致。ReAct 的执行轨迹经常是"绕圈子"——前 3 步检索到的信息到第 4 步被推翻。

痛点 2：长链路不稳定。超过 5 跳后，ReAct 的成功率显著下降。LLM 在长链路上容易"忘记"原始目标。

痛点 3：Token 浪费。每步都让 LLM 重新"思考一遍"，10 步 = 10 次完整思考，token 消耗巨大。

Plan-and-Execute 通过"先一次性规划完"解决这三大痛点：

解决 1：路径稳定。Plan 在执行前就确定了，Executor 只负责执行，不重新规划。这避免了"边走边改"的混乱。

解决 2：长链路友好。Planner 看到的是"全图"，能规划出"先查 A，再查 B，最后综合 C"的全局最优路径。

解决 3：Token 优化。Planner 一次生成完整 Plan，Executor 在每步只需执行（少量 token 决策），整体 token 消耗降低 30-50%。

15.3 Planner 的实现：Plan 生成 Prompt

Planner 的核心是"如何让 LLM 生成合理的 Plan"。典型 Prompt 设计：

Planner Prompt 模板
═══════════════════════════════════════════════════════════════

  你是一个任务规划专家。
  用户问题: {用户 Query}

  可用工具:
  1. search[query] - 搜索相关信息
  2. lookup[key] - 查找具体数据
  3. calculate[expression] - 数学计算
  4. finish[answer] - 完成并输出答案

  请将用户问题分解为 3-7 步可执行的计划:
  每步包含 tool 和 input。

  输出格式 (JSON):
  {
    "plan": [
      {"step": 1, "tool": "search", "input": "X 的概念"},
      {"step": 2, "tool": "search", "input": "X 的关键参数"},
      {"step": 3, "tool": "calculate", "input": "X * Y"},
      {"step": 4, "tool": "finish", "input": "综合答案"}
    ]
  }

15.4 Executor 的实现：ReAct 风格逐步执行

Executor 接收 Plan 后，按步骤执行。每一步可以是简单的工具调用，也可以是 ReAct 风格的"小循环"：

Plan-and-Execute Executor 流程
═══════════════════════════════════════════════════════════════

  Plan = [
    {step: 1, tool: "search", input: "X 的概念"},
    {step: 2, tool: "search", input: "X 的关键参数"},
    {step: 3, tool: "calculate", input: "X * Y"},
    {step: 4, tool: "finish", input: "综合答案"}
  ]

  执行流程:
  ─────────
  current_step = 0
  results = {}

  while current_step < len(Plan):
      step = Plan[current_step]
      # 执行当前步骤
      if step.tool == "search":
          result = search_engine.search(step.input)
      elif step.tool == "calculate":
          result = calculator.calculate(step.input)
      elif step.tool == "finish":
          return step.input  # 最终答案
      # 累积结果
      results[current_step] = result
      # Re-plan? (可选: 处理 Plan 与现实不一致)
      if should_replan(results):
          Plan = planner.replan(Plan, results)
          current_step = 0  # 重新开始
      else:
          current_step += 1

  return results

15.5 Replan 机制：处理计划与现实的不一致

Plan-and-Execute 的一个进阶设计是"Replan"——当某步执行结果与 Plan 假设不符时，重新规划剩余步骤。例如：

原 Plan：检索"X 的最新数据" → 计算 → 答案。但实际检索发现"X 的最新数据是 2024 年的，而用户问的是 2025 年"——这时需要 Replan，把 Plan 改为"检索 2025 年的新数据"。

Replan 触发条件与处理
═══════════════════════════════════════════════════════════════

  触发条件:
  ─────────
  ① 当前步骤结果与 Plan 假设不一致
     "我以为 X 是 Y,实际是 Z"
  ② 后续步骤的 input 依赖错误的中间结果
     "Plan 假设 A,实际 A 不存在"
  ③ 用户反馈当前路径不靠谱
     "这一步的答案不对"

  处理流程:
  ─────────
  触发 Replan ──► 调用 Planner (传入新信息)
              ──► 生成新 Plan (或修订 Plan)
              ──► 继续执行

  工程实现:
  ─────────
  维护一个"状态对象" {original_query, plan,
                       completed_steps, current_results}
  Replan 时把状态对象作为 Planner 的输入

Replan 机制让 Plan-and-Execute 在"Plan 不完全准确"时也能自适应，是其相比 ReAct 的核心优势之一。

15.6 Plan-and-Execute 的进阶设计

工业级 Plan-and-Execute 系统的常见进阶设计：

设计 1：层次化 Plan。把 Plan 组织为树形结构——主干 Plan + 子 Plan。例如"分析财报"主干 Plan 是"加载财报 → 提取数据 → 生成分析"，每个子 Plan 自己又是一个 Plan-and-Execute 子任务。

设计 2：并行 Plan。当 Plan 中某些步骤无依赖关系时，并行执行。例如"对比 A 和 B 的营收"可以并行检索"2024 年 A 营收"和"2024 年 B 营收"，再合并结果。

设计 3：Plan 缓存。对常见 Query 类型缓存 Plan，避免每次重新规划。例如"对比两家公司"类型的 Plan 模板可以缓存。

设计 4：人类反馈。在 Plan 生成后、执行前，允许人类审核和修改 Plan。这一设计在严肃业务场景（金融分析、医疗诊断）尤其重要。

15.7 Plan-and-Execute 的局限与替代方案

Plan-and-Execute 也有局限：

局限 1：Plan 错误传播。如果 Planner 生成的 Plan 第一步就错了，后续步骤都会受影响。虽然有 Replan 机制，但 Replan 本身需要 LLM 调用，有额外成本。

局限 2：难以处理"未知问题"。Planner 只能基于已有知识规划，对"未知领域"（"探索 X 是什么"）的 Plan 质量差。

局限 3：执行步骤固定。Plan 一旦生成，执行器倾向于"按部就班"，灵活性不如 ReAct。

针对这些局限，业界演化出两个改进方向：

方向 1：Plan-and-Execute + ReAct 混合。Plan 做粗粒度规划，ReAct 做细粒度执行。例如 Plan 说"检索 X"，ReAct 在检索时自主决定"用什么 Query 检索"。

方向 2：Multi-Agent 协作。下一章将深入讨论。把 Planner、Executor、Critic 设计为独立 Agent 协作，每个 Agent 负责自己擅长的环节。

十六、DeepResearch 系统架构：OpenAI / Anthropic / Gemini Deep Research

2025 年 2 月，OpenAI 推出 Deep Research 模式，紧接着 Anthropic 推出 Research 功能，Google 也发布了 Gemini Deep Research。三家头部 AI 公司的"深度研究"产品在用户层面表现惊艳，背后是新一代 Agentic RAG 系统的工程化落地。本章从架构层面深入剖析三大 DeepResearch 系统的设计哲学、模块拆解与技术取舍。

16.1 DeepResearch 范式的核心特征

DeepResearch 不同于传统 RAG 问答，它面向"深度研究类问题"——"调研 X 市场"、"对比 Y 和 Z"、"分析 W 行业近五年趋势"。这类问题有四个共性：

特征 1：长链路推理。通常需要 5-20 步推理，包含检索、阅读、对比、归纳、综合多个动作。

特征 2：多源信息融合。需要从 web、PDF、数据库、API 等多种来源获取信息，不能依赖单一知识库。

特征 3：质量要求高。用户期待"研究报告级别"的输出，包含引用、数据、可视化、结构化分析。

特征 4：耗时容忍。用户愿意等待 5-30 分钟换取高质量答案，与实时问答的 SLA 完全不同。

16.2 OpenAI Deep Research 架构剖析

OpenAI Deep Research 基于 o3 / o4-mini 模型，专为深度研究任务设计。其架构核心：

OpenAI Deep Research 内部架构（推测）
═══════════════════════════════════════════════════════════════

  ┌─────────────────────────────────────┐
  │  任务理解层 (Task Understanding)     │
  │  · Query 解析                       │
  │  · 任务类型分类                     │
  │  · 隐含需求提取                     │
  └──────────────┬──────────────────────┘
                 │
                 ▼
  ┌─────────────────────────────────────┐
  │  研究规划层 (Research Planning)      │
  │  · 子任务分解 (5-15 个)             │
  │  · 研究路径规划                     │
  │  · 信息源优先级                     │
  └──────────────┬──────────────────────┘
                 │
                 ▼
  ┌─────────────────────────────────────┐
  │  信息检索层 (Information Retrieval) │
  │  · Web 搜索 (Bing)                  │
  │  · 文档阅读 (多模态)                │
  │  · 数据抽取 (表格/图表)             │
  │  · API 调用 (结构化数据)            │
  └──────────────┬──────────────────────┘
                 │
                 ▼
  ┌─────────────────────────────────────┐
  │  推理综合层 (Reasoning & Synthesis)  │
  │  · 跨源信息融合                    │
  │  · 证据链构建                      │
  │  · 多视角分析                      │
  │  · 矛盾检测与调和                  │
  └──────────────┬──────────────────────┘
                 │
                 ▼
  ┌─────────────────────────────────────┐
  │  报告生成层 (Report Generation)      │
  │  · 结构化大纲                      │
  │  · 多章节撰写                      │
  │  · 引用标注                        │
  │  · 可视化建议                      │
  └──────────────┬──────────────────────┘
                 │
                 ▼
  最终研究报告

OpenAI Deep Research 的核心特点是o3 模型的强推理能力 + 工具调用 Agent 框架。o3 具备原生工具调用（web search、file search、code execution）和多步推理能力，能在 5-30 分钟内完成传统需要人类研究员数小时的工作。

16.3 Anthropic Claude Research 架构剖析

Anthropic 的 Research 模式基于 Claude 3.7 Sonnet + Computer Use 能力。其架构与 OpenAI 类似，但有几个显著差异：

差异 1：研究流程更透明。Claude Research 把"思考过程"显式展示给用户，每一步的推理都可见，符合 Anthropic 一贯的"可解释性优先"哲学。

差异 2：长上下文建模。Claude 200K token 的上下文窗口让 Claude Research 能"读完整份文档"再做分析，而不是仅靠检索片段。这对长文档研究（法规、论文）特别有利。

差异 3：研究质量控制。Claude Research 强调"质量而非速度"——单次研究可能耗时 10-20 分钟，但输出质量更高，包含更多交叉验证。

16.4 Google Gemini Deep Research 架构剖析

Google 的 Gemini Deep Research 基于 Gemini 2.5 Pro + 谷歌搜索生态。其架构特色：

特色 1：原生多模态。Gemini Deep Research 能直接处理图像、视频、音频等多媒体，生成"图文并茂"的研究报告。

特色 2：Google 生态整合。原生集成 Google Search、Gmail、Docs、Sheets 等生态数据，能研究用户的个人化数据（"分析我过去一年的邮件主题"）。

特色 3：1M token 上下文。Gemini 的超长上下文窗口让其能"一次性读完"大型研究材料，减少了"分块检索"的信息损失。

16.5 三大系统的架构对比

从架构层面，三大 DeepResearch 系统的差异：

16.6 DeepResearch 的核心工程挑战

DeepResearch 系统的工程实现面临五大挑战：

挑战 1：长链路稳定性。5-20 步推理中，任何一步失败都可能导致整个研究失败。必须设计Checkpoint + 重试 + Replan 机制。

挑战 2：上下文管理。长链路推理累积大量中间结果，Token 消耗呈线性增长。必须设计上下文压缩 + 关键证据保留机制。

挑战 3：质量控制。多步推理容易产生"幻觉积累"——前一步的错误在后续步骤被放大。必须设计事实校验 + 引用追溯 + 自相矛盾检测机制。

挑战 4：成本控制。单次研究消耗 100K-1M token，成本 1-10 美元。需要模型路由（小模型做粗筛 + 大模型做综合）+ 缓存机制。

挑战 5：用户交互。深度研究耗时 5-30 分钟，期间用户需要看到进度，否则会"以为卡死"。必须设计实时进度展示 + 阶段性结果预览 + 中途干预机制。

16.7 自建 DeepResearch 系统的工程路径

对希望自建 DeepResearch 系统的架构师，推荐的工程路径：

自建 DeepResearch 系统的技术栈
═══════════════════════════════════════════════════════════════

  基础层 (Foundation):
  ─────────────────
  · LLM: GPT-4 / Claude / Qwen-Max / DeepSeek-R1
  · Agent 框架: LangGraph / AutoGen / CrewAI
  · 工具调用: Function Calling / Tool Use

  数据层 (Data):
  ────────────
  · 向量库: Qdrant / Milvus / Weaviate
  · 图谱库: Neo4j / TuGraph (可选, 全局问题)
  · 文档存储: S3 / OSS / MinIO
  · 缓存: Redis (Plan / 检索结果)

  能力层 (Capabilities):
  ───────────────────
  · Web 搜索: SerpAPI / Tavily / Bing API
  · PDF 解析: MinerU / Marker
  · 公式识别: LaTeX-OCR
  · 表格理解: Table-as-Context
  · 多模态: Qwen-VL / GPT-4V

  应用层 (Application):
  ───────────────────
  · Web UI: 流式进度 + 阶段性展示
  · API: 异步任务 + Webhook 通知
  · 监控: 成本 / 时延 / 质量 / 失败率

自建 DeepResearch 系统的最小可行版本（MVP）可以先用 LangGraph + Claude/GPT-4 + Tavily 搜索快速搭建，先验证业务价值，再根据反馈迭代优化。直接照搬 OpenAI/Anthropic 的"全功能"是过度工程化。

三大 DeepResearch 系统的架构虽然细节不同，但核心模式高度一致：任务理解 → 研究规划 → 多源检索 → 推理综合 → 报告生成。这种范式代表了 RAG 的"终极形态"。

三大系统的差异在于"底座模型 + 工具生态 + 输出风格"，但范式一致。

Plan-and-Execute 的"先规划后执行"哲学解决了 ReAct "边走边绕"的问题。Planner 一次性生成完整 Plan，Executor 按步骤执行，让长链路推理更稳定。

Replan 机制是 Plan-and-Execute 相比 ReAct 的核心优势——它让系统在 Plan 不准确时能自适应。

Plan-and-Execute 与 ReAct 的核心区别是"规划时机"——前者一次性规划完整路径，后者边走边看。两种范式各有适用场景，架构师应根据问题复杂度选择。

三种范式代表"灵活性 vs 稳定性 vs 能力"的不同权衡。

十七、Multi-Agent 协作 RAG：检索 / 评估 / 生成 Agent

当 RAG 任务复杂度突破"单 Agent 能处理"的上限，Multi-Agent 协作就成为必然选择。2024 年起，CrewAI、AutoGen、LangGraph 等 Multi-Agent 框架相继成熟，让"多个专业 Agent 协作完成复杂 RAG 任务"从理论走向工程实践。本章从架构层面深入剖析 Multi-Agent RAG 的核心思想、协作机制与设计模式。

17.1 为什么需要 Multi-Agent RAG？

单 Agent（Self-Ask / ReAct / Plan-and-Execute）在面对"超复杂 RAG 任务"时会出现三个瓶颈：

瓶颈 1：能力溢出。一个 Agent 同时负责"规划 + 检索 + 评估 + 生成 + 反思"，prompt 越来越长，能力开始"溢出"——超过 LLM 上下文窗口，能力互相干扰。

瓶颈 2：角色冲突。"既要检索又要评估"的 Agent 在设计时存在角色冲突——检索要求"召回全"，评估要求"召回准"，两者目标不同，挤在同一个 Agent 里会妥协。

瓶颈 3：可扩展性差。单 Agent 系统难以"加新能力"——每加一种新检索源、新评估方法，都需要修改 Agent 的 prompt 和工具列表。

Multi-Agent RAG 通过"专业化分工 + 协作编排"解决这三大瓶颈。

17.2 Multi-Agent RAG 的核心架构

一个典型的 Multi-Agent RAG 系统由三类核心 Agent 组成：

Multi-Agent RAG 核心架构
═══════════════════════════════════════════════════════════════

  ┌──────────────────────────────────────────────┐
  │  Orchestrator (编排 Agent)                    │
  │  · 任务分解                                   │
  │  · Agent 调度                                 │
  │  · 结果汇总                                   │
  └──────────┬───────────────────────────────────┘
             │
   ┌─────────┼─────────┬─────────────┐
   ▼         ▼         ▼             ▼
┌──────┐ ┌──────┐ ┌──────┐    ┌──────────┐
│检索  │ │评估  │ │生成  │ ...│  反思     │
│Agent │ │Agent │ │Agent │    │  Agent   │
│      │ │      │ │      │    │          │
│工具: │ │工具: │ │工具: │    │ 工具:    │
│向量库│ │Rerank│ │LLM   │    │ 自我评估 │
│Web   │ │FactCC│ │Prompt│    │ 错误检测 │
│DB    │ │规则  │ │      │    │          │
└──┬───┘ └──┬───┘ └──┬───┘    └────┬─────┘
   │        │        │             │
   └────────┴────────┴─────────────┘
             │
             ▼
         最终答案

17.3 三大核心 Agent 的职责拆解

检索 Agent（Retriever Agent）。职责是"找出相关信息"。它的工具集包括：向量库检索、BM25 检索、Web 搜索、数据库查询、API 调用。检索 Agent 的设计原则是"召回优先"——宁多勿漏，评估由下游 Agent 完成。

评估 Agent（Evaluator Agent）。职责是"评估检索到的信息质量"。它的工具集包括：Reranker、FactCC 事实性检测、规则检查、引用追溯。评估 Agent 输出"信息分级标签"（完全可信 / 部分可信 / 不可信）和"关键证据摘要"。

生成 Agent（Generator Agent）。职责是"基于可信证据生成答案"。它的工具集主要是 LLM 本身 + 提示模板。生成 Agent 只接受评估 Agent 标记为"可信"的证据，避免被不可信信息污染。

三个 Agent 的协作流程：

Multi-Agent 协作流程（Linear 模式）
═══════════════════════════════════════════════════════════════

  1. Orchestrator 接收 Query
       │
       ▼
  2. Orchestrator 分解任务 → 检索任务
       │
       ▼
  3. 检索 Agent 执行
       │   · 调用向量库/Web/DB
       │   · 返回候选证据集合
       │
       ▼
  4. Orchestrator 传递结果 → 评估任务
       │
       ▼
  5. 评估 Agent 执行
       │   · 对每条证据打分
       │   · 标记可信/不可信
       │   · 提取关键证据摘要
       │
       ▼
  6. Orchestrator 传递结果 → 生成任务
       │
       ▼
  7. 生成 Agent 执行
       │   · 基于可信证据生成答案
       │   · 标注引用
       │
       ▼
  8. Orchestrator 汇总 → 最终答案

  优势:
  · 各 Agent 专业化,prompt 简洁
  · 评估与生成分离,降低幻觉
  · 可独立扩展(加新检索源不影响其他 Agent)
  劣势:
  · 串行流程,延迟较高
  · Orchestrator 单点

17.4 协作模式：Linear / Hierarchical / Peer-to-Peer

Multi-Agent 协作有三种模式：

Linear 模式（线性）。Agent 按固定顺序串行执行。简单稳定，但灵活性差。

Hierarchical 模式（层级）。存在 Manager Agent，统一调度 Worker Agents。类似传统"管理者-执行者"结构，适合任务可分解的场景。

Peer-to-Peer 模式（点对点）。Agent 之间对等通信，自主决定下一步调用哪个 Agent。灵活但难调试。

三种协作模式对比
═══════════════════════════════════════════════════════════════

  Linear 模式:
  ───────────
  Agent1 → Agent2 → Agent3 → Agent4
  适用: 流程固定的 RAG 任务
  优点: 简单、可预测
  缺点: 缺乏灵活性

  Hierarchical 模式:
  ──────────────────
        Manager
       /  |  \
      ↓   ↓   ↓
    A1   A2   A3
  适用: 任务可分解的复杂研究
  优点: 集中调度,流程清晰
  缺点: Manager 成为瓶颈

  Peer-to-Peer 模式:
  ──────────────────
    A1 ←→ A2
     ↕     ↕
    A3 ←→ A4
  适用: 探索性、协作性任务
  优点: 最灵活,可涌现新行为
  缺点: 难调试、可能死循环

17.5 CrewAI 与 AutoGen：主流 Multi-Agent 框架

当前主流的 Multi-Agent 框架：

17.6 CrewAI 的角色化协作范式

CrewAI 把 Multi-Agent 协作抽象为"角色（Role）+ 任务（Task）+ 团队（Crew）"三个概念：

CrewAI 协作范式伪代码
═══════════════════════════════════════════════════════════════

  from crewai import Agent, Task, Crew

  # 1. 定义 Agent (角色)
  retriever = Agent(
      role="检索专家",
      goal="找到与 Query 相关的所有信息",
      backstory="你是一个专业的检索专家,擅长从多个数据源召回信息",
      tools=[vector_search, web_search, db_query]
  )

  evaluator = Agent(
      role="评估专家",
      goal="评估检索到的信息质量",
      backstory="你是一个严格的事实核查员,对信息质量零容忍",
      tools=[fact_check, rerank, citation_check]
  )

  generator = Agent(
      role="生成专家",
      goal="基于可信信息生成高质量答案",
      backstory="你是一个专业的研究员,擅长综合信息形成报告",
      tools=[]  # 只需 LLM
  )

  # 2. 定义任务
  task1 = Task(
      description="检索 {query} 相关的信息",
      agent=retriever,
      expected_output="候选证据列表"
  )

  task2 = Task(
      description="评估候选证据的可信度",
      agent=evaluator,
      expected_output="可信证据列表(带引用)"
  )

  task3 = Task(
      description="基于可信证据生成最终答案",
      agent=generator,
      expected_output="最终答案 + 引用"
  )

  # 3. 组建团队并执行
  crew = Crew(
      agents=[retriever, evaluator, generator],
      tasks=[task1, task2, task3],
      process=Process.sequential  # 顺序执行
  )

  result = crew.kickoff(inputs={"query": "用户问题"})

17.7 Multi-Agent RAG 的工程挑战

Multi-Agent RAG 在生产落地中面临五大挑战：

挑战 1：Token 消耗爆炸。多个 Agent 各自调用 LLM，token 消耗是单 Agent 的 3-5 倍。解决方案：用小模型做"中间 Agent"+ 大模型做"最终 Agent"。

挑战 2：调试复杂。Multi-Agent 系统的执行轨迹是"图"而非"链"，传统日志调试方法失效。解决方案：LangSmith / Phoenix / Helicone 等可观测工具 + Tracing。

挑战 3：循环风险。Peer-to-Peer 模式下 Agent 可能互相调用形成循环。解决方案：max_iters 上限 + 调用图静态分析。

挑战 4：错误传播。上游 Agent 的错误会被下游 Agent 继承并放大。解决方案：每步独立校验 + 错误隔离。

挑战 5：成本控制。Multi-Agent 系统的"小问题也用大团队"是常见浪费。解决方案：Router Agent 根据问题复杂度动态选择 Agent 数量。

17.8 何时应该上 Multi-Agent？

Multi-Agent 不是"越早越好"，架构师应当用"复杂度阈值"判断：

Multi-Agent 上线判断矩阵
═══════════════════════════════════════════════════════════════

  问题复杂度       推荐方案          理由
  ──────────      ─────────        ─────
  单跳 / 简单      直接 RAG          杀鸡用牛刀
  2-3 跳 / 中等    Self-Ask/ReAct    性价比最高
  4-7 跳 / 复杂    Plan-and-Execute  稳定可控
  8+ 跳 / 超复杂   Multi-Agent       专业分工
  探索性 / 研究级  DeepResearch 系统  多 Agent + 多源

  其他考虑:
  · 团队规模: 小团队建议先单 Agent 跑通
  · 业务价值: ROI 不够时不上 Multi-Agent
  · 维护能力: Multi-Agent 调试复杂,需要可观测基础设施

Multi-Agent RAG 的核心是"专业化分工 + 协作编排"。检索 Agent、评估 Agent、生成 Agent 各自负责擅长的工作，避免单 Agent 的能力溢出。

Multi-Agent 协作流程体现了"专业化分工"的优势——每种 Agent 只做自己最擅长的事。

Multi-Agent 协作有三种模式：Linear 串行、Hierarchical 层级、Peer-to-Peer 点对点。架构师应根据"任务可分解性 + 流程确定性"两维度选型。

三种模式在"灵活性 vs 稳定性"上各有侧重，不存在"最好"。

十八、RAG 评估体系 2.0：RAGAS / TruLens / DeepEval 多维评估

在第四章我们剖析了传统 RAGAS 评估体系的失真问题。本章进一步深入"评估体系 2.0"的具体实现——如何构建多维度、细粒度、人机融合的工业级 RAG 评估体系。我们将对比 RAGAS、TruLens、DeepEval 三大主流框架，并给出生产级评估流水线的完整架构。

18.1 评估体系 2.0 的核心原则

从传统 RAGAS 的"四个指标"演进到评估体系 2.0，核心是"五个转变"：

传统 RAGAS → 评估体系 2.0 的五个转变
═══════════════════════════════════════════════════════════════

  转变 1: 单维度 → 多维度
  ──────────────────────
  传统: 4 个全局指标
  2.0:  分层多维(检索/生成/端到端/过程/人类)

  转变 2: 粗粒度 → 细粒度
  ──────────────────────
  传统: 问题级单一分数
  2.0:  方面级 + 步骤级 + token 级

  转变 3: 静态评估 → 动态评估
  ──────────────────────
  传统: 离线跑测试集
  2.0:  生产环境持续评估 + A/B Testing

  转变 4: 机器自动 → 人机融合
  ──────────────────────
  传统: 纯 LLM-as-a-Judge
  2.0:  LLM 初筛 + 人类精校 + 众包评估

  转变 5: 单一指标 → 业务对齐
  ──────────────────────
  传统: Faithfulness 0.9
  2.0:  用户满意度 + 业务 KPI(转化率/解决率)

18.2 RAGAS 2.0：细粒度增强版

RAGAS 在 2024-2025 年快速迭代，引入了多个细粒度指标：

18.3 TruLens：可解释评估框架

TruLens（由 TruEra 开源）的核心理念是"评估反馈循环"——把评估嵌入到 RAG 系统的每次运行中，实时反馈质量问题。

TruLens 评估反馈循环
═══════════════════════════════════════════════════════════════

  RAG 系统
     │
     ▼
  每次运行被 TruLens 记录
     │
     ├─► 输入: Query
     ├─► 检索结果: 5 个 chunks
     ├─► 检索评估: Context Relevance 0.85
     ├─► 生成评估: Faithfulness 0.92
     ├─► 端到端: Answer Correctness 0.88
     │
     ▼
  记录到 TruLens Dashboard
     │
     ▼
  反馈给开发者:
  · 哪些 Query 表现差
  · 哪些文档来源质量低
  · 哪些检索模式效率低
     │
     ▼
  持续优化

TruLens 的核心功能是 "feedback functions"——把评估指标作为函数嵌入 RAG 系统，每次运行时自动打分，结果可视化。开发者可以一眼看到"哪些 Query 长期表现差"，针对性优化。

18.4 DeepEval：LLM 单元测试框架

DeepEval 把 RAG 评估抽象为"LLM 单元测试"——使用类似 pytest 的接口，让 LLM 应用测试和传统软件测试一样自然。

DeepEval 单元测试风格
═══════════════════════════════════════════════════════════════

  from deepeval import evaluate
  from deepeval.metrics import (
      ContextualPrecisionMetric,
      ContextualRecallMetric,
      FaithfulnessMetric,
      AnswerRelevancyMetric
  )
  from deepeval.test_case import LLMTestCase

  def test_rag_pipeline():
      # 准备测试用例
      test_case = LLMTestCase(
          input="X 公司的毛利率是多少?",
          actual_output=rag_system.query("X 公司的毛利率是多少?"),
          expected_output="X 公司 2024 年毛利率为 40%",
          retrieval_context=[...]  # 检索到的 chunks
      )
      # 运行评估
      evaluate(
          test_cases=[test_case],
          metrics=[
              ContextualPrecisionMetric(threshold=0.8),
              ContextualRecallMetric(threshold=0.7),
              FaithfulnessMetric(threshold=0.9),
              AnswerRelevancyMetric(threshold=0.8)
          ]
      )

  # 像 pytest 一样运行: pytest test_rag.py

DeepEval 的优势是"测试驱动开发"友好——开发者可以像写单元测试一样写 RAG 评估，CI/CD 集成自然，特别适合 DevOps 团队。

18.5 三大框架对比与选型

RAGAS、TruLens、DeepEval 三大框架的定位差异：

18.6 LLM-as-a-Judge 工业化

三大框架的共同基础是 LLM-as-a-Judge——用 LLM 做自动评估。要把 LLM-as-a-Judge 工业化，需要解决三个问题：

问题 1：评判标准的形式化。把人类判断标准转译为 LLM 可执行的评分规则。常用做法是"Rubric Prompt"——给 LLM 一个详细的评分标准，每个分数档有明确的描述。

LLM-as-a-Judge Rubric Prompt 示例
═══════════════════════════════════════════════════════════════

  请评估以下 RAG 答案的忠实度(0-5 分):

  Query: {query}
  Context: {retrieved_chunks}
  Answer: {generated_answer}

  评分标准:
  5 = 所有事实都从 Context 找到,无任何编造
  4 = 主要事实来自 Context,1 个小细节有合理推断
  3 = 大部分事实来自 Context,有 1 处明显编造
  2 = 有一半事实来自 Context,多处编造
  1 = 多数事实无据可查,严重编造
  0 = 完全没有忠实于 Context

  请逐句分析 Answer 中每个事实的来源,然后给出最终分数。
  输出格式: {"score": X, "reason": "..."}

问题 2：评判者一致性。同一个 Query 让多个 LLM 评判，结果应高度一致。工程上常用"多 LLM 投票"——用 3-5 个不同的 LLM 评判，取平均或投票。

问题 3：评判者偏差。LLM-as-a-Judge 有已知偏差：位置偏差（偏好前文）、自我偏好（偏好自己生成的答案）、冗长偏好（偏好长答案）。解决方案：多 LLM + 位置打乱 + 长度归一化。

18.7 A/B Testing 框架

所有 RAG 改进必须经过 A/B Testing。生产级 A/B Testing 框架的关键设计：

RAG A/B Testing 框架
═══════════════════════════════════════════════════════════════

  实验设计:
  ─────────
  · 对照组 (Control):  旧版 RAG
  · 实验组 (Variant): 新版 RAG
  · 流量分配: 通常 90/10 或 80/20 (实验组小流量验证)
  · 关键指标: 用户满意度 / 任务完成率 / 点赞率
  · 护栏指标: P99 延迟 / 失败率 / 成本

  实验执行:
  ─────────
  · 同一 Query 随机路由到 Control 或 Variant
  · 记录所有指标
  · 显著性检验(通常需要 1000+ 样本)

  决策:
  ─────────
  · 提升 ≥ 2% 且显著: 推广
  · 持平: 观察
  · 下降: 回滚

  常见陷阱:
  ─────────
  · 样本量不足: 1-2 周小流量试运行
  · 流量不均: 用 hash(Query) 稳定路由
  · 短期偏差: 至少观察 2 个完整业务周期

18.8 生产级评估流水线

完整的企业级 RAG 评估流水线：

生产级 RAG 评估流水线
═══════════════════════════════════════════════════════════════

  ┌────────────────────────────────────────┐
  │  Layer 1: 在线自动评估                 │
  │  · LLM-as-a-Judge (生产 100% 流量)     │
  │  · 实时打分 + 异常告警                 │
  │  · 记录到评估库                        │
  └─────────────────┬──────────────────────┘
                    │
                    ▼
  ┌────────────────────────────────────────┐
  │  Layer 2: 离线批量评估                 │
  │  · 定期跑测试集 (RAGAS / DeepEval)     │
  │  · A/B Testing                         │
  │  · TruLens Dashboard 持续监控          │
  └─────────────────┬──────────────────────┘
                    │
                    ▼
  ┌────────────────────────────────────────┐
  │  Layer 3: 人类精校                      │
  │  · 高风险 query 人工标注               │
  │  · 众包评估 (Amazon MTurk)             │
  │  · 专家评审 (业务专家 / 领域专家)       │
  └─────────────────┬──────────────────────┘
                    │
                    ▼
  ┌────────────────────────────────────────┐
  │  Layer 4: 业务对齐                      │
  │  · 业务 KPI 联动 (转化率 / 留存率)      │
  │  · 用户调研 + NPS                      │
  │  · A/B Testing 持续迭代                │
  └────────────────────────────────────────┘

十九、生产级可观测：三层监控与漂移检测

当 RAG 系统从 PoC 进入生产，"可观测性"成为系统稳定运行的关键支柱。本章从架构层面深入剖析生产级 RAG 可观测系统的三大支柱：检索质量监控、生成质量监控、端到端质量监控，以及漂移检测、Tracing 系统等关键工程实践。

19.1 可观测性的三大支柱

RAG 可观测性的三大支柱对应系统的三层质量：

RAG 可观测性三大支柱
═══════════════════════════════════════════════════════════════

  ┌────────────────────────────────────┐
  │  ① 检索质量监控                    │
  │  · Context Relevance / Recall     │
  │  · 检索延迟 / QPS                  │
  │  · 向量库健康度                    │
  │  · 检索源覆盖率                    │
  ├────────────────────────────────────┤
  │  ② 生成质量监控                    │
  │  · Faithfulness / Answer Relevancy│
  │  · 幻觉率 / 引用准确率            │
  │  · Token 消耗 / LLM 延迟          │
  │  · LLM API 错误率                 │
  ├────────────────────────────────────┤
  │  ③ 端到端质量监控                  │
  │  · 用户满意度 (点赞 / 点踩)       │
  │  · 任务完成率                      │
  │  · P50/P95/P99 延迟               │
  │  · 业务 KPI 转化率                │
  └────────────────────────────────────┘

  三大支柱的关系:
  ─────────────
  ① 是因(检索质量差 → 答案质量差)
  ② 是果(生成质量反映检索质量)
  ③ 是根(用户满意才是终极标准)

19.2 检索质量监控

检索质量监控的核心是"持续观察检索表现"，包括：

指标 1：Context Relevance。检索到的 chunk 与 Query 的相关性。监控方法：对生产 Query 抽样 5-10%，用 LLM-as-a-Judge 评估检索结果的平均相关性。目标：>0.85。

指标 2：检索延迟。从 Query 到 Top-K 检索完成的时间。监控方法：直方图监控 P50 / P95 / P99。目标：P95 < 500ms。

指标 3：空召回率。检索结果为空（Top-K=0）或低于阈值（如 Top-1 similarity < 0.5）的比例。目标：<5%。空召回率高说明用户 Query 与文档语义鸿沟大。

指标 4：检索源覆盖率。不同检索源（向量/BM25/Web/API）被命中的比例。监控方法：记录每次检索命中的源。异常的单一源依赖（如 95% 都来自向量库）需要关注。

19.3 生成质量监控

生成质量监控关注 LLM 输出的健康度：

指标 1：Faithfulness（幻觉率）。答案中的事实有多少能从 context 找到。监控方法：LLM-as-a-Judge 抽样评估。目标：>0.90。幻觉率超过 15% 必须告警。

指标 2：Token 消耗。每次查询的 Prompt Token + Completion Token。监控方法：直方图 + 异常告警。Token 消耗突增可能是 Query 变长或检索结果爆炸。

指标 3：LLM 错误率。LLM API 调用失败（timeout / rate limit / content filter）的比例。目标：<1%。错误率突增需要切换备用 LLM。

指标 4：Answer Relevancy。答案与 Query 的语义相关性。监控方法：Embedding 余弦相似度。目标：>0.80。

19.4 端到端质量监控

端到端质量反映"用户实际体验"，是最重要的指标：

指标 1：用户满意度（点赞率）。用户对答案的"点赞 / 点踩"比例。目标：>70%。这是最直接的"用户反馈"，但样本量积累慢。

指标 2：任务完成率。用户基于答案是否解决了原始问题。监控方法：用户后续行为分析（"未追问"、"未人工接管"）。目标：>60%。

指标 3：P95 / P99 延迟。从用户 Query 到答案完整返回的时间。目标：P95 < 3s（实时问答）/ P95 < 30s（深度研究）。

指标 4：业务 KPI。客服场景的"一次解决率"、电商场景的"转化率提升"、教育场景的"学习效果"。这些指标反映 RAG 的实际业务价值。

19.5 漂移检测：从"看起来正常"到"实际已经坏掉"

漂移检测（Drift Detection）是生产级 RAG 系统的关键能力——它能在系统"看起来正常"但"实际已经退化"时及时告警。常见漂移类型：

RAG 系统的四大漂移类型
═══════════════════════════════════════════════════════════════

  ① 数据漂移 (Data Drift)
  ───────────────────────
  表现: 用户 Query 分布变化
  例子: 新业务上线,用户开始问新型问题
  检测: 周期性统计 Query Embedding 分布
  告警: 分布 KL 散度 > 阈值

  ② 概念漂移 (Concept Drift)
  ─────────────────────────
  表现: 同一 Query 的"正确"答案变了
  例子: "苹果"从水果变为公司
  检测: 同一 Query 的检索结果 Embedding 漂移
  告警: 长期 Embedding 中心偏移 > 阈值

  ③ 模型漂移 (Model Drift)
  ─────────────────────────
  表现: LLM 行为变化(API 升级 / 换模型)
  例子: GPT-4 升级到 GPT-4o,生成风格变化
  检测: 评估集持续跑分,监控分数变化
  告警: Faithfulness / Answer Relevancy 持续下降

  ④ 性能漂移 (Performance Drift)
  ──────────────────────────────
  表现: 检索/生成延迟增加
  例子: 向量库数据量翻倍,检索变慢
  检测: P95 / P99 延迟持续监控
  告警: P95 延迟超过 SLA 阈值

19.6 Tracing 系统：从 Query 到答案的完整路径

Tracing 系统是 RAG 可观测性的"基础设施"——它记录每次 Query 的完整执行路径，支持事后分析和故障排查。

RAG Tracing 系统的关键 Span
═══════════════════════════════════════════════════════════════

  Trace: query_abc123 (总耗时 2.3s)
  │
  ├─ Span: query_understanding (50ms)
  │    └─ 解析出 实体: ["X 公司", "2024 年"]
  │
  ├─ Span: retrieval (300ms)
  │    ├─ Span: vector_search (100ms)
  │    │    └─ 检索 100 候选,Top-10
  │    ├─ Span: bm25_search (80ms)
  │    │    └─ 检索 50 候选,Top-10
  │    └─ Span: rrf_fusion (20ms)
  │         └─ RRF 融合 → 15 个最终 chunk
  │
  ├─ Span: rerank (200ms)
  │    └─ BGE-Reranker → 精排 Top-5
  │
  ├─ Span: llm_generation (1500ms)
  │    ├─ Span: prompt_building (10ms)
  │    ├─ Span: llm_api_call (1480ms)
  │    │    ├─ Prompt Tokens: 2500
  │    │    └─ Completion Tokens: 200
  │    └─ Span: post_processing (10ms)
  │
  └─ Span: response (50ms)
       └─ 流式返回 + 引用标注

  关键字段:
  ────────
  · trace_id: 全局唯一 ID
  · parent_id: 父子 Span 关系
  · duration: 耗时
  · tokens: Token 消耗
  · error: 错误信息(如有)
  · metadata: 任意自定义字段

主流的 RAG Tracing 工具：LangSmith（LangChain 官方）、Phoenix（Arize AI 开源）、Helicone（LLM 专用）、Langfuse（开源，自部署友好）。这些工具都支持 OpenTelemetry 标准，能与 Grafana、Datadog 等监控平台集成。

19.7 告警与故障应对

可观测系统的"最后一公里"是告警与故障应对：

RAG 系统告警分级
═══════════════════════════════════════════════════════════════

  P0 严重故障 (立即响应):
  ─────────────────────
  · LLM API 完全不可用
  · 检索系统完全宕机
  · 错误率 > 50%
  应对: 切换备用 LLM / 启用缓存兜底

  P1 性能下降 (30 分钟响应):
  ─────────────────────────
  · P95 延迟 > SLA 阈值 2 倍
  · 错误率 10-50%
  · 幻觉率 > 20%
  应对: 限流 + 排查根因

  P2 质量下滑 (1 天响应):
  ─────────────────────
  · Faithfulness 持续下降
  · 空召回率突增
  · 用户点赞率持续下降
  应对: 数据分析 + 模型重训

  P3 漂移预警 (持续关注):
  ─────────────────────
  · 数据分布漂移
  · 模型分数持续波动
  · 新增未覆盖 Query 类型
  应对: 周期性 review + 知识库扩充

19.8 可观测性建设路径

对企业级 RAG 系统，可观测性建设应当分阶段推进：

阶段 1：基础日志。记录每次 Query 的输入、输出、关键步骤耗时、错误信息。这一阶段的目标是"出问题时能查"。

阶段 2：指标监控。基于日志计算关键指标（Faithfulness、P95 延迟、错误率），接入 Prometheus / Grafana。这一阶段的目标是"出问题前能预警"。

阶段 3：Tracing 体系。引入 OpenTelemetry 标准的 Tracing，记录完整执行路径。这一阶段的目标是"出问题能定位"。

阶段 4：漂移检测。建立数据/概念/模型/性能四类漂移的自动检测机制。这一阶段的目标是"主动发现问题"。

可观测性建设的"Metrics / Logs / Traces"三大支柱是 RAG 系统的"基础设施"。漂移检测是从"被动响应"到"主动预防"的关键能力。

漂移检测让 RAG 系统从"出问题再修"走向"出问题前预警"。

评估体系 2.0 的"多维度 + 细粒度 + 人机融合"原则把 RAG 评估从"指标打分"升级为"质量体系"。这一转变反映了"用业务对齐的指标驱动决策"的方法论升级。

三大评估框架各有定位，架构师应当按"团队背景 + 业务特征"选型。

LLM-as-a-Judge 是评估体系 2.0 的"基础设施"——用 LLM 做大规模自动评估，配合人类精校，把评估从"奢侈品"变成"日用品"。

LLM-as-a-Judge 让"全量评估"成为可能，是 RAG 评估的规模化基础。

二十、架构演进图谱：从传统 RAG 到自适应 RAG

经过 19 章的深度剖析，我们站在 RAG 架构的最前沿回望：从 2020 年的 Naive RAG 到 2026 年的自适应 RAG，五代演进清晰可见。本章作为整篇文章的"终章"，将用架构师视角梳理 RAG 的演进图谱，展望未来 5 年的技术趋势，并给出企业级 RAG 架构选型的决策框架。

20.1 RAG 五代演进全景图

RAG 架构经过 5 年的演化，已经形成清晰的五代演进谱系：

RAG 五代演进全景图
═══════════════════════════════════════════════════════════════

  2020    Naive RAG
  ────    ─────────
          · 一次性 Embedding 检索
          · Top-K 召回 + 一次性生成
          · 问题: 检索偏, 上下文断裂
                 │
                 ▼
  2021-22 Advanced RAG
  ────    ───────────
          · 混合检索(BM25 + 向量)
          · Query 改写 / HyDE
          · Reranker 精排
          · 文档分块优化
          · 问题: 多跳失败, 全局性问题
                 │
                 ▼
  2023    Modular RAG
  ────    ───────────
          · 模块化设计(检索/评估/生成解耦)
          · Self-RAG / CRAG / FLARE
          · 多路召回 + 精排
          · 问题: 评估失真, 不可解释
                 │
                 ▼
  2024    GraphRAG & Multi-Modal RAG
  ────    ─────────────────────────
          · GraphRAG(知识图谱 + 社区检测)
          · ColPali(视觉文档直读)
          · Multi-Modal(文/图/表/视频)
          · Plan-and-Execute
          · 问题: 成本高, 工程复杂
                 │
                 ▼
  2025-26 Agentic RAG
  ────    ───────────
          · Multi-Agent 协作
          · DeepResearch 系统
          · 自适应路由
          · 推理-检索-评估闭环
          · 问题: 复杂度, 可控性
                 │
                 ▼
  未来    Adaptive RAG (2027+)
  ────    ──────────────────
          · 系统自主决定检索策略
          · 自我反思 + 持续学习
          · 多模态原生统一
          · 与 Agent 框架深度融合

20.2 五代 RAG 的能力对比

用六个关键维度对比五代 RAG 的能力：

20.3 自适应 RAG：下一代范式

2027 年及以后，RAG 将演进到"自适应 RAG（Adaptive RAG）"——系统能自主决定"用哪种检索策略"、"调用哪些工具"、"投入多少推理算力"，无需人工预设流程。

自适应 RAG 的核心特征：

特征 1：动态路由。一个 Router Agent 评估 Query 复杂度与类型，自动选择执行路径——简单问题走单跳 RAG，多跳问题走 Plan-and-Execute，全局问题走 GraphRAG，深度研究走 Multi-Agent。

特征 2：自我反思。系统在生成答案前自我评估"信息是否充分"，不足时主动发起额外检索。生成答案后自我检测"是否有幻觉"，有疑问时重新生成。

特征 3：持续学习。系统从用户反馈中学习——点赞的点（哪些信息有用）、点踩的点（哪些信息不可靠）反馈给检索器和生成器，实现"自我进化"。

特征 4：成本自适应。系统根据 Query 价值动态调整算力投入——高价值问题（如"重大决策"）投入更多推理，低价值问题（如"闲聊"）快速响应。

自适应 RAG 架构
═══════════════════════════════════════════════════════════════

              用户 Query
                  │
                  ▼
        ┌──────────────────┐
        │ Router Agent     │  评估 Query 复杂度
        │ (自适应路由)      │  决定执行路径
        └────────┬─────────┘
                 │
   ┌─────────────┼─────────────┬─────────────┐
   ▼             ▼             ▼             ▼
 单跳 RAG    Plan-Execute   GraphRAG     Multi-Agent
 (简单)     (多跳)         (全局)       (深度研究)
   │             │             │             │
   └─────────────┴─────────────┴─────────────┘
                          │
                          ▼
                  ┌──────────────────┐
                  │ Reflector Agent  │  自我反思
                  │ (质量评估)        │  信息是否充分
                  └────────┬─────────┘  答案是否可靠
                          │
                          ▼
                  ┌──────────────────┐
                  │ Final Answer     │
                  │ + Confidence     │
                  │ + References     │
                  └──────────────────┘

20.4 未来 5 年的技术趋势

展望 2026-2031 年，RAG 领域将出现以下关键技术趋势：

趋势 1：长上下文 vs RAG 的边界模糊。随着 Gemini 2M / Claude 1M / GPT-5 等超长上下文模型的成熟，"是否还需要 RAG"的争论会持续。但架构师共识是：长上下文与 RAG 互补——长上下文适合"读完整文档"，RAG 适合"精确定位 + 大规模知识库"。未来 5 年，两者会融合为"长上下文 + 检索增强"的混合范式。

趋势 2：原生多模态统一检索。从"文本+图像"扩展到"文本+图像+视频+音频+3D+传感器"的全模态统一检索。代表方向是 ImageBind / LanguageBind 等全模态 Embedding 模型的成熟。

趋势 3：RAG 与 Agent 框架深度融合。未来 RAG 不再是"独立系统"，而是 Agent 的"工具集"——Agent 根据需要自主调用 RAG 检索，同时 RAG 也可调用 Agent 的其他能力（计算、API、代码执行）。

趋势 4：自建模型与开放模型的分层。企业会形成"小模型做粗筛 + 大模型做综合"的模型分层架构。Embedding 用 BGE-M3（小、快），评估用 BGE-Reranker（小、精），综合用 GPT-4/Claude（大、强）。

趋势 5：RAG 工业化标准成熟。类似 SQL 是数据库的标准接口，RAG 也会形成"事实标准"——MCP（Model Context Protocol）、OpenAI 的 Assistant API 等正在尝试统一 RAG 接口。

趋势 6：评估体系工业化。LLM-as-a-Judge + 持续评估 + A/B Testing + 漂移检测成为 RAG 系统的"标配"，评估成本从"奢侈品"变成"基础设施"。

20.5 企业级 RAG 架构选型决策框架

作为整篇文章的收尾，给架构师一个完整的选型决策框架：

企业级 RAG 架构选型决策框架
═══════════════════════════════════════════════════════════════

  Step 1: 评估业务复杂度
  ──────────────────────
  · Query 类型分布(事实型/多跳/全局/多模态)
  · 文档类型(纯文本/含图表/扫描件/视频)
  · 用户规模与并发量
  · 业务对延迟的容忍度

  Step 2: 评估非功能需求
  ──────────────────────
  · 答案准确性要求
  · 可解释性需求
  · 合规与审计需求
  · 成本预算

  Step 3: 选择基础架构
  ──────────────────────
  · 简单 FAQ: Naive/Advanced RAG
  · 企业知识库: Advanced/Modular RAG
  · 专业领域: Modular + GraphRAG
  · 深度研究: Agentic RAG

  Step 4: 选择增强能力
  ──────────────────────
  · 多跳问题多: Plan-and-Execute
  · 全局问题多: GraphRAG / LightRAG
  · 多模态多: ColPali / 多模态 Embedding
  · 复杂研究: Multi-Agent

  Step 5: 建设可观测性
  ──────────────────────
  · 三大支柱: 检索/生成/端到端
  · Tracing 系统
  · 漂移检测
  · A/B Testing

  Step 6: 持续迭代
  ──────────────────────
  · 数据驱动: 监控指标 → 发现问题 → 优化
  · 用户反馈: 点赞/点踩 → 模型微调
  · 业务对齐: KPI 联动 → 价值验证

20.6 架构师的"五个不要"

在 RAG 架构的演进中，架构师应当坚守"五个不要"原则：

不要 1：不要为了"先进"而先进。Multi-Agent、GraphRAG、DeepResearch 不是"更先进"，而是"更复杂"。复杂匹配业务才是对的，盲目追新是过度工程化。

不要 2：不要忽视可观测性。生产级 RAG 没有可观测性是"黑盒"——出问题只能猜，出问题前无法预警。可观测性是入场券，不是锦上添花。

不要 3：不要脱离业务谈技术。RAG 的最终价值是"解决业务问题"，不是"用上最酷的技术"。技术服务于业务，业务驱动技术选型。

不要 4：不要追求"完美系统"。RAG 系统没有"完美"——总有边界、有限制、失败模式。架构师的工作是"在约束下找到最优"，不是"消除所有限制"。

不要 5：不要把 RAG 当成"银弹"。RAG 不是万能的——有些问题适合 Fine-tuning、有些适合长上下文、有些需要传统数据库查询。RAG 是工具箱里的一个工具，不是唯一工具。

20.7 终章：探索架构之美

回到「探索架构之美」的品牌主题。RAG 架构的前沿演进给我们什么启示？

第一，架构的演进是问题驱动的。Naive RAG 的局限推动了 Advanced RAG，Advanced 的多跳失效推动了 Modular，Modular 的全局性失效推动了 GraphRAG，GraphRAG 的成本问题推动了 LightRAG/HippoRAG，复杂问题推动了 Agentic RAG。每一次跃迁都是"用更好的架构解决更复杂的问题"。

第二，架构的本质是权衡。每一种 RAG 范式都有其优势与代价——ColPali 精度高但存储贵，GraphRAG 全局性好但成本高，Multi-Agent 能力强但复杂度高。没有最好的架构，只有最匹配的架构。

第三，架构是系统思维。RAG 不只是"检索 + 生成"，它是数据工程、机器学习、分布式系统、用户体验、运维监控的综合艺术。架构师的核心能力不是"会用某种技术"，而是"在约束下设计可演进的系统"。

第四，架构服务于人。RAG 系统的最终用户是"用 RAG 解决问题的人"——客服、企业员工、研究员、医生、律师。技术为人服务，不是人为技术服务。架构师应当始终问自己："这个设计让用户生活更好了吗？"

最后，架构之美在于演进。RAG 架构不是"一成不变的金科玉律"，而是"持续演进的活系统"。从 2020 年到 2026 年，RAG 已经走过五代演进；未来 5 年还会有更多变化。架构师的工作是"看清演进方向、把握当下选择、为未来留出空间"。

RAG 五代演进的本质是"问题驱动的范式跃迁"。每代 RAG 都试图突破前代的某个具体边界，架构师选型时应当"匹配业务复杂度与范式能力"。

从 Naive 到 Adaptive，每一步都是"问题驱动 + 架构权衡"的产物。

自适应 RAG 是 RAG 演进的"下一站"——系统自主决定检索策略、调用工具、投入算力。这种"自演进"能力标志着 RAG 从"配置式系统"走向"智能系统"。

自适应 RAG 代表着 RAG 与 Agent 框架深度融合的终极形态。