Reconhecimento de Entidades Nomeadas

Visão geral

Reconhecimento de Entidades Nomeadas (Named Entity Recognition, NER) é uma tarefa central em Processamento de Linguagem Natural (Natural Language Processing) que detecta trechos de texto que se referem a “entidades” e classifica cada trecho em um tipo de entidade como Pessoa, Organização ou Localização. O NER é um bloco fundamental para extração de informação (information extraction), compreensão de documentos, busca e muitos fluxos de trabalho posteriores — especialmente em domínios de alto risco como revisão de documentos jurídicos (legal document review), em que identificar partes, tribunais, estatutos e datas é essencial.

Em alto nível, o NER responde a duas perguntas:

  1. Onde estão as entidades? (detecção de trechos)
  2. Que tipo de entidades elas são? (classificação de tipo)

Exemplo:

“Apple hired Tim Cook in California.”

Saída de NER (um esquema possível):

  • Apple → ORG
  • Tim Cook → PERSON
  • California → LOCATION

O NER é frequentemente formulado como um problema de rotulagem de sequência (sequence labeling) (ver Rotulagem de Sequência (Sequence Labeling)), mas sistemas modernos também usam classificação baseada em spans (span-based classification) e abordagens generativas (generative) com modelos Transformer (transformer models) e modelos de linguagem grandes (large language models, LLMs).

O que conta como uma “entidade”?

Uma entidade é tipicamente um objeto ou conceito do mundo real que pode ser nomeado, referenciado e, muitas vezes, vinculado a uma representação canônica (por exemplo, uma entrada em um banco de dados).

Tipos comuns de entidades

Tipos comuns de NER “granularidade grossa” (coarse-grained) (típicos em conjuntos de dados de propósito geral):

  • PERSON: “Ada Lovelace”
  • ORG: “OpenAI”, “U.S. Securities and Exchange Commission”
  • LOC / GPE (localização / entidade geopolítica): “Paris”, “California”, “Germany”
  • DATE / TIME: “January 7, 2026”, “3:00 PM”
  • MONEY / PERCENT: “$10 million”, “15%”

NER específico de domínio frequentemente usa taxonomias mais especializadas:

Exemplos de NER jurídico

  • PARTY (autor/réu), JUDGE
  • COURT, CASE_NUMBER / DOCKET
  • STATUTE / REGULATION, LEGAL_CITATION
  • CONTRACT_CLAUSE, OBLIGATION, EFFECTIVE_DATE
  • ADDRESS, JURISDICTION

O conjunto de rótulos adequado é uma decisão de produto tanto quanto uma escolha de modelagem: ele deve corresponder ao que os usuários a jusante precisam.

Casos difíceis: entidades aninhadas, sobrepostas e descontínuas

O NER fica mais difícil quando as entidades:

  • São aninhadas: “University of California” (ORG contém LOC)
  • Se sobrepõem: “New York” pode ser uma cidade ou um estado dependendo do contexto
  • São descontínuas (menos comum em benchmarks padrão): “Bank … of America”

Muitos benchmarks clássicos de NER assumem trechos contíguos e sem sobreposição, mas textos jurídicos e biomédicos do mundo real podem violar essas suposições.

Esquemas de rotulagem (BIO, BIOES, BILOU)

A maioria dos conjuntos de dados de NER converte spans em rótulos em nível de token (token-level tags) usando um esquema de rotulagem. O mais comum é o BIO (também chamado IOB2):

  • B-XXX: início de uma entidade do tipo XXX
  • I-XXX: dentro de uma entidade do tipo XXX
  • O: fora de qualquer entidade

Frase de exemplo:

“Tim Cook joined Apple in 1998.”

Tags BIO em nível de token:

Token Tag
Tim B-PER
Cook I-PER
joined O
Apple B-ORG
in O
1998 B-DATE
. O

Outros esquemas comuns:

  • BIOES: adiciona E (fim) e S (entidade de um único token)
  • BILOU: Begin, Inside, Last, Outside, Unit

