Guia de NER 2026: GLiNER, spaCy, Transformers e LLMs

Viacheslav Dubrov

2026-04-02 · Atualizado 2026-09-06 · 43 min · Sistemas de recuperação e linguagem

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

Atualização do artigo

Publicado originalmente em 2 de abril de 2026. Revisto e atualizado em 6 de setembro de 2026. A atualização abrange modelos GLiNER mais recentes, deteção de PII em streaming, APIs de extração estruturada e interpretação de benchmarks.

O reconhecimento de entidades nomeadas (NER) transforma texto em fragmentos etiquetados que um programa pode utilizar. Dado “Bill Gates founded Microsoft on April 4, 1975,” pode devolver os spans de texto contíguos Bill Gates, Microsoft e April 4, 1975, com os tipos pessoa, organização e data. Num encoder baseado em spans, como o GLiNER, o modelo lê o texto uma vez e atribui pontuações a spans candidatos face às etiquetas fornecidas. Escolher um sistema de NER implica decidir quanta latência, custo, flexibilidade de etiquetas e raciocínio essa extração exige.

O repositório complementar fornece exemplos smoke test para GLiNER, exportação para ONNX, geração de anotações e extração estruturada. A comparação com três frases não é um ranking de modelos: o scorer agrega pares de texto/tipo repetidos e pode ignorar documentos gold no fim quando faltam previsões. O script do teacher também não demonstra uma conversão para spans de treino revistos. Utilize estes exemplos para inspecionar APIs, não para afirmar que existe um workflow completo de treino ou avaliação. Para workloads dominados por spans explícitos, os encoders compactos são normalmente a opção mais rápida e barata. Os LLMs continuam a ser úteis para produzir dados de treino e tratar casos que exigem inferência ou normalização. As secções de benchmark explicam as comparações publicadas e as respetivas limitações; nenhuma corresponde a uma nova execução de benchmark para este guia.

Para um pipeline de retrieval ou privacidade, começaria por perguntar se o output tem de ser uma menção literal. Essa decisão separa um reconhecedor de spans de sistemas que também normalizam valores, associam registos ou inferem factos.

Repositório complementar: ner-field-guide, com demos executáveis para GLiNER, exportação para ONNX, o pipeline LLM-as-teacher e extração estruturada com Instructor.

Para uma comparação breve de modelos, consulte Melhores modelos de NER em 2026.

O que é o reconhecimento de entidades nomeadas?

O reconhecimento de entidades nomeadas encontra spans no texto e atribui-lhes tipos como pessoa, organização, data, produto ou etiquetas específicas do domínio. Um span é um fragmento contíguo do texto original. O NER identifica a menção; o entity linking é o passo separado que a associa a um registo canónico ou a um conceito de ontologia.

Onde os sistemas modernos utilizam NER

O NER continua a encontrar spans de texto e a atribuir-lhes etiquetas. O que mudou foi a sua posição no sistema. Atualmente fornece filtros para RAG, argumentos estruturados para ferramentas de agents e campos para pipelines de processamento documental. Estes usos tornam a latência, o custo e a flexibilidade do schema tão importantes como a precisão no benchmark.

RAG: melhor retrieval através de extração de entidades

A pesquisa por similaridade, por si só, tem dificuldades quando uma pergunta contém entidades exatas. Para “what did Anthropic say about model safety in Q4 2024?”, a extração de entidades pode propor “Anthropic” e “Q4 2024” como filtros. Aplique um filtro rígido apenas quando os metadados indexados e a semântica das datas o suportarem; caso contrário, utilize-o como sinal de ranking ou mantenha um caminho de retrieval sem filtros. Um alias não detetado ou um intervalo de datas inferido incorretamente pode excluir a resposta.

Durante a indexação, extraia entidades de cada chunk e guarde-as como metadados: {"organizations": ["Anthropic"], "dates": ["Q4 2024"], ...}. Isto permite filtrar por entidade antes de executar a pesquisa vetorial. Knowledge graph RAG (GraphRAG, property graphs do LlamaIndex) acrescenta relações nomeadas que o retrieval pode seguir ao longo de vários hops. Compare-o com pesquisas vetoriais repetidas nas perguntas e no corpus que precisa de suportar.

No momento da query, as entidades extraídas da pergunta do utilizador orientam o routing. Uma pergunta que mencione o nome de uma empresa é encaminhada para um índice financeiro; uma que mencione nomes de medicamentos vai para uma base de conhecimento clínica. O GLiNER é útil quando o schema ou os tipos de entidade em tempo de query mudam. Nomes de empresas ou medicamentos desconhecidos, por si só, não exigem etiquetas de vocabulário aberto; um modelo de etiquetas fechadas pode continuar a reconhecer novas menções de tipos conhecidos.

AI agents: transformar texto em factos estruturados

Os agents recebem texto não estruturado, como páginas Web, respostas de APIs e mensagens de utilizadores. O NER converte esse texto em factos estruturados sobre os quais o agent pode raciocinar, que pode armazenar ou passar a ferramentas.

Para routing de ferramentas, um pedido como “schedule a meeting with Sarah Chen from Accenture on Thursday at 2pm” pode produzir PERSON: Sarah Chen, ORGANIZATION: Accenture, DATE: Thursday e TIME: 2pm. Um resolver de calendários combina depois a data e a hora no timestamp exigido pela API. Um encoder local evita a ida e volta à API e é frequentemente bastante mais rápido, mas a latência depende do modelo, runtime, hardware, batch size e número de etiquetas. Meça ambos os caminhos no workload de calendário em vez de assumir uma diferença fixa em milissegundos.

O NER também suporta o acompanhamento de entidades ao longo de conversas. Os sistemas de memória de agents precisam de saber que “Sarah”, no turno 3, e “Ms. Chen”, no turno 12, correspondem à mesma pessoa. O NER identifica os spans; a resolução de correferência decide se as menções se referem à mesma pessoa no contexto. O entity linking associa depois essa pessoa a um registo canónico, quando este existe.

A restrição, em ambos os casos, é a latência. Se cada um de dez passos sequenciais fizer uma chamada de NER de 200 ms, essas chamadas acrescentam 2 segundos de atraso percebido. Uma única chamada acrescenta 200 ms. Os modelos encoder costumam integrar-se melhor no agent loop para trabalho de entidades do que a extração baseada em LLM.

Inteligência documental: das imagens aos dados estruturados

O OCR transforma imagens em texto. O NER transforma esse texto em campos estruturados.

Um pipeline standard utiliza primeiro OCR, como Tesseract, Azure Document Intelligence ou AWS Textract, para produzir texto e bounding boxes. O NER encontra depois spans para campos como invoice_number, vendor_name, total e due_date. Um passo de schema ou extração de relações tem de agrupar descrições de itens, quantidades e preços em line_items. A mesma sequência aplica-se a contratos, registos médicos e documentos regulamentares.

Os pipelines documentais modernos podem combinar compreensão do layout, extração de entidades e extração de relações. O OCR ou um modelo documental sensível ao layout continua a fornecer texto, ordem de leitura, tabelas e bounding boxes. Atualmente, o GLiNER2.5 expõe entidades, relações, classificação e registos estruturados através de uma interface de schema. Avalie cada output separadamente; o artigo mais antigo do GLiNER2 não avaliou todas as tarefas atualmente expostas pela biblioteca.

