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

La guía definitiva sobre NER en 2026: codificadores, LLMs y la arquitectura de producción de 3 capas

El reconocimiento de entidades nombradas (NER) abarca ahora codificadores compactos, modelos de vocabulario abierto y extracción basada en LLM. En los resultados presentados de CrossNER, un modelo GLiNER con 300 millones de parámetros supera el valor de F1 sin entrenamiento previo del modelo UniNER de 13 mil millones de parámetros. Un bi-codificador más reciente muestra una capacidad de procesamiento 130 veces mayor que el codificador cruzado original, permitiendo manejar 1.024 tipos de entidades. Estos resultados respaldan un patrón práctico para la extracción explícita de intervalos: utilizar un LLM para etiquetar los datos del dominio, revisar una muestra, ajustar finamente un codificador compacto y desplegarlo con ONNX o Rust.

El repositorio complementario ofrece ejemplos ejecutables para GLiNER, la exportación de ONNX, las etiquetas de entrenamiento generadas mediante LLM y la extracción estructurada. En trabajos donde predominan los segmentos explícitos, los codificadores compactos proporcionan una solución eficaz en términos de latencia y costes. Por su parte, los LLMs siguen siendo útiles para generar datos de entrenamiento y gestionar casos que requieren inferencia o normalización.

Repositorio complementario: ner-guía de campo, incluye demostraciones ejecutables para GLiNER, la exportación ONNX, el LLM-como-profesor pipeline, y la extracción estructurada con Instructor.

TL;DR: Empiece utilizando GLiNER cuando necesite extracción de segmentos con vocabulario abierto y despliegue de CPU. Para tareas específicas de un dominio, pruebe el método LLM-como-profesor pipeline: genere etiquetas, revise una muestra, ajuste finamente un codificador y evalúe su rendimiento en un conjunto etiquetado por humanos. Dirija los casos que involucren entidades implícitas, mapeo ontológico y otro tipo de razonamiento complejo a un LLM a través de Instructor o Outlines. La arquitectura de tres niveles combina estos enfoques sin establecer una distribución fija del tráfico.


Donde utilizan los sistemas modernos NER

NER sigue detectando segmentos 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 las herramientas de agente, y campos destinados al procesamiento de documentos mediante pipelines. Gracias a estos usos, la latencia, el costo y la flexibilidad del esquema adquieren tanta importancia como la precisión de benchmark.

RAG: una mejor recuperación gracias a la extracción de entidades

La búsqueda por similitud por sí sola tiene dificultades cuando una consulta incluye entidades exactas. En el caso de la pregunta “¿Qué dijo Anthropic sobre la seguridad de los modelos en el cuarto trimestre de 2024?”, el sistema debe extraer “Anthropic” y “Q4 2024” como filtros de metadatos, en lugar de depender únicamente de embeddings.

Durante el proceso de indexación, se extraen las entidades de cada bloque y se almacenan como metadatos: {"organizations": ["Anthropic"], "dates": ["Q4 2024"], ...}. Esto permite filtrar por entidad antes de ejecutar la búsqueda vectorial. El grafo de conocimiento RAG (GraphRAG, grafos de propiedades de LlamaIndex) va aún más allá: mediante NER junto con la extracción de relaciones se construye un grafo capaz de responder a preguntas de múltiples pasos que los embeddings planos no pueden abordar.

Durante el tiempo de consulta, las entidades extraídas de la pregunta del usuario determinan la ruta a seguir. Una pregunta que mencione el nombre de una empresa es dirigida a un índice financiero; una que haga referencia a nombres de fármacos, a una base de conocimientos clínicos. GLiNER funciona bien en este escenario porque las entidades de las consultas son impredecibles: no es posible volver a entrenar el modelo para cada nuevo tipo de entidad sobre el que los usuarios puedan preguntar.

AI agentes: transformación de texto en datos estructurados

Los agentes reciben texto no estructurado —páginas web, respuestas de API, mensajes de usuarios— y deben tomar medidas al respecto. NER transforma dicho texto en datos estructurados sobre los cuales el agente puede razonar, almacenar o transmitirlos a herramientas externas.

Dos aspectos en los que es más importante.

El primero es el enrutamiento de herramientas. Cuando un usuario indica “programar una reunión con Sarah Chen de Accenture el jueves a las 2 p.m.”, el agente debe extraer PERSON: Sarah Chen, ORGANIZATION: Accenture, y DATETIME: Thursday 2pm Antes de llamar al calendario API. Un modelo encoder NER realiza esta operación en menos de 10 ms. Un LLM añade entre 1 y 2 segundos por llamada, y ese retraso se acumula en flujos de trabajo de múltiples pasos hasta el punto de que un agente “instantáneo” deja de serlo realmente.

El segundo aspecto es el seguimiento de entidades a lo largo de las conversaciones. Los sistemas de memoria del agente deben ser capaces de reconocer que “Sarah” en el turno 3 y “Sra. Chen” en el turno 12 se refieren a la misma persona. NER sirve para identificar dichos segmentos de texto; el enlace de entidades los relaciona con el mismo ID.

