Muchas preguntas dentro de un proceso no piden una explicación: piden elegir una opción y seguir. Los modelos de decisión apuntan a ese espacio. Qué son, dónde encajan, qué cambia respecto de pedirle un JSON a un LLM y cómo evaluar Jev, Kev y Laya antes de invertir en entrenamiento.
Muchas empresas ya usan modelos de lenguaje para responder consultas, resumir documentos o ayudar a sus equipos a escribir código.
Pero dentro de un proceso de negocio aparecen preguntas mucho más acotadas:
¿A qué equipo corresponde este reclamo?
¿El documento contiene la información necesaria para continuar?
¿Este caso necesita revisión humana?
En esos puntos, el sistema necesita elegir una opción y seguir trabajando. Generar una explicación completa puede agregar tiempo y costo sin aportar demasiado a la siguiente acción.
Los modelos de decisión apuntan a ese espacio: transformar información en una respuesta estructurada que una aplicación pueda usar directamente.
Jev, Kev y Laya son tres propuestas para explorar esta idea. Comparten un tipo de interfaz, pero tienen diferencias importantes en despliegue, capacidad y necesidad de adaptación.
Qué es un modelo de decisión
Podemos entenderlo como una función que recibe contexto, una pregunta y un conjunto de respuestas posibles.
Por ejemplo, el contexto podría ser este mensaje:
Me cobraron dos veces la suscripción de este mes. Necesito que revisen el pago.
La pregunta sería: ¿qué equipo debería atender el caso? Y las opciones:
- Facturación.
- Soporte técnico.
- Ventas.
- Revisión manual.
El resultado puede incluir la opción seleccionada y una probabilidad para cada alternativa.
{
"equipo": "facturacion",
"probabilidades": {
"facturacion": 0.93,
"soporte_tecnico": 0.03,
"ventas": 0.01,
"revision_manual": 0.03
}
}
Este JSON es un ejemplo ilustrativo, con valores inventados y un formato simplificado. No representa una ejecución real ni el contrato exacto de una API.
La aplicación recibe esa evaluación y aplica sus reglas: asignar el ticket, pedir información adicional o enviarlo a una persona.
El modelo estima; el sistema define qué hacer con esa estimación.
Qué cambia respecto de pedirle un JSON a un LLM
Un modelo de lenguaje también puede clasificar mensajes y devolver respuestas estructuradas. En muchos proyectos, esa es una buena primera implementación.
Los modelos especializados en decisiones buscan optimizar ese trabajo: puntuar alternativas predefinidas sin generar una respuesta textual extensa.
TypeSafe presenta a Jev dentro de una categoría que denomina System One, orientada a respuestas tipadas y probabilísticas para software: las salidas posibles se definen de antemano y cada respuesta llega con su probabilidad. Lo propone para clasificar, enrutar, puntuar o bifurcar un flujo, con el objetivo de reducir el costo y la latencia de esas operaciones repetidas.[1]
Y la diferencia de costo es grande. Para este tipo de tareas, un modelo de decisión resulta mucho más barato que un LLM de uso general: no genera texto, solo puntúa opciones. TypeSafe cobra la entrada a US$ 0,042 por millón de tokens, no cobra la salida y, en sus evaluaciones de workflows, reporta un costo unas 445 veces menor que el de los LLM de frontera.[1]
- ~445×
- más barato que un LLM de frontera, según las evaluaciones de TypeSafe
- US$ 0,042
- por millón de tokens de entrada; la salida no se cobra
- 70–500 ms
- de respuesta de punta a punta
Son cifras del proveedor, medidas en sus propias pruebas, y la empresa reconoce que todavía tiene que demostrar que ese precio es sostenible. Pero la razón de fondo es estructural: elegir entre opciones conocidas exige mucho menos cómputo que redactar una respuesta. Por eso también un modelo abierto y chico como Kev puede resolver estas consultas con mucho menos hardware que un LLM general.
La clasificación automática existe desde mucho antes de esta categoría. También se pueden resolver problemas concretos con reglas, clasificadores tradicionales o modelos de lenguaje con salidas restringidas. La elección depende de qué necesita el proceso y de cuánto cuesta mantener cada alternativa.
| Necesidad | Enfoque que conviene evaluar |
|---|---|
| Aplicar una regla exacta sobre datos estructurados | Código o motor de reglas |
| Clasificar una tarea estable con muchos ejemplos etiquetados | Clasificador especializado |
| Evaluar texto contra opciones descritas en lenguaje natural | Modelo de decisión o LLM con salida estructurada |
| Redactar, explicar o elaborar una respuesta abierta | Modelo generativo |
Estas piezas pueden convivir dentro de una misma aplicación.
Tres responsabilidades dentro del proceso
Supongamos que queremos automatizar parte de la atención de reclamos. Podemos separar el trabajo en tres responsabilidades.
El modelo de decisión evalúa el contenido: tema del reclamo, urgencia o necesidad de más información.
El código de negocio comprueba permisos, consulta el estado del cliente y decide qué acciones están habilitadas.
El modelo generativo, si hace falta, redacta una respuesta usando la información validada.
Por ejemplo, detectar un posible cobro duplicado puede activar una consulta al sistema de pagos. La devolución dependerá de esa verificación y de las reglas de autorización de la empresa.
Esta separación permite cambiar el clasificador sin reescribir todo el proceso. También facilita investigar si un error vino de la interpretación del mensaje, de un dato incorrecto o de una regla mal configurada.
Jev, Kev y Laya: por dónde empezar
Las tres alternativas permiten explorar decisiones estructuradas, con distintos compromisos.
| Modelo | Modalidad | Qué conviene evaluar primero |
|---|---|---|
| Jev | Servicio propietario de TypeSafe, en acceso anticipado | Calidad en la tarea, latencia de red y condiciones de uso de la API |
| Kev | Familia abierta basada en Qwen; licencia Apache 2.0 | Tamaño del modelo, memoria disponible y desempeño con preguntas nuevas |
| Laya | Modelos abiertos con licencia Apache 2.0; variantes en inglés y multilingüe | Elección del checkpoint y mejora al ajustarlo al dominio |
Fuentes: documentación de TypeSafe y repositorios de Kev y Laya.[1][2][3]
Jev permite probar la idea mediante un servicio gestionado. Kev y Laya permiten ejecutar los modelos en infraestructura propia, a cambio de hacerse cargo del despliegue y la operación.
El alojamiento propio evita depender de una API externa para cada inferencia, pero sigue teniendo costos de hardware, mantenimiento y monitoreo.
¿Hace falta fine-tuning?
Esta es una de las preguntas más importantes antes de elegir.
Que un modelo acepte preguntas en lenguaje natural no garantiza que interprete bien las categorías particulares de una empresa. “Incidente crítico”, “cliente prioritario” o “documentación suficiente” necesitan definiciones que el modelo pueda aplicar.
Conviene distinguir tres intervenciones:
- Mejorar el contexto: describir las opciones, aclarar reglas y aportar los datos relevantes.
- Calibrar: ajustar cómo se interpretan las probabilidades usando ejemplos etiquetados.
- Hacer fine-tuning: modificar parámetros del modelo para adaptarlo a la tarea.
No tienen el mismo costo ni resuelven el mismo problema. Calibrar puede mejorar la utilidad de una probabilidad, pero no sustituye la capacidad de distinguir categorías.
Qué pasa con Laya
Laya muestra una dependencia fuerte del checkpoint en algunas evaluaciones. Su repositorio reporta un 36,2% de acierto para el modelo base en inglés en typed-decisions, frente a un 76,6% para la variante ajustada a esos workflows.[3]
Esto ayuda a entender por qué una primera prueba puede resultar decepcionante y mejorar mucho con entrenamiento específico. Tampoco significa que toda tarea con Laya requiera ajuste: hay que evaluar el checkpoint adecuado sobre el problema real.
Qué pasa con Kev
Kev publica modelos ya entrenados para decisiones. Se pueden probar con preguntas y opciones propias sin realizar primero un ajuste adicional.
En su evaluación de desarrollo sobre fuentes nuevas, el proyecto reporta un 64,8% de acierto para Kev-0.8B y un 81,7% para Kev-4B. Jev obtiene un 85,7% en ese mismo conjunto.[2]
Estos resultados sugieren que el tamaño puede marcar una diferencia relevante al salir de las tareas conocidas. Son mediciones del proyecto y no permiten anticipar el resultado en una empresa concreta. Tampoco se pueden comparar directamente con los porcentajes de Laya: provienen de evaluaciones distintas.
Para una primera prueba, tiene sentido evaluar un modelo publicado antes de invertir en entrenamiento. Si el error persiste con opciones bien definidas y contexto suficiente, el fine-tuning pasa a ser una alternativa concreta.
Una probabilidad alta también puede estar equivocada
Recibir una respuesta con una probabilidad de 0,95 puede dar una sensación de seguridad difícil de justificar.
Una probabilidad bien calibrada debería corresponderse con la frecuencia observada de aciertos en casos comparables. Pero esa relación puede cambiar cuando cambian el idioma, el dominio o la distribución de los datos. El propio repositorio de Laya advierte que sus checkpoints salen sobreconfiados y recomienda calibrarlos antes de usar sus probabilidades.[3]
Además, devolver siempre una opción válida solo garantiza que la respuesta pertenece al conjunto permitido. La opción elegida puede ser incorrecta.
Un estudio independiente sobre Laya y Jev encontró diferencias importantes al evaluarlos con entradas idénticas: Jev fue más preciso en nueve de once tareas, mientras que Laya cambió el 30% de sus respuestas al invertir el orden de las opciones. Es evidencia sobre las versiones y tareas estudiadas, no un ranking permanente.[4]
Por eso, un umbral como “automatizar si la probabilidad supera 0,90” debe validarse. El valor apropiado depende del error que el proceso pueda tolerar.
Cómo probarlos en un caso real
Una evaluación inicial puede organizarse en cinco pasos.
1. Elegir una decisión acotada
Por ejemplo, asignar tickets a cuatro equipos. Es una tarea fácil de describir y permite revisar los errores sin construir primero toda la automatización.
2. Preparar ejemplos representativos
Reunir casos reales y acordar sus respuestas correctas con quienes conocen el proceso. Incluir mensajes ambiguos, información incompleta, categorías parecidas y el idioma que se utilizará en producción.
También conviene reservar casos que no se usarán para ajustar instrucciones, umbrales ni parámetros.
3. Comparar contra una referencia sencilla
Medir el modelo frente a la solución actual, unas reglas básicas o un LLM con salida estructurada. Una arquitectura nueva tiene que justificar su complejidad con mejoras observables.
4. Medir la automatización completa
Además del porcentaje de aciertos, registrar:
- Errores por categoría y su impacto.
- Proporción de casos que puede resolverse automáticamente al nivel de error aceptado.
- Latencia mediana y del percentil 95.
- Costo total por caso procesado.
- Comportamiento ante cambios en el orden de las opciones y falta de información.
Un modelo rápido puede aportar poco si obliga a revisar manualmente casi todas sus respuestas.
5. Incorporar una salida para los casos dudosos
El proceso necesita poder escalar a una persona, pedir más datos o usar otro modelo. Esa ruta debe existir aunque el modelo entregue probabilidades altas: la evaluación puede revelar errores que su confianza no detecta.
Dónde aportan valor
Los modelos de decisión resultan especialmente interesantes cuando una aplicación repite una evaluación bien definida sobre información variable: clasificar reclamos, priorizar documentos o determinar si una solicitud tiene datos suficientes.
Su incorporación puede ser gradual. Primero se ejecutan en paralelo con el proceso actual, después se automatizan los casos que cumplen los criterios de calidad y se amplía el alcance con evidencia.
La pregunta útil para empezar es concreta:
¿Qué decisión repetimos todos los días y cómo sabremos si un modelo la está resolviendo bien?
Responderla permite elegir entre un servicio como Jev, un modelo abierto como Kev o Laya, o una solución más simple. También define qué datos hacen falta y cuándo vale la pena entrenar.
Una buena primera implementación puede ser pequeña: una decisión, opciones claras, una evaluación reproducible y una ruta para los casos que necesitan atención adicional.
Información técnica revisada al 23 de octubre de 2026. Los resultados citados pertenecen a versiones y evaluaciones específicas; deben comprobarse nuevamente al seleccionar una versión para producción.