O custo decide a maioria destes pipelines. Calcule o preço com base no volume mensal real de documentos, incluindo retries e revisão. Um encoder compacto pode correr em CPU, enquanto um LLM baseado em API acrescenta custo de inferência e latência por documento. Um teste prático consiste em etiquetar um conjunto representativo de faturas com um LLM. Faça fine-tuning do GLiNER nos registos revistos e compare depois ambos os caminhos ao nível de F1 por campo, latência e custo total.

Deteção de PII e guardrails para LLMs

Os princípios de proteção de dados e deveres de segurança do RGPD (artigos 5, 25 e 32), a Security Rule tecnologicamente neutra da HIPAA (orientações do HHS) e a CCPA da Califórnia, conforme alterada pela CPRA, impõem direitos e salvaguardas baseadas no risco diferentes. As disposições citadas não prescrevem NER nem uma arquitetura específica de scanning antes do modelo. Isto não constitui aconselhamento jurídico; peça ao departamento jurídico que reveja os requisitos aplicáveis aos seus dados e à sua jurisdição. O NER pode apoiar o inventário de dados, a minimização ou a desidentificação, mas é apenas um controlo cuja recall deve ser validada para os dados e a jurisdição relevantes.

O NER trata isto diretamente. Os modelos de desidentificação encontram spans de PERSON, SSN, PHONE, EMAIL e ADDRESS e fazem a sua redação ou substituem-nos por equivalentes sintéticos. Microsoft Presidio combina recognizers com operadores de anonimização, e os seus exemplos incluem GLiNER como recognizer. O GLiNER2-PII, com 0,3B parâmetros, é outro candidato: o artigo abrange 42 tipos de PII à resolução de spans de caracteres. Nenhum dos dois constitui prova de conformidade. Valide a recall por formato de dados, jurisdição, língua e classe de PII antes de utilizar qualquer detector como controlo.

Na comparação conduzida pelo fornecedor John Snow Labs, 48 documentos anotados por especialistas abrangem seis classes de PHI. As etiquetas dos fornecedores foram remapeadas e as previsões não mapeáveis foram excluídas, o que limita a interpretação entre fornecedores. O relatório da Providence descreve 281 eventos de PHI expostos numa revisão de 1.000 notas contendo 34.701 frases. Os eventos não correspondem a frases afetadas distintas: numa avaliação de privacidade, conte tanto as instâncias expostas como os documentos afetados.

Para guardrails de LLM, o NER funciona como uma camada de pré-triagem: analise a entrada do utilizador à procura de PII antes de a enviar para uma API externa e, em seguida, bloqueie-a ou anonimize-a. Pode ser mais rápido ou simples do que pedir ao LLM que faça self-moderation. Trate isto como uma hipótese de deployment: meça ambos os caminhos no seu modelo, hardware, mistura de inputs e objetivo de recall. Continuam a ser possíveis falsos negativos, por isso acrescente outro controlo para a exposição de PII que o seu sistema não pode aceitar. O GLiNER é especialmente útil neste contexto porque as categorias de PII variam consoante a jurisdição. Uma API pode aceitar uma nova etiqueta, como “genetic information”, sem retraining. Isto não estabelece a recall para a nova categoria; valide-a em exemplos revistos antes de depender dela.

GLiNER: correspondência span-etiqueta para NER de vocabulário aberto

O GLiNER (NAACL 2024, Zaratiana et al.) tornou o NER baseado em encoders competitivo com LLMs por uma fração do custo. Em vez de tratar o NER como etiquetagem de sequências ou geração de texto, o GLiNER trata-o como um problema de correspondência. Atribui uma pontuação a cada span de texto candidato (cada sequência contígua de palavras, como “Bill Gates” ou “Microsoft”) face a cada etiqueta de tipo de entidade e conserva os pares com pontuação elevada.

O modelo recebe as etiquetas dos tipos de entidade e o texto de entrada como uma única sequência: [ENT] person [ENT] organization [ENT] date [SEP] Bill Gates founded Microsoft.... Um transformer bidirecional (DeBERTa-v3) codifica tudo em conjunto.

A partir do output, o modelo constrói dois conjuntos de representações. Um refina cada representação de tipo de entidade a partir de uma posição de token [ENT], através de uma pequena rede feed-forward (FFN) que transforma o vetor do encoder. O outro representa spans de texto combinando vetores das palavras inicial e final através de outra FFN. O produto escalar entre uma representação de span e uma representação de tipo de entidade produz uma pontuação.

Aplique sigmoid e obtém a probabilidade de o span entre a posição de palavra $i$ e a posição de palavra $j$ pertencer ao tipo de entidade $t$: $\phi(i, j, t) = \sigma(S_{ij}^T \cdot q_t)$. Aqui, $S_{ij}$ é o vetor do span produzido pela FFN e $q_t$ é o embedding do tipo de entidade refinado pela FFN a partir do token [ENT] correspondente (Zaratiana et al., 2024, Eqs. 1–2). Os spans candidatos estão limitados a 12 palavras; o tokenizer pode dividir uma palavra em vários subword tokens.

O GLiNER aceita descrições de etiquetas em linguagem natural no momento da inferência, sem retraining, mas a qualidade da extração depende da formulação da etiqueta e da adequação ao domínio. Pode fornecer tipos de entidade como “person”, “adverse drug reaction” ou “financial instrument”, e o modelo atribui pontuações aos spans face a esses tipos. As configurações 50M, 90M e 300M abaixo são os modelos originais do artigo. O model card da v2.1 lista, em vez disso, checkpoints ingleses de 166M, 209M e 459M, além de um checkpoint multilingue de 209M, todos sob Apache 2.0. Não compare latência ou memória entre essas gerações como se os nomes dos parâmetros fossem idênticos (model card do GLiNER v2.1).

Para um verdadeiro teste hard zero-shot, mantenha de fora tanto os tipos-alvo como os exemplos-alvo: o modelo não tem exemplos anotados para a tarefa-alvo. Uma descrição de tipo como “a medically confirmed adverse effect caused by a treatment” fornece mais informação ao modelo do que apenas adverse event. Isto não garante transferência, mas o ZeroNER orientado por descrições superou baselines baseados apenas no nome nos seus benchmarks com tipos excluídos (Cocchieri et al., 2025).

Os dados de treino do modelo original vieram do dataset Pile-NER: 44.889 passagens com 240K spans de entidades distribuídos por 13K tipos de entidade, todos etiquetados pelo ChatGPT. O treino do GLiNER-L demorou cerca de 5 horas numa única A100 (Zaratiana et al., 2024).

Resultados de benchmark

Resultados zero-shot de Zaratiana et al. (2024), Tabelas 1 e 2. O F1 combina precisão e recall numa única pontuação; uma pontuação mais elevada só é melhor quando a tarefa e as regras de avaliação são as mesmas. A média dos sete datasets combina cinco datasets CrossNER com MIT Movie e MIT Restaurant:

O GLiNER-M, com 90M parâmetros, quase iguala o UniNER-13B na média de sete datasets do artigo (55,4% contra 55,6% F1), utilizando aproximadamente 140 vezes menos parâmetros. O GLiNER-S de 50M supera em 5 pontos de F1 o resultado reportado para ChatGPT (GPT-3.5). A variante multilingue, treinada apenas com dados ingleses, supera esse mesmo baseline do ChatGPT em 8 de 10 línguas não inglesas (Zaratiana et al., 2024). Estas comparações utilizam as versões dos modelos e o harness de avaliação do artigo; não estabelecem um ranking face a LLMs mais recentes.

