The pipeline that hides its weakest part

One model, one error rate, one place to send the money. That is why the previous sessions work. A pipeline breaks the link: the error rate is measured at the end of the chain, the money has to go to one link, and nothing in the number says which link. Every stage is a candidate and every stage has a sponsor who can explain why it is not their stage.

What fills the gap, in most teams, is the error sheet's category name. A frame with no animal in it comes out labelled deer, so the row says "empty frame called animal", and the word "called" points at the thing that does the calling. The category describes the symptom at the end of the pipe. It was never a claim about the cause, and it gets read as one.

• Pipeline - a system where the output of one learned component is the input of the next. Lanternfish has two stages: motion detector, then species classifier.
• Stage, or part - one box in that chain. The unit a project is funded against.
• Error analysis by parts - attributing each mistake of the whole system to one box, rather than to a symptom category. Chapter 53.
• Attribution by perfect input - hand the later stage a hand-corrected version of the earlier stage's output. If the error disappears, it was the earlier stage's. Chapter 54.
• Human-level performance for a stage - how well a person does that stage's job alone, given that stage's input. The yardstick from session 4, applied one box at a time.
• A flawed pipeline - every stage at human-level, system still short. The chain's shape is the problem. Chapter 57.
• End-to-end learning - replacing the whole chain with one model trained input to output. A real alternative, and a different course.

Consider one Lanternfish frame. A branch moves in the wind at three in the morning. The motion detector decides there is an animal and passes the frame on. The species classifier, whose entire job is to name an animal, is handed a picture with no animal in it and does the only thing it can do: it names the closest thing, and says deer. The frame is logged as a deer sighting, the conservation group's report has a deer in it that was never there, and the error sheet gets a row.

Every part of that story is the detector's doing except the last two. The classifier was not wrong in any sense it could have been right about; nothing in its training or its architecture would have saved it, because it was never asked whether there was an animal. It was asked which animal. Yet the sheet's row says the classifier said deer, and the classifier is what gets funded.

This is not a labelling slip. It is structural: the last stage in a chain is the one that produces the visible output, so the visible output carries its name. In a longer pipeline the effect compounds, and the last box acquires a reputation for being the weak one purely by standing at the exit.

Chapter 54 is called "Attributing error to one part", and the move it describes is small enough to do on a laptop in an afternoon. Take one error the whole system made. Give the second stage a perfect version of what the first stage should have produced, made by hand, by a person looking at the frame. Then run the second stage again and see what happens.

• The error disappears. The second stage was capable all along, given a correct input. The error belonged to the first stage.
• The error survives. Even handed a perfect input, the second stage still gets it wrong. The error is genuinely the second stage's, and a project on the first stage will not remove it.
• Both stages contributed. It happens, and it is not a problem for the tally: attribute it to the stage whose correction removed the error, and note the row. If correcting either one removes it, the cheaper correction wins the funding argument.

The reason this works is that it turns an argument into an experiment. Before it, two engineers hold two opinions about a frame and neither can be checked. After it, there is a frame, a corrected input, and a result that both of them can look at. Nothing about the model changed; the question changed from "whose fault do you think this is" to "watch what happens when we fix one thing at a time".

Lanternfish's Eyeball spreadsheet has 64 errors on it. Ten of them, 16 percent, sit in the category "empty frame called animal". Before tonight, those ten were classifier errors, because that is where the sheet put them and nobody had drawn the system as boxes.

Correcting the detector's decision by hand on all ten made all ten errors disappear. Not most of them. All of them, because an empty frame that never reaches the classifier cannot be misclassified. Every one of the ten belonged to the motion detector, which had never been measured, and none of them could have been touched by any amount of work on the species model.

• The project that fixes them is the motion-trigger filter, first stage, two weeks, ceiling 1.6 points, 0.80 points per week. It was on the sheet from session 3, sitting third.
• The project that cannot fix them is the deer-versus-elk specialist model, eight weeks, 0.21 points per week, and the one the room wanted. It is a second-stage project, and these are first-stage errors.
• What the attribution changed was not the ranking of those two projects, which was already clear, but the reason. The room could argue about points per week. It could not argue with ten frames where correcting the detector made the error go away.

