Evaluar agentes antes de soltarlos
Respuesta rápida:
Una demo demuestra que el sistema puede funcionar. Una evaluación demuestra con qué frecuencia lo hace. Son preguntas distintas y solo la segunda sirve para decidir.
La mayoría de los agentes llegan a producción validados con un puñado de ejemplos elegidos por quien los construyó. Es comprensible y es insuficiente: esos ejemplos son justo los casos que el sistema resuelve bien, porque son los que se usaron para ajustarlo.
Qué es un conjunto de evaluación
No es una lista de preguntas. Es un conjunto de casos reales donde, para cada uno, está escrito:
- La petición, tal y como la formularía un usuario real, con su ambigüedad incluida.
- La respuesta o acción esperada, acordada con quien sabe del dominio.
- La evidencia que debería usar: qué fuente contiene la respuesta correcta.
- Qué no debe hacer: acciones prohibidas en ese contexto.
Ese último punto es el que casi nadie escribe y el que más problemas evita. Un agente que responde bien pero ejecuta una acción que no le correspondía ha fallado, aunque el texto fuera impecable.
Los casos salen del historial real: tickets, correos, consultas. Entre cincuenta y doscientos bastan para empezar, y deben incluir los casos raros, no solo los frecuentes.
Las métricas que importan
Cuatro, y ninguna es la precisión a secas:
- Acierto con evidencia correcta. No basta con que la respuesta sea buena: tiene que apoyarse en la fuente adecuada. Acertar por casualidad es un fallo que aún no se ha manifestado.
- Corrección de las acciones. Qué porcentaje de las acciones ejecutadas eran las que tocaban, y cuántas se ejecutaron sin deber.
- Coste por caso, que decide la viabilidad tanto como el acierto.
- Tasa de derivación. Cuántas veces el agente reconoce que no puede y escala. Un agente que nunca escala no es seguro, es temerario.
Simulación adversaria
Antes de dar autonomía hay que intentar romperlo a propósito:
- Inyección de instrucciones en el contenido que el agente recupera: un documento que contiene una orden disfrazada de texto.
- Datos contradictorios entre dos fuentes fiables, para ver si detecta el conflicto o elige al azar.
- Peticiones fuera de alcance, para comprobar que se niega en lugar de improvisar.
- Herramientas que fallan o devuelven basura, para ver si lo detecta o construye sobre ello.
Esto no es una auditoría de seguridad al final del proyecto: es parte del desarrollo, y conviene que lo haga alguien distinto de quien construyó el agente.
El umbral y la firma
La evaluación solo sirve si alguien escribe, antes de ejecutarla, qué resultado se considera aceptable. Por ejemplo: acierto con evidencia por encima del noventa por ciento, cero acciones indebidas, coste por caso bajo el umbral de viabilidad.
Y alguien firma. No el equipo técnico en solitario: el responsable del agente, el mismo que responde de sus acciones. Sin esa firma, la decisión de soltarlo se toma por agotamiento, que es como se toman casi todas.
Es el mismo principio que aplicamos en MVP60™: el criterio de aceptación se acuerda al principio, no se negocia al final cuando ya hay prisa.
Después del despliegue
El conjunto de evaluación no se archiva: se ejecuta periódicamente. Los modelos cambian, las fuentes cambian y los usuarios preguntan cosas nuevas. Un agente que pasaba la evaluación en marzo puede no pasarla en septiembre sin que nadie haya tocado una línea de código.
Cada incidente real se convierte además en un caso nuevo del conjunto. Así se evita el patrón que ya describimos entre los errores más comunes al implementar IA generativa: arreglar un fallo concreto y volver a romperlo tres meses después.
Cómo puede ayudar Galde
Construimos el conjunto de evaluación con el equipo de dominio del cliente, no en un laboratorio: los casos salen de su historial y los umbrales los firma su responsable. Lo dejamos automatizado para que se ejecute en cada cambio, como cualquier otra prueba de regresión. Es como trabajamos en nuestra línea de IA con Palantir AIP.
Conclusión
Dar autonomía a un agente sin evaluación es una decisión tomada sin datos, aunque se tomen muchas reuniones para adornarla. Construir el conjunto cuesta una semana bien empleada y sirve durante toda la vida del sistema.
Lo que no se puede es sustituirlo por confianza. La confianza es el resultado de la evaluación, no un sustituto.
Preguntas frecuentes
¿Qué es un conjunto de evaluación para agentes de IA?
Es una colección de casos reales con su petición, la respuesta o acción esperada, la fuente que debería usarse y las acciones prohibidas. Permite medir con qué frecuencia acierta el agente, no solo si puede acertar.
¿Cuántos casos hacen falta?
Entre cincuenta y doscientos para empezar, siempre que incluyan los casos raros y no solo los frecuentes. El valor está en la variedad, no en el volumen.
¿Qué es la simulación adversaria?
Intentar romper el agente a propósito antes de darle autonomía: inyectar instrucciones en el contenido que recupera, presentarle datos contradictorios, pedirle cosas fuera de su alcance y simular herramientas que fallan.
¿Cada cuánto hay que repetir la evaluación?
En cada cambio relevante y de forma periódica, porque los modelos y las fuentes cambian aunque el código no. Cada incidente real debería incorporarse además como caso nuevo.
