KAG

1. 01_项目总览
2. 02_KAG-Builder知识图谱构建
3. 03_KAG-Solver推理引擎
4. 04_混合检索策略
5. 05_与GraphRAG对比分析

---

01_项目总览

KAG 项目总览

1. 什么是 KAG

KAG（Knowledge Augmented Generation，知识增强生成）是由蚂蚁集团联合浙江大学等机构研发的专业领域知识服务框架，于 2024 年 10 月通过 OpenSPG v0.5 正式开源。

KAG 的核心论文："KAG: Boosting LLMs in Professional Domains via Knowledge Augmented Generation"

开源仓库：github.com/OpenSPG/KAG

---

2. 为什么需要 KAG：RAG 的根本性局限

传统 RAG 与 GraphRAG 在专业领域存在以下系统性缺陷：

缺陷	描述
向量相似 ≠ 逻辑相关	语义近似的文本不代表逻辑上具有推理关联
无法多跳推理	单次检索无法串联跨文档多段证据链
噪声问题严重	GraphRAG 的 OpenIE 引入大量非结构化噪声
不支持数值计算	无法处理时序关系、数值运算、统计比较等
幻觉问题	缺乏结构化知识约束，LLM 容易生成不实内容
Token 成本极高	GraphRAG Global Search 可达 4×10⁴ tokens

专业领域（法律、医疗、政务、金融）对精确性要求极高，上述问题都是不可接受的。KAG 正是专为解决这些问题而设计的。

---

3. 整体架构：三大核心模块

KAG 框架由三个主要模块构成：

原始数据（非结构化文档 + 结构化数据 + 业务规则）
          │
          ▼
┌─────────────────────────────────────────────────────┐
│                    KAG Framework                     │
│                                                      │
│  ┌──────────────────┐     ┌──────────────────────┐  │
│  │   KAG-Builder    │────►│     KAG-Solver        │  │
│  │  (离线知识构建)   │     │   (在线推理求解)      │  │
│  │                  │     │                      │  │
│  │ • 文档解析        │     │ • Planner（规划器）  │  │
│  │ • 实体/关系抽取   │     │ • Reasoner（推理器） │  │
│  │ • 属性归一化      │     │ • Retriever（检索器）│  │
│  │ • 语义对齐        │     │ • Generator（生成器）│  │
│  │ • 互索引构建      │     │                      │  │
│  └──────────────────┘     └──────────────────────┘  │
│            │                         │               │
│            ▼                         │               │
│  ┌──────────────────┐                │               │
│  │  OpenSPG / KG    │◄───────────────┘               │
│  │  (知识图谱存储)   │                                │
│  │  Neo4j / TuGraph │     ┌──────────────────────┐  │
│  └──────────────────┘     │      KAG-Model        │  │
│                           │   (专用模型增强)       │  │
│                           │ • NLU（语言理解）      │  │
│                           │ • NLI（语言推理）      │  │
│                           │ • NLG（语言生成）      │  │
│                           └──────────────────────┘  │
└─────────────────────────────────────────────────────┘

---

4. 五大核心能力

KAG 提出了五项核心技术创新，区别于传统 RAG 和 GraphRAG：

能力 1：面向 LLM 的友好知识表示（LLMFriSPG）

基于 DIKW（Data-Information-Knowledge-Wisdom）层次理论，将知识分层管理：

• 数据层：原始文本 Chunk
• 信息层：OpenIE 抽取的开放三元组（schema-free）
• 知识层：Schema 约束的领域专业知识
• 智慧层：推理规则与业务��辑

同一实体类型可以同时支持两种表示模式并存，使 LLM 既能处理开放文本，又能利用结构化专家知识。

能力 2：知识图谱与原文的互索引机制（Mutual Indexing）

• 将传统词项倒排索引升级为基于图结构的倒排索引
• KG 节点持有指向原文 Chunk 的双向链接
• 检索时可从 KG 节点直接回溯完整原文上下文
• 知识与上下文不再割裂，多跳推理可追溯

能力 3：逻辑形式引导的混合推理（Logical Form Reasoning）

• 将自然语言问题转换为逻辑形式（Logical Form），明确语义类型和关系
• 通过 DAG 结构分解复杂问题为可执行子任务
• 混合使用：LLM 语义推理、KG 符号推理、数值计算

能力 4：基于语义推理的知识对齐（Semantic Alignment）

• 构建**概念图（Concept Graph）**存储同义词、上位词、包含关系
• 离线阶段通过语义推理提升知识规范性和图连通性
• 在线阶段概念图充当用户问题与索引之间的语义桥梁
• 跨文档实体归一和关系统一，显著降低噪声

能力 5：KAG-Model 专用能力增强

通过指令合成训练专用模型，在较小规模模型上实现大模型效果：

能力	应用场景
NLU（自然语言理解）	实体识别、关系理解、问题解析
NLI（自然语言推理）	语义推断、概念对齐、逻辑验证
NLG（自然语言生成）	上下文感知的答案生成与摘要

---

5. 知识表示：LPG + 向量双模态存储

KAG 采用**结构化知识图谱（LPG）+ 稠密向量（Dense Vector）**双模态并行存储：

原始文档
   │
   ├──► LPG（标签属性图）
   │       • SPO 三元组（主-谓-宾）
   │       • 实体类型 + 关系类型 + 属性约束
   │       • Cypher 查询支持精确图遍历
   │       • 符号化逻辑推理基础
   │
   └──► 向量层（Dense Vector）
           • 文本 Chunk 和知识节点的向量化编码
           • ANN 近似最近邻语义搜索
           • 模糊查询和语义召回

两层通过互索引（Mutual Index）双向打通：
KG 节点 ←──── 互索引 ────► 原文 Chunk

---

6. SPG Schema 类型体系

SPG（Semantic-Enhanced Programmable Graph）定义了三类核心知识类型：

类型	说明	示例
EntityType	实体类型	Person、Organization、Disease
ConceptType	概念类型（用于对齐）	疾病分类、法规类目、产品类别
EventType	事件类型	医疗事件、法律案件、金融交易

属性分为两个域：

• 知识域（Knowledge Area）：强 Schema 约束的专家决策知识（静态）
• 信息域（Information Area）：开放信息的文档检索索引（动态）

---

7. 技术栈全景

层次	技术选择
知识图谱引擎	OpenSPG（蚂蚁+OpenKG 联合开发）
图数据库（默认）	Neo4j（Cypher 接口）
图数据库（蚂蚁内部）	TuGraph-DB（蚂蚁自研高性能图存储）
向量存储	向量数据库（ANN 索引）
LLM 接入	OpenAI / Qwen / LLaMA / ChatGLM 等（可配置）
推理规则	KGDSL（知识图谱领域特定语言）
配置管理	Python 配置文件 + YAML
算子框架	KNext（可编程算子框架）

