Peter Vijeh: GLiNER reemplaza a Gemini 3.1 Pro por US$9

¿Por qué un LLM de frontera es overkill para NER a escala?

Peter Vijeh, desarrollador y autor del blog personal petervijeh.com, necesitaba sacar del texto nombres de marcas, modelos y aceros a partir de comentarios de Reddit sobre cuchillos de chef. Lo que empezó como un hobby de cocina se convirtió en un proyecto de named-entity recognition (NER) aplicado a los hilos más activos del subreddit.

Su primera versión del scraper usaba Gemini 3.1 Pro con un costo por llamada: el modelo devolvía la marca, el modelo y el acero de cada comentario con precisión razonable, pero cada nuevo comentario pagaba una llamada a la API. Cuando el volumen creció, la factura creció con él, y la única forma de contenerla era saltar comentarios. La búsqueda de una alternativa lo llevó a GLiNER, un modelo open source de NER basado en una arquitectura encoder tipo DeBERTa-v3-large que, según la página del modelo en Hugging Face, identifica cualquier tipo de entidad sin entrenamiento específico para esa clase.

GLiNER (Generalist Light Model for Named Entity Recognition) es la opción que cualquier founder debería conocer si su startup procesa grandes volúmenes de texto donde aparecen entidades concretas: tickets de soporte, menciones de producto, currículos, contratos. Frente a un LLM, corre en CPU o GPU barata, no alucina formatos y mantiene la latencia baja.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

¿Qué pasa cuando reemplazas Gemini por GLiNER sin entrenar?

La opción obvia era usar GLiNER zero-shot, es decir, sin reentrenar: pasarle los comentarios y dejar que detecte entidades por sí solo. Según el artículo original, la precisión cayó a 0,65 de F1 frente a las etiquetas de Gemini, una brecha demasiado grande para producción.

Esa caída no es sorprendente: el paper original de GLiNER multi-tarea (publicado en arXiv en 2024) reporta un F1 promedio de 0,5754 en el benchmark zero-shot CrossNER para el modelo gliner_large-v2.1, la versión anterior a la v2.5 que Vijeh terminó usando. En datasets como el de restaurantes, el F1 baja a 0,4625, lo que confirma la intuición de que el modelo genérico pierde precisión cuando el dominio tiene jerga técnica propia. Los cuchillos de chef son un caso extremo: nombres como «Mazaki», «Fibrox» o «white #2» se mezclan con acero, mango y palabras comunes como «carbon» o «patina» que el zero-shot tiende a etiquetar como entidades.

El plan: usar Gemini como profesor, no como producto final

El plan de Vijeh, documentado paso a paso en su blog, tuvo tres etapas que cualquier equipo técnico puede replicar:

Etiquetar una vez: pedirle a Gemini 3.1 Pro que marque las entidades en 4.290 comentarios de Reddit a temperatura 0, a través de OpenRouter. El costo total fue de US$9, unos US$0,0021 por comentario, en 25 minutos.
Entrenar el modelo open source: ajustar GLiNER large v2.5 (459M de parámetros) sobre esas etiquetas, en una Tesla T4 alquilada en Modal, durante 24 minutos.
Correr el modelo en local: servir el resultado vía FastAPI y dejar de pagarle a Gemini por cada comentario nuevo.

El umbral de rentabilidad se cruza en el comentario 4.291, siempre que los siguientes tengan una longitud parecida y la GPU ya estuviera disponible. En el paper de GLiNER multi-task, los autores midieron un F1 de 0,6276 en promedio en CrossNER, lo que da una referencia pública del techo alcanzable por la arquitectura sin ajuste fino.

La trampa del prompt: nunca pidas offsets, pide strings

Una decisión clave del prompt fue pedirle a Gemini el texto exacto de la entidad, no las posiciones de caracteres. Los modelos grandes cuentan caracteres de forma poco fiable y devuelven spans corridos por dos o tres posiciones. El código en TypeScript después buscaba la subcadena dentro del comentario y calculaba los offsets; si no encontraba la coincidencia exacta, la descartaba y la registraba.

Los nombres de productos están plagados de puntuación que un tokenizer genérico parte en pedazos. Vijeh escribió un regex que mantenía juntos tokens como VG-10, CPM-154 y 1.4116, y emitía cualquier otro carácter no espacial como token propio. Los spans que aún así no respetaban un límite de token se descartaban en lugar de adivinarse.

Por qué 5 de 10 entrenamientos fallaron (y cómo evitarlos)

De diez corridas, cinco no produjeron un modelo útil: tres por errores de configuración y dos por un bug silencioso en un tensor. La tabla del artículo original resume los tropiezos típicos que cualquier founder que intente un fine-tuning va a reconocer:

