Named Entity Recognition
Finding amounts, rates, tenures, banks and names in messy speech — and scoring it honestly.
Why this matters
Structured fields drive decisions: the amount sets the product tier, the rate shows whether the agent quoted correctly, the competitor bank is market intelligence. turns noisy speech into those fields.
In transcripts, entities hide behind Hinglish numbers (“pachas lakh”), misspellings (“home lon”), shorthand (“50 L”) and distractors (the *competitor's* rate is not the *offered* rate). And “did we find the entity?” has several defensible answers depending on how you score boundaries.
Core concept
Technical explanation + simple intuition + example
Entities as typed spans
An entity is a stretch of text plus a type: 5 lakh → AMOUNT, 10.5 percent → RATE, 5 years → TENURE. The hard part isn't the type — it's agreeing on exactly which words are included (“around 5 lakh” or “5 lakh”?).
Scoring: strict vs partial matching
If the reference says “10.5 percent” and you tagged “around 10.5 percent”, did you get it right? Strict matching says no (and counts it as one false positive AND one false negative). Partial matching gives credit for overlap with the right type. Which one to use depends on what the downstream code needs.
The 10 questions
Every important concept should answer all of these
1What is it?
Detecting spans of text that refer to entities of predefined types (amount, rate, tenure, bank, person, location, product…) and labelling their type.
2Why does it exist?
Downstream logic needs structured values, not free text.
3What problem does it solve?
It converts unstructured speech into fields that can be validated, aggregated and acted on.
4How does it work internally?
Rules/gazetteers, sequence-labelling models (BIO tagging), or LLMs with schemas; followed by value normalization (“five lac” → 500000).
5What does it look like on real transcript data?
Hinglish and word numbers (pachas lakh, teen saal), shorthand (50 L, PL), misspellings (home lon), competitor mentions, ranges (5-6 lakh), and entities split across turns.
6What can go wrong?
Boundary disagreements, extracting the competitor's rate as the offered rate, missing noisy variants, attributing an agent-mentioned amount to the customer, unit errors (lakh vs crore).
7How do I evaluate it?
Span-level precision/recall/F1 under strict and partial matching, per entity type, plus field-level accuracy after normalization (the value actually used).
8When should I use it?
Whenever decisions depend on specific values or names.
9When should I NOT use it?
Don't tag everything that looks like an entity — define which entities matter for the decision and who said them.
10How does it affect downstream systems?
Entity errors propagate to eligibility, pricing checks, lead scoring and analytics; unit errors are especially costly.
Interactive lab: NER annotation playground
Label entities by selecting spans, compare with the reference under strict and partial matching, and contrast with a transparent rule-based baseline.
Try it yourself
Conceptual (A), applied (B) and engineering (C) exercises
loan_type ("home"), amount (integer ₹), and timeframe (string, verbatim span).Real-world application
A rate-compliance check extracted every RATE entity in a call and compared the maximum against the approved rate card. It flagged 14% of calls as mis-selling. Almost all were false alarms: customers mentioning competitor rates (“Metro Finance 10.5 pe de raha hai”) or agents quoting ranges. The fix added *role* (who said it) and *relation* (whose offer) to the extraction: offered_rate must be spoken by the agent and refer to our product.
Common mistakes
A rate mentioned by the customer about a competitor is not the offered rate.
Fix: Extract (entity, speaker, relation) — e.g., offered_rate vs competitor_rate.
It hides boundary errors that change values (missing 'lakh').
Fix: Report strict and partial, plus field-level accuracy after normalization.
Rules miss noisy variants ('home lon', 'apna business').
Fix: Use rules for high-precision patterns and a model for recall; measure both.
Engineering decision
Rules, a trained NER model, or an LLM extractor?
- Rules: formats are regular (numbers + units, known bank names)
- Trained model: high volume, stable schema, labelled data available
- LLM: few labels, many entity types, need for relations/roles
- Rules alone on noisy ASR text
- LLM extraction without value validation and grounding checks
Quiz
Pass mark 60%. Missed questions go to your mistake log and spaced review.
offered_rate wrong?Advanced challenge
Graded by a transparent keyword rubric (not an LLM) — it checks for the key ideas, then shows a model answer for self-assessment.