Turning conversations into structured fields.
People speak in prose. A database needs fields. Information extraction is the bridge between them.
Information extraction is the part of machine learning that turns running language, a sentence, an email, a sales call, into the named fields a record can hold: who was on the call, which company they work for, the amount they mentioned, the date they promised, the next step they agreed to. We walk it the way the field is built: what it is, why it is hard, how a modern system does it, what it makes possible, and where it is heading. The papers behind each idea are linked, so you can read the source yourself.
“Acme wants to revisit pricing in early March, with a budget around $40k.”
- Company
- Acme
- Next step
- Revisit pricing
- Timing
- Early March Exact day not stated
- Budget
- About $40,000 Keep the approximation
Turning running language into named fields.
The field name is information extraction. A sentence goes in. Structured items come out: an entity, a relationship, a value that lands in a column.
Open any CRM and you meet the same gap. The information exists. It was said out loud, on calls and in meetings. It just never made it into the right boxes. Information extraction is the part of machine learning that closes that gap, turning a line like "the folks at Acme want to revisit pricing in early March, budget around $40k" into company: Acme · topic: pricing · date: early March (day unknown) · amount: $40,000 · next step: revisit.
The work breaks into a few sub-tasks, named in the order a reader can follow. Find the things: tag the spans of text that are fields, a company, a person, a date, an amount. Find how they connect: read two entities and decide the link between them. Decide what each one really refers to, then pin it to a stored value: "Acme," "Acme Corp," and "the account we talked to Tuesday" may all point to one record, and "early next month" has to become a real date. The output is a record, not a paragraph.
Dana at Acme wants to revisit pricing in early March, with a budget around $40k.
| Field | Extracted value |
|---|---|
| Person | Dana |
| Organization | Acme |
| Budget | About $40,000 |
| Timing | Early March; exact day unstated |
People do not talk in fields.
A fluent sentence is easy for a human and ambiguous for a program. The gap between "a person can tell" and "a program can tell" is the whole problem.
The same thing wears many names.
"Acme," "Acme Corp," "Acme Corporation," and a plain misspelling can all mean one account. Deciding that two records are the same real-world thing, called entity resolution or record linkage, is exactly why CRMs fill with duplicates.
Context decides meaning.
"Apple" is a company in one sentence and a fruit in another. A number could be a budget, a headcount, or a phone extension. "Next Thursday" only resolves against when the call happened. Only the surrounding words settle which is which.
Sometimes you do not know the fields.
Sometimes the schema is fixed and known in advance. Sometimes it is not, and the system has to discover relationships it was never told to look for. Both are harder than tagging a fixed list.
Teaching it is expensive.
Teaching a model what counts as a "mentioned budget" relation traditionally meant humans hand-labeling thousands of sentences. The field spent years finding ways around that cost.
A wrong field is worse than a blank one.
A record that is confidently wrong, the right amount on the wrong account, is more dangerous than a blank field, because a person trusts it. Extraction finding a field is not the same as the field being right. Honest systems keep "I found this" separate from "I am sure of this."
A span is not yet a value.
Finding the phrase "early March" in the text is only half the job. Turning it into a date a column can store, and a company nickname into the right account ID, is the step that makes a field usable.
From a sentence to a record, in stages.
Find the entities, read how they connect, decide what each refers to, then pin it to a stored value. Newer systems fold these steps into one model you prompt.
1Find the things
Tag which words are fields.
Named entity recognition tags spans of text with a type: PERSON, ORG, DATE, MONEY, PRODUCT. This is the "which words are fields" step. The plain picture: the model walks the sentence and, for each word, asks whether it is part of a name, a company, a date, an amount, or nothing.
A standard recipe for this is Lample et al. (2016): a bidirectional LSTM reads the sentence both directions, and a CRF layer keeps the tag sequence consistent so labels do not contradict each other. It is still a clean way to explain "label the spans."
| Span | Entity type |
|---|---|
| Dana | Person |
| Acme | Organization |
| early March | Date expression |
2Find how they connect
Read the link between two things.
Once you have the entities, relation extraction reads two of them and the words between them and decides the link: (Acme, employs, Dana), (Dana, mentioned_budget, $40k). The hard part is training it without hand-labeling every example.
Mintz et al. (2009) introduced distant supervision for this: take pairs you already know are related from an existing database, find sentences that mention both, and treat those as training examples. It traded perfect labels for a lot of free, noisy ones, and is the anchor for how relation extraction got cheap.
Dana works at Acme and mentioned a $40k budget.
(Dana, works_at, Acme)
(Dana, mentioned_budget, about $40k)3When the columns are not given
Extract without a fixed list.
Open information extraction drops the assumption that you know the relations in advance. An early open-extraction system, Banko et al. (2007), the TextRunner work, scanned web-scale text and pulled (entity, relation, entity) triples for relationships nobody specified up front.
The idea that matters for a reader: you do not always get to name the columns ahead of time. Some of the useful things a conversation reveals are links you did not think to ask for.
Marcus signs off on renewals. Acme is evaluating two vendors.
(Marcus, signs off on, renewals)
(Acme, is evaluating, two vendors)4Decide two records are the same thing
Merge the duplicate.
This is the part a CRM reader knows from daily work. "Acme," "Acme Corp," and "Acme Corporation" are three names for one account, and entity resolution is what merges them into one. Mudgal et al. (2018), the DeepMatcher work explored deep learning for deciding whether two records refer to the same entity.
As an industry finding from that paper, the gain concentrated on "textual and dirty" data: exactly the half-filled, inconsistently typed records a real CRM holds, rather than clean benchmark tables. That is the everyday version, the duplicate that splits an account's history in half.
| Mention | Candidate entity |
|---|---|
| Acme | Account 1182 |
| Acme Corp | Account 1182 |
| Acme Corporation | Account 1182 |
Use context or identifiers to confirm the shared account before merging.
5Read the whole passage at once
Hand the transcript to a model, ask for the fields.
Newer methods hand the whole transcript to a large language model and ask for the fields directly, often with few or zero hand-labeled examples. GPT-NER (Wang et al., 2023) reframes tagging as a generation task and adds a self-verification step to catch the model's own over-confident guesses.
The honest note: this is flexible and powerful, and it can still hallucinate a field that was never said. That is why a verification or grounding step matters, and why a trustworthy field should be able to point back at the exact sentence it came from. More on that in Grounding and hallucination.
| Field | Value | Evidence |
|---|---|---|
| Budget | About $40,000 | Explicitly mentioned |
| Next step | Revisit pricing | Explicitly requested |
| Close date | Not stated | No supporting sentence |
6Pin the value to something real
Turn a found span into a stored value.
The last mile is normalization: turning a found span into the value a column can hold. "Early March" becomes a date. "$40k" becomes a number. A company nickname becomes the right account ID. Extraction without normalization gives you spans, not fields.
This step is quiet and easy to skip, and it is the difference between a highlighted phrase and a value a forecast can actually add up. The loose human phrasing on the left becomes the clean stored value on the right.
| Found span | Stored meaning |
|---|---|
| $40k | amount: 40000; currency: USD if established |
| early March | month: March; day: unknown |
| Acme | organization_id: 1182 if resolved |
Clean fields are what everything downstream quietly depends on.
At the field level: records that match, gaps that fill, a pipeline you can trust, and reporting that means something. Garbage fields in, garbage report out.
This family of techniques is how the industry turns spoken language into the clean fields a CRM depends on. Here is what that looks like as an everyday outcome for a seller, stated as outcomes, not as a claim about how any one system is built.
Records that match.
When the field can tell that two spellings are one account, the duplicate stops splitting the history in half. One account, one timeline. The everyday version of the work in connecting records.
Gaps that fill themselves.
A call that mentions a title, a team size, or a renewal date can populate the fields that were blank, without anyone retyping what was just said.
A pipeline you can trust.
When the next step, the amount, and the stage change come off the conversation as fields, a stale deal stops looking healthy just because nobody updated it.
Reporting that means something.
Clean, consistent fields are what every roll-up, forecast, and dashboard quietly depends on. The field exists to remove the boring work of typing what was just said into boxes.
A reminder this page keeps throughout: extraction finding a field is not the same as the field being correct. Everything here describes the field, not the internals of any product.
The direction the field is heading.
We describe the direction, not a roadmap of our own.
From a pipeline to a single model.
The field is consolidating entity, relation, and normalization steps into one model you prompt, rather than a chain of specialized parts. Survey work, Xu et al. (2023), maps this shift toward generative information extraction.
From fixed fields toward proposed ones.
More systems can propose fields and relationships they were not told to look for, while still letting a human keep the schema sane.
Knowing when not to extract.
The frontier is not just extracting more, it is knowing when not to. Self-verification, confidence, and grounding a field back to the exact words that justify it are active work. A field should be able to point at the sentence it came from.
Matching messy records.
Matching the dirty, partial data real systems hold, rather than clean benchmarks, remains a live research area. It is the work that decides whether the duplicate ever really goes away.
Field-level, not just span-level.
Evaluation that asks the question a reader cares about: did it get the amount, the date, and the account right, and onto the right record?
The papers behind this page.
- Lample, Ballesteros, Subramanian, Kawakami, and Dyer (2016). Neural Architectures for Named Entity Recognition. arXiv:1603.01360.
- Mintz, Bills, Snow, and Jurafsky (2009). Distant Supervision for Relation Extraction without Labeled Data. ACL-IJCNLP 2009.
- Banko, Cafarella, Soderland, Broadhead, and Etzioni (2007). Open Information Extraction from the Web (TextRunner). IJCAI 2007.
- Mudgal, Li, Rekatsinas, Doan, Park, Krishnan, Deep, Arcaute, and Raghavendra (2018). Deep Learning for Entity Matching: A Design Space Exploration (DeepMatcher). SIGMOD 2018.
- Wang, Sun, Li, Ouyang, Wu, Zhang, Li, and Wang (2023). GPT-NER: Named Entity Recognition via Large Language Models. arXiv:2304.10428.
- Xu, Wang, Li, et al. (2023). Large Language Models for Generative Information Extraction: A Survey. arXiv:2312.17617.
Keep reading.
Sibling explainers in the Research section.
Talk. Done.
A conversation becomes clean, complete fields, with nothing left to retype. See it on a real call.
No app required. Just your phone number.