现在人人都在构建智能体。但比“智能体能做这件事吗？”更好的问题是：“智能体什么时候真的胜过更简单的方案？” 为了参加 TigerGraph Agentic GraphRAG 黑客松，我并排构建了三种问答流水线来一探究竟。
数据集包含约 2,900 篇有关奥运赛事的维基百科文章，以及 100 道带答案的评测题和 50 道隐藏题。问题分为五类：简单查询、多跳问题（“谁在这个场馆、这一天获得了金牌？”）、时间问题（“……在 2016 年之前最近一届奥运会上”）、聚合问题（“有多少个冬季两项赛事的参赛者超过 73 人？”）和极值问题（“哪个赛事的参赛者最多？”）。
早期的一项发现影响了整个方案：约 760 篇文档是干扰项——混在语料中的电影和公司文章。纯文本检索系统可能会被它们带偏。只根据奥运赛事记录构建的图谱则根本不会遇到这些内容。
我将每项赛事的维基百科信息框解析为结构化的Event顶点，涵盖运动项目、年份、季节、场馆、日期、参赛者人数、国家和奖牌获得者，并将其中 2,187 个加载到 TigerGraph Savanna。随后，我编写了用于筛选、计数和查询的 GSQL 查询端点。
关键的设计决策是，模型绝不计算答案。问题会转化为结构化计划，再由 TigerGraph 执行。统计 11 场冬季两项赛事并按参赛者人数筛选，是数据库的工作。让 LLM 根据检索到的几段文字猜答案，就会导致错误。
**RAG：**按相似度检索排名前 5 的文档，并从中读出答案。
**GraphRAG：**先规划，再执行一条图查询并返回结果。
**Agentic GraphRAG：**采用编排循环。它先规划，再查询图谱，判断证据是否充分；如果证据不足，就自行纠正（放宽筛选条件、重新匹配赛事），再与第二个来源交叉验证，并在有把握时停止。
| 流水线 | 准确率 | 估计每次查询的令牌数 |
|---|---|---|
| RAG | 18% | 1,573 |
| GraphRAG | 92% | 247 |
| Agentic GraphRAG | 100% | 1,295 |
RAG 在聚合和极值问题上的得分为 0%。你根本无法根据检索到的 5 篇文档统计 40 场赛事。对于“2016 年之前”这类问题，它也常常选错奥运年份，因为对文本检索器来说，“2012”和“1992”的相似度看起来一样。
GraphRAG 一举提升到 92%，令牌成本约为 RAG 的五分之一。
最后差的 8 个百分点来自多跳问题。比如：“谁在 2008 年 8 月 16 日于北京国家体育场获得金牌？”一个场馆承办几十场赛事，因此 GraphRAG 抓取了第一个匹配结果。智能体发现有多个候选项，便将此视为证据缺口，并用每项赛事记录中的确切日期消除歧义；若仍有并列，则以相似度搜索作为决胜依据。这种调查式行为让多跳问题的准确率从 71% 提升到 100%。
这才是真正的经验。**智能体并非处处更好。**对于大多数这类问题，设计良好的图查询已经足够，而且成本低得多。只有在证据含糊、需要核查时，智能体循环才发挥了作用。
- 在 Savanna 4.x 上，令牌来自
/gsql/v1/tokens，而不是旧版/restpp/requesttoken。 - 启用 Auto Resume ，否则工作区暂停后，每次 API 调用都会返回 HTTP 500。
- 通过 REST 调用已安装的 GSQL 查询时，必须提供所有参数，因此请使用无操作默认值。
代码： https://github.com/repulsortechnologies-alt/agentic-graphrag