How to Evaluate LLM Performance on Complex, Multi-Step Tasks

1. From Answering Questions to Completing Work

The focus of large language model competition is shifting. Early comparisons emphasized knowledge breadth, fluency, and performance on single-turn questions. More recent frontier models increasingly emphasize agentic, multi-step task execution: given a requirements document, can the model independently research information, modify code, run checks, fix errors, organize deliverables, and produce a result that is ready for review?

This shift has two important implications for developers.

First, the upper limit of a model’s value is no longer determined by the quality of its answers, but by the quality of its deliverables. Second, evaluation methods must evolve accordingly. Testing a tool-enabled model with a few interview-style questions is like using unit tests to validate an entire system: the coverage is far too limited.

One principle must be established at the outset: a model cannot be evaluated separately from its operating environment. The same model may behave very differently in a basic chat interface than it does when connected to a search engine, code execution environment, file system, or browser. Its permissions, context window, and available tools can all significantly affect the outcome.

For that reason, every evaluation dimension discussed below should be applied to the complete system:

Model + tools + permissions + context

2. Evaluate the Deliverable, Not the Presentation

This is where polished demonstrations can be especially misleading. A model may explain a solution convincingly, propose a reasonable architecture, justify its technology choices, and identify relevant risks. However, explaining how to complete a task is fundamentally different from completing it.

The difference becomes clear when the model encounters three common forms of execution friction.

2.1 Error Handling

Real-world tasks rarely work on the first attempt. Dependencies may be missing, APIs may return unexpected responses, tests may fail, or documentation may not match actual behavior.

When this happens, does the model stop at the error message and wait for human intervention? Or can it inspect the logs, identify the cause, revise its approach, and continue?

This is one of the clearest dividing lines between a model that can discuss work and a system that can execute it.

2.2 Recovering Missing Requirements

Requirements for long-running tasks are often distributed across multiple sources. One constraint may appear in the requirements document, another in a chat history, and a third in a code comment.

A capable system should collect these constraints, apply them consistently, and revisit earlier work if it discovers that something was missed. Its ability to identify and correct omissions directly affects the completeness of the final deliverable.

2.3 Practical Usability

The final output should be evaluated against a “ready to use” standard:

• Does the code compile and pass the required tests?
• Is the documentation complete and properly formatted?
• Can external data and citations be verified?
• Can the deliverable be accepted without structural changes?

A useful primary metric is therefore the rework rate. Measure how much time a human reviewer must spend correcting the result and what percentage of the deliverable must be changed.

Instead of asking, “Are you satisfied with this answer?”, ask:

How far is this deliverable from being usable?

3. Evaluate How the Model Handles Uncertainty

Long tasks are rarely specified perfectly at the beginning. The ability to handle uncertainty intelligently distinguishes a simple execution tool from an effective collaborator.

A strong system should use a tiered clarification strategy.

Ask About Critical Ambiguities

If an ambiguity could send the task in the wrong direction, the model should pause and ask for clarification rather than silently making an assumption.

Examples include:

• Version constraints for the target system
• Compliance requirements
• Modules that must not be changed
• Restrictions that could invalidate the implementation

These decisions can affect the entire outcome, so proceeding without clarification creates unnecessary risk.

Resolve Minor Details Independently

Not every uncertainty requires human input. If an ambiguity affects only implementation details and can be reasonably resolved from context, the model should make an appropriate choice and continue.

Examples include variable names, document formatting, or other low-risk details. Asking for approval at every step turns an autonomous collaborator into a tool that must be manually controlled throughout the process.

Preserve Direction After Feedback

When the model receives revision requests, it must adjust its work without losing sight of the original objective.

A common failure mode appears after several rounds of feedback: the model overfits to the most recent instruction, drifts away from the overall goal, or forgets constraints introduced earlier in the task.

To evaluate this capability, create a controlled stress test. Include one strategically important ambiguity and several minor ambiguities in the requirements. Observe:

• Which issues cause the model to ask questions
• Which issues it resolves independently
• Whether its assumptions are reasonable
• Whether it preserves the core objective after multiple rounds of revisions

4. Measure Cost and Reliability Together

Greater capability often comes with greater cost. Models that support long contexts, search, and multiple external tools may consume several times the resources required by lightweight models.

Cost and reliability should therefore be evaluated together.

