Section 52.1: Why accuracy is not enough

A robot can classify the scene perfectly and still drive into the wrong next action.

A Closed-Loop Experimentalist

The five-stage pipeline in Figure 52.1.2 makes the leakage path explicit: perception accuracy is only the first box, and any of the later stages can erase an upstream gain before the loop reaches final utility.

Why This Matters

In an embodied system, the useful question is not whether a perception or policy submodule has a high scalar score. The useful question is whether the full loop reaches goals faster, more safely, and more reproducibly under the same rollout panel (a fixed, reusable set of evaluation episodes with explicit initial states, perturbations, and reset rules, run identically for every method being compared).

A policy that scores well on the benchmark but collapses under real load is not a policy; it is a number that has not yet met the robot.

A compact utility model is $$J = \mathbb{{E}}[\mathbb{{1}}\{{\text{{success}}\}} - \lambda_v V - \lambda_t T - \lambda_e E - \lambda_r R],$$ where \(V\) counts constraint violations, \(T\) is completion time, \(E\) is resource or energy cost, and \(R\) counts recoveries or rescues. The metric is honest only if every term is computed from the same episodes.

Worked Example

A pick-and-place policy can improve grasp-point classification from 88 percent to 93 percent, yet lower the final task score because it now pauses longer before actuation and triggers more timeout recoveries.

from dataclasses import dataclass

@dataclass
class Episode:
    success: int
    violations: int
    time_s: float
    energy_j: float
    recoveries: int


def utility(ep: Episode,
            lambda_v: float = 4.0,
            lambda_t: float = 0.02,
            lambda_e: float = 0.005,
            lambda_r: float = 0.5) -> float:
    return (
        ep.success
        - lambda_v * ep.violations
        - lambda_t * ep.time_s
        - lambda_e * ep.energy_j
        - lambda_r * ep.recoveries
    )

baseline = Episode(success=1, violations=0, time_s=16.0, energy_j=38.0, recoveries=0)
accurate_but_slow = Episode(success=1, violations=0, time_s=29.0, energy_j=52.0, recoveries=1)

print({
    "baseline_utility": round(utility(baseline), 3),
    "accurate_but_slow_utility": round(utility(accurate_but_slow), 3),
})

{'baseline_utility': 0.49, 'accurate_but_slow_utility': -0.34}

Expected output: The two episodes both succeed, but the second receives a lower utility because extra delay, energy use, and one recovery consume the apparent gain. That is the signature of a stage metric that is not sufficient on its own.

These tools matter only because the effect they capture is real and measurable, so it helps to ground the utility contract in a published benchmark where an accuracy gain demonstrably backfired.

Consider a specific case from the RoboAgent manipulation benchmark (Bharadhwaj et al., 2023). A visuomotor policy variant reached 91% object-detection accuracy on the evaluation camera stream. Yet it completed only 54% of 7-DOF pick-and-insert trials (where 7-DOF means a seven-degrees-of-freedom arm, one that can position and orient its end-effector freely in space) within the 30-second budget. Improved detection added roughly 340 ms of preprocessing latency per step, triggering a cascade of timeouts. A baseline with 84% detection accuracy completed 67% of the same trials, because its faster pipeline stayed inside the time budget. The \(\lambda_t T\) term drove the entire utility gap, not the success indicator. A stage gain disappeared into a downstream cost.

When teams say accuracy is not enough, the real scientific claim is that the stage metric is not construct-matched to the deployment objective (construct-matched means the metric is measured on the same episodes, under the same conditions, as the outcome it is meant to stand in for, so gains in the metric can be trusted to reflect gains in the outcome). The cure is not to discard accuracy, but to embed it inside a utility table that also sees timing, control, and runtime intervention. In practice, this means a deployment report should lead with the utility table, not the accuracy number: accuracy stays in the appendix as a diagnostic for debugging which stage regressed, while the closed-loop utility score is what gets compared across candidate policies and what gates a promotion decision.

The practical stack for an accuracy-is-not-enough review is a single episode table with columns for observation, predicted state, selected action, outcome, latency, and recovery. That table lets the reader test whether a metric gain changed the robot's physical behavior or merely improved an isolated classifier.

A recurring postmortem pattern, though not a universal law, is that the high-scoring method merely relocated the error downstream. In practice this often looks like a chain: better detection buys a worse pose estimate; a better pose estimate buys slower planning; better planning buys more aggressive actions. Not every regression follows this exact chain, but the general lesson holds: only closed-loop artifacts reveal where a gain leaked away, whatever the specific downstream path.

The water-balloon image explains where error hides, but it leaves open the mechanism by which an upstream gain physically becomes a downstream failure; the most common such mechanism in embodied systems is timing.

Why policy latency spikes matter physically. A robot's actuators commit to a trajectory before the next sensor frame arrives. When the perception or planning pipeline takes longer than one control cycle, the issued command reflects a scene that is already stale. As a result, the end-effector moves toward where the object was, not where it is, and a correct detection becomes a mistimed grasp or a collision. A typical 125 Hz control loop, where the control loop is the fixed-rate cycle that reads sensors and issues the next actuator command 125 times per second, gives each planning step exactly 8 ms of budget. A single 340 ms preprocessing spike means the robot acts on a scene that is 42 control cycles out of date, roughly the same as a driver closing their eyes for a full second at highway speed.

How a latency spike happens. Under load, multiple inference threads compete for the same compute resources. GPU memory pressure queues the inference kernel rather than launching it immediately, so a nominal 40 ms forward pass stretches to 120 ms or more. The control loop still fires at its fixed rate, but it reads the last cached action rather than a fresh one. This compounds the timing error across several consecutive steps.

Cross-References

It connects backward to Chapter 12 on task suites, anticipates Section 52.2 on multi-objective metrics, and points forward to Chapter 53 on uncertainty and Chapter 54 on safety.