[!NOTE] Tradução automática Este artigo foi traduzido automaticamente a partir da versão original em inglês.

O Guia Definitivo sobre NER em 2026: Codificadores, LLMs e a Arquitetura de Produção em 3 Níveis

O reconhecimento de entidades nomeadas (NER) abrange atualmente codificadores compactos, modelos de vocabulário aberto e extração baseada em LLM. Nos resultados do CrossNER citados, um modelo GLiNER com 300 milhões de parâmetros supera o valor F1 de zero-shot do UniNER de 13 bilhões de parâmetros. Um bi-encoder mais recente apresenta uma capacidade de processamento 130 vezes maior do que o codificador cruzado original, suportando 1.024 tipos de entidades. Estes resultados sustentam um padrão prático para a extração explícita de intervalos: utilizar um LLM para rotular os dados do domínio, analisar uma amostra, fazer um ajuste fino num codificador compacto e, em seguida, implementá‑lo com ONNX ou Rust.

O repositório complementar disponibiliza exemplos executáveis para o GLiNER, a exportação de ONNX, as etiquetas de treino geradas por LLM e a extração estruturada. Em cargas de trabalho dominadas por trechos explícitos, os codificadores compactos oferecem uma solução eficaz em termos de latência e custo. Os LLMs continuam a ser úteis para a criação de dados de treino e para lidar com casos que exigem inferência ou normalização.

Repositório complementar: ner-guia-de-campo, com demonstrações executáveis para o GLiNER, ONNX export, o LLM-as-teacher pipeline, e extração estruturada com o Instructor.

TL;DR: Comece por utilizar o GLiNER quando precisar de extração de trechos com vocabulário aberto e de implementação de CPU. Para tarefas específicas de domínio, teste o método LLM-as-teacher pipeline: gere rótulos, analise uma amostra, faça o ajuste fino de um codificador e avalie-o com um conjunto rotulado manualmente. Encaminhe casos que envolvam entidades implícitas, mapeamento de ontologias e outros processos que exigem grande capacidade de raciocínio para um LLM através de ferramentas como Instructor ou Outlines. A arquitetura em três camadas combina esses fluxos sem impor uma divisão fixa do tráfego.


Onde os sistemas modernos utilizam NER

NER continua a identificar trechos de texto e a atribuir etiquetas a eles. O que mudou foi a sua posição no sistema: agora fornece filtros para RAG, argumentos estruturados para as ferramentas dos agentes, bem como campos para o processamento de documentos pipelines. Essas aplicações tornam a latência, o custo e a flexibilidade do esquema tão importantes quanto a precisão benchmark.

RAG: recuperação mais eficaz graças à extração de entidades

A busca por similaridade sozinha tem dificuldades quando uma pergunta contém entidades exatas. No caso da pergunta “o que a Anthropic disse sobre a segurança de modelos no Q4 de 2024?”, o sistema deve extrair “Anthropic” e “Q4 2024” como filtros de metadados, em vez de se basear apenas em embeddings.

Durante a indexação, extrai-se as entidades de cada bloco e armazenam‑se como metadados: {"organizations": ["Anthropic"], "dates": ["Q4 2024"], ...}. Isto permite filtrar por entidade antes de executar a busca vetorial. O grafo de conhecimento RAG (GraphRAG, grafos de propriedades do LlamaIndex) vai ainda mais longe: através da NER combinada com extração de relações, é criado um grafo capaz de responder a perguntas de vários passos que os embeddings simples não conseguem resolver.

Durante o tempo de consulta, as entidades extraídas da pergunta do utilizador determinam o caminho a seguir. Uma pergunta que menciona o nome de uma empresa é direcionada para um índice financeiro; uma que menciona nomes de medicamentos é encaminhada para uma base de conhecimento clínica. O GLiNER funciona bem nestes casos, pois as entidades das consultas são imprevisíveis — não é possível retreinar o modelo para cada novo tipo de entidade sobre o qual os utilizadores possam fazer perguntas.

AI agentes: transformar texto em factos estruturados

Os agentes recebem texto não estruturado — páginas da web, respostas de API, mensagens de utilizadores — e precisam de agir com base nele. O NER converte esse texto em factos estruturados que o agente pode utilizar para raciocinar, armazenar ou transmitir a ferramentas.

Dois aspetos em que é mais importante.

O primeiro é o roteamento de ferramentas. Quando um utilizador diz “agendar uma reunião com a Sarah Chen da Accenture na quinta-feira às 14h”, o agente precisa de extrair PERSON: Sarah Chen, ORGANIZATION: Accenture, e DATETIME: Thursday 2pm antes de chamar o calendário API. Um modelo encoder NER consegue fazer isso em menos de 10 ms. Um LLM adiciona de 1 a 2 segundos por chamada, e esse atraso se acumula ao longo de fluxos de trabalho com várias etapas, até que um agente “instantâneo” deixe de ser realmente instantâneo.

O segundo aspeto diz respeito ao rastreio de entidades ao longo de conversas. Os sistemas de memória de agente precisam de saber que “Sarah” na turno 3 e “Sra. Chen” na turno 12 são a mesma pessoa. NER identifica os intervalos de texto relevantes; a ligação de entidades associa-os ao mesmo ID.

