Jev es el modelo insignia de TypeSafe, y el primero de su línea System One: construido para responder preguntas que tu código, no una persona, tiene que usar para actuar. Vale la pena entender esa diferencia antes de mirar la forma exacta de la petición.
Qué devuelve Jev
La mayoría de los modelos de lenguaje están pensados para escribir texto que una persona lee después. Si lo dejas generar texto libre, uno al que le pides que clasifique un ticket te devuelve un párrafo que después tienes que interpretar, con la esperanza de que el formato se mantenga igual llamada tras llamada. La propia introducción de TypeSafe nombra el desajuste de fondo: estás forzando a un sistema hecho para generar texto a producir una decisión estructurada.
Jev se salta ese paso. Le envías un state, el material que quieres evaluar, y una o más questions tipadas, y te devuelve answers tipadas que tu código puede usar de inmediato. Hay tres tipos de pregunta. Choice elige una opción entre las que tú definas y devuelve esa opción junto con la distribución de probabilidad completa sobre todas las opciones. Score puntúa el estado contra una escala ordenada y devuelve una posición ponderada por probabilidad sobre esa escala. Noul responde una pregunta de sí o no con una única probabilidad, de 0 (no) a 1 (sí). Choice y Score también traen un valor de confidence, un número que resume qué tan concentrada está la probabilidad. Noul no lo trae: no hay nada más que resumir además del número mismo.
Imagina que estás clasificando un mensaje como “Mi exportación falló tres veces hoy y no puedo enviar el reporte.” Una pregunta Noul sobre si esto necesita atención inmediata podría devolver 0.91. Ese número tu código puede usarlo directamente para decidir. Sin expresiones regulares, sin pedirle al modelo que “responda solo en JSON.”
Dónde encaja en una aplicación
La petición en sí es una llamada HTTP, POST https://api.typesafe.ai/v1/systemone, con model, state y un mapa de questions en el cuerpo, autenticada con una clave que se queda en tu servidor. Cada pregunta del mapa se evalúa contra el mismo estado, en paralelo, sin ver las respuestas de las demás. Es una decisión de diseño deliberada: cada juicio queda aislado, así que una respuesta mala en una pregunta no contamina silenciosamente otra. Si mezclas un Choice, un Score y dos Noul en una sola llamada, recibes cuatro respuestas independientes, identificadas por las claves que tú elegiste (Jev nunca ve esas claves, solo las instrucciones de cada pregunta).
Esa forma encaja muy bien como una capa de clasificación y enrutamiento delante de tu lógica real. Una bandeja de soporte es el ejemplo obvio: una sola llamada puede decidir qué equipo debe atender un ticket, si es urgente y cuánto está afectando el trabajo del cliente, y tu código enruta desde ahí, lógica determinista para los casos sencillos, un modelo especializado o una persona para el resto. Recorro exactamente ese ejemplo en el próximo artículo.
Una respuesta tipada también puede ser incorrecta
Aquí está la parte fácil de pasar por alto: una respuesta tipada no es una respuesta correcta. Forzar el formato de salida no fuerza el juicio detrás de esa salida. La confianza te dice qué tan concentrada está la probabilidad del modelo. No te dice si acertó en tu caso concreto.
Hay dos trampas concretas que conviene conocer antes de construir nada. Primero, Score no es una escala de 0 a 1 por defecto. Va de 0 a n menos 1, donde n es la cantidad de niveles que definiste, así que tres niveles significan 0 a 2. Si quieres una fracción normalizada, divide por n menos 1 tú mismo; la API no lo hace por ti. Segundo, el modelo detrás de tu llamada es una versión concreta y fijada. Al 21 de septiembre de 2026, esa versión es jev-1.13.0, y los alias jev-latest y jev-preview apuntan ambos a ella, pero los alias se mueven cuando sale una versión nueva, y los umbrales que ajustaste contra una versión no tienen garantía de funcionar igual en la siguiente. La propia lista de límites conocidos de TypeSafe, lo que llaman jaggedness, señala lectura demasiado literal, aritmética y conteo poco confiables, comparación de fechas poco fiable, y sensibilidad a instrucciones adversariales o contradictorias. Nada de eso aparece en el esquema de la respuesta. Aparece cuando pruebas con datos reales y desordenados.
Qué probaría primero
Si tuviera que integrar esto hoy, empezaría con un solo juicio acotado en lugar de cinco preguntas de golpe, y dejaría cualquier cosa parecida a aritmética en mi propio código en lugar de pedirle a Jev que la calcule. Fijaría la versión del modelo de forma explícita en vez de confiar en un alias, registraría qué versión respondió realmente cada llamada, y escribiría con honestidad qué significa “probado” para mi integración antes de darla por terminada. Probado sin conexión contra casos fijos es un estado real y útil. Es un estado distinto de validado con el modelo real sobre tráfico de verdad.
La confianza es la herramienta para decidir qué pasa después. No es una garantía de que la respuesta sea correcta. Los próximos dos artículos desarrollan esto en código: un ejemplo de triaje de soporte que filtra por umbrales de confianza y de probabilidad, y después un plan para medir si los umbrales que elegiste realmente funcionan.