Jev y por qué no todo necesita un LLM

##Introducción

Cada vez que nuestro software necesita entender algo, llamamos a un LLM. Le pedimos que clasifique un correo, puntúe una respuesta, elija una herramienta o decida qué modelo debería resolver la siguiente petición. Aunque la salida solo pueda ser A o B, recurrimos a una máquina entrenada para escribir párrafos.

Funciona. Yo mismo lo he utilizado en varios sistemas de decisión, por ejemplo para asignar una puntuación de popularidad a distintos modelos de IA. En Runware también he construido un router donde el usuario indica cuánto le importan la velocidad, la calidad y el precio, y un juez elige el modelo que generará la petición. Le proporcionas los datos, defines un esquema y recibes una decisión que el código puede utilizar.

El 15 de septiembre de 2026, TypeSafe presentó Jev, un modelo que propone hacer ese trabajo sin generar texto. Recibe información sin estructurar y devuelve elecciones, puntuaciones y probabilidades. La empresa afirma que puede hacerlo entre 40 y 200 veces más rápido que un LLM con una capacidad similar y lo resume con una frase todavía más llamativa: Jev no puede alucinar.

La tentación es discutir si se trata de una nueva clase de modelo o de un clasificador con una API especialmente cuidada. Las dos preguntas son interesantes, pero hay otra bastante más útil: ¿por qué estamos utilizando un modelo generativo para cada pequeña decisión de un agente?

En este artículo vamos a ver qué cambia realmente entre Jev y un LLM con structured output, dónde empiezan a flojear sus promesas y por qué su idea importa incluso si nunca utilizamos el producto. Puede que a los agentes no les falte un modelo más inteligente. Puede que les sobre trabajo asignado al mismo modelo.

##El problema no es generar JSON

Un LLM moderno ya puede devolver una respuesta estructurada. Con Structured Outputs, por ejemplo, el proveedor restringe los tokens disponibles durante la generación para que el resultado respete el JSON Schema solicitado. Si un campo solo admite model-a, model-b o model-c, el modelo no puede responder con otro identificador ni añadir una explicación fuera del objeto.

Esto resuelve un problema importante. Ya no tenemos que cruzar los dedos para que aparezcan todas las llaves ni extraer JSON de un bloque de Markdown. El formato deja de ser una sugerencia y se convierte en un contrato.

Pero un contrato válido no garantiza una decisión correcta. El modelo todavía tiene que interpretar el contexto, elegir un valor y generarlo token a token. El schema limita cómo puede responder, no mejora por sí solo el criterio con el que escoge la respuesta.

Ese router de modelos es un buen ejemplo. El usuario asigna un peso de cero a cinco a la velocidad, la calidad y el precio. El juez recibe esas prioridades junto a las puntuaciones de los modelos. Su única salida útil es el identificador del modelo que generará la petición.

La respuesta puede estar perfectamente estructurada, pero hemos invocado un modelo generativo para elegir un identificador. La capacidad para redactar desaparece en cuanto parseamos el JSON.

Jev parte de la idea contraria. Si el resultado va a alimentar directamente al software, no genera primero una cadena para convertirla después en una decisión. Su salida ya es la decisión.

##Un modelo que decide en lugar de escribir

TypeSafe llama System One a una familia de modelos especializados en decisiones rápidas. El nombre hace referencia al sistema intuitivo de Pensar rápido, pensar despacio. Jev es el primero de ellos.

Una petición contiene dos partes. state reúne la información que el modelo necesita y questions describe las decisiones que queremos tomar. Jev 1.13 admite tres tipos de pregunta:

• Choice elige entre un máximo de 255 opciones y devuelve la probabilidad de cada una.
• Score puntúa algo dentro de una escala ordenada de entre dos y diez niveles.
• Noul responde a una afirmación con una probabilidad entre cero y uno.

La salida no incluye una justificación ni un campo de texto libre. Tampoco puede inventar una cuarta opción si solo le hemos dado tres. En lugar de componer la respuesta de izquierda a derecha, evalúa todas las preguntas en paralelo contra el mismo estado.