Em ambos os casos, a restrição principal é a latência. Uma chamada de 200 ms NER dentro de uma cadeia de agentes com 10 passos acaba por gerar um atraso percebido de 2 segundos. É por isso que os modelos codificadores, e não a extração baseada em LLM, constituem a escolha adequada para o processamento de entidades dentro dos ciclos de agente.

Inteligência de documentos: de imagens a dados estruturados

OCR converte imagens em texto. NER transforma texto em campos estruturados. Juntos, permitem a digitalização em larga escala de documentos.

Um pipeline padrão utiliza primeiro OCR, como Tesseract, Azure Document Intelligence ou AWS Textract, para gerar texto e caixas delimitadoras. Em seguida, o NER extrai campos tais como invoice_number, vendor_name, line_items, total, e due_date. A mesma lógica aplica-se a contratos, registos médicos e documentos regulatórios.

As plataformas modernas combinam três etapas: compreensão de layout (trata-se de um cabeçalho ou de uma célula de tabela?), extração de entidades (que tipo de texto é este?) e extração de relações (quais valores pertencem um ao outro?). O GLiNER 2 lida com todas essas etapas numa única passagem forward; uma única chamada ao modelo pode retornar {vendor: "Acme Corp", amount: "\$4,200", due_date: "2026-04-15"} a partir de uma fatura.

É aqui que o custo se torna relevante. Defina o preço do pipeline com base no volume real de documentos por mês, incluindo tentativas de processamento e revisões. Um codificador compacto pode ser executado em CPU, enquanto um LLM baseado em API acarreta custos adicionais de inferência e maior latência por documento. Um teste prático consiste em rotular um conjunto representativo de faturas com um LLM, ajustar o modelo GLiNER com base nos registros revisados e comparar os dois métodos em termos de pontuação F1 a nível de campo, latência e custo total.

Deteção de PII e regras de segurança LLM

As regulamentações de privacidade (GDPR, HIPAA, CCPA) exigem a deteção de dados pessoais antes que estes cheguem aos sistemas subsequentes. No caso das implementações de LLM, isso implica a análise das entradas antes que estas sejam processadas pelo modelo e das saídas antes que cheguem ao utilizador.

NER lida diretamente com isto. Os modelos de desidentificação identificam PERSON, SSN, PHONE, EMAIL, e ADDRESS os spans e, ou bem redigi‑los ou substituí‑los por equivalentes sintéticos. Na sua própria comparação de fornecedores, Os John Snow Labs apresentam os seus relatórios 96% F1 na deteção de PHI, em comparação com o Azure a 91%, o AWS a 83% e o GPT-4o a 79%. Um relatório de implementação separado descreve como o Providence processa mais de 100.000 notas clínicas por dia.

No que diz respeito às restrições definidas por LLM, o NER atua como uma camada de pré-filtragem: ele analisa as entradas dos utilizadores em busca de PII antes de as enviar para um API externo, bloqueando ou anonimizando esses dados posteriormente. Este método é mais rápido e simples do que solicitar que o LLM realize a autoregulação. O GLiNER é particularmente útil nesse contexto, uma vez que as categorias de PII variam consoante a jurisdição. É possível adicionar novos tipos de entidades, como “informações genéticas”, ao abrigo de novas regulamentações, sem ser necessário realizar um retreinamento.


As alterações do GLiNER NER na economia graças a um modelo com 300 milhões de parâmetros

O GLiNER (NAACL 2024, Zaratiana et al.) tornou os métodos baseados em codificador NER competitivos face a LLMs, com um custo significativamente menor. Em vez de tratar NER como rotulagem de sequências ou geração de texto, o GLiNER aborda-o como um problema de correspondência: avalia cada intervalo de texto candidato (cada sequência contígua de palavras, como “Bill Gates” ou “Microsoft”) em relação a cada etiqueta de tipo de entidade, mantendo apenas as combinações com as pontuações mais altas.

O modelo recebe os rótulos de tipo de entidade e o texto de entrada como uma única sequência: [ENT] person [ENT] organization [ENT] date [SEP] Bill Gates founded Microsoft.... Um transformador bidirecional (DeBERTa-v3) codifica tudo em conjunto.

A partir da saída, o modelo cria dois conjuntos de representações: um para os tipos de entidade (a partir de [ENT] uma para as posições dos tokens) e outra para os intervalos de texto (obtida através da combinação dos vetores de token inicial e final por meio de uma pequena rede FFN). O produto escalar entre a representação de um intervalo e a representação do tipo de entidade fornece uma pontuação.

Aplicando a função sigmoide, obtém-se a probabilidade de o intervalo que vai do token ii até ao token jj pertencer ao tipo de entidade tt: ϕ(i,j,t)=σ(SijTqt)\phi(i, j, t) = \sigma(S_{ij}^T \cdot q_t), onde SijS_{ij} é o vetor de intervalo gerado pela FFN e qtq_t é o tipo de entidade embedding correspondente. [ENT] token (Zaratiana et al., 2024, Eq. 1). Os spans têm um limite de 12 tokens para garantir velocidade de processamento.

Arquitetura GLiNER: os tokens de tipo de entidade e os tokens de texto são codificados em conjunto por meio do DeBERTa, sendo posteriormente as representações de span avaliadas em relação ao tipo de entidade embeddings através do produto escalar.