En ambos casos, la limitación principal es la latencia. Una llamada de 200 ms con NER dentro de una cadena de agentes formada por 10 pasos genera un retraso percibido de 2 segundos. Por eso, los modelos codificadores, y no el método de extracción basado en LLM, son la opción adecuada para el procesamiento de entidades dentro de los bucles de agentes.

Inteligencia en documentos: de las imágenes a datos estructurados

OCR convierte imágenes en texto. NER transforma el texto en campos estructurados. Juntos, permiten llevar a cabo la digitalización de documentos a gran escala.

Un pipeline estándar utiliza primero OCR, como Tesseract, Azure Document Intelligence o AWS Textract, para generar texto y cuadros delimitadores. A continuación, el NER extrae campos tales como invoice_number, vendor_name, line_items, total, y due_date. La misma lógica se aplica a los contratos, los historiales médicos y las solicitudes regulatorias.

Las plataformas modernas integran tres pasos: la comprensión del esquema (¿se trata de un encabezado o de una celda de tabla?), la extracción de entidades (¿qué tipo de texto es este?) y la extracción de relaciones (¿qué valores están relacionados?). GLiNER 2 gestiona los tres en una sola pasada forward; una única llamada al modelo puede devolver {vendor: "Acme Corp", amount: "\$4,200", due_date: "2026-04-15"} de una factura.

Aquí es donde el costo adquiere importancia. Se debe fijar el precio de pipeline en función del volumen real mensual de documentos, teniendo en cuenta las reintentos y las revisiones. Un codificador compacto puede ejecutarse sobre CPU, mientras que un LLM basado en API genera un costo adicional por inferencia y mayor latencia por documento. Una prueba práctica consiste en etiquetar un conjunto representativo de facturas con LLM, ajustar parámetros de GLiNER mediante los registros revisados, y comparar ambos enfoques en términos de puntuación F1 a nivel de campo, latencia y costo total.

Detección de PII y restricciones de LLM

Las normativas de privacidad (GDPR, HIPAA, CCPA) exigen localizar los datos personales antes de que lleguen a los sistemas posteriores. En el caso de las implementaciones de LLM, esto implica realizar un escaneo de las entradas antes de que lleguen al modelo y de las salidas antes de que lleguen al usuario.

NER se ocupa de esto directamente. Los modelos de desidentificación detectan PERSON, SSN, PHONE, EMAIL, y ADDRESS Los span se deben eliminar o reemplazar por equivalentes sintéticos. En su propia comparativa de proveedores, John Snow Labs publica sus informes 96 % de F1 en la detección de PHI, frente al 91 % de Azure, el 83 % de AWS y el 79 % de GPT-4o. Un informe de despliegue independiente indica que Providence procesa más de 100.000 notas clínicas al día.

En cuanto a las restricciones de LLM, NER funciona como una capa de preselección: escanea la entrada del usuario en busca de PII antes de enviarla a un API externo, y posteriormente bloquea o anonimiza dicha información. Este método es más rápido y sencillo que solicitar al LLM que se automodere. GLiNER resulta especialmente útil en este contexto, ya que las categorías de PII varían según la jurisdicción. Es posible añadir nuevos tipos de entidades, como “información genética”, en virtud de nuevas regulaciones, sin necesidad de realizar un reentrenamiento.


GLiNER transforma la economía NER mediante un modelo de 300 millones de parámetros

GLiNER (NAACL 2024, Zaratiana et al.) logró que los métodos basados en codificador NER fueran competitivos con LLMs a una fracción del costo. En lugar de tratar NER como un proceso de etiquetado de secuencias o generación de texto, GLiNER lo aborda como un problema de coincidencia: se calcula la puntuación de cada rango de texto candidato (cada secuencia contigua de palabras como “Bill Gates” o “Microsoft”) frente a cada etiqueta de tipo de entidad, y posteriormente se conservan las parejas con mayor puntuación.

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 transformador bidireccional (DeBERTa-v3) codifica todo junto.