As variantes do GLiNER abrangem texto biomédico, deteção de PII, notícias e suporte multilingue.

O material complementar mantém a v2.1 para o quickstart. Para uma nova comparação com cross-encoders, inclua também os checkpoints GLiNER v2.5 mantidos; os números de versão não são prova de melhoria de F1 num domínio. O GLiNER v2.5 e o Fastino GLiNER2.5 abaixo são famílias de modelos diferentes.

De scripts/01_gliner_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']}")
# Bill Gates => person
# Microsoft => organization
# April 4, 1975 => date

Como o GLiNER se compara com spaCy

O spaCy é uma das bibliotecas NLP mais estabelecidas em produção. Também funciona sob restrições arquiteturais diferentes das do GLiNER.

Os pipelines do spaCy (en_core_web_sm, en_core_web_trf) fazem NER de vocabulário fechado: um conjunto fixo de tipos de entidade (PERSON, ORG, GPE, DATE, etc.) definido no momento do treino. Expandir o componente ner treinado exige exemplos etiquetados e treino. Para identificadores ou um dicionário controlado, o EntityRuler pode adicionar etiquetas personalizadas através de padrões sem retraining; teste a sua recall fora desses padrões. Fixe o pacote de modelo mantido da versão 3.8 em vez de assumir que uma major line não lançada é uma atualização pronta para produção. O model card do modelo en_core_web_trf 3.8.0 reporta 90,19 NER F1 no OntoNotes 5.0, mas apenas para os seus 18 tipos predefinidos (model card do spaCy).

O GLiNER faz NER de vocabulário aberto: aceita novo texto de etiquetas no momento da inferência sem retraining. Isto não garante uma extração útil para todas as etiquetas; a formulação e a adequação ao domínio continuam a ser importantes. É um candidato forte quando os tipos de entidade não são conhecidos antecipadamente, mudam frequentemente ou são específicos do domínio (“adverse drug reaction”, “financial instrument”, “threat indicator”).

A minha recomendação: utilize spaCy para tipos de entidades standard quando os pipelines pré-treinados estiverem bem validados. Utilize GLiNER quando precisar de tipos flexíveis e zero-shot ou quando o pipeline tiver de se adaptar sem retraining. Podem partilhar um pipeline, com o spaCy a tratar da tokenização e segmentação de frases e o GLiNER a tratar da extração de entidades.

Um baseline Transformer supervisionado

Para etiquetas estáveis com spans anotados representativos, comece por um token classifier com fine-tuning, como RoBERTa ou DeBERTa, enquanto baseline supervisionado. Troca flexibilidade de etiquetas por precisão específica da tarefa. Compare-o com spaCy e GLiNER usando F1 de spans exatos, recall por etiqueta, calibração, latência e custo no mesmo conjunto do domínio.

UniNER e NuNER: até onde se pode reduzir?

O UniNER (ICLR 2024, Zhou et al.) e o NuNER (EMNLP 2024, Bogdanov et al.) destilam ambos anotações de LLMs em modelos de NER mais pequenos — mas discordam quanto ao limite dessa redução.

UniNER: o caminho maximalista

O UniNER faz fine-tuning do LLaMA-7B/13B em 45.889 pares input-output gerados pelo ChatGPT. Para cada tipo de entidade, o modelo responde a “What describes [type] in the text?” e produz listas JSON. Um truque de treino importante: a amostragem negativa baseada na frequência aumenta o F1 de 31,5% para 53,4% (Zhou et al., 2024).

O UniNER-7B alcança 41,7% de F1 zero-shot em 43 datasets — superando os 34,9% do ChatGPT em 7 pontos. A variante de 13B chega aos 43,4%, apenas mais 1,7 pontos com quase o dobro dos parâmetros (Zhou et al., 2024).

O compromisso em produção: a configuração UniNER-type com melhor pontuação no artigo consulta cada tipo de entidade sequencialmente. A variante all-in-one utiliza uma única resposta, mas teve em média menos 3,3%. Em FP16, um checkpoint de 7B precisa de aproximadamente 14GB apenas para os pesos; quantização com menos bits pode reduzir essa ocupação. O checkpoint UniNER-7B-all indica CC BY-NC 4.0; verifique o checkpoint exato em vez de transferir essa licença para todas as variantes.

NuNER: o caminho minimalista

O NuNER parte do RoBERTa-base (125M parâmetros) e utiliza treino contrastivo com 4,38 milhões de anotações do GPT-3.5 em 200K conceitos. Depois do treino, o concept encoder é descartado; o text encoder pode ser integrado em qualquer pipeline standard de NER como substituto do RoBERTa (Bogdanov et al., 2024).

A Tabela 3 do NuNER reporta aproximadamente 6,1–16,2 pontos acima do RoBERTa em F1 de classificação de tokens com média macro, usando encoders congelados e cabeças lineares, em quatro datasets e vários tamanhos de treino amostrados. O artigo também compara fine-tuning específico da tarefa com o UniNER-7B; a discussão separada de mais de uma dúzia de exemplos diz respeito à aprendizagem in-context do GPT-4, não a um limiar para igualar o UniNER (Bogdanov et al., 2024).

Ambos os artigos apoiam a aprendizagem a partir de anotações de LLMs. Não estabelecem que qualquer modelo mais pequeno irá superar o seu teacher num domínio novo. Mantenha um conjunto de teste revisto separadamente.

GLiNER2 e GLiNER2.5: separar o artigo do checkpoint

O ecossistema GLiNER original distribuía NER, extração de relações, classificação e extração ao nível do documento por modelos separados. O artigo GLiNER2 da EMNLP 2025 unificou NER, classificação e extração hierárquica num único modelo de 205M parâmetros; versões atuais acrescentaram posteriormente extração de relações à mesma interface de schema.

Essa arquitetura de 2025 mantém o design cross-encoder, mas aumenta o contexto para 2.048 tokens (4x o original) e acrescenta schemas declarativos para definir tarefas de extração. O treino utiliza 135.698 documentos reais anotados com GPT-4o, além de 118.636 exemplos sintéticos (Zaratiana et al., 2025).

No CrossNER zero-shot, o GLiNER 2 obtém 0,590 F1, próximo dos 0,599 do GPT-4o no benchmark de meados de 2025 do artigo. Para classificação, obtém uma média de 0,72 em 7 benchmarks, contra 0,69 do DeBERTa-v3-large. Em CPU, o artigo reporta latência de classificação de 130–208 ms nos números de etiquetas testados. O baseline DeBERTa zero-shot precisa de uma passagem forward por etiqueta candidata e sobe de 1.714 ms para 5 etiquetas a 16.897 ms para 50; este não é o runtime de um classificador DeBERTa supervisionado (Zaratiana et al., 2025).

O exemplo abaixo carrega, em vez disso, o GLiNER2.5: 194M parâmetros, uma arquitetura de fronteiras e uma janela configurada de 4.096 tokens. AutoExtractor seleciona BoundaryExtractor; o loader legado do GLiNER2 é inadequado. A combinação esparsa de início/fim altera os spans pontuados, não o limite finito de contexto. Utilize helpers documentados de chunks sobrepostos para documentos longos e verifique os offsets remapeados. As pontuações de 2025 acima não descrevem este checkpoint.