4.1 Hallucination Risk in Long Contexts

A larger context window means that more information can fit into the prompt. It does not guarantee that the model will interpret that information correctly.

As the amount of source material grows, the model may become more likely to attribute a statement to the wrong source, confuse similar facts, or cite information that does not support its conclusion.

Long-task deliverables require additional verification:

• Does every cited source actually exist?
• Does each source support the associated claim?
• Can the data source be reproduced or independently checked?

4.2 Safe Operational Boundaries

When a model can access a file system, call APIs, or execute commands, operational boundaries become a required part of reliability testing.

Permissions should follow the principle of least privilege, and important actions should be logged for auditing. The evaluation should explicitly check whether the model:

• Accessed information outside its authorized scope
• Performed write operations beyond the task requirements
• Modified resources that should have remained unchanged
• Produced adequate logs for critical operations

A successful deliverable does not justify unauthorized behavior.

4.3 Tiered Cost Allocation

The most capable model does not necessarily need to perform every step in a workflow.

A practical architecture may assign planning, judgment, and final review to a flagship model while using lower-cost models for mechanical tasks such as information extraction, format conversion, and straightforward rewriting.

During evaluation, record both:

• Total cost per task
• Cost distribution across workflow stages

This provides the data needed to optimize the system later without reducing quality in the stages that require stronger reasoning.

5. Run an End-to-End Test with Real Work

Rather than debating whether a model represents a major breakthrough or an incremental upgrade, run a controlled comparison based on a real task.

The following process provides a practical starting point.

Step 1: Select a Baseline Task

Choose a task from your normal workload that would take a person about two hours to complete.

The task should include several stages, such as:

• Research
• Modification
• Validation
• Final delivery

Avoid artificial toy problems. The goal is to measure how the system performs under conditions that resemble actual work.

Step 2: Define Acceptance Criteria in Advance

Before execution begins, write down objective, testable acceptance conditions.

For example:

• The code must pass all existing tests.
• The document must include specified sections.
• Every external data point must include a verifiable source.
• Restricted files or modules must remain unchanged.

This step is essential because it prevents evaluators from lowering the standard after seeing the model’s output.

Step 3: Let the System Complete the Task

Provide the tools, permissions, and context required to complete the work.

During execution, respond when the model explicitly asks for clarification, but do not provide additional hints or unsolicited guidance. Otherwise, the test will measure the combined performance of the model and the human operator rather than the model system itself.

Step 4: Quantify the Results

Record at least the following:

• Whether the deliverable passed the acceptance criteria
• How much human rework time was required
• What proportion of the output had to be changed
• Whether citations and data sources were accurate
• Whether any operation exceeded the authorized scope
• The total cost of completing the task
• How that cost was distributed across workflow stages

Step 5: Repeat Across Multiple Tasks

Repeat the experiment with three to five tasks from different domains. A single successful or unsuccessful result is not enough to support a reliable conclusion.

Multiple samples help distinguish consistent capability from task-specific luck.

A simple acceptance checklist might look like this:

Task Acceptance Checklist
□ Critical ambiguities were clarified before execution, while minor ambiguities were handled reasonably.
□ The deliverable can be used directly without structural rework.
□ All citations and data sources can be verified.
□ All operations remained within the authorized scope, and critical actions were logged.
□ Human rework time was significantly lower than the manual baseline.
□ Total cost was acceptable, with a reasonable cost distribution across workflow stages.

Where appropriate, teams can also use cloud platforms, including Baidu AI Cloud, to create a reproducible and auditable evaluation environment. General-purpose services such as object storage, logging, monitoring, and alerting can help preserve tool-call records, operation traces, and cost data for later review.

6. Free Humans from Supervising Every Step

The threshold for meaningful long-task capability is straightforward: can the system reliably move humans from continuously monitoring progress and troubleshooting errors to primarily making decisions and reviewing final results?

A successful demonstration is not enough. What matters is whether the system can consistently deliver:

• A measurable reduction in human rework
• Controlled operational boundaries
• Verifiable sources and outputs
• Acceptable and transparent costs

A practical way to evaluate any model is to give it a real task that would normally take you about two hours. Define the acceptance criteria first, let the system complete the work, and then inspect the result.

For your own workflows, this evidence will usually be more useful than any general-purpose benchmark leaderboard.