改一个数字，全身都得动：RevPropBench 拷问大模型的"牵一发动全身"能力
你有没有遇到过这种场景：让 AI 帮你排了一份旅行计划，你说"把景点 B 去掉"，它乖乖把 B 删了，时间表也顺了——但预算栏还写着原来的数字。或者让它维护一份项目排期，你删掉一个任务，后继任务的依赖链却没重新接上。
说实话，这个问题我自己在做 Agent 产品的时候被坑过不止一次。用户的修订请求永远只说"改这里"，但产物里藏着一堆隐式依赖，改一个数字，全身都得动。上周翻到这篇被 EMNLP 2026 Industry Track 接收的论文（arXiv:2609.03254），算是第一次有人把这个问题单独拎出来做成了基准，而且顺手回答了工程师最关心的问题：用测试时计算来补救，怎么花最少的钱涨最多的点。
核心摘要
这篇论文提出 RevPropBench，专门评估 LLM 在对话生成的 JSON 产物上做"修订传播"的能力——用户只提局部修改，模型要自己找出所有受牵连的部分一起改。基准含 150 个样本，覆盖 9 个领域、6 种传播模式、3 种产物规模。作者在 6 个模型上评了 9 种修订方法，结论很务实：单次推理基线完成率只有 68.3%–93%，而从 3 个并行样本里挑一个（用 LLM 选或用 medoid 规则选）是性价比之王，只多花一点钱就把准确率抬了 2.2 到 9.7 个点。论文不是底层突破，但任务定义扎实、工程结论可直接抄作业，做 Agent 编辑类产品的人值得细读。
论文信息
- 标题：What Else Needs Fixing? Exploring Cost-Effective Test-Time Compute for Revision Propagation in Artifacts Generated Through Conversation
- 作者：Daisuke Kikuta（NTT）
- 发表：arXiv:2609.03254，2026 年 9 月 3 日；EMNLP 2026 Industry Track 接收
- 代码与数据：https://github.com/ntt-dkiku/llm-revision-propagation
🎯 问题动机：这个坑为什么之前没人填
先把这个任务讲清楚。LLM 帮你生成产物——文档、计划、配置——通常是多轮对话逐步搭起来的。搭完之后你说"把发票第二行的数量改成 5"，模型只改那一行是不够的：行金额要重算，小计要重算，基于小计的税费和总额全都要跟着变。这个"顺着依赖链把修改传导下去"的动作，作者称之为 revision propagation（修订传播）。
图1：一个旅行计划的例子。生成阶段用户和模型聊出了目的地、时间表、按人头算的预算；修订阶段用户只说"去掉目的地 B"。错误的回答（红框）删了 B、把时间从 20:00 提前到 19:00，但预算还是 $200×3；正确的回答（绿框）必须把预算同步改成 $180×3。漏掉的那一步就是"修订传播"失败。
等等，这个能力之前没人研究吗？我的第一反应也是这个。但翻一下相关工作会发现，已有的几类任务都绕开了真正的难点：
| 已有任务 | 代表工作 | 依赖从哪来 |
|---|---|---|
| 仓库级代码编辑 | SWE-bench、CodePlan、DependEval | 调用图、import、变量引用，可静态分析 |
| 知识编辑 | RippleEdits、ChainEdit | 预先存在的知识图谱 |
| 文档编辑 | EditPropBench、LEDGER | 章节、图表、引用等显式结构 |
| 对话生成产物（本论文） | RevPropBench | 隐式依赖，甚至藏在对话历史里、产物之外 |
关键差别在最后这一类。比如预算为什么是 $200×3？因为第三轮对话里用户说了"3 个人"——这个依赖关系不在最终 JSON 里，而在对话历史里。只盯着产物本身做静态分析是找不到的。这是一个真实存在、且此前没有被系统测过的盲区。
🏗️ RevPropBench：这个基准是怎么搭出来的
基准聚焦 JSON 产物（理由很简单：Agent 系统里结构化输出大多走 JSON）。每个样本包含一段预先合成好的多轮对话、一个局部修订请求，以及一份 gold patch。模型要做的不是重新生成整个 JSON，而是输出 JSON Patch（RFC 6902）——一串 (op, path, value) 三元组，op 取 replace、add、remove。评估标准是打补丁后的产物与 gold 产物完全一致（completion rate），自由文本字段用关键词 matcher 宽松匹配。
图2：基准的完整流水线。左上 Data Sampling：人类设计的场景（领域、对话流、传播模式、轮数）喂给 GPT-5.5，合成对话历史和修订请求；右上 Annotation：Claude-Opus-4.8 先生成 tentative gold patch，人类标注者审查修正；左下是最终数据集结构（对话 + 修订请求 + gold patch）；右下 Evaluation：被测 LLM 输出 patch，与 gold patch 比对——图中红字标出的就是漏改预算的典型 miss 错误。
几个值得说的设计细节。
规模与覆盖：150 个样本 = 50 个场景 × 3 种产物大小（10 / 50 / 100 个 JSON 元素），按场景级别切成 30 个开发样本 + 120 个测试样本。覆盖 9 个领域：旅行行程、发票、购物车、项目排期、课程计划、数据管道、软件部署配置、组织访问计划、制造业 BOM。
六种传播模式，这是基准的灵魂，我整理成一张表：
| 模式 | 一句话解释 | 典型场景 |
|---|---|---|
| arithmetic | 数值进了公式链 | 改发票某行数量 → 行金额、小计、税费、总额连锁重算 |
| substitution | 换了实体，管辖属性跟着换 | 换员工角色 → 权限组、审批限额、培训要求全部替换 |
| add_remove | 增删元素，下游链接和聚合更新 | 删任务 → 后继重新链接、下游日期提前、结束时间变化 |
| threshold | 效果取决于是否跨阈值 | 数据量跨过阈值才翻转分区策略 |
| temporal | 日期沿依赖链平移 | 移动锚定日期 → 派生日期同步平移，独立日期不动 |
| status_flip | 状态变更带动一组字段 | 发票标记为已支付 → 所有状态管辖字段一起切 |
标注质量：合成数据由 GPT-5.5 生成对话，Claude-Opus-4.8 出 tentative gold patch，最后人工过一遍。150 个样本里 23 个（15%）被人工修正，标注花了 10 天 32 个小时以上。每个操作还标注了 direct（请求里明说）还是 cascade（因依赖必须联动），以及 optional 标志（改不改都合理的元素，两种处理都算对）——这个 optional 设计挺细的，避免了把合理差异误判成错误。
🔧 九种方法：从单发到群殴
作者把 9 种方法分成四类，核心变量只有一个：测试时计算怎么花。
单推理基线（3 种），区别只在给什么上下文： - j：只给最终 JSON 产物 - h：只给对话历史 - j+h：两者都给
顺序反思（1 种）： - Reflect：从 j+h 的初始 patch 出发，迭代反思修正，4 次反思共 5 次调用。每轮给模型看打完补丁的产物，让它只修"确定的错误"——遗漏的强制变更、多余修改、值错误、无效路径。
并行采样 + 规则合并（4 种）：先并行采多个 patch，再在叶级键值对层面合并： - or：任一候选改了某个叶子就采纳（多个版本取最早的） - and：所有候选一致才采纳 - maj：严格多数（超过 k/2）一致才采纳 - med（medoid）：受最小贝叶斯风险解码启发，返回与其他候选平均不一致度最小的那个完整候选
并行采样 + LLM 选择（1 种）： - Select：并行采 4 个 patch，再用同一个 LLM 挑一个作为最终答案（共 5 次调用）。
说实话，这套方法矩阵没有一个是新发明——反思、自洽性采样、MBR 解码、LLM-as-selector 都是现成工具。论文的价值不在方法创新，而在把这套工具在新任务上做了系统性的成本-效果标定。
📊 实验结果：谁是性价比之王
实验用了 6 个模型、三个规模档：gpt-oss-20b / 120b、gpt-5.4-mini、qwen3.5-9b / 27b / 122b-a10b，全部开启推理模式。每个样本跑 5 个种子。
基线排序在所有模型上一致：j < h < j+h。两个具体例子：gpt-5.4-mini 是 90.7% < 92.7% < 93.0%；qwen3.5-122b 是 81.7% < 86.7% < 90.3%。最强基线 j+h 的完成率跨度是 68.3%–93.0%，模型间差距很大，规模大的整体更好。
这个 j < h 的结果值得停下来看一眼：只看最终产物，不如只看对话历史。这直接证实了基准的设计意图——依赖信息确实藏在对话里，光看 JSON 恢复不出来。而 h 到 j+h 的进一步提升说明，显式给出最终产物能帮模型避免路径写错、修订漏掉。
各方法相对 j+h 的提升幅度（跨模型范围）：
| 方法 | 相对 j+h 的变化 | 点评 |
|---|---|---|
| Select | 涨 3.3 到 12.5 个点 | 最稳，6 个模型中 4 个第一、2 个第二 |
| med | 涨 1.8 到 7.7 个点 | 第二稳，1 个第一、3 个第二 |
| Reflect | +0.5 到 +8.2 个点 | 小幅提升，但很少追上 Select/med |
| or / maj | −0.8 到 +4.8 个点 | 个别模型能打，跨模型不稳 |
| and | 掉 13.2 到 21.3 个点 | 每个模型都大幅掉点 |
and 的崩盘一点不意外：要求全体一致才采纳，等于把"只有一个采样发现的正确联动修改"全扔了。而摘要里的总账是：3 个并行样本 + LLM 选择或 medoid 选择，是最具成本效益的配置，比单次推理涨 2.2 到 9.7 个点。
错误类型分析（6 个模型汇总 3600 个样本）是我觉得全文最有信息量的部分：
- 绝大多数方法的错误里，miss（漏改）占大头——模型倾向于传播得"太少"而不是"太多"。
or反过来，引入大量 over edit（见改就收）。med通过选最典型的候选压掉离群的过度编辑，但找回的 miss 不多。Select的推理倾向于定位最完整的那个候选，所以最大程度减少了 miss——但压不住 over edit。
这个失败画像很实用：如果你的场景对"漏改"敏感（比如金融单据的一致性），Select 是首选；如果对"乱改"敏感，med 更稳。
延迟数据（Table 1，j+h 绝对延迟 + 各方法相对倍数）：
| 模型 | j+h 延迟 | Reflect（k=5） | med（k=5） | Select（k=5） |
|---|---|---|---|---|
| gpt-oss-20b | 15.9 s | 4.56× | 1.49× | 3.08× |
| gpt-oss-120b | 19.3 s | 4.04× | 1.17× | 2.20× |
| gpt-5.4-mini | 7.3 s | 3.52× | 1.39× | 2.41× |
| qwen3.5-9b | 23.3 s | 5.70× | 1.32× | 4.41× |
| qwen3.5-27b | 58.5 s | 5.04× | 1.35× | 5.56× |
| qwen3.5-122b | 41.5 s | 6.02× | 1.47× | 5.51× |
注意 med 那一列：因为并行采样，延迟由最慢的样本决定，采样数加到 5 也始终压在 1.5× 以内。Reflect 则是严格随调用次数线性膨胀。Select 在 Qwen 系列上延迟飙到 4–6×，因为选择那一步生成的推理 token 多——成本上同样如此，Qwen 模型上 Select 的开销是 j+h 的 5.7 到 7.5 倍，而 GPT 系各方法成本基本随调用数成比例。
成本-准确率缩放还有两个发现：一是大多数方法在 4–5 次调用左右性能饱和，继续加钱没意义；二是把其他方法的调用数堆到与 Select 成本相当之后，方法间排序基本不变——Select 的赢不是靠砸钱。按"单位延迟换来的收益"算，med（k=3）是延迟效率最高的方法。
作者的实践建议很直白：默认用 Select 跑 4 次调用；在乎延迟就换 med 跑 3 次调用。
🔬 我的判断
这篇论文最值钱的地方，是把一个大家隐约知道存在、但一直没被量化的能力做成了可测的基准，并且给了一份可以直接抄的工程配置单。六种传播模式的分类（arithmetic / substitution / add_remove / threshold / temporal / status_flip）提炼得相当干净，做编辑类 Agent 的人可以拿这张表直接当测试用例设计 checklist。
但也要泼几盆冷水。
150 个样本，真的不多。 9 领域 × 6 模式 × 3 规模摊下来，每个格子没几个样本，单场景的结论噪声会很大。主结果还是柱状图呈现，正文没有给出 9 方法 × 6 模型的完整数值表，想复现细粒度对比只能去跑代码。
数据是 GPT-5.5 合成的，基准可能对 GPT 系偏容易。 作者自己也承认了这一点，缓解措施是"人类用 Claude-Opus-4.8 设计场景 + 元级指令构造对话"。这个缓解有多大用，我心里是打个问号的。而且 gpt-5.4-mini 已经干到 93% 完成率，基准离饱和不远了——好在作者开源了从采样到标注的全套工具，可以持续加难度。
合成对话 vs 真实对话的差距是硬限制。 为了自动评估可靠，依赖关系被控制成确定性的；但真实场景里"这个元素该不该跟着改"经常是有分歧的，基准完全不覆盖这种模糊情形。completion rate 这种"全对才算对"的指标也把难度拉满了，实际产品里改对 90% 的依赖往往已经够用。
方法层面也要说句实话：Select 和 med 都不是新东西，前者是 self-consistency 的选择版，后者就是 MBR 解码搬到了结构化 patch 上。论文的贡献在标定而不在发明——这在 Industry Track 里是恰如其分的，但别指望读到方法论上的惊喜。
还有一个我想追问但论文没回答的点：Select 用同一个 LLM 既当运动员又当裁判，会不会只是放大了该模型自身的偏好？换一个更强的外部 selector（哪怕是个小模型）效果会怎样？这个消融没做，有点可惜。
💡 收尾
如果你在做文档编辑、配置管理、计划生成这类 Agent 产品，这篇论文的三个结论可以直接落地：对话历史必须喂给模型（j 到 h 的涨幅证明它不可替代）；默认上 3–4 路并行采样加选择，花小钱办大事；在乎延迟就用 medoid 规则选，延迟只多一半不到。那个 miss 占大头的失败画像也值得记住——你的模型大概率不是改错，而是没改够。
更本质的问题还悬着：当依赖关系本身是模糊的、用户自己也说不清哪些该联动时，怎么评？这可能得等人机协作式的评估协议出现了。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我