from gliner2 import AutoExtractor

# Requires `pip install gliner2[local]` and downloads the checkpoint.
extractor = AutoExtractor.from_pretrained("fastino/gliner2.5-base-v1")

# Compose tasks through the current schema interface
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"))
text = "Acme launched a $19 widget in Berlin."
results = extractor.extract(text, schema)

As versões atuais do GLiNER2 expõem reconhecimento de entidades, classificação, extração hierárquica e extração de relações através de um único schema. O artigo da EMNLP avalia NER e classificação; não apresenta um benchmark de extração hierárquica e não abrange a API de relações adicionada posteriormente. Trate o caminho de quatro tarefas como uma capacidade de deployment a comparar, não como prova de que um modelo conserva a precisão de quatro modelos especializados.

Adições de 2026: escolha a arquitetura que corresponde ao bottleneck

O ecossistema GLiNER tem agora arquiteturas distintas. São candidatas a uma comparação no domínio, não a um único leaderboard.

O artigo original do GLiNER, o artigo do bi-encoder e o GLiNER-Relex utilizam os seus próprios modelos e harnesses. Os model cards do GLiNER-X e do GLiNER Decoder descrevem checkpoints lançados, mas não constituem um benchmark comparável revisto por pares. Mantenha essa distinção num registo de decisão arquitetural.

PII em streaming altera o momento em que pode libertar texto

GLiNER Streaming PII acrescenta deteção incremental com um backbone causal Qwen3-0.6B e estado de sessão em cache. A sua API devolve o snapshot completo da sessão atual, com offsets no texto acumulado. Preserve as fronteiras dos chunks, mantenha as etiquetas fixas até a recomputação completa e limpe as sessões concluídas. Requer GLiNER 0.2.28 ou posterior.

Para redação em streaming, faria buffer do texto ainda não libertado e testaria entidades divididas entre chunks. Encontrar um número de telefone depois de enviar a primeira metade não permite retirar esses bytes. Meça os caracteres expostos antes da libertação e o atraso adicional, além da recall dos spans finais. O model card reporta separadamente PIIMB masking F2 e F1 de spans tipados estritos; respondem a perguntas diferentes. A sua fragilidade multilingue também impede tratar o checkpoint lançado como um filtro de privacidade universal.

As licenças dos checkpoints fazem parte da escolha do modelo

Verifique os termos exatos relativos ao código, pesos e datasets antes do deployment. As versões citadas atualmente não são intercambiáveis:

As etiquetas de licença não constituem aconselhamento jurídico. Uma revisão de produção deve incluir os termos do modelo base, dos dados de treino e do fornecedor.

O bi-encoder: escalar o NER para milhões de etiquetas

O GLiNER original codifica etiquetas e texto em conjunto. A codificação conjunta torna-se progressivamente mais dispendiosa à medida que o texto das etiquetas consome contexto e tem de ser recodificado com cada documento. O ponto de transição depende do checkpoint, das descrições das etiquetas e do hardware. Quando o mesmo inventário grande de tipos é reutilizado em muitos documentos, utilize o GLiNER bi-encoder como comparação predefinida. Este separa a codificação do texto e das etiquetas em dois transformers separados (Stepanov et al., 2026).

O text encoder utiliza ModernBERT (família Ettin) e o label encoder utiliza sentence transformers (BGE ou MiniLM). Os spans e as etiquetas são pontuados através de produto escalar. Essa separação significa que os embeddings dos tipos de entidade podem ser pré-calculados uma vez e colocados em cache. Durante a inferência, as etiquetas em cache evitam a codificação repetida das etiquetas. Pontuar spans candidatos face a essas etiquetas continua a exigir compute e memória; uma aplicação com um milhão de etiquetas também precisa de retrieval de candidatos limitado ou batching, medindo a recall das etiquetas excluídas antes da pontuação.

Estão disponíveis quatro tamanhos de modelo, todos avaliados no CrossNER (Stepanov et al., 2026, Tabela 1):

Com 1.024 tipos de entidade, o bi-encoder gliner-bi-edge-v2.0 com etiquetas pré-calculadas perde apenas 5,2% de throughput face a uma única etiqueta (19,3 → 18,3 ex/s). O uni-encoder gliner_small-v2.5 comparável perde 98,7% (10,7 → 0,14 ex/s). Nos testes do artigo com uma única H100, batch size 1 e inputs de 64, 256 e 512 tokens, o bi-encoder pré-calculado alcança uma vantagem de throughput de até 130× sobre gliner_small-v2.5. Com 100 tipos de entidade numa única H100, o bi-encoder processa 1,96 milhões de previsões por dia, contra 368K do cross-encoder (Stepanov et al., 2026).

O artigo do bi-encoder reporta 61,5% para gliner-bi-large-v2.0 contra 60,9% para gliner_large-v2.5 na mesma média CrossNER-plus-MIT. O artigo original do GLiNER também reporta 60,9%, mas para um checkpoint e uma avaliação diferentes. Trate a comparação do artigo do bi-encoder como um resultado publicado e teste depois ambas as arquiteturas no conjunto do domínio. Os autores recomendam o bi-base-v2.0 (194M) como o ponto ideal, atingindo 98% da precisão do modelo large a 2,6x a velocidade (Stepanov et al., 2026).

from gliner import GLiNER

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

# Pre-compute embeddings for a reused label set; rebuild this cache when labels or the checkpoint change.
entity_types = ["person", "organization", "date"]  # Small example; large inventories need bounded candidate selection
entity_embeddings = model.encode_labels(entity_types, batch_size=8)

# Encode text and score spans against the cached labels
texts = ["Bill Gates founded Microsoft on April 4, 1975."]
outputs = model.batch_predict_with_embeds(texts, entity_embeddings, entity_types)

O sweep de timing termina nas 1.024 etiquetas, utilizando uma H100, batch size um e dez passagens forward por configuração. Não mede um serviço de produção com milhões de etiquetas. Inventários biomédicos ou empresariais maiores são aplicações a avaliar; o entity linking está disponível através do framework complementar GLiNKER.

LLMs como teachers: um estudo de caso de $70 e um pipeline utilizável em produção

O padrão LLM-as-teacher separa a anotação dispendiosa da inferência mais barata. Dois estudos de caso publicados mostram como diferentes equipas o aplicaram em condições distintas.

O estudo de caso da CFM

Num estudo de caso da Hugging Face, a Capital Fund Management extraiu nomes de empresas de aproximadamente 900.000 títulos de notícias financeiras. O GLiNER zero-shot obteve 87,0% F1. A equipa utilizou o Llama 3.1-70B para anotar o dataset em cerca de 8 horas por aproximadamente $70, e reviu depois 2.714 amostras através do Argilla durante mais 8 horas.

O fine-tuning do GLiNER com estes dados atingiu 93,4% F1 no estudo de caso, contra 92,7% do teacher Llama-70B. Os autores reportam $0,10 por hora em CPU para o modelo com fine-tuning e $8 por hora para o teacher (estudo de caso da CFM). Estes valores descrevem uma tarefa de notícias financeiras e uma configuração de infraestrutura específicas.

