Information Extraction

The Solution: A Detective Finding Clues

Information Extraction (IE) uses LLMs to identify and pull specific pieces of data out of unstructured text — the messy paragraphs in emails, PDFs, contracts, and web pages — and turn them into clean, machine-readable records. For example, from the raw text "The contract between Acme Corp and Bob Smith dated Jan 15 2024 for $50,000..." the model produces structured JSON: { party_a: "Acme Corp", party_b: "Bob Smith", date: "2024-01-15", amount: 50000 }. The two classic subtasks are named entity recognition (tagging the spans that are entities — people, organizations, dates, amounts) and relation extraction (connecting those entities — who signed what, who works where). The goal is almost always a structured output that downstream code can use directly, with no human re-typing.

How it works

In practice you give the model two things: an explicit output schema (the exact field names, types, and which fields are required) and the source text. With a strong instruction-tuned model you can often do this zero-shot, but accuracy jumps when you add a few few-shot examples that cover the edge cases — a missing phone number, two people with the same name, an amount written as "fifty thousand" instead of digits. Modern APIs let you enforce the schema at decoding time (JSON mode / constrained or "structured" output), which removes a whole class of parsing bugs because the response is guaranteed to be valid JSON that matches your shape. Compared with older rule-based systems (regular expressions and hand-written patterns), the LLM generalizes to phrasings it has never seen and handles context — but it costs more per document and is harder to fully predict.

Pitfalls and a worked example

The biggest risk is hallucination: when a field is absent, the model may invent a plausible value instead of leaving it null. The fix is to (1) tell it explicitly to return null for anything not stated, and (2) validate every extracted field against the source text before trusting it. Use IE when the data is recurring and high-volume (thousands of invoices, resumes, support tickets) and a few-percent error rate is acceptable with human review on the uncertain cases. As a concrete example, feed the model the email line "Hi, please reschedule my appointment from Tuesday to next Friday at 3pm, my reference is #A-4471" with a schema { action, old_date, new_date, time, reference }. A good prompt returns { action: "reschedule", old_date: "Tuesday", new_date: "next Friday", time: "15:00", reference: "A-4471" } — notice it normalized "3pm" to 24-hour time but kept the relative dates as written, because resolving "next Friday" to a calendar date needs context the text alone doesn't provide.

Where Is This Used?

• Resume Parsing: Extracting skills, experience, contact info
• Invoice Processing: Pulling amounts, dates, vendor details
• Medical Records: Finding diagnoses, medications, dates
• Contract Analysis: Identifying terms, parties, obligations

Try It Yourself!

Use the interactive example below to extract specific information from different types of text documents.