Na prática, isso significa que qualquer descrição em linguagem natural pode ser utilizada como rótulo no momento da inferência. Não é necessário realizar retreinamento. Basta fornecer os tipos de entidades desejados (“pessoa”, “reação adversa a medicamentos”, “instrumento financeiro”), e o modelo avaliará os trechos em relação a eles. Estão disponíveis três tamanhos: GLiNER-S (50M parâmetros), GLiNER-M (90M) e GLiNER-L (300M). Os dados de treinamento provêm do Pile-NER dataset: 44.889 passagens com 240K trechos de entidades abrangendo 13K tipos de entidades, todos rotulados pelo ChatGPT. O treinamento do GLiNER-L leva aproximadamente 4 horas num único dispositivo A100.Zaratiana et al., 2024).

Resultados de Benchmark

Resultados de zero-shot a partir de Zaratiana et al. (2024), Tabelas 1 e 2:

ModeloParâmetrosF1 de CrossNERMédia (20 datasets)
GLiNER-L300 milhões60.9%47.8%
GoLLIE7B58.0%
UniNER-13B13B55.6%
GLiNER-M90 milhões55.4%
UniNER-7B7B53.7%45.7%
GLiNER-S50 milhões52.7%
ChatGPT (GPT-3.5)47.5%36.5%

GLiNER-M, com 90 milhões de parâmetros, quase iguala o UniNER-13B na tabela CrossNER do artigo (55,4% contra 55,6% em F1), utilizando aproximadamente 140 vezes menos parâmetros. A versão GLiNER-S, com 50 milhões de parâmetros, supera o resultado reportado para o ChatGPT (GPT-3.5) em 5 pontos em F1. A variante multilíngue, treinada apenas com dados em inglês, supera essa mesma linha de base do ChatGPT em 8 das 10 línguas diferentes do inglês.Zaratiana et al., 2024). Estas comparações utilizam as versões de modelo e os métodos de avaliação descritos no artigo harness; elas não permitem estabelecer uma classificação em relação a versões mais recentes de LLMs.

O ecossistema é bastante extenso: mais de 280 modelos compatíveis com GLiNER na HuggingFace, cerca de 350.000 transferências via PyPI por mês e aproximadamente 2.800 estrelas no GitHub. As suas variantes abrangem texto biomédico, deteção de PII, notícias e suporte multilíngue.

De quickstart.py:

from gliner import GLiNER

model = GLiNER.from_pretrained("urchade/gliner_medium-v2.1")
text = "Bill Gates founded Microsoft on April 4, 1975."
labels = ["person", "organization", "date"]
entities = model.predict_entities(text, labels, threshold=0.5)

for entity in entities:
    print(f"  {entity['text']} => {entity['label']} ({entity['score']:.3f})")
# Bill Gates => person (0.987)
# Microsoft => organization (0.991)
# April 4, 1975 => date (0.974)

Como o GLiNER se compara com o spaCy

Qualquer guia sobre NER ficaria incompleto sem o spaCyCerca de 21 milhões de transferências por mês, e uma das bibliotecas de NLP mais robustas em ambientes de produção. No entanto, ela opera sob restrições arquitetónicas fundamentalmente diferentes das do GLiNER.

o pipelines do spaCy (en_core_web_sm, en_core_web_trf) no vocabulário fechado NER: um conjunto fixo de tipos de entidade (PERSON, ORG, GPE, DATE, etc.) definido durante o processo de treino. Quer adicionar um novo tipo de entidade? Colete dados rotulados e realize um novo treinamento. O modelo baseado em transformer en_core_web_trf ocorrências 89,8% de F1 em OntoNotes 5.0, mas apenas para os seus 18 tipos predefinidos.

O GLiNER suporta vocabulário aberto NER: qualquer rótulo pode ser utilizado durante a fase de inferência, sem necessidade de retreinamento. Isso torna-o a opção mais adequada quando os tipos de entidades são desconhecidos com antecedência, mudam frequentemente ou são específicos de um determinado domínio (“reação adversa a medicamentos”, “instrumento financeiro”, “indicador de ameaça”).

A minha recomendação é utilizar o spaCy para tipos de entidade padrão, nos quais os modelos pré-treinados pipelines já estão amplamente validados. Recomendo o GLiNER quando se necessita de tipos flexíveis e de abordagem zero-shot, ou quando os seus pipeline precisam de se adaptar sem a necessidade de retreino. Ambos podem partilhar um pipeline, sendo que o spaCy cuida da tokenização e da divisão em frases, enquanto o GLiNER é responsável pela extração de entidades.


UniNER e NuNER: até que ponto é possível reduzir o tamanho?

UniNER (ICLR 2024, Zhou et al.) e NuNER (EMNLP 2024, Bogdanov et al.) ambos convertem as anotações LLM em modelos NER de dimensões mais reduzidas — mas divergem quanto ao limite mínimo de tamanho que é possível atingir.

UniNER: o caminho maximalista

O UniNER realiza ajuste fino no LLaMA-7B/13B com base em 44.889 pares NER (240 mil entidades, 13 mil tipos) gerados pelo ChatGPT. Para cada tipo de entidade, o modelo responde à pergunta “O que descreve [tipo] no texto?” e gera listas JSON. Uma técnica importante de treino é a amostragem negativa baseada em frequência, que eleva o valor do F1 de 31,5% para 53,4%.Zhou et al., 2024).