O estudo da Refuel AI

O relatório técnico da Refuel AI avalia a etiquetagem com LLMs em 8 datasets de NLP, incluindo o CoNLL-2003. Reporta 88,4% de concordância com o ground truth para o GPT-4 (março de 2023) e 86,2% para os annotators humanos na sua configuração, além de uma etiquetagem 20 vezes mais rápida e 7 vezes mais barata. Uma experiência separada com um ensemble em dados proprietários superou 95% de concordância, com o melhor LLM individual a atingir 89%. O routing baseado na confiança para modelos mais baratos ou mais fortes é uma utilização proposta, não o mecanismo medido por detrás do resultado nos oito datasets (relatório técnico da Refuel AI). Trate estes valores como resultados reportados pelo fornecedor sob o protocolo de anotação desse estudo.

Um pipeline de produção

Um fluxo de produção prático tem seis passos:

1. Escreva guidelines de anotação em linguagem natural
2. Crie conjuntos de validação e teste hold-out etiquetados por humanos, dimensionados com base na prevalência das entidades, nos requisitos de slices por etiqueta e na largura desejada do intervalo de confiança. Um piloto de 50–200 documentos pode calibrar as guidelines, mas não é um tamanho predefinido para a avaliação em produção.
3. Utilize um LLM com um prompt versionado e um schema de output explícito para propor etiquetas de treino em massa. Retenha o modelo solicitado e o efetivamente utilizado, o prompt, o texto de origem e o estado de fallback. Rejeite tipos desconhecidos e spans que não possam ser alinhados com a origem; atualmente, o material complementar faz fallback silenciosamente e isso tem de ser corrigido antes de tratar o output como gold de treino.
4. Reveja um subconjunto através do Argilla ou do Label Studio
5. Faça fine-tuning de um encoder compacto (GLiNER, SpanMarker, RoBERTa)
6. Faça deployment apenas depois de o encoder passar uma verificação hold-out de qualidade e custo total. A CFM reportou um custo horário de infraestrutura 16–80x inferior na sua configuração; inclua na comparação os custos de anotação, revisão, serving e retraining.

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

Onde o GLiNER falha e os LLMs continuam a ser úteis

O benchmark da Sease (outubro de 2025) testou o GLiNER contra o GPT-4.1-mini em 30 tarefas de parsing de queries. O GPT-4.1-mini obteve 100% de respostas totalmente corretas. O GLiNER obteve 53% (16 em 30). Mas o GLiNER respondeu em 0,08 segundos, contra 1,21 segundos do LLM — 15x mais rápido.

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

1. Entidades implícitas: extrair “event” de “Elton John performed at Madison Square Garden” — nada no texto diz literalmente “event”, mas o LLM infere “concert”
2. Sensibilidade à formulação das etiquetas: “2022” obtém 0,388 contra “date”, mas 0,958 contra “year” — pequenas alterações nas etiquetas provocam grandes variações na pontuação
3. Mapeamento de valores: o GLiNER devolve o texto exato da superfície (“family houses”) em vez do valor canónico (“Single family house”). Um LLM pode executar essa normalização quando o prompt e o schema definem os valores-alvo.

Entidades aninhadas e sobrepostas

O GLiNER utiliza decoding plano por predefinição, suprimindo spans sobrepostos. A sua API também suporta flat_ner=False, pelo que são possíveis previsões aninhadas, embora a qualidade dependa do checkpoint, das etiquetas e dos dados do domínio. Compare ambos os modos de decoding num conjunto de teste ao nível de spans aninhados antes de escolher um modelo especializado.

Utilize o GLiNER para extração de entidades explícitas e encaminhe para um LLM os casos que exigem inferência, raciocínio ou mapeamento para ontologias predefinidas. O limiar de routing deve resultar de um conjunto de dados anotado do domínio.

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

Um modelo pode obter 95% de F1 num conjunto de teste selecionado e continuar a falhar na mistura de documentos que encontra após o deployment. Construa o conjunto de avaliação a partir da distribuição de produção e mantenha slices para os formatos raros e tipos de entidades que o F1 agregado pode ocultar.

As métricas principais

Identifique cada ocorrência pelo ID do documento, offsets half-open de início/fim e tipo, e verifique se text[start:end] recupera a menção. Duas ocorrências de “John” são dois alvos. Valide as contagens de documentos antes da correspondência: as previsões em falta têm de criar falsos negativos, não desaparecer através de zip(). Conte tipos ou offsets errados como uma previsão não correspondida e um span gold não correspondido. Reporte precisão, recall e F1 micro, suporte e recall por tipo, e defina a agregação macro e os casos vazios.

• F1 ao nível da entidade: A métrica standard. Uma previsão só está correta quando tanto os limites do span como o tipo correspondem exatamente ao ground truth. É o que a maioria dos artigos reporta.
• F1 ao nível do token: Avalia cada token individualmente. Pode fazer uma fronteira parcial parecer melhor do que uma pontuação de span exato; por isso, reporte F1 de spans exatos quando a correção dos limites for importante e utilize métricas ao nível do token apenas quando a decisão a jusante for ao nível do token.
• Precisão vs recall: Estes valores têm frequentemente custos assimétricos. Para desidentificação, a recall é mais importante — não detetar um nome é pior do que fazer redação excessiva. Para extração de bases de dados, a precisão é mais importante — entradas falsas corrompem a análise a jusante.

Armadilhas comuns na avaliação

1. Inflação por correspondências parciais: “Bill” é extraído quando a etiqueta gold é “Bill Gates” — alguns scripts contam isto como correspondência parcial. Utilize correspondência de spans exatos, salvo se tiver uma razão para não o fazer.
2. Confusão de tipos: “Microsoft” identificado corretamente como span, mas etiquetado como PERSON em vez de ORG, deve obter zero. Verifique se o código de avaliação trata este caso corretamente.
3. Fuga do conjunto de teste: Mantenha registos, documentos e anotações duplicados ou quase duplicados fora do conjunto de teste. Para uma afirmação hard zero-shot, mantenha também os tipos de entidades-alvo fora do treino; strings de superfície repetidas, por si só, não constituem fuga.
4. Prompts de etiquetas não controlados: Um nome de tipo curto e uma descrição de tipo testada são inputs diferentes. Versione as descrições das etiquetas, thresholds, revisões do checkpoint e modo de decoding com a pontuação.
5. Afirmações zero-shot baseadas numa só língua: Não infira a qualidade multilingue a partir do inglês. O OpenNER abrange 36 corpora e 52 línguas, e os seus baselines não encontraram um único modelo melhor em todas as línguas (Palen-Michel et al., 2025). Nas experiências do FiNERweb, mudar do inglês para etiquetas na língua-alvo alterou o F1 em 0,02–0,09, dependendo da configuração (Golde et al., 2026). Teste ambas as línguas das etiquetas quando o produto utiliza terminologia local.
6. Uma execução não é um veredicto: Reporte a variação entre random seeds quando aplicável, sweeps de thresholds e amostras de produção repetidas. Contagens pequenas por slice tornam instável o ranking dos modelos.