Esses esquemas podem melhorar a acurácia de fronteiras porque codificam explicitamente finais de entidades e entidades de um único token.

A tokenização importa (especialmente com Transformers)

Modelos modernos dependem de tokenização (tokenization) por subpalavras (ver Tokenização (Tokenization)), que pode dividir uma palavra em partes. Rótulos de NER geralmente são definidos no nível de palavra, então implementações precisam decidir como alinhar rótulos às subpalavras (estratégias comuns: rotular apenas a primeira subpalavra ou propagar rótulos pelas subpalavras de forma consistente).

Abordagens de modelagem

O NER avançou por várias gerações de métodos. Na prática, a melhor escolha depende da disponibilidade de dados, complexidade do domínio, restrições de latência e do quanto o sistema precisa ser explicável ou controlável.

Sistemas baseados em regras e dicionários (gazetteers)

Antes do aprendizado de máquina (machine learning), o NER era frequentemente construído usando:

  • Padrões de expressão regular (regex) (datas, números de processo, citações)
  • Listas de entidades (gazetteers) (listas de organizações conhecidas, tribunais, países)
  • Heurísticas (capitalização, sufixos como “Inc.”, “LLP”)

Prós:

  • Alta precisão para entidades bem estruturadas (por exemplo, citações jurídicas)
  • Fácil de depurar e de impor restrições de política

Contras:

  • Baixa revocação para entidades novas
  • Frágil a variações de formatação e erros de OCR
  • Difícil escalar para novos domínios/idiomas

Na prática, regras continuam valiosas como pós-processamento (post-processing) ou como sinais de supervisão fraca (weak supervision) (ver Supervisão Fraca (Weak Supervision)).

Campos Aleatórios Condicionais (CRF)

Um grande avanço foi modelar NER como rotulagem de sequência com Campos Aleatórios Condicionais (Conditional Random Fields, CRF) de cadeia linear (ver Campos Aleatórios Condicionais (Conditional Random Fields)).

Ideia-chave:

  • Prever a melhor sequência de tags para a frase inteira, e não de forma independente por token.
  • CRFs modelam dependências como “I-ORG não pode vir após B-PER”.

Um CRF tipicamente usa atributos projetados manualmente, como:

  • Palavra atual e palavras ao redor
  • Forma da palavra (capitalização, dígitos, pontuação)
  • Prefixos/sufixos
  • Tags POS (opcional)

Prós:

  • Forte predição estruturada (structured prediction): sequências de tags coerentes
  • Eficiente em dados em comparação com grandes modelos neurais

Contras:

  • Custo de engenharia de atributos (feature engineering)
  • Poder de representação limitado em comparação com Transformers

Rotuladores neurais de sequência (BiLSTM-CRF)

Modelos neurais melhoraram CRFs ao aprender atributos automaticamente usando redes recorrentes (por exemplo, LSTM bidirecional (BiLSTM)). Uma arquitetura popular era:

Embeddings de palavras (word embeddings) → BiLSTM → decodificador CRF

A camada CRF impõe transições válidas, enquanto a BiLSTM aprende representações contextuais de tokens.

Prós:

  • Menos engenharia de atributos
  • Forte desempenho em benchmarks clássicos

Contras:

  • Frequentemente superado por Transformers hoje
  • Treinamento/inferência pode ser mais lento do que classificadores simples por token (embora ainda prático)

NER baseado em Transformer (classificação de tokens)

A maioria dos sistemas de NER estado da arte hoje faz ajuste fino (fine-tuning) de um Transformer pré-treinado (pretrained) (ver Arquitetura Transformer (Transformer Architecture)):

Codificador Transformer → classificador em nível de token (função softmax (softmax))

Backbones comuns: BERT, RoBERTa, DeBERTa, variantes de BERT específicas de domínio (por exemplo, modelos no estilo legal-BERT).

Por que Transformers funcionam bem:

  • O pré-treinamento captura padrões linguísticos e factuais amplos
  • Embeddings contextuais (contextual embeddings) reduzem ambiguidade (“Apple” a empresa vs fruta)
  • O ajuste fino adapta as representações ao seu conjunto de rótulos

