Cambias una frase en las instrucciones del agente para que deje de ofrecer cupones a quien no los pide. Funciona. Y, sin que nadie lo note, también deja de ofrecérselos a quien tenía derecho a uno según tu política. Te enteras dos semanas después, por una queja.
Un agente de IA no se rompe como un programa normal. No da un error: sigue contestando, con buena redacción, otra cosa. Por eso no se puede probar mirándolo un rato. Hace falta una batería de casos que se vuelve a pasar cada vez que algo cambia. Eso son los evals, y en un agente que actúa sobre tus sistemas se diseñan distinto que en un chatbot.
Por qué no basta con evaluar la respuesta
Para un chatbot, el resultado es el texto: se evalúa si la respuesta es correcta, completa y educada. Para un agente, el texto es lo último que produce. Antes ha consultado sistemas, ha decidido con tus reglas y, a veces, ha cambiado algo. Una respuesta impecable encima de una acción equivocada es el peor resultado posible, porque no hay nada en el texto que lo delate.
En un agente que actúa, la respuesta es la parte menos interesante de lo que hay que probar.
Qué lleva un caso
En Qopper un caso es pequeño a propósito. Tiene un mensaje del cliente y cuatro comprobaciones, todas opcionales salvo el mensaje:
- Qué acciones tiene que usarPor ejemplo, consultar el pedido. Se exige que aparezcan, en cualquier orden, y se le permite usar otras además: lo que importa es que no se salte la consulta, no que siga un guion.
- Qué tiene que decirFragmentos de texto que deben aparecer en la respuesta, como el plazo de devolución que figura en tu política.
- Qué no puede decirLo que nunca debe salir: una cifra que no está en tu política, una promesa que no puedes cumplir, un cupón que no existe.
- Cómo tiene que terminarLa conversación abierta, resuelta o pasada a una persona. Un caso fuera de política que el agente “resuelve” por su cuenta es un fallo aunque el cliente quede encantado.
Por qué no lo juzga otro modelo
Lo habitual es pedirle a un segundo modelo que puntúe la respuesta del primero. Es cómodo y tiene un problema de fondo: el juez también es probabilístico. El mismo caso puede aprobar hoy y suspender mañana sin que el agente haya cambiado, y entonces ya no sabes si se rompió el agente o el juez.
Nosotros juzgamos cada caso con reglas fijas: si aparecieron las acciones esperadas, si el texto incluye lo que debe y no incluye lo que no debe, y si el estado final es el esperado. Las comparaciones de texto no distinguen mayúsculas. Es más tosco que un juez con criterio, y lo sabemos. A cambio, la misma respuesta siempre recibe el mismo veredicto: si un caso pasa de verde a rojo, cambió lo que hizo el agente, no el criterio con el que se le mide.
Una prueba que a veces falla sin motivo no es una prueba. Es ruido con forma de alarma.
Probar acciones sin tocar a ningún cliente
Aquí está la parte que no existe cuando se evalúa un chatbot. Si un caso pide un reembolso, el agente tiene que poder decidir hacerlo, porque eso es lo que se está probando. Y ningún cliente puede recibir un reembolso de prueba.
- 1Las escrituras se validan pero no se ejecutan. Cancelar, reembolsar o crear una devolución pasan por todas las comprobaciones de una acción real y se detienen justo antes de llamar al sistema. El agente recibe “validado, no ejecutado”.
- 2Las reglas se evalúan igual. Si un reembolso llega al tope que fijaste, la prueba refleja que quedaría esperando aprobación. Pero no se crea ninguna solicitud ni se avisa a nadie del equipo.
- 3Las consultas son reales. Leer un pedido o un cobro va a tus sistemas de verdad. Es deliberado: un caso que consulta datos inventados sólo comprueba que el agente lee bien datos inventados.
- 4Se prueba el borrador. Siempre la versión que todavía no has publicado. La que atiende a tus clientes no se toca.
Que las consultas sean reales tiene un precio, y conviene saberlo: si el pedido que usa un caso cambia de estado, el caso puede cambiar de resultado. Por eso los casos de consulta conviene apuntarlos a datos que no se mueven, como un pedido antiguo ya entregado.
La prueba de honestidad
Hay un fallo que ninguna de las comprobaciones anteriores ve: el agente dice “ya está hecho” y no hizo nada. Un modelo que ha leído miles de conversaciones de soporte sabe que eso es lo que se contesta al final. Así que a cada caso se le añade una comprobación que nadie tiene que escribir.
Si la respuesta afirma que algo ya ocurrió (“ya te he devuelto”, “he cancelado tu pedido”, y sus equivalentes en inglés) y en ese turno no se ejecutó ninguna acción de escritura, el caso falla. Las promesas en futuro no cuentan: “te lo devuelvo ahora” es otra cosa y a veces es lo correcto.
En producción la misma idea va más lejos: una escritura sólo cuenta como comprobada si, después de hacerla, se volvió a leer el sistema y el cambio estaba allí. Sin esa segunda lectura, el agente no puede decirle al cliente que está hecho.
Lo que importa es lo que cambió
Un “38 de 40 casos aprobados” dice poco. Lo que necesitas saber es si los dos que fallan son los mismos de la semana pasada o dos que acabas de romper. Por eso cada ejecución se compara con la anterior y cada caso sale con una de cuatro etiquetas:
- RotoAntes pasaba y ahora no. Es lo primero que hay que mirar.
- ArregladoAntes fallaba y ahora pasa.
- IgualNo cambió, pase o falle.
- NuevoNo estaba en la ejecución anterior. Nunca cuenta como arreglado, aunque pase: un caso que acabas de escribir para que apruebe no arregla nada.
Publicar pasa por la batería
Si los evals son opcionales, se dejan de pasar la semana que hay prisa, que es justo la semana en que se rompen cosas. Por eso publicar un agente ejecuta primero todos sus casos contra el borrador. Si falla uno solo, el borrador no se publica y el agente que atiende a tus clientes sigue como estaba. No hay botón para publicar igualmente.
Un agente sin ningún caso sí se puede publicar, y queda marcado como no probado. Bloquearlo sería castigar a quien empieza; ocultarlo sería mentir.
Por dónde empezar
La batería vacía es la razón número uno por la que nadie escribe evals. Para no empezar de cero, Qopper propone cuatro casos a partir de la descripción de tu negocio: una consulta, una petición dentro de tu política, una fuera de ella y una pregunta de conocimiento.
El reparto de trabajo es deliberado. El modelo sólo escribe las palabras: el mensaje del cliente y lo que debería y no debería decir la respuesta. Las comprobaciones las decide el código. Sólo el caso de consulta exige una acción, la primera de lectura que tengas activada, y ninguno exige una escritura: qué se puede hacer sin preguntar es una decisión tuya, no algo que deba inventar un modelo.
Lo que todavía no hace
Hoy cada caso es un único mensaje: todavía no se pueden probar conversaciones de varios turnos, donde vive una parte importante de los fallos. Cada caso se ejecuta una vez, sin repeticiones para detectar resultados que cambian solos. Y las comprobaciones de texto buscan fragmentos literales, así que una respuesta correcta dicha con otras palabras puede fallar. Son los tres siguientes pasos, y los contamos aquí porque una batería sólo sirve si sabes lo que no cubre.
Cómo escribir buenos casos
- Sácalos de conversaciones realesLas que salieron mal valen el doble. Cada queja es un caso que todavía no tienes.
- Uno por cada borde de tu políticaJusto por debajo del tope, justo en el tope, por encima. Los fallos viven en los bordes, no en el medio.
- Prueba el noLo que el agente no debe hacer importa tanto como lo que sí. Un caso que pide algo prohibido y espera un traspaso a una persona.
- Prueba la insistenciaEl cliente que pide lo mismo por tercera vez con otras palabras. Ahí se ve si las reglas viven en el código o en una frase de las instrucciones.
- Pocos y buenosVeinte casos que cubren tus decisiones importantes valen más que doscientos que preguntan el horario de diez maneras.
Un agente que actúa en tus sistemas es software, y el software que no se prueba se rompe en producción. La diferencia es que este, cuando se rompe, no da un error: te lo cuenta un cliente.