Esta diferencia se puede medir. En una prueba pública con la API, enviar una, tres, cuatro o cinco preguntas produjo tiempos internos de 70, 72, 81 y 74 milisegundos. No demuestra que cualquier carga vaya a costar exactamente lo mismo, pero sí respalda que las preguntas no se resuelven como una larga respuesta generada en serie.

También permite adelantar preguntas que quizá no lleguemos a necesitar. En el patrón que TypeSafe llama speculative fan-out, un sistema de soporte puede calcular a la vez la categoría, la gravedad, la frustración y la probabilidad de que se solicite un reembolso. Después el código utiliza las respuestas relevantes e ignora las demás. Cambiamos varias llamadas consecutivas por preguntas paralelas y una ruta explícita en código.

La versión actual acepta hasta 64k tokens por petición, trabaja únicamente con texto y cuesta $0,042 por millón de tokens de entrada. TypeSafe no cobra los tokens de salida porque no existe una secuencia de texto que medir. El inglés es además su idioma principal, y la propia empresa afirma que es donde funciona mejor.

##Puede equivocarse sin alucinar

La frase «Jev no puede alucinar» funciona muy bien como titular porque contiene una verdad técnica y una conclusión fácil de malinterpretar.

Si preguntamos a un LLM si un correo es legítimo y exigimos un JSON estricto, puede devolver una estructura válida con la respuesta equivocada. También podría inventar una explicación o un dato si le dejamos campos de texto. Jev elimina esta segunda posibilidad. Solo puede repartir probabilidad entre las respuestas que hemos definido.

Eso no evita la primera. Si la respuesta correcta era A y Jev elige B, tenemos un error de clasificación. No suele llamarse alucinación porque no ha generado una afirmación nueva fuera del espacio permitido, pero al software que ejecute la decisión le dará bastante igual la terminología.

Jev elimina las alucinaciones propias de la generación libre, no los errores de juicio. El contrato puede ser impecable y la decisión estar equivocada.

##La idea es anterior a Jev

Los clasificadores llevan décadas tomando decisiones sin generar texto. Su problema tradicional era la rigidez: definíamos unas etiquetas, reuníamos datos, entrenábamos el modelo y repetíamos el proceso cuando cambiaba la tarea.

Los modelos de lenguaje empezaron a romper esa relación. En 2019, la clasificación zero-shot basada en inferencia textual ya permitía describir etiquetas con lenguaje natural y utilizarlas sin entrenar un clasificador específico. Proyectos posteriores como SetFit o GLiClass han seguido acercando los clasificadores a esa flexibilidad.

Los modelos de recompensa utilizados para entrenar LLM hacen algo parecido desde otro ángulo. No escriben la mejor respuesta. Leen varias y estiman cuál satisface mejor unos criterios. El trabajo de InstructGPT, por ejemplo, sustituyó la salida lingüística del modelo por una proyección que producía una recompensa escalar.

También existen modelos como Llama Guard, diseñados para clasificar contenido, y routers como RouteLLM, que aprenden cuándo merece la pena enviar una petición a un modelo más caro. Ninguna de estas piezas necesitó que Jev inventara el acto de juzgar.

La diferencia está en cómo TypeSafe empaqueta esas ideas. Jev acepta criterios nuevos en cada petición, devuelve distribuciones de probabilidad y responde a varias preguntas con una sola lectura del contexto. Intenta conservar la facilidad de programar con lenguaje natural sin pagar siempre el coste de generarlo.

##Sustituir el LLM no siempre mejora el sistema

Las cifras de lanzamiento comparan a Jev con modelos grandes dentro de flujos preparados por el equipo de TypeSafe. La propia empresa reconoce que sus mejoras de 193,6× en velocidad y 444,6× en coste están probablemente en el extremo alto de lo que veremos en tareas reales. Además, utiliza como referencia el promedio de dos modelos propietarios, no una verdad anotada de forma independiente.

