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

Viacheslav Dubrov

2026-04-02 · Atualizado 2026-08-17 · 37 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.

O reconhecimento de entidades nomeadas (NER) abrange atualmente encoders compactos, modelos de vocabulário aberto e extração baseada em LLMs. Na avaliação CrossNER citada, um modelo GLiNER com 300M de parâmetros supera o F1 zero-shot reportado pelo UniNER de 13B. Um bi-encoder mais recente reporta até 130 vezes mais throughput do que o gliner_small-v2.5 uni-encoder comparável, com 1.024 tipos de entidade quando os labels são pré-computados. O artigo mediu este resultado numa única H100, com batch size 1, em entradas de 64, 256 e 512 tokens. Estes resultados justificam experiências, não um ranking universal para produção.

O repositório complementar fornece exemplos executáveis para GLiNER, exportação para ONNX, labels de treino gerados por LLM e extração estruturada. 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 lidar com casos que exigem inferência ou normalização.

Este guia destina-se a engenheiros que escolhem e avaliam arquiteturas de NER para pipelines de RAG, agentic, documentos ou privacidade. No final, terá um percurso de seleção de modelos, um plano de avaliação limitado e um design de três níveis para combinar encoders com extração por LLM.

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.

Em resumo: Comece com GLiNER quando precisar de extração de spans com vocabulário aberto e deployment em CPU. Use um bi-encoder GLiNER como primeira comparação quando um inventário grande e reutilizável de tipos tornar dispendiosa a codificação conjunta repetida dos labels. Para tarefas específicas de um domínio, teste o pipeline LLM-as-teacher: gere labels, reveja uma amostra, faça fine-tuning de um encoder e avalie-o num conjunto anotado por humanos. Encaminhe entidades implícitas, mapeamento de ontologias e outros casos exigentes em raciocínio para um LLM com uma schema API nativa, Instructor ou um decoder local com restrições. A arquitetura de três níveis combina estes percursos sem assumir uma divisão fixa do tráfego.

Para uma comparação breve entre 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 labels específicos do domínio. O NER identifica a menção. Entity linking é o passo separado que resolve uma menção para um registo canónico ou conceito de uma ontologia.

Onde os sistemas modernos usam NER

O NER continua a encontrar spans de texto e a atribuir-lhes labels. O que mudou foi a sua posição no sistema. Atualmente fornece filtros para RAG, argumentos estruturados para tools de agentes 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 «o que disse a Anthropic sobre a segurança dos modelos no quarto trimestre de 2024?», o sistema deve extrair «Anthropic» e «Q4 2024» como filtros de metadata, em vez de depender apenas de embeddings.

Durante a indexação, extraia entidades de cada chunk e armazene-as como metadata: {"organizations": ["Anthropic"], "dates": ["Q4 2024"], ...}. Isto permite filtrar por entidade antes de executar a pesquisa vetorial. O knowledge graph RAG (GraphRAG, property graphs do LlamaIndex) vai mais longe: NER e relation extraction constroem um grafo capaz de responder a perguntas multi-hop que embeddings planos não conseguem resolver.

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 é encaminhada para uma base de conhecimento clínica. 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 labels de vocabulário aberto; um modelo de labels fechados pode reconhecer novas menções de tipos já conhecidos.

AI agents: transformar texto em factos estruturados

Os agentes 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 agente pode raciocinar, que pode armazenar ou passar a tools.

Para o routing de tools, um pedido como «marcar uma reunião com Sarah Chen, da Accenture, na quinta-feira às 14:00» exige PERSON: Sarah Chen, ORGANIZATION: Accenture e DATETIME: Thursday 2pm antes de o agente chamar a calendar 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 labels. Meça ambos os percursos com o workload de calendário, em vez de assumir uma diferença fixa em milissegundos.

O NER também permite acompanhar entidades ao longo das conversas. Os sistemas de memória de agentes precisam de saber que «Sarah», no turno 3, e «Sra. Chen», no turno 12, são a mesma pessoa. O NER identifica os spans; o entity linking resolve-os para o mesmo ID.

