Guía de NER 2026: GLiNER, spaCy, Transformers y LLMs

Viacheslav Dubrov

2026-04-02 · Actualizado 2026-09-06 · 43 min · Sistemas de recuperación y lenguaje

Traducción automática Este artículo se tradujo automáticamente a partir de la versión original en inglés.

Actualización del artículo

Publicado originalmente el 2 de abril de 2026. Revisado y actualizado el 6 de septiembre de 2026. La actualización cubre nuevos modelos de GLiNER, detección de PII en streaming, APIs de extracción estructurada e interpretación de benchmarks.

El reconocimiento de entidades con nombre (NER) convierte el texto en fragmentos etiquetados que un programa puede utilizar. Ante «Bill Gates fundó Microsoft el 4 de abril de 1975», puede devolver los spans contiguos Bill Gates, Microsoft y April 4, 1975 con los tipos persona, organización y fecha. En un encoder basado en spans, como GLiNER, el modelo lee el texto una vez y puntúa los spans candidatos frente a las etiquetas que proporcionas. Elegir un sistema de NER implica decidir cuánta latencia, coste, flexibilidad de etiquetas y capacidad de razonamiento necesita esa extracción.

El repositorio complementario proporciona ejemplos smoke de GLiNER, exportación a ONNX, generación de anotaciones y extracción estructurada. Su comparación de tres frases no es un ranking de modelos: el scorer agrupa los pares texto/tipo repetidos y puede ignorar los documentos gold finales cuando faltan predicciones. El script del teacher tampoco muestra una conversión demostrada a spans de entrenamiento revisados. Utiliza estos ejemplos para inspeccionar APIs, no para afirmar que existe un flujo completo de entrenamiento o evaluación. En cargas dominadas por spans explícitos, los encoders compactos suelen ser la opción más rápida y barata. Los LLMs siguen siendo útiles para generar datos de entrenamiento y resolver casos que requieren inferencia o normalización. Las secciones de benchmarks explican las comparaciones publicadas y sus limitaciones; ninguna corresponde a una nueva ejecución de benchmark para esta guía.

Para un pipeline de retrieval o privacidad, yo empezaría preguntando si la salida debe ser una mención literal. Esa decisión separa un recognizer de spans de los sistemas que también normalizan valores, enlazan registros o infieren hechos.

Repositorio complementario: ner-field-guide, con demos ejecutables de GLiNER, exportación a ONNX, el pipeline de LLM-as-teacher y extracción estructurada con Instructor.

En resumen: Empieza con GLiNER cuando necesites extracción de spans con vocabulario abierto y despliegue en CPU. Utiliza un bi-encoder de GLiNER como primera comparación cuando un inventario amplio y reutilizable de tipos haga costosa la codificación conjunta repetida de etiquetas. Para tareas específicas de dominio, prueba el pipeline de LLM-as-teacher: genera etiquetas, revisa una muestra, haz fine-tuning de un encoder y evalúalo con un conjunto etiquetado por personas. Envía las entidades implícitas, el mapeo de ontologías y otros casos con mucho razonamiento a un LLM con una API de esquemas nativa, Instructor o un decoder local con restricciones. La arquitectura de tres niveles combina esas rutas sin asumir una distribución fija del tráfico.

Para una comparación breve de modelos, consulta Mejores modelos de NER en 2026.

¿Qué es el reconocimiento de entidades con nombre?

El reconocimiento de entidades con nombre identifica spans en el texto y les asigna tipos como persona, organización, fecha, producto o etiquetas específicas del dominio. Un span es un fragmento contiguo del texto original. NER identifica la mención; el entity linking es el paso independiente que la resuelve a un registro canónico o a un concepto de una ontología.

Dónde utilizan NER los sistemas modernos

NER sigue identificando spans de texto y asignándoles etiquetas. Lo que ha cambiado es su posición dentro del sistema. Ahora proporciona filtros para RAG, argumentos estructurados para herramientas de agentes y campos para pipelines de procesamiento documental. Estos usos hacen que la latencia, el coste y la flexibilidad del esquema sean tan importantes como la precisión del benchmark.

RAG: mejor retrieval mediante extracción de entidades

La búsqueda por similitud tiene dificultades cuando una pregunta contiene entidades exactas. Para «¿qué dijo Anthropic sobre la seguridad de los modelos en el cuarto trimestre de 2024?», la extracción de entidades puede proponer «Anthropic» y «Q4 2024» como filtros. Aplica un filtro estricto solo cuando los metadatos indexados y la semántica de fechas lo permitan; en caso contrario, úsalo como señal de ranking o conserva una ruta de retrieval sin filtrar. Un alias no detectado o un intervalo de fechas inferido incorrectamente puede excluir la respuesta.

Durante la indexación, extraes entidades de cada chunk y las almacenas como metadatos: {"organizations": ["Anthropic"], "dates": ["Q4 2024"], ...}. Esto permite filtrar por entidad antes de ejecutar la búsqueda vectorial. Knowledge graph RAG (GraphRAG, grafos de propiedades de LlamaIndex) añade relaciones con nombre que el retrieval puede seguir a través de varios saltos. Compáralo con búsquedas vectoriales repetidas usando las preguntas y el corpus que necesites cubrir.

En tiempo de consulta, las entidades extraídas de la pregunta del usuario dirigen el enrutamiento. Una pregunta que mencione el nombre de una empresa se envía a un índice financiero; otra que mencione nombres de fármacos, a una base de conocimiento clínica. GLiNER resulta útil cuando cambian el esquema o los tipos de entidad en tiempo de consulta. Los nombres de empresas o fármacos no vistos no requieren por sí solos etiquetas de vocabulario abierto; un modelo de etiquetas cerradas también puede reconocer nuevas menciones de tipos conocidos.

Agentes de AI: convertir texto en hechos estructurados

Los agentes reciben texto no estructurado, como páginas web, respuestas de APIs y mensajes de usuarios. NER convierte ese texto en hechos estructurados sobre los que el agente puede razonar, que puede almacenar o que puede pasar a herramientas.

Para el enrutamiento de herramientas, una petición como «programa una reunión con Sarah Chen de Accenture el jueves a las 14:00» puede producir PERSON: Sarah Chen, ORGANIZATION: Accenture, DATE: Thursday y TIME: 2pm. Después, un resolver de calendario combina la fecha y la hora en el timestamp requerido por la API. Un encoder local evita el round trip a la API y suele ser considerablemente más rápido, pero la latencia depende del modelo, el runtime, el hardware, el tamaño del batch y el número de etiquetas. Mide ambas rutas con la carga de trabajo del calendario en lugar de asumir una diferencia fija en milisegundos.

NER también permite hacer tracking de entidades entre conversaciones. Los sistemas de memoria de agentes deben saber que «Sarah» en el turno 3 y «Sra. Chen» en el turno 12 son la misma persona. NER identifica los spans; la resolución de coreferencia decide si las menciones se refieren a la misma persona en contexto. Después, el entity linking asigna esa persona a un registro canónico, cuando existe.

La restricción en ambos casos es la latencia. Si cada uno de diez pasos secuenciales realiza una llamada de NER de 200 ms, esas llamadas añaden 2 segundos de retraso percibido. Una sola llamada añade 200 ms. Los modelos encoder suelen encajar mejor el trabajo de entidades dentro de los agent loops que la extracción basada en LLMs.