---

8. 与同类方案对比

维度	Naive RAG	GraphRAG（微软）	KAG（蚂蚁）
知识结构	无	社区层级图谱	SPG 语义增强图谱
多跳推理	✗	弱（社区摘要）	✓（逻辑形式 DAG）
数值计算	✗	✗	✓（math_executor）
知识噪声	高	中（OpenIE 噪声）	低（概念图对齐）
专业领域	弱	中	强（Schema 约束）
Token 成本	低	极高	中（轻量模式-89%）
推理可解释性	低	中	高（逻辑形式追溯）

---

9. 基准测试表现

基准数据集	Naive RAG	GraphRAG	KAG	提升
HotpotQA（F1）	基线	+部分提升	最高	+19.6%（相对）
2WikiMultiHopQA（F1）	基线	+部分提升	最高	+33.5%（相对）
政务问答精确率	66%	—	91.6%	+25.6pp
医疗问答准确率	~70%	—	94%+	显著提升

---

10. 主要应用场景

E-Government（政务问答）：

• 11,000 份政府服务文档
• 精确率 91.6%，召回率 71.8%
• 准确解释行政流程、政策法规

E-Health（医疗问答）：

• 超 180 万实体，超 500 万关系
• 热门科普查询准确率 94%+
• 疾病推理、症状-诊断链路、治疗方案

法律领域：

• 法律条款 KG + 判例推理
• 法条检索 + 时效计算 + 赔偿推算

金融领域：

• 监管文件 + 历史数据 + 产品文档统一 KG
• 合规检查、风险评估、量化分析

---

相关文档

• 02_KAG-Builder知识图谱构建.md — 离线知识图谱构建 Pipeline 详解
• 03_KAG-Solver推理引擎.md — 在线逻辑推理求解引擎
• 04_混合检索策略.md — DPR + PPR + RRF 混合检索机制
• 05_与GraphRAG对比分析.md — 架构与性能深度对比

---

02_KAG-Builder知识图谱构建

KAG-Builder：知识图谱构建 Pipeline

1. 概述

KAG-Builder 是 KAG 框架的离线索引构建模块，负责将原始非结构化文档转化为结构化知识图谱。与 GraphRAG 的 OpenIE + 社区摘要方式不同，KAG-Builder 采用双模态抽取 + 语义对齐 + 互索引的精细化构建策略。

构建目标：

原始数据（文档 / 结构化表 / 业务规则）
        │
        ▼
LPG 知识图谱（SPO 三元组 + 属性）
+
向量索引（Dense Vector Embeddings）
+
互索引（KG 节点 ←→ 文本 Chunk 双向映射）

---

2. 完整 Pipeline 步骤

总览流程图

① 文档解析（Layout Analysis）
        │  识别段落/表格/标题，处理 PDF/Word/HTML
        ▼
② 语义分块（Semantic Chunking）
        │  基于语义边界切割，保持上下文连贯性
        ▼
③ 知识抽取（Knowledge Extraction）
        │  双模态：OpenIE（schema-free）
        │         + Schema-constrained（领域约束）
        ▼
④ 属性归一化（Property Normalization）
        │  日期格式、单位、编码标准化
        ▼
⑤ 语义对齐（Semantic Alignment）
        │  实体消歧 + 实体归一 + 概念图对齐
        ▼
⑥ 互索引构建（Mutual Index Construction）
        │  KG 节点 ←→ 文本 Chunk 双向链接
        ▼
⑦ 图存储（Graph Storage）
           写入 Neo4j / TuGraph-DB

---

3. 步骤详解

3.1 文档解析（Layout Analysis）

作用： 识别文档的结构布局，提取内容边界。

PDF / Word / HTML / Markdown
          │
          ▼ Layout Analysis
    ┌─────┴─────┐
    │           │
  结构元素      内容
  • 标题层级    • 正文段落
  • 表格        • 列表
  • 图表标注    • 页眉页脚（过滤）
  • 分页边界

技术难点：

• 扫描件 PDF 需要 OCR 处理
• 跨页表格需要合并重组
• 图表中的数字和标注需要特殊处理

---

3.2 语义分块（Semantic Chunking）

核心问题： 如何切割文本既保证语义完整，又不超过 LLM 的上下文窗口？

KAG 策略：

• 基于语义边界（段落、章节）切割，而非固定字符数
• 保留相邻 Chunk 之间的重叠区域（避免边界处信息丢失）
• 每个 Chunk 携带元信息（所属章节、页码、文档来源）
• Chunk 向量化存储到向量数据库

Chunk 数据结构示意：

{
    "chunk_id": "doc001_chunk_042",
    "content": "《劳动合同法》第三条规定，订立劳动合同，应当遵循...",
    "source_doc": "劳动合同法.pdf",
    "section": "第一章 总则",
    "page": 3,
    "vector": [...],          # 向量化表示
    "entity_refs": ["劳动合同法", "劳动合同"],  # 关联实体（互索引）
}

---

3.3 知识抽取（Knowledge Extraction）

这是 KAG-Builder 最核心的步骤，采用双模态抽取策略：

模式一：Schema-free（开放信息抽取 / OpenIE）

• 不依赖预定义 Schema，对文本进行开放性三元组抽取
• 灵活适应新领域，适合信息层（Information Area）知识
• 抽取结果：(主体实体, 关系谓词, 客体实体/属性值)

输入文本：
"马云是阿里巴巴集团的创始人，该公司成立于1999年。"

OpenIE 抽取结果：
(马云, 是, 阿里巴巴集团的创始人)
(阿里巴巴集团, 成立于, 1999年)
(马云, 创始, 阿里巴巴集团)

模式二：Schema-constrained（Schema 约束抽取）

• 在预定义的领域 Schema 约束下进行精准信息抽取
• 确保知识结构符合领域规范，适合知识域（Knowledge Area）
• 减少噪声，提升知识质量

领域 Schema 示例（医疗领域）：
EntityType: Disease {name, icd_code, category, symptoms, treatments}
EntityType: Drug {name, compound, dosage, contraindications}
RelationType: TREATS {Drug → Disease, evidence_level}
RelationType: CAUSES {Disease → Symptom, frequency}

Schema-constrained 抽取结果：
Disease("高血压", icd_code="I10", category="心血管疾病")
Drug("氨氯地平", compound="氨氯地平苯磺酸盐", dosage="5-10mg/日")
TREATS("氨氯地平" → "高血压", evidence_level="A级证据")