Em ambos os casos, a limitação é 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 percetível. Uma chamada acrescenta 200 ms. Os modelos encoder tendem a encaixar melhor o processamento de entidades nos agent loops 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 convencional usa primeiro OCR, como Tesseract, Azure Document Intelligence ou AWS Textract, para produzir texto e bounding boxes. O NER extrai depois campos como invoice_number, vendor_name, line_items, total e due_date. 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. O GLiNER 2 pode então combinar extração de entidades, relações, classificação e extração hierárquica estruturada sobre esse texto, numa única passagem orientada por schema.

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

Deteção de PII e guardrails para LLMs

Os princípios de proteção de dados e os 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, 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 a assessoria jurídica para rever os requisitos aplicáveis aos seus dados e à sua jurisdição. O NER pode apoiar o inventário, a minimização ou a desidentificação de dados, mas é apenas um controlo, cujo recall deve ser validado para os dados e a jurisdição relevantes.

O NER trata diretamente deste problema. Os modelos de desidentificação encontram spans de PERSON, SSN, PHONE, EMAIL e ADDRESS e eliminam-nos ou substituem-nos por equivalentes sintéticos. O Microsoft Presidio combina recognizers com operadores de anonimização, e os seus exemplos incluem GLiNER como recognizer. O GLiNER2-PII, com 0,3B de parâmetros, é outro candidato: o seu artigo abrange 42 tipos de PII com resolução ao nível do span de caracteres. Nenhum dos dois constitui prova de conformidade. Valide o recall por formato documental, jurisdição, idioma e classe de PII antes de usar qualquer detector como controlo.

Na comparação realizada pelo fornecedor John Snow Labs, com 48 documentos open-source anotados por especialistas e abrangendo seis classes de PHI, a avaliação ao nível dos tokens reportou 96% de F1. Reportou 91% para Azure, 83% para AWS e 79% para GPT-4o. O estudo mapeou os labels dos fornecedores para o seu schema de ground truth e excluiu previsões sem mapeamento. Considere-o uma comparação limitada entre fornecedores, não uma prova de conformidade. Um relatório de deployment separado descreve o processamento de mais de 100.000 notas clínicas por dia pela Providence.

Para guardrails de LLM, o NER funciona como uma camada de pré-seleção: analisa a entrada do utilizador à procura de PII antes de a enviar para uma API externa e, em seguida, bloqueia-a ou anonimiza-a. Pode ser mais rápido ou simples do que pedir ao LLM que faça a sua própria moderação. Trate isto como uma hipótese de deployment: meça ambos os percursos com o seu modelo, hardware, mistura de entradas e objetivo de recall. Continuam a ser possíveis falsos negativos, pelo que deve acrescentar outro controlo para a exposição de PII que o seu sistema não pode aceitar. GLiNER é especialmente útil neste contexto porque as categorias de PII variam por jurisdição. Pode adicionar novos tipos de entidade, como «informação genética», ao abrigo de uma nova regulamentação, sem voltar a treinar.

GLiNER: correspondência entre spans e labels para NER de vocabulário aberto

O GLiNER (NAACL 2024, Zaratiana et al.) tornou o NER baseado em encoders competitivo com LLMs a uma fração do custo. Em vez de tratar o NER como sequence labeling ou geração de texto, o GLiNER trata-o como um problema de matching. Atribui uma pontuação a cada span de texto candidato — cada sequência contígua de palavras, como «Bill Gates» ou «Microsoft» — contra cada label de tipo de entidade e conserva os pares com pontuação elevada.

O modelo recebe os labels 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 da saída, o modelo constrói dois conjuntos de representações. Um representa os tipos de entidade a partir das posições de tokens [ENT]. O outro representa spans de texto combinando os vetores dos tokens inicial e final através de uma pequena 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 obterá a probabilidade de o span do token $i$ ao token $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 proveniente do token [ENT] correspondente (Zaratiana et al., 2024, Eqs. 1–2). Os spans estão limitados a 12 tokens para manter a rapidez.

