TL;DR
Instead of simply asking the model to "extract such-and-such data from the text," you hand it a detailed blueprint (schema): a list of fields, a description of each field, allowed values (for example, only "positive/negative/unknown"), and explicitly spelled-out nesting, i.e. where there's a list with an unknown number of items and where there's just a key-value pair. The model fills in that blueprint with data from the text in a single request, with no examples.
Models struggle with data extraction when the structure is nested and variable-length. For example, one document may contain one drug and another five, each with its own nested assessment. Without a clear blueprint, the model mixes up which attribute belongs to which object and loses the links between levels of the hierarchy.
The method gives the model the schema right in the prompt text (field descriptions + types + a restricted set of values + nesting structure), and the model extracts data following it like instructions. Separately, to check the result, instead of looking for exact word matches, the model classifies the match on four levels: exact, semantic, "useful enough," and complete mismatch.
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Method Blueprint
STEP 1 (one prompt, no examples):
Model role + task + SCHEMA (fields, descriptions, types, allowed values,
nesting of lists/dictionaries) + document text
→ the model returns structured JSON following that schema
STEP 2 (separate request, to check the result):
Extracted value + reference value + field description from the schema
→ the model classifies the match: exact / semantic / useful / mismatch
Example in Practice
Task: A lawyer is reviewing a stack of supply contracts before signing. Each contract has a varying number of counterparties, and each counterparty has its own list of obligations, penalties and deadlines. Everything needs to go into a single table to compare terms.
Prompt:
You are a legal analyst. Extract information from the contract text strictly according to the following structure.
SCHEMA:
- counterparties: [list, length not known in advance]
- counterparty_name: string (full legal name)
- role: one of ["supplier", "buyer", "agent", "unknown"]
- obligations: [list, length not known]
- description: string (brief summary of the obligation)
- deadline: string in MM/DD/YYYY format, or null if not specified
- penalty_for_breach: string with an amount or condition, or null
Return the result strictly as JSON matching this schema, with no explanations.
CONTRACT TEXT:
{contract_text}
Result: The model returns JSON where each counterparty (there may be 2, there may be 5) has its own list of obligations with dates and penalties. The lawyer gets a single structured format no matter how chaotically a given contract is written, and can merge several contracts into one comparison table.
Why It Works
Without an explicit structure, the model invents the format on the fly, and in complex cases it mixes up which field belongs to which object, especially when two similar entities sit next to each other in the text (two counterparties, two drugs, two candidates).
But the model is excellent at following a clearly defined pattern if you spell it out. It readily recognizes: "here's the list of fields, here's what each one means, here's what you can choose from."
The schema removes ambiguity: the model doesn't decide how to format the answer; it just fills in pre-labeled slots. It's like giving someone not the task "write a report" but a ready-made form with boxes.
Control levers: - Field description (what exactly the attribute means) → the more detailed the description, the more accurately a non-obvious field gets extracted - Restricted list of values (only these options, not free text) → sharply cuts classification errors - Explicit nesting (list vs. plain field) → keeps the model from mixing up what belongs to what - Anchor field for matching lists (e.g., "company name" as an identifier) → helps figure out which item corresponds to which when comparing results
Prompt Template
You are a {expert role in your field}. Extract information from the text strictly according to the following structure (schema).
SCHEMA:
{field_name_1}: {data type, e.g. string/date/number}
- description: {what exactly it means}
- allowed values: {if it's a restricted list, enumerate them}
{field_name_2}: [list, number of items not known in advance]
- {subfield_1}: {description}
- {subfield_2}: [nested list, if you need to go deeper]
Return the result strictly as JSON following this schema, with no explanations or comments.
TEXT:
{source_text}
Once you have the result, to check it against a reference:
Compare the extracted value with the reference value for the field "{field_name}"
(field description: {description from the schema}).
Extracted value: {value_1}
Reference value: {value_2}
Classify the match as one of:
1. Exact match (minimal textual differences)
2. Semantic match (different words, same meaning)
3. Sufficient match (not identical, but the information is useful for {task_goal})
4. Mismatch
Explain your choice in one sentence.
🚀 Quick start — paste into the chat:
Here's a Schema-Guided Extraction template. Adapt it to my task: {your task}.
Ask me questions to fill in the fields.
[paste the template above]
The LLM will ask what data exactly needs to be extracted, which fields repeat (variable count), and whether some fields have a restricted set of values, because without that the schema won't come together correctly, and without a correct schema the nesting and variable item counts won't work.
Limitations
⚠️ Adjacent fields get mixed up: if two different attributes are described in the same sentence or paragraph (for example, "indication" and "usage restriction" appear together), the model may assign part of the information to the wrong field.
⚠️ Subjective and ambiguous assessments: where even a human expert hesitates over the interpretation (e.g., is "efficacy confirmed, but data are limited" a positive or a negative conclusion?), the model errs about as often as a human. The method doesn't solve that problem, it only automates it.
⚠️ Schema quality = result quality: if fields are described vaguely, without format examples and without value restrictions, extraction accuracy drops. The method doesn't work "out of the box" without carefully prepared schemas.
How They Studied It
The researchers took 50 documents from the UK organization NICE (health technology assessment) and manually created a "gold standard": reference data annotated by experts. They gave Claude Opus 3 a prompt with a 14-field JSON schema in which part of the structure was nested (indication → drugs → efficacy assessment, with a variable number of both).
Results were compared not by exact text match but via a model that classified matches on four levels: exact/semantic/useful/mismatch. For 12 of the 14 fields, accuracy exceeded 90%. Two fields did worse, and both turned out to be places where the wording in the source document was itself ambiguous, and the human expert hesitated over the interpretation just as the model did. That's an important insight: the model makes mistakes in the same places that are hard for humans, not at random.
Data extraction took roughly 30 times less time than for a human expert. The method was also tested on other models (Gemini, GPT) and on documents from other countries and in other languages; the schema worked without modification, which points to the approach being universal rather than a lucky break with one model.
Resources
Schema-Guided Hierarchical Information Extraction and Semantic Evaluation Using Generative AI — Modhurita Mitra, Jan-Willem Versteeg, Maarten D. Schermer et al., Utrecht University. Code, prompts and schema are available in an open repository: github.com/UtrechtUniversity/hta-genai