A partir de la salida, el modelo genera dos conjuntos de representaciones: uno para los tipos de entidad (provenientes de [ENT] una para las posiciones de tokens y otra para los intervalos de texto (obtenidos al combinar los vectores de token de inicio y fin mediante una pequeña red FFN). El producto escalar entre la representación de un intervalo y la representación del tipo de entidad genera una puntuación.

Al aplicar la función sigmoide se obtiene la probabilidad de que el rango que va desde el token ii hasta el token jj pertenezca al tipo de entidad tt: ϕ(i,j,t)=σ(SijTqt)\phi(i, j, t) = \sigma(S_{ij}^T \cdot q_t), donde SijS_{ij} es el vector de rango generado por la FFN y qtq_t es el tipo de entidad embedding correspondiente [ENT] token (Zaratiana et al., 2024, Eq. 1). Los span tienen un límite máximo de 12 tokens para garantizar una ejecución rápida.

Arquitectura GLiNER: los tokens de tipo entidad y los tokens de texto se codifican conjuntamente mediante DeBERTa, y posteriormente las representaciones de los intervalos se evalúan en relación con el tipo de entidad embeddings mediante producto escalar.

En la práctica, eso significa que cualquier descripción en lenguaje natural puede funcionar como etiqueta en el momento de la inferencia. No es necesario realizar un reentrenamiento. Se introducen los tipos de entidad que se deseen (“persona”, “reacción adversa a fármacos”, “instrumento financiero”), y el modelo evalúa los intervalos en función de ellos. Están disponibles tres tamaños: GLiNER-S (50M parámetros), GLiNER-M (90M) y GLiNER-L (300M). Los datos de entrenamiento provienen de Pile-NER dataset: 44,889 pasajes con 240K intervalos de entidad correspondientes a 13K tipos de entidad, todos etiquetados por ChatGPT. El entrenamiento de GLiNER-L tarda aproximadamente 4 horas en una sola unidad A100.Zaratiana et al., 2024).

Resultados de Benchmark

Resultados de tipo zero-shot provenientes de Zaratiana y colaboradores (2024), Tablas 1 y 2:

ModeloParámetrosF1 de CrossNERPromedio (20 datasets)
GLiNER-L300 millones60.9%47.8%
GoLLIE7B58.0%
UniNER-13B13 mil millones55.6%
GLiNER-M90 millones55.4%
UniNER-7B7B53.7%45.7%
GLiNER-S50 millones52.7%
ChatGPT (GPT-3.5)47.5%36.5%

GLiNER-M, con 90 millones de parámetros, casi iguala a UniNER-13B en la tabla CrossNER del artículo (55,4 % frente a 55,6 % de F1), aunque utiliza aproximadamente 140 veces menos parámetros. La versión GLiNER-S, con 50 millones de parámetros, supera el resultado reportado para ChatGPT (GPT-3.5) en 5 puntos de F1. La variante multilingüe, entrenada únicamente con datos en inglés, supera a ese mismo estándar de ChatGPT en 8 de las 10 lenguas no inglesas.Zaratiana et al., 2024). Estas comparaciones emplean las versiones de modelo y los métodos de evaluación descritos en el artículo harness; no permiten establecer una clasificación relativa con las versiones más recientes de LLMs.

El ecosistema es muy amplio: más de 280 modelos compatibles con GLiNER en HuggingFace, ~350.000 descargas desde PyPI al mes, y aproximadamente 2.800 estrellas en GitHub. Las variantes existentes abarcan texto biomédico, detección de PII, noticias, además de soporte multilingüe.

Desde quickstart.py:

from gliner import GLiNER

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

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

Cómo se compara GLiNER con spaCy

Cualquier guía sobre NER quedaría incompleta sin spaCyAproximadamente 21 millones de descargas al mes, y una de las bibliotecas de NLP más robustas para entornos de producción. No obstante, funciona bajo restricciones arquitectónicas radicalmente distintas a las de GLiNER.

el componente pipelines de spaCy (en_core_web_sm, en_core_web_trf) se realiza un vocabulario cerrado NER: un conjunto fijo de tipos de entidad (PERSON, ORG, GPE, DATE, etc.) definido en el momento del entrenamiento. ¿Se desea añadir un nuevo tipo de entidad? Es necesario recopilar datos etiquetados y volver a entrenar el modelo. Basado en transformadores. en_core_web_trf consultas 89,8 % de F1 en OntoNotes 5.0, pero únicamente para sus 18 tipos predefinidos.

GLiNER cuenta con vocabulario abierto NER: en el momento de la inferencia se puede utilizar cualquier etiqueta, sin necesidad de realizar un reentrenamiento. Esto lo convierte en la opción más adecuada cuando los tipos de entidades son desconocidos de antemano, cambian con frecuencia o son específicos de un dominio concreto (“reacción adversa a fármacos”, “instrumento financiero”, “indicador de amenaza”).

Mi recomendación es utilizar spaCy para los tipos de entidad estándar, donde los modelos preentrenados pipelines están ampliamente validados. Por su parte, se debe emplear GLiNER cuando sea necesario contar con tipos flexibles y de tipo zero-shot, o bien cuando sus pipeline deban adaptarse sin necesidad de realizar un reentrenamiento. Ambos frameworks pueden compartir un pipeline, siendo spaCy el encargado de la tokenización y la división en oraciones, mientras que GLiNER se ocupa de la extracción de entidades.


UniNER y NuNER: ¿hasta qué punto se puede reducir el tamaño?

UniNER (ICLR 2024, Zhou et al.) y NuNER (EMNLP 2024, Bogdanov et al.) ambos extraen las anotaciones LLM y las condensan en modelos NER de menor tamaño; sin embargo, difieren en cuanto al límite mínimo al que se puede reducir dicho tamaño.

