En los capítulos anteriores hemos diseñado agentes que tienen herramientas, usan memoria y reparten el trabajo entre varios. Aquí hay un muro con el que chocan muchos desarrolladores: «Lo he construido, sí, pero no sé si de verdad funciona bien». Como los agentes actúan de forma probabilística, con la misma instrucción no se comportan cada vez exactamente igual. Por eso, precisamente, «un mecanismo para medir (evaluación)» y «un mecanismo para visibilizar (observabilidad)» son la línea de vida para meterlos en producción. En este capítulo construimos el cimiento para captar la calidad en cifras, reproducir los fallos y seguir girando la mejora.
La meta es «mejorar el agente con cifras medidas, no a ojo»
Por qué la evaluación es lo más importante
Un programa normal, con la misma entrada, devuelve el mismo resultado. Pero en el centro del agente está el LLM, y su salida es probabilística. Con la misma instrucción, la herramienta que elige, los pasos y la formulación cambian ligeramente cada vez. Es decir, que haya funcionado bien una vez no garantiza en absoluto que vaya a funcionar bien la siguiente.
Aquí hay una trampa propia del desarrollo de agentes. Que en la demo funcionara de maravilla pero se rompa en cuanto un usuario real lo pide de forma algo distinta no es nada raro. La causa es simple: «funcionó» no siempre significa «es correcto». Quizá solo tocó acertar por casualidad, y puede que se equivoque 3 de cada 10 veces. Para saberlo, no queda más que contar.
💡 Lo que no se puede medir no se puede mejorar. «Me da la sensación de que ha mejorado» no es mejorar. Si cambiaste el prompt, ¿la tasa de éxito subió o bajó? Si añadiste una herramienta, ¿no se ha vuelto más lento y caro de la cuenta? Solo cuando puedes comparar con cifras puedes juzgar si un cambio es un avance o un retroceso. La evaluación no es «los deberes de después de construir», sino el cimiento del desarrollo.
Otra cosa importante es no dejar la evaluación para después. No hace falta una base de evaluación perfecta desde el principio. Pero si avanzas con «primero construyo y, cuando funcione, pienso en la evaluación», casi siempre la evaluación no se construye nunca. Aunque sea pequeña, empezar a medir justo después de crear el primer agente es, aunque parezca un rodeo, el camino más corto. Como panorama de la evaluación, la Guía práctica de evaluación de agentes de IA y, para saber qué es en sí, Qué es la evaluación de agentes (evals) son las puertas de entrada.
Qué se evalúa: el resultado y la trayectoria
Al oír «evaluar», mucha gente piensa solo en si la respuesta final es correcta. Eso es, desde luego, el punto de partida, pero en los agentes no basta con eso, porque «qué hizo por el camino» importa muchísimo. Aunque llegue a la respuesta correcta, si invocó 10 herramientas inútiles y malgastó tiempo y coste, en la práctica no sirve. Y al revés, a veces la respuesta erró por poco, pero las decisiones intermedias fueron correctas.
Por eso dividimos el objeto de la evaluación en 4 aspectos. Teniendo estos 4 en la cabeza, se disipa la duda de «no sé qué medir».
¿Logró el objetivo dado? ¿La respuesta es exacta y cumple los requisitos? El indicador más básico.
Qué herramientas invocó, en qué orden y por qué. ¿El proceso es razonable? ¿No hay rodeos ni pasos innecesarios?
¿Invocó la herramienta correcta con los argumentos correctos? ¿No invocó herramientas inexistentes ni dejó pasar fallos?
Los tokens consumidos, el precio y el tiempo empleado en una ejecución. ¿Está equilibrado con la calidad?
📊 Medir la «trayectoria» es el meollo de la evaluación de agentes. Mientras que la evaluación de una salida de IA normal es «corregir la respuesta», la de agentes mira «la respuesta + el proceso que lleva a ella». Un agente con un proceso sucio se rompe con facilidad en cuanto cambian un poco las condiciones. Al revés, uno con un proceso con lógica se recupera aunque se desvíe algo. Precisamente por mirar el proceso encuentras las pistas para mejorar.
Los 5 métodos de evaluación
«Entonces, ¿cómo se mide?»: aquí está el centro de la práctica. Hay varios tipos de método de evaluación y cada uno tiene fortalezas y debilidades distintas. Lo habitual no es fiarse de uno solo, sino combinarlos según el objeto que quieras medir. Veamos los 5 más representativos con sus pros y sus contras.
Comparas la salida del agente con una «respuesta correcta» preparada de antemano y mides la coincidencia. Va bien para tareas de respuesta única, como clasificar, extraer o calcular.
Pro: claro, fácil de automatizar y sin oscilaciones.
Contra: poco útil para texto libre «cuya respuesta no es única».
Juzgas de forma mecánica con condiciones fijas: «¿contiene los términos obligatorios?», «¿tiene formato JSON válido?», «¿no hay palabras prohibidas?».
Pro: rápido y barato, fuerte para comprobar formato y condiciones de seguridad.
Contra: no mide una calidad ambigua como «¿el sentido encaja?».
Le das a otro LLM un criterio de puntuación y le haces evaluar si la salida es buena o mala. Puede medir tareas cuya respuesta no es única, como la calidad de un resumen o la amabilidad de una respuesta.
Pro: evalúa de forma automática y masiva texto libre y calidad subjetiva.
Contra: el propio evaluador oscila o se sesga. Requiere explicitar el criterio y una comprobación manual por muestreo.
Reúnes tareas representativas en un conjunto de pruebas y las corres todas en cada cambio. Un mecanismo que protege «que lo que pasaba hasta ayer no se haya roto con el arreglo de hoy».
Pro: detecta pronto el deterioro por cambios (regresiones).
Contra: preparar y mantener el conjunto de pruebas da trabajo.
Tras publicar, observas de forma continua las ejecuciones de usuarios reales. Reúnes la evolución de la tasa de éxito, el coste y la latencia, y la valoración del usuario (👍/👎) para seguir el rendimiento real.
Pro: descubre problemas que solo salen en el entorno real y usos imprevistos.
Contra: es a posteriori. El problema solo se sabe «después de que ocurra». Presupone combinarlo con evaluación previa.
⚠️ Combinar es la base. El formato y las condiciones de seguridad, con reglas; lo que tiene respuesta única, con cotejo con la verdad; el texto libre, con LLM-as-judge; en cada cambio, con pruebas de regresión; y tras publicar, con monitorización en producción. No intentes cubrirlo todo con un solo método. Si cribas la mayor parte con los métodos baratos y rápidos (①②) y reservas el caro (③) solo para lo necesario, mantienes la precisión conteniendo el coste. Para más detalle, consulta Qué es la evaluación de LLM.
Cómo crear los datos de evaluación (conjunto de pruebas)
Sea cual sea el método, el cimiento es el «material de qué medir» = los datos de evaluación (conjunto de pruebas). Esto es, en esencia, una colección de tareas representativas del tipo «ante esta entrada, quiero que el resultado sea este». Si esto es pobre, ningún método de evaluación, por espléndido que sea, es fiable. Y al revés: con un buen conjunto de pruebas, el 80 % de la evaluación está prácticamente logrado.
La forma de crearlo es sencilla y avanza en este orden. En vez de aspirar a la perfección, la regla de oro es empezar pequeño y hacerlo crecer.
Reúne peticiones que de verdad podrían hacerle al agente, incluyendo casos típicos, límite y propensos al fallo.
Escribe el «quiero que sea así» de cada tarea. Puede ser la respuesta correcta, las condiciones a cumplir o el criterio de puntuación.
Al principio, 10-20 casos bastan. Prioriza la «calidad» que refleja la realidad del terreno, no la cantidad.
Añade al conjunto los fallos hallados en producción. Se vuelve un activo que se hace más listo cuanto más lo usas.
✅ No subestimes «solo 10 casos». Quizá sientas que «con tan pocas muestras no tiene sentido». Pero 10 casos elegidos con cuidado son mucho más útiles que 1000 reunidos sin criterio. Hazte primero medibles 10 casos representativos de lo que de verdad te da problemas. Solo con eso ya puedes juzgar al momento si un cambio de prompt o de herramienta va en buena o mala dirección. El conjunto de pruebas no se crea una vez y se acabó: es un activo vivo que crece añadiendo un caso cada vez que encuentras un fallo.
Observabilidad: visibilizar el comportamiento
Si la evaluación es «medir lo bueno y lo malo», la observabilidad es «poder rastrear por qué acabó así». Aunque la evaluación te diga «la tasa de éxito ha bajado», si no puedes ver qué ocurría dentro, no hay forma de arreglarlo. Como el agente gira por dentro varios pasos, visto desde fuera tiende a ser una caja negra: «metí una entrada, pasó algo y salió un resultado». Abrir esa caja y dejar ver su interior es la observabilidad.
Los elementos que sostienen la observabilidad son, a grandes rasgos, 3.
El registro de principio a fin de una ejecución. Permite seguir entero, en orden cronológico, el flujo de «entrada → pensamiento → invocación de herramienta → resultado → siguiente decisión».
En cada paso, qué prompt envió, con qué argumentos invocó la herramienta y qué devolvió. El consumo de tokens y el tiempo empleado también quedan aquí.
Poder volver a recorrer una ejecución problemática con la misma entrada y el mismo estado. Solo cuando puedes reproducirlo puedes identificar la causa y verificar el arreglo.
Puedes ir escribiendo todo esto a mano en registros, pero en la práctica lo habitual es usar una herramienta de trazado (tracing). La herramienta de trazado captura de forma automática cada paso del agente y lo visualiza de forma legible como un árbol cronológico. «En qué paso se tardó», «dónde falló la invocación de una herramienta», «en qué decisión se desvió hacia un rumbo extraño» quedan claros de un vistazo.
📊 La traza es «el ojo de la depuración». En el ejemplo de arriba, en ④ falla la invocación de la herramienta y en ⑤ el propio agente se recupera. Si miras solo el resultado, es «éxito», pero si miras la traza ves la debilidad de que «se equivoca con facilidad en el número de columna». Esa toma de conciencia lleva a la siguiente mejora. El enfoque de la observabilidad se explica de forma sistemática en Qué es la observabilidad de la IA.
Girar el bucle de mejora
Las herramientas vistas hasta aquí —evaluación y conjunto de pruebas, y observabilidad— son útiles por sí solas, pero su verdadero valor sale cuando las giras como un único bucle. El desarrollo de agentes no es «lo construyo una vez y está terminado», sino la labor de mejorarlo poco a poco en el ciclo medir, hallar la debilidad, arreglar y volver a medir.
Corre la evaluación contra el conjunto de pruebas y saca en cifras la tasa de éxito, el coste y la latencia.
Lee la traza de las ejecuciones que fallaron y averigua dónde y por qué se equivocó.
Cambia una sola cosa que ataque la causa: prompt, descripción de herramienta, procedimiento, reparto…
Reevalúa con el mismo conjunto y confirma si salió la mejora buscada y si no ha empeorado otra cosa.
En este bucle hay un truco importante: cambia lo menos posible de una vez, idealmente una sola cosa. Si cambias a la vez prompt, herramienta y procedimiento, aunque suba la tasa de éxito no sabrás «qué cambio surtió efecto». Precisamente por cambiar de uno en uno y medir, se enlaza la causa entre el cambio y el resultado, y el conocimiento se va acumulando. Es discreto, pero esta es la frontera que separa la «mejora a ojo» de la «mejora segura».
✅ Gira el bucle rápido y pequeño. En vez de acertar una gran reforma de golpe, girar cambios pequeños muchas veces y rápido mejora antes al final. Con 10 casos en el conjunto, cambias y mides al instante. Cuando interiorizas este ritmo de «cambiar → medir al momento», el desarrollo de agentes deja de ser adivinar a ojo y se convierte en un trabajo de ingeniería que avanza con paso firme.
- El agente es probabilístico y «funcionó» no siempre es «correcto». Si no mides, no puedes mejorar.
- El objeto de evaluación tiene 4 aspectos: resultado final, trayectoria, invocaciones de herramientas y coste/latencia. La «trayectoria», en especial, es el meollo.
- Los métodos son 5: cotejo con la verdad, reglas, LLM-as-judge, pruebas de regresión y monitorización en producción, combinados según el objeto.
- Los datos de evaluación, tareas representativas empezando por pocas. 10 cuidados vencen a 1000 sin criterio. Se hacen crecer añadiendo fallos.
- La observabilidad es traza de ejecución, registro de cada paso y reproducción del fallo. Con una herramienta de trazado, visibiliza el comportamiento.
- La mejora es el bucle medir → hallar la debilidad → arreglar → volver a medir. Cambia de uno en uno, pequeño y rápido.
Cuando ya puedas medir la calidad y ver el comportamiento, lo siguiente es «cómo evitar descontroles, errores y usos malintencionados». La autonomía que aumentaste en el capítulo 4, «Diseño multiagente», aprendamos a manejarla con seguridad. Pasamos al siguiente capítulo 6, «Guardarraíles y seguridad».