Inteligencia documental: de imágenes a datos estructurados

OCR convierte las imágenes en texto. NER convierte ese texto en campos estructurados.

Un pipeline estándar utiliza primero OCR, como Tesseract, Azure Document Intelligence o AWS Textract, para producir texto y bounding boxes. Después, NER identifica spans para campos como invoice_number, vendor_name, total y due_date. Un paso de esquema o extracción de relaciones debe agrupar las descripciones, cantidades y precios de las líneas en line_items. La misma secuencia se aplica a contratos, historiales médicos y documentos regulatorios.

Los pipelines documentales modernos pueden combinar comprensión del layout, extracción de entidades y extracción de relaciones. OCR o un modelo documental sensible al layout sigue proporcionando texto, orden de lectura, tablas y bounding boxes. GLiNER2.5 expone actualmente entidades, relaciones, clasificación y registros estructurados mediante una interfaz de esquema. Evalúa cada salida por separado; el artículo original de GLiNER2 no evaluó todas las tareas que ahora expone la librería.

El coste determina la mayoría de estos pipelines. Calcula el precio con el volumen mensual real de documentos, incluidos los reintentos y la revisión. Un encoder compacto puede ejecutarse en CPU, mientras que un LLM basado en API añade coste y latencia de inferencia por documento. Una prueba práctica consiste en etiquetar un conjunto representativo de facturas con un LLM. Haz fine-tuning de GLiNER con los registros revisados y compara después ambas rutas en F1 a nivel de campo, latencia y coste total.

Detección de PII y guardrails para LLMs

Los principios de protección de datos y las obligaciones de seguridad del GDPR (Articles 5, 25, and 32), la Security Rule tecnológicamente neutral de HIPAA (HHS guidance) y la CCPA de California, modificada por la CPRA, imponen derechos y salvaguardas diferentes basadas en el riesgo. Las disposiciones citadas no prescriben NER ni una arquitectura específica de escaneo previo al modelo. Esto no es asesoramiento jurídico; pide a un abogado que revise los requisitos aplicables a tus datos y jurisdicción. NER puede contribuir al inventario de datos, la minimización o la desidentificación, pero es solo un control cuyo recall debe validarse para los datos y la jurisdicción relevantes.

NER aborda esto directamente. Los modelos de desidentificación encuentran los spans PERSON, SSN, PHONE, EMAIL y ADDRESS y los eliminan o sustituyen por equivalentes sintéticos. Microsoft Presidio combina recognizers con operadores de anonimización, y sus ejemplos incluyen GLiNER as a recognizer. El modelo de 0,3B parámetros GLiNER2-PII es otra opción: su artículo cubre 42 tipos de PII a resolución de span de caracteres. Ninguno de los dos constituye evidencia de cumplimiento. Valida el recall por formato de datos, jurisdicción, idioma y clase de PII antes de utilizar cualquier detector como control.

En la comparación realizada por el proveedor John Snow Labs, 48 documentos anotados por expertos cubren seis clases de PHI. Las etiquetas de los proveedores se reasignaron y se excluyeron las predicciones no mapeables, lo que limita la interpretación entre proveedores. El informe de Providence describe 281 incidentes de PHI filtrada en una revisión de 1.000 notas que contenían 34.701 frases. Los incidentes no son frases afectadas distintas: en una evaluación de privacidad cuenta tanto las instancias filtradas como los documentos afectados.

Para los guardrails de LLMs, NER funciona como una capa de prefiltrado: analiza la entrada del usuario en busca de PII antes de enviarla a una API externa y después la bloquea o anonimiza. Puede ser más rápido o sencillo que pedir al LLM que se automodere. Trátalo como una hipótesis de despliegue: mide ambas rutas con tu modelo, hardware, mezcla de entradas y objetivo de recall. Siguen siendo posibles los falsos negativos, así que añade otro control para la exposición de PII que tu sistema no pueda aceptar. GLiNER resulta especialmente útil aquí porque las categorías de PII varían según la jurisdicción. Una API puede aceptar una etiqueta nueva, como «información genética», sin reentrenamiento. Eso no demuestra el recall para la nueva categoría; valídalo con ejemplos revisados antes de confiar en ella.

GLiNER: matching de spans con etiquetas para NER de vocabulario abierto

GLiNER (NAACL 2024, Zaratiana et al.) hizo que el NER basado en encoders fuera competitivo con los LLMs a una fracción del coste. En lugar de tratar NER como sequence labeling o generación de texto, GLiNER lo trata como un problema de matching. Puntúa cada span de texto candidato (cada secuencia contigua de palabras, como «Bill Gates» o «Microsoft») frente a cada etiqueta de tipo de entidad y conserva los pares con puntuación alta.

El modelo recibe las etiquetas de tipo de entidad y el texto de entrada como una única secuencia: [ENT] person [ENT] organization [ENT] date [SEP] Bill Gates founded Microsoft.... Un transformer bidireccional (DeBERTa-v3) codifica todo conjuntamente.

A partir de la salida, el modelo construye dos conjuntos de representaciones. Uno refina cada representación de tipo de entidad a partir de una posición de token [ENT] mediante una pequeña red feed-forward (FFN) que transforma el vector del encoder. El otro representa los spans de texto combinando los vectores de las palabras inicial y final mediante otra FFN. El producto escalar entre la representación de un span y la representación de un tipo de entidad proporciona una puntuación.

Aplica sigmoid y obtienes la probabilidad de que el span desde la posición de palabra $i$ hasta la posición de palabra $j$ pertenezca al tipo de entidad $t$: $\phi(i, j, t) = \sigma(S_{ij}^T \cdot q_t)$. Aquí, $S_{ij}$ es el vector del span producido por la FFN y $q_t$ es el embedding del tipo de entidad refinado por la FFN a partir del token [ENT] correspondiente (Zaratiana et al., 2024, Ecs. 1–2). Los spans candidatos están limitados a 12 palabras; el tokenizer puede dividir una palabra en varios subword tokens.

GLiNER acepta descripciones de etiquetas en lenguaje natural en tiempo de inferencia sin reentrenamiento, pero la calidad de extracción depende de la redacción de la etiqueta y de su adecuación al dominio. Se le pasan tipos de entidad como «persona», «reacción adversa a un medicamento» o «instrumento financiero», y el modelo puntúa los spans frente a ellos. Las configuraciones de 50M, 90M y 300M que aparecen a continuación son los modelos originales del artículo. La model card de v2.1 enumera, en cambio, checkpoints en inglés de 166M, 209M y 459M, además de un checkpoint multilingüe de 209M, todos bajo Apache 2.0. No compares la latencia o la memoria entre esas generaciones como si los nombres de los parámetros fueran idénticos (GLiNER v2.1 model card).

Para una prueba realmente hard zero-shot, reserva tanto los tipos objetivo como los ejemplos objetivo: el modelo no debe tener ejemplos etiquetados de la tarea objetivo. Una descripción de tipo como «un efecto adverso confirmado médicamente causado por un tratamiento» proporciona al modelo más información que adverse event por sí solo. No garantiza la transferencia, pero ZeroNER guiado por descripciones superó a los baselines basados únicamente en el nombre en sus benchmarks con tipos reservados (Cocchieri et al., 2025).