O GLiNER aceita descrições de labels em linguagem natural durante a inferência, sem necessidade de retraining, mas a qualidade da extração depende da formulação dos labels e da adequação ao domínio. Forneça tipos de entidade como «pessoa», «reação adversa a um medicamento» ou «instrumento financeiro», e o modelo atribuirá pontuações aos spans correspondentes. As configurações de 50M, 90M e 300M abaixo são os modelos do artigo original. O model card atual 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 a latência ou a memória entre estas 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. Uma descrição do tipo, como «um efeito adverso clinicamente confirmado causado por um tratamento», fornece ao modelo mais informação do que apenas adverse event. Isto não garante a transferência, mas o ZeroNER orientado por descrições superou baselines que usavam apenas o 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 em 13K tipos de entidade, todos anotados 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 GLiNER-M, com 90M de parâmetros, quase iguala o UniNER-13B na tabela CrossNER do artigo (55,4% contra 55,6% de F1), usando aproximadamente 140 vezes menos parâmetros. O GLiNER-S de 50M supera em 5 pontos de F1 o resultado reportado para o ChatGPT (GPT-3.5). A variante multilingue, treinada apenas com dados em inglês, supera esse mesmo baseline do ChatGPT em 8 de 10 idiomas não ingleses (Zaratiana et al., 2024). Estas comparações usam as versões dos modelos e o harness 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.

A partir 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 o spaCy

O spaCy é uma das bibliotecas NLP mais consolidadas em produção. Também opera 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 em tempo de treino. Quer um novo tipo de entidade? Recolha dados anotados e volte a treinar. Fixe o pacote de modelos 3.8 mantido, em vez de assumir que uma major version ainda não lançada constitui uma atualização para produção. O model card do modelo en_core_web_trf 3.8.0 reporta 90,19 de F1 em NER no OntoNotes 5.0, mas apenas para os seus 18 tipos predefinidos (model card do spaCy).

O GLiNER faz NER de vocabulário aberto: qualquer label funciona em tempo de inferência, sem necessidade de retraining. Isto torna-o a melhor escolha quando os tipos de entidade são desconhecidos à partida, mudam frequentemente ou são específicos do domínio («reação adversa a um medicamento», «instrumento financeiro», «indicador de ameaça»).

A minha recomendação: use spaCy para tipos de entidade standard, quando os pipelines pretrained estão bem validados. Use GLiNER quando precisar de tipos flexíveis, 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 divisão em frases e o GLiNER da extração de entidades.

Um baseline de Transformer supervisionado

Para labels estáveis e spans anotados representativos, comece com um token classifier com fine-tuning, como RoBERTa ou DeBERTa, enquanto baseline supervisionado. Troca flexibilidade dos labels por precisão específica da tarefa. Compare-o com spaCy e GLiNER em F1 de spans exatos, recall por label, calibração, latência e custo, usando o 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 inferior de redução.

UniNER: o percurso maximalista

O UniNER faz fine-tuning de LLaMA-7B/13B em 45.889 pares de entrada-saída gerados pelo ChatGPT. Para cada tipo de entidade, o modelo responde a «O que descreve [tipo] no texto?» e produz listas em JSON. Um truque de treino importante: a negative sampling baseada na frequência aumenta o F1 de 31,5% para 53,4% (Zhou et al., 2024).

O UniNER-7B atinge 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 por quase o dobro do compute (Zhou et al., 2024).

O compromisso para produção: a configuração UniNER de maior pontuação do artigo consulta cada tipo de entidade sequencialmente. A variante all-in-one usa uma única resposta, mas obteve uma média 3,3% inferior. Em FP16, um checkpoint de 7B precisa de aproximadamente 14 GB apenas para os pesos; a quantização com menos bits pode reduzir esse footprint. O modelo tem também uma licença restritiva CC BY-NC 4.0.

NuNER: o percurso minimalista

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

O NuNER supera o RoBERTa simples em 6–15 pontos de F1 em todos os tamanhos few-shot. Com apenas uma dúzia de exemplos por tipo de entidade, o NuNER iguala o UniNER-7B apesar de ser 56 vezes mais pequeno (Bogdanov et al., 2024).

