AI Glossary / AI and machine learning / Advanced

One-vs-one

Definition

One-vs-one is a scheme for multi-class classification that trains one binary classifier for every pair of classes: ten classes mean forty-five pairwise judges, and each new item is assigned by their combined votes.

What it means

The scheme turns a hard multi-class problem into many easy binary ones: distinguishing billing from legal is simpler than distinguishing everything from everything at once, and pairwise judges specialize.

Voting combines them: each classifier casts a vote for one of its two classes, and the class with the most votes wins, with ties broken by confidence or convention.

The cost grows quadratically: n classes need n-times-n-minus-one-over-two judges, so fifty classes mean over a thousand models to train, store and keep consistent.

Each judge trains only on its two classes' data, which is the compensating virtue: every model sees a clean, balanced, narrow problem, and judges retrain independently.

For a business, one-vs-one appears inside standard toolkits as the default behind some popular classifiers, so knowing the scheme explains the training times, the model counts and the confidence quirks in vendor documentation.

The scheme is also called pairwise classification or all-pairs, and it is the historic default behind support vector machines on multi-class problems.

How it works

Confirm the class count is moderate, since pairwise judges grow quadratically and dominate training time beyond a few dozen classes.

Train one binary classifier per class pair on just those classes' examples.

Score a new item with every judge, collecting each pair's vote for its winner.

Assign the class with the most votes, breaking ties by summed confidence or a fixed rule.

Track judges as a fleet: versioning, retraining and monitoring now multiply by the pair count.

Watch judge agreement on errors: items that split the fleet evenly are the hard cases worth routing to review.

Three practical examples

A ten-queue ticket router running forty-five pairwise judges, each distinguishing one queue pair with specialist focus.
A document classifier where pairwise judges beat a one-vs-rest scheme because the classes overlapped heavily in shared vocabulary.
A toolkit default silently training one-vs-one behind a familiar algorithm, explaining why model size grew quadratically with classes.

Think of it this way

Think of a round-robin tournament: every team plays every other team, and the winner is the side with the most victories, not the one that won a single grand final.

Worked example

the pairwise judges

Suppose a twelve-class document router is built one-vs-one: sixty-six judges. The figures are illustrative.

Training is heavy but each judge is excellent on its narrow question, and combined accuracy beats the one-vs-rest baseline by four points.

The operational bill arrives later: a schema change forces sixty-six retrainings, and the team builds a registry to keep the fleet consistent.

The trade is the scheme in miniature: specialization and accuracy against a quadratic maintenance fleet.

Illustrative case study

A fictional bank scaled a one-vs-one router from eight to thirty classes without revisiting the scheme, and training time grew from minutes to days as judges multiplied from twenty-eight to four hundred thirty-five.

Retraining slipped from nightly to weekly, model freshness degraded, and fraud patterns outran the update cycle.

The invented lesson: quadratic costs are invisible at small scale and decisive at large. Recount the judges before adding classes, not after the schedule breaks.

The redesign moved the bank to a native multi-class model for the thirty classes, cutting the fleet from hundreds of judges to one model with one retraining schedule.

Common misconceptions and mistakes

It is always better than one-vs-rest. It often wins on overlapping classes but costs quadratically in judges; the choice is empirical.
The votes need calibration. Plain voting works without calibrated scores, which is part of the scheme's appeal; confidence only breaks ties.
Judges share data freely. Each judge trains only on its pair's examples, which is why the problems stay narrow and clean.
The scheme is obsolete. It remains the default inside widely used toolkits, so it is quietly present in production systems everywhere.

Business use

Count the judges before adding classes, and budget retraining for the fleet, not for one model.

Choose between one-vs-one and one-vs-rest empirically per problem, not by habit.

Build a registry for pairwise judges early, since consistency across a fleet is where operations fail.

Check which scheme your toolkit uses by default, because it explains training cost, model size and confidence behavior.

Prefer one-vs-rest or native multi-class heads when classes are many, and reserve pairwise schemes for moderate counts with overlapping classes.

Check your understanding

Why does one-vs-one training cost grow quadratically with the number of classes?

Answer: Because every pair of classes needs its own judge, and pairs grow as n-squared: ten classes need forty-five judges and fifty need over a thousand, so model count, training time and maintenance all scale with the square of the class count.

Related terms

Learn next

AI for Business Owners helps you read the architecture choices hidden in vendor training times: https://aiforbusinessandlife.com/academy/ai-for-business-owners. [C2]

Sources

[S24] scikit-learn documentation, Glossary of Common Terms and API Elements; [S2] Google, Machine Learning Glossary. Full URLs are in the source ledger. Verified 11 October 2026.

Previous: One-to-one (data model) Next: One-vs-Rest