Las primeras pruebas externas ofrecen una historia menos espectacular y bastante más útil.

En una comparación de 100 reseñas sintéticas, repetidas tres veces, Jev obtuvo un 96,13% de acierto por campo y Luna un 97,13%. Luna fue 2,4× más lenta y cada llamada costó de media 4,88× más. Una petición de Jev terminó además en un error HTTP después de 41 segundos, suficiente para recordar que una mediana rápida no elimina las colas ni los fallos de la infraestructura.

El resultado no demuestra que uno sea universalmente mejor. Solo muestra que, en una clasificación sencilla, un LLM pequeño con JSON estricto puede mantener una precisión similar. La ventaja de Jev apareció en el coste y la latencia, no en una inteligencia claramente superior.

Un benchmark con 2.000 correos de phishing fue mucho más duro. Preguntado directamente si se debía pulsar el enlace, Jev acertó el 62,6% y Claude Haiku 4.5 el 81,3%. Jev también quedó peor calibrado. Era más rápido y barato, pero se equivocaba demasiado para automatizar esa decisión.

Si el análisis terminase ahí, Jev sería simplemente un clasificador muy económico que perdió contra un LLM pequeño. El experimento continuó y ahí es donde se vuelve interesante.

##Un agente no necesita un único cerebro

Durante los últimos años hemos utilizado el LLM como una CPU universal. Interpreta la petición, decide qué hacer, genera los argumentos, llama a herramientas y explica el resultado. Cuando algo falla, añadimos otra instrucción al prompt y esperamos que todas esas responsabilidades sigan cabiendo dentro de la misma conversación.

Jev sugiere una arquitectura menos cómoda al principio, pero más clara cuando el sistema crece. La propia guía de TypeSafe insiste en que System One no es un agente, no elige su siguiente acción y no debería controlar el flujo. La idea es integrarlo en un flujo de software convencional para resolver decisiones acotadas mientras el código conserva el control.

##Jev importa aunque no sea una revolución

Es posible que TypeSafe termine publicando una arquitectura realmente distinta. También es posible que Jev combine un encoder con una decision head y que buena parte de sus mejoras proceda del entrenamiento para calibrar las probabilidades y de la infraestructura. Con la información disponible no podemos resolverlo.

Ya han aparecido proyectos abiertos que exploran una forma parecida. Laya combina ModernBERT con una decision head y ofrece operaciones compatibles con Choice, Score y Noul. También existe un Qwen3 de 0.6B entrenado con RLCD. Sus resultados no demuestran que hayan reproducido la calidad de Jev, pero sí que la categoría se puede investigar de forma abierta.

Y esa categoría merece atención. Los LLM generativos desplazaron a muchos clasificadores porque se podían programar con una frase y funcionaban en tareas que no justificaban reunir un dataset. Jev intenta conservar esa flexibilidad y recuperar algunas propiedades que perdimos por el camino: decisiones acotadas, probabilidades utilizables y muchas preguntas resueltas en paralelo.

No hace falta que haya inventado cada ingrediente para que la combinación sea valiosa. Tampoco hace falta llamarlo «nuevo cerebro para la IA». A veces un buen producto consiste en colocar una frontera útil donde todo el mundo se había acostumbrado a no verla.

##Conclusión

Jev no demuestra que los LLM sobren. Demuestra que generar, decidir y ejecutar son trabajos distintos, aunque durante años hayamos utilizado la misma API para los tres.

Seguiré necesitando un modelo generativo cuando el sistema tenga que interpretar o crear algo que no puedo definir de antemano. Para elegir entre opciones conocidas, quizá prefiera un modelo entrenado para decidir. Y cuando exista una regla exacta, seguiré prefiriendo resolverla con código que dé siempre el mismo resultado.

El error no está en utilizar un LLM. Está en convertirlo en la única pieza inteligente del sistema. Si no hay nada que escribir, quizá tampoco haga falta llamar a un modelo que escribe.