基于知识图谱对标准 RAG、GraphRAG 与 Agentic 架构的基准测试

向标准的检索增强生成（RAG）系统提出这样一个问题：“在 2018年平昌冬奥会中，有多少项双样滑雪比赛的参赛选手超过了 73 人？”系统通常会给出一个看起来十分自信的答案。然而，这个答案极有可能是错误的。要准确回答该问题，系统必须跨越 8 到 43 份独立文档进行数据检索与聚合统计，而传统的 Top-8 向量相似度搜索根本无法覆盖全部所需的上下文。

为了探究知识图谱在何时提供辅助、Agent 代理在何时发挥关键作用，以及在哪些场景下简单架构即已足够，我们在完全相同的底层模型（Claude 3.5 Sonnet）、相同向量嵌入算法与相同 TigerGraph 数据库实例上，对三种主流检索架构进行了系统的基准测试。

在由 100 道公开测试题组成的评测集上，Agentic GraphRAG 架构取得了 99% 的准确率，而标准 Naive RAG 的准确率仅为 48%。本文将深入解析这项基准测试的技术细节、架构设计、代码实现与工程选型建议。

核心基准测试结果对比

本次测试的数据集包含 2,951篇关于 1987年至 2023年奥运会比赛项目的维基百科英文文章以及部分干扰页面。测试团队通过确定性解析器解析文章的 Infobox 结构构建图谱，避免了 LLM 抽取导致的图谱噪音。

评测过程由独立的大语言模型裁判（LLM Judge）进行自动打分，评分前经过确定性语法预检，且裁判模型的 Token 消耗不计入各 Pipeline 的统计数据中。

经济性与 Token 效率分析

尽管 Agentic GraphRAG 的平均 Token 消耗是 Naive RAG 的 1.24倍，但其准确率提升了 2.06倍。从生产环境中衡量实际成本的关键指标——“单位正确答案所需的 Token 消耗”（Tokens per Correct Answer）来看，Agentic GraphRAG 的实际成本比 Naive RAG 低 40%。

静态 GraphRAG 拥有最低的单次正确答案 Token 成本（5,529），但由于其准确率上限仅为 69%，在对精度要求苛刻的企业级应用中难以单独担当重任。

五大问题类型深度评测

评测集将 100个问题细分为五类经典场景，用以检测不同架构的边界能力：

1. 单点查询 (Lookup, 19 题)：从单份文档中提取单一事实。
2. 聚合统计 (Aggregation, 21 题)：跨运动项目对满足特定阈值的事件进行计数或汇总。
3. 极值查询 (Superlative, 10 题)：寻找全局最大值或最小值（如参赛人数最多的项目）。
4. 时序追踪 (Temporal, 22 题)：跨届次追踪特定实体的历史记录（如前一届冠军）。
5. 多跳推理 (Multi-Hop, 28 题)：结合地点、日期等多重条件进行实体关联查找。

关键现象分析

• 标准 RAG 在聚合统计场景下完全失效：向量 Top-K 检索在聚合统计类问题中的得分仅为 0/21。向量相似度检索侧重语义相近度，无法执行条件计数。单纯拉取 8个文本块根本不足以覆盖几十份文档的数据总量。
• 静态 GraphRAG 在多跳推理中可能劣于标准 RAG：在多跳推理问题中，静态 GraphRAG 的准确率仅为 21%，低于标准 RAG 的 57%。原因在于静态扩展策略强行从初始向量检索到的错误种子节点展开图遍历，导致填充给 LLM 的全部都是高置信度但完全无关的上下文。
• Agentic GraphRAG 完美胜任复杂动态路径：Agent 架构能够自主选择工具。在多跳查询中，Agent 首先检索场馆节点，随后按日期进行过滤，最后精准定位到具体的比赛项目节点。

TigerGraph 图模型与 Schema 设计

本项目的知识图谱将结构化图拓扑与向量索引深度集成于 TigerGraph 数据库中。Schema 包含以下核心节点与边：

• 顶点 (Vertices)：Event（赛事）、Sport（体育项目）、Games（届次）、Venue（场馆）、Athlete（运动员）、Country（国家）、Document（文档）、Chunk（文本块）。
• 边 (Edges)：IN_SPORT、AT_GAMES、HELD_AT、WON、PREV_EDITION、HAS_CHUNK。

每个 Chunk 节点直接存储文本嵌入向量。向量检索直接在图数据库内部原生产生，从而实现了图遍历与向量搜索的单引擎融合。

// 示例 GSQL 聚合查询：统计指定运动项目中参赛人数超过阈值的赛事数量
CREATE QUERY count_events_by_competitors(STRING sport_name, STRING games_name, INT min_competitors) FOR GRAPH OlympicGraph {
  INT event_count = 0;
  
  Events = { Event.* };
  MatchedEvents = SELECT e FROM Events:e - (IN_SPORT) - Sport:s,
                         Events:e - (AT_GAMES) - Games:g
                  WHERE s.name == sport_name AND g.name == games_name AND e.num_competitors > min_competitors;
                  
  PRINT MatchedEvents.size() AS count;
}

三条 Pipeline 架构详解与实现

[用户输入问题]
     │
     ├──> 1. 标准 RAG ───────────> [ 向量 Top-8 Chunk ] ─────────> [ 单次 LLM 调用 ] ──> 输出结果
     │
     ├──> 2. 静态 GraphRAG ──────> [ 向量 Top-6 种子 ] ─────────> [ 固定图扩展遍历 ] ──> [ LLM 调用 ] ──> 输出结果
     │
     └──> 3. Agentic GraphRAG ───> [ ReAct 编排器工具选择 ]
                                         ├── GSQL 结构化聚合
                                         ├── 实体关联与向量检索
                                         └── 证据评估器 (熔断保护)
                                         └── [ 最终验证输出 ]

1. 标准 Naive RAG

执行纯向量检索获取 Top-8 语义匹配文本块（k=8），将其拼接到 Prompt 中进行单次 LLM 调用。 失败模式：在面对复杂聚合场景时，由于无法提供完整上下文，LLM 在 4096 Token 的输出预算内进行了大量无效推理，最终未能给出有效答案。

2. 静态 GraphRAG

首先通过向量检索选取 Top-6 文本块，从中提取最多 3个种子事件节点，沿着 PREV_EDITION、WON 等固定边关系展开单层图图扩展，最后交给 LLM 生成答案。

3. Agentic GraphRAG 架构

Agent 架构基于 LLM 编排器运行 ReAct 循环，配备了完善的工具集：

• entity_linking：将输入字符串映射为图节点 ID。
• gsql_aggregation：执行参数化 GSQL 查询进行精确的数学与关系计算。
• graph_traversal：按需探索相邻节点。
• vector_search：对非结构化文本块进行补充检索。
• evidence_evaluator：输出前的证据评估器。

class AgenticGraphRAG:
    def __init__(self, llm_client, tigergraph_driver):
        self.llm = llm_client
        self.tg = tigergraph_driver
        self.max_steps = 8
        self.error_circuit_breaker = 2

    def run(self, query: str) -> str:
        consecutive_errors = 0
        trace = []
        
        for step in range(self.max_steps):
            action = self.llm.plan_next_step(query, trace)
            
            if action.type == "FINAL_ANSWER":
                # 证据评估器校验
                if self.evaluate_evidence(action.payload, trace):
                    return action.payload
                else:
                    trace.append(\{"system_feedback": "拒绝回答：缺少有效的文档引用或存在未解决的逻辑盲区。