UniNER: el enfoque maximalista

UniNER realiza un ajuste fino de LLaMA-7B/13B con 44,889 pares NER (240K entidades, 13K tipos) generados por ChatGPT. Para cada tipo de entidad, el modelo responde a “¿Qué describe [tipo] en el texto?” y genera listas JSON. Un truco clave en el entrenamiento es el muestreo negativo basado en frecuencia, que permite elevar el valor de F1 de 31.5 % hasta 53.4 %.Zhou et al., 2024).

UniNER-7B alcanza un 41.7 % de F1 sin entrenamiento previo en 43 datasets, superando así el 34.9 % de ChatGPT por 7 puntos. La variante de 13B logra un 43.4 %, solo 1.7 puntos más, a pesar de requerir casi el doble de recursos computacionales.Zhou et al., 2024).

El problema de producción: al tratarse de un modelo autoregresivo de 7 mil millones de parámetros, UniNER necesita N pasos forward para cada uno de los N tipos de entidades, consume 14 GB+ VRAM (lo que significa que ya se agota tu presupuesto de GPU antes incluso del almuerzo), y está sujeto a una licencia restrictiva CC BY-NC 4.0.

NuNER: el enfoque minimalista

NuNER parte de RoBERTa-base (125 millones de parámetros) y emplea entrenamiento contrastivo con 4,38 millones de anotaciones de GPT-3.5 correspondientes a 200 mil conceptos, lo que supone un costo total de anotación inferior a $500. Tras el entrenamiento, el codificador de conceptos se descarta; el codificador de texto se integra en cualquier NER pipeline estándar como sustituto de RoBERTa (Bogdanov y colaboradores, 2024).

Resultados: NuNER supera a la versión simple de RoBERTa en 6-15 puntos F1 en todos los tamaños de ejemplos pocos. Con tan solo una docena de ejemplos por tipo de entidad, NuNER alcanza el rendimiento de UniNER-7B a pesar de ser 56 veces más pequeño.Bogdanov y colaboradores, 2024).

Ambos artículos respaldan la destilación de las anotaciones LLM en modelos NER más compactos. NuNER demuestra que un codificador de 125 millones de parámetros puede alcanzar los mismos resultados que el UniNER-7B reportado cuando se dispone de datos fine-tuning específicos para la tarea, todo ello bajo una licencia MIT y con una inferencia compatible con CPU.


GLiNER 2: un modelo, cuatro tareas

El ecosistema original de GLiNER presentaba un problema cada vez más grave: la existencia de modelos independientes para NER (GLiNER), la extracción de relaciones (GLiREL), la clasificación (GLiClass) y la extracción de relaciones a nivel de documento (GLiDRE); cada uno de ellos requería su propia implementación, contenedor Docker, sistema de monitoreo y mecanismos para hacer frente a fallos. GLiNER 2 (EMNLP 2025, Zaratiana et al.) integra los cuatro en un único modelo de 205 millones de parámetros que cuenta con una interfaz basada en esquemas.

La arquitectura mantiene el diseño de codificador cruzado, pero amplía el contexto a 2,048 tokens (4 veces el valor original) e incorpora esquemas declarativos para definir tareas de extracción. El entrenamiento se realiza con 135,698 documentos reales anotados con GPT-4o, además de 118,636 ejemplos sintéticos.Zaratiana et al., 2025).

En el escenario de CrossNER sin entrenamiento previo, GLiNER 2 obtiene una puntuación de 0.590 F1, cercana a los 0.599 de GPT-4o según los resultados del estudio de mediados de 2025 benchmark. En cuanto a la clasificación, su promedio es de 0.72 en 7 benchmarks, frente a los 0.69 registrados por DeBERTa-v3-large. Respecto a CPU, el estudio indica una latencia de clasificación de 130-208 ms para los diferentes números de etiquetas probadas. La línea de referencia DeBERTa aumenta de 1,714 ms con 5 etiquetas a 16,897 ms con 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"))
results = extractor.extract(text, schema)

En las aplicaciones que requieren las cuatro tareas, el modelo compartido puede sustituir a cuatro implementaciones independientes, manteniendo la precisión reportada en el artículo original.


El bi-encoder: escalado a millones de etiquetas NER

El GLiNER original codifica las etiquetas y el texto junto, lo que genera un cuello de botella. Cada tipo de entidad adicional prolonga la secuencia de entrada, y el rendimiento disminuye rápidamente cuando se superan unas 30 entidades. El GLiNER bi-encoder (febrero de 2026, Stepanov et al.; arXiv 2602.18487) soluciona este problema al dividir la codificación del texto y de las etiquetas en dos transformadores independientes.

Codificador cruzado frente a codificador bilateral: el codificador cruzado codifica de forma conjunta las etiquetas y el texto, mientras que el codificador bilateral emplea codificadores independientes con etiquetas precomputadas embeddings

