Most of the information businesses care about lives in formats machines were never meant to read: emailed invoices, scanned contracts, support transcripts, resumes, product reviews, and meeting notes. The work of converting that prose into rows and columns used to require brittle regular expressions or expensive manual data entry. Language models changed the economics of that work, but only for teams who treat extraction as an engineering discipline rather than a one-off question typed into a chat box.
Prompting for data extraction is the practice of instructing a language model to read unstructured or semi-structured input and return specific fields in a predictable structure. The output might be JSON, a table, or a labeled list, but the goal is always the same: take ambiguous human text and produce a record you can store, query, and trust. Done casually, it produces plausible-looking output that quietly corrupts your database. Done deliberately, it replaces hours of tedious labor with a process that runs in seconds.
This guide covers the full arc of serious extraction work: defining what you actually need, designing a schema the model can hit reliably, writing prompts that reduce ambiguity, handling the values that do not exist, and validating output before it touches a system of record. The thread running through all of it is that extraction is a contract between you and the model, and contracts only work when both sides know the terms.
Start With the Schema, Not the Prompt
The single most common mistake is writing the prompt first and discovering the fields you need afterward. Reverse that order. Decide what the output record looks like before you write a word of instruction.
Define Fields Precisely
For each field, name it, give it a type, and decide whether it is required. "Date" is not a specification; "invoice_date as ISO 8601 string, required" is. Ambiguous field names produce ambiguous output, because the model has to guess what you meant by "amount" when the document shows subtotal, tax, and total.
Choose a Concrete Output Format
JSON is the default for a reason: it is unambiguous, machine-parseable, and supported by structured-output features in most modern models. Specify the exact shape you want and provide it as part of the instruction. A schema the model can echo is a schema the model can fill.
- Use flat structures when you can; nested objects multiply the ways output can go wrong
- Give every field a stable key name that matches your database column
- Decide up front how lists (line items, tags, participants) should be represented
Write Instructions That Remove Ambiguity
Once the schema exists, the prompt's only job is to map the input onto it without leaving room for interpretation. The model is not malicious, but it will fill gaps with guesses unless you tell it not to.
Anchor the Task With Examples
A single worked example of input paired with correct output teaches the model more than a paragraph of description. This is few-shot prompting, and for extraction it is close to mandatory. Show one document and its exact target record, then ask the model to do the same for new input. We cover this in depth in Prompting for Data Extraction: Best Practices That Actually Work.
State the Rules for Missing Data
Tell the model exactly what to do when a field is absent: return null, an empty string, or the literal "not found." Without this rule, models invent plausible values, and a fabricated invoice number is worse than no invoice number at all. Make the absence case explicit and the hallucination rate drops sharply.
Handle the Hard Cases Deliberately
Clean documents are easy. The value of a real extraction pipeline shows up on the messy ten percent: the scanned PDF with smudged numbers, the email that mentions two dates, the contract with a renewal clause buried on page nine.
Disambiguate Competing Values
When a document contains several candidates for one field, give the model a rule for choosing. "If multiple dates appear, return the one labeled as the due date" turns a coin flip into a deterministic decision. The more concrete scenarios in Prompting for Data Extraction: Real-World Examples and Use Cases show how often this single technique decides success or failure.
Preserve Source Fidelity
Instruct the model to extract values as written rather than normalizing them, unless normalization is the explicit goal. A model that "helpfully" converts "$1,200.00" to 1200 may also convert "1,200" meaning twelve hundred euros, silently dropping currency. Extract first, transform in code.
Validate Before You Trust
No extraction prompt is reliable enough to skip validation. The output looks like data, which makes it dangerously easy to insert without checking.
Enforce the Schema in Code
Parse the output and validate it against your schema programmatically. Reject records with missing required fields, wrong types, or values outside expected ranges. This catches the cases where the model returned prose instead of JSON or invented a field you never asked for.
Sample and Audit
For any pipeline running at volume, manually review a random sample of records against their source documents on a recurring basis. Extraction quality drifts as input distributions change, and sampling is how you catch the drift before it becomes a data-quality incident. A structured way to do this lives in The Prompting for Data Extraction Checklist for 2026.
Scale Without Losing Control
A prompt that works on one document and a pipeline that processes fifty thousand are different problems. The leap requires thinking about cost, consistency, and failure handling.
Batch and Monitor
Process documents in batches, log every input and output, and track parse-failure and validation-failure rates as standing metrics. When those rates move, your input changed or the model did, and you want to know immediately rather than after a quarter of bad records.
Pick the Right Model for the Job
Larger models extract more reliably from messy input; smaller models are cheaper and faster for clean, well-structured documents. Match the model to the difficulty of the input rather than defaulting to the most capable option for everything. The trade-offs here are the subject of The Best Tools for Prompting for Data Extraction.
Frequently Asked Questions
What output format works best for extracted data?
JSON is the strongest default because it is unambiguous and natively parseable, and most current models support a structured-output mode that guarantees valid JSON. Specify the exact keys and types you expect. Tables or labeled lists can work for human review, but for anything feeding a system, structured JSON validated in code is the reliable choice.
How do I stop the model from inventing values?
Give an explicit rule for missing data and enforce it. Tell the model to return null or "not found" when a field is absent, provide an example showing that behavior, and then validate the output in code so any fabricated or malformed value is rejected before it reaches your database. The combination of clear instruction and downstream validation is what keeps hallucinated fields out.
Do I need examples in every extraction prompt?
For anything beyond the simplest field, yes. A single worked example pairing a sample input with its correct output dramatically reduces ambiguity and improves consistency. Examples teach the model your conventions for edge cases far more effectively than prose descriptions, which is why few-shot prompting is close to mandatory for production extraction.
How is this different from using regular expressions?
Regular expressions match fixed patterns and break the moment the input varies, which makes them brittle for natural language. Language models understand context and handle variation gracefully, extracting a date whether it reads March 3 or 03/03 or the third of March. The trade-off is that models require validation because they can produce plausible but wrong output, whereas a regex either matches or does not.
Key Takeaways
- Design the output schema before writing the prompt; define every field with a name, type, and required flag
- Default to validated JSON output and provide at least one worked input-output example
- Specify explicit rules for missing data and competing values to prevent fabrication
- Extract values as written and transform in code rather than asking the model to normalize
- Validate every record against the schema programmatically and audit a sample regularly
- Match model size to input difficulty, and monitor parse and validation failure rates as the pipeline scales