Why the field needed a map
Learning to defer began with a deceptively compact question: should a model answer this case, or pass it to an expert? The literature now spans joint and modular training, different notions of consistency, regression and sequential decisions, changing expert pools, capacity constraints, fairness, and safety.
Those developments are useful, but they also made papers difficult to compare. The same system can be described through different architectures, losses, assumptions, and evaluation protocols. Our survey gives that work a common map—and makes the design choices behind a deferral system easier to see.
Four branches, one decision problem
Methodological frameworks
Is the predictor learned jointly with the deferral policy, kept fixed, or fine-tuned after pretraining?
Optimisation & theory
Which surrogate loss recovers the intended decision rule, and what kind of consistency or regret guarantee does it provide?
Task generalisations
How does deferral change for regression, multi-task outputs, committees, sequences, or causal pipelines?
Real-world adaptations
What happens when annotations are scarce, experts rotate, budgets bind, or robustness and fairness become operational requirements?
Three ways to build the system
A useful first distinction is not the loss function but which parts of the system can actually be changed. This determines what the predictor and rejector can learn about one another.
One-stage learning
Train predictor and deferral mechanism together from scratch. They can specialise to one another, which is powerful but can make the system brittle when experts or constraints change.
Two-stage learning
Keep an existing predictor fixed and learn a router around it. This is the natural choice for deployed models and black-box APIs, and is easier to update when the expert pool changes.
Post-hoc fine-tuning
Start from a pretrained predictor, then jointly adapt it with a new rejector. This sits between modularity and co-adaptation.
A practical reading of the theory
A consistent surrogate is valuable because improving its training loss should move the learned policy toward the Bayes-optimal handover rule. But the guarantee is conditional: it depends on the architecture, training framework, cost definition, hypothesis class, and expert assumptions. A theorem for a fixed expert and joint training does not automatically transfer to a frozen predictor or a changing expert pool.
Before choosing a loss, write down:
- Whether the predictor is trainable, frozen, or accessible only through an API.
- What an expert query costs—and whether that cost changes with workload.
- Whether expert correctness can be estimated and calibrated on the cases that matter.
- Which constraints apply at inference: budgets, fairness, latency, or routing policy.
- Which system-level curves and failure modes will be reported beyond headline accuracy.
Conclusion
The survey's main message is that learning to defer is no longer a single loss-function problem. It is a family of allocation problems, and each formulation encodes a view of the predictor, the expert, the cost of consultation, and the world in which they will operate. The right method is the one whose assumptions match that world.