El codificador de texto emplea ModernBERT (familia Ettin), mientras que el codificador de etiquetas utiliza sentence transformers (BGE o MiniLM). Las subsecuencias y las etiquetas se evalúan mediante el producto escalar. La ventaja radica en que el tipo de entidad embeddings puede calcularse por adelantado una sola vez y guardarse en caché. Durante la inferencia, solo es necesario codificar el texto; la búsqueda de las etiquetas se realiza de forma instantánea.

Existen cuatro tamaños de modelo disponibles, todos evaluados en CrossNER.Stepanov y colaboradores, 2026, Tabla 1):

ModeloParámetrosF1 de CrossNERCon etiquetas precomputadas
bi-edge-v2.060 millones54.0%13,64 ex/s24,62 ex/s
bi-small-v2.0108 millones57.2%7,99 €/s15,22 ex/s
bi-base-v2.0194 millones60.3%5.91 ex/s9.51 ex/s
bi-large-v2.0530 millones61.5%2,68 ex/s3,60 ex/s

Con 1,024 tipos de entidad, el bi-encoder (de borde, precomputado) pierde solo un 5.2 % de rendimiento en comparación con un único etiquetado. El cross-encoder, por su parte, ve disminuir su rendimiento en un 98.7 % (de 10.7 a 0.14 ex/s). Esto supone una ventaja de rendimiento de 130 veces a escala masiva. Al contar con 100 tipos de entidad en un único H100, el bi-encoder procesa 1.96 millones de predicciones al día, frente a las 368K que logra el cross-encoder.Stepanov y colaboradores, 2026).

La precisión también se mantiene sólida. El Bi-encoder-large alcanza un 61,5 % de F1 en CrossNER, ligeramente por encima del 60,9 % del cross-encoder. Los autores recomiendan bi-base-v2.0 (194M) como la opción óptima, ya que logra el 98 % de la precisión del modelo grande a una velocidad 2,6 veces mayor.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)

Las aplicaciones incluyen el análisis biomédico NER basado en la ontología UMLS (más de 4 millones de conceptos), taxonomías empresariales que evolucionan sin necesidad de volver a entrenar los modelos, y el enlazamiento de entidades a través del complemento correspondiente. GLiNKER framework.


LLMs como instructores: un estudio de caso por valor de 70 dólares y un pipeline listo para desplegarse

El patrón LLM-como-profesor@@ separa la anotación, que es un proceso costoso, de la inferencia, que es más económica. Dos estudios de caso publicados muestran cómo los equipos lo han aplicado en condiciones distintas.

El LLM-como-profesor pipeline: LLM etiqueta los datos brutos; los humanos revisan un subconjunto, el codificador se ajusta mediante fine-tuning y se despliega con un costo 80 veces menor

El estudio de caso de CFM

En un estudio de caso Hugging Face, Capital Fund Management extrajo los nombres de las empresas de aproximadamente 900.000 titulares de noticias financieras. El método GLiNER sin entrenamiento previo obtuvo una puntuación de 87,0 % en F1. El equipo utilizó Llama 3.1-70B para anotar los dataset en unos 8 horas, lo que costó alrededor de 70 dólares, y posteriormente revisó 2.714 muestras mediante Argilla en otras 8 horas más.

Fine-tuning En el estudio de caso, GLiNER alcanzó un valor de 93,4 % F1 con estos datos, frente al 92,7 % obtenido por el modelo maestro Llama-70B. Los autores indican que el coste de uso del modelo afinado asciende a $0,10 por hora en CPU, mientras que el modelo maestro tiene un costo de $8 por hora.Estudio de caso de CFM). Esos gráficos describen una tarea relacionada con las noticias financieras y una configuración de infraestructura.

El estudio de reabastecimiento AI

Actualiza el informe técnico de AI mediante la etiquetación benchmarks LLM en 8 frameworks de procesamiento del lenguaje natural datasets, entre los que se encuentra CoNLL-2003. En dicho informe se indica que se logra una concordancia del 88,4 % con los valores de referencia para GPT-4 (marzo de 2023), mientras que los anotadores humanos alcanzan un 86,2 % en su configuración; además, este método permite realizar la etiquetación 20 veces más rápido y a un costo 7 veces menor. Su enfoque basado en conjuntos de modelos dirige los ejemplos sencillos a modelos menos costosos y los ejemplos complejos a GPT-4, obteniéndose así una concordancia superior al 95 % en los experimentos presentados.Volver a cargar el informe técnico de AI). Considérelos como resultados reportados por el proveedor según el protocolo de anotación de dicho estudio.

Producción pipeline

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

  1. Redactar pautas de anotación en lenguaje natural.
  2. Crear un conjunto de validación pequeño etiquetado por humanos (50-200 documentos).
  3. Utilizar un LLM (GPT-5.4 Mini, Llama 4 Maverick o Qwen3.5) para etiquetar los datos de entrenamiento en masa.
  4. Revisar una subcarga de dichos datos. Argila o Label Studio
  5. Ajuste fino de un codificador compacto (GLiNER, SpanMarker, RoBERTa)
  6. Despliegue con un costo de inferencia 16-80 veces menor

