交互式基准测试：通过预算多轮交互评估模型推理能力 Interactive Benchmarks
通过预算多轮交互评估LLM推理能力的新范式
前置知识
大语言模型评测基准
大语言模型评测基准（LLM Benchmarks）是用于系统性评估模型能力的标准化测试集。传统基准如GSM8K（数学）和MMLU（知识）采用静态问答形式，模型直接对固定输入作答。这类基准的优势在于可复现、可对比，但随着模型能力提升逐渐饱和，且容易受到数据污染影响。新兴的交互式基准则要求模型在多轮交互中主动获取信息并迭代优化答案。
理解传统静态基准的局限性是本文提出交互式评测范式的出发点，也是理解论文核心贡献的基础
不完全信息博弈
不完全信息博弈（Imperfect-Information Game）是指参与者无法完全观察到游戏状态的博弈情境。经典例子是德州扑克，玩家只能看到自己的手牌和公共牌，无法知道对手的手牌。在这类博弈中，玩家需要基于概率推理、对手行为模式分析来做出决策，而非依赖完整信息进行确定性推理。这与围棋等完全信息博弈形成对比。
论文中的德州扑克和信任博弈都是不完全信息博弈，理解这一概念对于理解Interactive Games评测设置至关重要
交互预算
交互预算（Interaction Budget）是对模型与环境之间交互轮次的限制。在本文中，大多数任务设置为20轮交互，每轮模型可以提问或提交答案，每个动作消耗一轮预算。预算限制模拟了现实场景中信息获取的成本约束，迫使模型在有限查询中做出最优决策。这一设计避免了无限查询的计算浪费，也更贴近实际应用场景。
预算机制是论文框架的核心约束条件，决定了模型需要在信息获取效率和答案质量之间权衡
Pass@k 评估
Pass@k 是一种代码生成和数学推理的评估指标，指从k个独立生成的样本中至少有一个正确的概率。传统评估中，给定固定计算预算生成k个完整答案，统计正确率。这种方法的局限在于：早期步骤的错误会导致整个生成作废，且无法利用中间反馈进行修正。论文将其与交互式评估进行对比，展示了交互范式的优势。
论文通过将交互式评估与Pass@k进行公平对比，揭示了交互范式在相同预算下的显著优势
情境谜题（Situation Puzzle）
情境谜题是一种逻辑推理游戏，给出一个看似矛盾或不合常理的简短叙事，玩家需要通过是/否提问来推断隐藏的因果解释。例如：一个男人走进酒吧，要了一杯水，酒保却拿出一把枪指着他，男人说谢谢后离开了，为什么？答案是：男人打嗝了，被枪吓一跳后治好了打嗝。这类谜题的关键特征是表面信息不足，必须通过交互获取额外约束才能解决。
这是论文Interactive Proofs中Logic任务的具体实例，是理解整个评测框架的关键
折扣因子与长期效用
折扣因子 $\gamma \in (0, 1]$ 用于计算长期累积奖励的现值。公式为 $\sum_{t=1}^{T} \gamma^{t-1} r_t$，其中 $r_t$ 是第 $t$ 轮的奖励。当 $\gamma = 1$ 时所有奖励等价重要，$\gamma < 1$ 时未来奖励被折扣，强调即时收益。在博弈论评估中，折扣因子决定了模型需要考虑多远的未来后果，影响策略选择。
这一概念在Interactive Games的数学形式化中出现，是理解博弈评估目标函数的基础
研究动机
现有大语言模型评测范式存在系统性缺陷，无法充分衡量模型的核心智能——主动获取信息并有效利用信息的能力。具体而言，传统静态基准如GSM8K和MMLU采用固定输入-输出的形式，模型直接对预定义问题作答，不涉及信息获取决策。这类基准面临严重的饱和问题：随着模型能力提升和训练数据规模扩大，顶尖模型在这些测试上的得分持续攀升，区分度下降。同时，静态基准极易受到数据污染影响，模型可能在训练中见过测试集，导致分数虚高，无法真实反映推理能力。另一方面，基于偏好的评测如ChatBot Arena虽然能捕捉人类对开放式对话的主观偏好，但其依赖主观判断的特性使其不适合可靠评估推理能力。更关键的是，这两类评测范式都忽略了一个核心维度：模型决定获取什么信息以及如何有效利用这些信息的能力。在大多数现有基准中，模型要么响应固定输入，要么在预定义信息通道的任务特定环境中行动，几乎没有空间让模型决定要寻求什么证据。这与经典智能理论相矛盾——强化学习将从交互中学习视为基础，主动感知理论主张完整的人工智能体必须主动控制其感知内容。
本文的目标是本文的具体目标是提出并验证一个统一的交互式评测框架——Interactive Benchmarks，通过预算多轮交互过程来评估模型的推理能力。这个框架需要满足以下设计目标：首先，它必须能够在统一的数学形式化下覆盖不同类型的交互场景，包括收敛性证明任务和发散性博弈任务；其次，评测结果必须客观可复现，避免主观判断的干扰；第三，它需要揭示现有静态基准无法捕捉的模型能力维度——信息获取效率和交互策略优化能力。具体来说，论文在两个子框架下展开评测：Interactive Proofs用于评估模型在有客观验证器的任务中的逻辑、编码和数学推理能力，涵盖情境谜题、UI2Html和数学问题三个测试床；Interactive Games用于评估模型在不完全信息博弈中的策略推理能力，涵盖德州扑克和信任博弈两个测试床。通过这五个具体测试床的实验，论文旨在证明交互式评测能够提供更鲁棒的模型智能评估，同时揭示当前模型在交互场景中仍有巨大改进空间。
与已有工作不同的是，本文的独特切入角度在于将交互形式化为一个有理论支撑的统一评测范式，而非仅仅设计需要交互的任务。与现有交互式评测工作相比，本文有三个本质区别：第一，理论形式化——论文将每个评测实例建模为模型 $\pi$ 与环境 $E$ 之间持续 $T$ 轮的交互过程，在每轮 $t$ 中模型观察历史 $h_t$ 并选择动作 $a_t$，环境返回观察 $o_{t+1}$。这种形式化支持对交互式证明和交互式博弈的统一分析，前者的目标是 $\max_\pi \mathbb{E}[\mathbf{1}\{\hat{y} = y^*\}]$（在预算约束 $\sum c(a_t) \leq B$ 下最大化正确答案概率），后者的目标是 $\max_\pi \mathbb{E}[\sum \gamma^{t-1} r_t]$（最大化长期折扣效用）。第二，预算约束下的公平比较——论文不仅比较不同模型在交互设置下的表现，还首次实现了交互式评估与Pass@k评估在相同推理预算下的公平对比，通过匹配玩家侧token消耗量来确保比较的公正性。第三，跨任务泛化——现有交互式评测通常针对单一任务设计（如TurtleBench的海龟汤谜题、Entity-deduction Arena的20问游戏），而本文的框架理论上可以推广到任何有验证器或环境反馈的交互场景，提供了从逻辑推理到策略博弈的统一评估视角。
核心方法
Interactive Benchmarks框架的核心思路是：将智能评估从「给定输入预测输出」转变为「在有限预算内通过交互获取信息并做出决策」。直觉上，真正的智能不仅体现在能够回答已知问题，更体现在面对不确定性时能够提出正确的问题、从反馈中学习、并高效收敛到正确答案。技术路线分为两条：对于有客观正确答案的任务（Interactive Proofs），模型与一个持有真实答案的裁判交互，通过提问和验证来逐步缩小解空间，最终在预算耗尽前提交正确答案；对于博弈任务（Interactive Games），模型与环境中的其他智能体交互，通过策略推理来最大化长期累积收益。两条路线共享同一数学框架：在每轮 $t$，模型观察交互历史 $h_t = (o_1, a_1, o_2, a_2, \ldots, o_t)$，选择动作 $a_t \sim \pi(\cdot | h_t)$，环境返回下一观察 $o_{t+1}$。这种统一形式化使得不同任务的评测结果可以在相同框架下分析和比较。论文在这两个子框架下共设计了五个具体测试床：情境谜题（逻辑推理）、UI2Html（编码能力）、数学问题（数学推理）、德州扑克（不完全信息策略博弈）、信任博弈（合作与背叛决策）。
本文的核心创新点在于将「主动信息获取」确立为智能评测的核心维度，并提出了一个可操作的评测范式。与已有方法的本质区别体现在三个层面：首先，在评测哲学层面，传统基准假设智能可以通过静态回答来测量，而本文认为智能的关键在于「决定获取什么信息以及如何有效利用」——这与强化学习的「从交互中学习」和主动感知的「主动控制感知内容」理论一致。其次，在评测机制层面，现有交互式评测（如TurtleBench）虽然也需要交互，但未提供统一的理论形式化来支持跨任务的公平比较。本文通过统一的马尔可夫决策过程形式化，使得不同任务的评测结果可以放在同一数学框架下分析。第三，在公平比较层面，论文首次实现了交互式评估与Pass@k评估在相同推理预算下的公平对比。具体方法是通过公式 $k^* = \arg\min_k |k \cdot \mathbb{E}[T_{\text{pass}}^{(1)}] - \mathbb{E}[T_{\text{interactive}}]|$ 匹配玩家侧token消耗，确保交互式评估使用 $N$ 轮交互的总token量与Pass@k生成 $k$ 个完整解的总token量大致相等。这一设计首次量化了交互式评估相对于静态评估的效率优势。
方法步骤详情
Interactive Benchmarks的完整方法包含以下步骤：第一步，任务设计与数据集构建。针对每个测试床，专家构建评测数据集并定义交互协议。情境谜题数据集包含46个高质量谜题，通过「交互必要性」（表面叙事不足解决）和「歧义消解」（隐藏解释足够确定）两个标准筛选。UI2Html从UI2Code-Real中选取50个截图，由前端专家重新标注。数学问题从HLE数据集中选取52个专家筛选的高难度实例。第二步，交互协议定义。每个任务定义固定的交互预算（通常20轮）、允许的动作类型（提问/提交答案）、反馈类型（是/否/两者/无关）和评分标准。以情境谜题为例，玩家每轮可提问中间问题或提交候选答案，中间问题获得 {yes, no, both, irrelevant} 四种反馈之一，最终答案获得 correct/incorrect 反馈。第三步，模型评测。在Interactive Proofs中，固定裁判模型（如Grok-4.1-fast用于逻辑和数学任务，qwen-vl-max用于UI2Html任务），所有玩家模型使用相同温度（temperature 0）进行评测。在Interactive Games中，所有模型在同一环境中进行对战。第四步，多维度指标收集。收集正确率、平均轮次（仅计算成功实例）、token消耗量、行为统计（如扑克中的VPIP率、弃牌率；信任博弈中的合作率和背叛率）等多维度指标。第五步，与Pass@k的公平对比。通过token预算匹配确定等价的 $k^*$ 值，对比交互式评估和Pass@k评估在相同推理预算下的表现差异。
技术新颖性
本文的技术新颖性体现在以下几个方面：第一，统一的数学形式化。论文将看似不同的评测任务（逻辑证明、代码生成、数学推理、扑克博弈、合作博弈）统一到同一个交互过程框架 $h_t = (o_1, a_1, \ldots, o_t)$, $a_t \sim \pi(\cdot | h_t)$ 中。这种形式化不仅提供了理论上的优雅性，更支持对不同任务的评测结果进行统一分析——例如，可以比较模型在逻辑任务中的「信息获取效率」和在博弈任务中的「策略适应能力」。第二，公平预算匹配机制。论文设计的公式 $k^* = \arg\min_k |k \cdot \mathbb{E}[T_{\text{pass}}^{(1)}] - \mathbb{E}[T_{\text{interactive}}]|$ 首次实现了交互式和静态评估的公平比较。这解决了一个长期存在的方法论问题：之前的研究声称交互式评估更好，但缺乏在相同计算成本下的严格比较。第三，UI2Html评测设计。将网页构建任务设计为需要通过二进制视觉反馈迭代改进的交互过程，这不仅测试编码能力，更测试从稀疏反馈中推断用户隐含需求的能力——这是真实编程辅助场景中的关键技能。第四，跨博弈类型的统一评估。在同一论文中同时覆盖收敛性任务（有唯一正确答案）和发散性任务（博弈中无绝对最优），展示了框架的通用性。
实验结果
论文在五个测试床上对六个前沿模型（Grok-4.1-fast、Gemini-3-flash、GPT-5-mini、Kimi-k2、DeepSeek-v3.2、Qwen3-max）进行了全面评测，获得了以下核心发现：在情境谜题（逻辑推理）上，所有模型在无交互设置下正确率均为0%，证明该数据集不存在直接回答的捷径，必须通过交互获取信息。在有交互设置下，Gemini-3-flash以30.4%的正确率领先，GPT-5-mini为17.4%，Qwen3-max仅4.3%。从效率看，Kimi-k2平均需要12.3轮解决（仅计算成功实例），DeepSeek-v3.2则需要18.0轮。在UI2Html（编码推理）上，所有模型在交互设置下得分均高于单轮基线，证明交互对代码生成有普遍帮助。GPT-5-mini以57.62分领先，Grok-4.1-fast从53.19提升至57.12（提升最大），Kimi-k2从48.88仅提升至49.03（提升最小）。在数学推理上，交互式评估的优势最为显著。Grok-4.1-fast达到76.9%准确率，GPT-5-mini为73.1%。与Pass@k在相同token预算下对比，Pass@k的准确率比交互式评估低约20%-50%。这量化了交互式评估的效率优势：通过早期验证中间步骤、修剪错误分支，模型可以在相同计算成本下获得显著更高的正确率。从效率看，Qwen3-max平均仅需5.2轮，但准确率只有46.2%，说明它只能高效解决部分问题。在德州扑克上，Gemini-3-flash以每手平均盈利31.8筹码领先，Grok-4.1-fast为27.9，GPT-5-mini为22.2。GPT-5-mini是参与度最高的玩家（VPIP 23.7%，弃牌率71.4%），而DeepSeek-v3.2是最紧的玩家（VPIP 9.0%，弃牌率90.5%）。在信任博弈上，Qwen3-max以1.867的每轮平均收益领先，且仅Qwen3-max（1.867）和GPT-5-mini（1.836）超越了Grim Trigger（1.811）和Tit-for-Tat（1.782）两个启发式基线，表明大多数模型在自适应博弈策略上仍有很大改进空间。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 情境谜题（逻辑推理） | 准确率（20轮预算内解决率） | Gemini-3-flash: 30.4%, GPT-5-mini: 17.4%, Grok-4.1-fast: 15.2% | 所有模型在无交互设置下均为0% | 交互设置相比无交互提升了15-30个百分点，证明了交互对逻辑推理的必要性 |
| UI2Html（编码推理） | 综合得分（布局+组件+样式+文本+精细度） | GPT-5-mini: 57.62, Grok-4.1-fast: 57.12, Gemini-3-flash: 55.46 | 单轮基线：GPT-5-mini 54.57, Grok-4.1-fast 53.19 | Grok-4.1-fast提升最大（+3.93），所有模型在交互设置下均有提升 |
| 数学推理 | 准确率（20轮预算） | Grok-4.1-fast: 76.9%, GPT-5-mini: 73.1%, Gemini-3-flash: 61.5% | Pass@k在相同token预算下：Grok约50%, Gemini约35% | 交互式评估比Pass@k高约20-50%，交互效率优势显著 |
| 德州扑克 | 每手平均盈利（筹码） | Gemini-3-flash: 31.8, Grok-4.1-fast: 27.9, GPT-5-mini: 22.2 | Kimi-k2: -23.2, DeepSeek-v3.2: -28.3, Qwen3-max: -30.4 | 前三个模型实现正收益，后三个模型亏损，显示明显的策略能力差异 |
| 信任博弈 | 每轮平均收益 | Qwen3-max: 1.867, GPT-5-mini: 1.836 | Grim Trigger: 1.811, Tit-for-Tat: 1.782 | 仅Qwen3-max和GPT-5-mini超越两个启发式基线 |
局限与改进
论文存在以下局限性：首先，评测规模有限——情境谜题仅46个实例，UI2Html仅50个截图，数学问题仅52个实例，这些较小的数据集可能导致统计显著性不足，评测结果的置信区间较宽。其次，裁判模型的选择可能引入偏差——论文固定使用Grok-4.1-fast作为逻辑和数学任务的裁判，qwen-vl-max作为UI2Html的裁判，但未充分讨论裁判模型自身能力上限对评测结果的影响。虽然附录中提供了裁判消融实验，但主要结果仍依赖单一裁判。第三，交互协议设计的任意性——20轮的预算限制、是/否问题的格式约束、UI2Html中问题模板的设计，这些选择可能偏向某些模型的交互风格，而非反映通用能力。第四，公平比较的token计数方法——论文在Pass@k对比中仅计算玩家侧token，不包括裁判侧token，但交互式评估的实际成本应该包括双方的计算开销。第五，缺乏对模型失败模式的深入分析——论文报告了总体指标，但未系统分析模型在何种类型的谜题上失败、在何种博弈情境下策略失误。第六，德州扑克的评测可能受发牌随机性影响较大——5000手的规模在扑克统计中仍属有限，结果的方差较大（如Grok-4.1-fast的标准差为53.5，远高于均值27.9）。
独立分析的弱点
论文存在以下弱点，每个弱点都指向具体的改进方向：第一，评测数据集规模过小。情境谜题46个、UI2Html 50个、数学问题52个实例难以支撑统计上的强结论，特别是当模型间差异仅为几个百分点时。改进方向包括：建立更大规模的标准化数据集，采用分层抽样确保不同难度梯度的覆盖，以及引入置信区间和统计显著性检验。第二，裁判模型单一且与评测目标不完全解耦。当使用Grok-4.1-fast作为裁判评测Grok-4.1-fast自身时，存在自我评测的偏差风险。改进方向是：使用多个独立裁判模型进行交叉验证，或者开发专用的规则化裁判系统（如程序化的数学证明验证器）。第三，UI2Html评测中视觉反馈的粒度有限。当前方案使用二进制的yes/no反馈来比较渲染截图与目标，这种粗粒度反馈可能无法引导模型进行精细的代码修改。改进方向包括：提供更细粒度的视觉差异反馈（如高亮不同区域的热力图），或者提供结构化的反馈（如「布局匹配但颜色不对」）。第四，缺乏对模型交互策略的可解释性分析。论文报告了整体指标，但未深入分析模型是如何分配查询预算、何时决定提交答案、失败时的错误模式是什么。改进方向包括：可视化模型的查询-反馈序列、分析提交时机与正确率的关系、建立交互策略的分类学。第五，德州扑克评测中对手池固定。所有模型与相同的六个模型对战，这限制了结果的泛化性。改进方向包括：引入更多样化的对手池（包括传统算法玩家），或者采用ELO评分系统来支持跨不同对战组合的结果比较。
未来方向
论文在结论中提出计划扩展基准的任务覆盖面，并研究能够优化模型交互性能的训练方法。基于论文成果，可延伸的未来研究方向包括：第一，动态交互预算分配。当前每个任务使用固定的20轮预算，但现实中不同类型的任务可能需要不同的交互深度。未来可以研究自适应预算分配策略，让模型或系统根据任务难度和已获取信息动态调整剩余预算。第二，多模态交互评测。当前UI2Html已经是视觉-代码交互，但可以扩展到更多模态，如语音交互（需要理解口语中的模糊性）、视频理解（需要时间序列上的信息获取）、机器人控制（需要物理环境中的主动探索）。第三，交互式训练方法。论文证明了交互式评估的价值，下一步可以研究如何在训练阶段就优化模型的交互能力，例如通过强化学习让模型学会何时提问、何时提交、如何从反馈中高效学习。第四，跨语言和跨文化评测。情境谜题具有文化特异性，可以构建多语言版本来评测模型在不同文化背景下的交互推理能力。第五，真实用户研究。当前使用的是合成的裁判反馈，未来可以引入真实人类用户作为裁判，研究模型与人类交互时的信息获取策略是否与机器裁判一致。第六，对抗性评测。研究模型在面对恶意裁判（提供误导性反馈）或不合作环境时的鲁棒性，这更贴近真实世界中的信息获取挑战。
复现评估
论文的复现评估如下：开源情况方面，论文提供了项目页面（https://github.com/interactivebench/interactivebench），但未明确说明是否开源了完整的评测代码、数据集和评测脚本。数据方面，情境谜题数据集标注为46个高质量、由推理和谜题协会附属专家策划的实例，UI2Html基于UI2Code-Real数据集构建，数学问题来自HLE数据集，但论文未提供这些数据集的公开下载链接或详细构建流程。算力方面，论文使用了六个商业模型的API（Grok-4.1-fast、Gemini-3-flash、GPT-5-mini、Kimi-k2、DeepSeek-v3.2、Qwen3-max），这意味着复现需要访问这些API且产生相应的调用成本。每个模型在每个实例上最多进行20轮交互，加上裁判模型的调用，总API成本可能相当可观。难度方面，交互式评测框架本身不难理解，但完整复现需要：实现五个测试床的交互环境（包括情境谜题裁判、UI2Html渲染器和评分器、数学证明验证器、扑克引擎、信任博弈环境），配置六个模型的API调用，并处理各种格式验证和错误重试逻辑。论文的数学形式化清晰，关键公式完整，有助于理解评测机制。总体而言，复现难度中等偏高，主要瓶颈在于API访问和五个独立交互环境的实现。
论文图表
