Case Study: Self-Driving Cars and the Last Few Percent

Self-driving cars are worth studying even though you will never build one, because they demonstrate the most commercially important lesson in AI: the relationship between how finished something looks and how finished it is.

The pipeline

Broadly:

📅 Timeline

SensingCameras, radar and often lidar produce a continuous stream of raw observation.

PerceptionDetecting and classifying what is there: cars, pedestrians, cyclists, lane markings, signs, signals. Heavily machine learning.

PredictionForecasting what each of those things will do next. Will that pedestrian step out? Is that car about to merge?

PlanningDeciding the vehicle's own path and speed. Partly learned, substantially conventional algorithms and safety rules.

ControlTurning the plan into steering, accelerator and brake. Classical control engineering, decades old.

Again, much of it is not machine learning. And again, errors compound: a perception mistake becomes a prediction mistake becomes a planning mistake.

The last few percent

A competent team can build something that drives well on a clear, dry, well-marked road in light traffic surprisingly quickly. That is the demo, and it looks like the product.

Then comes everything else. A cyclist carrying a large mirror. A traffic officer waving cars through a red light — a human gesture overriding a signal. Faded lane markings after resurfacing. Heavy rain reducing sensor range. A plastic bag blowing across the road, which must be distinguished from a solid object. A truck with a picture of a car printed on its side. Roadworks where the correct action is to cross a solid white line.

None of these are rare in aggregate. Each is individually rare, and there are effectively unlimited kinds of them. This is the long tail: the vast set of situations that are each unlikely but collectively constant.

The long tail is why serious self-driving efforts have taken far longer than early predictions, and it is not a failure of ambition. It is a structural property of open-world problems.

Why this matters for your organisation

You are not building a car. You will absolutely encounter the same curve.

The demo is the easy 80%. When a vendor shows you their system working, they are showing you the road in good weather. The correct question is not "does it work?" but "what does it do with the strange cases, and how many strange cases are there?"

Ask about the tail directly. For a document-reading system: what happens with a handwritten annotation in the margin, a scan at an angle, a supplier who redesigned their invoice last month, two invoices in one PDF? Any vendor who has actually shipped will have thought about these and will answer readily. One who has not will get vague, and that vagueness is your answer.

Closed problems are much easier than open ones. Routing tickets into six categories is closed — the set of outcomes is fixed and known. Driving is open — the set of situations is unbounded. Closed problems have short tails and are dramatically more likely to succeed. Prefer closed problems for early projects, and be suspicious of proposals that quietly assume an open problem is closed.

A practical technique, usable by a non-technical manager in an afternoon.

Take a random sample of the real inputs your proposed system would handle — a hundred invoices, a hundred tickets, a hundred claims. Genuinely random, not a curated set, and not last week's only.

Now go through them by hand and sort into three piles:

Straightforward. A clear, standard case the system would obviously handle.
Awkward. Something unusual, but a person could work it out.
Genuinely hard. Ambiguous, incomplete, or needing outside knowledge or a judgement call.

The proportions tell you a great deal before a single pound is spent.

If it is 90 / 8 / 2, this is a promising project: automate the straightforward pile, route the rest to people, and you have captured most of the value.

If it is 60 / 30 / 10, be careful. Forty percent needing human attention may still be worth automating, but the business case is now about assistance rather than automation, and it should be sold internally that way.

If it is 40 / 40 / 20, this is not an automation project. It might be a very good assistance project — a system that drafts and a person finalises — but anyone promising to remove the headcount is going to be wrong.

Two further benefits. You will find that the "genuinely hard" pile has recurring themes, which are exactly the exception paths that must be designed. And you will have created, almost for free, the beginnings of a labelled evaluation set — the thing every project needs and few teams have at the start.

❓ Knowledge Check

A vendor demonstrates a document-processing system working flawlessly on ten sample invoices. What is the most useful next question?

📚 Flashcards1 / 4

Term

The long tail

Click to flip

Definition

The vast set of situations that are each individually rare but collectively constant. It dominates the difficulty of open-world problems and explains why the last few percent can cost more than the first ninety.

Click to flip back

💡Key Takeaway

Self-driving teaches the curve every AI project rides: the demo is the easy majority, and the long tail of individually rare situations is where the time and money go. Before committing, sample your real inputs by hand and sort them into straightforward, awkward and genuinely hard — the proportions tell you whether you are looking at an automation project, an assistance project, or a disappointment. And favour closed problems early, where the set of possible answers is fixed and known.