← 返回 PaperDaily
大模型与智能体
多伦多大学新基准：AI在复杂任务中准确率暴跌33%，上下文管理是致命短板
最近大家都在追怎么让AI“长记忆”，但你有没想过：就算记忆再长，记错关键计算的中间结果、或者被无关干扰冲昏头脑，照样白搭？多伦多大学联合Vector Institute的新工作ArbiGraph，就用一套可验证的任务图，精准拷打了语言代理在复杂流程中的“上下文管理”能力。结果有点扎心：Qwen3.5-27B单做一题数学题94.5%正确，但放进带分支的依赖链里
龙哥读论文
阅读 3
查看原文
龙哥推荐理由：
最近大家都在追怎么让AI“长记忆”，但你有没想过：就算记忆再长，记错关键计算的中间结果、或者被无关干扰冲昏头脑，照样白搭？多伦多大学联合Vector Institute的新工作ArbiGraph，就用一套可验证的任务图，精准拷打了语言代理在复杂流程中的“上下文管理”能力。结果有点扎心：Qwen3.5-27B单做一题数学题94.5%正确，但放进带分支的依赖链里，准确率直接跌到61.2%——整整掉了33个点！这不是模型笨，而是它根本不擅长区分“哪些该记、哪些该忘、哪些该传下去”。这个基准生成器思路挺新，值得每一个搞Agent的团队看一看。
原论文信息如下：
想象一下这个场景：你让一个AI助手帮你处理了一套复杂的财务计算——先算税前利润、再扣税、再算投资回报率。它每一步都算得完全正确。可当你接着让它查一下昨天会议纪要里的某个数字时，它却把刚才算的“投资回报率”当成了会议数字来回复你。
这不是AI变笨了，而是它的上下文管理系统出了大问题：该记住的不够牢，该忘记的却牢牢霸占着思维空间。
现在的语言模型代理（LLM Agent）越来越擅长处理单一任务。给它们一道数学题、一段代码或一个简单的问题，它们能答得准准的。但当把它们放进一个包含多个依赖步骤的工作流时，情况就完全不同了——中间结果需要被正确传递、旧的计算需要被主动忘记、无关信息不能干扰后续推理。这些能力的缺失，正是当前大模型评测中一个被严重低估的盲区。
现有的长上下文评测基准（如RULER、LongBench）更多是在考查“从长篇文档中检索事实”的能力，而不是考查代理是否能够通过跨任务的类型化状态传播来管理推理上下文。这就好比考试只考你能不能从一本厚书里找到某句话，却从不考你能否在解完15道连环题后还记得中间结果应该传给谁。
多伦多大学与Vector Institute的研究者们正是看到了这个缺口，于是推出了ARBIGRAPH——一个可任意扩展的、可验证的任务图生成框架，专门用来拷打语言代理在多步依赖流程中的上下文管理能力。它的核心洞察很直接：把上下文从“一堆文本”变成“带类型的计算状态”，然后设计不同的依赖拓扑结构，看看代理到底能不能正确地保存、更新、传递和丢弃中间计算值。
ArbiGraph的总体框架可以这样理解：它把一个完整的评估流程抽象为“用户指定一个依赖图结构→框架自动用兼容的任务填充图中的每个节点→渲染成一个包含所有子问题的单条prompt→让代理去解→用Python可执行代码验证最终答案”。整个过程完全自动化，不需要人工编写每个测试用例。
下图展示了这个生成器的抽象流程以及一个生成的链式prompt实例（图1）。从图中可以看到，底层生成器接收一个任务图和一系列可执行的任务模板，输出的是自动生成、自动验证的基准数据集（单条prompt）。下方的实例则展示了代理实际看到的prompt片段：蓝色文字是输入，橙色是预处理适配器，绿色是任务特定计算，紫色是输出。
图1：ARBIGRAPH生成器抽象与生成实例。上方：生成器将任务图与类型化可执行任务模板结合，生成自动验证的单提示基准数据集。下方：链式提示片段示例（代理所见）。颜色标记提示角色：蓝色为输入，橙色为预处理适配器，绿色为任务特定计算，紫色为输出。
ArbiGraph的设计精髓在于：它把“上下文管理”这个模糊概念操作化为四种明确的评估拓扑结构，每种拓扑对应一种特定的上下文管理能力。
图2：ARBIGRAPH评估布局。基线拓扑包含单一目标任务。遗忘拓扑在目标任务前放置3个独立干扰任务。链式拓扑通过3个任务的线性依赖路径传递输出。多链拓扑引入分支依赖图，中间状态分裂、独立演化，在最终目标前重新合并。
只有单一目标任务，没有干扰、没有依赖。这个拓扑用来确定模型对目标的“本地求解能力”到底有多高。如果模型连这个都做不好，那后面的测试就无从谈起了。在实验中，基线拓扑为每个任务类别生成了16个独立样本，每个样本只包含一个子问题，不涉及任何跨任务的状态传递。这相当于给模型一个“开卷考试”，只考它会不会做这道题，而不考它是否能在多步流程中保持清醒。
在目标任务前面插入3个独立的不相关任务（干扰项）。目标任务的输入与其他任务完全无关。成功的关键不是“多记得”，而是“记得什么该忘”——能忽略无关计算的中间结果，不让它们干扰最后的答案。实际上，这比简单的检索更难，因为干扰项也是计算任务，它们的“计算真实感”会诱使模型去考虑它们。在遗忘拓扑中，三个干扰任务与目标任务之间没有任何数据依赖关系，它们的输出也不会被目标任务使用。模型必须学会在阅读prompt时主动忽略这些干扰任务的计算过程，只关注与最终目标相关的信息。这种能力在现实场景中非常关键，因为一个Agent在处理复杂任务时，往往会遇到大量无关的上下文信息，如果不能有效过滤，就会导致“信息过载”式的推理失败。
4个任务形成线性依赖链：第一个任务的输出作为第二个的输入，依此类推。目标放在最后。这种拓扑测试的是模型能否在连续的步骤中正确传递中间状态。每一步的错误都会累积，所以这比单纯的多步推理更难。在链式拓扑中，任务A的输出经过预处理适配器后成为任务B的输入，任务B的输出再经过适配器成为任务C的输入，最后任务C的输出作为目标任务D的输入。模型必须准确记住每一步的计算结果，并在后续步骤中正确使用。如果模型在某个中间步骤中记错了数值，或者错误地使用了前一步的输出，那么后续所有步骤都会受到影响，最终导致目标任务失败。这种错误累积效应在数学任务中尤为明显，因为数学计算通常要求精确的数值传递。
这是一种有向无环图（DAG）结构：一个列表输出任务先分裂成多个标量分支，每个分支独立演化处理，然后再合并为一个列表输入到下一个任务。多链布局包含8个任务，复杂度明显高于前面的几种。这是对模型“同时管理多条活动状态线程”的能力的终极考验。具体来说，多链拓扑中有一个初始任务输出一个列表，这个列表被拆分成多个标量元素，每个标量元素分别进入不同的独立计算分支。每个分支可能包含多个任务，这些任务只处理自己分支的标量值，不与其他分支交互。最后，所有分支的输出被重新合并成一个列表，作为最终目标任务的输入。模型必须同时跟踪多个分支的计算状态，确保每个分支的值在各自的任务链中正确传递，并且在合并时不会混淆不同分支的结果。这种拓扑模拟了现实世界中许多并行处理的工作流，比如同时处理多个数据流，最后汇总结果。
通过比较这四种拓扑下的表现差距，ArbiGraph就能有效地分离出“本地任务解决能力”与“上下文管理能力”——后者正是这篇论文想要捕捉的关键信号。
一个可链化的任务节点被定义为六元组：输入x_i、预处理适配器a_i、自然语言prompt p_i、后处理适配器b_i、输出y_i，以及可执行求解器s_i。代理永远不会看到s_i，但基准生成器用s_i来计算ground truth答案。当前实现中，中间值的类型限定为标量（int/float）和列表，这两种类型已经够用来组合算术、文字题和代码追踪任务。预处理适配器a_i负责将前驱节点的输出转换为当前任务所需的内部格式，例如将一个列表截断为前5个元素，或者将一个标量取模100。后处理适配器b_i则将当前任务的输出转换回图级的标准类型，确保与后续节点的输入类型兼容。这种类型化设计使得不同任务可以灵活组合，只要它们的输入输出类型匹配即可。
虽然现在的语言模型在单道题目上表现亮眼，但在实际工作流中，它们往往需要处理多个相互依赖的子任务。比如一个简单的数据清洗流程：先解析原始CSV，再过滤异常值，接着归一化，最后做统计汇总——每一步的输出都是下一步的输入。如果一个模型在单步上正确率99%，但每步错误率累积，到第四步时正确率可能只有96%左右，这还是乐观的估计。更麻烦的是，中间一旦出现偏差，后续所有步骤都会受到污染。
ArbiGraph把这种多步依赖问题抽象成了可验证的任务图。一个任务图由节点和边组成：每个节点是一个自然语言描述的子问题，同时附带一个Python求解器（agent看不到，但用来生成标准答案）；边表示数据依赖，即前一个节点的输出作为后一个节点的输入。用户可以像搭积木一样指定任意有向无环图（DAG）——可以是单节点基线、线性链、带干扰的链，甚至分支合并的复杂图。ArbiGraph的生成器会依据用户指定的拓扑，自动从任务模板库中挑选兼容的任务，生成具体的prompt，并计算出所有中间值和最终答案。整个过程不需要人工编写任何一个测试用例，而且所有答案都可以用Python代码精确验证。
这种设计最大的价值在于可控性：通过系统性地改变图中的节点数、依赖深度、干扰项数量和数据类型，我们可以精细地探测模型在不同维度上的上下文管理退化曲线。这远比固定模板的评测更具诊断力。例如，研究者可以设计一个包含10个节点的链式拓扑，观察模型在长链上的错误累积模式；也可以设计一个包含多个分支的复杂DAG，测试模型在并行状态管理上的极限。这种灵活性使得ArbiGraph不仅是一个评测工具，更是一个诊断工具，可以帮助研究者定位模型在上下文管理方面的具体短板。
Qwen3.5-27B在ARBIGRAPH上的“压力测试”实录：数学链准确率暴跌33%
论文中报告了使用Qwen3.5-27B模型（带计算器工具）在ArbiGraph上的初步评估结果。实验覆盖了数学、Python代码追踪和GSM文字题三大任务类别，每种类别都在四种拓扑上各生成16个样本。下面的图3展示了最核心的对比——不同拓扑下的最终任务准确率。
图3：Qwen3.5-27B在ARBIGRAPH各拓扑上的最终任务准确率。基线为孤立任务，遗忘拓扑添加独立干扰，链式拓扑需线性状态传播，多链拓扑需分支状态传播。
基线表现很强数学94.5%，Python追踪96.8%，GSM文字题100%。说明模型本身具备足够的本地求解能力，问题不出在“会不会做”上。这些高基线分数也验证了任务模板的质量——它们不是故意刁难模型的无意义计算，而是模型确实有能力解决的合理问题。
遗忘压力有效但温和数学降至89.2%，Python降至92.5%。说明无关计算的干扰虽然导致了一定损失，但模型仍能基本抵御。值得注意的是，GSM文字题在遗忘拓扑下仍然保持了100%的准确率，这可能是因为文字题的语言描述提供了丰富的语义线索，使得模型更容易识别哪些任务是相关的，哪些是干扰。相比之下，数学任务对数值的精确性要求更高，干扰任务的计算过程更容易让模型产生混淆。
依赖链才是真正的杀手数学链准确率跌至75.5%，多链进一步跌至61.2%——相比基线降幅达33.3个百分点！Python追踪相比之下稳健得多，链式仍保持90.1%，多链90.5%。GSM文字题在链式下仍有96.0%，遗忘拓扑下100%。
这个巨大的类别差异很有意思。数学任务通常涉及精确的标量/列表转换和数值运算，一步算错后续全乱；而Python追踪任务虽然也有复杂逻辑，但模型往往可以通过部分执行或推理来验证中间步骤，容错性更强。GSM文字题因为语言描述提供了额外的语义线索，即使计算过程有瑕疵，最终答案也容易猜对。此外，Python追踪任务的prompt中包含了函数定义和示例代码，这些额外的上下文信息可以帮助模型更好地理解任务逻辑，从而在状态传播过程中保持更高的准确性。
除了最终的准确率，ArbiGraph还记录了过程指标——平均生成的token长度和平均会话轮数，分别对应图4和图5。
图4：Qwen3.5-27B的平均生成token长度。
图5：Qwen3.5-27B的平均agent轮数。
可以看出，随着拓扑复杂度的增加，模型消耗的token和轮数几乎都同步增长。最突出的是数学链和多链，token长度和轮数均远高于基线。这说明模型并非“快速犯错”，而是真的花了更多精力去推理、试错、修复，但最终还是没能正确传播状态。过程指标与准确率的下滑互为印证，揭示了上下文管理失败不仅仅是一个结果问题，更是一个“认知负担”问题——模型在复杂图上表现得更加吃力，却仍然失败。例如，在数学多链拓扑中，平均token长度从基线的约500个token增加到超过2000个token，平均轮数也从基线的约2轮增加到超过8轮。这表明模型在尝试通过更多的推理步骤和工具调用来弥补上下文管理能力的不足，但效果有限。
如何搭建你自己的上下文管理评估：ARBIGRAPH设计原理全解析
ArbiGraph的底层设计围绕几个关键抽象展开，理解这些抽象就能自己构建类似的测试。下面逐一拆解。
一个可以在图中使用的任务节点被形式化定义为六元组：
任务节点六元组：输入x_i、预处理适配器a_i、自然语言prompt p_i、后处理适配器b_i、输出y_i、可执行求解器s_i。
其中x_i是输入（可能来自前驱节点的输出），a_i是预处理适配器，负责将输入转换为任务内部格式（比如截断列表、取模、强制整数化等）；p_i是自然语言prompt模板；b_i是后处理适配器，将任务内部输出转换回图级的标准类型（标量或列表）；y_i是输出值；s_i是Python可执行求解器，用于生成ground truth。Agent只能看到p_i，看不到s_i，这样就避免了作弊。这种设计确保了评估的公平性：模型必须通过理解自然语言prompt来解决问题，而不能直接访问求解器。
两个任务可以组合成边，只要输出类型与输入类型兼容（当前只有标量和列表两种）。ArbiGraph使用NetworkX构建DAG，用户只需提供一个描述节点和边的JSON即可。适配器层是确保可组合性的关键：它让不同任务可以互相连接，即使它们内部使用不同的数值范围或数据结构。例如，一个输出大数值的数学任务可以通过适配器在取模100后再传给下一个任务，避免数值爆炸。论文中默认将列表长度限制在10以内，标量幅度限制在100以内。这种限制不仅控制了问题的复杂度，也防止了模型通过猜测大数规律来作弊。适配器层的设计使得ArbiGraph具有很强的扩展性：只要新任务遵循相同的输入输出类型约定，就可以无缝集成到现有的任务图中。
数学任务40种手选算子，覆盖线性代数、多项式、离散变换、组合数学、几何和数论。按输入输出类型分为四个象限：列表→列表（10种）、列表→标量（10种）、标量→标量（10种）、标量→列表（10种）。这些算子都是精确可计算且输出行为可控的，避免了数值爆炸或退化为平凡常数。例如，列表→列表的算子包括列表排序、列表反转、列表元素平方等；标量→标量的算子包括取模运算、最大公约数、最小公倍数等。每个算子都配有对应的Python求解器，可以精确计算ground truth。
Python代码追踪任务从LeetCode数据集中选取了80个算法，要求模型“追踪”一个具体函数在具体输入上的执行过程（而非自己写代码）。这些函数涵盖了数组处理、排序搜索、栈与贪心、动态规划、模拟和算术等。任务生成器会解析函数签名，识别输入输出类型，并将链式输入绑定到一个兼容参数上，其余参数由静态随机值填充。例如，对于一个两数之和的函数，链式输入会被绑定到其中一个参数上，另一个参数由随机值填充。这种设计确保了每个任务都有唯一的正确答案，同时避免了模型通过记忆常见输入输出对来作弊。
GSM文字题基于GSM-Symbolic模板，是一个仅支持标量→标量的类别。它增加了自然语言描述的多样性，作为体系中的“干扰任务”和语言算术节点非常合适。GSM文字题通常以故事形式呈现，例如“小明有5个苹果，小红给了小明3个苹果，请问小明现在有多少个苹果？”这种任务虽然计算简单，但自然语言描述增加了模型的语义理解负担，可以测试模型在语言干扰下的上下文管理能力。
长prompt中的多任务交互会引入一些非上下文管理的机械故障，例如工具调用格式错误、缺少boxed答案、输出截断等。为了分离这些干扰，ArbiGraph设计了修复协议：如果agent首次回复中没有合法计算器调用，则发送短修复提示要求补一个；如果缺少某些boxed答案，则要求补充；如果达到最大token限制，则要求继续。每个拓扑都有固定的修复预算（例如基线最多5次工具修复、3次答案修复、3次续写修复）。修复后仍失败的结果计入错误分母。这样可以确保准确率下降反映的是真正的认知/上下文管理失败，而非格式错误。修复协议的引入显著提升了评估的信度，使得不同模型之间的比较更加公平。
生成每个实例时，先随机选一个目标任务，再随机生成输入（对于基线）或根据拓扑构造依赖链。每个生成的样例都会通过求解器计算ground truth，并过滤掉那些输出退化为0、1、-1、无穷大、空列表、单元素列表或重复列表的退化实例。过滤是为了防止模型通过捷径猜对答案。论文以随机种子0生成了每个任务的16个样本，最终语料库规模可观。例如，对于数学任务，40种算子每种生成16个样本，总共640个基线样本；对于链式拓扑，每个链包含4个任务，总共生成16个链式样本。这种生成流程确保了每个测试用例都是唯一的、非平凡的，并且具有明确的正确答案。
龙迷三问
ArbiGraph跟现有长上下文基准（如RULER、LongBench）有什么区别？现有基准主要测试“从长文本中检索信息”的能力，比如找一句话、数数字等。而ArbiGraph测试的是任务间的状态传播能力：你必须记住前一个任务的输出，并根据依赖关系正确传递给下一个任务，同时还要忽略无关任务的干扰。这是两种完全不同的认知负荷。简单来说，RULER考的是“在图书馆里找一本书”，而ArbiGraph考的是“在流水线上组装一个产品，每个步骤的零件都不能搞混”。
为什么数学链的准确率下降比Python追踪更严重？数学任务涉及精确的数值转换和闭式运算，一步算错后面就全错了，错误会累积。Python追踪任务虽然也有链式依赖，但模型可以通过对函数的局部推理（例如知道一个排序函数会返回有序列表）来帮助判断，即使中间某个变量记岔了，也可能通过推理修正。此外，Python追踪的prompt中包含了函数定义和示例，提供了更多的上下文线索。例如，如果一个Python追踪任务要求模型追踪一个快速排序函数的执行过程，模型即使忘记了某个中间步骤的精确值，也可以通过排序算法的逻辑来推断输出应该是一个有序列表，从而在一定程度上弥补记忆错误。
ArbiGraph只能测试Qwen模型吗？我能用它测试GPT-4或Claude吗？ArbiGraph完全通用，但需要自己写一个agent harness（工具调用循环）。论文开源了Qwen的评估代码，但接口是可扩展的。你只需要实现与模型API的交互，并遵循同样的修复协议即可。注意不同模型对长上下文的处理能力不同，ArbiGraph正好可以帮你精确对比它们的上下文管理短板。例如，你可以用ArbiGraph测试GPT-4在数学多链拓扑上的表现，看看它是否比Qwen3.5-27B更好地处理分支状态传播。这种跨模型的比较对于理解不同架构的上下文管理能力非常有价值。
如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~
龙哥点评
论文创新性分数：★★★★☆
将上下文管理抽象为类型化状态传播任务图，并引入可控拓扑变化来分离不同维度的失败模式，思路新颖且实用。虽然类似的可验证合成基准已有（如GSM-Symbolic），但ArbiGraph的图结构可编程性是一个明显的增量创新。它首次将“上下文管理”这个模糊概念操作化为可量化的评估指标，为后续研究提供了标准化的测试平台。
实验合理度：★★★★☆
实验设计工整：四种拓扑+三类任务+过程指标，足以支撑核心结论。但仅测试了单模型Qwen3.5-27B，代表性有限。修复协议的引入提升了评估的信度。未来如果能扩展到更多模型（如GPT-4、Claude-3、Llama-3等），将能