Los datos de entrenamiento del modelo original procedían del dataset Pile-NER: 44.889 pasajes con 240K spans de entidades repartidos entre 13K tipos de entidad, todos etiquetados por ChatGPT. Entrenar GLiNER-L llevó unas 5 horas en una única A100 (Zaratiana et al., 2024).

Resultados del benchmark

Resultados zero-shot de Zaratiana et al. (2024), Tablas 1 y 2. F1 combina precisión y recall en una única puntuación; una puntuación más alta solo es mejor bajo la misma tarea y las mismas reglas de evaluación. La media de siete datasets combina cinco datasets de CrossNER con MIT Movie y MIT Restaurant:

GLiNER-M, con 90M parámetros, casi iguala a UniNER-13B en la media de siete datasets del artículo (55,4 % frente a 55,6 % de F1), utilizando aproximadamente 140 veces menos parámetros. GLiNER-S, con 50M, supera en 5 puntos de F1 el resultado comunicado para ChatGPT (GPT-3.5). La variante multilingüe, entrenada únicamente con datos en inglés, supera ese mismo baseline de ChatGPT en 8 de 10 idiomas no ingleses (Zaratiana et al., 2024). Estas comparaciones utilizan las versiones de modelos y el harness de evaluación del artículo; no establecen un ranking frente a LLMs más recientes.

Las variantes de GLiNER cubren texto biomédico, detección de PII, noticias y soporte multilingüe.

El repositorio complementario conserva v2.1 para su quickstart. Para una comparación nueva de cross-encoders, incluye también los checkpoints mantenidos de GLiNER v2.5; los números de versión no demuestran una mejora de F1 en un dominio. GLiNER v2.5 y Fastino GLiNER2.5 son familias 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

Cómo se compara GLiNER con spaCy

spaCy es una de las librerías de NLP más consolidadas en producción. También funciona con restricciones arquitectónicas distintas de las de GLiNER.

Los pipelines de spaCy (en_core_web_sm, en_core_web_trf) realizan NER de vocabulario cerrado: un conjunto fijo de tipos de entidad (PERSON, ORG, GPE, DATE, etc.) definido durante el entrenamiento. Ampliar el componente ner entrenado requiere ejemplos etiquetados y entrenamiento. Para identificadores o un diccionario controlado, EntityRuler puede añadir etiquetas personalizadas mediante patrones sin reentrenamiento; comprueba su recall fuera de esos patrones. Fija el paquete de modelo mantenido 3.8 en lugar de asumir que una línea major aún no publicada es una mejora apta para producción. La model card del modelo en_core_web_trf 3.8.0 comunica un 90,19 de F1 de NER en OntoNotes 5.0, pero solo para sus 18 tipos predefinidos (spaCy model card).

GLiNER realiza NER de vocabulario abierto: acepta texto de etiquetas nuevas en tiempo de inferencia sin reentrenamiento. Eso no garantiza una extracción útil para cualquier etiqueta; la redacción y la adecuación al dominio siguen siendo importantes. Es una opción sólida cuando los tipos de entidad no se conocen de antemano, cambian a menudo o son específicos del dominio («reacción adversa a un medicamento», «instrumento financiero», «indicador de amenaza»).

Mi recomendación: utiliza spaCy para tipos de entidad estándar cuando los pipelines preentrenados estén bien validados. Utiliza GLiNER cuando necesites tipos flexibles y zero-shot o cuando tu pipeline deba adaptarse sin reentrenamiento. Pueden compartir pipeline: spaCy se encarga de la tokenización y la segmentación en frases, y GLiNER de la extracción de entidades.

Un baseline Transformer supervisado

Para etiquetas estables con spans anotados representativos, empieza con un token classifier con fine-tuning, como RoBERTa o DeBERTa, como baseline supervisado. Intercambia flexibilidad de etiquetas por precisión específica de la tarea. Compáralo con spaCy y GLiNER en F1 de span exacto, recall por etiqueta, calibración, latencia y coste, usando el mismo conjunto de dominio.

UniNER y NuNER: ¿hasta dónde se puede reducir el tamaño?

UniNER (ICLR 2024, Zhou et al.) y NuNER (EMNLP 2024, Bogdanov et al.) destilan anotaciones de LLMs en modelos NER más pequeños, pero discrepan sobre cuánto se puede reducir el tamaño.

UniNER: la vía maximalista

UniNER hace fine-tuning de LLaMA-7B/13B con 45.889 pares de entrada-salida generados por ChatGPT. Para cada tipo de entidad, el modelo responde a «¿Qué describe [tipo] en el texto?» y produce listas JSON. Un truco de entrenamiento clave: el negative sampling basado en frecuencia eleva F1 de 31,5 % a 53,4 % (Zhou et al., 2024).

UniNER-7B alcanza un 41,7 % de F1 zero-shot en 43 datasets, superando en 7 puntos el 34,9 % de ChatGPT. La variante de 13B llega al 43,4 %, solo 1,7 puntos más con casi el doble de parámetros (Zhou et al., 2024).

El compromiso para producción: la configuración de tipo UniNER con mayor puntuación del artículo consulta cada tipo de entidad secuencialmente. Su variante all-in-one utiliza una única respuesta, pero obtiene una media 3,3 % menor. En FP16, un checkpoint de 7B necesita aproximadamente 14 GB solo para los pesos; la quantization de menos bits puede reducir esa huella. El checkpoint UniNER-7B-all indica CC BY-NC 4.0; comprueba el checkpoint exacto en lugar de trasladar esa etiqueta a todas las variantes.

NuNER: la vía minimalista

NuNER parte de RoBERTa-base (125M parámetros) y utiliza entrenamiento contrastivo con 4,38 millones de anotaciones de GPT-3.5 sobre 200K conceptos. Después del entrenamiento, el concept encoder se descarta; el text encoder se integra en cualquier pipeline NER estándar como sustituto de RoBERTa (Bogdanov et al., 2024).

La Tabla 3 de NuNER comunica aproximadamente entre 6,1 y 16,2 puntos más que RoBERTa en F1 macro medio de token classification con encoders congelados y cabezas lineales, en cuatro datasets y tamaños de entrenamiento muestreados. El artículo también compara fine-tuning específico de tarea con UniNER-7B; su discusión independiente de más de una docena de ejemplos se refiere al in-context learning de GPT-4, no a un umbral para igualar a UniNER (Bogdanov et al., 2024).

Ambos artículos respaldan el aprendizaje a partir de anotaciones de LLMs. No demuestran que un modelo más pequeño vaya a superar a su teacher en un dominio nuevo. Conserva un conjunto de prueba revisado por separado.

GLiNER2 y GLiNER2.5: separa el artículo del checkpoint

El ecosistema original de GLiNER separaba NER, extracción de relaciones, clasificación y extracción a nivel documental en modelos distintos. El artículo de GLiNER2 de EMNLP 2025 unificó NER, clasificación y extracción jerárquica en un modelo de 205M parámetros; las versiones actuales añadieron posteriormente la extracción de relaciones a la misma interfaz de esquema.

Esa arquitectura de 2025 mantiene el diseño cross-encoder, pero amplía el contexto a 2.048 tokens (4 veces el original) y añade esquemas declarativos para definir tareas de extracción. El entrenamiento utiliza 135.698 documentos reales anotados con GPT-4o, además de 118.636 ejemplos sintéticos (Zaratiana et al., 2025).

