Prebuilt Analyzers: Starting From Someone Else's Homework

What a prebuilt analyzer actually is

A prebuilt analyzer is a ready-made analyzer definition published by Microsoft under a reserved identifier that starts with prebuilt-. You call it exactly as you would call your own: name it in an analyze request and send content. Nothing is trained, nothing is deployed, and there is no schema for you to write.

What makes the domain-specific ones interesting is that they are more than a schema someone else typed for you. They are backed by knowledge bases of real-world examples of that document type, so they cope with the layout variation you meet in the wild rather than only the template the schema was designed against. This is the practical reason a prebuilt invoice analyzer usually beats a hand-written one on the first day.

The five families, and why the split matters

The catalogue is easier to hold in your head as families rather than as a list of names.

Content extraction analyzers do reading and layout, with no field extraction and no generative model involved at all. Basic text recognition, richer layout with paragraphs, tables, figures and annotations, and a variant that reads a file's internal structure directly for machine-readable documents. Because these need no language model, they are the cheap, deterministic end of the catalogue.

Base analyzers are the four modality parents — document, audio, video, image — whose job is to be inherited from when you build custom analyzers. They are not really meant to be called directly for business outcomes.

Retrieval analyzers are tuned for search and retrieval-augmented generation. The document one produces markdown with figure descriptions, chart and diagram structure, annotations, a whole-document summary, and chunked output ready for embedding. There are equivalents for images, audio and video. If your goal is to feed an index, start here rather than designing fields.

Domain-specific analyzers cover recognisable business documents: invoices, receipts and purchase orders; a large family of United States tax forms; contracts; identity documents and passports; bank statements, checks and credit memos; mortgage packages; pay stubs and utility bills; and call recordings.

Utility analyzers are the odd, useful pair: one proposes a field schema for a document type you have never seen, and one extracts generic key-value pairs when a document does not match a predefined schema.

Composed analyzers do the routing for you

Several prebuilt identifiers are not extractors at all but routers. The procurement, tax and mortgage entries classify an incoming document and hand it to the right specialised analyzer. That composition is exactly the pattern you would otherwise build yourself with content categories, packaged and named.

This is worth recognising because a common design instinct — write a classifier, then a switch statement, then call the right analyzer — is already solved for these families. Reach for a composed prebuilt before you build a router.

The workflow: read, copy, adapt

The intended path is not to choose between prebuilt and custom but to move along a line between them. Retrieve a prebuilt analyzer's definition with a GET on its identifier. You get back its configuration and field schema as JSON. Read it — this is the best available worked example of schema design. Edit what you need, and create it under your own identifier.

The production discipline that follows is the point most learners miss. Prebuilt definitions can change between API versions, which means the analyzer you tested against is not guaranteed to be the analyzer you run against next quarter. The service offers a copy operation that snapshots a prebuilt analyzer into one of your own with a fixed definition, and the documentation is explicit that production workloads should do this rather than call the prebuilt directly.

Think of it as pinning a dependency version. You would not ship an application that floats to whatever version of a library happens to be published; the same reasoning applies here.

Choosing badly, and how to notice

Three mistakes recur.

Picking a reading analyzer when you needed layout. If your downstream chunking depends on section headers and table boundaries, plain text recognition throws away exactly the structure that makes retrieval work.

Assuming a domain analyzer covers your fields. Prebuilt schemas are generous but they are not yours. When a needed field is missing, the answer is to copy the definition and add the field, not to abandon the prebuilt and write a schema from scratch.

Using a prebuilt where the content is not what its name implies. The identifiers describe semantic document types, not file formats. A photograph of a receipt is still a receipt; a spreadsheet of invoice totals is not an invoice.

Where the exam pressure sits

Expect to be asked to match a scenario to a starting point: ingest a library of PDFs for a chat experience, process supplier invoices, split a mortgage package, transcribe and summarise support calls. The answer is almost always a named prebuilt family rather than a custom build, and where a custom analyzer is warranted, it usually begins as a copy of the closest prebuilt one.