Jev para desarrolladores: diferencias con los LLM
Jev es un modelo para decisiones estructuradas desarrollado por TypeSafe AI. Vincula al código opciones y probabilidades, y al adoptarlo en la práctica hay que distinguir entre el formato de salida y la precisión de las decisiones.
Jev devuelve opciones predefinidas y probabilidades en lugar de explicaciones libres.
Choice y Score incluyen un nivel de confianza, pero Noul no tiene un campo de confianza separado.
El precio de entrada anunciado el 15 de septiembre de 2026 es de 0.042 dólares por cada millón de tokens.
La comparación de velocidad publicada se basa en una tarea y un entorno de medición específicos.
Para tareas en coreano, compruebe con casos reales la precisión y los criterios para pasar a revisión.
Jev es un modelo desarrollado por TypeSafe para tomar decisiones de software. Devuelve valores seleccionados y probabilidades en lugar de textos explicativos. Está diseñado para la clasificación y la bifurcación de tareas. Aunque el formato de salida sea correcto, la decisión puede ser errónea.
Las cifras de precios y velocidad se basan en el anuncio de TypeSafe del 15 de septiembre de 2026.
Qué significan Jev y System One Model
Jev es una IA que produce resultados de decisión que el código puede usar directamente. Su nombre oficial de producto es Jev. TypeSafe denomina a esta familia System One Model.
La entrada incluye state, que es el objeto de la decisión, y questions, que contiene las preguntas. state es la información necesaria para decidir, como una consulta de un cliente o un registro de trabajo. En las preguntas se especifican las respuestas permitidas y los criterios de evaluación.
El nombre System One procede del pensamiento rápido e intuitivo. Es el término que usa la empresa para explicar la función del producto. También cuenta con la capacidad de comprender entradas en lenguaje natural. Puede consultar el concepto y el alcance de las entradas en la documentación de System One de TypeSafe.
¿En qué se diferencia de un LLM?
La diferencia principal es el alcance de las respuestas que puede producir. Un LLM genera contenido libre, como textos explicativos y código. Jev decide dentro del conjunto de respuestas definido por el desarrollador.
Aspecto comparado | Uso habitual de un LLM | Uso de Jev
Resultado principal | Texto explicativo, resumen, código generado | Valor seleccionado, puntuación de evaluación, probabilidad
Alcance de las respuestas | Generación libre o salida estructurada | Alcance predefinido en la pregunta
Integración con software | Interpretación y validación según el formato de respuesta | Conexión del valor devuelto con condiciones y clasificaciones
Generación de explicaciones | Puede redactar en frases los motivos de una decisión | No admite la generación libre de textos explicativos
Función adecuada | Conversación, redacción, resolución de problemas complejos | Clasificación, selección de la ruta responsable, evaluación por criterios
También se puede configurar un LLM para que responda en un formato estructurado. Por tanto, la salida JSON no es una función exclusiva de Jev. La documentación de Vercel también explica cómo conectarlo con un LLM estructurado. Sin embargo, un mismo formato de respuesta no implica el mismo comportamiento de evaluación. Esta distinción se explica en el artículo de Vercel sobre Jev.
En el software, el formato de salida debe ser correcto para poder ejecutar la siguiente tarea. Por ejemplo, el valor del departamento responsable debe contener un nombre permitido. Si se mezcla con texto explicativo, hace falta un proceso de interpretación adicional. Jev está diseñado para devolver directamente este tipo de resultados de decisión.
Resumen de Choice·Score·Noul según las condiciones
Elija el tipo según la forma que deba tener la respuesta a la pregunta. Los tipos básicos de pregunta de Jev son Choice, Score y Noul. Las preguntas independientes sobre un mismo estado pueden agruparse en una sola llamada. La forma de configurarlas se explica en TypeSafe Introduction.
Decisión necesaria | Tipo de pregunta | Contenido devuelto | Ejemplo de uso
Elegir entre opciones definidas | Choice | Valor seleccionado, probabilidad de cada opción, confianza | Enviar una consulta al departamento responsable
Evaluar con criterios ordenados | Score | Puntuación, probabilidad de cada nivel, confianza | Evaluar la gravedad de una incidencia
Determinar si una afirmación es cierta | Noul | Valor de 0-1 que representa la probabilidad de «sí» | Determinar si se incluye una solicitud de reembolso
El número de Score indica la posición dentro de los niveles de evaluación configurados. No siempre representa un porcentaje. Noul es un tipo que devuelve la probabilidad de «sí». La documentación de Score y la documentación de Noul establecen los criterios de interpretación de cada uno.
Defina el orden de procesamiento de las preguntas que dependan entre sí. Si una pregunta posterior necesita una respuesta anterior, debe conectarlas en el código. Las preguntas incluidas en una misma llamada evalúan de forma independiente el estado común.
¿Cómo deben interpretarse las cifras del caso de atención en un restaurante?
Las cifras de la demostración de atención en un restaurante no pueden considerarse una medida de la precisión general del producto. En la explicación del vídeo de presentación aparecen los siguientes valores. No se han podido comprobar la solicitud original a la API ni las condiciones de medición.
Valor presentado | Significado en la explicación | Aspectos que deben comprobarse al interpretarlo
0.09 en una escala de 0-1 | Evaluación de la legitimidad de la conducta del cliente | Comprobar si es una puntuación o la probabilidad de «sí»
Idoneidad de la opción 94% | Valor asignado a la opción de explicar el motivo del pago | Comprobar las opciones presentadas y los criterios de la pregunta
Confianza 92% | Indicación de la confianza en esa decisión | No interpretarla como la tasa real de aciertos
Tiempo de procesamiento inferior a 0.1 segundos | Tiempo de respuesta presentado en la demostración | Comprobar si incluye el tiempo de comunicación
Este caso es un ejemplo para entender el formato de salida. Las cifras por sí solas no permiten resolver un conflicto real. En particular, si cambia la composición de las opciones, cambia también la propia pregunta.
Errores frecuentes al confundir la probabilidad y la confianza
La probabilidad y la confianza son valores diferentes. Las probabilidades de Choice son los valores asignados a cada opción. La confianza resume hasta qué punto está concentrada esa distribución de probabilidades.
Por tanto, una confianza del 92% no debe interpretarse como una tasa de aciertos del 92%. La tasa real de aciertos debe medirse con casos cuya respuesta correcta se haya confirmado. Noul no tiene un campo confidence independiente. Esta distinción se especifica en la documentación de TypeSafe sobre Confidence.
· Confusión entre formato y precisión: Aunque se elija un departamento permitido, el departamento responsable puede ser incorrecto.
· Confusión entre puntuación y probabilidad: El valor de Score puede ser la posición dentro de los niveles de evaluación.
· Confusión entre confianza y tasa de aciertos: Una confianza alta por sí sola no garantiza que una respuesta concreta sea correcta.
· Omisión de opciones: Si la respuesta necesaria no está entre las opciones, resulta difícil tomar una decisión adecuada.
La calibración consiste en reunir varias predicciones para evaluar la relación entre las probabilidades y los resultados. No es un procedimiento que garantice la exactitud de una respuesta individual. Evalúe por separado el cumplimiento del formato de salida y la exactitud semántica.
Condiciones de la comparación pública de precios y velocidad
Los precios públicos se calculan según los tokens de entrada. Un token es una unidad que el modelo usa para procesar texto. En el anuncio del 15 de septiembre de 2026 se indicó que los tokens de salida eran gratuitos.
Aspecto | Información pública | Ámbito de aplicación
Precio de entrada | 0.042 dólares por 1 millón de tokens | Precio de TypeSafe en el momento del anuncio
Precio de salida | Gratis | Precio de TypeSafe en el momento del anuncio
Tiempo de respuesta | 70-500 milisegundos | Intervalo de medición anunciado por la empresa
Entorno de medición | Principalmente ordenadores portátiles del oeste de Estados Unidos | Entorno de evaluación indicado en el anuncio de la empresa
Estas cifras no garantizan el rendimiento de todas las solicitudes. La evaluación de la empresa incluye comparaciones que toman como referencia las predicciones de modelos externos. No pueden considerarse equivalentes a la tasa de aciertos en tareas reales. Las condiciones de medición están publicadas en el anuncio de lanzamiento de TypeSafe.
Ejemplo de cálculo con el precio público
El precio base de uso de 1,000 millones de tokens de entrada es de 42 dólares. La fórmula es 1,000,000,000 ÷ 1,000,000 × 0.042. Es un ejemplo de conversión del precio público.
El precio de una decisión varía según la longitud de la entrada. Los reintentos o las llamadas posteriores a otros modelos también influyen en el coste real. Consulte los precios más recientes en la documentación de TypeSafe sobre Models.
Alcance de uso que muestra la demostración de Doom
La demostración de Doom es un caso en el que se elige una acción a partir de un estado estructurado del juego. No es una demostración que interprete directamente las imágenes de la pantalla del juego. TypeSafe explica que usó datos de estado en formato de texto. Esta condición aparece en la explicación de Doom del anuncio de lanzamiento.
Al aplicarlo al trabajo, los puntos donde se toman decisiones repetidamente son posibles candidatos. La siguiente tabla presenta ejemplos de diseño basados en sus funciones. El rendimiento en cada tarea debe validarse por separado.
Condición de la tarea | Función posible | Procesamiento adicional necesario
Clasificar consultas en departamentos definidos | Elegir con Choice la ruta responsable | Ruta de revisión para consultas ambiguas
Evaluar documentos con criterios comunes | Devolver con Score una puntuación por criterio | Definición clara de los criterios de evaluación
Comprobar si se incluye una solicitud concreta | Evaluar la afirmación con Noul | Código que determine si debe ejecutarse
Redactar un texto explicativo para el usuario | Conectar con un modelo generativo | Transmitir las fuentes originales y la decisión aprobada
Limitaciones del trabajo en coreano y del procesamiento numérico
Las tareas en coreano requieren una validación propia. TypeSafe indica que el inglés es el idioma principal de entrenamiento. También explica que el rendimiento no es igual en otros idiomas. Las condiciones de compatibilidad lingüística pueden consultarse en la documentación de Models.
Que devuelva números no significa que los cálculos sean exactos. Así se explica en el documento sobre limitaciones revisado el 17 de septiembre de 2026. El documento recomienda hacer los cálculos en el código.
Jev is not a calculator.
La frase anterior es el texto original de Jev 1.13 jaggedness.
Limitación conocida | Medida durante el desarrollo
Cálculo exacto de cantidades | Calcular en el código la cantidad de elementos
Comparación de fechas y horas | Convertir los valores extraídos a un tipo de datos de fecha y compararlos
Entradas largas no relacionadas | Seleccionar solo el contenido necesario para la decisión
Negaciones complejas y condiciones indirectas | Separarlas en preguntas claras y breves
Criterios de evaluación ambiguos o contradictorios | Alinear el significado de la pregunta y las opciones
Incluya expresiones de tareas reales en los datos de validación en coreano. También deben comprobarse el lenguaje honorífico y los sujetos omitidos. Puede comparar las respuestas del modelo con casos cuyos resultados de procesamiento estén confirmados.
Comparación de las vías de uso de la API y los SDK
Además de la conexión directa con TypeSafe, también se han confirmado vías mediante gateways. En el anuncio de lanzamiento se indicó que el acceso inicial sería por una lista de espera. Compruebe en cada servicio si su cuenta tiene acceso.
Vía | Forma de acceso confirmada | Documentación que debe consultarse
TypeSafe | Consola, API, SDK de cliente | Quick start
Vercel AI Gateway | Conexión de solicitudes de evaluación de Jev | Evaluation
OpenRouter | Registro del modelo Jev 1.13 | Página del modelo Jev 1.13
La Quick start de TypeSafe explica el procedimiento de llamada directa. Estos son los pasos básicos de esa vía.
· Compruebe en la consola los permisos de acceso de la cuenta.
· Pruebe en Playground el objeto de la decisión y las preguntas.
· Obtenga una clave de API en el panel.
· Envíe una solicitud mediante el SDK o la API HTTP.
· Conecte los valores devueltos y las probabilidades con las reglas de procesamiento del código.
La documentación de Evaluation de Vercel incluye un ejemplo de conexión. En esta vía, las preguntas de sí o no se representan como Boolean. El modelo también puede consultarse en la página de Jev 1.13 de OpenRouter. Use la documentación correspondiente como referencia para el formato de las solicitudes y los límites de cada vía.
Criterios de diseño para registrar las decisiones
Para validar los resultados de la automatización, registre también los datos de entrada que sustentan la decisión. Si solo guarda el valor seleccionado, será difícil encontrar la causa de una decisión errónea. Los siguientes puntos son propuestas de diseño basadas en la interfaz oficial.
Elemento registrado | Problema que permite comprobar
Texto original y momento usados para la decisión | Información desactualizada u omitida
Versión de las preguntas y las opciones | Diferencias en los resultados por cambios en los criterios
ID real del modelo que respondió | Efectos de un cambio de modelo
Respuesta y distribución de probabilidades | Motivo del procesamiento de casos ambiguos
Acción ejecutada por el código | Discrepancias entre la decisión y la ejecución
Resultado comprobado por una persona | Errores reales e historial de correcciones
Los alias de los nombres de modelo pueden cambiar para apuntar a una versión nueva. La versión validada puede fijarse mediante el ID del modelo. Este método operativo se explica en la documentación de TypeSafe sobre Models.
Defina los criterios para derivar un caso a revisión usando casos reales. Evalúe tanto el coste de una clasificación errónea como la carga de la revisión humana. No existe un valor de confianza universalmente válido. Para el método de validación puede consultar las indicaciones de la documentación de Confidence.
