jev-latest

Jev es el modelo insignia de TypeSafe y el primero de una nueva categoría, System One. No redacta texto: toma decisiones rápidas que un programa puede utilizar directamente. Envías un estado (state) —texto o JSON— y un conjunto de preguntas, y recibes valores tipados con probabilidades calibradas.

Los modelos de lenguaje escriben palabras para personas; según TypeSafe, Jev se parece más al código: responde directamente en el formato que el código necesita, a gran velocidad y sin ningún valor fuera de las opciones definidas. Está concebida para ofrecer respuestas estables en solicitudes repetidas.

En qué se diferencia System One de un modelo de lenguaje

• No genera. Jev no redacta respuestas para el usuario, no escribe código ni explica su razonamiento. Tú defines las respuestas posibles mediante uno de los tres tipos de preguntas.
• Está entrenada para tomar decisiones calibradas. TypeSafe entrena el modelo con RLCD (Reinforcement Learning for Calibrated Decisions): las probabilidades se ajustan a los resultados reales y reflejan la incertidumbre. De muchas respuestas con una probabilidad de 0,8, aproximadamente el 80% deberían ser correctas. La calibración es una propiedad de una muestra amplia, no una garantía de que una respuesta concreta sea correcta.
• Tiene otro objetivo de entrenamiento. Los modelos de chat se entrenan para agradar a las personas (RLHF) y, según las observaciones de TypeSafe, esto favorece la complacencia y los errores expresados con seguridad. Diogo Almeida, uno de los coautores de RLHF, es cofundador de TypeSafe.

El nombre alude al «Sistema 1» del libro de Daniel Kahneman «Pensar rápido, pensar despacio»: el juicio intuitivo y rápido frente al pensamiento lento y deliberado del «Sistema 2». Jev está diseñada para emitir juicios rápidos y concretos.

Tres tipos de preguntas

Cada pregunta pide un juicio sobre el estado; la respuesta es un valor que el código compara con un umbral, utiliza para ordenar o transmite al siguiente paso.

1. Choice — selección de una opción. El departamento para una consulta, la categoría de un producto o el lenguaje de un fragmento de código. Las opciones son un diccionario «opción → descripción», con hasta 255 entradas. La respuesta contiene la opción elegida, choice, las probabilidades probabilities de todas las opciones (que suman 1) y la confianza confidence. Si la lista puede no cubrir todos los casos, añade «otro» o «ninguna de las anteriores».
2. Score — valoración en una escala. Una posición en una escala ordenada que tú describes: la gravedad de un error, la irritación de un cliente o un nivel de habilidad. Tiene entre 2 y 10 niveles, de menor a mayor; el modelo evalúa cada nivel por separado, sin ver su número ni los niveles vecinos. La respuesta contiene score (la suma de los números de los niveles multiplicados por sus probabilidades, de modo que el valor puede quedar entre niveles), legend con sus descripciones, probabilities y confidence.
3. Noul — sí o no. Determina si una afirmación es verdadera. La respuesta noul es la probabilidad de «sí», entre 0 y 1: cerca de 1 es un «sí» seguro, cerca de 0 es un «no» seguro y cerca de 0,5 indica duda. No hay un confidence independiente: un solo número describe toda la respuesta. El parámetro opcional criteria precisa qué se considera «sí» y qué se considera «no».

Cómo elegir: para opciones conocidas sin orden, choice; para grados de un espectro, score; para un «sí/no» puro en el que importa la probabilidad, noul. Noul 0,5 indica las mismas posibilidades de «sí» y «no», no un «nivel medio»: el grado se mide con score. Si dos tipos encajan, elige aquel con el que el código pueda actuar directamente: choice para ramas, score para umbrales y noul para if.

Los tipos se pueden combinar en una misma solicitud. La respuesta siempre queda limitada a tus opciones y es independiente de las demás preguntas: puedes añadir o quitar preguntas sin cambiar las otras respuestas.

Estado

El estado es lo que el modelo evalúa: un mensaje de un cliente, un fragmento de documento, un registro de una base de datos o el estado de tu aplicación.

• Cadena — cuando hay un único texto: un mensaje, un artículo o un fragmento.
• Objeto — campos con nombre, registros relacionados o el estado de una aplicación. TypeSafe recomienda objetos para la mayoría de las solicitudes: cada parte tiene un nombre claro.
• Array — una secuencia de mensajes o registros.

Prepáralo como materiales para especialistas: reúne la conversación, el pedido y las normas de devolución si la decisión exige compararlos. Coloca el contenido en el estado y los juicios en las preguntas. Si una pregunta se refiere a una parte concreta del estado, indica su ruta entre comillas invertidas, por ejemplo ticket.messages[0].text.

Cómo formular las preguntas