En CrossNER zero-shot, GLiNER 2 obtiene 0,590 de F1, cerca del 0,599 de GPT-4o en el benchmark de mediados de 2025 del artículo. Para clasificación, alcanza una media de 0,72 en 7 benchmarks, frente a 0,69 de DeBERTa-v3-large. En CPU, el artículo comunica entre 130 y 208 ms de latencia de clasificación para los recuentos de etiquetas evaluados. El baseline DeBERTa zero-shot necesita un forward pass por cada etiqueta candidata y aumenta de 1.714 ms para 5 etiquetas a 16.897 ms para 50; este no es el runtime de un clasificador DeBERTa supervisado (Zaratiana et al., 2025).

El ejemplo siguiente carga, en cambio, GLiNER2.5: 194M parámetros, una arquitectura boundary y una ventana configurada de 4.096 tokens. AutoExtractor selecciona BoundaryExtractor; el loader heredado de GLiNER2 no es adecuado. El emparejamiento disperso de inicios y finales cambia qué spans se puntúan, no el límite finito de contexto. Utiliza helpers documentados de chunks solapados para documentos largos y comprueba los offsets remapeados. Las puntuaciones de 2025 anteriores no describen 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)

Las versiones actuales de GLiNER2 exponen reconocimiento de entidades, clasificación, extracción jerárquica y extracción de relaciones mediante un único esquema. El artículo de EMNLP evalúa NER y clasificación; no comunica un benchmark de extracción jerárquica y no cubre la API de relaciones posterior. Trata la ruta de cuatro tareas como una capacidad de despliegue que debe someterse a benchmark, no como evidencia de que un modelo conserve la precisión de cuatro modelos especializados.

Novedades de 2026: elige la arquitectura que encaje con el cuello de botella

El ecosistema GLiNER cuenta ahora con arquitecturas distintas. Son candidatas para una comparación de dominio, no posiciones de una única clasificación.

El artículo original de GLiNER, el artículo del bi-encoder y GLiNER-Relex utilizan sus propios modelos y harnesses. Las model cards de GLiNER-X y GLiNER Decoder describen checkpoints publicados, pero no constituyen un benchmark comparable revisado por pares. Conserva esta distinción en un registro de decisión arquitectónica.

La PII en streaming cambia cuándo puedes liberar el texto

GLiNER Streaming PII añade detección incremental con un backbone causal Qwen3-0.6B y estado de sesión cacheado. Su API devuelve la instantánea completa de la sesión actual, con offsets sobre el texto acumulado. Conserva los límites de los chunks, mantén las etiquetas fijas hasta un recompute completo y elimina las sesiones finalizadas. Requiere GLiNER 0.2.28 o posterior.

Para la redacción en streaming, almacenaría en buffer el texto aún no liberado y probaría entidades divididas entre chunks. Detectar un número de teléfono después de haber enviado su primera mitad no permite retirar esos bytes. Mide los caracteres filtrados antes de la liberación y la latencia añadida, además del recall del span final. La model card comunica por separado PIIMB masking F2 y F1 estricto de spans tipados; responden a preguntas diferentes. Su debilidad multilingüe también impide tratar el checkpoint publicado como un filtro de privacidad universal.

Las licencias de los checkpoints forman parte de la elección del modelo

Verifica los términos exactos del código, los pesos y los datasets antes del despliegue. Las versiones citadas actualmente no son intercambiables:

Las etiquetas de licencia no constituyen asesoramiento jurídico. Una revisión de producción debe incluir los términos del modelo base, los datos de entrenamiento y el proveedor.

El bi-encoder: escalar NER a millones de etiquetas

El GLiNER original codifica conjuntamente las etiquetas y el texto. La codificación conjunta se vuelve progresivamente más cara a medida que el texto de las etiquetas consume contexto y debe recodificarse con cada documento. El punto de cambio depende del checkpoint, las descripciones de las etiquetas y el hardware. Cuando se reutiliza el mismo inventario amplio de tipos en muchos documentos, utiliza el GLiNER bi-encoder como comparación predeterminada. Divide la codificación del texto y las etiquetas en dos transformers independientes (Stepanov et al., 2026).

El text encoder utiliza ModernBERT (familia Ettin), y el label encoder utiliza sentence transformers (BGE o MiniLM). Los spans y las etiquetas se puntúan mediante producto escalar. Esta separación significa que los embeddings de tipos de entidad pueden precalcularse una vez y cachearse. En inferencia, las etiquetas cacheadas evitan codificar las etiquetas repetidamente. Puntuar los spans candidatos frente a esas etiquetas sigue consumiendo cómputo y memoria; una aplicación con un millón de etiquetas también necesita retrieval de candidatos acotado o batching, midiendo el recall de las etiquetas excluidas antes del scoring.

Hay cuatro tamaños de modelo disponibles, todos evaluados en CrossNER (Stepanov et al., 2026, Tabla 1):

Con 1.024 tipos de entidad, el bi-encoder gliner-bi-edge-v2.0 con etiquetas precalculadas pierde solo un 5,2 % de throughput frente a una única etiqueta (19,3 → 18,3 ex/s). El gliner_small-v2.5 uni-encoder comparable pierde un 98,7 % (10,7 → 0,14 ex/s). En las pruebas del artículo con una sola H100, batch size 1 y entradas de 64, 256 y 512 tokens, el bi-encoder precalculado alcanza una ventaja de throughput de hasta 130× sobre gliner_small-v2.5. Con 100 tipos de entidad en una única H100, el bi-encoder procesa 1,96 millones de predicciones al día, frente a 368K del cross-encoder (Stepanov et al., 2026).

El artículo del bi-encoder comunica 61,5 % para gliner-bi-large-v2.0 frente a 60,9 % para gliner_large-v2.5 en la misma media de CrossNER más MIT. El artículo original de GLiNER también comunica 60,9 %, pero para un checkpoint y una evaluación diferentes. Trata la comparación del artículo del bi-encoder como un resultado del artículo y prueba después ambas arquitecturas con el conjunto de dominio. Los autores recomiendan bi-base-v2.0 (194M) como punto óptimo: alcanza el 98 % de la precisión del modelo grande a 2,6 veces su velocidad (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)

El barrido temporal se detiene en 1.024 etiquetas y utiliza una H100, batch size uno y diez forward passes por configuración. No mide un servicio desplegado con un millón de etiquetas. Los inventarios biomédicos o empresariales más grandes son aplicaciones que deben evaluarse; el entity linking está disponible mediante el framework complementario GLiNKER.

Los LLMs como teachers: estudio de caso de $70 y pipeline desplegable

El patrón LLM-as-teacher separa la anotación cara de la inferencia más barata. Dos estudios de caso publicados muestran cómo lo han aplicado distintos equipos en condiciones diferentes.

El estudio de caso de CFM

En un estudio de caso de Hugging Face, Capital Fund Management extrajo nombres de empresas de unos 900.000 titulares de noticias financieras. GLiNER zero-shot obtuvo 87,0 % de F1. El equipo utilizó Llama 3.1-70B para anotar el dataset en unas 8 horas por aproximadamente $70, y después revisó 2.714 muestras mediante Argilla durante otras 8 horas.

El fine-tuning de GLiNER con estos datos alcanzó 93,4 % de F1 en el estudio de caso, frente al 92,7 % del teacher Llama-70B. Los autores comunican $0.10 por hora en CPU para el modelo con fine-tuning y $8 por hora para el teacher (CFM case study). Esas cifras describen una tarea concreta de noticias financieras y una configuración de infraestructura determinada.