O UniNER-7B atinge 41,7% de F1 em modo zero-shot em 43 datasets — superando os 34,9% do ChatGPT por 7 pontos. A variante de 13B alcança 43,4%, apenas 1,7 pontos a mais, apesar de exigir quase o dobro de recursos computacionais.Zhou et al., 2024).

O problema de produção: como modelo autoregressivo de 7B, o UniNER necessita de N passagens forward para cada um dos N tipos de entidade, consome 14GB+ VRAM (o que significa que o seu orçamento destinado a GPU já se esgota antes mesmo do almoço), além de contar com uma licença restritiva CC BY-NC 4.0.

NuNER: o caminho minimalista

O NuNER parte de RoBERTa-base (125 milhões de parâmetros) e utiliza treino contrastivo com 4,38 milhões de anotações do GPT-3.5 abrangendo 200 mil conceitos — o custo total das anotações fica abaixo de $500. Após o treino, o codificador de conceitos é descartado; o codificador de texto é integrado em qualquer NER pipeline padrão como substituto da RoBERTa (Bogdanov et al., 2024).

Os resultados: o NuNER supera a RoBERTa simples em 6–15 pontos F1 em todos os tamanhos de poucos exemplos. Com apenas uma dúzia de exemplos por tipo de entidade, o NuNER alcança desempenho semelhante ao UniNER-7B, apesar de ser 56 vezes menor.Bogdanov et al., 2024).

Ambos os artigos demonstram como é possível extrair anotações LLM e transformá‑las em modelos NER de tamanho reduzido. O NuNER prova que um encoder com 125 milhões de parâmetros consegue alcançar os mesmos resultados do UniNER-7B quando existem dados fine-tuning específicos para a tarefa, oferecendo, ainda, licenciamento MIT e capacidade de inferência compatível com CPU.


GLiNER 2: um modelo, quatro tarefas

O ecossistema original do GLiNER enfrentava um problema crescente: a existência de modelos separados para NER (GLiNER), extração de relações (GLiREL), classificação (GLiClass) e extração de relações a nível de documento (GLiDRE) — cada um exigindo a sua própria implementação, contêiner Docker, sistema de monitorização e mecanismos de gestão de falhas. O GLiNER 2 (EMNLP 2025, Zaratiana et al.) integra todos estes componentes num único modelo com 205 milhões de parâmetros, dotado de uma interface orientada a esquemas.

A arquitetura mantém o design de codificador cruzado, mas estende o contexto para 2.048 tokens (4 vezes o valor original) e adiciona esquemas declarativos para definir tarefas de extração. O treinamento utiliza 135.698 documentos reais anotados com o GPT-4o, além de 118.636 exemplos sintéticos.Zaratiana et al., 2025).

Em tarefas de CrossNER sem treino prévio, o GLiNER 2 obtém uma pontuação de 0,590 F1, próxima dos 0,599 do GPT-4o, conforme indicado no artigo referente a meados de 2025 benchmark. Para fins de classificação, a média obtida é de 0,72 em 7 benchmarks, contra 0,69 para o DeBERTa-v3-large. Em termos de CPU, o artigo relata uma latência de classificação entre 130 e 208 ms nas diferentes quantidades de etiquetas testadas. A linha de base do DeBERTa aumenta de 1.714 ms para 5 etiquetas para 16.897 ms quando são utilizadas 50 etiquetas.Zaratiana et al., 2025).

from gliner2 import GLiNER2
extractor = GLiNER2.from_pretrained("fastino/gliner2-base-v1")

# Multi-task composition in ONE forward pass
schema = (extractor.create_schema()
    .entities({"person": "Names of people", "company": "Organization names"})
    .classification("sentiment", ["positive", "negative", "neutral"])
    .relations(["works_for", "founded", "located_in"])
    .structure("product_info")
        .field("name", dtype="str")
        .field("price", dtype="str"))
results = extractor.extract(text, schema)

Para aplicações que necessitam de todas as quatro tarefas, o modelo partilhado pode substituir quatro implementações separadas, mantendo a precisão reportada no artigo original.


O bi-encoder: escalabilidade para milhões de rótulos NER

O GLiNER original codifica rótulos e texto em conjunto — o que cria um gargalo. A existência de mais tipos de entidades resulta numa sequência de entrada mais longa, fazendo com que o desempenho decline rapidamente após cerca de 30 tipos. O GLiNER bi-encoder (fevereiro de 2026, Stepanov et al.; arXiv 2602.18487) resolve este problema ao dividir a codificação de texto e rótulos em dois transformers separados.

Cross-encoder vs bi-encoder: o cross-encoder codifica em conjunto as etiquetas e o texto, enquanto o bi-encoder utiliza encoders separados com etiquetas pré-calculadas embeddings

O codificador de texto utiliza o ModernBERT (família Ettin), enquanto o codificador de rótulos recorre a modelos Sentence Transformer (BGE ou MiniLM). As faixas de texto e os rótulos são avaliados através do produto escalar. A vantagem reside no facto de que o tipo de entidade embeddings pode ser calculado previamente uma única vez e armazenado em cache. Durante a inferência, apenas o texto precisa de ser codificado — a consulta aos rótulos é feita de forma instantânea.

Existem quatro tamanhos de modelo disponíveis, todos avaliados com base no CrossNER (Stepanov et al., 2026, Table 1):

