Extract, Classify, Generate: Designing a Field Schema for Text Analysis

What this slice covers

The moment that decides whether a content analysis project succeeds is small and early: someone writes down the fields they want. Content Understanding is built around that act. You define a schema, and the service produces values for it — no prompt engineering, no chain of calls, no parsing of free-form prose. But a schema is only useful if each field is declared with the right method, and there are exactly three. This note covers what the three methods mean, how to choose between them, what constraints attach to each, and why the choice determines whether the output is trustworthy.

Why a schema beats a prompt

Consider the alternative. You could ask a language model, in prose, to read an invoice and return the total, the date, and the vendor. It will often work. It will also occasionally return a differently-shaped object, invent a field name, or answer in a paragraph. Your code then needs defensive parsing, and every change to the wording risks changing the output shape.

Declaring a schema inverts that. The shape is fixed by you, the service is responsible for filling it, and the output is a predictable set of key-value pairs. Prompt craft stops being a skill your team must maintain. That reliability is the whole argument.

Method one: extract

Extract means take the value as it literally appears in the content. A date printed on a receipt, a line item on an invoice, a policy number on a form — the value exists in the source and the job is to locate and lift it.

There is an important constraint here that is easy to miss: this method is for documents. It does not apply to every modality, and the reason is intuitive rather than arbitrary. Taking a value as printed is only meaningful when there is a written surface to point at. A value in an audio recording is not printed anywhere.

Extract is the method you should prefer whenever it applies, because verification is straightforward. The value is either in the document or it is not.

Method two: classify

Classify means choose from a set of categories you defined in advance. The sentiment of a call, the type of a chart, the category of an incoming document, the department a request belongs to.

The mental model is that you are constraining the answer space. The service is not writing a label; it is picking one of yours. That is what makes classified output safe to switch on in code — a downstream branch can enumerate the possibilities because you enumerated them.

Classification also plays a structural role beyond producing a field value. Classify a document first and you can route it to the analyzer built for that type, rather than forcing one general-purpose analyzer to cope with everything. A mixed inbox becomes a set of clean, specialised streams. Thinking of classification as a routing decision rather than merely as a field is what turns it from a nice-to-have into an architecture.

Method three: generate

Generate means produce a value that does not appear anywhere in the source. A summary of a conversation, a description of a scene in a video, a one-line characterisation of what a call was about.

This is the method with the most power and the least verifiability. The output is genuinely new text, which means there is no region of the source you can point to and say there it is. Use it where synthesis is the actual requirement, and be deliberate about it. Reaching for generate because a field was hard to extract is a way of converting a visible failure into an invisible one.

How the three interact with confidence and grounding

Each extracted value can carry a confidence score and a grounding reference back to its source region. The value of both varies sharply by method, and understanding that variation is the mark of someone who has actually built with this.

For extracted fields, grounding is precise and confidence is genuinely actionable: set a threshold, automate above it, review below it. For classified fields, confidence tells you how clear-cut the categorisation was, which is exactly the signal you need to flag ambiguous documents. For generated fields, grounding is necessarily looser — a summary draws on the whole source — so human review policy has to be correspondingly more conservative.

Design your review workflow around this gradient rather than applying one threshold to everything.

Choosing an output shape

The last schema decision is what the result looks like leaving the service. Markdown suits search and retrieval destinations, where the goal is readable content that an index or a retrieval workflow can consume. JSON matching your schema suits automation and analytics, where code reads specific keys. Pick according to the consumer, and notice that these serve genuinely different downstream systems.

Mistakes people make

Declaring everything as generate because it always returns something. Using extract on non-document content and being puzzled by the result. Defining classification categories that overlap, so the label is arbitrary. Ignoring confidence entirely and then reviewing all output by hand — which throws away the main benefit. And starting from a blank schema when a prebuilt analyzer for that scenario already exists.