Cómo evaluar un agente de IA: benchmarks y pruebas propias

Evaluar un agente de IA consiste en comprobar que realmente completa una tarea, de forma constante, y no solo que produce una respuesta convincente. Los benchmarks públicos ofrecen una primera referencia, pero la decisión se toma con sus propias pruebas, construidas a partir de sus casos de uso.

Por qué un agente no se evalúa como un chatbot

Un benchmark clásico plantea una pregunta y compara la respuesta con una solución. Un agente de IA, en cambio, encadena acciones: busca información, llama a herramientas, modifica un archivo, envía un mensaje. La evaluación de agentes debe fijarse, por tanto, en varias cosas a la vez:

• el resultado: ¿el estado final es el correcto (incidencia cerrada, factura creada, prueba superada)?
• el camino: ¿usó el agente las herramientas adecuadas, sin rodeos costosos ni acciones arriesgadas?
• la constancia: ¿acierta siempre o solo de vez en cuando?
• el coste y la duración: ¿cuántos tokens y minutos necesitó?

Dos agentes pueden llegar al mismo resultado por caminos muy distintos, y un mismo agente puede acertar y luego fallar en una tarea idéntica. Por eso el ejercicio es más exigente que corregir un cuestionario.

Lo que dicen (y lo que no) los benchmarks públicos

Los benchmarks públicos funcionan como un lenguaje común. Los más citados para agentes:

• SWE-bench, creado en Princeton en octubre de 2023, pide corregir problemas reales de proyectos Python de código abierto; su versión Verified reúne 500 tareas revisadas por personas.
• Terminal-Bench, lanzado el 19 de mayo de 2025 por Stanford y el Laude Institute, evalúa el trabajo en línea de comandos; su versión 2.0 es de noviembre de 2025.
• GPQA mide el razonamiento científico de alto nivel, útil para juzgar el «cerebro» del modelo más que el agente completo.

Nuestra clasificación de modelos agrega pruebas de este tipo. A 22 de octubre de 2026, el índice publicado por Epoch AI es la media de siete pruebas, entre ellas SWE-bench y Terminal-Bench. Esta es la parte alta de la tabla:

Puesto	Modelo	Organización	Índice
1	Claude Sonnet 5.5	Anthropic	95,9
2	Claude Opus 5.5	Anthropic	95,9
3	Gemini 4 Argon	Google DeepMind	95,3
4	GPT-6 Astra	OpenAI	94,7
5	Claude Opus 5	Anthropic	92,7

Y la distancia entre algunos modelos destacados en ese mismo índice:

Índice de capacidad (sobre 100)

• Claude Sonnet 5.595,9
• Gemini 4 Argon95,3
• GPT-6 Astra94,7
• Claude Haiku 5.584
• GPT-6 Luna80,3

Los cinco primeros caben en algo más de tres puntos. A ese nivel, la diferencia depende menos del modelo que de lo que usted construye a su alrededor: el prompt, las herramientas, la memoria, las salvaguardas. Nuestra metodología explica cómo se recogen y muestran estas puntuaciones.

Conviene recordar tres límites. Un benchmark mide una situación precisa, a menudo programación. Sus tareas pueden haberse filtrado en los datos de entrenamiento. Y la puntuación depende tanto del entorno de ejecución como del modelo: dos equipos que prueban el mismo modelo con herramientas distintas no obtienen la misma cifra.

Crear sus propias pruebas: el vocabulario útil

En su guía «Demystifying evals for AI agents», publicada el 9 de enero de 2026 y consultada el 22 de octubre de 2026, Anthropic propone un vocabulario que se ha vuelto habitual:

• Tarea: una prueba con entradas y un criterio de éxito.
• Intento: una ejecución. Se lanzan varios por tarea, porque los resultados varían de una vez a otra.
• Evaluador: la lógica que puntúa un aspecto del trabajo. Una tarea puede tener varios.
• Transcripción: el registro completo de un intento, con las llamadas a herramientas y los pasos intermedios.
• Resultado: el estado final del entorno al terminar el intento.

La misma guía distingue dos medidas. La primera es la probabilidad de acertar al menos una vez en varios intentos, que sube al multiplicar las ejecuciones. La segunda es la probabilidad de acertar en todos los intentos, que en cambio baja. La primera indica lo que el agente sabe hacer; la segunda, lo que puede confiarle sin supervisión.

Método en cinco pasos

1. Parta de fallos reales. La guía de Anthropic considera que entre 20 y 50 tareas sencillas sacadas de fallos reales son un excelente comienzo. Reúna lo que ya comprueba a mano y lo que señalan los usuarios.