Um aprimoramento comum é Transformer + CRF, combinando representações fortes com decodificação estruturada.

Nota prática: a maioria das implementações de NER com Transformer prediz rótulos de token de forma independente (softmax por token). Adicionar uma cabeça CRF pode melhorar a consistência de fronteiras, especialmente em domínios ruidosos.

NER baseado em spans

Em vez de rotular tokens, o NER baseado em spans enumera spans candidatos (dentro de um comprimento máximo) e classifica cada span:

  • Predizer (início, fim, rótulo)
  • Útil para entidades aninhadas e esquemas de anotação mais complexos

Trade-offs:

  • Mais caro computacionalmente (muitos spans candidatos)
  • Pode representar estruturas mais ricas do que a rotulagem BIO

NER generativo e baseado em LLM

LLMs podem realizar NER por:

  • Elaboração de prompts (prompting) (“Extract persons and organizations as JSON…”)—ver Engenharia de Prompts (Prompt Engineering)
  • Extração sequência a sequência (sequence-to-sequence) com ajuste fino (gerar saídas estruturadas)

Prós:

  • Prototipagem rápida sem dados rotulados
  • Pode lidar com esquemas complexos e estruturas aninhadas

Contras:

  • Mais difícil garantir consistência e formatação estrita
  • Pode alucinar (hallucinate) entidades ou perder spans sutis
  • Avaliação e calibração podem ser mais difíceis do que em modelos clássicos de rotulagem

Em fluxos regulados (como revisão jurídica), extração baseada em LLM frequentemente precisa de salvaguardas (guardrails), validação e revisão humana.

Métricas de avaliação

A avaliação de NER geralmente é em nível de span, não em nível de token: uma entidade prevista só é correta se suas fronteiras e tipo coincidirem com o ground truth (a menos que se usem métricas de correspondência parcial).

Precisão, revocação e F1

Defina:

  • VP = entidades previstas que correspondem exatamente a uma entidade gold (span + tipo)
  • FP = entidades previstas que não estão no gold
  • FN = entidades gold não previstas

Então:

  • Precisão (precision) = VP / (VP + FP)
  • Revocação (recall) = VP / (VP + FN)
  • F1 = 2PR / (P + R)

A maioria dos relatórios usa F1 microagregado (micro-averaged F1) em todas as instâncias de entidades (comum em benchmarks como CoNLL).

Correspondência exata vs correspondência parcial

  • Correspondência exata (exact match) (estrita): fronteiras + tipo devem corresponder
  • Correspondência parcial (partial match): dá crédito por sobreposições (útil para anotação ruidosa ou entidades longas)
  • Acurácia em nível de token (token-level accuracy): às vezes reportada, mas pode ser enganosa (muitos tokens são “O”)

Para NER jurídico, métricas de correspondência parcial podem ser úteis durante o desenvolvimento, mas a aceitação em produção geralmente exige correspondência estrita (por exemplo, extrair o nome completo da parte).

Casos especiais

  • Entidades aninhadas: exigem avaliação especializada se as anotações permitirem aninhamento
  • Normalização/vinculação de entidades: avaliada separadamente (acurácia da atribuição de ID canônico)

Para um contexto mais amplo sobre como medir a qualidade de modelos, ver Métricas de Avaliação (Evaluation Metrics).

Considerações práticas (o que importa em produção)

Qualidade de dados e diretrizes de anotação

O desempenho de NER costuma ser limitado mais pela consistência de anotação do que pela escolha de modelo. Passos de alto impacto:

  • Definir regras claras de fronteira (incluir títulos? “Judge Smith” vs “Smith”)
  • Especificar escopo da entidade (“the Company” é uma menção ORG?)
  • Decidir como rotular citações e abreviações
  • Acompanhar concordância entre anotadores e resolver discordâncias sistemáticas