四类子任务

子任务	说明	输出
NER（实体识别）	识别 Person、Org、Location、Disease 等	实体列表 + 类型
RE（关系抽取）	提取实体间语义关系	(S, P, O) 三元组
EE（事件抽取）	识别事件触发词和事件要素角色	事件结构体
属性抽取	提取实体的属性值	键值对

---

3.4 属性归一化（Property Normalization / Postprocessor）

作用： 清洗和标准化从不同文档抽取的属性值。

归一化类型：

# 日期格式归一化
"2024年10月24日" → "2024-10-24"
"24/10/2024"     → "2024-10-24"
"今年10月"        → "2024-10" (结合文档时间戳推断)

# 数值单位归一化
"5千克" → 5000 (grams) 或保留 5 (kg)
"100ml" → 0.1 (liters) 或保留 100 (ml)

# 编码标准化
"高血压" → ICD-10: "I10"
"北京市" → 行政区划代码: "110000"

# 噪声过滤
去除空值属性、置信度低的抽取结果

---

3.5 语义对齐（Semantic Alignment）

语义对齐是 KAG 降噪和提升图质量的关键步骤，分三个层次：

层次一：实体消歧（Entity Disambiguation）

处理同名不同义的实体：

"苹果" → ?
  ├── [水果] 苹果（Fruit）
  └── [公司] 苹果公司（Apple Inc.）

依据上下文语境判断：
"苹果公司发布了新iPhone" → 苹果公司（Apple Inc.）
"苹果富含维生素C"        → 苹果（Fruit）

层次二：实体归一化（Entity Normalization）

合并不同表述的同一实体：

"蚂蚁集团" / "蚂蚁金服" / "Ant Group" / "支付宝母公司"
    → 统一归一到: 蚂蚁集团（entity_id: ant_group_001）

层次三：概念图对齐（Concept Graph Alignment）

利用**概念图（Concept Graph）**进行语义层面的关系对齐：

Concept Graph 中的关系类型：
• 同义词（synonym）：  "高血压" ≡ "血压过高"
• 上位词（hypernym）：  "高血压" is-a "心血管疾病"
• 包含关系（contains）：  "心血管疾病" contains "高血压", "冠心病"
• 相关词（related）：   "高血压" related-to "钠盐摄入"

对齐效果：
查询"血压过高的治疗方案"
→ 概念图展开 → 检索"高血压"相关知识
→ 命中Schema-constrained 的TREATS关系三元组

概念图在两个阶段的作用：

• 离线构建阶段：提升知识规范性，增加图连通性，减少孤立节点
• 在线查询阶段：作为用户问题与索引之间的语义桥梁，扩展检索覆盖

---

3.6 互索引构建（Mutual Indexing）

核心创新： 建立 KG 节点与原始文本 Chunk 之间的双向索引。

传统 RAG 的问题：
  向量检索 → 文本 Chunk → 缺乏结构化知识锚点

GraphRAG 的问题：
  知识图谱节点 与 原文之间关联薄弱

KAG 互索引解决方案：
  KG 节点 ────────────────► 源文本 Chunk（正向链接）
  文本 Chunk ──────────────► 关联实体/关系（反向链接）

互索引的数据结构：

# KG 节点侧：持有 Chunk 引用
{
    "entity_id": "disease_hypertension_001",
    "name": "高血压",
    "type": "Disease",
    "properties": {...},
    "source_chunks": [           # ← 指向原文
        "doc_health_001_chunk_015",
        "doc_health_003_chunk_042"
    ]
}

# Chunk 侧：持有实体/关系引用
{
    "chunk_id": "doc_health_001_chunk_015",
    "content": "高血压是最常见的心血管疾病...",
    "entity_refs": [             # ← 指向 KG 节点
        "disease_hypertension_001",
        "disease_cardiovascular_001"
    ],
    "relation_refs": [
        "rel_hypertension_is_a_cardiovascular_001"
    ]
}

互索引的价值：

1. 推理时命中 KG 节点后可直接回溯原文，获取完整上下文
2. 向量检索命中 Chunk 后可直接定位相关知识节点
3. 多跳推理的每一跳都保持完整的溯源链路（可解释性强）

---

3.7 图存储（Graph Storage）

存储目标：

• 结构化 KG → Neo4j / TuGraph-DB（Cypher 查询）
• 向量化 Chunk → 向量数据库（ANN 检索）
• 互索引映射 → 图数据库中的边关系

断点续建机制：

KAG-Builder 生成 Checkpoint 目录，记录各阶段状态：

checkpoint/
├── reader/      ← 文档解析完成的记录
├── splitter/    ← 分块完成的记录
├── extractor/   ← 知识抽取完成的记录
├── postprocessor/ ← 归一化完成的记录
└── chain/       ← 写图完成的记录

任务中断后可从断点自动恢复，避免重复构建。

---

4. 双模态抽取的质量对比

维度	Schema-free（OpenIE）	Schema-constrained
适用范围	所有文档，无需前期设计	需要提前定义领域 Schema
噪声水平	较高（开放关系复杂）	低（Schema 约束明确）
召回率	高（不遗漏任何关系）	中（仅抽取 Schema 内关系）
知识质量	中	高
推理支持	弱	强（有类型约束的推理）

KAG 的创新： 两种模式应用于同一实体类型，在同一图实例中共存，实现"开放信息 + 专家知识"的统一管理。

---

5. 与 GraphRAG 构建流程对比

GraphRAG 构建：
文档 → OpenIE 抽取 → KG → Leiden 社区检测 → 社区摘要（LLM）
                              └── 丢失大量细节，Token 成本高

KAG 构建：
文档 → Layout 解析 → 语义分块 → 双模态抽取（精准）
     → 属性归一化 → 概念图对齐（降噪）→ 互索引（保留细节）
     → LPG + 向量双存储

关键差异：

• KAG 无社区摘要步骤，通过互索引直接保留原文上下文
• KAG 的概念图对齐大幅降低 OpenIE 噪声
• KAG 的 Schema 约束提供比 GraphRAG 更高质量的领域知识

---

6. 构建成本优化：轻量模式

KAG 提供了轻量构建模式，相比完整 LLM 抽取可降低 89% 的 Token 成本：

构建模式	特点	Token 成本	知识质量
完整模式	全程 LLM 抽取 + 对齐	高	最高
轻量模式	NLP 模型替代部分 LLM 调用	低（-89%）	较高
混合模式	关键实体用 LLM，其余用 NLP	中	高

---

相关文档