• Un juicio rápido por pregunta. Una buena pregunta es aquella que una persona informada y con el contexto necesario respondería en un segundo: «¿Hay urgencia en el mensaje?». «Analiza el mensaje y decide qué hacer» ya requiere razonamiento lento y debe dividirse en preguntas sencillas.
• La pregunta completa va en instructions. La clave de la pregunta, por ejemplo refund_requested, solo la necesita tu código y no se envía al modelo.
• Todas las preguntas sobre un mismo estado, en una sola solicitud. El modelo las evalúa en paralelo: según TypeSafe, las preguntas adicionales apenas aumentan el tiempo de respuesta y solo cuestan los tokens que utilizan. Una pregunta «por si acaso» sale casi gratis: el código decidirá qué respuestas necesita.
• Los juicios complejos, por partes. En vez de «evalúa la solicitud de la startup», pregunta por separado sobre el tamaño del mercado, la viabilidad técnica y las diferencias respecto a la competencia, y calcula el resultado en el código con ponderaciones. Si cambian las prioridades, cambia las ponderaciones sin reformular la pregunta.
• Las preguntas dependientes, en una segunda solicitud. Las respuestas de una solicitud no sirven de contexto entre sí. Una segunda solicitud solo es necesaria si no puede construirse sin la primera respuesta: hay que cargar datos o elegir las opciones de la siguiente pregunta.
• Las preguntas largas, como objetos. instructions y criteria suelen ser cadenas, pero también pueden ser objetos o arrays: la pregunta en un campo y los datos en otros. Así resulta cómodo contrastar un currículo con registros de una base de datos mediante una sola pregunta.

Confianza

En choice y score, confidence va de 0 a 1 e indica hasta qué punto la probabilidad se concentra en una respuesta: 1 significa que toda se concentra en una opción y 0, que se reparte por igual entre todas. En score, un nivel vecino reduce la confianza menos que uno distante. En noul, la confianza es el propio valor: cuanto más se aleja de 0,5, más firme es la respuesta.

TypeSafe recomienda tres rangos:

1. Confianza alta — actúa automáticamente.
2. Confianza media — actúa con cautela; por ejemplo, pide confirmación al usuario.
3. Confianza baja — deriva el caso a una persona, aclara la solicitud o utiliza una vía alternativa, como un modelo más potente con razonamiento.

Cuanto mayor sea el coste de un error, más exigente debe ser el umbral: debe ser más alto para acciones irreversibles que para lectura. La respuesta indica qué elegir y la confianza, si conviene actuar. Ajusta los umbrales con tus propios datos, comparando confianza y exactitud.

Cómo construir un sistema con Jev

Jev está concebida para programas en los que el código controla el proceso y el modelo responde a preguntas semánticas concretas, en lugar de agentes que eligen por sí mismos el siguiente paso y pueden desviarse en cada ciclo. Ocho pasos de diseño según TypeSafe:

1. Todo lo que se pueda hacer con código, hazlo con código: es fiable y económico.
2. Incluye en el estado solo lo que necesitan las preguntas actuales; los datos recientes deben proceder de tu propia base de conocimientos, no de la memoria del modelo.
3. Estructura el estado con JSON anidado y, cuando reduzca la ambigüedad, indica en la pregunta la ruta al campo necesario entre comillas invertidas.
4. Formula preguntas lo más concretas y específicas posible: según TypeSafe, quizá sea la regla principal; una pregunta amplia esconde varios juicios en una sola respuesta.
5. Estructura las preguntas: la pregunta en sí debe ser breve; coloca explicaciones, ejemplos y valores de tu base en campos vecinos del objeto instructions o criteria, en lugar de una única cadena larga.
6. Reúne muchas preguntas independientes sobre un mismo estado en una solicitud: obtendrás más utilidad por cada dólar.
7. Combina las respuestas en el código mediante reglas, una suma ponderada o como características de un modelo clásico de aprendizaje automático.
8. Bifurca según la confianza: deriva los casos inciertos a una persona o a un modelo con razonamiento.

Jev no es un chat ni un modelo de autocompletado de código; no puede sustituir al modelo de lenguaje en un agente de programación. En cambio, un agente puede escribir el código que llame a Jev cuando necesites una respuesta rápida y calibrada.

Aplicaciones