ModeloParâmetrosF1 de CrossNERLargura de banda (H100)Com rótulos pré-computados
bi-edge-v2.060 milhões54.0%13,64 ex/s24,62 ex/s
bi-small-v2.0108 milhões57.2%7,99 ex/s15,22 ex/s
bi-base-v2.0194 milhões60.3%5,91 ex/s9,51 ex/s
bi-large-v2.0530 milhões61.5%2,68 ex/s3,60 ex/s

Com 1.024 tipos de entidades, o bi-encoder (baseado em arestas, pré-computado) perde apenas 5,2% da taxa de processamento em comparação com um único rótulo. O cross-encoder perde 98,7% (de 10,7 para 0,14 ex/s). Isso representa uma vantagem de 130 vezes na taxa de processamento em escala. Com 100 tipos de entidades num único H100, o bi-encoder consegue processar 1,96 milhões de previsões por dia, contra 368 mil para o cross-encoder.Stepanov et al., 2026).

A precisão também se mantém sólida. O Bi-encoder-large atinge um valor de 61,5% em CrossNER F1, ligeiramente acima dos 60,9% obtidos pelo cross-encoder. Os autores recomendam o bi-base-v2.0 (194M) como a opção ideal, conseguindo 98% da precisão do modelo grande com 2,6 vezes mais velocidade.Stepanov et al., 2026).

from gliner import GLiNER

model = GLiNER.from_pretrained("knowledgator/gliner-bi-base-v2.0")

# Pre-compute embeddings for massive label sets — encode once, use forever
entity_types = ["person", "organization", "date"]  # Can be thousands or millions
entity_embeddings = model.encode_labels(entity_types, batch_size=8)

# Inference only encodes text — labels are a cached lookup
outputs = model.batch_predict_with_embeds(texts, entity_embeddings, entity_types)

As aplicações incluem sistemas biomédicos NER baseados na ontologia UMLS (4 milhões+ de conceitos), taxonomias empresariais que evoluem sem a necessidade de retreinamento de modelos, e vinculação de entidades através do componente complementar. GLiNKER framework.


LLMs como instrutores: um estudo de caso de $70 e um pipeline pronto para implementação

O padrão LLM-como-professor separa a anotação, que é um processo dispendioso, da inferência, que é mais económica. Dois estudos de caso publicados demonstram como as equipas o aplicaram em condições distintas.

O LLM-como-professor pipeline: os LLM rotulam os dados brutos, sendo que humanos analisam um subconjunto; em seguida, o codificador é ajustado por treinamento fino e implantado com um custo 80 vezes menor

O estudo de caso do CFM

Num estudo de caso Hugging Face, a Capital Fund Management extraiu nomes de empresas de aproximadamente 900.000 títulos de notícias financeiras. O método Zero-shot GLiNER atingiu uma pontuação de 87,0% em F1. A equipa utilizou o Llama 3.1-70B para anotar os dataset em cerca de 8 horas, por um custo de cerca de 70 dólares, e posteriormente analisou 2.714 amostras através da Argilla em mais 8 horas.

Fine-tuning O GLiNER aplicado a estes dados atingiu um valor de 93,4% F1 no estudo de caso, em comparação com os 92,7% obtidos pelo modelo Llama-70B de referência. Os autores indicam que o custo de utilização do modelo retocado é de $0,10 por hora em CPU, enquanto o modelo de referência custa $8 por hora.Estudo de caso do CFM). Esses valores descrevem uma tarefa relacionada com notícias financeiras e uma configuração de infraestrutura.

O estudo de reabastecimento AI

Atualize o relatório técnico de AI com a rotulagem benchmarks LLM em 8 frameworks de NLP datasets, incluindo o CoNLL-2003. O documento indica uma concordância de 88,4% em relação aos valores de referência para o GPT-4 (março de 2023) e 86,2% entre os anotadores humanos utilizados no teste, além de um processo de rotulagem 20 vezes mais rápido e 7 vezes menos dispendioso. A abordagem baseada em conjunto direciona exemplos fáceis para modelos mais económicos e exemplos complexos para o GPT-4, alcançando mais de 95% de concordância nos experimentos apresentados.Atualizar o relatório técnico de AI). Trate estes resultados como dados reportados pelo fornecedor, de acordo com o protocolo de anotação desse estudo.

Uma produção pipeline

Um fluxo de produção prático possui seis etapas:

  1. Escreva diretrizes de anotação em linguagem natural.
  2. Crie um pequeno conjunto de validação rotulado por humanos (50–200 documentos).
  3. Utilize um LLM (GPT-5.4 Mini, Llama 4 Maverick ou Qwen3.5) para rotular os dados de treino em massa.
  4. Revise um subconjunto dos mesmos. Argila ou Label Studio
  5. Ajustar um codificador compacto (GLiNER, SpanMarker, RoBERTa)
  6. Implante com um custo de inferência 16 a 80 vezes menor

O LLM consegue reduzir o volume de anotação manual, mas a equipa continua a ser responsável pelo conjunto de validação, pelas diretrizes de anotação, pela revisão direcionada e pela análise de erros.


Onde o GLiNER falha e LLMs continua a ser útil

