当大模型从“回答问题”走向“执行任务”，Agent 需要的不只是语义相似度，而是对实体、事件与因果链条的结构化理解。图数据库与 GraphRAG 正在成为补上这块能力短板的关键拼图。

一、为什么 Agent 需要“关系”而不只是“文本”

传统 RAG（Retrieval-Augmented Generation）的核心逻辑是：把文档切块、向量化，再按语义相似度召回若干片段拼接进上下文。这套方法在“找一段相关描述”时表现不错，但一旦任务涉及多跳推理，就会暴露短板。

典型场景包括：

多跳问答：A 公司的子公司 B 的负责人同时任职于 C 机构，这类问题需要跨多个实体跳转。

全局性总结：如“这批文档里反复出现的核心矛盾是什么”，向量召回只能拿到局部片段，难以覆盖整体结构。

Agent 任务规划：Agent 要调用工具、串联步骤，必须知道“谁依赖谁”“哪个实体影响哪个结果”。

换句话说，向量检索擅长“相似”，而 Agent 的复杂任务往往需要“关联”。这正是图结构介入的切入点。

二、图数据库提供了什么

图数据库以节点（实体）和边（关系）为基本存储单元，天然适合表达：

实体之间的显式关系：人—公司—职位、药物—靶点—疾病、设备—部件—故障。

关系的属性与方向：边可以带权重、时间、类型，支持有向查询。

多跳遍历：从任一节点出发，沿关系路径扩展，代价远低于在关系型数据库中做多层 JOIN。

对 Agent 而言，图数据库相当于一张可查询的“世界关系地图”。Agent 不再只拿到一段文字，而是能沿着关系路径逐步取证、验证和推理。

三、GraphRAG 的思路

GraphRAG 可以理解为把图结构引入 RAG 流程的一类方法。其核心思路通常包含以下环节：

抽取：从原始文本中识别实体与关系，构建知识图谱。

建图：将实体、关系、以及可能的社区/簇结构写入图存储。

检索：查询时不仅做向量相似度匹配，还沿图进行多跳扩展或社区聚合。

生成：把结构化的子图或路径作为上下文交给 LLM，产出更贴合关系的回答。

与纯向量 RAG 相比，GraphRAG 的价值主要体现在：

可解释性：答案可以追溯到具体的实体和关系路径。

多跳能力：支持跨实体的链式推理。

全局视角：通过社区摘要等方式覆盖文档整体，而非零散片段。

需要说明的是，GraphRAG 并非要取代向量检索。实践中更常见的是混合方案：向量负责语义召回，图负责关系扩展与约束。

四、落到 Agent 身上：三个结合点

1. 作为 Agent 的长期记忆结构

Agent 在长期运行中会积累大量交互与事实。若只以对话历史或向量库存储，关系会逐渐模糊。用图组织记忆，可以让 Agent 明确“这个用户属于哪个组织”“这个任务依赖哪些前置条件”。

2. 作为工具调用的路由依据

当 Agent 面对多个工具或 API 时，图可以帮助判断调用顺序与依赖关系，减少无效尝试。

3. 作为推理过程的中间表示

Agent 的推理链可以映射为图中的路径遍历，每一步都有据可查，便于调试与审计。

五、工程上需要正视的挑战

落地图数据库 + GraphRAG 时，以下问题通常无法回避：

抽取质量：实体与关系抽取的准确率直接决定图的质量，错误会沿路径传播。

Schema 设计：是固定本体还是开放抽取，需要根据业务权衡。

成本与延迟：建图、多跳查询、社区摘要都会带来额外开销。

更新与一致性：源数据变化时，图如何增量更新、如何与向量库保持同步。

评估困难：多跳与全局性任务的评测指标，仍不如传统检索成熟。

结语

Agent 要理解复杂关系，靠的不只是更大的上下文窗口，而是更合适的知识结构。图数据库提供了关系的骨架，GraphRAG 提供了把骨架接入生成流程的方法。二者结合，未必能解决所有问题，但至少让 Agent 在“关系”这件事上，有了比向量相似度更扎实的抓手。

生成标记：本文由 ITPUB 文章生成平台基于已选素材整理生成。