El estudio de Refuel AI

El informe técnico de Refuel AI evalúa el etiquetado con LLMs en 8 datasets de NLP, incluido CoNLL-2003. Comunica un 88,4 % de acuerdo con el ground truth para GPT-4 (marzo de 2023) y un 86,2 % para los annotators humanos en su configuración, además de un etiquetado 20 veces más rápido y 7 veces más barato. Un experimento independiente con un ensemble sobre datos propietarios superó el 95 % de acuerdo, con su mejor LLM individual en el 89 %. El enrutamiento basado en confianza hacia modelos más baratos o potentes es un uso propuesto, no el mecanismo medido detrás del resultado de ocho datasets (Refuel AI technical report). Trata estos resultados como datos comunicados por el proveedor bajo el protocolo de anotación de ese estudio.

Un pipeline de producción

Un flujo de producción práctico tiene seis pasos:

1. Redacta directrices de anotación en lenguaje natural
2. Crea conjuntos de validación y prueba held-out etiquetados por personas, dimensionados a partir de la prevalencia de entidades, los requisitos de slices por etiqueta y la amplitud deseada del intervalo de confianza. Un piloto de 50-200 documentos puede calibrar las directrices, pero no es un tamaño de evaluación de producción predeterminado.
3. Utiliza un LLM con un prompt versionado y un esquema de salida explícito para proponer etiquetas de entrenamiento en bloque. Conserva el modelo solicitado y el utilizado realmente, el prompt, el texto de origen y el estado del fallback. Rechaza tipos desconocidos y spans que no puedan alinearse con el texto de origen; el repositorio complementario actualmente aplica un fallback silencioso y debe corregirse antes de tratar su salida como gold de entrenamiento.
4. Revisa un subconjunto mediante Argilla o Label Studio
5. Haz fine-tuning de un encoder compacto (GLiNER, SpanMarker, RoBERTa)
6. Despliega solo después de que el encoder supere una comprobación held-out de calidad y coste total. CFM comunicó un coste de infraestructura por hora entre 16 y 80 veces menor en su configuración; incluye los costes de anotación, revisión, serving y reentrenamiento en la comparación.

El LLM puede reducir el volumen de anotación manual, pero el equipo sigue siendo responsable del conjunto de validación, las directrices de anotación, la revisión dirigida y el análisis de errores.

Dónde falla GLiNER y dónde los LLMs siguen siendo útiles

El benchmark de Sease (octubre de 2025) probó GLiNER frente a GPT-4.1-mini en 30 tareas de parsing de consultas. GPT-4.1-mini obtuvo un 100 % de respuestas completamente correctas. GLiNER obtuvo un 53 % (16 de 30). Sin embargo, GLiNER respondió en 0,08 segundos, frente a los 1,21 segundos del LLM: fue 15 veces más rápido.

En este benchmark de 30 tareas, GLiNER falló en tres patrones recurrentes:

1. Entidades implícitas: extraer «evento» de «Elton John actuó en el Madison Square Garden»; ningún texto dice literalmente «evento», pero el LLM infiere «concierto»
2. Sensibilidad a la redacción de la etiqueta: «2022» obtiene 0,388 frente a «date», pero 0,958 frente a «year»; pequeños cambios en la etiqueta provocan grandes variaciones en la puntuación
3. Mapeo de valores: GLiNER devuelve el texto exacto de superficie («family houses») en lugar del valor canónico («Single family house»). Un LLM puede realizar esa normalización cuando el prompt y el esquema definen los valores objetivo.

Entidades anidadas y solapadas

GLiNER utiliza por defecto un decoding plano, que suprime los spans solapados. Su API también admite flat_ner=False, por lo que son posibles las predicciones anidadas, aunque la calidad depende del checkpoint, las etiquetas y los datos del dominio. Evalúa ambos modos de decoding con un conjunto de prueba a nivel de span y con entidades anidadas antes de elegir un modelo especializado.

Utiliza GLiNER para la extracción de entidades explícitas y deriva a un LLM los casos que requieran inferencia, razonamiento o mapeo a ontologías predefinidas. El umbral de enrutamiento debe proceder de un conjunto de datos de dominio etiquetado.

Evaluación de NER: métricas, errores y conjuntos de prueba

Un modelo puede obtener un 95 % de F1 en un conjunto de prueba seleccionado y aun así fallar con la mezcla de documentos que recibe después del despliegue. Construye el conjunto de evaluación a partir de la distribución de producción y conserva slices para los formatos y tipos de entidad raros que el F1 agregado puede ocultar.

Las métricas principales

Identifica cada aparición mediante el ID del documento, offsets de inicio y fin half-open y el tipo, y verifica que text[start:end] recupere la mención. Dos apariciones de «John» son dos objetivos. Valida el número de documentos antes de hacer el matching: las predicciones ausentes deben crear falsos negativos, no desaparecer mediante zip(). Cuenta los tipos u offsets incorrectos como una predicción no emparejada y un span gold no emparejado. Comunica precisión, recall y F1 micro, soporte y recall por tipo, y define la agregación macro y los casos vacíos.

• F1 a nivel de entidad: La métrica estándar. Una predicción es correcta solo si coinciden exactamente tanto los límites del span como el tipo con el ground truth. Es lo que comunican la mayoría de los artículos.
• F1 a nivel de token: Puntúa cada token de forma independiente. Puede hacer que un límite parcial parezca mejor que una puntuación de span exacto, así que comunica F1 de span exacto cuando importe la corrección de los límites; utiliza métricas a nivel de token solo cuando la decisión posterior también se tome a nivel de token.
• Precisión frente a recall: Suelen tener costes asimétricos. En desidentificación, el recall importa más: no detectar un nombre es peor que redactar de más. En extracción para bases de datos, la precisión importa más: las entradas falsas corrompen el análisis posterior.

Errores habituales de evaluación

1. Inflación por coincidencia parcial: se extrae «Bill» cuando la etiqueta gold es «Bill Gates»; algunos scripts lo cuentan como coincidencia parcial. Utiliza matching de spans exactos salvo que tengas una razón para no hacerlo.
2. Confusión de tipos: identificar correctamente «Microsoft» como span pero etiquetarlo como PERSON en lugar de ORG debe puntuar cero. Comprueba que el código de evaluación lo gestione así.
3. Fuga en el conjunto de prueba: Mantén registros, documentos y anotaciones duplicados o casi duplicados fuera del conjunto de prueba. Para una afirmación hard zero-shot, mantén también los tipos de entidad objetivo fuera del entrenamiento; la repetición de strings de superficie por sí sola no constituye fuga.
4. Prompts de etiquetas no controlados: Un nombre de tipo corto y una descripción de tipo probada son entradas diferentes. Versiona las descripciones de las etiquetas, los umbrales, las revisiones de los checkpoints y el modo de decoding junto con la puntuación.
5. Afirmaciones zero-shot en un único idioma: No infieras la calidad multilingüe a partir del inglés. OpenNER abarca 36 corpus y 52 idiomas, y sus baselines no encontraron un único modelo que fuera el mejor en todos los idiomas (Palen-Michel et al., 2025). En experimentos de FiNERweb, cambiar del inglés a etiquetas en el idioma objetivo modificó F1 entre 0,02 y 0,09 según la configuración (Golde et al., 2026). Prueba ambos idiomas de etiquetas cuando el producto utilice terminología local.
6. Una única ejecución no es un veredicto: Comunica la variación entre random seeds cuando proceda, barridos de umbral y muestras de producción repetidas. Un número pequeño de ejemplos por slice hace inestable el ranking de modelos.