O Sease benchmark (Outubro de 2025) Foi realizado um teste com o GLiNER contra o GPT-4.1-mini em 30 tarefas de análise de consultas. O GPT-4.1-mini obteve 100% de acertos totais. Já o GLiNER alcançou 53% (16 de 30). No entanto, o GLiNER respondeu em 0,08 segundos, contra os 1,21 segundos do LLM — ou seja, 15 vezes mais rápido.

Neste conjunto de 30 tarefas benchmark, o GLiNER falhou em três padrões recorrentes:

  1. Entidades implícitas: extração de “evento” a partir da frase “Elton John performed at Madison Square Garden” — não há texto que diga literalmente “evento”, mas o LLM infere “concerto”;
  2. Sensibilidade na formulação das etiquetas: “2022” obtém uma pontuação de 0,388 quando comparado com “data”, mas de 0,958 quando comparado com “ano” — pequenas alterações nas etiquetas causam grandes flutuações nas pontuações;
  3. Mapeamento de valores: o GLiNER devolve o texto exato apresentado (“family houses”) em vez do valor canónico (“Single family house”). Um LLM consegue realizar essa normalização sempre que o seu prompt e o esquema definirem os valores alvo.

Entidades aninhadas e sobrepostas

O GLiNER também enfrenta dificuldades com entidades aninhadas. Em “New York University”, um humano poderia rotular tanto “New York” (LOCALIZAÇÃO) como “New York University” (ORGANIZAÇÃO). O GLiNER seleciona apenas o intervalo com a pontuação mais alta. Isso é relevante em textos biomédicos (“acute myeloid leukemia” contém tanto uma doença quanto um modificador) e em textos jurídicos (hierarquias organizacionais aninhadas). Modelos especializados conseguem lidar com aninhamentos, mas o design de intervalos planos do GLiNER não o permite.

Utilize o GLiNER para a extração explícita de entidades e direcione os casos que exigem inferência, raciocínio ou mapeamento para ontologias predefinidas para um LLM. O limiar de encaminhamento deve ser determinado a partir de um conjunto de domínios rotulados.


Avaliação de NER: métricas, armadilhas e conjuntos de teste

Um modelo pode atingir uma pontuação de F1 de 95% num conjunto de teste cuidadosamente selecionado e, ainda assim, falhar ao lidar com a mistura de documentos que encontra após a implementação. É necessário construir o conjunto de avaliação a partir da distribuição em produção, mantendo amostras dos formatos e tipos de entidades raros, pois a agregação dos resultados do F1 pode ocultar essas diferenças.

As métricas principais

Erros comuns de avaliação

  1. Inflação por correspondência parcial: É extraído “Bill” quando o rótulo de referência é “Bill Gates” — alguns scripts consideram isto como uma correspondência parcial. Utilize a correspondência exata por intervalo, a menos que haja motivos para o contrário.
  2. Confusão de tipo: “Microsoft” é identificado corretamente como um intervalo, mas se for rotulado como PERSON em vez de ORG, a pontuação deve ser zero. Verifique se o seu código de avaliação lida com este cenário.
  3. Vazamento no conjunto de teste: Se as entidades do conjunto de teste sobrepor-sem às entidades de treino, as pontuações são infladas. Existem métodos zero-shot benchmarks (CrossNER, Few-NERD) para testar a generalização.

Criação de um conjunto de teste para domínio

Para avaliação em produção, recomendo:

  1. Use amostras de dados de produção, e não exemplos selecionados manualmente. Inclua os documentos desorganizados que o seu modelo realmente irá processar.
  2. 200–500 documentos anotados permitem estimativas estáveis para o valor F1. Com menos de 100, os intervalos de confiança ficam excessivamente amplos.
  3. No mínimo dois annotadores, com alto grau de concordância entre eles (Cohen’s kappa > 0,8). Se houver divergências entre humanos, o seu modelo não conseguirá obter resultados melhores.
  4. Estratifique por nível de dificuldade — casos fáceis (texto limpo, tipos padrão) e casos difíceis (entidades ambíguas, jargão, texto ruim).

Produção NER em quatro setores industriais

Aqui estão as implementações de NER mais maduras que encontrei, acompanhadas de valores numéricos específicos.

Saúde Pública

O setor de saúde dispõe da mais avançada infraestrutura de ferramentas NER. A John Snow Labs disponibiliza mais de 2.500 modelos pré-treinados, dos quais mais de 1.200 são destinados ao setor de saúde, abrangendo mais de 400 tipos de entidades clínicas mapeadas para ICD-10, SNOMED CT, LOINC e RxNorm. Na empresa… comparação de fornecedores, os seus modelos de desidentificação atingiram um valor de 96% F1, em comparação com o Azure a 91%, o AWS a 83% e o GPT-4o a 79%. Um estudo de caso separado relata A Providence St. Joseph Health processa diariamente entre 100.000 e 500.000 notas clínicas..

Na sua revisão de projetos de 2025, o código aberto Projeto OpenMed Listam mais de 380 modelos biomédicos NER, 29,7 milhões de downloads Hugging Face, além de resultados de destaque em 10 dos 12 repositórios biomédicos públicos benchmarks.

Financeiro NER

O principal caso de uso é a extração de informações para submissões à SEC. O Finance NLP da John Snow Labs consegue extrair mais de 11 tipos de entidades de documentos 10-K/10-Q (endereços, códigos de ações, exercícios fiscais e bolsas de valores). FinBERT-MRC As variantes atingem um valor de F1 entre 0,87 e 0,93 nas tarefas relacionadas com entidades financeiras. O principal desafio reside nos documentos extensos e nas entidades aninhadas presentes em instrumentos financeiros complexos.

