El paso más frágil de un agente es interpretar lo que el modelo escribió

Tengo un agente de WhatsApp que califica leads. Le llega un mensaje y tiene que decidir dos cosas: si el lead sirve, y si la conversación necesita que entre una persona. Son dos decisiones binarias. Sin embargo, la forma de obtenerlas hoy es pedirle a un modelo de lenguaje que escriba una frase y después convertir esa frase en un booleano.

Ese paso intermedio es el que se rompe. No el modelo: el paso.

Si el modelo responde CALIFICA: sí el código funciona. Si un día responde Sí, este lead califica o Calificado o Creo que sí, aunque habría que confirmar el presupuesto, el código ya no funciona, o peor, funciona mal en silencio. Y el modelo tiene permiso para responder cualquiera de las cuatro, porque lo que se le pidió fue que escribiera.

Lo que es ese paso, dibujado

Qué devuelve un modelo que no escribe

Esta semana TypeSafe AI publicó Jev, que va justamente por ahí. Lo resumen en tres palabras en su portada: «decisions, not strings» (typesafe.ai). No genera texto, devuelve decisiones tipadas sobre opciones que tú declaras antes.

Su documentación define tres primitivas, y conviene usar sus nombres porque son los de la API (docs.typesafe.ai):

Dos detalles de esa tabla que no son adorno. El primero es que Choice y Score devuelven el reparto completo, no solo la ganadora: puedes ver si la segunda opción venía pisándole los talones, que es justo cuando conviene que mire una persona. El segundo es que las tres se pueden mezclar en una sola llamada a la API, así que calificar y decidir el escalado no son dos viajes.

Lo interesante no es que sea más rápido. Es que el contrato cambia de lado. Con un modelo de lenguaje, el contrato es una promesa: «responde solo sí o no», y confías. Con una decisión tipada, el contrato es el tipo, y el modelo no tiene forma de salirse aunque quiera.

Eso convierte un problema de fiabilidad en un problema de calibración, que es mucho mejor sitio donde estar. Un 0.62 te dice que el modelo duda, y puedes escalar a una persona. Una frase que empieza con «creo que» también te lo dice, pero solo si escribiste la expresión regular que lo detecte.

La parte que me interesa más que el modelo

Su documentación insiste en un principio de diseño que vale con Jev y sin Jev: «atomic questions, composed in code». En vez de un prompt que pregunta cinco cosas a la vez y devuelve un párrafo que hay que desmenuzar, se hacen cinco preguntas pequeñas, cada una con su tipo, y la lógica que las combina vive en tu código, no dentro del modelo.

En mi agente eso cambia esto:

antes   "analiza este mensaje y dime si el lead califica,
         qué urgencia tiene y si hay que escalar a un humano"
        -> un párrafo del que extraer tres cosas

después  Noul   "el mensaje declara un presupuesto"
         Score  "urgencia del 1 al 5"
         Choice "producto: A, B, C o ninguno"
        -> tres valores, y la decisión la toma un if

La ventaja no es la velocidad, es que cada pregunta se puede probar por separado. Cuando el agente se equivoca hoy, tengo que leer el párrafo para adivinar en qué se equivocó. Con tres respuestas tipadas sé cuál de las tres falló, y puedo medirla contra casos reales sin tocar las otras dos.

Y es un razonamiento que me resulta familiar, porque es el mismo que aplico al levantar un proceso: el problema nunca es la pregunta grande, es que nadie la había partido en las pequeñas que sí tienen respuesta.

Lo que cambiaría en mi agente, y lo que no

Mi agente toma dos decisiones tipadas y una que no lo es.

Esta es la parte que me parece que se va a malinterpretar cuando el tema se ponga de moda. Un modelo que no escribe no sustituye al que escribe: sustituye a las partes de tu sistema donde estabas usando uno que escribe para obtener algo que no era texto. En mi agente eso son dos de tres pasos, y el tercero sigue necesitando un modelo de lenguaje entero.

Dicho de otro modo: no es un modelo más barato, es una pieza distinta. Y si el reparto en tu sistema se parece al mío, la mayor parte de las llamadas que haces hoy no necesitaban una frase.

Lo que no voy a afirmar

No he integrado Jev. Esto es la lectura de un cambio de enfoque sobre un sistema que sí tengo funcionando, y hasta ahí llega.

Sobre las cifras, conviene mirar de dónde salen. TypeSafe publica en su portada «193.6x Faster, 444.6x Cheaper», y debajo el detalle del que sale esa cuenta: 0,114 segundos frente a 8,566, y 42 dólares por cada mil millones de tokens de entrada (typesafe.ai).

Son cifras del fabricante sobre una tarea que eligió el fabricante. No digo que sean falsas, digo que un 193,6 con un decimal invita a creer que es una constante, y es un cociente entre dos medidas concretas. El número que yo querría antes de mover nada no es ese: es cuánto tarda en mi caso, que tiene mensajes de WhatsApp en español chileno con faltas de ortografía y nombres de producto que no salen en ningún corpus.

Lo que mediría antes de mover nada en producción son tres cosas, y ninguna es la latencia:

Esa tercera es la que más me interesa, porque es la misma que aparece cada vez que llevo un proceso de papel a un sistema. Siempre hay un caso que la operación resuelve hablando y que el formulario no contempla. Un modelo que solo puede contestar entre las opciones que le diste hereda exactamente ese problema, y la solución probablemente sea la misma de siempre: una salida explícita para «esto no es ninguna de las anteriores», y alguien mirándola.