Skip to content

CONCEPT Cited by 1 source

Speed-Accuracy Trade-off (Real-Time Decisions)

Structural property of real-time decision systems where the data supporting a decision accumulates over time, so the decision's accuracy improves monotonically with the time the system waits before committing — but the value of the decision is a decreasing function of that same waiting time. The two curves cross at a system-specific optimum.

The trade-off shows up whenever an online inference loop has to choose between acting on partial evidence and waiting for more:

  • Earthquake Early Warning — every second waiting for the magnitude estimate to converge is a second of warning taken away from users in the path of the shaking. Google explicitly names this trade-off in the 2025-07-17 Android Earthquake Alerts post: "the first few seconds of an earthquake provide limited data, but every second you wait to issue an alert is a second less of warning for those in the path of the shaking" (Source: sources/2025-07-17-google-android-earthquake-alerts).
  • Online fraud detection — wait for more signals (device fingerprint settling, velocity check, behavioural biometrics) at the cost of delayed transaction authorization.
  • Autonomous-vehicle perception — wait for more sensor frames to disambiguate object class at the cost of delayed braking / steering.
  • Ad bidding — more feature lookups mean better bid but miss the auction deadline.
  • Trading risk checks — more risk-model iterations vs. fill deadline.

The trade-off is asymmetric: the cost function of being early and wrong is usually structurally different from the cost function of being late and right. EEW's asymmetry is canonical — an over-estimate triggers false alarms that erode public trust (amortised cost across many events), an under-estimate leaves people in the danger zone unwarned (localised cost per missed event). Fraud has the same shape with opposite polarity. Design has to price each side separately.

Load-bearing design implications

  • Publish the error curve, not a single-point metric. A system that reports "MAE 0.25" at the first estimate is not comparable with one reporting MAE at a fully-converged estimate; both must be reported against wall-clock-since-event-onset to be useful.
  • Quote the operating point. The chosen (latency, accuracy) operating point is a product + safety decision, not a model property. Moving the operating point is a product change, not just a tuning change.
  • Continuous improvement of the curve is the real engineering target. A three-year halving of first-estimate MAE (AEA 0.50 → 0.25) shifts the curve down everywhere; the product can then choose to keep the same latency and spend the accuracy budget on fewer false alarms, or keep the same accuracy and spend the latency budget on longer warning windows.
  • Asymmetric costs motivate asymmetric thresholds. Not a single operating point but distinct alert-threshold surfaces per asymmetric cost direction (e.g. lower threshold for issuing a localised alert near the epicentre where false-alarm cost is lower and missed-alarm cost is higher).

Canonical wiki instance

Android Earthquake Alerts (AEA) — Google's 2025-07-17 post is the canonical wiki articulation of the trade-off in a production EEW system. The MAE 0.50 → 0.25 three-year improvement is a curve-shift, not just a point improvement: the post explicitly argues the gain came from "continuously improved our magnitude estimation" rather than from waiting longer per event.

Seen in

Last updated · 200 distilled / 1,178 read