T5 Task Formatting › Named Entity Recognition as Generation
Language AI HandbookAll chapters T5 Task Formatting › Named Entity Recognition as GenerationOne section · Sections in this chapter5 / 15 ↓
Reading tools Definitions & inline links
Choose your expertise level to adjust how many terms are explained. Beginners see more tooltips, experts see fewer to maintain reading flow. Hover over underlined terms for instant definitions.
Article links
Make inline references clickable
Named entity recognition, as we covered in earlier chapters on sequence labeling, traditionally uses BIO tagging to assign labels to each token in sequence. This approach is elegant for sequence labeling architectures that produce one output per input position. The model reads the input left to right and, at each token, decides its label based on context and the previous label. However, this approach does not naturally fit the text-to-text paradigm where input and output lengths can differ arbitrarily. Converting NER to text-to-text requires reformulating the task: instead of predicting per-token labels, the model generates the entities directly.
This reformulation changes what the model needs to learn. Instead of learning to classify each token independently with CRF dependencies capturing label transitions, the model learns to read the input text, identify entity spans, and express those findings in a structured output format. This is arguably closer to how humans perform entity recognition. We do not mentally label each word as B-PER or I-PER in sequence. We read the sentence as a whole and notice that "Marie Curie" is a person's name, that "Paris" is a location, and that "Nobel Prize" is an award. The generative approach allows the model to discover entities through global comprehension rather than local token classification.
The generative approach also handles a case that BIO tagging handles awkwardly: entities that span discontinuous text, or situations where one entity type overlaps with another in nested structures. In BIO tagging, the standard approach requires either flattening these relationships or using multiple passes. In the generative approach, nested entities can be listed explicitly in the output without any special treatment. The model simply generates the nested structure as part of its output string.
There are two main approaches to formatting NER as text generation, and each makes different tradeoffs between parsability, information preservation, and generation complexity.
Approach 1: Entity Listing
The model generates a structured list of entities and their types. This format separates entity recognition from positional information, focusing purely on what entities exist and what types they belong to. Think of it as asking the model: "What entities are mentioned in this text, and what are they?"
# NER as entity extraction
ner_examples = [
{
"input": "ner: Barack Obama was born in Honolulu, Hawaii.",
"output": "person: Barack Obama, location: Honolulu, location: Hawaii",
},
{
"input": "ner: Apple Inc. announced the iPhone 15 in Cupertino.",
"output": "organization: Apple Inc., product: iPhone 15, location: Cupertino",
},
{
"input": "ner: The patient was prescribed 500mg of ibuprofen.",
"output": "dosage: 500mg, medication: ibuprofen",
},
]Input: ner: Barack Obama was born in Honolulu, Hawaii. Output: person: Barack Obama, location: Honolulu, location: Hawaii Input: ner: Apple Inc. announced the iPhone 15 in Cupertino. Output: organization: Apple Inc., product: iPhone 15, location: Cupertino Input: ner: The patient was prescribed 500mg of ibuprofen. Output: dosage: 500mg, medication: ibuprofen
This format is intuitive and handles overlapping entities naturally, since each entity is listed separately regardless of its position in the source text. The model learns a consistent pattern: type followed by a colon, then entity text, with entities separated by commas. This regularity helps the model generalize to new entity types and new texts, because the structural pattern is consistent across all examples. Adding a new entity type like "medication" or "product" requires only that the training data include examples with that label. No architectural changes are needed, and the model naturally learns to use the new label in the same structural format as all the others.
Approach 2: Inline Markup
Alternatively, entities can be marked inline with special delimiters. This approach preserves the original text structure while adding entity annotations as in-place markup. The output reads like the input text but with entity spans wrapped in type tags.
# NER with inline markup
inline_ner_examples = [
{
"input": "extract entities: Barack Obama was born in Honolulu, Hawaii.",
"output": "[PER Barack Obama] was born in [LOC Honolulu], [LOC Hawaii].",
},
{
"input": "extract entities: Microsoft acquired GitHub for $7.5 billion.",
"output": "[ORG Microsoft] acquired [ORG GitHub] for [MONEY $7.5 billion].",
},
]This approach preserves entity positions in the original text and makes nested entities explicit, but requires careful parsing of the output. The inline format has the advantage of maintaining context around entities, which can help with certain downstream applications where the position or surrounding context matters. For example, relation extraction systems that need to know how two entities are related in the sentence can benefit from the inline representation, which makes the structural relationship visible. However, this approach requires the model to regenerate the entire input with markup added, which is more computationally expensive and introduces more opportunities for the model to make mistakes in recreating the original text.
Handling Edge Cases
The generative approach to NER introduces challenges that traditional sequence labeling does not face. Because the model generates entities as discrete items rather than labeling positions, it must handle various edge cases that require explicit decisions in how you format your training data.
# Edge cases in generative NER
edge_cases = [
# Entity spans multiple mentions of same text
{
"input": "ner: New York hosted the New York Marathon.",
"output": "location: New York, event: New York Marathon",
},
# Nested entities
{
"input": "ner: University of California, Berkeley researchers published...",
"output": "organization: University of California, Berkeley, location: California, location: Berkeley",
},
# No entities
{
"input": "ner: It was a beautiful day.",
"output": "", # Or "none" depending on format
},
]Training data must cover these edge cases consistently for the model to handle them reliably. The format chosen during training becomes necessary. Mixing formats leads to inconsistent outputs. If some training examples list nested entities and others do not, the model will not learn a consistent policy for handling nesting. Practitioners must make deliberate choices about how to handle these edge cases and apply those choices uniformly across training data.
The case of repeated entity surface forms deserves special attention. In the sentence "New York hosted the New York Marathon," both "New York" (as a location) and "New York Marathon" (as an event) contain the substring "New York." A BIO tagger handles this straightforwardly by labeling each token position. The generative approach must decide how to stand for the relationship between the overlapping spans in its output. There is no universally correct answer. The right approach depends on your downstream application and what information you need to extract. The necessary principle is consistency: whatever convention you choose, apply it uniformly in your training data.