Evaluar un agente antes de que lo usen tus clientes

Un agente de IA casi siempre sale bien en la demo. Las preguntas son las previstas, la persona que lo prueba sabe cómo hablarle y nadie intenta confundirlo. Los problemas aparecen después, con clientes que preguntan otra cosa, se equivocan, cambian de idea o escriben con prisa.

Los números de la investigación son poco tranquilizadores. En τ-bench, una prueba que simula conversaciones de atención al cliente con herramientas y normas reales, los mejores agentes de 2024 completaban menos de la mitad de las tareas. Y cuando se repetía la misma tarea ocho veces, en el caso de la tienda en línea, menos de una de cada cuatro salía bien las ocho (Yao et al., 2024). Los modelos han mejorado desde entonces, pero la lección sigue en pie: un agente que acierta una vez no tiene por qué acertar siempre.

Estos son los pasos que seguimos para evaluar un asistente o un agente antes de que llegue a los clientes.

1. Define qué es hacerlo bien

Parece obvio y casi nunca está escrito. Para cada tarea importante: qué tiene que conseguir, qué normas tiene que respetar, qué datos puede usar, qué tono debe tener y cuándo tiene que pasar la conversación a una persona. Sin eso, cada revisor juzga con su propio criterio y los resultados no se pueden comparar.

2. Reúne conversaciones de prueba realistas

La base de todo es un conjunto de conversaciones con las que probar cada versión. Las mejores salen de conversaciones reales, anonimizadas: correos, chats y llamadas del servicio de atención al cliente. Hay que completarlas con lo que más falla:

Peticiones ambiguas o incompletas.
Personas que se corrigen o cambian de idea a mitad de camino.
Preguntas que el agente no debería responder.
Datos con formatos raros: fechas, direcciones, números de pedido.
Casos en los que la respuesta correcta es derivar a una persona.

También se puede usar un modelo de lenguaje que haga de cliente y genere muchas variaciones, como hace τ-bench. Sirve para ampliar, pero no sustituye a las conversaciones reales.

3. Repite cada prueba varias veces

Un modelo de lenguaje no responde siempre igual. Una prueba que sale bien una vez puede fallar a la segunda. Por eso cada conversación importante se ejecuta varias veces y se mide cuántas salen bien todas, no solo si alguna sale bien. La medida que propone τ-bench, que exige acertar en todos los intentos, es un buen ejemplo.

4. Automatiza lo que se pueda comprobar con reglas

Muchas cosas se comprueban sin juicio humano: si la respuesta tiene el formato correcto, si deja ver datos que no debería, si supera la longitud máxima, si llamó a la herramienta adecuada, si la reserva quedó bien guardada en el sistema. Hamel Husain, que ha ayudado a muchos equipos a evaluar productos con IA, recomienda empezar por estas comprobaciones sencillas y baratas, y ejecutarlas con cada cambio (Husain, 2024).

5. Usa un modelo como juez, y vigílalo

Para lo que no se puede comprobar con reglas, como la utilidad o el tono, se puede pedir a otro modelo de lenguaje que valore la respuesta siguiendo una rúbrica. Su fiabilidad varía según el criterio, así que conviene validarlo con juicios humanos y mitigar sus sesgos. Siempre que la corrección pueda verificarse (por ejemplo, contra una base de datos), es preferible comprobarla directamente o dar al juez acceso a esa información.

Un estudio de 2023 encontró que GPT-4 como juez coincidía con las valoraciones humanas en más del 80 % de los casos, lo mismo que coinciden dos personas entre sí. También identificó sus sesgos: prefiere la primera respuesta que lee, las respuestas largas y las que se parecen a las suyas (Zheng et al., 2023). Que funcione en un estudio no garantiza que funcione en tu producto: antes de fiarte de un modelo como juez (LLM-as-a-judge), comprueba que sirve para tu caso de uso y tu dominio.

La forma más fiable de usarlo es calibrarlo: que varias personas del equipo valoren una muestra, comparar con lo que dice el juez y ajustar los criterios hasta que su acuerdo con las personas se acerque al que hay entre ellas. Después, conviene confirmarlo con otra muestra distinta y volver a comprobarlo cada vez que cambie el modelo o el tipo de conversaciones.