Mantén la normalización, el entity linking, la agrupación de registros y los extremos de las relaciones separados del F1 extractivo. Para privacidad, comunica las instancias filtradas y los documentos afectados aceptados automáticamente, las redacciones falsas y la fracción revisada. Para serving, comunica la tasa de finalización, la latencia por documento p50/p95, ejecuciones en frío y en caliente, tamaños de batch y de etiquetas, memoria máxima y coste por documento aceptado.

Construcción de un conjunto de prueba de dominio

Para la evaluación en producción, recomiendo:

1. Muestrea datos de producción, no ejemplos seleccionados. Incluye los documentos problemáticos que realmente verá el modelo.
2. Dimensiona el conjunto de prueba para la estimación que necesites. Elige el número a partir de la prevalencia de entidades, los tamaños de los slices por etiqueta y la amplitud deseada del intervalo de confianza. Comunica intervalos de confianza bootstrap o analíticos.
3. Utiliza al menos dos annotators en un subconjunto de calibración. Adjudica las discrepancias y comunica una medida de acuerdo sensible a spans. El acuerdo diagnostica la ambigüedad y la calidad de las directrices; no es un techo del rendimiento del modelo.
4. Estratifica por dificultad: casos fáciles (texto limpio, tipos estándar) y casos difíciles (entidades ambiguas, jerga, texto ruidoso).
5. Conserva slices de privacidad y fairness. Para PII, comunica el recall por tipo de PII, idioma, locale, formato documental y slices demográficos o relacionados con el origen de los nombres. Minimiza el acceso de los evaluadores al texto sensible en bruto, establece límites de retención y revisa los falsos negativos.

El NER continuo necesita un conjunto de regresión inmutable

Las taxonomías de producción cambian. Añade tipos nuevos sin cambiar silenciosamente el significado de los antiguos. Conserva un conjunto de regresión versionado e inmutable para los tipos existentes, un conjunto de prueba independiente para el tipo nuevo y un changelog de los cambios en las directrices de anotación. Comunica por separado las puntuaciones de los tipos antiguos y nuevos antes de sustituir un checkpoint. Es la forma más sencilla de detectar el forgetting y el drift de la taxonomía.

NER en producción en cuatro sectores

Estos son ejemplos sectoriales seleccionados con cifras concretas bajo las condiciones comunicadas. Las fuentes combinan comparaciones comunicadas por proveedores, estudios de caso comunicados por empresas o proyectos y artículos revisados por pares o preprints. Trátalos como ejemplos prácticos, no como un ranking de madurez.

Sanidad

Los ejemplos de John Snow Labs y Providence anteriores muestran por qué la desidentificación necesita informes tanto a nivel de entidad como de documento. Sus protocolos de evaluación son más útiles para diseñar una revisión que para establecer un ranking de proveedores sin matices.

La retrospectiva de OpenMed, publicada el 6 de enero de 2026, comunica 481 modelos; «más de 380» describe su inventario de lanzamiento de julio. Las descargas miden distribución, no despliegues. Su afirmación de liderar los resultados en 10 de 12 benchmarks procede de un preprint independiente de los autores de agosto de 2025, no de resultados de producción verificados de forma independiente.

NER financiero

La extracción financiera incluye menciones de empresas en noticias y campos en documentos regulatorios; sus esquemas y longitudes documentales son diferentes. El estudio de caso de CFM cubre el primer caso. FinBERT-MRC formula la extracción como machine reading comprehension y comunica 92,78±0,56 de F1 en ChFinAnn y 96,80±0,38 en AdminPunish, ambos datasets chinos. Estos resultados no demuestran precisión en documentos SEC en inglés. Prueba documentos largos y entidades financieras anidadas en el idioma previsto.

Comercio electrónico

El artículo de Walmart en KDD 2023 utiliza datos multitarea de consultas QU-965M; sus aproximadamente 60 etiquetas NER son clases IOB2. La sección 6.8 atribuye el incremento del 0,51 % en GMV al baseline MTDNN entrenado con esos datos, mientras que la evaluación online de EAMT quedó como trabajo futuro. El cambio de negocio no puede atribuirse únicamente a NER. El TripleLearn de Home Depot comunica una mejora del F1 en held-out de 69,5 a 93,3, un experimento online y más de nueve meses en producción. La lección transferible es la supervisión iterativa de dominio, no un ranking actual de arquitecturas.

Ciberseguridad

iACE es un ejemplo histórico de extracción automatizada de threat intelligence. El artículo de CyNER combina reconocimiento neuronal con otras fuentes de extracción y comunica 76,66 de span micro-F1 para XLM-RoBERTa-large, evaluado con seqeval. El preprint de CyberNER armoniza cuatro datasets en 21 etiquetas alineadas con STIX 2.1 y comunica 0,736 de F1 para RoBERTa. Son resultados de investigación, no evidencia de adopción en producción.

Optimización del despliegue: de Python a inferencia de menor latencia

El repositorio complementario demuestra la exportación de GLiNER a ONNX y el empaquetado INT8. Registra tamaños de artefactos, pero no reproduce las cifras de latencia o F1 comunicadas por proyectos externos.

Serving nativo de GLiNER

Antes de cambiar de runtime, prueba la ruta de Ray Serve del proyecto. gliner[serve] proporciona batching dinámico, dimensionamiento de batches consciente de la memoria, escalado con múltiples réplicas y un cliente HTTP. El batching y las réplicas pueden mejorar el throughput manteniendo el código del modelo; el batching también puede añadir tiempo de espera y las réplicas no eliminan las colas. Mide la latencia de cola, la latencia en caliente, el throughput y el F1 de span exacto con tu mezcla de peticiones antes de compararlo con ONNX o Rust.

Exportación a ONNX

GLiNER ofrece conversión nativa a ONNX y existen modelos preconvertidos en Hugging Face (onnx-community/gliner_small-v2.1). Mide la latencia frente al mismo checkpoint de PyTorch, con el mismo batch size, hardware y protocolo de warm-up.

Ejecuta scripts/02_onnx_export.py desde el repositorio complementario para exportar un modelo y aplicar quantization dinámica a su artefacto ONNX. Necesita ese entorno y descarga un checkpoint, por lo que es un comando que debe ejecutarse allí, no un fragmento autocontenido del artículo:

uv run python scripts/02_onnx_export.py

Quantization INT8

La quantization dinámica puede reducir los requisitos de almacenamiento y memoria de un modelo ONNX. El efecto sobre la latencia y el F1 por etiqueta depende del checkpoint y de la CPU, por lo que el script de exportación es evidencia del empaquetado, no un benchmark de despliegue.

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: reimplementación en Rust

gline-rs (Apache 2.0) elimina el runtime de Python de la ruta de inferencia. Su benchmark v0.9.0 en modo token, sobre un Intel i9 con tres etiquetas, comunica 6,67 seq/s frente a 1,61 de Python, con 100 muestras de NuNER. Un experimento independiente v0.9.1 con una RTX 4080 sobre 1.000 muestras comunica 248,75 seq/s, sin una comparación equivalente con Python en GPU. Son las condiciones del propio proyecto, no resultados reproducidos por el repositorio complementario. Admite modelos de spans y tokens, GPU/NPU mediante ONNX Runtime y se distribuye como crate en 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%)