El LLM permite reducir el volumen de anotación manual, pero el equipo sigue siendo responsable del conjunto de validación, las directrices de anotación, las revisiones dirigidas y el análisis de errores.


Donde falla GLiNER y LLMs sigue siendo útil

El Sease benchmark (Octubre de 2025) Se probó GLiNER frente a GPT-4.1-mini en 30 tareas de análisis de consultas. GPT-4.1-mini obtuvo un 100 % de aciertos totales. GLiNER logró un 53 % (16 de 30). No obstante, GLiNER respondió en 0,08 segundos, frente a los 1,21 segundos del LLM, lo que supone una velocidad 15 veces mayor.

En esta prueba con 30 tareas benchmark, GLiNER falló en tres patrones recurrentes:

  1. Entidades implícitas: extracción de “evento” a partir de “Elton John performed at Madison Square Garden”; aunque en el texto no se menciona literalmente “evento”, el LLM infiere que se trata de un “concierto”.
  2. Sensibilidad en la redacción de las etiquetas: el valor “2022” obtiene una puntuación de 0,388 frente a “date”, pero de 0,958 frente a “year”; pequeños cambios en la etiqueta provocan grandes variaciones en las puntuaciones.
  3. Mapeo de valores: GLiNER devuelve el texto superficial exacto (“family houses”) en lugar del valor canónico (“Single family house”). Un LLM puede realizar dicha normalización cuando su prompt y el esquema definen los valores objetivo.

Entidades anidadas y superpuestas

GLiNER también tiene dificultades con las entidades anidadas. En frases como “New York University”, un humano podría etiquetar tanto “New York” (LOCALIZACIÓN) como “New York University” (ORGANIZACIÓN). GLiNER solo selecciona el rango de texto con la puntuación más alta. Esto es relevante en textos biomédicos (“acute myeloid leukemia” contiene tanto una enfermedad como un modificador) y en textos legales (jerarquías organizativas anidadas). Los modelos especializados sí son capaces de manejar este tipo de estructuras anidadas, pero el diseño basado en rangos planos de GLiNER no lo permite.

Utilice GLiNER para la extracción explícita de entidades y dirija los casos que requieran inferencia, razonamiento o mapeo a ontologías predefinidas a un LLM. El umbral de enrutamiento debe determinarse a partir de un conjunto de dominios etiquetados.


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

Un modelo puede obtener una puntuación de F1 del 95 % en un conjunto de pruebas cuidadosamente seleccionado y, aun así, fallar al procesar la mezcla de documentos a la que se enfrenta tras su despliegue. Es necesario construir el conjunto de evaluación a partir de la distribución real de producción y reservar muestras de los formatos y tipos de entidades poco comunes, ya que la agregación de resultados del F1 puede ocultar problemas reales.

Las métricas clave

Errores comunes en la evaluación

  1. Inflación por coincidencia parcial: Se extrae “Bill” cuando la etiqueta de referencia es “Bill Gates”; algunas implementaciones consideran esto como una coincidencia parcial. Utilice la comparación de intervalos exactos a menos que tenga un motivo para no hacerlo.
  2. Confusión de tipo: Si “Microsoft” se identifica correctamente como un intervalo pero se etiqueta como PERSON en lugar de ORG, su puntuación debería ser cero. Verifique que su código de evaluación maneje este caso.
  3. Fuga al conjunto de prueba: Cuando las entidades del conjunto de prueba solapan con las del conjunto de entrenamiento, las puntuaciones se inflan. Existen métodos zero-shot benchmarks (CrossNER, Few-NERD) para comprobar la generalización.

Creación de un conjunto de pruebas por dominio

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

  1. Extraer muestras de datos reales de producción, y no ejemplos seleccionados previamente. Incluir los documentos con errores que el modelo verá en la práctica.
  2. Entre 200 y 500 documentos anotados permite obtener estimaciones estables del valor F1. Con menos de 100, los intervalos de confianza son demasiado amplios.
  3. Se requieren al menos dos annotadores, con un alto grado de acuerdo entre ellos (kappa de Cohen > 0,8). Si las personas no están de acuerdo, el modelo no podrá superar ese rendimiento.
  4. Estratificar por nivel de dificultad: casos fáciles (texto limpio, tipos estándar) y casos difíciles (entidades ambiguas, jerga técnica, texto ruidoso).

Producción NER en cuatro industrias

A continuación se presentan las implementaciones de NER más avanzadas que he encontrado, junto con cifras específicas.

Salud

El sector sanitario cuenta con la herramientería más madura para NER. John Snow Labs pone a disposición más de 2.500 modelos preentrenados, de los cuales más de 1.200 están destinados al ámbito sanitario y abarcan más de 400 tipos de entidades clínicas mapeadas a ICD-10, SNOMED CT, LOINC y RxNorm. En la empresa’s comparativa de proveedores, Sus modelos de desidentificación alcanzaron un 96 % de F1, frente al 91 % de Azure, el 83 % de AWS y el 79 % de GPT-4o. Un estudio de caso independiente informa Providence St. Joseph Health procesa entre 100,000 y 500,000 notas clínicas diariamente.

