14

9:45 - 10:14

Failure mode: sending a good image for enhancement

Watch from 9:45

Selective enhancement only works when the router knows when not to edit. This chapter examines the opposite of a recall miss: the system sends an image that is already good enough down the enhancement path.

Source focus (09:45–10:14): The presenters show a high-quality cheeseburger image that the router incorrectly judges to be below the technical-quality bar. The image is therefore sent for enhancement. They point out two costs: compute is spent without an expected quality lift, and an already good image may be degraded.

The example: a routing false positive

The image shows a cheeseburger with fries. In the example, it is described as high quality, but the router assigns a below-bar technical-quality assessment. The other checks shown on the slide pass. Because the router treats the image as needing help, it chooses enhance instead of skip.

At about 09:51, the slide pairs the food image with a technical below-bar assessment and an over-processing label. The visible example illustrates the router's mistake before enhancement begins.

This is a false positive when we define “positive” as “send the image for enhancement”:

What the router predicts What the image actually needs Result
Enhance Skip; the image is already good enough False positive, or over-routing

The important detail is where the error occurs. The router has made the wrong branch decision. This is not yet an editor failure. We do not need to show that the editor produced a bad image to identify the problem; unnecessary processing is already a system error.

Why unnecessary enhancement is harmful

1. It spends compute without an expected benefit

Enhancement consumes model inference and the surrounding pipeline's resources. If the input is already high quality, the system should not expect a meaningful improvement from editing it. The result is therefore extra compute for zero expected quality lift.

This is the operational reason for selective enhancement. The goal is not to maximize the number of images edited. The goal is to edit the images for which editing is worthwhile.

2. It exposes a good source image to degradation

An editor can alter more than the defect that motivated the route. On an image that is already good, a change may reduce fidelity or make the result look less natural. The source describes this as a risk, not as a claim that every unnecessary edit will definitely fail.

That distinction matters. A route to enhancement is not automatically safe just because a downstream editor and QA gate exist. The system has already taken on avoidable cost and avoidable risk. A later gate may catch the degradation, but it is better to avoid the bad route when the original should have been retained.

Routing quality is different from editing quality

There are two separate questions:

  1. Routing: Did the system choose the appropriate branch for the input?
  2. Editing: If enhancement was appropriate, did the editor improve the image without damaging its content or appearance?

The cheeseburger case is a failure of the first question. It should not be counted only as an editor problem, even if the eventual edited image also looks worse. Keeping these stages separate helps the team choose the right fix:

  • A routing error calls for better input understanding, rubric criteria, or routing thresholds.
  • An editing error calls for a better edit prompt, editor, or enhancement-and-QA loop.

The same final image can hide these different causes. A trace that records the route makes the distinction visible.

The metric connection: precision and recall protect different sides

The earlier routing evaluation treats the router like a classifier. With enhance as the positive class, this example is a false positive: the router predicted enhance when the appropriate action was skip.

In ordinary classifier terms, precision asks how often the cases predicted positive are truly positive. Here, it asks how often images sent for enhancement really needed that route. A low precision can mean that the enhancement path is receiving too many good images.

Recall asks how many of the cases that truly need the positive action were found. In this system, a recall miss is the other direction: a poor or unsuitable image is accepted or skipped when it should have been caught. The next failure-mode example covers that risk.

These metrics are not interchangeable:

Routing concern Failure What it protects against
Precision of the enhance route Good image sent to enhancement Wasted compute and unnecessary degradation risk
Recall for images needing intervention Bad image not caught An unsuitable image slipping through

The system therefore needs both sides of the evaluation. Optimizing only recall could make the router send too many images to enhancement. Optimizing only precision could allow images that need help to escape detection. The useful operating point must support selective quality improvement while respecting the safety and fidelity goals of the larger system.

A practical mental model

Treat the router as a gate with two responsibilities, not one:

Is this image worth editing?
        |
        +-- no  -> retain the original
        |
        +-- yes -> send it to enhancement, then evaluate the result

For the cheeseburger example, the correct path is the first branch. The failure is not that the system lacked an editing capability. It is that the system invoked that capability when the expected benefit was absent.

This is why a production eval must measure branch decisions as well as final image quality. A system can produce attractive edits and still be inefficient or unsafe if it over-routes good inputs. Conversely, a system that skips too aggressively may preserve originals that needed improvement. Closed-loop tuning needs evidence about both errors so that a change to the router improves the whole workflow rather than merely shifting failures from one branch to the other.

Source boundary: The talk does not provide the router's exact threshold, rubric fields, or numeric precision and recall values. “Technical: Below bar” is the reliable interpretation of the slide and transcript; the precise transcript wording for that label is unclear.

Source visuals

A slide shows a cheeseburger-and-fries image alongside a routing assessment marked Technical: Below bar, while the other checks pass.

All three supplied nearby frames show the same stable slide: the visible food image is paired with a technical below-bar assessment and an over-processing label, directly illustrating the requested routing-failure example.

Source at 9:51
100% Space + drag to pan | Ctrl/Cmd + wheel to zoom