max_steps por defecto: el HF Trainer usa max_steps=10000 por defecto y anula num_train_epochs=3; el modelo entrenó 39 epochs sin que nadie se diera cuenta.
eval_strategy faltante: usar load_best_model_at_end=True sin eval_strategy="steps" lanza un error.
Prefijo de state-dict: el Trainer guardaba las claves sin el prefijo model. que el loader de GLiNER espera.
Etiquetas faltantes en negativos: ejemplos negativos sin ner_labels rompían el balance.
words_mask mal construido: un tensor que parece una máscara de atención, tiene la misma forma, y se llena con unos y ceros, destruye dos entrenamientos sin que la pérdida grite.

El error silencioso que destruyó dos entrenamientos

El último punto merece capítulo aparte. El tensor words_mask vive junto a attention_mask y tiene la misma forma, pero no es una máscara binaria: es un índice de palabra. Cada token real recibe un número incremental (1, 2, 3…), y los tokens especiales, de prompt y de padding reciben 0. El span-scoring head lo usa para agrupar sub-tokens de vuelta en palabras.

Cuando Vijeh lo llenó con unos, le estaba diciendo al modelo que toda la secuencia era una sola palabra. El modelo intentaba encontrar marcas y materiales dentro de un solo token enorme. La pérdida arrancó en 130, bajó a 70 y se quedó ahí. Sin crash, sin warning, sin NaN, gradientes de tamaño normal, checkpoints guardados en horario, F1 de evaluación cerca de cero.

La solución fue leer el bucle de entrenamiento de GLiNER en lugar de sus docstrings. Una vez corregido el índice, la corrida 6 aprendió en el primer intento.

El resultado: 0,83 F1 por US$11,50

El modelo final alcanzó 0,83 de F1 contra las etiquetas de Gemini en un set de validación de 225 comentarios que Vijeh apartó y nunca volvió a tocar. La métrica importante es que el modelo fue evaluado contra Gemini, no contra la verdad real, lo que significa que hereda los errores del profesor y es penalizado cuando los corrige.

La optimización más rentable fue un umbral por clase en lugar de un umbral global: la recall de materiales pasó de 0,787 a 0,911 porque nombres de acero como MagnaCut, S35VN y HAP40 generan confianza más baja que las marcas, y un corte único los descartaba. El modelo corre de forma estable en local, distingue que «carbon steel» es una categoría y no un acero, y entiende que «PM2» a veces significa Spyderco Paramilitary 2 y a veces son solo letras.

El costo total: US$9 de etiquetas y US$2,50 de GPU a lo largo de diez corridas. Los días de debugging no entran en la factura.

¿Qué significa esto para tu startup?

Si tu producto procesa texto donde aparecen entidades concretas (soporte, contratos, currículos, menciones de marca), el patrón LLM-como-profesor + encoder-open-source es probablemente la mejor relación costo-calidad disponible en 2026. El propio Fastino Labs, el laboratorio detrás de GLiNER, lanzó en abril de 2026 la plataforma Pioneer, descrita en un comunicado de Yahoo Finance como «el primer agente de fine-tuning para modelos open source», bajo la tesis de que «los modelos especializados y afinados igualan o superan la precisión de modelos frontera en tareas específicas, a una fracción de la latencia y el costo».

Tres acciones concretas que puedes implementar este mes:

Identifica una tarea estrecha de alto volumen en tu producto y etiqueta 2.000 a 5.000 ejemplos con un LLM una sola vez. Si la llamada al LLM cuesta alrededor de US$0,002 por ejemplo como reporta Vijeh, el techo de inversión es de US$10 para tener un dataset de entrenamiento.
Aparta tu set de validación antes de la segunda corrida y no lo vuelvas a tocar. Vijeh vio cómo un split aleatorio le inflaba el F1 a 0,879 y dos caídas que parecían bugs suyos venían en realidad de qué comentarios caían en validación.
Llena de negativos tu entrenamiento: el 30% de los datos de Vijeh son comentarios con palabras que disparan falsos positivos (gyuto, carbon, handle, patina) y sin producto. Sin negativos adversariales, el modelo zero-shot se queda en 0,65 de F1.

Un consejo que Vijeh mismo destaca: «Si tuviera que elegir entre un mejor set de etiquetas y una aserción sobre cada tensor que construyo a mano, me quedo con la aserción». El modelo y los datos rara vez son el problema; el código entre ellos falla, y una pérdida plana por un tensor mal llenado se ve igual que una pérdida plana por datos difíciles.