En su revisión de proyectos de 2025, el código abierto Proyecto OpenMed Muestra más de 380 modelos biomédicos NER, 29,7 millones de descargas Hugging Face, y los mejores resultados en 10 de los 12 repositorios biomédicos públicos benchmarks.

Financiero NER

El caso de uso principal es la extracción de información para presentaciones ante la SEC. La solución Finance NLP de John Snow Labs permite identificar más de 11 tipos de entidades en los documentos 10-K/10-Q (direcciones, códigos bursátiles, años fiscales, bolsas de valores). FinBERT-MRC

Comercio electrónico

Walmart’s Sistema EAMT (KDD 2023) se entrena con 965 millones de consultas que incluyen aproximadamente 60 etiquetas de entidad; el artículo informa sobre un aumento del 0,51 % en el GMV en pruebas A/B. En el caso de Home Depot’s TripleLearn framework (AAAI 2021) incrementó el valor de NER F1 de 69.5 a 93.3 mediante entrenamiento iterativo.

Ciberseguridad

El sistema iACE (CCS 2016) procesó 71,000 artículos de 45 blogs de seguridad, extrayendo 900K elementos IOC con una precisión del 98 % y una recuperación del 93 %. Sistemas modernos como CyNER combinar DeBERTa (F1 >91%) con heurísticas IOC basadas en expresiones regulares. El CyberNER El dataset unificado (2025) armoniza cuatro datasets en 21 tipos de entidad alineados con STIX 2.1, logrando un valor de F1 de 0.736 gracias al uso de RoBERTa.


Optimización del despliegue: de Python a inferencias con menor latencia

Probé tres métodos para acelerar GLiNER con el fin de utilizarlo en entornos de producción, en el repositorio complementario.

ONNX exportación

GLiNER dispone de una conversión nativa de ONNX, y existen modelos ya preconvertidos en HuggingFace.onnx-community/gliner_small-v2.1). ONNX Runtime proporciona una aceleración de 1,5 a 3 veces en CPU con respecto a PyTorch, ofreciendo cuatro niveles de optimización que van desde el básico hasta el de precisión mixta.

Desde onnx_export.py:

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

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

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

INT8 cuantización

La cuantización dinámica reduce el tamaño de los modelos en 2,4 veces (de 438 MB a 181 MB), con una pérdida en la métrica F1 inferior al 0,6 %. Además, la velocidad aumenta 1,8 veces en CPU. Gracias a CPUs junto con ONNX Runtime en Intel VNNI, INT8 logra una aceleración de hasta 6 veces respecto a PyTorch FP32.

from onnxruntime.quantization import quantize_dynamic, QuantType

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

gline-rs: Reimplementación en Rust

gline-rs (Apache 2.0) elimina la sobrecarga asociada a Python. En CPU: 6.67 sec/sequencia frente a los 1.61 de Python, lo que supone una aceleración de 4.1 veces. En una RTX 4080: 248.75 sec/sequencia.gline-rs benchmarks). Es compatible con modelos de span y token, GPU/NPU a través de ONNX Runtime, y se distribuye como un paquete 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 fast-gliner El paquete ofrece bindings en Python a través de PyO3: la velocidad de Rust combinada con la ergonomía de Python.

Resumen de la pila de optimización

OptimizaciónAceleración frente a PyTorchTamaño del modeloF1 ImpactoMejor para
ONNX Runtime1,5-3 vecesIgualNingunoUna solución rápida y eficaz, con cualquier tipo de hardware.
INT8 Cuantización3-6 veces2.4 veces más pequeñouna pérdida del 0,6%CPU despliegue, con restricciones de memoria
4.1x (CPU)Formato ONNXNingunoAlto rendimiento y baja latencia crítica
gline-rs + INT84-8 veces2.4 veces más pequeñoPérdida del 1%Producción a escala

Extracción estructurada: Instructor frente a esquemas

Cuando se necesita mayor flexibilidad que la que ofrecen los modelos de codificador —entidades implícitas, razonamiento, mapeo ontológico—, dos bibliotecas se encargan de la extracción estructurada desde LLMs.

Instructor (~12 600 estrellas en GitHub y ~8,8 M de descargas al mes a fecha de marzo de 2026), creado por Jason Liu, corrige LLM SDKs para que admitan modelos de respuesta de Pydantic, e incluye reintentos automáticos en caso de fallo en la validación. Soporta a más de 15 proveedores y sirvió de inspiración para la función nativa structured output de OpenAI.

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