Em texto jurídico, ambiguidades são comuns:

  • “Plaintiff” como papel vs uma menção a uma parte específica
  • Termos definidos (“Effective Date means…”) em que a capitalização sinaliza significado
  • Artefatos de reconhecimento óptico de caracteres (OCR) que quebram tokens e pontuação

Adaptação de domínio

Um modelo treinado em NER de notícias (por exemplo, CoNLL-2003) frequentemente tem desempenho ruim em documentos jurídicos porque:

  • O vocabulário difere (“hereinafter”, “indemnify”, “§ 2.1”)
  • As entidades diferem (estatutos, citações de casos, cláusulas)
  • A formatação difere (cabeçalhos, rodapés, enumerações, PDFs escaneados)

Estratégias comuns de adaptação (em esforço crescente):

  1. Fazer ajuste fino em um pequeno conjunto rotulado do domínio
  2. Continuar o pré-treinamento (continue pretraining) em texto não rotulado do domínio (pré-treinamento adaptado ao domínio (domain-adaptive pretraining))
  3. Usar aprendizado ativo (active learning) para rotular os exemplos mais informativos (ver Aprendizado Ativo (Active Learning))
  4. Adicionar regras/gazetteers para padrões de alta precisão (números de processo, datas)
  5. Usar supervisão fraca para iniciar (bootstrap) rótulos (ver Supervisão Fraca)

Uma abordagem prática em revisão jurídica é um pipeline híbrido: NER com Transformer para spans gerais + extratores baseados em regras para formatos de citação.

Design da taxonomia de rótulos (mantenha útil)

Conjuntos de rótulos excessivamente detalhados podem reduzir a acurácia e complicar a anotação. Uma estratégia comum:

  • Começar com tipos grossos (PARTY, COURT, STATUTE, DATE)
  • Adicionar subtipos de maior granularidade apenas quando as necessidades a jusante estiverem claras
  • Considerar um sistema em duas etapas: NER grosso → classificação de subtipo

Lidando com desbalanceamento de classes e entidades raras

Em corpora jurídicos, algumas entidades são raras (por exemplo, certos tipos de regulamentação). Técnicas:

  • Oversampling ou coleta de dados direcionada
  • Função de perda com pesos por classe
  • Aumento de dados (com cuidado; evitar gerar texto jurídico inválido)
  • Aprendizado ativo com foco em classes de baixa frequência

Análise de erros e depuração

Recortes úteis para inspecionar:

  • Erros de fronteira vs erros de tipo
  • Confusões entre tipos semelhantes (ORG vs COURT; GPE vs localização de COURT)
  • Desempenho por seção do documento (caption vs corpo vs blocos de assinatura)
  • Faixas de qualidade de OCR (alta vs baixa confiança)

Normalização de entidades (e por que NER sozinho muitas vezes não é suficiente)

NER identifica menções; muitos fluxos de trabalho exigem mapear menções para uma forma canônica — frequentemente chamado normalização de entidades (entity normalization) ou vinculação de entidades (entity linking) (ver Vinculação de Entidades).

Exemplos:

  • “IBM”, “I.B.M.”, “International Business Machines” → um registro ORG canônico
  • “Cal. Civ. Code § 1542” → forma normalizada de citação de estatuto
  • “Hon. Jane Smith”, “Judge Smith” → identidade canônica de pessoa (se resolvível)

A normalização é crucial em revisão jurídica para:

  • Deduplicar partes entre documentos
  • Agregar menções em visões centradas no caso (matter-centric)
  • Apoiar busca e analytics (“mostrar todos os documentos que referenciam o estatuto X”)

Técnicas comuns de normalização:

  • Canonicalização de strings (string canonicalization): normalização de caixa (case folding), remoção de pontuação, normalização de espaços em branco
  • Dicionários / listas de autoridade (authority lists): tribunais conhecidos, clientes conhecidos, listas de reguladores
  • Correspondência aproximada (fuzzy matching): distância de edição (edit distance), razões de conjunto de tokens (token set ratios)
  • Recuperação baseada em embeddings (embedding-based retrieval): similaridade semântica (semantic similarity) com entidades candidatas
  • Regras para citações: analisar (parse) citações em campos estruturados (nome do código, seção, ano)

