Cómo evaluar agentes de IA
Respuesta corta: la evaluación es un conjunto fijo de casos reales con resultado esperado, que corres contra el agente en cada cambio. Sin evals, cada mejora es una corazonada; con evals, sabes si tu agente mejoró, empeoró o solo cambió de forma de fallar. Es la diferencia entre operar un sistema y alimentar una demo.
Tu primer set, hoy
- Diez a veinte casos reales: solicitudes tal como llegan de verdad — con errores de dedo, datos faltantes y mal humor incluido.
- Resultado esperado por caso: no la respuesta literal, sino lo verificable: “aparta la pieza y confirma”, “responde que no hay existencias y ofrece aviso”.
- Los fracasos históricos: aquellos casos donde el proceso manual ya se rompía. Si tu set no incluye los modos de falla conocidos, está midiendo el día soleado.
- Un caso imposible: algo fuera del alcance del agente, para verificar que escala a un humano en lugar de inventar.
Las métricas que importan
- Tasa de éxito por caso — la métrica madre.
- Costo por tarea — un agente exitoso que cuesta más de lo que aporta no es exitoso.
- Pasos y reintentos — si crecen, algo se degradó aunque el éxito se mantenga.
- Tasa de escalación — cuánto baja a humanos; esperada baja, alarmante si es cero (nadie escala nunca) o altísima.
Evals antes de construir
Ya escribiste la primera versión sin saberlo: el ejercicio de la introducción (objetivo, datos, acción final, cuándo preguntar a un humano, tres fracasos) es un set de evaluación en borrador. Escríbelo antes del código y el agente nace con su prueba de entrada lista.
Regresión: la disciplina que salva
Cada vez que cambias modelo, prompt o herramienta, corres el set completo y comparas. El error clásico del campo: “mejoré el prompt y ahora contesta más bonito” — y también dejó de apartar existencias en dos casos que nadie revisó. Bonito no es verificado; el set es el juez.
Preguntas frecuentes
- ¿Cuántos casos de prueba necesito?
- Para empezar, entre diez y veinte casos reales — incluyendo los tres en los que el proceso solía fallar, del ejercicio de la introducción. No buscas exhaustividad estadística: buscas detectar el daño típico antes de que lo vea un cliente. El set crece con cada incidente real.
- ¿Puedo usar un LLM como juez de mis agentes?
- Con cautela y solo para lo verificable: el juez modelo sirve para revisar formato, completitud o adherencia a reglas claras con rúbrica explícita. Para resultados de negocio, mejor verificación determinista (¿agendó la cita? ¿el pedido existe?) o humana en la muestra. Un modelo juzgando sin rúbrica mide gusto, no calidad.
- ¿Cuándo se evalúa: antes o después de construir?
- Antes. Los casos escritos primero definen qué significa «bien hecho» y se convierten en la prueba de entrada del agente; después, cada cambio de modelo, prompt o herramienta se mide contra el mismo set para saber si mejoraste o rompiste algo. Evaluar solo al final es demo, no ingeniería.
Siguiente paso de la ruta
Un agente evaluado necesita límites que no dependan de la buena suerte: seguridad y guardrails. Próximamente en la ruta.