How to Write Prompts for Data Extraction

Extraction is the task of pulling specific, named values out of unstructured text — an invoice total, a person's title, a list of skills — and returning them in a fixed shape. The failure modes are predictable: the model invents fields you didn't ask for, guesses a value that isn't actually in the source, changes the JSON key names between runs, or wraps the output in prose that breaks your parser.

Every one of those failures has the same root cause: ambiguity about what "done" looks like. A reliable extraction prompt removes that ambiguity by being explicit on four axes — **which fields**, **what type** each field is, **what shape** the overall output takes, and **what to do when a value is missing**. Nail those four and the model has nothing left to improvise.

Where the platform supports it, prefer a real structured-output mode over asking for JSON in plain text. OpenAI's structured outputs / JSON mode and the equivalent constrained-decoding features described in the Anthropic prompt engineering overview enforce the schema at decode time, so the model literally cannot return malformed JSON. Prompt wording is your second line of defense, not your only one.

Name fields the way you want them in your database, in snake_case or camelCase, and use the exact same names in the instruction and the example. If you call it invoice_total in the schema but Total in the example, the model will pick one at random across runs. Consistency in your own prompt is the cheapest reliability win available.

State the type next to every field: string, number, boolean, ISO-8601 date, or an array of one of those. Numbers are the classic trap — if you don't say number, you'll get "$1,240.00" as a string with a currency symbol and a comma, which your parser then has to clean. Saying **number, no currency symbol, no thousands separator** fixes it at the source.

For categorical fields, give the model a closed list and forbid anything outside it: "priority: one of [low, medium, high]". This is the same enum discipline that powers classification — see our how to write prompts for classification guide for the edge-case handling that applies equally here.

Order matters less than you'd think for accuracy, but keeping the schema, the example, and the requested output in the same field order makes the result far easier to eyeball and diff in review.

The single most important instruction in any extraction prompt is the missing-value rule. Without it, the model fills gaps with plausible-sounding hallucinations — a phone number that looks real but appears nowhere in the source. With it, you get an honest null you can detect and handle.

Pick one fallback convention and state it explicitly: **"If a value is not present in the source text, return null — never guess."** null is preferable to an empty string because it's unambiguous in JSON and easy to filter. For array fields, the empty fallback is [] rather than null, so downstream code can always iterate without a type check.

Add a confidence or evidence field when the cost of a wrong extraction is high. Asking the model to also return the exact source substring it pulled each value from ("quote the span you extracted this from") gives you an audit trail and makes hallucinations obvious — the quoted span won't exist in the source. This is a lightweight, prompt-only form of grounding; for heavier grounding over large corpora see what is RAG.

Never put real personal data, financial records, or confidential documents into a public chatbot to test extraction. Redact identifiers first, or use sample data.

Here is a vague prompt that produces inconsistent, unparseable output:

``` Pull the key details out of this resume: {resume_text} ```

It will return prose, invent fields, and format dates differently every run. Now the schema-first version with types and a fallback:

``` Extract the following fields from the resume below. Return ONLY a JSON object with exactly these keys and types: { "full_name": string, "email": string, // exact email, or null if absent "years_experience": number, // integer, or null if not stated "current_title": string, // most recent role, or null "skills": string[], // empty array [] if none listed "has_security_clearance": boolean } Rules: - If a value is not present in the text, return null. Never guess. - Do not add keys that are not listed above. - No prose, no markdown — JSON only. Example output: {"full_name":"Jordan Lee","email":"jordan@example.com","years_experience":7,"current_title":"Senior Analyst","skills":["SQL","Python"],"has_security_clearance":false} Resume: {resume_text} ```

The difference is night and day: closed key set, explicit types, one example to anchor the shape, and a null fallback that kills hallucinated values. Wire this through a real structured-output mode and the JSON is guaranteed well-formed.

When the source exceeds what fits comfortably in the model's working window, don't paste the whole thing and hope — chunk it. Extract per-chunk into the same schema, then merge. For fields that should appear once (an invoice number), take the first non-null; for list fields (line items), concatenate and de-duplicate. Mind the context window limits of whichever model you choose.

For batch extraction across many documents, keep the schema identical and version it. The moment you change a field name or type, re-run a small golden set of known-answer documents to confirm the change didn't silently break parsing. Reusing a stable schema also lets you cache the instruction portion — see LLM caching strategies — which cuts cost on high-volume jobs.

Model choice matters less than schema discipline here, but for very long or multi-format sources a long-context, multimodal model helps. See how to choose an AI model in 2026 for the trade-offs and check live capabilities on the official model pages.