Zero-shot classification definition

Zero-shot classification sorts an input into labels you describe at request time, so you can add, rename, or remove a category without collecting examples or retraining anything. The quality of the result depends on how clean the input and the label set are. In Sanity, typed fields and references to taxonomy documents mean the text you send is already bounded and the label descriptions live beside the labels themselves, so every classification run uses the same wording.

How does zero-shot classification work?

Zero-shot classification works by comparing an input against descriptions of the candidate labels, rather than against learned examples of them. Because the model already understands language, naming and describing a category gives it enough information to judge whether a piece of text belongs there.

There are four common implementations. The first is prompting a general model: you send the text, list the allowed labels, and ask for one back. The second uses a natural language inference model, which was trained to judge whether one sentence follows from another; you turn each label into a hypothesis like "This text is about refunds" and keep the label the model judges most likely. The third uses text embeddings, numeric representations of meaning, to measure how close the input sits to a written description of each label. The fourth uses an API that takes the label set as an explicit, finite answer space and returns a choice from it, rather than free text.

That last pattern is what decision models do. OpenAI's Decisions API, announced at DevDay on 29 September 2026, is a current example: in OpenAI's description, it "enables real-time decision-making by focusing Luna's intelligence on a specific set of user-defined questions with finite pre-defined answers. Developers supply context using text or images, and get back answers they can use to classify content, route requests, or choose an agent's next action." The practical difference from open-ended prompting is that the answer space is part of the request, so you do not have to parse or repair whatever the model felt like writing.

What is the difference between zero-shot, few-shot, and fine-tuned classification?

The difference between zero-shot, few-shot, and fine-tuned classification is how much labeled data each one needs before it can produce a label. Zero-shot classification needs none: you describe the labels and the model decides. Few-shot classification puts a handful of worked examples in the prompt, typically two to ten per label, which teaches the model your house conventions for edge cases without any training run. A fine-tuned classifier is trained on your labeled data, hundreds or thousands of examples per label, and the labels are baked into the model.

Each is right in a different situation. Zero-shot is right when the label set changes often, when you have no labeled data, or when you need something working today and would rather learn what the real categories are by watching the output. Few-shot is right when zero-shot is nearly correct but keeps getting the same boundary case wrong, and a couple of examples would settle it. Fine-tuning is right when the task is stable, the volume is high enough that per-request cost matters, and you have the labeled data to train on.

These are not exclusive. A common progression is to start zero-shot, keep the outputs and the corrections editors make to them, and use that accumulated set as training data later. The zero-shot phase is what produces the labeled corpus that makes fine-tuning possible.

What are the pitfalls of zero-shot classification?

The main pitfalls of zero-shot classification come from the label set, not the model. Because the labels are the only instruction the model gets, anything vague or overlapping in them shows up directly in the output.

Ambiguous or overlapping label names are the first problem. If a taxonomy contains both "Pricing" and "Billing", a human needs the house rule to tell them apart, and so does the model. The second is a missing escape hatch: if every input must be forced into one of the listed labels, content that belongs in none of them gets assigned to whichever is closest, which quietly pollutes the data. Including an explicit "other" or "none of these" option, and treating how often it fires as a signal about the taxonomy, avoids that.

The third is sensitivity to wording. Zero-shot classification gives different answers for "Support" and "Customer support requests" because the label text is the prompt. Changing a label name is a change to the classifier, so it should be versioned and remeasured like one. The fourth is the assumption that skipping training means skipping evaluation. It does not. You still need a sample of inputs labeled by hand, a few hundred is usually enough to see the shape of the errors, and to check the model against before trusting it at volume. Techniques for stabilizing label descriptions and output format fall under prompt engineering, and the broader practice of applying labels to content is content classification.

How do you get better zero-shot classification results from your content?

You get better zero-shot classification results by improving the two things you control: the input text and the label descriptions. The model is fixed, so the tuning work sits on either side of it.

On the input side, a bounded, typed excerpt beats a whole page. Sending a product's description field and category reference is a cleaner signal than sending the rendered HTML of the page it appears on, because the markup, navigation, and boilerplate are noise the model has to work past. On the label side, the biggest single improvement in our experience is storing a written description with each label in the taxonomy, rather than keeping it in a prompt template or in someone's head. A label document that holds the name, a sentence on what belongs in it, and a sentence on what does not is both the thing editors read and the thing the classifier is sent.

This is the architectural reason structured content matters here. Sanity is the AI Content Operating System, and because taxonomy terms are documents with their own fields and revision history, the definition a model classifies against is the same definition an editor sees, and a change to it is a reviewable event, rather than an untracked prompt edit. Consistency across runs comes from the labels being governed content, not from the classifier.

When should you not use zero-shot classification?

You should not use zero-shot classification when the categories depend on knowledge the model has no way to infer from language alone. If the difference between two labels is an internal policy, a contractual distinction, or a convention your team decided on last quarter, describing the labels will not be enough, and the correct answer is few-shot examples, fine-tuning, or a rule.

Zero-shot classification is also the wrong tool when the decision is high stakes and unreviewed. Routing a support ticket to the wrong queue is recoverable. Applying a regulatory or safety label with no human in the loop is not, and the fact that a zero-shot system will always return one of your labels, confidently, is exactly what makes silent errors hard to spot.

The third case is pure volume economics on a frozen task. If the label set has not changed in a year and you are classifying millions of items, a small trained classifier is cheaper per call than a general model, and you already have the labeled data to build it because the zero-shot system produced it. The useful framing is that zero-shot classification is how you start and how you handle change, not how you necessarily run a settled high-volume pipeline forever.

Last updated: October 5, 2026