Mantenha a normalização, o entity linking, o agrupamento de registos e os endpoints de relações separados do F1 extrativo. Para privacidade, reporte instâncias expostas e documentos afetados aceites automaticamente, redações falsas e fração revista. Para serving, reporte taxa de conclusão, latência p50/p95 por documento, execuções cold e warm, batch sizes e tamanhos de etiquetas, memória máxima e custo por documento aceite.

Construir um conjunto de teste do domínio

Para uma avaliação de produção, recomendo:

1. Amostre dados de produção, não exemplos selecionados. Inclua os documentos problemáticos que o modelo irá realmente receber.
2. Dimensione o conjunto de teste para a estimativa de que precisa. Escolha a contagem com base na prevalência das entidades, nos tamanhos dos slices por etiqueta e na largura desejada do intervalo de confiança. Reporte intervalos de confiança bootstrap ou analíticos.
3. Utilize pelo menos dois annotators num subconjunto de calibração. Resolva as divergências e reporte uma medida de concordância sensível a spans. A concordância diagnostica a ambiguidade e a qualidade das guidelines; não é um teto para o desempenho do modelo.
4. Estratifique por dificuldade — casos fáceis (texto limpo, tipos standard) e casos difíceis (entidades ambíguas, jargão, texto ruidoso).
5. Mantenha slices de privacidade e fairness. Para PII, reporte recall por tipo de PII, língua, locale, formato documental e slices demográficos ou relacionados com a origem dos nomes relevantes. Minimize o acesso dos avaliadores ao texto sensível bruto, defina limites de retenção e reveja os falsos negativos.

NER contínuo requer um conjunto de regressão imutável

As taxonomias de produção mudam. Acrescente novos tipos sem alterar silenciosamente o significado de um tipo antigo. Mantenha um conjunto de regressão versionado e imutável para os tipos existentes, um conjunto de teste separado para o novo tipo e um changelog para alterações nas guidelines de anotação. Reporte separadamente as pontuações dos tipos antigos e novos antes de substituir um checkpoint. Esta é a forma mais simples de detetar forgetting e drift da taxonomia.

NER em produção em quatro setores

Estes são exemplos selecionados de setores, com números específicos nas condições reportadas. As fontes combinam comparações reportadas por fornecedores, estudos de caso reportados por empresas ou projetos e artigos revistos por pares ou preprints. Trate-os como exemplos práticos, não como um ranking de maturidade.

Saúde

Os exemplos da John Snow Labs e da Providence acima mostram por que razão a desidentificação precisa de reporting ao nível da entidade e do documento. Os seus protocolos de avaliação são mais úteis para desenhar uma revisão do que para estabelecer um ranking não qualificado de fornecedores.

A retrospectiva da OpenMed, publicada em 6 de janeiro de 2026, reporta 481 modelos; o valor 380+ descreve o inventário do lançamento de julho. Downloads medem distribuição, não deployments. A sua afirmação de resultados líderes em 10 de 12 benchmarks provém de um preprint dos autores de agosto de 2025, não de resultados de produção verificados independentemente.

NER financeiro

A extração financeira inclui menções a empresas em notícias e campos em documentos regulamentares; os seus schemas e comprimentos documentais diferem. O estudo de caso da CFM abrange o primeiro caso. O FinBERT-MRC formula a extração como machine reading comprehension e reporta 92,78±0,56 F1 no ChFinAnn e 96,80±0,38 no AdminPunish, ambos datasets chineses. Estes resultados não estabelecem precisão em documentos SEC em inglês. Teste documentos longos e entidades financeiras aninhadas na língua pretendida.

E-commerce

O artigo da Walmart na KDD 2023 utiliza dados multitask de queries QU-965M; as suas cerca de 60 etiquetas de NER são classes IOB2. A Secção 6.8 atribui o aumento de 0,51% no GMV ao baseline MTDNN treinado com esses dados, enquanto a avaliação online do EAMT permaneceu como trabalho futuro. A variação de negócio não pode ser atribuída apenas ao NER. O TripleLearn da Home Depot reporta uma melhoria do F1 hold-out de 69,5 para 93,3, uma experiência online e mais de nove meses em produção. A lição transferível é a supervisão iterativa do domínio, não um ranking atual de arquiteturas.

Cibersegurança

iACE é um exemplo histórico de extração automatizada de threat intelligence. O artigo do CyNER combina reconhecimento neural com outras fontes de extração e reporta 76,66 de span micro-F1 para XLM-RoBERTa-large, avaliado com seqeval. O preprint CyberNER harmoniza quatro datasets em 21 etiquetas alinhadas com STIX 2.1 e reporta RoBERTa com 0,736 F1. São resultados de investigação, não evidência de adoção em produção.

Otimização de deployment: de Python a inferência com menor latência

O repositório complementar demonstra a exportação do GLiNER para ONNX e o packaging INT8. Regista os tamanhos dos artefactos, mas não reproduz os valores de latência ou F1 reportados por projetos externos.

Serving nativo do GLiNER

Antes de mudar para um novo runtime, teste o caminho Ray Serve do projeto. gliner[serve] fornece batching dinâmico, dimensionamento de batches sensível à memória, scaling de múltiplas réplicas e um cliente HTTP. Batching e réplicas podem melhorar o throughput mantendo o código do modelo; o batching também pode acrescentar tempo de espera e as réplicas não eliminam a queueing. Compare latência da queue, latência warm, throughput e F1 de spans exatos sob a sua mistura de pedidos antes de o comparar com ONNX ou Rust.

Exportação para ONNX

O GLiNER tem conversão nativa para ONNX, e existem modelos pré-convertidos na Hugging Face (onnx-community/gliner_small-v2.1). Meça a latência face ao mesmo checkpoint PyTorch, batch size, hardware e protocolo de warm-up.

Execute scripts/02_onnx_export.py a partir do repositório complementar para exportar um modelo e quantizar dinamicamente o seu artefacto ONNX. Requer esse ambiente e descarrega um checkpoint, por isso é um comando para executar nesse repositório e não um snippet autocontido no artigo:

uv run python scripts/02_onnx_export.py

Quantização INT8

A quantização dinâmica pode reduzir os requisitos de armazenamento e memória de um modelo ONNX. O efeito na latência e no F1 por etiqueta depende do checkpoint e da CPU, pelo que o script de exportação é evidência de packaging, não um benchmark de deployment.

from onnxruntime.quantization import quantize_dynamic, QuantType

# Quantize weights dynamically, then evaluate the result
quantize_dynamic("gliner.onnx", "gliner_int8.onnx", weight_type=QuantType.QInt8)

gline-rs: reimplementação em Rust

gline-rs (Apache 2.0) remove o runtime Python do caminho de inferência. O seu benchmark v0.9.0 em modo token, numa Intel i9 e com três etiquetas, reporta 6,67 seq/s contra 1,61 do Python, em 100 amostras NuNER. Uma experiência separada v0.9.1 numa RTX 4080, com 1.000 amostras, reporta 248,75 seq/s, sem uma comparação equivalente com Python em GPU. São condições próprias do projeto, não resultados reproduzidos pelo repositório complementar. Suporta modelos de spans e tokens, GPU/NPU através do ONNX Runtime e é distribuído como crate no 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 pacote fast-gliner fornece bindings Python através de PyO3.

O que cobre a evidência de otimização

Extração estruturada: schemas nativos, Instructor e decoders locais

