Modelo de decisión Jev: diseño de ramificaciones y límites
Jev es el modelo de decisión de TypeSafe AI que devuelve opciones predefinidas y probabilidades. Se explica cómo vincular al código cada tipo de pregunta y cómo funciona la inferencia de tipos. También se resumen la interpretación de la confianza y los aspectos que deben verificarse al aplicarlo al coreano.
Jev devuelve opciones y probabilidades que el código puede usar en lugar de frases libres.
Choice sirve para elegir una categoría; Score, para evaluar por niveles; y Noul, para consultar la probabilidad de que algo sea verdadero.
El SDK de TypeScript infiere el tipo de respuesta a partir de la definición de la pregunta.
confidence es un valor que resume la distribución de probabilidad y no equivale a la tasa de aciertos.
Los servicios en coreano deben evaluar con sus propios datos tanto la tasa de procesamiento automático como la tasa de decisiones erróneas.
Jev es el modelo de decisión de TypeSafe AI que devuelve opciones predefinidas y probabilidades. Es adecuado para conectar juicios sobre lenguaje natural con condiciones de bifurcación en el código. Limita el formato de salida, pero no garantiza la exactitud del juicio.
Los precios se basan en el anuncio del 15 de septiembre de 2026 y las limitaciones, en la documentación revisada el 17 de septiembre.
¿Qué tarea cumple Jev?
Jev lee el contenido de entrada y devuelve respuestas estructuradas a preguntas definidas de antemano. El contenido que se evaluará se coloca en state. Los criterios de evaluación se definen en questions. Las respuestas devueltas pueden usarse para clasificar o establecer prioridades.
TypeSafe AI llama a este enfoque modelo System One. Describe su método de entrenamiento con el nombre RLCD. Se trata de aprendizaje por refuerzo centrado en calibrar las probabilidades de los juicios. No obstante, la exactitud debe verificarse por separado para cada servicio.
El documento oficial Introduction expresa así el principio de diseño:
Atomic questions, composed in code TypeSafe AI, Introduction
Esto significa asignar un solo juicio a cada pregunta. La combinación de varios juicios se gestiona en el código. Las preguntas de una misma solicitud evalúan el mismo estado de forma independiente. Puede consultar la estructura en detalle en TypeSafe AI Introduction.
Comparación de Choice·Score·Noul
Elija el tipo de pregunta según cómo vaya a usar la respuesta en el código. Identificar el departamento responsable es un problema de selección de categorías. Evaluar la gravedad implica una escala ordenada. La presencia de una solicitud concreta puede dividirse entre verdadero y falso.
Tipo | Qué pregunta | Valores principales devueltos | Uso en el código
Choice | A cuál de las categorías predefinidas pertenece | choice, probabilities, confidence | Bifurcación con switch
Score | A qué nivel de los descritos corresponde | score, probabilities, confidence | Comparación de la puntuación con un umbral
Noul | Si se cumple una condición concreta | noul | Comparación de la probabilidad y bifurcación con if
¿Cómo se definen las opciones de Choice?
Choice admite hasta 255 opciones por pregunta. Evalúa tanto el nombre como la descripción de cada opción. Si pueden llegar entradas que no figuren en la lista, considere incluir una opción como other. Esto ayuda a reducir las clasificaciones forzadas.
Choice elige una de las opciones proporcionadas. Si también necesita determinar por separado si todas las opciones son inadecuadas, debe añadir una pregunta. La suma de las probabilidades devueltas es 1. Las definiciones y los límites figuran en la documentación de Choice.
¿En qué se diferencian Score y Noul?
Score evalúa la posición dentro de una serie de niveles descritos. La numeración de los niveles empieza en 0. El resultado es la media ponderada por probabilidad de los números de nivel. Por eso también puede devolver puntuaciones no enteras.
Noul devuelve la probabilidad de que una condición sea verdadera, entre 0 y 1. Un valor cercano a 0,5 significa que las probabilidades de verdadero y falso son parecidas. No debe interpretarse como un grado intermedio de descontento. Use Score para medir el grado y Noul para preguntar por la presencia de algo.
Comparación de funciones con el código convencional y los modelos generativos
Deje los cálculos exactos al código y encargue al modelo solo los juicios sobre el significado. Redactar texto nuevo corresponde a un modelo generativo. Jev es adecuado para juicios cuyo conjunto de respuestas está definido. Esta distinción permite decidir qué parte de una función existente conviene sustituir.
Condición de la tarea | Método adecuado | Motivo
Calcular el intervalo entre fechas o contar elementos | Código convencional | Puede calcularse exactamente siguiendo reglas
Clasificar el departamento responsable de una consulta de un cliente | Jev Choice | Juicio sobre el significado con opciones definidas
Evaluar la gravedad de un informe de incidencia | Jev Score | Juicio entre niveles descritos
Confirmar una solicitud de contacto con un agente | Jev Noul | Juicio sobre la presencia de una intención concreta
Redactar respuestas o resumir libremente | Modelo generativo | Es necesario generar texto nuevo
Al procesar salidas de texto, puede hacer falta código que valide el formato. Jev devuelve directamente respuestas con el formato definido. Esto no elimina todas las validaciones ni los reintentos. El SDK oficial también ofrece una política de reintentos ante errores de comunicación, entre otros.
Siga diseñando por separado la validación de entradas externas y las comprobaciones de reglas de negocio. Aunque la respuesta del modelo tenga el tipo correcto, puede ser incorrecta para la tarea. Esta distinción es una interpretación de diseño basada en Client SDKs y en la documentación sobre las limitaciones del modelo oficiales.
Definición de preguntas y tipos de respuesta en TypeScript
El SDK de TypeScript infiere el tipo de los valores devueltos a partir de la definición de las preguntas. Las claves de las opciones de Choice pasan a ser los valores permitidos de la respuesta. Así, las comparaciones con cadenas no permitidas pueden detectarse durante la compilación. El SDK requiere Node.js 20 o posterior.
El siguiente código es un ejemplo explicativo basado en el formato de llamada del SDK oficial. No muestra resultados de ejecución ni mediciones de exactitud. Es necesario configurar la variable de entorno TYPESAFE_API_KEY.
import { TypeSafeClient, choice } from "@typesafe-ai/sdk";
const api = new TypeSafeClient();
async function classifyMessage(message: string) {
const result = await api.systemOne({
model: "jev-1.13.0",
state: { message },
questions: {
topic: choice("Classify the subject of message.", {
account: "Account access or password problems",
delivery: "Shipment tracking or delivery problems",
other: "Any subject outside those categories",
}),
},
});
return result.answers.topic;
}
En este ejemplo, el tipo de choice es account | delivery | other. En TypeScript, estas cadenas son tipos literales que se muestran entre comillas. Sin embargo, la comprobación de tipos no determina si una consulta se ha clasificado correctamente. Consulte los requisitos de instalación y el formato de las llamadas en la documentación del SDK de JavaScript.
Ejemplo de cálculo de la confianza y errores habituales
confidence es un valor que resume las probabilidades devueltas. No es la misma cifra que la probabilidad de la respuesta elegida. Tampoco debe interpretarse directamente como la tasa real de aciertos. Es especialmente importante tener en cuenta esta diferencia al definir criterios de ejecución automática.
La fórmula oficial de Choice es la siguiente:
confidence = (probabilidad máxima - 1 / número de opciones) / (1 - 1 / número de opciones)
La distribución de probabilidades del documento oficial es 0.6, 0.3, 0.1. Hay 3 opciones. Al sustituir la probabilidad máxima por 0,6, el valor de confidence es 0,4. La probabilidad de la opción elegida, 60 %, y la confianza, 0,4, son indicadores distintos.
Interpretación habitual | Interpretación correcta
Una confidence de 0,4 equivale a una tasa de aciertos del 40 % | Es un valor que resume la distribución de probabilidades según la fórmula
Un Noul de 0,5 indica un nivel medio | Se han asignado probabilidades parecidas a verdadero y falso
Los decimales de Score son una medición precisa | Son la media ponderada por probabilidad de los números de nivel definidos
Una confianza alta permite omitir las comprobaciones de permisos | Los permisos de negocio y las condiciones de ejecución se comprueban por separado en el código
El significado de estas cifras se basa en la documentación oficial de Confidence. La recomendación de separar las comprobaciones de permisos es una propuesta de diseño para su aplicación operativa.
¿Cómo comparar el precio y el tiempo de respuesta?
El precio anunciado es de 0,042 dólares por cada millón de tokens de entrada. Se indicó que los tokens de salida son gratuitos. El intervalo de tiempos de respuesta anunciado es de 70 a 500 milisegundos. Estas cifras se basan en el anuncio de la empresa del 15 de septiembre de 2026.
Las comparaciones por múltiplos de la empresa proceden de la evaluación de un flujo de trabajo concreto. En vez de respuestas correctas reales, se tomó como referencia la predicción media de otros modelos grandes. La evaluación de velocidad se hizo principalmente desde el oeste de Estados Unidos. Por tanto, no indica la exactitud en todas las tareas ni los tiempos de respuesta en Corea.
Aspecto de la comparación | Qué comprobar
Coste de la API | Uso real de tokens de entrada y precio aplicable
Tiempo de respuesta | Tiempo de ida y vuelta desde la región donde se ejecuta el servicio
Exactitud | Resultados de muestras de trabajo real con respuestas correctas asignadas
Coste operativo | Coste incluidos los reintentos y la revisión humana
Comparar solo los precios puede pasar por alto situaciones en las que aumenta el trabajo de revisión. Para decidir si adoptarlo, hay que considerar también el coste de los resultados del procesamiento. Las condiciones de las cifras anunciadas figuran en el anuncio público de Jev.
Nueve limitaciones de Jev 1.13
La documentación oficial agrupa en nueve categorías los tipos de fallos de Jev 1.13. Esta lista corresponde a la revisión del 17 de septiembre de 2026. Que funcione en algunos casos no garantiza que sea fiable para esa tarea.
Tipo de fallo | Respuesta de diseño
Interpretación literal de las expresiones | Especificar en las instrucciones las condiciones implícitas
Cálculos y recuentos | Gestionar la aritmética en el código
Comparación de fechas y horas | Construir las fechas y compararlas en el código
Doble negación y razonamientos de varios pasos | Separarlos en preguntas directas
Entradas con mucho contenido irrelevante | Enviar solo los campos necesarios
Entradas que inducen una respuesta | Hacer una evaluación previa que incluya frases inductivas
Conflictos entre las instrucciones y los criterios de selección | Alinear el significado de la pregunta y los criterios
Falta de coherencia matemática entre preguntas | Gestionar las relaciones lógicas en el código
Generación libre de texto | Usar un modelo generativo
Un mismo significado puede producir probabilidades distintas en Noul y Choice. No traslade directamente a un tipo un umbral ajustado para otro. La referencia es Jev 1.13 jaggedness.
Condiciones para aplicarlo a un servicio en coreano
Procesa entradas en coreano, pero no garantiza un rendimiento equivalente al del inglés. La documentación oficial explica que el idioma principal de entrenamiento es el inglés. También señala diferencias de rendimiento en los sistemas de escritura CJK, incluido el coreano. No proporciona una cifra general de exactitud para el coreano.
Decida si aplicarlo al coreano a partir de muestras propias. Conviene incluir consultas con expresiones indirectas y omisiones. Si solo evalúa traducciones, puede pasar por alto las diferencias en la forma de escribir de los clientes reales. Esta es una propuesta de evaluación que tiene en cuenta las diferencias de rendimiento entre idiomas.
· Evaluar por separado las solicitudes claras y las ambiguas
· Registrar por separado la clasificación por departamento y la evaluación de emociones
· Volver a validar en coreano los umbrales definidos en inglés
· Comparar las mismas muestras antes y después de cambiar el modelo
Cuando sale una versión nueva, cambia el modelo al que apunta jev-latest. Si ajustó los umbrales para una versión concreta, considere fijar esa versión. Puede consultar las políticas de idioma y versiones en la documentación oficial de Models.
La tasa de procesamiento automático que suele pasarse por alto al evaluar un cambio de modelo
Al cambiar de modelo, hay que examinar tanto la exactitud general como la tasa de procesamiento automático. Si todos los casos ambiguos se envían a revisión humana, disminuye el volumen procesado automáticamente. Si se amplía el alcance del procesamiento automático, pueden aumentar las ejecuciones incorrectas. El siguiente método de evaluación amplía el criterio de bifurcación basado en la confianza de la documentación oficial.
Indicador | Método de cálculo o registro | Qué permite comprobar
Tasa de procesamiento automático | Casos procesados automáticamente / total de casos evaluados | Trabajo manual que realmente se reduce
Tasa de errores en el procesamiento automático | Errores entre los casos procesados automáticamente / casos procesados automáticamente | Calidad de los resultados de la automatización
Tasa de revisión humana | Casos enviados a revisión / total de casos evaluados | Carga de revisión restante
Tiempo total de procesamiento | Medición desde la entrada hasta la finalización | Tiempo de espera, incluida la revisión
Si no hay casos procesados automáticamente, no se puede calcular la tasa de errores en el procesamiento automático. En ese caso, regístrela como «no calculable» en lugar de 0 %. Es necesario conservar el denominador de los indicadores para poder comparar modelos.
La evaluación puede seguir estos pasos:
· Pida a una persona que asigne las respuestas correctas a muestras de trabajo real.
· Fije la redacción de las preguntas y la definición de las opciones.
· Registre la versión del modelo, las probabilidades y la bifurcación final.
· Compare la tasa de procesamiento automático y la tasa de errores para cada umbral.
· Defina los criterios operativos según el nivel de error aceptable.
No existe un umbral adecuado para todos los casos. Los criterios deben reflejar las consecuencias de una ejecución incorrecta. Puede consultar el principio de bifurcación que sirve de punto de partida en la documentación de Confidence.
