Jev: cómo funciona una IA diseñada para decidir rápido
Neaptide · 27 de septiembre de 2026 · 12 min de lectura
Cómo funciona Jev: Choice, Score, Noul, probabilidades y límites. System One, cifras publicadas y cómo probar el modelo con tus propias tareas.
En este artículo
Un cliente escribe: «No puedo exportar el catálogo. CSV funciona, pero XLSX no. Necesito enviar el archivo a un proveedor antes de esta noche». La aplicación debe identificar el tema de la solicitud, evaluar el impacto del fallo y elegir el siguiente paso. Una respuesta extensa del modelo puede añadir trabajo innecesario: el sistema necesita unos pocos valores concretos.
Jev es el modelo de TypeSafe para este tipo de decisiones. Recibe contexto y preguntas con tipos de respuesta definidos, y devuelve valores y probabilidades que el software puede utilizar. TypeSafe llama a este enfoque System One. El modelo no redacta correos ni código, ni explica su razonamiento.
En su anuncio del 15 de septiembre de 2026, la empresa abrió el acceso anticipado y destacó la rapidez y el bajo coste de las decisiones. Para entender el valor práctico de Jev, conviene seguir todo el recorrido: desde la pregunta al modelo hasta la acción de la aplicación.
Dónde encaja Jev en una aplicación
Una petición contiene state, el material que se va a evaluar, y questions, las preguntas sobre ese material. El contexto puede ser un mensaje, un objeto JSON con los campos de una solicitud de soporte o un array con datos de texto. Las preguntas de una misma llamada comparten el contexto y se evalúan de forma independiente. Jev solo acepta datos de texto: las imágenes y el audio deben convertirse primero en texto o en los campos pertinentes.
En este ejemplo, puedes preguntar por separado qué departamento necesita el cliente, cuánto afecta el problema a su trabajo y si quiere hablar con una persona. La regla que envía las solicitudes técnicas a la cola correspondiente permanece en el código. Si cambia el proceso de atención, el desarrollador puede modificar esa regla sin cambiar las preguntas.
Esta separación tiene valor por sí misma. Preguntar «¿qué debemos hacer con este cliente?» mezcla comprensión del texto, prioridades del negocio y acciones permitidas. Las preguntas concretas facilitan localizar el paso en el que el sistema se equivocó. La documentación de TypeSafe recomienda esta organización del trabajo.
Tres tipos de pregunta, tres significados
Jev ofrece tres tipos básicos de pregunta: Choice, Score y Noul. La elección depende de lo que el programa necesite averiguar.
Choice sirve cuando se necesita una opción de un conjunto definido, como technical, billing u other. La respuesta incluye la opción elegida, una distribución de probabilidades y confidence. Las descripciones de las categorías deben permitir distinguirlas.
Score sirve para una escala ordenada. Para valorar el impacto de un fallo, puedes definir los niveles «no afecta al trabajo», «lo dificulta, pero hay una alternativa» y «el trabajo está bloqueado». El resultado puede quedar entre dos niveles: se calcula como la media de sus índices, ponderada por las probabilidades. Un valor de 1,4 en una escala de 0 a 2 no significa que el 70 % de los usuarios esté afectado.
Noul evalúa una sola pregunta con respuestas sí o no: por ejemplo, «¿El cliente pide explícitamente hablar con una persona?». Un número entre 0 y 1 expresa la probabilidad de «sí». Un valor cercano a 0,5 indica incertidumbre, no una «petición moderada». Noul no tiene un campo confidence independiente.
Para comprobar la redacción, pregúntate si un compañero podría distinguir las opciones sin una explicación verbal de quien las escribió. Si no es así, aclara primero las categorías y los niveles. El modelo no resolverá por el desarrollador la ambigüedad de una regla de negocio.
Qué cubre la promesa de «no alucinar»
En el anuncio, TypeSafe relaciona la ausencia de alucinaciones con un espacio de respuestas limitado: el modelo devuelve valores permitidos por la estructura. Esto resuelve un problema concreto, la aparición de una respuesta arbitraria donde el programa espera un tipo determinado.
Si hay tres departamentos disponibles, elegir uno que existe no demuestra que la solicitud haya llegado al equipo adecuado. Una garantía de formato no implica una comprensión correcta del texto. Por la misma razón, cumplir el esquema no demuestra que una acción de negocio sea correcta.
Tampoco basta con comparar Jev con un modelo de chat al que se le pide «devuelve JSON». El propio adaptador de TypeSafe admite los modos nativos de salida estructurada de los LLM. Para un proyecto real, compara integraciones completas: calidad de las decisiones, latencia, coste y gestión de fallos.
Las probabilidades sirven si el programa sabe utilizarlas
Imagina dos respuestas Choice con la misma opción ganadora: soporte técnico. En la primera, esa opción concentra casi toda la probabilidad. En la segunda, las otras dos opciones están cerca. El nombre del departamento elegido, por sí solo, oculta esa diferencia.
En Choice y Score, confidence se calcula a partir de la forma de la distribución de probabilidades. No debe interpretarse automáticamente como «la probabilidad de que esta respuesta sea correcta». TypeSafe propone usarlo para decidir cómo continuar, con umbrales adaptados a cada tarea.
La calibración es otro concepto. En un conjunto amplio de predicciones comparables que asignan una probabilidad de 0,8 a un suceso, este debería ocurrir aproximadamente el 80 % de las veces si el modelo está bien calibrado. Es una propiedad del conjunto de predicciones. No promete una respuesta correcta en cada caso. Según TypeSafe, RLCD, Reinforcement Learning for Calibrated Decisions, es el método orientado a entrenar esas probabilidades.
La consecuencia práctica es prever una ruta para las solicitudes ambiguas. Una elección clara de departamento puede permitir el envío automático, mientras que una distribución dispersa puede llevar la solicitud a una cola de revisión general. El umbral depende del coste de enviarla al lugar equivocado y de las pruebas con tus propios mensajes.
Cómo interpretar las cifras de velocidad y coste
Las cifras publicadas sirven para una primera estimación, pero tienen bases distintas. El precio de la documentación es una tarifa. El tiempo de respuesta es una medida en determinadas condiciones. Una ventaja en un conjunto de pruebas es una comparación con alternativas seleccionadas.
| Indicador | Qué se ha publicado | Cómo utilizarlo |
|---|---|---|
| Tiempo de respuesta | El anuncio indica 70–500 ms; las evaluaciones se realizaban generalmente desde la costa oeste de EE. UU., donde estaba el servicio | Mide la latencia desde la región de tu aplicación, incluidas las respuestas lentas |
| Precio de Jev 1.13 | 0,042 USD por millón de tokens de entrada; los de salida son gratuitos | Calcula toda la entrada, incluidos contexto y preguntas |
| Calidad de los flujos | Cuatro escenarios: incidentes de seguridad, observabilidad de agentes, procesamiento de facturas y atención al cliente | Revisa la metodología y prueba tus propios escenarios |
Fuentes: condiciones de medición del anuncio, modelos y tarifas, Workflow evals. Comprobadas el 27 de septiembre de 2026.
Workflow evals construye su referencia a partir del promedio de las respuestas de GPT-6 Astra y Claude Fable 5.1 con un nivel de razonamiento alto; los demás participantes usan la configuración predeterminada de su proveedor. Por tanto, el resultado mide la concordancia con una referencia producida por modelos dentro de un proceso definido. No equivale a medir la precisión frente a resultados reales etiquetados de forma independiente.
Para hacerse una idea de la tarifa, tomemos un cálculo ilustrativo: un millón de llamadas de mil tokens de entrada cada una suma mil millones de tokens, es decir, 42 USD a la tarifa publicada. Esos mil tokens deben incluir tanto el contexto como las preguntas. El cálculo excluye reintentos, otros modelos, infraestructura y revisión humana.
Al elegir una solución, resulta más útil calcular el coste por solicitud resuelta correctamente. Una llamada barata ayuda poco si una parte considerable de los resultados necesita corrección humana.
Dónde ayuda Jev y dónde hace falta otra herramienta
Las decisiones repetitivas sobre texto son un buen punto de partida: identificar el tema de una solicitud, evaluar si algo coincide con una descripción o elegir una categoría. El siguiente paso depende de lo que el sistema deba hacer con el resultado.
Para el fallo de exportación, Jev puede evaluar el contenido de la queja. Comprobar la disponibilidad del servicio, calcular el plazo del SLA y cambiar el estado de la solicitud siguen siendo operaciones de software convencionales. El correo al cliente puede componerse con una plantilla o redactarse con un modelo generativo al que se faciliten los datos verificados y la acción elegida.
Esta distribución refleja las limitaciones de Jev 1.13 descritas por TypeSafe. El modelo no es fiable al contar con precisión ni al comparar fechas; la información irrelevante en un contexto largo perjudica las respuestas. Un texto diseñado deliberadamente puede influir en la clasificación. El desarrollador recomienda mantener los cálculos en el código, eliminar el contexto irrelevante y probar los casos difíciles.
Para un producto en español, prepara un conjunto de pruebas en español. La documentación identifica el inglés como el idioma principal de entrenamiento y aquel en el que la precisión actual es mejor; el rendimiento puede variar en otros idiomas. Esto es especialmente relevante si las solicitudes contienen abreviaturas, erratas y vocabulario especializado.
Cómo empezar una prueba piloto en tu producto
Elige una decisión frecuente con un resultado correcto claro, como asignar solicitudes a departamentos. Conserva el proceso actual como referencia. Etiqueta ejemplos reales y anonimizados, incluidos los ambiguos, y separa el material de ajuste del conjunto de evaluación final.
Observa juntas dos magnitudes: qué proporción de solicitudes se procesa automáticamente y con qué frecuencia se equivoca el sistema dentro de esa proporción. Un umbral que envía casi todo a una persona puede ofrecer una precisión excelente sin automatizar apenas nada. Un umbral más permisivo debe evaluarse teniendo en cuenta el coste de las correcciones.
Añade la latencia p95, el tiempo en el que termina el 95 % de las peticiones medidas, el gasto del modelo y la carga de trabajo manual. Compara Jev con el proceso actual y con un LLM adecuado usando los mismos ejemplos. El adaptador de TypeSafe permite devolver probabilidades o decisiones discretas: elige condiciones de comparación que reflejen las necesidades reales de la aplicación.
Guarda la versión del modelo, las preguntas y los umbrales junto con los resultados. El alias jev-latest puede pasar a señalar una nueva versión; la documentación recomienda fijar un identificador concreto cuando el comportamiento ya se ha ajustado a esa versión.
La idea de ingeniería de Jev es clara: convertir una evaluación del significado en un paso pequeño y observable dentro de un programa. Pruébala donde esos pasos sean frecuentes y el equipo pueda definir con precisión qué constituye un error. Así, el piloto mostrará qué decisiones se pueden automatizar y cuánta incertidumbre queda fuera de esa automatización.
Artículo basado en fuentes primarias públicas comprobadas el 27 de septiembre de 2026. Los ejemplos y diagramas son ilustrativos. No se hicieron llamadas a la API ni pruebas independientes de Jev.