Quando precisa de mais flexibilidade do que os modelos encoder oferecem — entidades implícitas, raciocínio, mapeamento para ontologias — comece pelo mecanismo de schema nativo do fornecedor. A OpenAI suporta formatos de resposta json_schema estritos, os structured outputs da Anthropic suportam outputs JSON e tool inputs estritos, e a API Gemini suporta um subconjunto de JSON Schema. Um modelo Pydantic ou Zod partilhado pode descrever o contrato, mas cada fornecedor aceita um subconjunto de schema diferente e tem comportamentos diferentes relativamente a recusas e complexidade.

A conformidade com o schema torna o parsing fiável. Não prova que um span extraído existe no texto de origem nem que um valor normalizado está correto. Valide os valores dos campos, preserve offsets ou citações quando possível e avalie a precisão semântica num conjunto anotado.

Instructor envolve clientes de fornecedores com validação Pydantic e retries opcionais após falhas de validação.

Adaptado do padrão do Instructor em scripts/05_structured_extraction.py. Requer os pacotes listados e um OPENAI_API_KEY; o script complementar faz fallback para GLiNER quando não está disponível uma key. Este artigo utiliza agora o GPT-5.6 Terra, cujo model card suporta Chat Completions, function calling, structured outputs e none reasoning effort. Compare-o com o baseline antigo, mais barato, antes de mudar um extractor de alto volume; uma nova geração não estabelece uma precisão de NER melhor.

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.6-terra", reasoning_effort="none",
    response_model=ExtractEntities,
    messages=[{"role": "user", "content": "BioNTech SE acquired InstaDeep in the U.K."}])
# entities=[Entity(name='BioNTech SE', label='ORGANIZATION'), ...]

O Outlines, da dottxt, adota uma abordagem diferente: geração de tokens constrangida através de máquinas de estados finitos. O decoder mascara tokens que violariam a gramática-alvo, em vez de esperar por uma falha de validação e fazer retry. Uma visão geral da AWS cita 98% de conformidade com o schema contra 76% para validação pós-geração. Repete separadamente a afirmação da .txt Engineering de uma geração até 5 vezes mais rápida graças à sua abordagem de coalescence; a página não publica metodologia suficiente para tratar ambos os valores como um benchmark controlado único.

O pequeno exemplo local seguinte mantém o Phi-3 como exemplo histórico de integração de um decoder, não como recomendação de modelo para 2026. Para uma nova comparação de extração self-hosted, inclua o Qwen3.8-27B ou os checkpoints Qwen3.5 mais pequenos. Utilize o loader de modelo, chat template e serving backend documentados; substituir apenas a string abaixo não estabelece compatibilidade com uma arquitetura multimodal nem com o seu formato de reasoning.

import outlines
from transformers import AutoModelForCausalLM, AutoTokenizer
from pydantic import BaseModel
from typing import Literal

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

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

model_id = "microsoft/Phi-3-mini-4k-instruct"
model = outlines.from_transformers(
    AutoModelForCausalLM.from_pretrained(model_id),
    AutoTokenizer.from_pretrained(model_id),
)
result = model(
    "Extract entities from: BioNTech SE acquired InstaDeep in the U.K.",
    ExtractEntities,
)

O LangExtract é útil quando um campo gerado tem de estar grounded na fonte: devolve intervalos de caracteres e suporta backends LLM hosted ou locais. Para extração documental self-hosted, o NuExtract converte schemas JSON em templates e inclui modelos documentais multimodais. Trate ambos como sistemas de extração estruturada, não como substitutos automáticos de NER por spans. Os seus objetivos de campos, offsets, layout documental e latência precisam de testes próprios.

A escolha depende do local onde executa os modelos. Os schemas nativos são o caminho com menor fricção para um fornecedor suportado. O Instructor acrescenta uma camada de validação Pydantic e retries independente do fornecedor. O Outlines restringe a geração local face a um schema. O LangExtract dá prioridade ao grounding na fonte, enquanto o NuExtract visa a extração documental self-hosted. Todos os caminhos com LLM continuam a incluir geração autoregressiva. Compare cada caminho com um encoder usando o mesmo batch size, hardware, schema de entidades e rubric de precisão semântica.

A arquitetura de produção em três níveis

Faria o routing do NER em produção com base na forma da tarefa, e não num ranking único de modelos.

Nível 1: modelos encoder para spans explícitos. Utilize um cross-encoder GLiNER para um inventário pequeno de tipos. Quando é reutilizado um inventário grande, compare o bi-encoder com embeddings de tipos em cache. Faça fine-tuning através do pipeline LLM-as-teacher e faça deployment com serving nativo, ONNX, INT8 ou gline-rs apenas quando esse caminho passar o benchmark do domínio.

Nível 2: extração multitask ou de relações. Quando um pedido precisa de NER, classificação e campos hierárquicos, teste o checkpoint atual do GLiNER2.5 com 194M parâmetros contra baselines separados por tarefa. Quando o requisito central for spans conjuntos mais relações, teste o GLiNER-Relex. O artigo do GLiNER2 reporta 130–208 ms de latência de classificação em CPU nos números de etiquetas testados; isso não é evidência para a API de relações posterior nem para um deployment diferente.

Nível 3: LLMs para extração exigente em raciocínio. Encaminhe entidades implícitas, inferência contextual e mapeamento para ontologias para uma API de schema nativa ou para o Instructor em APIs cloud, e para o Outlines em output local constrangido. Utilize LangExtract quando os intervalos na fonte forem essenciais e NuExtract quando o próprio documento for o input. Registe estes casos para revisão. Apenas spans explícitos e alinhados com a fonte podem tornar-se targets normais de treino de Tier 1; factos inferidos e valores normalizados precisam de targets e avaliação próprios.

O estudo de caso da CFM fornece uma referência de custo para o Tier 1: 93,4% F1 a um custo reportado de $0,10 por hora em CPU, contra 92,7% F1 e $8 por hora para o seu teacher Llama-70B. Os preços horários das instâncias não determinam o custo por documento sem throughput. Recalcule com o seu hardware, modelo teacher, conjunto de etiquetas, utilização e custo de revisão.

Compromissos e limitações

Para cada compromisso abaixo, as perguntas úteis são onde se manifesta e se pode medi-lo antes do deployment.

Os erros do LLM-as-teacher propagam-se. Se o LLM errar sistematicamente um tipo específico de entidade (por exemplo, confundindo nomes de subsidiárias com empresas-mãe), o encoder com fine-tuning herda esse viés. Reveja cuidadosamente tipos com baixa confiança ou inconsistentes e mantenha uma amostra aleatória estratificada para detetar erros sistemáticos confiantes.

Um schema válido pode conter factos falsos. O output estruturado nativo, o Instructor e os decoders constrangidos podem tornar uma resposta parseável. Não conseguem garantir que todos os campos estão grounded, que os limites de um span estão corretos ou que um valor normalizado corresponde ao registo certo. Retenha evidência da fonte e valide a semântica separadamente.

As perdas de quantização dependem do checkpoint e dos dados. O material complementar cria um artefacto INT8 quantizado dinamicamente, mas não mede o seu F1. As orientações atuais do GLiNER recomendam quantization-aware training quando é necessário preservar a precisão INT8. Compare os checkpoints quantizado e original quanto a F1 de spans exatos e recall por etiqueta antes do deployment.