• 01_项目总览.md — KAG 整体架构
• 03_KAG-Solver推理引擎.md — 在线推理求解引擎详解
• 04_混合检索策略.md — DPR + PPR + RRF 混合检索机制

---

03_KAG-Solver推理引擎

KAG-Solver：逻辑推理求解引擎

1. 概述

KAG-Solver 是 KAG 框架的在线推理核心，负责将用户的自然语言问题转化为结构化的推理过程，最终生成精确可追溯的答案。

设计哲学： 不是简单地"检索 → LLM 生成"，而是"逻辑分解 → 混合执行 → 验证迭代"。

核心组件：

用户问题
   │
   ▼
┌─────────────────────────────────────────────────────────┐
│                      KAG-Solver                          │
│                                                          │
│   ┌────────────────┐                                     │
│   │    Planner     │  ← 问题理解 + 逻辑形式分解          │
│   │  （规划器）     │    生成 DAG 子问题图                │
│   └───────┬────────┘                                     │
│           │ 子问题序列                                    │
│           ▼                                              │
│   ┌────────────────┐                                     │
│   │    Executor    │  ← 混合推理执行                     │
│   │  （执行引擎）   │    四类算子调度                      │
│   └───────┬────────┘                                     │
│           │ 子答案                                       │
│           ▼                                              │
│   ┌────────────────┐                                     │
│   │   Generator    │  ← 答案综合 + 验证                  │
│   │  （生成器）     │    不满足则触发重规划                │
│   └────────────────┘                                     │
└─────────────────────────────────────────────────────────┘
   │
   ▼
最终答案（带溯源链路）

---

2. Planner：规划器

2.1 逻辑形式（Logical Form）

KAG-Solver 的第一步是将自然语言问题转化为逻辑形式（Logical Form）。

逻辑形式的作用：

• 明确问题的语义类型（实体查询 / 关系推理 / 数值计算）
• 将复杂问题分解为具有依赖关系的子问题
• 为后续的执行算子选择提供依据
• 提升推理严谨性和可解释性

示例：

用户问题：
"2023年，蚂蚁集团收购的最大一家公司的CEO是谁？"

逻辑形式分解：
SubQ1: FIND companies WHERE acquired_by="蚂蚁集团" AND year=2023
SubQ2: MAX SubQ1 BY acquisition_amount
SubQ3: FIND person WHERE role="CEO" AND organization=SubQ2

依赖关系 DAG：
SubQ1 ──► SubQ2 ──► SubQ3 → 最终答案

2.2 DAG 子问题图

规划器将问题分解为有向无环图（DAG），节点是子问题，边是数据依赖关系：

复杂问题：
"根据最新指南，高血压合并糖尿病的患者，
 哪种降压药物的推荐级别最高，该药的常见副作用是什么？"

DAG 分解：
  ┌──────────────────────────────────┐
  │ SubQ1: 高血压合并糖尿病的降压指南  │
  └───────────────┬──────────────────┘
                  │
  ┌───────────────▼──────────────────┐
  │ SubQ2: 各药物的推荐级别对比       │
  │       （数值比较 + 排序）          │
  └───────────────┬──────────────────┘
                  │  最高推荐级别的药物名
  ┌───────────────▼──────────────────┐
  │ SubQ3: 该药物的常见副作用         │
  └───────────────┬──────────────────┘
                  │
              最终答案综合

2.3 两种规划模式

静态规划模式（Static Planner）

• 对问题一次性生成完整的 DAG 求解路径
• 明确所有子问题及其依赖关系
• 适合问题结构相对清晰的场景
• 执行效率高（无需中间迭代）

问题输入 → LLM 一次规划 → 完整 DAG → 顺序执行所有子问题 → 答案

迭代规划模式（Iterative Planner）

• 逐步推进，每步根据已知结果决定下一步
• 支持多轮推理迭代，直至满足终止条件
• 适合开放性、复杂度高、答案路径不确定的推理场景

问题输入 → LLM 规划当前步 → 执行 → 观察结果
                │                        │
                └────── 未完成 ────────────┘
                                 │ 完成
                              最终答案

---

3. Executor：执行引擎

执行引擎是 KAG-Solver 的推理核心，根据子问题的语义类型调度不同算子。

3.1 四类推理算子

算子类型	实现方式	适用场景	典型问题
精确图查询	Cypher → Neo4j/TuGraph	实体属性、关系查找	"蚂蚁集团的创始人是谁？"
语义文本检索	DPR + PPR + RRF	模糊语义、上下文推断	"有哪些治疗高血压的方法？"
数值计算	math_executor	统计、时序、数学推算	"计算5年来的复利收益"
语义推理	LLM + 概念图	因果推断、分类判断	"这个症状可能是什么疾病？"

3.2 算子一：精确图查询（cypher_executor）

原理： 将子问题转换为 Cypher 查询语句，在 KG 中执行精确检索。

# 子问题：蚂蚁集团的总部在哪里？
cypher = """
MATCH (org:Organization {name: '蚂蚁集团'})
RETURN org.headquarters
"""

# 子问题：哪些药物可以治疗高血压？
cypher = """
MATCH (drug:Drug)-[:TREATS]->(disease:Disease {name: '高血压'})
RETURN drug.name, drug.evidence_level
ORDER BY drug.evidence_level DESC
LIMIT 10
"""

优势：

• 精确、确定性强，无随机性
• 不依赖 LLM，速度快
• 结果可完整溯源到 KG 节点

3.3 算子二：语义文本检索（kag_hybrid_exec）

原理： 三阶段混合检索（详见 04_混合检索策略.md）：

子问题文本
    │
    ├── DPR（稠密向量检索）→ top-k 语义相近 Chunk
    │
    └── PPR（个性化 PageRank）→ 图传播相关 Chunk
            │
            ▼
        RRF（互惠排名融合）→ 重排序
            │
            ▼
        最相关的 Chunk 列表

3.4 算子三：数值计算（math_executor）

原理： 专门处理需要数值运算的子问题。

# 子问题示例：计算用药安全剂量
"""
患者体重: 70kg
推荐剂量: 5mg/kg/天
用药天数: 7天

计算：总剂量 = 5 × 70 × 7 = 2450mg
"""