Comércio Eletrónico

da Walmart Sistema EAMT (KDD 2023) treina com 965 milhões de consultas e cerca de 60 rótulos de entidades; o artigo relata um aumento de 0,51% no GMV em testes A/B. Da Home Depot’s TripleLearn framework (AAAI 2021) aumentou o valor de NER F1 de 69,5 para 93,3 através de treino iterativo.

Cibersegurança

O sistema iACE (CCS 2016) processou 71.000 artigos de 45 blogs de segurança, extraíndo 900 mil itens IOC com 98% de precisão e 93% de recuperação. Sistemas modernos como CyNER combine o DeBERTa (F1 >91%) com heurísticas IOC baseadas em regex. O CyberNER O dataset unificado (2025) harmoniza quatro datasets em 21 tipos de entidade alinhados com o padrão STIX 2.1, alcançando um valor de F1 de 0,736 graças ao uso do modelo RoBERTa.


Otimização de deploy: da Python a inferências com menor latência

Testei três métodos para acelerar o GLiNER para ambiente de produção no repositório complementar.

ONNX exportar

O GLiNER dispõe de conversão nativa para ONNX, e existem modelos já convertidos disponíveis no HuggingFace.onnx-community/gliner_small-v2.1). ONNX Runtime proporciona uma aceleração de 1,5 a 3 vezes em CPU em comparação com PyTorch, dispondo de quatro níveis de otimização que vão desde o básico até à precisão mista.

De onnx_export.py:

# Export with quantization
# python convert_to_onnx.py --model_path model/ --save_path onnx/ --quantize True

# Load ONNX model — same API, faster inference
from gliner import GLiNER
model = GLiNER.from_pretrained("path/to/model", load_onnx_model=True)

# Same predict_entities call, 1.5-3x faster on CPU
entities = model.predict_entities(text, labels, threshold=0.5)

INT8 quantização

A quantização dinâmica reduz o tamanho dos modelos em 2,4 vezes (de 438 MB para 181 MB), com uma perda F1 inferior a 0,6%. A velocidade aumenta 1,8 vezes em CPU. Com o uso de CPUs e ONNX Runtime em Intel VNNI, INT8 consegue atingir um ganho de desempenho de até 6 vezes em relação a PyTorch FP32.

from onnxruntime.quantization import quantize_dynamic, QuantType

# One-line quantization — 2.4x smaller, <1% F1 loss
quantize_dynamic("gliner.onnx", "gliner_int8.onnx", weight_type=QuantType.QInt8)

gline-rs: Reimplementação em Rust

gline-rs (Apache 2.0) elimina o overhead do Python. Em CPU: 6,67 sequências/s contra 1,61 do Python — um aumento de velocidade de 4,1x. Em uma RTX 4080: 248,75 sequências/s (gline-rs benchmarks). Ele suporta modelos de span e token, GPU/NPU através de ONNX Runtime, e está disponível como um pacote em crates.io.

use gliner::{GLiNER, TokenMode, Parameters, RuntimeParameters, TextInput};

let model = GLiNER::<TokenMode>::new(
    Parameters::default(), RuntimeParameters::default(),
    "tokenizer.json", "model.onnx")?;

let input = TextInput::from_str(
    &["My name is James Bond."], &["person", "vehicle"])?;
let output = model.inference(input)?;
// => "James Bond" : "person" (99.7%)

O fast-gliner Este pacote disponibiliza bindings em Python através do PyO3 — velocidade de execução Rust aliada à ergonomia do Python.

Resumo da pilha de otimização

OtimizaçãoAceleração versus PyTorchTamanho do ModeloF1 ImpactoMelhor para
ONNX Runtime1,5-3 vezesIdemNenhumUma solução rápida e eficaz, com qualquer hardware
INT8 Quantização3-6 vezes2,4 vezes menorperda de 0,6%CPU de implementação, com restrições de memória
4.1x (CPU)ONNX formatoNenhumAlto rendimento, crítico em termos de latência
gline-rs + INT84-8 vezes2,4 vezes menorperda de 1%Produção em escala

Extração estruturada: Instrutor versus Esboços

Quando é necessário maior flexibilidade do que a oferecida pelos modelos de codificador — entidades implícitas, raciocínio, mapeamento de ontologias — duas bibliotecas permitem a extração estruturada a partir de LLMs.

Instrutor (~12.600 estrelas no GitHub, ~8,8 milhões de downloads/mês em março de 2026) desenvolvido por Jason Liu corrige LLM SDKs para permitir a utilização de modelos de resposta Pydantic, incluindo tentativas automáticas de recuperação em caso de falha na validação. Este projeto suporta mais de 15 fornecedores e serviu de inspiração para a funcionalidade nativa structured output da OpenAI.

De structured_extraction.py:

import instructor
from pydantic import BaseModel
from typing import List, Literal
from openai import OpenAI

class Entity(BaseModel):
    name: str
    label: Literal["PERSON", "ORGANIZATION", "LOCATION"]

class ExtractEntities(BaseModel):
    entities: List[Entity]

