LLM 能否在起草-验证-修订流程中解决指示语歧义？

arXiv:2609.12162v1 公告类型：新发布 摘要：草稿-验证-修订（draft-verify-revise）是一种常见的 LLM 编排模式，用于扩展推理时计算（inference-time compute）。一个 LLM 负责起草，第二个对草稿进行评审并给出反馈，第三个再利用这些反馈将草稿修订为最终输出。随着上下文在各级联阶段之间传递，不同阶段的 LLM 可能会对"previous"这类依赖上下文的表达产生不同的理解。一旦发生这种情况，该表达就会发生指示语转换（deictic shift），即其所指对象发生改变。本研究使用了一个合成数据集来考察这一现象，其中包含 10 个基础示例，每个示例在三种条件下分别呈现。在保持共享组件不变的前提下，这些条件改变了：草稿阶段的 LLM（即 assistant）与验证阶段的 LLM（即 grader）中哪一个能正确理解该表达，以及修订阶段的 LLM（即 meta-evaluator）需要多少独立推理才能判断哪种理解是正确的。研究选取了来自三家提供商的六款模型，在 21 种推理强度配置下进行了测试，采用 e-values 进行序贯检验；实验包括一个主实验和一个消融实验，后者移除了 grader 反馈中的错误分类标签。另有独立的 LLM 对 meta-evaluator 在每次错误判定中所陈述的理由进行了分析。平衡准确率（即灵敏度与特异度的非加权平均值）介于 0.156（低于随机水平）到接近完美之间。GPT-5.2 在不做推理时为 0.156，在其最高推理强度下升至 0.942；而 Gemini 3 Pro 在所有强度水平下均保持在 0.94 以上。Gemini 3 Pro 在低推理强度下的表现优于 GPT-5.2 在 xhigh 推理强度下的表现，而每次试验的成本仅约为后者的 5%。当 meta-evaluator 出错时，它往往依赖表面线索而非操作性推理。在实现 draft-verify-revise 流水线时，上下文工程师（context engineers）应警惕指示语转换，并在每个阶段明确其所指对象。