# 子问题示例：时序推断
"""
合同签订日期: 2022-03-15
诉讼时效: 3年

诉讼截止日期: 2025-03-15
当前日期: 2024-11-01
剩余时效: 134天

支持的计算类型：

• 算术运算（加减乘除、百分比）
• 日期时序推算（到期日、时效计算）
• 统计计算（平均值、最大最小值、排序）
• 单位换算

3.5 算子四：语义推理（LLM + 概念图）

原理： 利用 LLM 的语言推理能力，结合概念图进行语义层面的推断。

子问题：
"患者出现持续性头痛、视物模糊、恶心，最可能的诊断是什么？"

推理过程：
1. 概念图展开：
   头痛 → 可能原因 → [高血压危象、偏头痛、颅内压增高]
   视物模糊 → 可能原因 → [高血压视网膜病变、青光眼]
   恶心 → 可能原因 → [颅内压增高、消化道问题]

2. 症状交集推断：
   三个症状共同指向 → 高血压危象（高可信度）
                    → 颅内压增高（中可信度）

3. LLM 综合生成：
   "根据症状组合，最可能的诊断是高血压危象，
    建议立即测量血压并进行眼底检查。"

---

4. Generator：答案生成器

4.1 答案综合

Generator 将各子问题的执行结果综合为最终答案：

def generate_final_answer(
    original_question: str,
    sub_answers: list[SubAnswer],    # 各子问题结果
    source_chunks: list[Chunk],      # 支撑文本来源
    kg_triples: list[Triple],        # 支撑的 KG 三元组
) -> Answer:
    """
    1. 按 DAG 依赖顺序组织子答案
    2. LLM 综合生成流畅自然语言回答
    3. 附加溯源信息（哪些文档、哪些 KG 节点支撑了答案）
    """

4.2 答案验证与迭代

生成答案后，KAG-Solver 会进行自我验证：

答案质量评估维度：
• 完整性：是否回答了所有子问题？
• 一致性：各子答案之间是否矛盾？
• 可信度：是否有足够的证据支撑？
• 准确性：数值计算结果是否正确？

评估结果：
  ✓ 满足 → 输出最终答案
  ✗ 不满足 → 触发重规划（Iterative Mode）
              或降级到更保守的回答策略

---

5. FunctionCall 机制

KAG-Solver 利用 LLM 的 Function Call / Tool Use 能力实现算子的智能调度：

# 定义可用的算子工具
tools = [
    {
        "name": "cypher_executor",
        "description": "在知识图谱中执行精确查询，适合实体属性和关系查找",
        "parameters": {"cypher_query": "str"}
    },
    {
        "name": "semantic_retrieval",
        "description": "向量检索 + 图传播，适合模糊语义查询",
        "parameters": {"query": "str", "top_k": "int"}
    },
    {
        "name": "math_executor",
        "description": "数值计算，适合时序、统计、单位换算",
        "parameters": {"expression": "str", "variables": "dict"}
    },
    {
        "name": "semantic_reasoning",
        "description": "语义推理，适合因果推断和分类判断",
        "parameters": {"premise": "str", "question": "str"}
    }
]

# LLM 根据子问题语义自动选择最合适的算子
response = llm.chat(
    messages=[{"role": "user", "content": sub_question}],
    tools=tools,
    tool_choice="auto"
)

---

6. 推理过程完整示例

问题： "我国最新劳动法规定，连续工作满1年的员工，年假天数是多少？如果员工已累计工龄10年，年假又是多少天？"

[Planner - 静态规划]
SubQ1: 最新劳动法关于年假的规定
SubQ2: 连续工作满1年的年假天数（基础查询）
SubQ3: 累计工龄10年的年假天数（数值+条件查询）

DAG: SubQ1 → SubQ2 → SubQ3 → 综合答案

[Executor - SubQ1]
算子选择: kag_hybrid_exec（语义检索）
查询: "年假 劳动法 最新规定"
结果: 命中《职工带薪年休假条例》相关条款（互索引→原文Chunk）

[Executor - SubQ2]
算子选择: cypher_executor（精确图查询）
Cypher:
  MATCH (law:Law {name: '职工带薪年休假条例'})
  -[:STIPULATES]->(rule:Rule {condition: '连续工作满1年'})
  RETURN rule.annual_leave_days

结果: 5天

[Executor - SubQ3]
算子选择: cypher_executor + math_executor
Cypher: 查询工龄10-19年的年假规定 → 10天

[Generator]
综合以上子答案，LLM 生成：
"根据《职工带薪年休假条例》（2008年施行，现行有效）：
 - 连续工作满1年不满10年的员工：年假5天
 - 连续工作满10年不满20年的员工：年假10天

 因此，累计工龄10年的员工享有10天带薪年假。

 来源：《职工带薪年休假条例》第三条"

---

7. 设计亮点与局限

亮点

特性	说明
逻辑严谨性	逻辑形式强制分解，避免"一步到位"的模糊推理
多算子混合	精确查询 + 语义检索 + 数值计算，覆盖多类型问题
完整溯源	每个子答案都有对应的 KG 节点和原文 Chunk
迭代纠错	验证不通过可重规划，降低幻觉风险
FunctionCall	利用 LLM 能力自动调度算子，灵活扩展

局限

局限	描述
推理延迟	多步逻辑推理比单次向量检索慢
规划依赖 LLM	Planner 本身依赖 LLM 能力，复杂问题可能规划错误
Schema 覆盖	Schema 未覆盖的领域只能依赖 OpenIE + 语义检索
多语言	主要优化中文，多语言支持有限

---

相关文档

• 02_KAG-Builder知识图谱构建.md — 离线知识图谱构建
• 04_混合检索策略.md — DPR + PPR + RRF 详细机制
• 05_与GraphRAG对比分析.md — 与 GraphRAG 的深度对比

---

04_混合检索策略

KAG 混合检索策略：DPR + PPR + RRF

1. 概述

KAG 的混合检索是其在检索精度上超越传统 RAG 的核心机制。它不依赖单一的向量相似度，而是将稠密向量检索（DPR）、**图结构传播（PPR）和排名融合（RRF）**三种机制有机结合，实现语义理解与图结构知识的双重覆盖。

传统 RAG 检索的问题：

查询 → 向量相似度 → top-k 文本块
                  ↑
          仅捕获语义近似，
          无法发现图结构上相关但语义距离较远的知识

KAG 混合检索的改进：

查询 ─┬─► DPR 向量检索 ─────────────────┐
      │                                  ├─► RRF 融合排序 → 最终结果
      └─► PPR 图传播检索 ───────────────┘

---

2. 第一层：DPR（Dense Passage Retrieval，稠密向量检索）

2.1 工作原理

DPR 是传统 RAG 的核心检索机制，在 KAG 中作为第一层召回：

用户查询（或子问题文本）
        │
        ▼ Embedding 模型
    查询向量 q_vec
        │
        ▼ ANN（近似最近邻）检索
    向量数据库（所有 Chunk 的向量）
        │
        ▼ 余弦相似度 / 内积排序
    top-k 最相似的文本 Chunk

数学表达：

相似度(q, chunk) = cos(q_vec, chunk_vec)
                 = (q_vec · chunk_vec) / (|q_vec| × |chunk_vec|)

DPR 结果: {chunk_i: score_i} for top-k

2.2 DPR 的局限

DPR 只能捕获语义表层相似性，对以下情况无能为力：

查询: "谁是蚂蚁集团的实际控制人？"

DPR 可能召回:
  ✓ "马云是阿里巴巴集团创始人..."（语义近似）
  ✓ "支付宝母公司的CEO..."（语义近似）

DPR 可能遗漏:
  ✗ "杰克·马（Jack Ma）..."（实体不同表述）
  ✗ 通过"阿里巴巴 → 控股关系 → 蚂蚁集团"图路径能找到的内容

---

3. 第二层：PPR（Personalized PageRank，个性化 PageRank 图传播）

3.1 PageRank 原理回顾

PageRank 的核心思想：一个节点的重要性由指向它的节点的重要性决定，模拟随机游走过程：

每次随机游走：
  以概率 (1-d)：传送到种子节点（teleport）
  以概率 d：从当前节点随机跳转到相邻节点

d = damping factor（阻尼系数，通常为 0.85）

Personalized PageRank（PPR） 是 PageRank 的个性化变体：将随机游走的"传送目标"限定为一组种子节点（Seed Nodes），使排名反映与种子节点的关联程度。

3.2 KAG 中的 PPR 实现

种子节点来源：

KAG 的 PPR 种子节点 = DPR 召回的 top-k 文本 Chunk
                    + 查询中直接识别的实体
                    + 子问题分解出的候选知识单元

PPR 传播过程：

种子节点集合 S = {chunk_i, entity_j, ...}

在知识图谱上执行个性化 PageRank：

图结构（边类型）：
  • Chunk → Entity（文本包含实体）
  • Entity → Entity（实体关系）
  • Entity → Chunk（实体出现在文本中，即互索引）
  • Concept → Entity（概念包含关系）

PPR 分数计算（迭代直至收敛）：
  PR(v) = (1-d) × IsInS(v)/|S|   # 传送到种子节点的概率
         + d × Σ_{u→v} PR(u)/out_degree(u)  # 邻居传播

收敛后，每个节点得到一个 PPR 分数，
分数越高表示与种子节点的图结构关联越强

3.3 PPR 能捕获什么？

PPR 通过图结构传播，能发现 DPR 语义检索遗漏的相关内容：

示例：多跳图路径

查询: "高血压患者能使用布洛芬吗？"

DPR 直接召回：
  → 高血压相关文本
  → 布洛芬相关文本（可能较少）

PPR 通过图传播发现：
  种子：高血压实体
  └──► 高血压 -[CONTRAINDICATED_WITH]→ NSAIDs（非甾体抗炎药）
       └──► NSAIDs -[IS_A_CLASS]→ 布洛芬所属类别
            └──► 布洛芬相关使用��忌文本

最终 PPR 高分节点：
  • 高血压禁忌用药指南 Chunk ← 通过两跳图路径发现
  • NSAIDs 与血压关系研究 Chunk

PPR 的价值：

能力	描述
多跳推理	通过图边传播，发现 N 跳之外的相关知识
关系感知	利用实体关系（TREATS、CAUSES、CONTRAINDICATED 等）传播
互索引利用	通过 KG 节点←→Chunk 双向链接扩展检索覆盖
概念扩展	通过概念图上位词关系扩展查询范围

---

4. 第三层：RRF（Reciprocal Rank Fusion，互惠排名融合）

4.1 问题背景

DPR 和 PPR 分别返回排好序的候选 Chunk 列表，但：

• 两者的分数量纲不同（余弦相似度 vs. PPR 概率值）
• 无法直接比较，需要融合重排

4.2 RRF 算法

RRF 是一种简单而有效的排名融合算法，不依赖分数绝对值，只利用排名位置：

RRF_score(doc d) = Σ_{i ∈ retrievers} 1 / (k + rank_i(d))

其中：
  k = 平滑常数（通常为 60，防止排名第1的过度优势）
  rank_i(d) = 文档 d 在第 i 个检索器中的排名（从1开始）
  如果文档 d 未出现在某检索器的结果中，该检索器不贡献分数

示例计算：

两个检索器结果：
DPR 排名: [A, B, C, D, E]
PPR 排名: [C, A, F, B, G]

RRF 计算（k=60）：
  Doc A: 1/(60+1) + 1/(60+2) = 0.01639 + 0.01613 = 0.03252
  Doc B: 1/(60+2) + 1/(60+4) = 0.01613 + 0.01563 = 0.03176
  Doc C: 1/(60+3) + 1/(60+1) = 0.01587 + 0.01639 = 0.03226
  Doc D: 1/(60+4) + 0         = 0.01563
  Doc E: 1/(60+5) + 0         = 0.01538
  Doc F: 0         + 1/(60+3) = 0.01587
  Doc G: 0         + 1/(60+5) = 0.01538

RRF 最终排名: A > C > B > F > D > E > G

4.3 RRF 的优势

特性	描述
分数无关	只用排名位置，无需两个系统分数量纲一致
鲁棒性强	对任一检索器的偶发失误不敏感
参数简单	只有一个超参数 k（通常 60 即可）
无需训练	无需额外的重排模型，计算成本极低
互补性	两个检索器都召回的文档会获得双重加分

---

5. 完整混合检索流程

用户问题 / 子问题
        │
        ▼ 问题解析
  提取关键实体 + 语义核心
        │
        ├─────────────────────────────────┐
        │                                 │
        ▼                                 ▼
  DPR 向量检索                    PPR 图传播检索
  1. 问题向量化                   1. 识别种子节点
  2. ANN 检索向量数据库                (DPR top-k + 查询实体)
  3. 返回 top-k Chunk 及排名     2. 在 KG 上运行 PPR
                                  3. 按 PPR 分数排序
                                  4. 返回 top-k Chunk 及排名
        │                                 │
        └──────────────┬──────────────────┘
                       │
                       ▼
              RRF 互惠排名融合
              计算每个 Chunk 的 RRF 分数
              最终排序 → top-m Chunk
                       │
                       ▼
         相关 KG 三元组（来自互索引）
                       │
                       ▼
              送入 Generator 生成答案

---

6. 与传统检索方案对比

6.1 覆盖率对比

                  DPR 覆盖    PPR 扩展的额外覆盖
                  ─────────   ──────────────────
直接语义相关          ✓              ✓（强化）
多跳图路径关联        ✗              ✓
同义词/上位词扩展      弱             ✓（概念图）
实体关系链接          ✗              ✓

6.2 各检索方案对比总结

检索方案	多跳推理	图结构利用	实现复杂度	典型应用
Naive RAG	✗	✗	低	通用问答
GraphRAG Local	弱（1-hop）	弱	中	实体查询
GraphRAG Global	✗（社区摘要）	中	高	全局总结
KAG DPR 单独	✗	✗	低	—
KAG DPR+PPR+RRF	✓（多跳）	✓（PPR 传播）	中高	专业推理

---

7. 超参数配置

hybrid_retrieval:
  # DPR 配置
  dpr:
    model: "bge-m3"         # 向量化模型
    top_k: 10               # 初始召回数量
    similarity: "cosine"    # 相似度度量

  # PPR 配置
  ppr:
    damping_factor: 0.85    # 随机游走阻尼系数
    max_iterations: 100     # 最大迭代次数
    convergence_threshold: 1e-6  # 收敛阈值
    top_k: 10               # PPR 返回的 Chunk 数量
    seed_from_dpr: true     # 使用 DPR top-k 作为种子节点

  # RRF 配置
  rrf:
    k: 60                   # 平滑常数
    final_top_m: 5          # 最终送入 Generator 的 Chunk 数

---

8. 实际效果数据

在 HotpotQA 多跳问答基准上，不同检索策略的性能（F1 分数）：

检索策略	F1 分数	相对提升
纯向量检索（DPR only）	基线	—
图检索（PPR only）	基线 +5%	+5%
DPR + PPR（无 RRF）	基线 +12%	+12%
DPR + PPR + RRF（KAG）	基线 +19.6%	+19.6%

RRF 的额外贡献（相比简单合并）约提升 7-8%，说明排名融合本身带来了显著的质量提升。

---

相关文档

• 03_KAG-Solver推理引擎.md — 混合检索在推理引擎中的调用方式
• 02_KAG-Builder知识图谱构建.md — 互索引如何支撑 PPR 图传播
• 05_与GraphRAG对比分析.md — 与 GraphRAG 检索机制的对比

---

05_与GraphRAG对比分析

KAG vs. GraphRAG 深度对比分析

1. 背景

GraphRAG（微软研究院，2024年4月）和 KAG（蚂蚁集团，2024年10月）都是基于知识图谱增强 RAG 的代表性框架，但两者的设计目标、技术路线和适用场景存在显著差异。

	GraphRAG	KAG
发布方	微软研究院	蚂蚁集团 + 浙江大学
发布时间	2024年4月	2024年10月
论文	"From Local to Global: A Graph RAG Approach to Query-Focused Summarization"	"KAG: Boosting LLMs in Professional Domains via Knowledge Augmented Generation"
核心定位	大规模语料全局理解与摘要	专业领域精准推理与问答

---

2. 设计理念对比

2.1 GraphRAG 的核心思想

GraphRAG 聚焦于解决"查询聚焦摘要"问题：如何从大量文档中回答需要全局理解的宏观问题？

GraphRAG 的核心路径：
文档 → OpenIE 抽取 → KG → 社区检测（Leiden 算法）
     → 社区层级摘要（LLM）
          │
          ├── Global Search: 汇总所有社区摘要（Map-Reduce）
          └── Local Search: 从实体出发遍历 1-hop 邻居

适合的问题类型：

• "这批文档的主要主题是什么？"
• "哪些组织在这个领域最具影响力？"
• "整体趋势如何？"（全局综合性问题）

2.2 KAG 的核心思想

KAG 聚焦于解决"专业领域精准推理"问题：如何在要求事实精确、逻辑严谨的专业场景下提供可靠答案？

KAG 的核心路径：
文档 → 双模态抽取（OpenIE + Schema约束）→ 概念图对齐
     → 互索引（KG节点 ←→ Chunk）
          │
          └── KAG-Solver:
              逻辑形式分解（DAG）→ 混合推理（DPR+PPR+RRF）
              → 四类算子执行（图查询/语义检索/数值计算/推理）

适合的问题类型：

• "高血压患者能否同时使用布洛芬？"（多知识结合推理）
• "连续工作满1年的员工，年假天数是多少？"（精确法规查询）
• "2023年蚂蚁集团收购的公司中，收购金额最大的是哪家？"（多跳+数值）

---

3. 知识图谱构建对比

3.1 构建流程对比

GraphRAG 构建：

文档
 ↓ 文本分块
 ↓ 实体/关系抽取（OpenIE - LLM）
 ↓ 知识图谱（无 Schema 约束）
 ↓ Leiden 社区检测（图算法）
 ↓ 社区报告生成（LLM）← Token 成本极高
输出：
  • entities.parquet
  • relationships.parquet
  • communities.parquet
  • community_reports.parquet（核心检索对象）

KAG 构建：

文档
 ↓ Layout 解析 + 语义分块
 ↓ 双模态知识抽取
   ├── Schema-free OpenIE（信息层）
   └── Schema-constrained 精准抽取（知识层）
 ↓ 属性归一化
 ↓ 概念图语义对齐（降噪）
 ↓ 互索引构建（KG ←→ Chunk 双向映射）
 ↓ LPG + 向量双模态存储
输出：
  • 知识图谱（Neo4j / TuGraph）
  • 向量数据库（Chunk Embeddings）
  • 互索引（双向映射表）

3.2 知识图谱质量对比

维度	GraphRAG	KAG
Schema 约束	无（完全开放 OpenIE）	双模态（开放 + 约束）
噪声水平	高（OpenIE 抽取自由度大）	低（概念图对齐降噪）
知识精确性	中	高（领域 Schema 保证）
知识与文本关联	弱（KG 节点与原文割裂）	强（互索引双向绑定）
图连通性	依赖 OpenIE 质量	高（概念图增强连通）
社区摘要	有（Leiden + LLM 摘要）	无

---

4. 检索与推理机制对比

4.1 GraphRAG 的两种查询模式

Local Search（局部精确查询）：
  Query → 向量检索 → 相关实体
       → 图遍历（1-hop 邻居）
       → [实体信息 + 关系 + 社区报告片段 + 文本块]
       → LLM 生成答案

  优点：速度快，适合实体相关问题
  缺点：仅 1-hop，无法多跳推理

Global Search（全局综合查询）：
  Query → 所有社区报告 → 并发 Map（每个社区一次 LLM 调用）
       → Reduce（LLM 汇总所有局部答案）

  优点：全局视角，综合性强
  缺点：Token 成本极高（4×10⁴ tokens），无法精确推理

4.2 KAG 的混合推理

KAG-Solver（统一推理引擎）：
  Query
   → 逻辑形式分解（DAG 子问题图）
   → 对每个子问题：
       ├── cypher_executor：精确图查询
       ├── kag_hybrid_exec：DPR + PPR + RRF 混合检索
       ├── math_executor：数值计算
       └── semantic_reasoning：LLM + 概念图推理
   → 子答案综合 → 验证 → 最终答案

  优点：支持多跳推理、数值计算、精确匹配、语义推理全覆盖
  缺点：推理延迟较高

4.3 推理能力对比

推理类型	GraphRAG	KAG
单跳实体查询	✓（Local）	✓
全局总结	✓（Global）	弱（无社区摘要机制）
多跳图推理	✗	✓（DAG + PPR）
数值计算	✗	✓（math_executor）
时序推理	✗	✓（math + Cypher）
概念扩展	✗	✓（概念图）
逻辑推断	✗	✓（逻辑形式）
探索式研究	✓（DRIFT Search）	弱

---

5. Token 成本对比

5.1 构建阶段

阶段	GraphRAG	KAG（完整模式）	KAG（轻量模式）
实体/关系抽取	LLM（高）	LLM（高）	NLP 模型（极低）
摘要/报告生成	LLM（极高）	无	无
对齐归一化	无	LLM（中）	NLP 模型（低）
总计	极高	高	低（-89%）

GraphRAG 社区摘要生成是 Token 消耗的主要来源——每个社区都需要一次 LLM 调用生成摘要，大规模语料（如 10 万文档）可能需要数万次 LLM 调用。

5.2 查询阶段

GraphRAG Global Search Token 消耗（单次查询）：
  - 所有社区报告（level=1）平均：2000 tokens × 100 社区 = 200,000 tokens（Map 阶段）
  - Reduce 阶段：~5,000 tokens
  - 总计：~200,000 tokens（约 4×10⁴ tokens 是保守估计）

KAG 查询 Token 消耗（单次查询）：
  - 规划器：~1,000 tokens
  - 每个子问题的上下文：~2,000 tokens × N 个子问题
  - 最终生成：~1,000 tokens
  - 总计：通常 5,000~15,000 tokens（取决于问题复杂度）

成本比较：GraphRAG Global Search 约为 KAG 的 10-40 倍

---

6. 知识与文本的关联机制

这是 KAG 与 GraphRAG 最根本的架构差异之一：

GraphRAG 的关联方式（弱关联）

原始文本 ──► 实体/关系节点（KG）
              │
              └── 指向社区摘要（LLM 生成的摘要文本）
                        │
                        └── 社区摘要与原始文本之间的联系已弱化

问题：

• 社区摘要是 LLM 生成的二次文本，可能丢失原文细节
• 推理结果的溯源链路断裂（答案来自摘要，而非原文）

KAG 的互索引（强关联）

原始文本 Chunk ◄──── 互索引 ────► KG 节点（实体/关系）
     │                                    │
     │ 携带实体引用                        │ 携带 Chunk 引用
     ▼                                    ▼
可直接定位相关实体                   可直接回溯原文上下文

优势：

• 每个推理步骤都可追溯到具体原文段落
• 不丢失细节，知识与上下文完整保留
• 推理结果可引用具体文档位置（高可解释性）

---

7. 性能基准对比

7.1 多跳推理基准

HotpotQA（需要跨两篇文章推理）：

方案	F1 分数
Naive RAG	~45%
GraphRAG	~52%
KAG	~64%
提升（vs GraphRAG）	+12pp

2WikiMultiHopQA（需要跨多文档多跳推理）：

方案	F1 分数
Naive RAG	~38%
GraphRAG	~42%
KAG	~56%
提升（vs GraphRAG）	+14pp

7.2 专业领域基准

政务问答（E-Government QA）：

方案	精确率	召回率
Naive RAG	66%	—
GraphRAG	71%	—
KAG	91.6%	71.8%

医疗热门科普（E-Health Popular QA）：

方案	准确率
Naive RAG	~70%
KAG	94%+

---

8. 适用场景决策指南

需要全局理解和宏观总结？
  └── 是 → GraphRAG（Global Search）
          └── "这批文档涉及哪些主要议题？"

问题涉及具体实体，需要局部精确答案？
  └── 是 → GraphRAG（Local Search）或 KAG 均可
          └── "Tesla 的主要业务是什么？"

问题需要多跳推理（跨多个知识节点）？
  └── 是 → KAG（逻辑形式 + DAG）
          └── "蚂蚁集团的母公司阿里巴巴的创始人在哪里读大学？"

问题涉及数值计算或时序推断？
  └── 是 → KAG（math_executor）
          └── "这份合同还有多少天到期？"

专业领域（法律/医疗/金融/政务）问答？
  └── 是 → KAG（Schema 约束 + 精确推理）

探索性研究，不知从何入手？
  └── 是 → GraphRAG（DRIFT Search）

大规模通用语料，快速构建，成本敏感？
  └── 是 → GraphRAG（fast 模式）或 Naive RAG

---

9. 两者的互补性

KAG 和 GraphRAG 并非互斥关系，各有所长：

优势场景	推荐方案
通用问答、宏观摘要	GraphRAG
探索式开放研究	GraphRAG DRIFT
专业领域精准推理	KAG
多跳逻辑推理	KAG
数值时序计算	KAG
成本极度敏感	Naive RAG / GraphRAG fast
超大规模语料全局理解	GraphRAG

---

10. 总结

维度              GraphRAG              KAG
─────────────────────────────────────────────
设计目标          大规模全局理解         专业领域精准推理
KG 构建质量       中（OpenIE噪声）       高（Schema+对齐）
知识-文本关联     弱（社区摘要）         强（互索引）
多跳推理          ✗                     ✓
数值计算          ✗                     ✓
全局总结          ✓（Global Search）    ✗
Token 成本        高（Global 极高）      中（轻量-89%）
可解释性          中                    高（逻辑溯源）
专业领域          中                    强
多跳基准提升      基线                  +19.6%~33.5%

KAG 在专业领域精准推理上的优势来自于：

1. Schema 约束的高质量知识图谱
2. 逻辑形式引导的结构化推理
3. 互索引保证的完整上下文溯源
4. 四类算子覆盖的全面推理能力

GraphRAG 的优势则在于大规模语料的全局理解和探索性研究场景。

---

相关文档

• 01_项目总览.md — KAG 整体介绍
• 02_KAG-Builder知识图谱构建.md — KAG 知识构建详解
• 03_KAG-Solver推理引擎.md — KAG 推理引擎详解
• 04_混合检索策略.md — DPR + PPR + RRF 详解