client = instructor.from_openai(OpenAI())
result = client.chat.completions.create(
    model="gpt-5.4-mini", temperature=0.0,
    response_model=ExtractEntities,
    messages=[{"role": "user", "content": "BioNTech SE acquired InstaDeep in the U.K."}])
# entities=[Entity(name='BioNTech SE', label='ORGANIZATION'), ...]

Esboços por parte da dottxt é adotada uma abordagem diferente: geração de tokens condicionada através de máquinas de estado finito. O decodificador mascara os tokens que violariam a gramática alvo, em vez de aguardar uma falha de validação e tentar novamente. Em um AWS benchmark, Este caminho atingiu uma adesão ao esquema de 98%, em comparação com 76% na validação pós-geração, e gerou a saída 5 vezes mais rapidamente do que o fluxo de trabalho sem restrições testado, incluindo tentativas de recuperação. O resultado está diretamente relacionado com esse modelo, conjunto de esquemas e configuração de serving.

import outlines

model = outlines.models.transformers("microsoft/Phi-3-mini-128k-instruct")
generator = outlines.generate.json(model, ExtractEntities)
result = generator("Extract entities from: BioNTech SE acquired InstaDeep in the U.K.")

A escolha depende de onde você executa os seus modelos. O Instructor oferece soluções em nuvem LLM APIs um fluxo de validação e tentativa de repetição familiar com Pydantic. Os Outlines restringem a geração local a um esquema definido. Ambos oferecem suporte a NERA extração de estilo, embora a sua latência continue a incluir a geração por modelo autoregressivo. Benchmark qualquer um dos caminhos perante um encoder com o mesmo tamanho de lote, hardware e esquema de entidades.


A arquitetura de produção em três camadas

Eu encaminharia a produção NER com base na estrutura da tarefa, em vez de utilizar a classificação de um único modelo.

Arquitetura de três camadas NER que direciona os trechos explícitos para codificadores, a extração de múltiplas tarefas para o GLiNER 2 e os casos que exigem grande capacidade de raciocínio para LLMs

Nível 1: modelos de codificador para intervalos explícitos. Utilize um cross-encoder GLiNER para conjuntos de rótulos mais pequenos e teste o bi-encoder à medida que o número de rótulos aumenta. Faça o ajuste fino através do LLM-como-professor pipeline, e, em seguida, implemente a solução com ONNX, INT8 ou gline-rs sempre que essas abordagens superarem os requisitos do domínio benchmark.

Nível 2: GLiNER 2 para extração multi-tarefa. Quando um pedido requer NER, classificação, extração de relações e dados estruturados, teste o modelo partilhado do GLiNER 2 com 205 milhões de parâmetros. O artigo científico indica uma latência de classificação de 130–208 ms CPU nas diferentes quantidades de etiquetas testadas.

Nível 3: LLMs para extração com forte componente de raciocínio. Direcione a identificação de entidades implícitas, a inferência contextual e o mapeamento ontológico para um LLM através do Instructor em ambientes cloud APIs ou do Outlines em modelos locais. Registe estes casos, pois constituem candidatos para o próximo conjunto de treino do Nível 1.

O estudo de caso do CFM fornece uma referência de custo para o Nível 1: 93,4% F1 a um custo reportado de $0,10 por hora em CPU, em comparação com 92,7% F1 e $8 por hora para o modelo tutor Llama-70B. Recalcule essa comparação utilizando o seu hardware, modelo tutor e conjunto de rótulos, e analise os custos resultantes.


Compromissos e limitações

Os sistemas ML apresentam sempre compromissos. A questão fundamental é determinar onde esses compromissos surgem e se é possível medi-los antes da implementação.

LLM – os erros de “professor” propagam‑se. Se o LLM identificar de forma consistente um tipo específico de entidade de maneira incorreta (por exemplo, confundir nomes de subsidiárias com nomes de empresas-mãe), o codificador afinado herda esse viés. A solução passa por uma revisão humana direcionada: concentrar os esforços nos tipos de entidade em que a confiança do LLM é baixa ou inconsistente, e não em amostragens aleatórias.

As perdas de quantização não são uniformes. A perda média no F1 de ~0,6% resultante de INT8 pode ser maior em tipos de entidades raras com padrões de fronteira subtis (compostos químicos, abreviaturas de várias palavras). Sempre benchmark modelos quantizados para os seus tipos de entidade específicos, e não apenas com base na média geral do F1.

Quando a arquitetura de três camadas é excessiva. Um único domínio com tipos de entidade estáveis e exemplos suficientemente rotulados pode exigir apenas um modelo RoBERTa ou spaCy pipeline otimizado. O padrão de três camadas é mais adequado para múltiplos domínios, tipos de entidade em constante evolução, ou uma combinação equilibrada entre extração explícita e processos baseados em raciocínio. Uma fatura simples pipeline, que extrai apenas nomes e datas, pode ser processada diretamente na Primeira Camada.

Teto de qualidade do bi-encoder. O bi-encoder sacrifica a atenção conjunta em troca de maior taxa de processamento. Quando as semânticas das etiquetas interagem com o contexto textual (“data”, “ano” ou “período” para o mesmo trecho), o cross-encoder continua a ser a melhor opção. Utilize o cross-encoder para tarefas críticas com baixo número de etiquetas; opte pelo bi-encoder quando se busca maior abrangência.


Referências

Artigos Científicos

Artigos da indústria

Estudos de caso

Ferramentas e frameworks