El paquete fast-gliner proporciona bindings de Python mediante PyO3.

Qué cubre la evidencia de optimización

Extracción estructurada: esquemas nativos, Instructor y decoders locales

Cuando necesites más flexibilidad de la que ofrecen los modelos encoder —entidades implícitas, razonamiento, mapeo de ontologías— empieza por el mecanismo de esquemas nativo del proveedor. OpenAI admite formatos de respuesta estrictos json_schema, Anthropic structured outputs admite salidas JSON y tool inputs estrictos, y la Gemini API admite un subconjunto de JSON Schema. Un modelo compartido de Pydantic o Zod puede describir el contrato, pero cada proveedor acepta un subconjunto de esquemas diferente y tiene un comportamiento distinto ante rechazos y complejidad.

La conformidad con el esquema hace fiable el parsing. No demuestra que un span extraído exista en el texto de origen ni que un valor normalizado sea correcto. Valida los valores de los campos, conserva offsets o citas cuando sea posible y puntúa la precisión semántica con un conjunto etiquetado.

Instructor envuelve los clientes de los proveedores con validación de Pydantic y reintentos opcionales tras fallos de validación.

Adaptado del patrón de Instructor en scripts/05_structured_extraction.py. Requiere los paquetes enumerados y un OPENAI_API_KEY; el script complementario recurre a GLiNER cuando no hay ninguna clave disponible. Este artículo utiliza ahora GPT-5.6 Terra, cuya model card admite Chat Completions, function calling, structured outputs y none reasoning effort. Compáralo con el baseline antiguo más barato antes de cambiar un extractor de alto volumen; una nueva generación no demuestra una precisión NER superior.

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'), ...]

Outlines, de dottxt, adopta otro enfoque: generación restringida de tokens mediante máquinas de estados finitos. El decoder enmascara los tokens que infringirían la gramática objetivo en lugar de esperar a un fallo de validación y reintentar. Un resumen de AWS cita un 98 % de adherencia al esquema frente al 76 % de la validación posterior a la generación. También repite por separado la afirmación de hasta 5 veces más velocidad de generación de .txt Engineering gracias a su enfoque de coalescence; la página no publica metodología suficiente para tratar ambas cifras como un único benchmark controlado.

El pequeño ejemplo local siguiente mantiene Phi-3 como ejemplo histórico de integración de un decoder, no como recomendación de modelo para 2026. Para una comparación nueva de extracción self-hosted, incluye Qwen3.8-27B o los checkpoints Qwen3.5 más pequeños. Utiliza el model loader, chat template y serving backend documentados para esos modelos; cambiar únicamente el string siguiente no demuestra compatibilidad con una arquitectura multimodal ni con su formato de razonamiento.

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,
)

LangExtract resulta útil cuando un campo generado debe estar fundamentado en la fuente: devuelve intervalos de caracteres y admite backends de LLM alojados o locales. Para extracción documental self-hosted, NuExtract convierte esquemas JSON en templates e incluye modelos documentales multimodales. Trata ambos como sistemas de extracción estructurada, no como sustitutos automáticos del NER de spans. Sus objetivos de campos, offsets, layout documental y latencia requieren pruebas propias.

La elección depende de dónde ejecutes tus modelos. Los esquemas nativos son la ruta con menos fricción para un proveedor compatible. Instructor añade una capa agnóstica del proveedor de validación y reintentos con Pydantic. Outlines restringe la generación local según un esquema. LangExtract prioriza el grounding en la fuente, mientras que NuExtract se orienta a la extracción documental self-hosted. Todas las rutas con LLM incluyen generación autoregresiva. Compara cada ruta con un encoder usando el mismo batch size, hardware, esquema de entidades y rúbrica de precisión semántica.

La arquitectura de producción de tres niveles

Yo dirigiría el NER de producción según la forma de la tarea, no según el ranking de un único modelo.

Nivel 1: modelos encoder para spans explícitos. Utiliza un cross-encoder de GLiNER para un inventario pequeño de tipos. Cuando se reutilice un inventario grande, compara el bi-encoder con embeddings de tipos cacheados. Haz fine-tuning mediante el pipeline de LLM-as-teacher y despliega con serving nativo, ONNX, INT8 o gline-rs solo cuando esa ruta supere el benchmark de dominio.

Nivel 2: extracción multitarea o de relaciones. Cuando una petición necesite NER, clasificación y campos jerárquicos, prueba el checkpoint actual de GLiNER2.5 con 194M parámetros frente a baselines independientes por tarea. Cuando el requisito central sean spans y relaciones conjuntas, prueba GLiNER-Relex. El artículo de GLiNER2 comunica una latencia de clasificación en CPU de 130-208 ms para los recuentos de etiquetas evaluados; no constituye evidencia para la API de relaciones posterior ni para un despliegue diferente.

Nivel 3: LLMs para extracción con mucho razonamiento. Dirige las entidades implícitas, la inferencia contextual y el mapeo de ontologías a una API de esquemas nativa o Instructor para APIs cloud, y a Outlines para salidas locales restringidas. Utiliza LangExtract cuando los intervalos de la fuente sean esenciales y NuExtract cuando el propio documento sea la entrada. Registra estos casos para revisión. Solo los spans explícitos y alineados con la fuente pueden convertirse en objetivos de entrenamiento ordinarios del Nivel 1; los hechos inferidos y los valores normalizados necesitan objetivos y evaluación propios.

El estudio de caso de CFM proporciona una referencia de coste para el Nivel 1: 93,4 % de F1 con un coste comunicado de $0.10 por hora en CPU, frente al 92,7 % de F1 y $8 por hora de su teacher Llama-70B. Los precios por hora de las instancias no determinan el coste por documento sin conocer el throughput. Recalcula con tu hardware, modelo teacher, conjunto de etiquetas, utilización y coste de revisión.

Compromisos y limitaciones

Para cada compromiso siguiente, las preguntas útiles son dónde aparece y si puedes medirlo antes del despliegue.

Los errores del LLM-as-teacher se propagan. Si el LLM se equivoca sistemáticamente con un tipo de entidad concreto (por ejemplo, confunde nombres de filiales con los de sus matrices), el encoder con fine-tuning hereda ese sesgo. Revisa intensivamente los tipos con baja confianza o inconsistentes y conserva una muestra aleatoria estratificada para detectar errores sistemáticos confiados.

Un esquema válido puede contener hechos falsos. La salida estructurada nativa, Instructor y los decoders restringidos pueden hacer que una respuesta sea parseable. No pueden garantizar que todos los campos estén fundamentados, que los límites de los spans sean correctos o que un valor normalizado corresponda al registro adecuado. Conserva la evidencia de origen y valida la semántica por separado.

Las pérdidas por quantization dependen del checkpoint y de los datos. El repositorio complementario crea un artefacto INT8 con quantization dinámica, pero no mide su F1. Las directrices actuales de GLiNER recomiendan quantization-aware training cuando haya que preservar la precisión INT8. Compara los checkpoints quantizado y original en F1 de span exacto y recall por etiqueta antes del despliegue.

