Source-linked AI summary
Interactive Evaluation Requires a Design Science
Keyang Xuan, Peiyang Song, Pan Lu, Pengrui Han, Wenkai Li, Zhenyu Zhang, Zexue He, Wenyue Hua, Manling Li, Jiaxuan You, Adrian Weller, Yizhong Wang, Jiaxin Pei
TL;DR
Interactive evaluation is fragmented because systems acting through trajectories require evidence and judgments beyond response-centered benchmarks. This position paper defines interactive evaluation as a trajectory-based design science, proposes a two-axis taxonomy and design principles, and finds that current benchmarks often record trajectories while still judging mainly final task success.
Problem
Response-centered evaluation is insufficient for systems acting over time because evidence needed for judgment is generated through interaction trajectories.
Method
The paper defines evaluation as mapping admissible evidence to judgments, then proposes a two-axis taxonomy organized by evaluation inputs and evaluation programs.
Results
Current interactive evaluations concentrate on Task Success while comparatively underdeveloping Recoverability and Robustness, often treating trajectories as evidence for final outcomes.
Takeaways & Limitations
Interactive evaluation should be designed as trajectory-based, system-level evaluation with explicit protocols and richer measures to support comparison, reproducibility, and extension.
Takeaways & Limitations
Interactive benchmarks remain vulnerable to policy gaming through simulator quirks, predictable user models, evaluator heuristics, and shortcuts satisfying scorers without intended competence.
Abstract
from arXiv · showhide
AI evaluation is undergoing a structural change. Large language models (LLMs) are increasingly deployed as systems that act over time through tools, environments, users, and other agents, while many evaluation practices still inherit assumptions from response-centered benchmarks (e.g., fixed inputs, isolated outputs, and outcome judgments that can be made from a single response). The field has begun to build interactive benchmarks, but the resulting landscape is fragmented: benchmarks differ in what interaction artifacts they admit, how trajectories are scored, and what claims their results support. This position paper argues that interactive evaluation should be treated as a principled evaluation paradigm, not merely a new family of agent benchmarks. Simply adopting previous evaluation paradigms does not suffice. We define evaluation as an autonomous mapping from evidence to judgments, and show that interactive evaluation changes both sides of this mapping: the evidence becomes interaction-generated trajectories, while the evaluation procedure must assess process, recoverability, coordination, robustness, and system-level performance. Building on this definition, we propose a two-axis taxonomy, derive design principles and reporting standards, examine representative scenarios, and analyze how longstanding evaluation challenges reappear at the trajectory level.
1 Introduction
Interactive evaluation should be developed as a design science because systems increasingly act through trajectories, while existing evaluations vary in evidence, environments, scoring procedures, and supported claims. The paper defines this paradigm, proposes a two-axis taxonomy, and derives design principles for interpretable, comparable, scientifically useful evaluation.
- Introduction: Interactive evaluation expands beyond fixed-instance judgments of standalone outputs toward executable, grounded settings that assess behavior unfolding through interaction.This transition reflects changing expectations for large language models and motivates trajectory-level evaluation.
- Introduction: Existing interactive evaluations differ in recorded artifacts, substrates, environments, action-dependent state transitions, and procedures for converting trajectories into scores.They span long-horizon grounded tasks, tool-user interaction, process-level reward modeling, and social interaction.
- Introduction: Interactive evaluation should specify which interaction artifacts constitute evidence and how an evaluation program maps that evidence to judgments.The paper formalizes evaluation as an autonomous program E : X →Y, with interactive evaluation expanding X from final responses to interaction-generated trajectories.
- Introduction: The paper proposes a two-axis taxonomy organized around evaluation inputs and evaluation programs to make current and future benchmarks comparable across task domains.It also derives principles and a roadmap for benchmark design.
- Introduction: Trajectory-level evaluation must address how classic problems—including overfitting, gaming, leakage, brittleness, and reproducibility—reappear in interactive settings.The broader goal is to support claims that are interpretable, comparable, and scientifically useful rather than merely evaluate harder tasks.
2 Rethinking Evaluation Beyond Response-centered Evaluation
Response-centered evaluation remains valuable for scalable, comparable, and repeatable input-output assessment, but it becomes insufficient when systems act over time and interaction changes the evidence and meaning of success. Interactive evaluation therefore judges trajectories, including how actions affect state, errors are recovered, and coordination is achieved.
- Why the Old Assumptions Worked: Response-centered evaluation enabled scalable model comparison through fixed datasets, standardized instances, legible scoring, comparability, aggregation, and repeatability.These strengths remain essential, and interactive evaluation should supplement rather than discard the response-centered paradigm where interaction is constitutive of capability.
- Why Interaction Breaks the Fit: When systems act over time, evidence is generated through trajectories because actions can alter opportunities, persistent state, user responses, other agents’ behavior, and error recoverability.The initial prompt or final answer may not contain the evidence needed for judgment.
- Why Interaction Itself Must Be Evaluated: Process must be evaluated when interaction changes the meaning of success, because outcome-only measurement cannot distinguish robust, transparent competence from brittle patches or confusing coordination.The passage contrasts coding agents that isolate faults, preserve interfaces, and recover from failing tests with brittle, unreviewable patches, and social agents that coordinate transparently with those that confuse counterparts.
- A Minimal Notion of Interaction: Interactive evaluation concerns consequential external loops in which tools, environments, users, or other agents affect what the system encounters next and that dependence matters for evaluation.Multiple turns alone are insufficient when later prompts are fixed in advance.
3 Definition and Scope of Interactive Evaluation
Interactive evaluation treats evaluation as an autonomous mapping from admissible evidence to evaluative judgments, with evidence consisting of consequential interaction trajectories and outputs concerning system-level performance. This changes both what artifacts must preserve and which trajectory properties evaluators must assess, while excluding interaction that does not affect later conditions or evaluation state.
- Definition: Evaluation maps an accepted domain of evidence X to evaluative outputs Y through a procedure E that supports scalable judgments.Outputs may include scores, rankings, pass/fail decisions, diagnostic reports, or qualitative judgments.
- Definition: Interactive evaluation admits consequential interaction trajectories as evidence and maps them to judgments about system-level performance.This is the paper’s definition of interactive evaluation.
- What Changes in X: A trajectory can include observations, actions, tool calls, state transitions, responses, intermediate artifacts, costs, constraints, and final outcomes.The recorded artifact must preserve the action-dependent structure needed to judge performance, regardless of whether it comes from a web environment or operating system.
- What Changes in E: Interactive evaluators assess trajectory properties such as completion, progress, constraint satisfaction, efficient exploration, safe tool use, recoverability, cooperation, communication quality, and resilience.The evaluator therefore is not merely an answer checker.
- Boundary Cases: Multiple turns do not qualify when the sequence is predetermined and earlier behavior does not affect later conditions, and tool calls do not qualify when they only provide hidden computation.These are boundary cases defining the scope of interactive evaluation.
4 Taxonomy of Interactive Evaluation
Interactive evaluation is organized by two axes: the interaction-generated artifacts admitted as evidence and the program that maps trajectories to judgments. The taxonomy shows that current benchmarks remain outcome-centered and substrate-bound, with sparse coverage of hybrid dynamics and underused human validation.
- Two-Axis Taxonomy: Interactive evaluations differ by the artifacts admitted as evidence and by how the evaluation mapping converts those artifacts into judgments.The taxonomy treats a benchmark as a point or region in this two-dimensional design space.
- Interaction Artifacts: The first axis distinguishes trajectories connecting systems to tools and environments, users, other agents, or hybrid dynamic systems.Hybrid and dynamic systems combine tools, users, agents, memory, and changing environments, but remain comparatively underexplored.
- Judgment Programs: The second axis includes Task Success, Process Quality and Efficiency, Recoverability and Robustness, and Safety, Alignment, and Social Competence.These programs assess final states, intermediate behavior, error response under changing conditions, and norm-sensitive interaction.
- Landscape Observations: Current interactive evaluation remains concentrated around Task Success, leaving Recoverability and Robustness comparatively sparse despite admitting trajectories as evidence.Trajectory recording has expanded faster than trajectory-level judgment.
- Landscape Observations: Evaluation programs remain substrate-bound: tools and environments emphasize Task Success or Process Efficiency, other agents emphasize Safety, Alignment, and Social Competence, and hybrid systems remain sparse.This pattern suggests that programs often follow what is easiest or most natural to measure in each substrate.
- Landscape Observations: Hybrid and Dynamic Systems have the sparsest evaluation coverage, concentrated around Task Success and Process Quality and Efficiency while recoverability, safety, alignment, and social competence remain underdeveloped.The gap becomes more consequential as systems face complex end-to-end tasks requiring hybrid and dynamic interaction evidence.
- Implementation Limitations: Human-in-the-loop validation is often needed for claims involving user intent, social appropriateness, or domains requiring expertise, because scalable scores can miss contextual user-facing failures.Final success scores, automated checks, and LLM-as-a-judge pipelines may appear reliable without capturing these failures.
5 Principles and Roadmap for Interactive Evaluation
Interactive evaluation requires benchmarks to make systems, trajectory evidence, interaction protocols, judged dimensions, and supported claims explicit. The roadmap combines perturbation-aware assessment, separate outcome/process/risk reporting, and shared infrastructure that preserves diversity in domains and protocols.
- Specify the System and Trajectory Evidence: Benchmarks must specify the evaluated system, accessible resources, recorded trajectory evidence, and claims those traces support.Model identity alone is insufficient because wrappers, memory, retrieval, sandboxes, simulators, and orchestration policies can affect performance.
- Specify the Interaction Protocol: Interaction protocols should state initial states, allowed actions, observations, counterpart behavior, stopping rules, randomness, persistence, and reset conditions.These conditions determine the opportunities and constraints systems face and whether trajectories are meaningfully comparable.
- Design for Perturbation and Repair: Future benchmarks should test whether systems remain effective under ambiguity, misleading feedback, partial failure, state drift, and counterpart adaptation.These perturbations are presented as central to interactive evaluation rather than adversarial add-ons.
- Build Shared Infrastructure without Freezing the Design Space: The roadmap calls for reusable environments, logging schemas, trajectory viewers, evaluation harnesses, and reporting templates while preserving diversity in domains and protocols.It moves from response-centered benchmarks through executable and tool-augmented tasks toward suites treating protocol, state, and measurement logic as first-class objects.
6 Broad Risks and Open Issues in Interactive Evaluation
Interactive evaluation introduces risks that arise from its growing capability, standardization, and consequential role as shared scientific infrastructure. Key concerns include policy gaming, sensitivity to distribution and interface shifts, premature standardization, simulator artifacts, and dependence on evaluators or counterparts.
- Overfitting, Leakage, and Gaming: Interactive benchmarks can be policy-gamed through leakage from environment state, task templates, tool APIs, simulator regularities, user models, or evaluator heuristics.The resulting failure is not only answer exposure but systems learning how to be evaluated.
- Distribution Shift and Benchmark Brittleness: Small changes in interface, timing, initial state, tool behavior, or counterpart response can alter trajectories, making distribution shift and benchmark brittleness more acute.Benchmarks should distinguish harmful brittleness from deployment-relevant sensitivity to shifting states, imperfect instructions, and changing counterparts.
- Standardization–Diversity Tradeoff: Shared logging, reporting, and replay infrastructure support comparability, reproducibility, and auditability, but premature convergence on narrow protocols or environments can reduce interaction diversity.Interactive evaluation must develop shared infrastructure without collapsing into a single narrow format.
- Fidelity, Control, and Simulator Artifacts: High-fidelity environments provide richer situated evidence but are expensive, noisy, and difficult to control, whereas simulators improve repeatability but may reward simulator-exploiting strategies.There is no universal optimum between realism and control.
- Evaluator and Counterpart Dependence: Evaluator and counterpart standardization can make scores reward adaptation to particular policies rather than intended capability, so conclusions should be tested across plausible variants.Systems may perform well under one judge, simulator, or expert group yet fail under alternatives, creating a construct-validity risk.
7 Scope and Implications of the Position
Interactive evaluation is not required for every benchmark or agent, and it need not always use expensive, high-fidelity simulation. Its use should depend on the claims being made and on whether behavior unfolds through consequential interaction.
- Scope and implications: Interactive evaluation is not universally required, and it does not always require expensive, high-fidelity simulation.The position addresses concerns about cost, protocol dependence, reproducibility, simulator artifacts, and trajectory-level gaming.
- Interactive Evaluation Is Not Just Agent Evaluation: Agent benchmarks may remain response-centered when actions do not affect later conditions or only the final output is judged.Conversely, systems not described as autonomous agents may still require interactive evaluation when behavior unfolds through tools, web environments, users, or other external loops.
- Trajectory-Level Evaluation Is Claim-dependent: Trajectory-level evaluation should be claim-dependent: task success remains indispensable for claims about final completion, but trajectories require richer assessment for process-oriented claims.The passage identifies process quality, recoverability, safety, efficiency, and coordination as examples of claims that cannot be reduced to a final success label.
8 Conclusion · Appendix
Interactive evaluation must be deliberately designed as a systematic, unified framework rather than merely adopted. The paper frames it as trajectory-based, system-level evaluation under action-dependent conditions, supporting comparison, reproducibility, and extension.
- 8 Conclusion: Interactive evaluation must be designed rather than merely adopted.The paper presents this as its central conclusion.
- 8 Conclusion: Increasingly consequential interactions make a systematic framework for interactive evaluation necessary.The conclusion links this need to how AI systems increasingly act.
- 8 Conclusion: The framework should be unified across interactive evaluations.Unification is identified as a requirement for the field’s evaluation design.
- 8 Conclusion: Interactive evaluations should support comparison, reproducibility, and extension.These are the three explicit purposes named in the conclusion.
- 8 Conclusion: Interactive evaluation is framed as trajectory-based evaluation.The conclusion characterizes the evaluation object through trajectories.
- 8 Conclusion: Interactive evaluation is system-level evaluation under action-dependent conditions.The framing emphasizes both the system level and dependence on actions.
- 8 Conclusion: The framework is organized around what interaction artifacts enter evaluation.This is one of the two organizing questions stated in the conclusion.
A More Alternative Views … C.1 Roadmap Categories.
The paper distinguishes interactive evaluation by its trajectory-based evidence and system-level judgments, while treating response-centered and related benchmark extensions as complementary, claim-dependent alternatives. It argues that interactive evaluation should expose process, risk, recovery, and system-scaffold assumptions through observable, separately reported properties rather than opaque or stylistic scores.
- A More Alternative Views: Interactive evaluation is defined by consequential interaction trajectories as admissible evidence and by mapping those trajectories to system-level performance judgments.Difficulty, freshness, realism, executability, and multi-step structure alone do not establish the boundary.
- A More Alternative Views: Live, executable, tool-use, and holistic benchmarks can remain response-centered when they refresh instances, verify final artifacts, or cover capabilities without making action-dependent trajectories part of judgment.Tool use becomes relevant only when tool results change subsequent observations and the trajectory matters to evaluation.
- A More Alternative Views: Interactive evaluation should be used when the capability claim requires interaction as evidence; otherwise, response-centered evaluation may be cheaper, cleaner, and easier to reproduce.The paper does not argue that all evaluations should become interactive or that response-centered benchmarks should be discarded.
- A More Alternative Views: Trajectory-level evaluation can increase evidential efficiency by supporting judgments about recovery, constraint satisfaction, action economy, unsafe operations, and robustness from the same evaluation run.The design challenge is to add trajectory-level judgments only when they provide additional validity relative to their cost.
- A More Alternative Views: Interactive evaluations should report outcome, process, and risk dimensions separately and ground process measures in externally checkable trajectory properties rather than collapsing them into one opaque score.The paper identifies state changes, action counts, constraint violations, failed tool calls, recovery, rollback behavior, unsafe operations, and communication failures as examples.
- A More Alternative Views: To resist performative behavior, trajectory evaluation should reward capability-relevant observable outcomes, testing recovery through induced failures and measuring efficiency and safety through actions, costs, and violations.Verbose plans, artificial self-corrections, judge-pleasing rationales, and safety-themed language are insufficient evidence.
- A More Alternative Views: Interactive evaluation often assesses assembled systems rather than isolated models, so reports must distinguish model-level from system-level claims and document the surrounding scaffold.Relevant scaffold elements include tools, memory, retrieval, planners, sandboxes, permissions, interfaces, orchestration, and prompting strategies.
- C.1 Roadmap Categories.: The roadmap categories separate response-centered evaluation, task-driven extensions organized around fixed outcomes, and interactive evaluation centered on consequential trajectory evidence.The supplied roadmap passage introduces these three categories for examining the temporal pattern behind Figure 1.
C.2 Benchmark Collection.
The benchmark collection expands representative benchmarks through citation-based and early-year retrieval, then deduplicates and quality-filters candidates before LLM-based classification. Classification is validated against manually curated anchors and used descriptively to identify broad temporal trends.
- Retrieval: The collection expands representative benchmarks through citation-based snowball sampling and a second retrieval channel intended to recover early-year work.Citing papers are retained when titles match benchmark-related keywords such as “bench,” “arena,” and “gym.”
- Filtering: Papers are deduplicated across retrieval channels using arXiv IDs when available and normalized titles otherwise, then passed through a shared quality filter.A paper is retained if it appears in a top venue, has citation velocity at least 1.5, or has at least 50 GitHub stars.
- Classification: An LLM-based classifier assigns candidates to three roadmap categories or Not Relevant, with only roadmap-category assignments included in trend analysis.Classification uses each paper’s title and abstract and focuses on the primary contribution rather than merely evaluating a new model on existing benchmarks.
- Validation and scope: The classifier is applied to the expanded corpus only after achieving over 90% agreement with manual labels, while ambiguous Interactive Evaluation cases require explicit trajectory, stateful-interaction, or feedback-loop emphasis.The resulting analysis is treated as descriptive evidence for broad temporal trends rather than an exhaustive census.
C.3 Industry-Academic Comparison. … D.2 Multi-Agent Social Systems.
The paper presents descriptive evidence that task-driven and interactive evaluation is unevenly distributed across industry and academia, then illustrates how trajectory-based evaluation applies to coding agents and multi-agent social systems. These scenarios require evidence and evaluation programs that capture process, adaptation, coordination, robustness, and system-level claims beyond isolated outputs.
- C.3 Industry-Academic Comparison.: Industry and academic evaluation-stage compositions differed significantly, with a Pearson χ2 test of χ2(2) = 7.09, p = 0.029.The comparison covers 43 industry benchmark families from recent public reports by OpenAI, Anthropic, Google DeepMind, and Alibaba/Qwen, alongside academic benchmark papers from 2024–2026.
- C.3 Industry-Academic Comparison.: The comparison is descriptive evidence that transition toward task-driven and interactive evaluation is uneven across the evaluation ecosystem, not an exhaustive census.The paper explicitly limits the interpretation of the industry–academic comparison.
- D Illustrative Scenarios: The illustrative scenarios show how interactive evaluation changes both trajectory evidence entering X and the evaluation program E needed to support valid claims.The framework is applied end to end in coding-agent and multi-agent social settings.
- D.1 Coding Agents.: Coding-agent evaluation uses repository feedback loops in which actions, observations, errors, edits, and revisions provide evidence about process quality, recoverability, and robustness.Agents inspect files, run commands, observe failures or traces, edit code, and revise solutions based on feedback.
- D.1 Coding Agents.: Coding-agent evaluation should include repository state, issue text, tool calls, edits, tests, error traces, and final patches, assessing task success, process quality, efficiency, recoverability, and robustness.The evaluation should also distinguish localized, maintainable patches, error-driven recovery, and avoidance of collateral damage.
- D.1 Coding Agents.: Coding-agent scores risk measuring visible-test gaming or benchmark-specific exploitation, while also varying with environment setup, dependencies, tools, timeouts, and retries.The paper calls for replayable trajectory logs, environment versioning, and reporting that separates genuine debugging competence from exploitation.
- D.2 Multi-Agent Social Systems.: Multi-agent social evaluation measures systems acting in feedback loops where counterparts’ beliefs, strategies, and behavior change as agents communicate, negotiate, coordinate, refuse, and adapt.The relevant evidence includes interaction trajectories rather than isolated utterances.
- D.2 Multi-Agent Social Systems.: Social-agent evaluation must assess coordination, fairness, communication, and robustness across counterpart behavior, roles, private information, incentives, and power asymmetries.Scores can conflate genuine coordination with persuasion, pressure, or strategic withholding, so evaluations should distinguish goal completion, effective coordination, and fair, transparent communication.
E Representative Benchmark List
The section presents a representative, transparent benchmark list for roadmap analysis rather than an exhaustive census, covering response-centered and interactive evaluation stages. It records approximate citation and GitHub-star metadata while leaving unavailable star fields blank.
- Scope and metadata: The benchmark list is intended as a transparent roadmap resource, not an exhaustive census of evaluation benchmarks.It records metadata such as citation counts and GitHub stars as accurately as possible at collection time.
- Scope and metadata: Citation counts and GitHub stars are approximate indicators rather than definitive measures of benchmark importance or influence.GitHub-star fields are left blank when counts are unavailable, including for some older benchmarks or works without official public repositories.
- Stage 1: Response-Centered Evaluation: The list spans response-centered benchmarks such as reading comprehension, commonsense, knowledge, math, and formal-theorem reasoning.Examples include SQuAD, GLUE, DROP, CommonsenseQA, MMLU, GSM8k, MATH, and MiniF2F.
- Stage 3: Interactive Evaluation: Interactive benchmarks cover app and software use, web and computer use, tool assistance, social interaction, and embodied open-world settings.The list includes AppWorld, AndroidWorld, τ-bench, WorkArena, ToolEmu, VisualWebArena, AgentClinic, OSWorld, ToolSandbox, Multi-agent Bench, Vending-Bench, SimWorld, ARE (GAIA2), RealWebAssist, CooperBench, and BuilderBench.