• Automatización en segundo plano — decisiones que se ejecutan un millón de veces sin una persona al lado.
• Tiempo real — según TypeSafe, la mayoría de las solicitudes se resuelven en unos 100 ms: suficiente para procesamiento sobre la marcha e interfaces.
• Grandes volúmenes de datos — búsqueda en corpus enormes, etiquetado de registros de trabajo de agentes y características para predicciones.
• Comprobación de otros modelos — solicitudes, extracciones, razonamientos y llamadas a herramientas: elusión de restricciones, errores de cita e invenciones.
• Búsqueda y clasificación — relevancia del par «consulta — candidato», reclasificación y selección de contexto.
• Enrutamiento por intención — qué quiere el usuario y qué lo debe atender: lógica sencilla, un modelo especializado o una persona; el tema, la complejidad y el riesgo determinan a qué modelo de lenguaje se envía la solicitud.
• Comprobaciones de seguridad — entrada, salida y llamadas a herramientas de un modelo de lenguaje: instrucciones inyectadas, incumplimiento de normas y filtración de datos personales.
• Soporte — tema e intención de la consulta, urgencia, irritación, riesgo de abandono, solicitud de devolución y cola.
• Moderación — según las normas de tu plataforma: toxicidad, acoso, spam, fraude, consejos peligrosos y datos personales; según la gravedad y la confianza, permitir, advertir, revisar o bloquear.
• Sectores — siniestros, investigaciones financieras y KYC, contratos y publicidad, fichas de productos, selección de personal, oportunidades comerciales, juegos, riesgos, previsión de demanda, grafos de conocimiento, revisiones científicas y comprobaciones semánticas de código en CI.

Características

• jev-latest — alias de la última versión estable, actualmente Jev 1.13; la versión que ha respondido aparece en el campo model, por ejemplo jev-1.13.0. Cuando llega una versión nueva, el alias pasa a ella y las respuestas pueden cambiar sin que hagas modificaciones; vigila este campo si has ajustado los umbrales a una versión.
• Contexto — 64K tokens por solicitud: el estado y todas las preguntas juntos; el estado junto con la pregunta más larga puede ocupar hasta 32K. El modelo lee el estado una sola vez y evalúa todas las preguntas en paralelo con respecto a él.
• Entrada — solo texto: una cadena, un objeto JSON o un array de textos. Todavía no admite imágenes, audio ni vídeo; conviértelos antes en texto.
• Idioma — el principal idioma de entrenamiento es el inglés y actualmente ofrece la mayor exactitud en él. El modelo acepta otros idiomas, incluidos chino, japonés y coreano, pero con menor exactitud; compruébalo con tus propios datos.
• Precios y facturación en Ailoot API — las condiciones dependen del método seleccionado y se indican en su ficha.
• Configuración — Jev no se ajusta con datos del cliente: tus materiales van en state y las reglas del dominio, en instructions y criteria.
• Datos — TypeSafe afirma que Jev no se entrena con las solicitudes ni las respuestas de los clientes.

Limitaciones conocidas de Jev 1.13

TypeSafe enumera abiertamente las limitaciones de la versión actual y promete corregir muchas de ellas en las siguientes. El modelo es rápido, está calibrado y emite buenos juicios de sentido común, pero:

1. Lee literalmente. Responde a la pregunta escrita, no a la implícita: interpreta de forma literal las salvedades, las negaciones y las condiciones no expresadas. Escribe la condición exacta y los casos límite en criteria; si no se puede evitar una interpretación, divídela en dos preguntas literales.
2. No es una calculadora. Contar caracteres, repeticiones y elementos de una lista no es fiable, y el error aumenta con el tamaño; haz los cálculos en el código, con una pregunta por candidato. El modelo entiende peor los colores en hex o RGB que sus nombres. score sirve para un umbral, pero no para un número exacto entre niveles.
3. Fechas y horas. No determina de forma fiable qué fecha es anterior, cuánto tiempo hay entre dos fechas o si una fecha cae en un periodo, sobre todo con formatos mezclados y fechas relativas. Extrae las partes de la fecha mediante choice (con una opción «no indicado») y compáralas en el código.
4. Formulaciones indirectas. Las dobles negaciones y las preguntas sobre una propiedad de otra propiedad reducen la exactitud. Escribe de forma directa y llama a cada parte del estado por su nombre.
5. Información superflua en el estado. El texto ajeno a la tarea reduce la exactitud. Fíltralo en el código y, si no puedes, descarta lo irrelevante con preguntas noul.
6. Texto adversarial. Por defecto, el modelo no espera trampas en el estado: una instrucción inyectada o un texto que discuta su propia clasificación puede cambiar la respuesta. Escribe criterios precisos y comprueba los casos límite antes de ponerlo en funcionamiento.
7. Contradicciones. Si instructions y criteria piden cosas distintas —por ejemplo, si en noul «sí» se describe como «no»—, la exactitud disminuye. Los criterios son una continuación de la pregunta.
8. Orden de las opciones. A veces el modelo tiende a la primera opción de choice. Cambia su orden y comprueba que la respuesta se mantiene.
9. Generación. Jev no está entrenada para redactar texto. Para extraer datos, busca candidatos con una expresión regular o un modelo generativo y deja que Jev elija el correcto mediante choice.