Autores: @eddiedzhou, @mr_cheu, @MatZhao, @CosmicPegasis19, @manav_ai
Jev es un modelo para tomar decisiones tipadas. Le envías contexto junto con un conjunto fijo de preguntas y opciones, y en lugar de generar texto, te devuelve elecciones, puntuaciones y probabilidades. ¡Es un modelo de «Sistema Uno»!
Pero la clasificación no es nada nuevo, y tampoco lo son las salidas estructuradas, los modelos pequeños o la lectura de probabilidades a partir de logits. Esa historia explica en parte la reacción dividida ante Jev...
Los escépticos tienen razón en parte, pero Jev tiene un lugar real en este ecosistema. Para entenderlo mejor, conviene mapear todo el espacio de soluciones.
¿Qué alternativas existen?
Cuando un sistema necesita una etiqueta, una puntuación o una respuesta de sí o no, hay cuatro opciones razonables:
Enfoque
Por qué usarlo
Contrapartida
Un LLM de propósito general
Zero-shot, flexible, también puede generar argumentos o explicaciones. Podría decirse que ofrece una «mayor inteligencia» gracias al cómputo en tiempo de inferencia (razonamiento).
Asumir la latencia y el coste de un modelo autorregresivo para una decisión pequeña
Un clasificador zero-shot abierto
Barato, local y controlable
Calidad variable; tú te encargas de elegir y servir el modelo
Un clasificador fine-tuned
Normalmente la mejor apuesta para una tarea estable, de alto volumen y con buenas etiquetas
Recopilación de datos, entrenamiento, despliegue, drift y una taxonomía menos flexible
Jev
Flexibilidad zero-shot detrás de una API alojada y limpia
Calidad dependiente de la tarea, sin texto generado y dependencia del proveedor
El argumento a favor de Jev: un equipo puede cambiar la pregunta y las opciones sin tener que recopilar un nuevo conjunto de entrenamiento, y además se ahorra el trabajo de servir bien un modelo. Nadie debería hacerle ascos a eso. Lo de «podríamos construirlo nosotros mismos» aplica a casi cualquier producto de infraestructura.
Las reproducciones abiertas ponen en perspectiva su novedad. Implementaciones con Qwen y SGLang, DiffusionGemma y vLLM y Kev replican gran parte de la forma de la API o del modelo.
85,7 % para Jev y 79,6 % para Kev-8B con n=764
Las pruebas externas de Parallel también concluyeron que Jev era competitivo en reranking, aunque los modelos especializados siguieron ganando en dos tareas de clasificación.
Lo que hemos visto en Glean
Esto nos deja una pregunta práctica: ¿cuándo la combinación de flexibilidad zero-shot e inferencia alojada de Jev supera realmente a las alternativas? En Glean probamos cuatro decisiones acotadas en las que ya teníamos una línea base y podíamos comparar la calidad real en un entorno empresarial. La mayoría de estas líneas base son sistemas basados en LLM, así que en esos experimentos esperábamos mejoras de dos órdenes de magnitud en coste y latencia. Los resultados fueron desde un rendimiento materialmente peor que el de producción hasta ser más rápido y preciso que un router basado en LLM.
Clasificación de consultas
La clasificación de consultas asigna una petición a una tarea amplia utilizada por los sistemas posteriores. Es una carga de trabajo natural para Jev porque, aunque a nivel de cada petición el espacio de etiquetas se conoce de antemano, la taxonomía puede cambiar más rápido de lo que tarda en reentrenarse un clasificador fine-tuned.
En este experimento nos centramos en medir la concordancia de Jev frente a las predicciones de nuestra línea base / producción, que está basada en LLM. Esperábamos —y observamos— una gran aceleración en el throughput offline con Jev, así que usamos la concordancia como un indicador sencillo de calidad. También comparamos con Laya, un modelo de decisión de pesos abiertos, y con una versión fine-tuned de Laya. Este fine-tuning pudo ejecutarse en local en unas pocas horas, y el modelo es lo bastante pequeño como para servirse en la máquina de un desarrollador.
Experimento
Concordancia en tarea amplia
Rendimiento
Jev zero-shot
66,8 %
~
12 min (concurrencia de 4
)
Laya base
35,9 %
~
90 s (máquina de desarrollo local)
Laya fine-tuned
74,5 %
~
90 s (máquina de desarrollo local)
Como modelo listo para usar, cómodo y sin necesidad de entrenamiento, Jev supera claramente a Laya, pero, como era de esperar, el fine-tuning hace brillar a Laya, sobre todo si miramos las cifras de rendimiento. La contrapartida es el esfuerzo de conseguir buenas etiquetas y configurar el entrenamiento. Jev probablemente siga siendo más atractivo cuando la tarea es nueva o sus etiquetas cambian.
Enrutamiento de modelos: transferencia a expertos
El enrutamiento de modelos es un problema relacionado con la clasificación de consultas. Aquí lo planteamos como una transferencia a expertos, donde nuestro sistema decide qué experto / modelo debe gestionar la petición. Nuestra línea base de producción actualmente le pide a un LLM que tome esa decisión de forma nativa dentro del bucle agéntico del orquestador. Aunque es una prueba natural para ver si Jev puede sustituir una llamada generativa por una decisión acotada, una limitación técnica importante es que Jev añadirá estrictamente una llamada cuando no haya transferencia. Esto contrasta con la línea base de producción, que en los casos sin transferencia puede empezar el trabajo de tool calling con esa misma primera y única llamada al LLM.
Usamos una versión simplificada de nuestro enrutamiento de producción con solo 3 expertos, reprocesamos 751 entradas golden comparables a través del nuevo router con Jev y comparamos la ruta elegida con nuestro router actual basado en prompts (impulsado por un LLM tradicional), midiendo la precisión frente a la etiqueta golden.
También aislamos 40 entradas en las que la ruta original hizo una llamada real de transferencia a experto (una n menor) y comparamos la latencia de llamada en esas mismas entradas.
La aceleración mediana por entrada fue de 8,1×. Es uno de los mejores resultados internos de Jev hasta ahora: en esta tarea de enrutamiento acotada, Jev fue más preciso y considerablemente más rápido. La magnitud de la diferencia sugiere que el impuesto de «bloqueo» que pagamos en las peticiones no enrutadas a expertos podría ser una buena contrapartida. Ten en cuenta que sigue siendo una comparación offline contra un conjunto golden, y la muestra de latencia contiene solo 40 transferencias positivas, ¡así que aún queda mucho por validar y probar!
Reranking
¡Un tema muy cercano a Glean! A continuación, nuestra línea base de producción es el orden que genera la stack de búsqueda actual de Glean. En este experimento le pedimos a Jev que reordenara hasta 50 resultados.
Probamos cuatro formas de expresar la relevancia mediante las salidas tipadas de Jev:
Formulación
Cómo expresa la relevancia
Noul pointwise
Hace una pregunta independiente de sí o no sobre la relevancia de cada resultado y luego ordena según la probabilidad de «sí».
Noul de estado compartido
Le muestra a Jev todo el conjunto de candidatos como contexto compartido y luego hace la misma pregunta de sí o no para cada resultado.
Puntuación
Le pide a Jev que asigne a cada candidato una puntuación numérica de relevancia.
Elección
Trata todos los candidatos como alternativas en una única decisión y luego los ordena según las probabilidades resultantes.
Lo ejecutamos en un evalset interno en el que el usuario no tiene acceso a todos los canónicos, así que los números absolutos no reflejan nuestro ranking de producción, pero los relativos sí resultan interesantes.
La formulación «Elección» de Jev fue la más potente. En un control pareado de 4.855 consultas de búsqueda capturadas, eliminando los desempates basados en producción, el resultado fue:
Jev Elección costó aproximadamente 0,00044 $ por consulta y tardó 0,195 segundos en el p50 durante la prueba offline. Pero asignó puntuaciones idénticas a unos 37 de los 41 candidatos en una consulta media. Usar el orden de producción para resolver esos empates elevó el Recall@6 del 40,2 % al 44,3 %, haciendo que el resultado sin corregir pareciera mejor de lo que justificaban las puntuaciones de Jev por sí solas. Como siempre, hay muchos matices, pero en términos generales, Jev es una línea base barata y eficiente, no un sustituto del ranker de producción de Glean.
Evaluación de soporte de citas
La evaluación de citas responde a dos preguntas relacionadas: ¿las afirmaciones que requieren evidencia cuentan con citas adecuadas (recall de citas) y ¿las fuentes citadas respaldan realmente las afirmaciones que se les atribuyen (precisión de citas)? A primera vista, como el espacio de salida / etiquetas está acotado (igual que en la mayoría de configuraciones de juez), parece un caso obvio para Jev. Sin embargo, la rúbrica es compleja y puede exigir descomponer varias afirmaciones; además, Jev no genera la justificación que solemos usar para analizar errores, por lo que hay cierto riesgo tanto para la calidad como para la usabilidad.
Probamos Jev con una respuesta real de evaluación de producción de 1.448 palabras, manteniendo fijos la respuesta y la evidencia de las citas. Comparamos su pasada conjunta de precisión y recall con GPT-5.6 Luna sin razonamiento y con razonamiento xhigh. Para reducir la varianza, ejecutamos cada juez tres veces.
Juez
Tiempo medido original por respuesta
Coste medido original por respuesta
Jev
6,6 s
$
0,014
GPT-5.6 Luna, sin razonamiento
81,3–85,5 s
$
0,030–
$
0,047
GPT-5.6 Luna,
xhigh
227,4–259,7 s
$
0,047–
$
0,060
Ten en cuenta que los tiempos son orientativos, no end-to-end: Jev reporta el wall time secuencial del cliente, mientras que las filas de Luna suman las duraciones de las llamadas al modelo. Los costes incluyen el caching observado.
También comparamos la consistencia en los mismos 28 párrafos. Un elemento cambiado significa que el juez modificó su veredicto sobre si un párrafo tenía cobertura de citas adecuada en al menos una de tres ejecuciones con inputs idénticos. El desacuerdo pareado cuenta cada párrafo entre los tres pares de ejecuciones, lo que da 84 comparaciones por juez.
Juez
Párrafos con veredicto de recall cambiado
Desacuerdos pareados de recall
Jev
1 de 28 (3,6 %)
2 de 84 (2,4 %)
GPT-5.6 Luna, sin razonamiento
7 de 28 (25,0 %)
15 de 84 (17,9 %)
GPT-5.6 Luna,
xhigh
5 de 28 (17,9 %)
10 de 84 (11,9 %)
El único cambio de Jev fue si un párrafo contaba como necesitado de cita; su categoría bruta de recall no varió. Por tanto, los veredictos de cobertura de citas a nivel de párrafo de Jev fueron más repetibles que los de cualquiera de las configuraciones de Luna.
No concluimos que esto convierta a Jev en un juez más preciso (los sistemas aplicaron criterios de soporte y denominadores de puntuación distintos, y no tuvimos tiempo de hacer etiquetado humano independiente). Pero incluso con razonamiento xhigh (que prácticamente triplicó el tiempo de modelo de Luna), siguió siendo menos consistente que Jev. El resultado respalda a Jev como una forma rápida, económica y relativamente repetible de implementar una política de citas acotada.
Conclusiones de los experimentos y guía práctica
En algunos casos, Jev destaca como una alternativa de baja fricción tanto a los LLM tradicionales como a los clasificadores fine-tuned. Cuando la línea base ya es sólida (reranking) o resulta fácil hacer fine-tuning de un modelo más pequeño (clasificación de consultas), la ventaja es menor. Hay indicios de mayor calidad en algunas tareas (enrutamiento de modelos) y también señales de mejor consistencia y estabilidad (juez de citas). En algunas de nuestras cargas de trabajo más importantes, logra las mejoras esperadas de coste y latencia frente a los LLM tradicionales.
Los resultados anteriores dan buenas pistas sobre hacia dónde ir, y en Glean estamos muy entusiasmados con Jev. Tras dar unos cuantos pasos más (principalmente de preparación operativa, como residencia de datos y garantías), planeamos llevar Jev a producción en algunos de estos casos de uso. Además, Jev tendrá un papel protagonista en nuestra hackathon interna esta semana, ¡y nos encanta poder compartir más resultados!
Para cerrar, un consejo general: si la salida se puede listar de antemano, haz benchmark de Jev. Si la tarea y las etiquetas son estables y el volumen es alto, compara también con un clasificador fine-tuned. Si la llamada necesita generar una consulta, una explicación u otro texto dinámico, mantén un modelo generativo en el circuito. El tool calling es un buen ejemplo: Jev puede ayudar a elegir una herramienta, pero la mayoría de las herramientas de Glean siguen necesitando argumentos generados dinámicamente (como consultas de búsqueda).
Jev no cambia el hecho de que los clasificadores ya existían. Simplemente hace que un buen clasificador zero-shot sea mucho más fácil de usar. Eso es un producto sólido, aunque no suponga una nueva base para todos los sistemas de IA.