Take two rows from the Lanternfish sheet, both filed under a species being named wrongly. On paper they are the same failure. Under attribution they are two different projects.

• Row one. The detector cropped tightly around a moving shape and handed the classifier a corner of an elk. Given the full frame by hand, the classifier names it correctly. First-stage error. A better classifier changes nothing.
• Row two. The detector produced a clean, correctly cropped animal, and the classifier said deer where a person says elk. Given a perfect crop, the error survives. Second-stage error, and it is one of the twelve the specialist model exists to fix.

Both rows say the same thing in the category column. One of them belongs to a two-week project and one to an eight-week project, and only the attribution step can tell them apart. This is why the tally is worth an afternoon even when the sheet already looks well organised: a good category scheme describes what the output looked like, and funding needs to know what produced it.

Chapter 56 extends session 4's yardstick to a chain. Human-level performance for the whole system is not the useful number here; human-level performance for each stage in isolation is. Show a person only what the motion detector sees, a single frame, and ask only the detector's question: is there an animal in this. Then show a person only what the classifier sees, a correctly cropped animal, and ask only which species. Two separate exercises, two separate numbers.

At Lanternfish the detector is right 91 times in 100 on its own question and a person is right 99 times: a gap of eight points. The classifier, handed a correct detector call, is right 94 times where a person is right 98: a gap of four. The stage with the wider gap is the one where work has somewhere to go, and it is the stage nobody had been funding.

• A wide gap means headroom. Something a person can do and the model cannot is, by demonstration, learnable.
• A narrow gap means diminishing returns. The classifier can still be improved, and each point will cost more than the last, because it is close to what anyone can do with that input.
• The share of errors does not decide this. The classifier owns more of the 120 errors and is nearer its ceiling. Both are true at once, and only the second one prices a project.

Chapter 57 is titled "Spotting a flawed ML pipeline", and it names the situation every stage-by-stage analysis has to be able to reach: each stage is performing at human-level for its own job, and the system as a whole is still not good enough. When that happens, there is no stage left to fund. The problem is the shape of the chain.

The usual cause is that the interface between two stages throws away something the later stage needed. A motion detector that outputs a yes or a no has already discarded where in the frame the movement was, how large it was, and how fast. A person doing the detector's job perfectly, under that interface, still hands the classifier a bare yes. If the classifier needs the crop and the interface cannot carry it, both stages can be flawless and the pair can still be wrong.

• The test is cheap. Give every stage a perfect input by hand and let it run. If the system is still short, the design is the finding.
• The remedy is a design change, not a training run: widen the interface, merge two stages, or reorder them.
• It is worth reaching this conclusion early, because it is the one conclusion that no amount of funding a stage can arrive at, and teams can spend a year discovering it the slow way.

There is an alternative to fixing a chain, and chapters 47 to 52 of Machine Learning Yearning are about it: replace the whole pipeline with a single model trained straight from the raw input to the final answer, so no hand-designed interface exists to lose anything. It is a genuine option, it has a real cost in data volume, and the trade-off between the two designs belongs to the deep learning course, which owns architecture decisions. It is named here so that a leader reading a flawed-pipeline finding knows the option exists, and does not conclude that the only move is to keep widening interfaces.

The method has one real cost and it should be stated before anybody commits to it. A perfect input for a stage rarely exists in any system. Somebody has to make it, one example at a time, by looking at a frame and writing down what the earlier stage should have said. For Lanternfish that is a person, a screen, and a morning.

• Ten errors is enough to change a decision. Not a hundred. Ten hand-corrected examples that all point at one box is a finding, and a team can produce ten in an hour.
• Not every stage can be hand-corrected cheaply. If a stage's output is a learned embedding, no person can write down its perfect value. Attribute what you can and say plainly which stages the method could not reach.
• The labelling is reusable. Corrected first-stage outputs are training data for the first stage, so the afternoon spent attributing errors is also the start of the project it recommends.
• It is worth it because the alternative is a guess with a two-week project and an eight-week project riding on it. An afternoon against eight weeks is not a close call.