AI 系统设计中一个常见的错误是要求语言模型像阅读文档一样对图（graph）进行推理。模型会生成一个自信且流利的答案。但这个答案会以一种看起来正确的方式出错——它会列出真实的节点，引用看似合理的路径，并描述几乎存在的关系。接着你会发现，你的组织架构遍历幻觉出了越级经理，你的依赖项解析忽略了超过十个节点的图中的循环，而你的三跳知识图谱查询在第二步时的错误率就达到了 60%。
这不是提示词（prompt）质量的问题。这是一个架构问题，你可以在编写任何提示词之前就诊断出它。
根本原因：序列模型具有线性先验
LLM 是在序列上训练的。它们的 Transformer 架构通过在令牌流（token stream）上的注意力机制从左到右处理文本，并构建表示。这对于语言来说极其有效，因为语言的意义沿着线性轴流动，具有局部且有时是长距离的依赖关系。
图不是序列。图没有规范的顺序。节点只有邻域（neighborhoods），没有位置。最短路径查询需要维护一个候选前沿（frontier），在每一步跳转时更新距离，并进行回溯——这些操作在下一个令牌预测中没有自然的类比。当你将图序列化为文本并交给 LLM 时，模型将其线性先验应用于一个本质上是非线性的结构。
经验证据是确凿的。在图计算任务（GraphArena, ICLR 2025）上对 LLM 进行基准测试的研究发现，在直径计算任务上，五节点图的幻觉率从 16% 跃升至三十节点图的 80% 以上。随着路径长度超过三或四跳，最短路径查询的成功率急剧下降。循环检测——在概念上很简单，只需要带有访问集合的深度优先搜索（DFS）——在超过十个节点的图上始终失败。这些数字并不会随着更好的提示词而显著改善；它们追踪的是任务的复杂性，而不是指令的质量。
Google 2024 年关于图编码的研究发现，仅序列化格式的选择就能使准确率波动 55 个百分点。这并不是说正确的编码解决了问题——这表明模型是在对文本结构进行模式匹配，而不是进行图推理。
构建前你需要了解的失败分类学
并非所有的图问题都会以同样的方式失败。在投入架构之前，对你的目标任务进行快速的复杂度审计。失败模式分为三类。
局部属性查询——边 (A, B) 是否存在？节点 X 的邻居是谁？——是最宽容的。LLM 可以在小图上可靠地处理这些问题，因为它们被简化为序列化文本中的类似于查找的操作。
路径依赖查询——最短路径、可达性、传递闭包——失败率与路径长度和图密度成正比。错误在每一步跳转中传播。每步准确率为 90% 的模型在三跳后准确率达到 73%，在五跳后降至 59%。多智能体路径规划研究发现，迷宫遍历中 77% 的失败来自于模型在局部区域振荡，而不是进行全局探索——这是模型将局部注意力应用于需要全局状态的问题时的典型症状。
全局属性查询——这个图是有向无环图吗？它的直径是多少？它是二分图吗？——对于任何非平凡的图，这些查询几乎总是错误的。这些任务要求模型同时整合整个结构的信息，而这在线性上下文中没有表示。
构建前的诊断非常简单：根据任务所属的类别和图的规模来表征你的任务。如果你的任务是路径依赖的且图有超过二十个节点，或者是全局属性的且图有超过十个节点，请不要要求 LLM 在上下文（context）中对图进行推理。使用工具。
实践中会出现什么问题：三种常见模式
组织架构遍历。有人构建了一个 HR 助手来回答关于汇报结构的问题。图被序列化为自然语言：“Alice 汇报给 Bob。Bob 汇报给 Carol。Dave 汇报给 Carol。”像“谁是 Alice 的同级经理？”这样的问题需要找到 Alice 的经理 (Bob)，找到 Bob 的经理 (Carol)，并找到 Carol 的除 Alice 以外的其他直接下属。LLM 经常会发生短路，返回 Bob 的同僚而不是 Alice 的同僚，或者将层级结构压缩一级。模型没有“级别”的表示——它只有给定的边标签，并用统计上最合理的答案填补空白。
依赖图解析。构建系统、包管理器和数据管道都涉及依赖图，其中“我可以运行步骤 X 吗？”这一问题需要检查所有上游节点是否已完成，以及图是否无环。如果循环足够长，以至于在生成过程中超出了模型的隐式注意力范围，LLM 会自信地报告循环依赖是安全的。在基准测试中，一旦循环长度超过五条边，循环检测失败率就会急剧增加。
多跳知识图谱查询。“哪家公司资助了收购开发这项技术的公司的初创公司？”是一个三跳查询。关于知识图谱问答的研究发现，多跳错误率会按跳数复合：每一步都会引入独立的幻觉风险，而后续的跳转则建立在先前的错误之上。如果模型在第二跳命名了错误的收购目标，那么第三跳就完全失去了依据。
补偿架构
这种行之有效的模式包含三个组成部分：有意识的编码（deliberate encoding）、外部遍历（external traversal）以及计划与执行分离（plan-execute separation）。
有意识的编码即便在你使用工具时也至关重要。当你需要 LLM 理解图结构——无论是规划遍历路径、解释结果还是说明路径时——你选择的编码格式会产生可衡量的影响。Google 的研究发现，事件式编码（incident-style encoding，即在描述每个节点时紧接着列出其相邻的边）的表现优于原始边列表和邻接矩阵。当 LLM 需要理解结构而非在其上执行代码时，自然语言形式的邻接列表（例如 “节点 A 连接到节点 B 和 C；节点 B 连接到节点 A 和 D”）比结构化格式的解析效果更可靠。对于语义图，请在节点 ID 旁边包含简短的实体描述——模型对 “Node_CEO_0: Alice, 工程副总裁” 的推理效果远好于 “Node_0”。
外部遍历工具是支撑系统的核心修复方案。GraphWalk 模式（2024）提供了一个极简且可验证的工具接口：模型可以查询节点的邻居、遍历特定的边、检索节点属性以及回溯。LLM 负责规划遍历并解释结果；每一个具体的步骤都由确定性函数执行，并在下一步开始前进行验证。这把图推理问题转化为了 LLM 擅长的规划与解释问题。对于知识图谱，等效的模式是 Cypher 或 SPARQL 生成——由模型编写查询语句，由数据库执行。模型的工作变成了将意图转化为查询语言，而不是在其上下文窗口中遍历图。
计划与执行分离推广了这一原则。LLM 产出高层级的遍历计划：“步骤 1：找到所有具有属性 X 的节点。步骤 2：针对每个结果，检索出边。步骤 3：按属性 Y 进行过滤。” 一个独立的执行层针对实际的图运行每个步骤，并将结果反馈给规划器。这创建了一个可验证的审计追踪。当答案错误时，你可以精确地检查是哪个步骤出了问题。
实践中的任务诊断
在构建之前，请对你的目标任务进行以下检查：
- 最坏情况下的查询需要多少跳（hops）？ 如果超过两跳，请为工具辅助遍历而设计，而非上下文内推理。
- 任务是否需要全局属性？ 环检测、直径、连通性、平面性——这些始终需要符号执行。
- 峰值负载时你的图有多大？ 对于路径查询超过 20 个节点，或对于全局查询超过 10 个节点，上下文内推理的可靠性就会低于生产环境阈值。
- 边权重是否关键？ 带权最短路径问题对 LLM 来说比无权路径难得多；权重值在 Token 空间中没有自然的表示形式。
- 你的任务是否需要跨分支维护状态？ 具有多个分支的决策树或选项树（tree-of-options）问题需要在工具调用中进行显式状态管理，而不是在上下文中进行隐式跟踪。
如果你的任务通过了所有这些关卡——小规模图、局部属性、不超过两跳——那么经过精心编码的上下文内推理可能会奏效。在确定架构之前，请先运行 50 次查询评估。如果失败率超过十分之一，请切换到基于工具的遍历。
这对你的设计意味着什么
在实践中，这意味着 AI 系统中的图结构数据需要与数据库查询得到相同的待遇：模型应该负责规划和解释，而不是执行。对于 SQL 这已经是成熟的模式（没有严肃的团队会提示 LLM 在上下文中扫描行），图数据也理应遵循同样的规范。
在知识图谱应用中，这意味着从一开始就采用 GraphRAG 或 Cypher 生成层，而不是在上下文内推理大规模失败时再进行补救。在组织架构和依赖关系应用中，这意味着构建显式的遍历 API——甚至是基于 networkx 图的简单 Python 函数——供模型调用，而不是让模型在输出中模拟遍历。
结合了基于 GNN 的结构推理与 LLM 语义理解的架构（如 GNN-RAG 及其变体）代表了这一领域的的前沿：让图原生模型处理消息传递和关系聚合，让 LLM 处理语言理解和解释。这两类问题的形状正好匹配这两种架构。
要避免的失败模式是那种“看起来行得通”的情况：模型对组织架构图或依赖图给出了流利、自信的回答，直到它出错为止。LLM 中的图推理缺陷在小规模时是隐形的，在大规模时则是灾难性的。诊断的成本很低，而修复方案——带有意识编码的工具化遍历——也很直接。请在集成之前进行诊断，而不是在事故发生之后。