Un codificador de 17 millones de parámetros elige la herramienta correcta en 14 ms en CPU

El último paso de muchos pipelines de LLM parece modesto: elegir una opción de un conjunto conocido de antemano. Qué herramienta invocar, bajo qué etiqueta clasificar una consulta, a qué ruta enviarla. Normalmente esto se hace mediante un prompt a un modelo grande, y eso resulta lento, caro y sensible al orden de las opciones. Tardelli Ronan Coelho Stekel probó cuán pequeño puede ser un codificador para esta tarea y publicó en abierto la familia Crivo, de seis modelos de entre 17 millones y 1.000 millones de parámetros.

Las cifras clave. Los modelos de 68M y 150M superan al clasificador zero-shot DeBERTa-v3 de 435M de parámetros por 4,9 y 5,9 puntos de precisión en 209 tareas de System1-Arena, auditadas para descartar solapamiento con los datos de entrenamiento. En 145 tareas que los modelos no vieron durante el entrenamiento, se mantienen al menos a la altura de DeBERTa. El modelo más pequeño, de 17M, responde a una consulta en una mediana de 14 ms con 16 hilos de CPU. El clasificador DeBERTa, en las mismas condiciones, tiene una mediana de 728 ms.

¿Leer las opciones juntas o de una en una?

La segunda pregunta de la investigación importa más a quienes diseñan sistemas. Un codificador puede recibir todas las opciones a la vez (joint) o evaluar cada opción por separado, emparejada con la consulta (per-option). El autor realizó un estudio con tres semillas en un modelo de 32M de parámetros sobre un conjunto de validación de 37 benchmarks.

El esquema per-option gana por 5,8 puntos de habilidad ajustada al azar con el mismo número de pasos de optimización. Con un coste computacional de entrenamiento aproximadamente igual, la diferencia se reduce a 2,8 puntos. Dos benchmarks externos confirman la dirección del efecto, pero en tareas no vistas la diferencia no es estadísticamente significativa.

La ventaja no aparece siempre. Solo surge cuando se inicializa desde un reranker: su entrada en forma de par consulta-candidato coincide con la manera en que el esquema per-option lee las opciones. Si se parte de un codificador crudo, ambos enfoques son indistinguibles.

El precio de la precisión y el punto débil de joint

Per-option requiere entre 5 y 13 veces más pasadas del codificador. En latencia mediana, eso supone una pérdida de no más del doble, pero en latencia media ya supera el cuádruple: las listas largas de opciones afectan a la cola de la distribución. Por eso en la publicación entraron los modelos joint.

El enfoque joint tiene un defecto medido: reordenar las opciones cambia entre un 12% y un 23% de las respuestas. El esquema per-option no presenta esa dependencia: sus respuestas no cambian en absoluto. Para producción, es un argumento serio: el orden de las herramientas en una lista no debería influir en la elección, pero aquí lo hace.

Hasta los 68M de parámetros, los modelos de Crivo lideran su rango de tamaño en el leaderboard público. La evaluación se hace con pruebas privadas, en su mayoría cercanas a la distribución de entrenamiento, por lo que es un resultado sólido para tareas similares a las de entrenamiento, pero no una garantía de transferencia.

Qué incluye el lanzamiento

• La familia Crivo: seis codificadores joint abiertos de entre 17M y 1.000M de parámetros, colección en Hugging Face (tardellirs/crivo).
• 68M y 150M: +4,9 y +5,9 puntos de precisión respecto a DeBERTa-v3 (435M, zero-shot) en 209 tareas de System1-Arena.
• 145 tareas no vistas: paridad con DeBERTa-v3 como mínimo.
• 17M: mediana de 14 ms con 16 hilos de CPU frente a 728 ms de DeBERTa-v3.
• Estudio con 32M: per-option mejora sobre joint por 5,8 puntos con pasos iguales y 2,8 con cómputo igual, tres semillas, 37 benchmarks.
• Coste de per-option: entre 5 y 13 veces más pasadas, hasta 2 veces en latencia mediana y más de 4 veces en latencia media.
• Sensibilidad al orden: entre un 12% y un 23% de las respuestas joint cambian al reordenar las opciones.
• Código y resultados publicados en el repositorio crivo-decision-encoders en GitHub.

Dónde será útil

Para enrutar consultas entre modelos, la selección de herramientas por parte de un agente y la clasificación sobre un conjunto cerrado de etiquetas, estos codificadores ofrecen una alternativa barata a llamar a un LLM. El modelo de 17M cabe en 14 ms en un procesador normal sin GPU, y eso cambia la economía: la decisión puede tomarse en cada paso de un ciclo agéntico en lugar de acumularse en una llamada aparte y costosa.

Las conclusiones prácticas son estas. Si importa la estabilidad, conviene aleatorizar y promediar el orden de las opciones, o usar el esquema per-option asumiendo el aumento de latencia en la cola. Si se entrena un selector propio, hay que empezar desde un reranker: desde un codificador crudo no se obtiene ninguna ventaja al leer las opciones una a una. Antes de implementarlo hay que probar el modelo con las propias tareas: la paridad en datos no vistos significa «no peor que DeBERTa», no superioridad, y las mayores ventajas se obtienen donde la distribución es cercana a la de entrenamiento.