Ambos os artigos apoiam a destilação de anotações de LLMs em modelos NER mais pequenos. O NuNER mostra que um encoder com 125M de parâmetros pode igualar o resultado reportado para o UniNER-7B quando existem dados de fine-tuning específicos da tarefa, com licença MIT e inferência adequada para CPU.

GLiNER 2: um modelo, quatro tarefas

O ecossistema GLiNER original dividia NER, relation extraction, classificação e extração ao nível documental por modelos separados. O artigo GLiNER2, publicado na EMNLP 2025, unificou NER, classificação e extração hierárquica num único modelo com 205M de parâmetros; as releases atuais adicionaram posteriormente relation extraction à mesma interface de schema.

A arquitetura mantém o design cross-encoder, mas alarga o contexto para 2.048 tokens (4 vezes o original) e adiciona schemas declarativos para definir tarefas de extração. O treino usa 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 de F1, próximo dos 0,599 do GPT-4o no benchmark do artigo em meados de 2025. Em 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 labels testados. O baseline DeBERTa sobe de 1.714 ms para 5 labels para 16.897 ms para 50 (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"))
text = "Acme launched a $19 widget in Berlin."
results = extractor.extract(text, schema)

As releases atuais do GLiNER2 expõem reconhecimento de entidades, classificação, extração hierárquica e relation extraction 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 percurso de quatro tarefas como uma capacidade de deployment a avaliar, não como prova de que um modelo preserva a precisão de quatro modelos especializados.

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

O ecossistema GLiNER dispõe agora de arquiteturas distintas. São candidatas para uma comparação no domínio, não para uma única tabela classificativa.

O artigo original do GLiNER, o artigo do bi-encoder e o GLiNER-Relex usam modelos e harnesses próprios. Os model cards do GLiNER-X e do GLiNER Decoder descrevem checkpoints disponibilizados, mas não constituem um benchmark comparável sujeito a revisão por pares. Registe esta distinção no architecture decision record.

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

Verifique os termos exatos aplicáveis ao código, aos pesos e aos datasets antes do deployment. As releases citadas atualmente não são intercambiáveis:

As designações 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 labels

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

O text encoder usa ModernBERT (família Ettin) e o label encoder usa sentence transformers (BGE ou MiniLM). Os spans e os labels recebem pontuações através de produto escalar. Esta separação significa que os embeddings dos tipos de entidade podem ser pré-computados uma vez e colocados em cache. Durante a inferência, apenas o texto precisa de ser codificado; o lado dos labels passa a ser uma leitura da cache.

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 labels pré-computados perde apenas 5,2% de throughput face a um único label (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, realizados numa única H100, com batch size 1 e entradas de 64, 256 e 512 tokens, o bi-encoder com labels pré-computados alcança uma vantagem de throughput até 130× face a 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).

A precisão também se mantém. O bi-encoder-large atinge 61,5% de F1 no CrossNER, ligeiramente acima dos 60,9% do cross-encoder. Os autores recomendam o bi-base-v2.0 (194M) como o ponto ideal, atingindo 98% da precisão do modelo large a 2,6 vezes a 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 NER biomédico face à ontologia UMLS (mais de 4M de conceitos), taxonomias empresariais que evoluem sem retraining do modelo e entity linking através do framework complementar GLiNKER.

LLMs como teachers: um estudo de caso de $70 e um pipeline deployable

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 headlines de notícias financeiras. O GLiNER zero-shot obteve 87,0% de F1. A equipa usou o Llama 3.1-70B para anotar o dataset em cerca de 8 horas, por cerca de $70, e reviu 2.714 amostras através do Argilla noutras 8 horas.

O fine-tuning do GLiNER com estes dados atingiu 93,4% de 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 anotação com LLMs em 8 datasets 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 anotadores humanos na sua configuração, além de uma anotação 20 vezes mais rápida e 7 vezes mais barata. O seu ensemble encaminha exemplos fáceis para modelos mais baratos e exemplos difíceis para o GPT-4, atingindo mais de 95% de concordância nas experiências reportadas (relatório técnico da Refuel AI). Trate estes números como resultados reportados pelo fornecedor ao abrigo do protocolo de anotação desse estudo.

Um pipeline de produção

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

1. Escreva orientações de anotação em linguagem natural
2. Crie conjuntos de validação e teste held-out anotados por humanos, dimensionados a partir da prevalência das entidades, dos requisitos de slices por label e da largura pretendida do intervalo de confiança. Um piloto de 50–200 documentos pode calibrar as orientações, mas não é um tamanho predefinido para uma avaliação de produção.
3. Use um LLM com um prompt versionado e um schema de saída explícito para anotar dados de treino em massa; retenha a versão do modelo, o prompt e o texto de origem com cada label
4. Reveja uma amostra 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 se o encoder cumprir o quality gate e reduzir o custo total medido. A CFM reportou um custo horário de infraestrutura 16–80 vezes inferior na sua configuração; inclua no comparativo 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 orientações 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 — 15 vezes mais rápido.

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

1. Entidades implícitas: extrair «evento» de «Elton John atuou no Madison Square Garden» — o texto não diz literalmente «evento», mas o LLM infere «concerto»
2. Sensibilidade à formulação dos labels: «2022» obtém 0,388 contra «date», mas 0,958 contra «year» — pequenas alterações no label 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 usa por predefinição flat decoding, que suprime 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, dos labels e dos dados do domínio. Avalie ambos os modos de decoding num conjunto de teste ao nível dos spans aninhados antes de escolher um modelo especializado.

Use GLiNER para extração explícita de entidades 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 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, ainda assim, 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 e tipos de entidade raros que o F1 agregado pode ocultar.

As métricas principais

• F1 ao nível das entidades: A métrica standard. Uma previsão só está correta se tanto os limites do span como o tipo coincidirem exatamente com o ground truth. É isto que a maioria dos artigos reporta.
• F1 ao nível dos tokens: Avalia cada token independentemente. Inflaciona os resultados, porque acertar na maior parte de uma entidade longa dá crédito parcial. Prefira o F1 ao nível das entidades.
• Precision vs. Recall: Estes valores têm frequentemente custos assimétricos. Para desidentificação, o recall é mais importante — falhar um nome é pior do que eliminar dados em excesso. Para extração para bases de dados, a precision é mais importante — entradas falsas corrompem a análise a jusante.

Armadilhas comuns na avaliação

1. Inflação por correspondência parcial: extrair «Bill» quando o label gold é «Bill Gates» — alguns scripts contam isto como correspondência parcial. Use correspondência exata de spans, salvo motivo em contrário.
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 corretamente este caso.
3. Data leakage no conjunto de teste: Se as entidades de teste se sobrepõem às entidades de treino, as pontuações ficam inflacionadas. Existem benchmarks zero-shot (CrossNER, Few-NERD) para testar a generalização.
4. Prompts de labels não controlados: Um nome curto de tipo e uma descrição de tipo testada são entradas diferentes. Versione as descrições dos labels, os thresholds, as revisões dos checkpoints e o modo de decoding juntamente com a pontuação.
5. Afirmações zero-shot numa única 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 FiNERweb, a mudança de labels em inglês para labels 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 dos labels quando o produto usa terminologia local.
6. Uma execução é um veredicto: Reporte a variação entre random seeds quando aplicável, varrimentos de thresholds e amostras de produção repetidas. Contagens pequenas por slice tornam instável o ranking dos modelos.

Construir um conjunto de teste de domínio

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

1. Amostre dados de produção, não exemplos selecionados. Inclua os documentos imperfeitos que o modelo irá realmente receber.
2. Dimensione o conjunto de teste para a estimativa de que precisa. Escolha a quantidade a partir da prevalência das entidades, dos tamanhos dos slices por label e da largura pretendida do intervalo de confiança. Reporte intervalos de confiança bootstrap ou analíticos.
3. Use pelo menos dois anotadores num subconjunto de calibração. Arbitre as divergências e reporte uma medida de concordância sensível aos spans. A concordância diagnostica a ambiguidade e a qualidade das orientações; não é um teto de 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 o recall por tipo de PII, idioma, locale, formato documental e slices demográficos ou de origem dos nomes relevantes. Minimize o acesso dos avaliadores ao texto sensível em bruto, defina limites de retenção e reveja os falsos negativos.

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

As taxonomias de produção mudam. Adicione 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 às orientações 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 da indústria, 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 sujeitos a revisão por pares ou preprints. Trate-os como exemplos práticos, não como um ranking de maturidade.

Saúde

A John Snow Labs disponibiliza modelos de entidades clínicas mapeados para ICD-10, SNOMED CT, LOINC e RxNorm. Na sua comparação reportada pelo fornecedor, com 48 documentos e seis classes, a avaliação ao nível dos tokens reportou 96% de F1, contra 91% para Azure, 83% para AWS e 79% para GPT-4o. A comparação remapeou os labels e excluiu previsões sem mapeamento. Um estudo de caso separado, reportado pelo fornecedor, descreve a Providence St. Joseph Health a processar 100.000–500.000 notas clínicas diariamente.

Na sua análise de projeto de 2025, reportada pelo próprio projeto open-source OpenMed, são indicados mais de 380 modelos biomédicos de NER, 29,7 milhões de downloads na Hugging Face e resultados líderes em 10 de 12 benchmarks biomédicos públicos.

NER financeiro

O principal caso de uso é a extração de documentos submetidos à SEC. O Finance NLP da John Snow Labs extrai mais de 11 tipos de entidade de documentos 10-K/10-Q (moradas, tickers, anos fiscais, bolsas de valores). Variantes do FinBERT-MRC, publicadas em artigos sujeitos a revisão por pares, atingem 0,87–0,93 de F1 em tarefas de entidades financeiras. As maiores dificuldades são os documentos longos e as entidades aninhadas em instrumentos financeiros complexos.

Comércio eletrónico

Artigos sujeitos a revisão por pares reportam que o sistema EAMT da Walmart (KDD 2023) treina com 965 milhões de queries, cerca de 60 labels de entidades, e produziu um aumento de 0,51% no GMV em testes A/B. O framework TripleLearn da Home Depot (AAAI 2021) elevou o F1 de NER de 69,5 para 93,3 através de treino iterativo.

Cibersegurança

O sistema iACE, sujeito a revisão por pares (CCS 2016), processou 71.000 artigos de 45 blogs de segurança, extraindo 900K itens OpenIOC com 95% de precision e mais de 90% de cobertura. Um relatório de projeto sobre sistemas modernos como o CyNER descreve a combinação de DeBERTa (F1 >91%) com heurísticas IOC baseadas em regex. O preprint CyberNER apresenta um dataset unificado de 2025 que harmoniza quatro datasets em 21 tipos de entidade alinhados com STIX 2.1, com o RoBERTa a atingir 0,736 de F1.

Otimização do deployment: de Python à inferência de menor latência

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

Serving nativo de GLiNER

Antes de mudar para um novo runtime, teste o percurso Ray Serve do projeto. gliner[serve] fornece batching dinâmico, dimensionamento de batches sensível à memória, scaling com múltiplas réplicas e um cliente HTTP. Pode eliminar overhead de queueing num serviço multiutilizador, mantendo o mesmo código do modelo. Avalie a latência da fila, a latência a quente, o throughput e o F1 de spans exatos com a sua mistura de pedidos antes de o comparar com ONNX ou Rust.

Exportação para ONNX

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

A partir de scripts/02_onnx_export.py:

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

# Load the exported ONNX model
from gliner import GLiNER
model = GLiNER.from_pretrained("path/to/model", load_onnx_model=True)

entities = model.predict_entities(text, labels, threshold=0.5)

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 label depende do checkpoint e da CPU, pelo que o script de exportação constitui evidência de empacotamento, 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

O gline-rs (Apache 2.0) remove o runtime Python do percurso de inferência. O seu benchmark v0.9.0 em modo token, num Intel i9 e com três labels, reporta 6,67 seq/s contra 1,61 do Python; o resultado na RTX 4080 é de 248,75 seq/s. Estas são as condições do próprio projeto, não resultados reproduzidos pelo repositório complementar. Suporta modelos span e token, 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 precisar de mais flexibilidade do que a oferecida pelos modelos encoder — entidades implícitas, raciocínio, mapeamento de ontologias — comece pelo mecanismo de schema nativo do fornecedor. A OpenAI suporta formatos de resposta json_schema estritos, os structured outputs da Anthropic suportam saídas JSON e tool inputs estritos, e a Gemini API suporta um subconjunto de JSON Schema. Um modelo Pydantic ou Zod partilhado pode descrever o contrato, mas cada fornecedor aceita um subconjunto diferente do schema 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.

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

Adaptado do padrão Instructor em scripts/05_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'), ...]

O Outlines, da dottxt, adota uma abordagem diferente: geração de tokens com restrições através de máquinas de estados finitos. O decoder mascara os tokens que violariam a gramática-alvo, em vez de aguardar uma falha de validação e fazer retry. Uma visão geral da AWS cita 98% de adesão ao schema, contra 76% na validação pós-geração. Repete separadamente a alegaçã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.

import outlines
from transformers import AutoModelForCausalLM, AutoTokenizer

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 de LLM hosted ou locais. Para extração documental self-hosted, o NuExtract converte JSON schemas em templates e inclui modelos documentais multimodais. Trate ambos como sistemas de extração estruturada, não como substitutos automáticos do NER de spans. Os objetivos de campos, offsets, layout documental e latência precisam de testes próprios.

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

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

Eu faria o routing do NER em produção com base no formato da tarefa, e não num ranking único de modelos.

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

Nível 2: extração multi-tarefa ou de relações. Quando um pedido exigir NER, classificação e campos hierárquicos, teste o modelo partilhado do GLiNER2 com 205M de parâmetros. Quando o requisito central for combinar spans e relações, teste o GLiNER-Relex. O artigo do GLiNER2 reporta latência de classificação em CPU de 130–208 ms para os números de labels testados; isto não constitui evidência para a API de relações posterior nem para outro deployment.

Nível 3: LLMs para extração exigente em raciocínio. Encaminhe entidades implícitas, inferência contextual e mapeamento de ontologias para uma schema API nativa ou Instructor em APIs cloud, e para o Outlines em outputs locais com restrições. Use LangExtract quando os intervalos na fonte forem essenciais e NuExtract quando o próprio documento for a entrada. Registe estes casos, pois são candidatos para o próximo conjunto de treino do Nível 1.

O estudo de caso da CFM fornece uma referência de custo para o Nível 1: 93,4% de F1 a um custo reportado de $0,10 por hora em CPU, contra 92,7% de F1 e $8 por hora para o seu teacher Llama-70B. Recalcule essa comparação com o seu hardware, modelo teacher, conjunto de labels 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 de entidade específico — por exemplo, confundindo nomes de subsidiárias com nomes das empresas-mãe — o encoder com fine-tuning herdará esse viés. A solução é uma revisão humana direcionada: concentre o esforço nos tipos de entidade em que a confiança do LLM é baixa ou inconsistente, e não numa amostragem aleatória.

Um schema válido pode conter factos falsos. Structured output nativo, Instructor e decoders com restrições podem tornar uma resposta parseable. Não conseguem garantir que todos os campos estão grounded, que um limite de span está correto ou que um valor normalizado aponta para o registo certo. Conserve evidência da fonte e valide a semântica separadamente.

As perdas de quantização dependem do checkpoint e dos dados. O repositório 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 em F1 de spans exatos e recall por label antes do deployment.

Quando a arquitetura de três níveis é excessiva. Um único domínio com tipos de entidade estáveis e exemplos anotados suficientes pode precisar apenas de um pipeline RoBERTa ou spaCy com fine-tuning. O padrão de três níveis adequa-se a vários domínios, tipos de entidade em evolução ou uma mistura medida de extração explícita e exigente em raciocínio. Um pipeline de faturas restrito que extrai 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 CrossNER do artigo e o uni-encoder fica ligeiramente à frente no CoNLL-2003. Avalie ambos no conjunto do domínio; escolha com base na qualidade de spans exatos medida, calibração, número de labels e throughput, em vez de usar «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 num locale, numa forma de nome, num layout documental ou numa classe rara de PII. Trate um modelo de privacidade como uma defesa em profundidade, defina um processo de resposta a falsos negativos e volte a avaliar quando a taxonomia, a mistura de idiomas ou a origem dos dados mudar.

Principais conclusões

1. Use um encoder compacto para spans explícitos apenas depois de este passar um conjunto de teste do domínio com suporte por tipo e intervalos de confiança.
2. Use GLiNER para vocabulários de labels variáveis. Compare primeiro o seu bi-encoder quando um inventário grande de tipos for reutilizado; ative flat_ner=False apenas depois de medir a qualidade em spans aninhados.
3. Use descrições de tipos testadas para afirmações hard zero-shot e avalie separadamente a formulação dos labels em inglês e localizada nos produtos multilingues.
4. Mantenha OCR, NER, relation extraction e entity linking como fases 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. Orientações humanas, adjudicação, conjuntos de regressão imutáveis e um conjunto de teste held-out continuam a ser necessários.
6. Use schemas nativos para fornecedores de LLM suportados, mas valide a correção semântica e o grounding na fonte separadamente da validade do JSON.
7. Avalie separadamente e em conjunto os percursos 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 matching entre spans e entidades.
• GLiNER2: An Efficient Multi-Task Information Extraction System with Schema-Driven Interface — Zaratiana et al., demonstrações de sistemas da EMNLP 2025. Unifica NER, classificação e extração hierárquica; as releases atuais adicionaram posteriormente relation extraction.
• 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 labels.
• GLiNER-Relex: A Unified Framework for Joint Named Entity Recognition and Relation Extraction — Stepanov et al., 2026. Extração conjunta 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 com resolução ao nível do span 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 dos 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. Labels multilingues e avaliação de transferência.
• UniNER: Universal NER using Large Language Models — 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. Mostra que 125M de parâmetros são suficientes com dados de treino gerados por LLM.

Artigos da indústria

• EAMT: Entity-Aware Multi-Task Learning for Query Understanding — Walmart, KDD 2023. 965M de queries, aumento de 0,51% no GMV.
• TripleLearn: End-to-End NER for E-Commerce Search — Home Depot, AAAI 2021. F1 de 69,5 para 93,3.
• iACE: Automatic Collection of Cyber Threat Intelligence — CCS 2016. 71K artigos, 900K IOCs.
• CyberNER: A Harmonized STIX Corpus for Cybersecurity NER — 21 tipos de entidade alinhados com STIX 2.1.
• FinBERT-MRC: Financial NER via Machine Reading Comprehension — 0,87–0,93 de F1 em tarefas de entidades financeiras.

Estudos de caso

• CFM Case Study: Fine-tuning GLiNER for Financial NER — pipeline de anotação LLM da Capital Fund Management, com $70, que atingiu 93,4% de F1.
• Refuel AI: LLM Labeling Technical Report — GPT-4 a atingir 88,4% de concordância na anotação, superando os anotadores 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 — Comparação da deteção de PHI com 96% de F1 entre fornecedores.
• OpenMed: Year in Review 2025 — Mais de 380 modelos biomédicos de NER e 29,7M de downloads na Hugging Face.

Tools e frameworks

• ner-field-guide demo repo — Demos complementares para este artigo: quickstart do GLiNER, exportação para ONNX, LLM-as-teacher e extração estruturada.
• gline-rs: Rust reimplementation of GLiNER — Speedup de 4,1x em CPU face ao Python, com licença Apache 2.0.
• GLiNER serving — Percurso Ray Serve com batching dinâmico e deployment com múltiplas réplicas.
• spaCy English pipelines — Métricas versionadas de pipelines com labels fechados.
• Microsoft Presidio — Análise e anonimização de PII com recognizers personalizados.
• Instructor — Extração estruturada com LLM através de modelos Pydantic.
• Outlines — Geração de tokens com restrições através de FSMs, com um benchmark reportado de adesão ao 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 do formato de resposta com JSON Schema estrito.
• Anthropic Structured Outputs — Saídas JSON e tool inputs estritos.
• Gemini Structured Outputs — Subconjunto de JSON Schema para respostas estruturadas.
• AWS: Structured Output with Outlines — Benchmark de 98% de adesão ao schema.