System One Models y Jev: por qué usar un LLM para tomar decisiones en código es un error de diseño
Generar texto token a token para clasificar, enrutar o validar estados en software empresarial es lento y caro. Analizamos cómo los modelos System One como Jev de TypeSafe AI complementan a los LLMs tradicionales.
Durante los últimos tres años, la industria del software ha cometido un error conceptual recurrente: tratar a los modelos de lenguaje generativos (LLMs) como si fueran oráculos universales para cualquier tarea automatizada.
Cuando necesitas redactar un correo persuasivo, resumir una conversación larga o sintetizar un informe complejo, la generación secuencial de texto token a token tiene todo el sentido del mundo. Pero cuando tu pipeline de backend necesita responder preguntas operativas como:
- “¿Este siniestro supera los 3.000 euros de daño estimado?”
- “¿A qué departamento técnico debemos asignar este ticket urgente?”
- “¿El albarán adjunto coincide con la orden de compra aprobada?”
- “¿Este usuario muestra un riesgo anómalo de abandono de cuenta?”
Usar un LLM tradicional (GPT-4, Claude 3.5 Sonnet, etc.) para resolver esa decisión es el equivalente técnico a contratar a un novelista para que pulse un interruptor de encendido y apagado.
El problema de la generación secuencial en código
Los LLMs autoregresivos funcionan generando un token detrás de otro, calculando probabilidades condicionadas al contexto anterior. Este mecanismo introduce tres fricciones críticas cuando se integra en software de producción:
- Latencia inaceptable para procesos en caliente: una llamada a un LLM frontera tarda habitualmente entre 3 y 15 segundos en devolver una respuesta completa. Si tu flujo de automatización tiene cinco bifurcaciones condicionales sucesivas, el proceso tarda un minuto en completarse.
- Coste desproporcionado en tokens de salida: los tokens generados suelen costar entre 3 y 5 veces más que los tokens de entrada. Pagar por la generación de párrafos explicativos cuando tu backend solo necesita un booleano o un enum tipado es un desperdicio financiero continuado.
- Fragilidad de tipos y alucinaciones: aunque uses JSON mode o function calling, el modelo sigue operando sobre cadenas de texto. Siempre existe un porcentaje de ejecuciones donde el parseador falla, se devuelven campos nulos o el modelo inventa claves inexistentes.
Qué aporta un System One Model como Jev
El investigador Diogo Almeida (ex-OpenAI, parte del equipo de investigación original de ChatGPT) fundó TypeSafe AI precisamente para resolver este cuello de botella con una categoría distinta de modelos: los System One Models.
Inspirados en la distinción psicológica de Daniel Kahneman entre el Sistema 1 (pensamiento rápido, intuitivo y automático) y el Sistema 2 (pensamiento deliberativo y lento), TypeSafe AI presentó Jev.
La premisa técnica de Jev es radical: renuncia por completo a la generación libre de texto (strings) a cambio de superpoderes que el software empresarial necesita con urgencia:
- Muestreo en paralelo en lugar de secuencial: Jev no genera texto token por token. Evalúa todas las preguntas y condiciones tipadas en una única pasada en paralelo sobre el estado del programa.
- Latencia de 70 a 500 milisegundos: entre 40 y 200 veces más rápido que un LLM tradicional para el mismo nivel de capacidad lógica.
- Tipado estricto garantizado por diseño: las salidas no son cadenas de texto parseadas con expresiones regulares o esquemas frágiles, sino tipos probables nativos definidos previamente. Es matemáticamente imposible que devuelva un fallo de tipo o invente una estructura no autorizada.
- Coste de salida prácticamente nulo: mientras que los tokens de entrada rondan los 0,042 dólares por millón (frente a los 2-10 dólares de modelos frontera tradicionales), los tokens de salida no se facturan porque el coste computacional de emitir el valor tipado es despreciable.
- Probabilidades epistémicamente calibradas: cada respuesta viene acompañada de un nivel de certidumbre real. Si el modelo no está seguro (por ejemplo, ante ambigüedad en un documento), entrega una probabilidad baja y consistente, permitiendo que tu código derive el caso a revisión humana automáticamente.
La arquitectura complementaria: Jev + LLM en producción
Jev no viene a reemplazar a los LLMs, sino a complementarlos dentro de una arquitectura híbrida inteligente.
En los sistemas de automatización de operaciones que construimos para empresas, la separación de responsabilidades queda definida de forma limpia:
[Datos de Entrada: Emails, PDFs, Transcripciones, Webhooks]
│
▼
┌───────────────────────────┐
│ Capa de Decisión │
│ (Jev / System One) │
│ │
│ - Clasificación y triage │
│ - Extracción tipada │
│ - Evaluación de riesgos │
│ - Latencia: ~120ms │
│ - Coste: Fracción de céntimo
└─────────────┬─────────────┘
│
┌───────────────┴───────────────┐
▼ ▼
[Caso Rutinario] [Caso Complejo]
│ │
Ejecución directa en Llamada a LLM Generativo
base de datos / ERP (System Two / Claude / GPT)
(Sin coste de IA generativa) para redactar respuesta a medida
Casos de uso inmediatos donde el ahorro es masivo
- Enrutamiento inteligente de incidencias y soporte: clasificar 50.000 tickets mensuales por categoría, urgencia y sentimiento cuesta decenas de miles de dólares con LLMs frontera. Con un modelo System One, esa misma clasificación se resuelve en menos de un segundo por ticket y con un coste residual de céntimos.
- Validación documental y conciliación de facturas: comprobar si los datos extraídos de un albarán cuadran con las líneas de una orden de compra es un problema de verificación relacional y lógica condicional, no de creatividad literaria.
- Guardrails y supervisión de seguridad: antes de enviar un prompt a un modelo grande o antes de entregar su respuesta al usuario final, un modelo System One puede validar cumplimiento de políticas internas, detectar inyecciones de prompt o comprobar coherencia en milisegundos sin ralentizar la interfaz.
Conclusión práctica
Si tu empresa está utilizando llamadas a APIs de LLMs como si fueran instrucciones condicionales if/else en su código, estás pagando un sobrecoste financiero innecesario y degradando la experiencia de usuario por latencia acumulada.
El futuro de la automatización empresarial no pasa por hacer los LLMs más charlatanes, sino por separar la generación de contenido (Sistema 2) de la toma rápida de decisiones tipadas (Sistema 1). Diseñar esta arquitectura desde el inicio es la diferencia entre un prototipo costoso y un sistema rentable y escalable en producción.
Artículos Relacionados
Laya en CPU, sin GPU: lo que medí en tres máquinas antes de ponerlo en producción
38 ms era con GPU. En CPU, de 94 a 848 ms según la máquina. Benchmarks reales, la trampa de los hilos, ONNX frente a PyTorch y cómo quedó el despliegue en un VPS.
Arquitectura Hexagonal y DDD en Laravel: Desacoplando el Dominio de Eloquent con DTOs y Repositorios
Cómo estructurar aplicaciones complejas en Laravel sin que Eloquent contamine la lógica de negocio: Puertos y Adaptadores, Value Objects inmutables con PHP 8.2 y separación estricta de capas.
¿Necesitas diseñar sistemas resistentes sin sobrecostes de infraestructura?
Hablemos 15 minutos en una sesión de diagnóstico técnico con Pablo para auditar tus cuellos de botella y definir la arquitectura adecuada.