6. Si responde con tus documentos, mide dos cosas por separado

Cuando un asistente responde consultando tu documentación (lo que se conoce como RAG, generación aumentada por recuperación), puede fallar en dos fases. Al buscar, puede no traer los fragmentos adecuados o traerlos mezclados con mucho texto que no viene a cuento. Al responder, puede afirmar algo que no aparece en lo que ha encontrado o irse por las ramas. Conviene evaluar cada fase por separado, porque se arreglan de forma distinta: en un caso hay que mejorar el buscador y en el otro, las instrucciones o el modelo que redacta.

Ragas, un marco de evaluación para este tipo de sistemas, propone tres métricas (Es et al., 2023). La primera mide si el contexto recuperado está centrado en lo que se pregunta. La segunda, si la respuesta es fiel a ese contexto, es decir, si cada afirmación se apoya en él. La tercera, si la respuesta aborda realmente la pregunta. Su atractivo es que no necesitan respuestas de referencia escritas a mano, porque es otro modelo de lenguaje el que hace de evaluador.

Eso sí, conviene conocer sus límites. Una respuesta fiel no es necesariamente correcta: si el documento recuperado está desactualizado, el asistente puede repetir el error con total fidelidad. Estas métricas tampoco detectan bien que falte el fragmento clave, porque para eso hay que saber de antemano qué debería haberse encontrado. Y como el juez es un modelo de lenguaje, sus valoraciones no son infalibles.

7. Intenta romperlo

Alguien va a intentar que el agente diga lo que no debe, revele sus instrucciones o haga algo para lo que no tiene permiso. La inyección de instrucciones encabeza la lista de riesgos de OWASP para aplicaciones con modelos de lenguaje (OWASP, 2025). Antes del lanzamiento, dedica tiempo a atacarlo a propósito. Es lo que se conoce como red teaming: un equipo se pone en el lugar de quien ataca para encontrar los fallos antes que nadie. Se puede hacer con personas y también con modelos de lenguaje que generan ataques de forma automática, una variante que propusieron investigadores de DeepMind en 2022 (Perez et al., 2022).

8. Prueba con personas

Ninguna prueba automática sustituye a ver a personas reales usando el asistente. Salen peticiones que nadie había previsto, formas de hablar distintas y momentos de confusión que no aparecen en los datos. Si el asistente es de voz, además, hay que probarlo con ruido, con distintos acentos y con personas que hacen pausas, como contamos en por qué no me entiende mi asistente de voz y en cuándo me toca hablar.

9. Sigue midiendo después del lanzamiento

La evaluación no termina con el lanzamiento. Revisa conversaciones reales cada semana, mira dónde se deriva a una persona y por qué, y añade los fallos nuevos al conjunto de pruebas. Y cada vez que cambies de modelo, aunque sea a una versión nueva del mismo proveedor, vuelve a pasar todas las pruebas: el comportamiento puede cambiar sin que nadie lo avise.

Lista de comprobación antes de lanzar

¿Está escrito qué es una buena respuesta para cada tarea?
¿Hay un conjunto de conversaciones de prueba realistas, con casos difíciles?
¿Cada prueba se repite varias veces?
¿Las comprobaciones automáticas se ejecutan con cada cambio?
¿El modelo que hace de juez está calibrado con valoraciones humanas?
¿Alguien ha intentado romperlo a propósito?
¿Lo han usado personas reales?
¿Hay un plan para seguir midiendo después?

Es lo que hacemos en nuestro servicio de evaluación de asistentes y agentes, y lo que recomendamos a cualquier equipo antes de poner un agente delante de sus clientes.

Referencias

Yao, S., Shinn, N., Razavi, P. y Narasimhan, K. (2024). τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains. arXiv.
Husain, H. (2024). Your AI Product Needs Evals.
Zheng, L., Chiang, W.-L., Sheng, Y. et al. (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. NeurIPS 2023.
Es, S., James, J., Espinosa-Anke, L. y Schockaert, S. (2023). Ragas: Automated Evaluation of Retrieval Augmented Generation. arXiv.
OWASP GenAI Security Project (2025). Top 10 for LLM Applications.
Perez, E., Huang, S., Song, F. et al. (2022). Red Teaming Language Models with Language Models. EMNLP 2022.