Em sistemas maduros, NER alimenta um pipeline mais amplo de Extração de Informação e, às vezes, de Grafos de Conhecimento (Knowledge Graphs).

Exemplo: NER em um fluxo de revisão de documentos jurídicos

Considere um corpus de contencioso com PDFs convertidos em texto. Um pipeline prático pode se parecer com:

  1. Extração e limpeza de texto
    • OCR quando necessário
    • Remover cabeçalhos/rodapés ou marcá-los como zonas
  2. Rotulagem de NER
    • PARTY, COURT, JUDGE, CASE_NUMBER, DATE, STATUTE, ADDRESS
  3. Pós-processamento
    • Corrigir spans quebrados por quebras de linha
    • Impor regras de formatação para citações/números de processo
  4. Normalização
    • Canonicalizar nomes de partes (lidar com sufixos como “LLC”, “Inc.”)
    • Normalizar referências a estatutos
  5. Indexação / UI de revisão
    • Destacar entidades nos documentos
    • Fornecer filtros (“documentos que mencionam Judge X”)
  6. Humano no loop (human-in-the-loop)
    • Revisar e corrigir entidades
    • Realimentar correções no conjunto de dados de treinamento

Essa combinação tende a ser mais robusta do que “apenas rodar um modelo”, especialmente com ruído de OCR, formatação inconsistente e requisitos estritos de acurácia.

Exemplo prático mínimo (inferência de NER com Transformer)

Usando Hugging Face Transformers para classificação de tokens:

from transformers import pipeline

ner = pipeline(
    "token-classification",
    model="dslim/bert-base-NER",
    aggregation_strategy="simple"  # groups subword tokens into spans
)

text = "Apple hired Tim Cook in California."
print(ner(text))

Uma saída típica é uma lista de spans extraídos com rótulos e escores de confiança. Em produção, você geralmente:

  • mapeia rótulos para o seu esquema,
  • aplica regras de pós-processamento,
  • opcionalmente direciona previsões de baixa confiança para revisão humana.

Nota de treinamento

O ajuste fino requer um conjunto de dados com rótulos em nível de token alinhados ao tokenizador do modelo. Muitas equipes usam bibliotecas como 🤗 Datasets + Trainer, ou spaCy para pipelines ponta a ponta de anotação e treinamento.

Armadilhas comuns

  • Tokenização e rótulos desalinhados: subpalavras podem corromper silenciosamente rótulos de treinamento se não forem tratadas com cuidado.
  • Fronteiras de anotação inconsistentes: inconsistência ao rotular “U.S.” vs “U.S. District Court” pode limitar o desempenho.
  • Dependência excessiva de pontuações de benchmark: um modelo com alto F1 no CoNLL pode falhar gravemente em contratos ou petições.
  • Ignorar normalização: extrair menções sem canonicalização frequentemente não atende às necessidades do fluxo de trabalho.
  • Ruído de OCR e formatação: quebras de linha, hifenização e artefatos de digitalização podem dominar os erros.

Tarefas relacionadas e onde NER se encaixa

NER é frequentemente usado junto com:

Resumo

O Reconhecimento de Entidades Nomeadas identifica e classifica spans de entidades em texto. Enquanto o NER clássico é frequentemente implementado como rotulagem de sequência com tags BIO usando CRFs ou rotuladores neurais, sistemas modernos em produção tipicamente dependem de ajuste fino com Transformers, às vezes aprimorado com decodificação CRF, métodos baseados em spans para aninhamento e componentes baseados em regras para padrões de alta precisão.

Para fluxos reais — especialmente revisão de documentos jurídicos — o sucesso depende tanto de diretrizes de anotação, adaptação de domínio e normalização quanto da arquitetura do modelo. O NER é mais valioso quando integrado a um pipeline ponta a ponta que produz entidades consistentes e canônicas nas quais sistemas a jusante e revisores possam confiar.