想象你是探险队队长,目标是在一片未知森林里找到传说中的宝藏。最稳妥的做法是什么?不是让全体队员沿着唯一一条小路闷头走到底,而是派出几支小队分头探索不同的山道。每支小队在关键岔路口留下标记(营地),如果发现前方是断崖,就折返回来换一条路;几支小队在山谷汇合时,还会交换地图碎片,拼出更完整的路线。这套“多路探索—营地标记—回溯折返—汇合拼图”的打法,正是 Graph of Thought(GoT)思维图的核心思想。它把大模型的推理过程从一根笔直的单行线,升级成一张可以随意分叉、汇合、绕路的有向地图。相比传统 Chain-of-Thought(CoT)只允许“一路走到黑”,GoT 让模型同时考虑多条思路,把好的结论合并起来,把坏的思路及时掐掉,从而在数学证明、方案设计这类“岔路多、陷阱多”的复杂问题上,显著提升答案质量和可控性。
掌握 GoT 思维图,等于给你的大模型应用装上“多视角推理引擎”:无需更换模型,仅靠优化 Prompt 的结构化方式,就能让复杂任务的成功率与稳定性明显提升,是 AI 从业者性价比最高的进阶技能之一。
可视化演示
动态演示GoT思维图的核心机制,通过架构/数据/状态/性能四种模式展示关键概念与交互流程。
本节配有交互动效(进入视口后自动加载,约 3KB)。
GoT思维图:GoT思 GoT思维图核心原理与图结构推 推理分支的合并与聚合机制 核心机制可视化 GoT思维图整体架构与关键组件
核心概念
探险队出发前的第一件事,是画一张地图草稿。队长把所有人的计划摊开:哪个营地是起点,哪条路通往下一个观察点,哪几个岔路口值得分头走。在这张图上,营地与道路构成了一个网络,而不是一条笔直的路线。GoT 思维图做的正是这件事:它把大模型的思考过程显式地组织成一张有向图,图中每个顶点是一次中间思考的产物,每条边代表“从某个结论可以推导到另一个结论”的流动方向。
当你的 Prompt 告诉模型“请同时从三个角度分析这个问题”时,模型会从根问题分裂出多个推理分支。每个分支独立推进,各自生成自己的中间结论,这就是“多路探索”。如果一条分支发现矛盾,可以像探险队发现断崖一样折返;如果两条分支殊途同归,就在某个营地汇合,把信息合并成更强的结论。整个推理不再是一条单行线,而是一幅不断生长的地图。
地图的价值在于:它记录了所有可能性,而不是只记录碰巧走通的那一条路。GoT 的核心概念可以用一张有向图来概括:
有了图这份“总地图”,探险队就不再害怕迷路——因为每一条走过的路、每一个思考过的结论,都被记录在案,随时可以回头重新规划。
- 顶点集合 V图上所有“营地”的集合,每个营地是一个中间思考结论,比如“这条定理可以分两步证明”或“方案的第三个约束无法满足”。
- 推理边集 E营地之间的通路,表示从一个结论可以推导到另一个结论。边必须标明方向,就像山路有上下坡之分。
- 图 G把顶点和边打包到一起,就得到完整的推理图。这张图既记录了探索过的路径,也记录了还没走的岔路。
图结构设计
既然要把推理画成地图,就要先约定地图上的符号。在 GoT 中,顶点(Vertex)代表一个可独立评估的结论状态,它可能是一个子问题答案、一个中间假设、一组候选方案,甚至是一条被否定的路径。边(Edge)则代表结论之间的推导关系,例如“由分支 A 的结论可以推出分支 B 的下一步操作”。
探险队的地图上,一个营地可以有多个入口和多个出口。GoT 同样允许一个顶点被多条边指向:当几个分支小队各自得出部分结论时,所有结论都指向同一个汇合营地。此时,这个营地不再属于任何单一分支,而是多个分支共同孕育出的新结论。设计图结构时,最关键的问题是:哪些顶点应该聚合,哪些边应该允许回溯。
聚合点选得好,能像山谷隘口一样把多路人马汇成一股洪流;选得不好,则会强制合并两个实际上互斥的结论,让推理跑偏。回溯点则像地图上标注的“此路不通”记号,提示模型:从这个营地出发的这条边没有未来,请回到上一个岔路口另选方向。一个聚合结论的生成,本质上是对多个分支做信息融合:
图结构设计的功夫,就体现在这些聚合点与回溯点的选取上。地图画得好不好,直接决定了探险队能否高效抵达终点。
- 分支顶点 v_a、v_b两支探险小队分别产出的中间结论,比如“用归纳法证明可行”和“直接构造序列证明可行”。
- 信息融合 ⊕把 v_a 与 v_b 的内容拼接、对比,在 Prompt 中要求模型分析两套结论的共性与差异。
- 聚合函数 f大模型扮演“汇合点”,对融合后的信息做裁决与提炼,生成一个新的顶点 v_c,作为下一阶段推理的起点。
关键操作
探险队在地图上会执行四类动作:扎营、合并、修图、折返。GoT 与之对应的操作是:推理生成(Generation)、信息聚合(Aggregation)、结论精炼(Refinement)与循环回退(Feedback)。
推理生成发生在每个顶点上:模型根据当前顶点的内容,通过“下一步该做什么”的 Prompt 引导,生成一个或多个新的候选顶点。这是图扩张的基本动作,就像小队在每个营地决定下一个探索方向。信息聚合则是把多个顶点的结论汇总成一个新顶点,要求模型扮演评审团,找出这些结论中的共识、冲突与互补。结论精炼针对单个顶点:如果发现某个中间结论表述含混或覆盖面不足,模型会原地优化它,而不是推倒重来。循环回退则是在发现死路时,沿着之前的边返回到某个祖先顶点,重新选择分支执行推理生成。
这四种操作组合起来,构成了 GoT 推理的完整闭环。其中,信息聚合是最具特色的操作,它让图不是一堆散沙,而是一张真正能“合拢”的地图:
聚合不是简单地把文本拼在一起,而是让模型像队长听取各小队汇报一样,去芜存菁、提炼共识。因此聚合 Prompt 的质量,往往比分支数量更能决定最终答案的上限。
- 候选结论集多个分支产生的候选中间成果,比如三种不同的证明思路各自走到一半的结论。
- 聚合算子 AggPrompt 中约定的融合规则,它告诉模型“现在把这几条思路放在一起比较、取舍、整合”。
- 最终结论 q聚合后产出的统一顶点,它吸收了几个分支的精华,供后续推理继续使用。
与CoT对比
早期的 Chain-of-Thought 技术,像是探险队只派一支小队,沿着一条确定的路走下去。每走一步,都把推理过程写下来,直到抵达终点或撞上死路。它的优点是把“隐藏的思考过程”显性化,让模型一步步逼近答案;缺点也显而易见:一旦半路走错,必须从头再来,而且没有机会同时尝试另一条更优路线。
GoT 则将这支小队升级成一个探险网络。多支小队并行探索,既可以在岔路口分离,也可以在山谷汇合。从理论上看,在包含多条可行路径的搜索空间中,图结构一定能找到不短于线性链的最优路径。也就是说,GoT 在最坏情况下的表现不会比 CoT 差,而在复杂问题上往往能发现 CoT 看不到的“近路”:
不过,地图越丰富,绘制成本也越高。GoT 需要多次调用模型来生成分支、执行聚合,Token 消耗和延迟都会上升。因此场景选择很重要:简单的是非题用 CoT 就够了,涉及多路径组合推理的难题才值得动用 GoT。
- 路径集合 P图中所有从起点到终点的可用推理路径,每条路径由若干条边串联而成。
- 路径长度 |p|某条推理路径经过的边数,边数越少代表推理越直接。
- 最短路径与 CoT 对比对同样的问题,GoT 总会找到一条不劣于 CoT 的路径;在多岔路问题上,这条最短路径通常明显更短。
实战应用
讲到这里,你可能会问:这张地图在真实工作中到底能画出什么?最常见的战场是数学证明。面对“证明素数无穷多”这类问题,模型可以同时走“反证法”与“构造法”两条分支,一条构造出 N = p1×…×pn + 1,另一条证明 N 的因子不可能在已知素数列表中,最后在“矛盾”这个顶点汇合,得到完整证明。任何一条分支单独走,都容易在半路卡住,但合在一起就顺畅了。
方案设计是另一个典型场景。当 AI 需要为一个系统设计架构时,分支一负责“高可用方案”,分支二负责“低成本方案”,分支三负责“可扩展性分析”。聚合时,模型综合三者优劣,输出一个平衡方案。这比让模型一口气写一个方案要稳得多。代码生成与逻辑推理同理:多路探索能覆盖边界条件,回溯能在错误假设出现时及时纠偏。
多路探索之所以有效,是因为多个独立分支的成功概率可以被叠加。假设每个分支的成功率是 p_i,那么只要有一条分支成功,整体推理就不会失败:
实践中的经验是:GoT 最适合那些“一眼看不出唯一解法”的问题。越是需要组合多种知识、尝试多条路径的任务,图结构带来的收益就越明显。
- 每个分支的成功率 p_i第 i 条探索路线独立成功的概率,例如“反证法分支能走通的概率是 0.6”。
- 所有分支都失败的概率多条独立路线同时失败的机率,是各自失败率 (1−p_i) 的乘积。
- 至少一个分支成功用 1 减去“全军覆没”,得到整体成功率。分支越多,整体成功率越接近 100%。
实施策略
把 GoT 用到自己的项目里,不需要推翻现有 Prompt,只需要按策略改造它。第一步是“专家提示”:在 Prompt 中明确要求模型扮演一个推理队长,先列出若干独立的研究方向,再逐方向深挖。这样能把隐式的多路探索变成显式的分支操作,让模型更容易遵循。
第二步是决定“遍历顺序”。常见的策略是广度优先(先让所有分支都产生第一层结论,再统一评估该扩展哪个)和深度优先(沿着最有希望的分支一路走到底,走不通再回溯)。复杂问题上,广度优先更稳妥;需要快速验证一个想法的可行性时,深度优先更高效。第三步是“结果融合”:在聚合节点上,用专门的聚合 Prompt 让模型比较、筛选、合并各分支结论。每一步的取舍,都可以用一个加权评分来辅助决策:
一个可落地的 GoT Prompt 模板可以长这样:
把这张“探险指示图”交给模型,你就完成了从单链推理到图结构推理的升级。
---
- 评审维度得分 s_i对某个分支结论,从正确性、完整性、可行性等维度分别打分。
- 权重 w_i不同维度在任务中的重要性,比如数学证明中正确性权重最高,方案设计中可行性权重最高。
- 加权总分 S所有维度加权求和,得到分支的保留优先级,供模型决定优先扩展还是回溯。
你是一位严谨的推理队长,请用以下步骤分析问题:1. 发散:列出 3 个不同的研究方向,分别简述思路;2. 深入:对每个方向独立推进两步,并标注中间结论;3. 汇合:比较上述结论,找出共识与矛盾;4. 回溯:若某方向出现自相矛盾,说明矛盾点并返回岔路;5. 定稿:综合所有有效结论,输出最终答案。
AI 应用场景
智能数学解题助手
阶段:推理优化与答案生成
解决的问题:传统 CoT 在复杂数学题上一旦选错推导方向,就会一路错到底,用户得不到任何中间反馈。GoT 让解题系统同时从“几何法”和“代数法”两个方向探索,在中间节点比对两条路的结果,发现哪条路走不通就自动回溯换路,最终聚合出可信的解答过程。
具体案例:某在线教育平台接入大模型解题功能,学生提出“证明三角形的三条中线交于一点”。系统先用 GoT Prompt 分裂出“向量法”和“坐标法”两个分支,分别推导出重心位置,再在聚合节点验证两个结果一致后输出证明。相比之前单链推理,正确率从 61% 提升到 89%,且给出的步骤可回溯、可解释。
企业架构方案选优
阶段:多方案生成与聚合评估
解决的问题:让 AI 一次输出完整架构方案时,它很容易只考虑单一视角,遗漏成本或扩展性问题。GoT 引导模型先分裂出“高性能版”“低成本版”“易维护版”三个独立方案,再用聚合 Prompt 统一评估三个方案的约束满足情况,输出一个融合方案。
具体案例:某金融科技公司使用该策略生成微服务拆分方案。三个分支分别评估了吞吐量、开发成本和故障隔离能力,聚合后给出的混合方案比单次生成方案在压测中性能提升 32%,同时部署成本下降 18%。
代码缺陷多角度排查
阶段:问题定位与修复建议
解决的问题:代码出现 bug 时,原因往往不止一种。传统方式让 AI 直接读代码找错,容易被表象误导。GoT 让模型从“数据流异常”“接口契约不符”“边界条件未处理”三个角度独立排查,各分支产出嫌疑点后再聚合,交叉验证最终根因。
具体案例:一名后端工程师遇到线上接口偶发超时,借助 GoT Prompt 对代码进行多角度分析:数据流分支发现某字段可能为空,并发分支发现共享连接池耗尽,最终聚合定位到连接池参数配置不当,修复后超时率归零。
Python 演示
class GraphOfThought: """以有向图方式组织多分支推理过程。""" def __init__(self, root_question): self.nodes = {0: root_question} self.edges = [] self._counter = 1 def add_branch(self, parent_id, thought): node_id = self._counter self._counter += 1 self.nodes[node_id] = thought self.edges.append((parent_id, node_id)) return node_id def merge_nodes(self, node_ids, merged_thought): node_id = self._counter self._counter += 1 self.nodes[node_id] = merged_thought for nid in node_ids: self.edges.append((nid, node_id)) return node_id def get_paths(self, start=0): paths = [] def dfs(node_id, path): children = [e for e in self.edges if e[0] == node_id] if not children: paths.append(path + [node_id]) return for _, child in children: dfs(child, path + [node_id]) dfs(start, []) return paths if __name__ == "__main__": got = GraphOfThought("证明:素数有无限多个") p1 = got.add_branch(0, "假设素数是有限的 p1..pn") p2 = got.add_branch(0, "构造 N = p1*p2*...*pn + 1") combine = got.merge_nodes([p1, p2], "N 的质因子不在已知列表,矛盾") got.add_branch(combine, "所以素数无限多个") for path in got.get_paths(): print(" -> ".join(got.nodes[i][:10] for i in path))
self.nodes = {0: root_question}最初的用户问题被存成 0 号顶点,是整个推理图的起点。def add_branch(self, parent_id, thought)在指定父顶点上长出一条新的推导边,模拟探险队从营地出发进入新方向。self.edges.append((parent_id, node_id))把“从父到子”的有向边记录下来,让图结构逐步成型。def merge_nodes(self, node_ids, merged_thought)把多个顶点聚合成一个新顶点,并记录所有指向聚合点的边,完成信息汇聚。got.add_branch(0, "假设素数是有限的 p1..pn")从根问题分出一路“反设”分支,这是反证法的关键一步。got.merge_nodes([p1, p2], "N 的质因子不在已知列表,矛盾")两条分支在图中央汇合,聚合出矛盾结论。for path in got.get_paths():深度优先遍历整张图,输出每条从根到叶的完整推理路径,便于检查逻辑链路。
常见误区
误区我一开始以为 GoT 就是把同一个问题让模型多回答几遍,把几次 Chain-of-Thought 的结果放在一起挑一个最好的。既然都是让模型想很多次,那 GoT 也没什么特别的。
正解多跑几次 CoT 的各条分支互不连通,每轮都是独立重新开始,没有信息交换;而 GoT 的核心在于有向图结构,分支之间通过“聚合边”建立联系,新结论能继承多个分支的成果,死路也能被显式标记并回溯。好比几支探险队各走各的从不通信,与定期在山口交换情报完全是两回事。
为何常见:因为 GoT 和多次 CoT 在 Prompt 层面都表现为“让模型多方向思考”,初学者容易忽略图结构带来的信息流动,只看到表面上的“多次推理”。
误区既然多路探索比单路强,那我干脆让模型列出 10 个、20 个分支一起探索,答案岂不是更全面?分支越多,GoT 的效果越好。
正解分支数量翻倍,模型调用次数和 Token 消耗同步翻倍,但有效信息量并不会线性增长。更关键的是,分支越多,聚合操作的难度越大——让模型强行综合一堆互相冲突的中间结论,反而容易产生幻觉。实际使用中,3~5 个高质量分支通常已足够,聚合 Prompt 的质量比分支数量更重要。
为何常见:人们容易把“多样性”等同于“数量多”,而忽视了 GoT 的真正杠杆是结构化的聚合与回溯,而不是简单的暴力枚举。
误区GoT 听起来全面碾压 CoT,那我以后所有问题都用 GoT,把 CoT Prompt 全丢掉算了,反正图结构包含一切。
正解GoT 的每次分支、聚合都要额外调用模型,延迟和成本显著高于 CoT。对于“法国首都是哪里”“这个函数的时间复杂度是多少”这类单步问题,CoT 一次调用即可完成,用 GoT 反而画蛇添足。正确做法是把 GoT 当作复杂问题专用工具:当问题需要多路径探索、组合推理或反复试错时,才切换到图结构策略。
为何常见:看到 GoT 在 benchmark 上的亮眼表现后,容易忽略它适用的前提条件是“高复杂度问题”,而把新方法神化为万能药。
误区只要我在 Prompt 里写一句“请用 Graph of Thought 方式思考”,模型就会自动分裂分支、聚合结论,我不需要刻意设计任何提示结构。
正解GoT 的效果高度依赖 Prompt 中显式规定的“发散—深入—汇合—回溯—定稿”流程。模型不会凭空知道该在哪一步聚合、用什么标准回溯,你需要用清晰的指令告诉它:列出几个方向、每个方向推进几步、何时把结论交汇、矛盾时如何返回岔路。缺失这些结构化指令,模型产出的所谓“图”只是一段无序文本。
为何常见:市面上很多文章把 GoT 讲成一种“模型天然具备的能力”,让人误以为不需要工程化设计。实际上 GoT 首先是一种 Prompt 策略,结构的清晰度直接决定推理的质量。
面试题
Q1. Graph of Thought 中的“图”指的是什么?
- A.树形层级数据结构
- B.顶点与边构成的有向图← 正确答案
- C.神经网络的拓扑结构
- D.线性文本处理的表格
答案:B。GoT 把推理过程建模为有向图 G=(V,E),顶点是中间结论、边是推导关系,因此“图”指由顶点和边构成的有向图(B)。树是图的一种特例,但 GoT 允许分支聚合,会形成环,所以 A 不完整;C、D 与推理过程的建模无关。
Q2. 与 CoT 相比,GoT 的核心差别是什么?
- A.需要更多人工标注数据
- B.完全不需要编写提示词
- C.支持多分支聚合与回溯← 正确答案
- D.只能解决数学证明问题
答案:C。GoT 的关键能力是把多条推理分支组织成图,支持分支间的信息聚合和死路上的回溯(C)。A 与推理策略无关;B 错误,GoT 恰恰需要精心设计的 Prompt;D 错误,它同样适用于方案设计、代码调试等场景。
Q3. GoT 中“信息聚合”操作的作用是什么?
- A.删除冗余的中间结论
- B.合并多分支成统一结论← 正确答案
- C.把文本转换为向量表示
- D.压缩提示词的总体长度
答案:B。信息聚合是 GoT 最具特色的操作,它把多个分支的候选结论汇总、比对、提炼,生成一个统一的新顶点供后续推理使用(B)。A 是聚合过程中可能的附带动作但不是本质;C、D 属于其他技术领域的概念。
Q4. 下列哪类问题最适合使用 GoT 策略?
- A.简单事实型问答任务
- B.单轮短句翻译服务
- C.长文档自动摘要任务
- D.多路径组合的数学证明题← 正确答案
答案:D。GoT 的优势在于多路径探索与组合推理,数学证明题往往需要尝试多种证法并在中间汇合,是典型适用场景(D)。A、B 用 CoT 甚至零样本即可;C 的摘要更适合分层摘要方法,而非推理图。
Q5. 在 GoT 中,“回溯”对应探险队的哪个行为?
- A.出发前精心准备物资
- B.发现死路后返回换道← 正确答案
- C.组织全员同步向前推进
- D.在地图上补记新的营地点
答案:B。回溯是指当一条推理分支发现矛盾或走不通时,沿着边返回之前的岔路顶点,选择另一条分支继续推理(B)。A 是准备阶段,C 是同步推进,D 是生成新节点,均与折返纠错的行为不符。
Q6. GoT 中若三个分支得出的结论互相矛盾,正确的处理方式是?
- A.直接取第一个分支的答案
- B.将矛盾交由聚合逻辑裁决← 正确答案
- C.删除所有存在矛盾的分支
- D.随机选取其中一个分支结果
答案:B。多分支矛盾恰恰说明需要聚合操作:通过 Prompt 中的聚合逻辑让模型分析各分支的假设前提,找出矛盾根源并裁决(B)。A、D 忽略信息导致随机性;C 删除所有矛盾分支会把可能正确的结论一并丢掉,正确做法是保留并分析矛盾。
Q7. GoT 相对 CoT 的计算开销通常如何?
- A.一定比 CoT 成本更低
- B.成本完全一模一样
- C.多分支调用通常更高← 正确答案
- D.不消耗任何 Token 数量
答案:C。GoT 需要额外调用模型来生成每个分支、执行聚合和回溯,Token 消耗和延迟通常高于 CoT(C)。A 错误,多路探索必然带来额外成本;B 忽略分支数量差异;D 与事实完全相反。
Q8. GoT 推理过程包含哪些关键环节?
- A.单一路径的线性推进
- B.分支独立生成中间结论← 正确答案
- C.分支间信息聚合与融合← 正确答案
- D.生成顶点后继续扩展边← 正确答案
答案:BCD。GoT 的关键环节包括:分支推理生成(B)、信息聚合(C)以及通过边不断扩展新顶点(D)。A 是 CoT 的特点,不是 GoT 的环节。掌握这三点就能正确区分 GoT 与线性推理。
Q9. 设计 GoT 图结构时需要考虑哪些要素?
- A.顶点之间的有向边方向← 正确答案
- B.哪些分支需要做聚合← 正确答案
- C.分支失败后的回溯点← 正确答案
- D.模型参数量的大小
答案:ABC。图结构设计要明确边的方向表达推导关系(A)、定义分支聚合的位置(B)以及设置回溯点(C)。D 模型参数量属于部署层问题,与推理图结构设计无关。好的图结构是聚合点、回溯点与有向边的精心布局。
Q10. 下列哪些问题更适合用 GoT 解决?
- A.多约束条件下的方案选优← 正确答案
- B.包含多个子证明的定理推导← 正确答案
- C.单步常识性事实查询
- D.需要反复试错的程序调试← 正确答案
答案:ABD。多约束方案选优(A)、多子证明定理推导(B)、反复试错的程序调试(D)都需要多路径探索与聚合,适合 GoT。C 是简单事实查询,用直接回答或 CoT 即可,无需图结构增加复杂度。