Esquemas por su parte, dottxt adopta un enfoque distinto: genera tokens de forma restringida mediante máquinas de estado finito. El decodificador enmascara aquellos tokens que violarían la gramática objetivo, en lugar de esperar a que se produzca un fallo de validación y volver a intentarlo. En AWS benchmark, Este camino alcanzó una adherencia al esquema del 98%, frente al 76% observado en la validación posterior a la generación, y produjo resultados 5 veces más rápidos que el flujo de trabajo sin restricciones probado con intentos repetidos. El resultado está vinculado directamente a dicho modelo, conjunto de esquemas y configuración de serving.

import outlines

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

La elección depende del lugar donde ejecute sus modelos. Instructor ofrece en la nube LLM APIs una solución con validación mediante Pydantic y mecanismos de reintentos ya conocidos por los ingenieros. Outlines, por su parte, limita la generación local a un esquema predefinido. Ambos métodos admiten la extracción al estilo NER, aunque su latencia sigue incluyendo el tiempo necesario para la generación autoregresiva del modelo. Benchmark funciona en ambos casos con un codificador, manteniendo el mismo tamaño de lote, hardware y esquema de entidades.


La arquitectura de producción en tres capas

Enviaré la carga de trabajo a producción NER en función de la estructura de la tarea y no según la clasificación de un único modelo.

Arquitectura de tres capas NER que dirige los segmentos explícitos a los codificadores, la extracción multi-tarea a GLiNER 2, y los casos que requieren un alto nivel de razonamiento a LLMs

Nivel 1: modelos de codificador para intervalos explícitos. Se debe utilizar un cross-encoder GLiNER para conjuntos de etiquetas más pequeños, y probar el bi-encoder a medida que aumenta el número de etiquetas. Se realiza el ajuste fino mediante LLM-como-profesor pipeline, y posteriormente se despliega con ONNX, INT8 o gline-rs cuando esas alternativas superan las pruebas en el dominio benchmark.

Nivel 2: GLiNER 2 para extracción multi-tarea. Cuando una solicitud requiere NER, clasificación, extracción de relaciones y datos estructurados, se debe probar el modelo compartido de GLiNER 2 con 205 millones de parámetros. El artículo indica una latencia de clasificación de entre 130 y 208 ms CPU en los diferentes conjuntos de etiquetas sometidos a pruebas.

Nivel 3: LLMs para la extracción con alto grado de razonamiento. Dirigir la identificación de entidades implícitas, la inferencia contextual y el mapeo ontológico a un LLM mediante Instructor en entornos cloud APIs, o a Outlines para modelos locales. Registrar estos casos, ya que constituyen candidatos para el próximo conjunto de entrenamiento del Nivel 1.

El estudio de caso de CFM ofrece una referencia de coste para el nivel Tier 1: un 93,4 % F1 a un precio reportado de $0,10 por hora en CPU, frente a un 92,7 % F1 y $8 por hora en el modelo maestro Llama-70B. Recálculo esa comparación teniendo en cuenta su hardware, modelo maestro, conjunto de etiquetas y analice los costes resultantes.


Compromisos y limitaciones

Los sistemas basados en ML siempre presentan compromisos. La cuestión clave es determinar dónde se manifiestan dichos compromisos y si es posible medirlos antes de su despliegue.

LLM: los errores propios del rol de profesor se propagan. Si el LLM identifica de forma constante un tipo de entidad incorrectamente (por ejemplo, confundiendo nombres de filiales con los de las empresas matrices), el codificador afinado hereda dicho sesgo. La solución consiste en realizar una revisión humana dirigida: es necesario concentrar los esfuerzos en aquellos tipos de entidad donde la confianza del LLM es baja o inconsistente, y no en muestreos aleatorios.

Las pérdidas por cuantización no son uniformes. La pérdida promedio en F1 de ~0.6% que se obtiene con INT8 puede ser mayor en tipos de entidades poco comunes que presentan patrones de límites sutiles (compuestos químicos, abreviaturas de varias palabras). Siempre debe benchmark los modelos cuantizados para sus tipos de entidades específicos, y no solo basarse en el valor promedio del F1.

Cuándo la arquitectura de tres capas es un exceso. Un único dominio con tipos de entidad estables y suficientes ejemplos etiquetados podría requerir únicamente una versión ajustada de RoBERTa o spaCy pipeline. El patrón de tres capas resulta adecuado para múltiples dominios, tipos de entidad en constante evolución, o una combinación equilibrada entre extracción explícita y procesos basados en razonamiento. Una factura simple pipeline que solo extrae nombres y fechas puede limitarse a la primera capa.

Techo de calidad del bi-encoder. El bi-encoder sacrifica la atención conjunta a cambio de mayor rendimiento. Cuando las semánticas de las etiquetas interactúan con el contexto textual (“fecha”, “año” o “período” para el mismo segmento), el cross-encoder sigue siendo la opción superior. Utilice el cross-encoder en tareas críticas con escaso número de etiquetas; el bi-encoder, en cambio, es adecuado cuando se busca mayor amplitud de análisis.


Referencias

Artículos científicos

Artículos de la industria

Estudios de caso

Herramientas y frameworks