Cuándo sobra la arquitectura de tres niveles. Un único dominio con tipos de entidad estables y suficientes ejemplos etiquetados quizá solo necesite un pipeline de RoBERTa con fine-tuning o de spaCy. El patrón de tres niveles encaja con múltiples dominios, tipos de entidad cambiantes o una mezcla medida de extracción explícita y con mucho razonamiento. Un pipeline de facturas limitado que extraiga nombres y fechas puede detenerse en el Nivel 1.

La calidad del bi-encoder varía según el dataset. La codificación conjunta puede ayudar en algunos datasets, mientras que el bi-encoder gana la comparación de CrossNER del artículo y el uni-encoder lo supera ligeramente en CoNLL-2003. Evalúa ambos con el conjunto de dominio; elige basándote en la calidad de span exacto, la calibración, el número de etiquetas y el throughput medidos, no utilizando «high stakes» como regla de familia de modelos.

Las afirmaciones sobre PII y multilingüismo necesitan slices. Una puntuación agregada alta puede ocultar una pérdida peligrosa de recall para un locale, una forma de nombre, un layout documental o una clase rara de PII. Trata el modelo de privacidad como una defensa en profundidad, establece un proceso de respuesta a falsos negativos y vuelve a evaluarlo cuando cambien la taxonomía, la mezcla de idiomas o la fuente de datos.

Conclusiones clave

1. Utiliza un encoder compacto para spans explícitos solo después de que supere un conjunto de prueba de dominio con soporte por tipo e intervalos de confianza.
2. Utiliza GLiNER para vocabularios de etiquetas cambiantes. Compara primero su bi-encoder cuando se reutilice un inventario amplio de tipos; activa flat_ner=False solo después de medir la calidad con spans anidados.
3. Utiliza descripciones de tipos probadas para afirmaciones hard zero-shot y evalúa por separado la redacción de etiquetas en inglés y localizada para productos multilingües.
4. Mantén OCR, NER, extracción de relaciones y entity linking como etapas de evaluación distintas, aunque un modelo exponga varias tareas.
5. Trata al LLM teacher como un sistema que propone anotaciones. Siguen siendo necesarias las directrices humanas, la adjudicación, los conjuntos de regresión inmutables y un conjunto de prueba held-out.
6. Utiliza esquemas nativos para proveedores de LLM compatibles, pero valida por separado la corrección semántica y el grounding en la fuente respecto a la validez de JSON.
7. Evalúa por separado y conjuntamente las rutas de serving nativo, ONNX, quantization y Rust. No multipliques nunca aceleraciones no medidas.

Referencias

Artículos

• GLiNER: Generalist Model for Named Entity Recognition using Bidirectional Transformer - Zaratiana et al., NAACL 2024. La arquitectura fundacional de matching entre spans y entidades.
• GLiNER2: An Efficient Multi-Task Information Extraction System with Schema-Driven Interface - Zaratiana et al., EMNLP 2025 System Demonstrations. Unifica NER, clasificación y extracción jerárquica; las versiones actuales añadieron posteriormente la extracción de relaciones.
• GLiNER Bi-Encoder: Scalable Named Entity Recognition with Bi-Encoder Architecture - Stepanov et al., febrero de 2026. Codificación desacoplada para escala de millones de etiquetas.
• GLiNER-Relex: A Unified Framework for Joint Named Entity Recognition and Relation Extraction - Stepanov et al., 2026. Extracción conjunta y zero-shot de entidades y relaciones.
• GLiNER2-PII: A Multilingual Model for Personally Identifiable Information Extraction - Zaratiana et al., 2026. 42 tipos de PII con resolución a nivel de span de caracteres.
• ZeroNER: Fueling Zero-Shot Named Entity Recognition via Entity Type Descriptions - Cocchieri et al., ACL 2025. Evaluación hard zero-shot con descripciones de tipos.
• OpenNER 1.0: Standardized Open-Access Named Entity Recognition Datasets in 50+ Languages - Palen-Michel et al., EMNLP 2025. 36 corpus, 52 idiomas y baselines multiontología.
• FiNERweb: Datasets and Artifacts for Scalable Multilingual Named Entity Recognition - Golde et al., EACL 2026. Etiquetas multilingües y evaluación de transferencia.
• UniversalNER: Targeted Distillation from Large Language Models for Open Named Entity Recognition - Zhou et al., ICLR 2024. NER universal basado en LLMs mediante destilación de ChatGPT.
• NuNER: Entity Recognition Encoder Pre-training via LLM-Annotated Data - Bogdanov et al., EMNLP 2024. Estudia un encoder de 125M preentrenado con anotaciones de LLMs.

Artículos industriales

• EAMT: Entity-Aware Multi-Task Learning for Query Understanding - Walmart, KDD 2023. Estudio multitarea de consultas; el resultado online pertenece a su baseline MTDNN.
• TripleLearn: End-to-End NER for E-Commerce Search - Home Depot, AAAI 2021. F1 de 69,5 a 93,3.
• Acing the IOC Game: Toward Automatic Discovery and Analysis of Open-Source Cyber Threat Intelligence - Liao et al., CCS 2016. Enfoque histórico de extracción.
• CyberNER: A Harmonized STIX Corpus for Cybersecurity NER - 21 tipos de entidad alineados con STIX 2.1.
• FinBERT-MRC: Financial NER via Machine Reading Comprehension - Formulación MRC evaluada en datasets financieros chinos.

Estudios de caso

• CFM Case Study: Fine-tuning GLiNER for Financial NER - Pipeline de etiquetado con LLMs de $70 de Capital Fund Management que alcanza un 93,4 % de F1.
• Refuel AI: LLM Labeling Technical Report - GPT-4 alcanza un 88,4 % de acuerdo en la anotación, superando a los annotators humanos.
• Sease: GLiNER as an Alternative to LLMs for Query Parsing - Dónde falla GLiNER y por qué los LLMs siguen siendo necesarios.
• John Snow Labs: Medical Text De-Identification Benchmark - Estudio del proveedor con reasignación y exclusiones de etiquetas.
• OpenMed: Year in Review 2025 - Retrospectiva de enero de 2026; el inventario y las descargas no son despliegues.

Herramientas y frameworks

• ner-field-guide demo repo - Demos complementarias para este artículo: quickstart de GLiNER, exportación a ONNX, LLM-as-teacher y extracción estructurada.
• gline-rs: Rust reimplementation of GLiNER - Experimentos independientes del maintainer en CPU y GPU; código Apache 2.0.
• GLiNER serving - Ruta de Ray Serve con batching dinámico y despliegue con múltiples réplicas.
• spaCy English pipelines - Métricas versionadas de un pipeline de etiquetas cerradas.
• Microsoft Presidio - Análisis de PII y anonimización con recognizers personalizados.
• Instructor - Extracción estructurada con LLMs mediante modelos de Pydantic.
• Outlines - Generación restringida de tokens mediante FSMs, con un benchmark comunicado de adherencia al esquema.
• LangExtract - Extracción estructurada fundamentada en la fuente con intervalos de caracteres.
• NuExtract - Extracción documental self-hosted de esquema a template.
• OpenAI Structured Outputs - Referencia del formato de respuesta estricto basado en JSON Schema.
• Anthropic Structured Outputs - Salidas JSON y tool inputs estrictos.
• Gemini Structured Outputs - Subconjunto de JSON Schema para respuestas estructuradas.
• AWS: Structured Output with Outlines - Benchmark de adherencia al esquema del 98 %.