Quando a arquitetura de três níveis é excessiva. Um único domínio com tipos de entidade estáveis e exemplos etiquetados suficientes pode precisar apenas de um pipeline RoBERTa com fine-tuning ou spaCy. O padrão de três níveis é adequado para múltiplos domínios, tipos de entidade em evolução ou uma mistura medida de extração explícita e exigente em raciocínio. Um pipeline estreito de faturas que extraia nomes e datas pode ficar no Nível 1.

A qualidade do bi-encoder varia consoante o dataset. A codificação conjunta pode ajudar em alguns datasets, enquanto o bi-encoder vence a comparação do artigo no CrossNER e o uni-encoder fica ligeiramente à frente no CoNLL-2003. Compare ambos no conjunto do domínio; escolha com base na qualidade medida de spans exatos, calibração, número de etiquetas e throughput, em vez de utilizar “high stakes” como regra para a família do modelo.

As afirmações sobre PII e multilinguismo exigem slices. Uma pontuação agregada elevada pode ocultar uma perda perigosa de recall numa locale, forma de nome, layout documental ou classe rara de PII. Trate um modelo de privacidade como uma defesa em profundidade, defina um processo de resposta a falsos negativos e reavalie quando mudar a taxonomia, a mistura de línguas ou a fonte de dados.

Principais conclusões

1. Utilize um encoder compacto apenas para spans explícitos e só depois de este passar um conjunto de teste do domínio com suporte por tipo e intervalos de confiança.
2. Utilize GLiNER para vocabulários de etiquetas variáveis. Compare primeiro o seu bi-encoder quando for reutilizado um inventário grande de tipos; ative flat_ner=False apenas depois de medir a qualidade dos spans aninhados.
3. Utilize descrições de tipos testadas para afirmações hard zero-shot e teste separadamente a formulação das etiquetas em inglês e localizada para produtos multilingues.
4. Mantenha OCR, NER, extração de relações e entity linking como etapas de avaliação distintas, mesmo quando um modelo expõe várias tarefas.
5. Trate um LLM teacher como um sistema de proposta de anotações. Guidelines humanas, adjudicação, conjuntos de regressão imutáveis e um conjunto de teste hold-out continuam a ser necessários.
6. Utilize schemas nativos para fornecedores de LLM suportados, mas valide a correção semântica e o grounding na fonte separadamente da validade JSON.
7. Compare separadamente e em conjunto os caminhos de serving nativo, ONNX, quantização e Rust. Nunca multiplique speedups não medidos.

Referências

Artigos

• GLiNER: Generalist Model for Named Entity Recognition using Bidirectional Transformer - Zaratiana et al., NAACL 2024. A arquitetura fundacional de correspondência entre spans e entidades.
• GLiNER2: An Efficient Multi-Task Information Extraction System with Schema-Driven Interface - Zaratiana et al., demonstrações de sistemas EMNLP 2025. Unifica NER, classificação e extração hierárquica; as versões atuais acrescentaram posteriormente extração de relações.
• GLiNER Bi-Encoder: Scalable Named Entity Recognition with Bi-Encoder Architecture - Stepanov et al., fevereiro de 2026. Codificação desacoplada para escala de milhões de etiquetas.
• GLiNER-Relex: A Unified Framework for Joint Named Entity Recognition and Relation Extraction - Stepanov et al., 2026. Extração conjunta e zero-shot de entidades e relações.
• GLiNER2-PII: A Multilingual Model for Personally Identifiable Information Extraction - Zaratiana et al., 2026. 42 tipos de PII à resolução de spans de caracteres.
• ZeroNER: Fueling Zero-Shot Named Entity Recognition via Entity Type Descriptions - Cocchieri et al., ACL 2025. Avaliação hard zero-shot com descrições de tipos.
• OpenNER 1.0: Standardized Open-Access Named Entity Recognition Datasets in 50+ Languages - Palen-Michel et al., EMNLP 2025. 36 corpora, 52 línguas e baselines multi-ontologia.
• FiNERweb: Datasets and Artifacts for Scalable Multilingual Named Entity Recognition - Golde et al., EACL 2026. Etiquetas multilingues e avaliação de transferência.
• UniversalNER: Targeted Distillation from Large Language Models for Open Named Entity Recognition - Zhou et al., ICLR 2024. NER universal baseado em LLM através de destilação do ChatGPT.
• NuNER: Entity Recognition Encoder Pre-training via LLM-Annotated Data - Bogdanov et al., EMNLP 2024. Estuda um encoder de 125M pré-treinado em anotações de LLM.

Artigos da indústria

• EAMT: Entity-Aware Multi-Task Learning for Query Understanding - Walmart, KDD 2023. Estudo multitask de queries; o resultado online pertence ao seu baseline MTDNN.
• TripleLearn: End-to-End NER for E-Commerce Search - Home Depot, AAAI 2021. F1 de 69,5 para 93,3.
• Acing the IOC Game: Toward Automatic Discovery and Analysis of Open-Source Cyber Threat Intelligence - Liao et al., CCS 2016. Abordagem histórica de extração.
• CyberNER: A Harmonized STIX Corpus for Cybersecurity NER - 21 tipos de entidades alinhados com STIX 2.1.
• FinBERT-MRC: Financial NER via Machine Reading Comprehension - Formulação MRC avaliada em datasets financeiros chineses.

Estudos de caso

• CFM Case Study: Fine-tuning GLiNER for Financial NER - Pipeline de etiquetagem com LLM de $70 da Capital Fund Management, que alcançou 93,4% F1.
• Refuel AI: LLM Labeling Technical Report - GPT-4 a alcançar 88,4% de concordância de anotação, superando os annotators humanos.
• Sease: GLiNER as an Alternative to LLMs for Query Parsing - Onde o GLiNER falha e os LLMs continuam a ser necessários.
• John Snow Labs: Medical Text De-Identification Benchmark - Estudo do fornecedor com remapeamento e exclusões de etiquetas.
• OpenMed: Year in Review 2025 - Retrospectiva de janeiro de 2026; inventário e downloads não são deployments.

Ferramentas e frameworks

• ner-field-guide demo repo - Demos complementares para este artigo: quickstart do GLiNER, exportação ONNX, LLM-as-teacher e extração estruturada.
• gline-rs: Rust reimplementation of GLiNER - Experiências separadas do maintainer em CPU e GPU; código Apache 2.0.
• GLiNER serving - Caminho Ray Serve com batching dinâmico e deployment de múltiplas réplicas.
• spaCy English pipelines - Métricas versionadas de pipelines de etiquetas fechadas.
• Microsoft Presidio - Análise de PII e anonimização com recognizers personalizados.
• Instructor - Extração estruturada com LLM através de modelos Pydantic.
• Outlines - Geração de tokens constrangida através de FSMs, com um benchmark reportado de conformidade com o schema.
• LangExtract - Extração estruturada grounded na fonte, com intervalos de caracteres.
• NuExtract - Extração documental self-hosted de schema para template.
• OpenAI Structured Outputs - Referência de formatos de resposta JSON Schema estritos.
• Anthropic Structured Outputs - Outputs JSON e tool inputs estritos.
• Gemini Structured Outputs - Subconjunto de JSON Schema para respostas estruturadas.
• AWS: Structured Output with Outlines - Benchmark de 98% de conformidade com o schema.