Cómo se evalúa un agente antes de confiarle la operación

El proveedor del modelo anuncia una versión nueva, más rápida y más barata. El equipo la activa un viernes en la tarde, porque el cambio parece menor. El lunes, el agente de clasificación de gastos sigue funcionando, pero empezó a mandar a la categoría equivocada un tipo de factura que antes resolvía bien. Nadie lo nota hasta el cierre de mes.

La escena es una composición y describe una regresión: un cambio que arregla algo y rompe otra cosa. Las pruebas automatizadas ayudan a detectar regresiones en software. Con los agentes se necesitan además evaluaciones, o «evals», sobre la calidad de las respuestas, la elección de herramientas y la derivación a una persona.

Por qué la demo engaña

Una demo muestra el caso que el agente resuelve bien. La operación real está hecha de casos borde: la factura con dos monedas, el pago que agrupa tres documentos, el cliente con un nombre escrito de cuatro formas. Un agente puede acertar en el noventa y tantos por ciento de los casos fáciles y fallar justo en los que más importan. La única forma de saberlo es probarlo contra los casos reales.

El conjunto de referencia

La pieza central de una evaluación es un conjunto de casos de referencia: ejemplos del proceso con resultados esperados o criterios definidos por quienes conocen el negocio. Una conciliación puede tener un calce correcto; una respuesta abierta puede admitir varias formulaciones y necesitar una rúbrica que mida exactitud, respaldo y límites. Conviene separar una muestra representativa, para estimar el rendimiento esperado, de un conjunto de estrés con más casos raros y costosos. Si se usan datos reales, hay que proteger la información personal y evitar que los casos de prueba entren en las instrucciones o el entrenamiento.

Un agente que no se mide contra casos reales no está probado. Está presentado.

Qué se mide

• Exactitud: en casos cerrados, qué proporción coincide con el resultado correcto; en los abiertos, cuánto cumple la rúbrica definida.
• Cobertura: qué parte de los casos el agente resuelve, y qué parte deriva a una persona.
• Calidad de la derivación: cuando no está seguro, ¿lo dice, o responde igual con confianza?
• Costo y tiempo por caso, para saber si la mejora compensa.
• Seguridad: si intenta acciones fuera de su alcance o expone datos que no debería.

De todas, la tercera es la que más se olvida y la que más importa. Un agente que sabe decir «no estoy seguro, revísalo» vale más que uno que acierta un poco más pero nunca duda.

Evaluar no es un evento: es un circuito

La evaluación no se hace una vez antes del lanzamiento. Se repite cada vez que algo cambia: una versión nueva del modelo, un ajuste en las instrucciones, una herramienta nueva, una regla de negocio modificada. Si el resultado empeora en un tipo de caso crítico, el cambio se revisa antes de producción. El conjunto de referencia crece con la operación: los errores detectados se convierten en casos de prueba, aunque ningún conjunto puede garantizar que no se repitan.

Parece mucho trabajo, y al principio lo es. Pero es el mismo trabajo que permite subir la autonomía de un agente con argumentos, como vimos en el episodio anterior, en lugar de hacerlo por intuición.

Las escenas de estos episodios son composiciones de situaciones frecuentes, no casos de clientes. Las cifras que aparecen en ellas son ilustrativas.