Named Entity Recognition
Pulling the names, dates and places out of text — reported as solved, and reliably disappointing on anything that isn't news.
When not to use it
- When the entity has a format. Invoice numbers, postcodes, dates in a fixed layout — regex is faster, exact and free.
- When you haven't defined your entities. If two people would disagree about what counts, the model can't do better than the disagreement.
- When you needed entity linking. Knowing "Apple" is an organisation rarely helps. Knowing which Apple does.
- With an off-the-shelf model on specialist text. It knows Person, Org, Location, Date. It doesn't know your domain.
Reach for something else instead
- Regex and rules — for anything with structure. Does more production work than people admit.
- Fine-tuned small encoder — a few hundred labels, and it beats prompted LLMs on your domain, far cheaper.
- Prompted LLM — no training, good on general text, expensive per document.
- Entity linking systems — when you need to know which entity, not just what type.
Sources & further reading
- Tjong Kim Sang & De Meulder (2003), Introduction to the CoNLL-2003 Shared Task — the benchmark that defined the field and dated it.
- Lample et al. (2016), Neural Architectures for Named Entity Recognition — BiLSTM-CRF; the architecture that held for years.
- Ratinov & Roth (2009), Design Challenges and Misconceptions in Named Entity Recognition — the practical difficulties, honestly catalogued.
Primary sources, listed so you can check the claims on this page rather than take them on trust.
Where people go wrong
- Reading 93% on CoNLL as a general capability. That's 1990s newswire, and your documents aren't.
- Using a pretrained model for domain entities it was never trained on.
- Not checking whether your evaluation is strict or lenient on boundaries. It changes the number a lot.
- Reaching for ML when a regex would do.
- Blaming the model for what's actually annotation inconsistency. The ceiling is your labels.