2. Escriba un criterio de éxito sin ambigüedad. Una buena prueba es aquella en la que dos expertos que leen el mismo resultado estarían de acuerdo. «La respuesta es útil» no basta; «el reembolso queda registrado por el importe correcto y el cliente recibe un mensaje de confirmación» sí funciona.

3. Equilibre los casos. Añada tareas en las que el agente deba negarse, pedir una aclaración o pasar el caso a una persona. Si no, acabará optimizando un agente que siempre actúa, incluso cuando no debería.

4. Separe dos familias de pruebas. Las pruebas de capacidad apuntan a lo que el agente aún no hace bien: un porcentaje de éxito bajo al principio es normal. Las pruebas de no regresión comprueban que sigue haciendo lo que ya sabía: deben mantenerse cerca del 100 %.

5. Repita en cada cambio. Nuevo prompt, nueva herramienta, nuevo modelo: todo pasa por la batería de pruebas. El trabajo sobre las instrucciones, explicado en nuestra guía de prompt engineering, se vuelve entonces medible en lugar de depender de impresiones.

Elegir los evaluadores

La guía de Anthropic describe tres tipos de evaluadores, que conviene combinar en lugar de enfrentar:

Evaluador	Puntos fuertes	Puntos débiles	Ejemplo de uso
Código	Rápido, barato, objetivo, reproducible	Rígido ante una solución válida pero inesperada	Comprobar que un archivo existe o que una prueba pasa
Modelo	Flexible, maneja respuestas abiertas y matices	No determinista, costoso, hay que calibrarlo	Juzgar el tono o la exhaustividad de una respuesta
Persona	Referencia de calidad, criterio experto	Lento y caro a gran escala	Revisar una muestra, calibrar el modelo evaluador

El evaluador basado en un modelo tiene nombre: el LLM como juez. El artículo fundacional de Zheng y sus coautores (junio de 2023) informa de más de un 80 % de acuerdo entre GPT-4 y las preferencias humanas, pero también describe sesgos: preferir la primera respuesta, la más larga o la de su propio modelo. De ahí tres costumbres: invertir el orden de las respuestas comparadas, pedir una justificación antes de la nota y contrastar con regularidad al juez con una muestra puntuada por personas.

Póngase a prueba Su agente redacta respuestas a clientes y actualiza su ficha en un CRM. ¿Qué evaluador usaría para cada parte?

Un script para la actualización del CRM, porque el estado final se comprueba de forma objetiva (¿el campo correcto tiene el valor correcto?). Un modelo evaluador, calibrado con notas humanas, para la calidad y el tono del mensaje. Y una revisión humana de una muestra a intervalos regulares.

Leer las transcripciones, no solo la puntuación

Una puntuación global oculta lo esencial. Cuando una tarea falla, la transcripción indica si el agente se equivocó de verdad o si fue su evaluador quien rechazó una solución válida. Anthropic cuenta en la misma guía que una puntuación en el benchmark CORE-Bench pasó del 42 % al 95 % una vez corregidos defectos de la propia evaluación, no del modelo.

La lección vale también para sus pruebas: un aumento repentino de fallos merece una lectura de las trazas antes de sacar conclusiones. Los errores típicos de un evaluador son un formato demasiado estricto, una solución de referencia equivocada o un entorno que no se reinicia bien entre intentos.

Probar la seguridad y el criterio

Una evaluación seria no mide solo los aciertos. También busca lo que puede salir mal. El red teaming consiste en atacar al agente a propósito: documentos trampa, peticiones ambiguas, intentos de que revele datos. Añada tareas en las que lo correcto sea detenerse y recurrir a un humano en el circuito antes de una acción irreversible. Nuestra guía sobre la seguridad de los agentes de IA detalla estos escenarios.

Herramientas: del framework a la producción

No hace falta programarlo todo. Varios frameworks incluyen piezas de evaluación: Pydantic AI incorpora Pydantic Evals para puntuar respuestas y secuencias de llamadas a herramientas, y Google ADK ofrece un marco de evaluación con simulación de usuario y métricas personalizadas. Nuestro comparativo de frameworks de agentes le ayuda a elegir.

En producción toma el relevo la observabilidad de los LLM: cada llamada queda trazada (modelo, tokens consumidos, herramientas usadas, duración), lo que permite detectar desviaciones y convertir los fallos reales en nuevas tareas de prueba. Las convenciones de OpenTelemetry para la IA generativa, con atributos como gen_ai.request.model o gen_ai.usage.input_tokens, buscan estandarizar esas trazas.

Para situar la evaluación en el conjunto del proyecto, desde la definición de la tarea hasta el despliegue, consulte nuestra guía para crear un agente de IA.