Contenido
Después de construir un agente de IA, siempre te topas con el mismo muro: "Vale, pero ¿de verdad funciona?". Cambiaste el prompt, sustituiste el modelo, añadiste una herramienta, y el mecanismo para decidir si eso lo hizo mejor o peor con datos en lugar de intuición son las evals (evaluaciones).
Un LLM puede producir una salida distinta cada vez para la misma entrada (es probabilístico). Por eso, lanzar a producción con un "parece que funciona" lleva a regresiones silenciosas y fallos en casos límite. Este artículo explica qué son las evals, cinco formas de medir la calidad, la evaluación específica de agentes y cómo empezar en pequeño, escrito para quienes lo llevan a la práctica.
La conclusión, en 30 segundos
Si solo lees una cosa
1. Por qué necesitas evals
El software corriente es determinista: misma entrada, misma salida. Por eso funciona una prueba unitaria que comprueba "¿coincide la salida con el valor esperado?". Pero un LLM es probabilístico: incluso la misma pregunta vuelve redactada o planteada de forma algo distinta cada vez. En los términos de agentes de IA frente a RPA, no es una "mano" determinista sino un "cerebro" probabilístico, así que las pruebas de coincidencia exacta no sirven tal cual.
Aquí suelen aparecer tres modos de fallo.
Pruebas un par de ejemplos a mano y decides que "parece mejor". Nunca te enteras de que otro caso se rompió.
Cambias un prompt o un modelo y solo un tipo de entrada empeora. Te enteras por una queja en producción.
"A veces devuelve algo raro". Como es probabilístico, un solo intento no lo reproduce, así que no puedes rastrear la causa.
Las evals previenen las tres a la vez. Prepara un conjunto de datos de evaluación, puntúa todo el conjunto en cada cambio y compara las puntuaciones: eso, por sí solo, convierte la "intuición" en "datos" y hace visibles las regresiones. Cuanto más juicio delegues en un agente, más se vuelven las evals el cimiento de la calidad, junto con las guardrails.
2. Qué son las evals
Evals (evaluaciones) = medir si la salida de una IA o el comportamiento de un agente funciona de forma correcta y estable, como se espera. En términos humanos, es calificar. Los bloques que la componen son simples y se dividen en tres partes.
El conjunto de entradas sobre el que evalúas. Reúne ejemplos de uso real, registros pasados y los casos límite esperados.
Cómo conviertes la salida en una puntuación: coincidencia exacta, comprobaciones por reglas o calificación por otra IA.
Puntúa todo el conjunto y compara antes y después de un cambio para decidir si mejora o empeora.
Las evals no son "constrúyelas una vez y listo": la esencia es ejecutarlas como una prueba de regresión cada vez que cambias un prompt, un modelo o una herramienta. Como el código de pruebas, son un activo que haces crecer.
3. Cinco formas de medir la calidad
Hay cinco enfoques representativos de puntuación. La regla general es elegir según la naturaleza de la tarea y combinar varios.
Prepara la salida esperada (etiqueta de oro) para cada entrada y puntúa por la tasa de coincidencia. Ideal para tareas con una respuesta fija: clasificación, extracción, sí/no.
Comprueba mecánicamente regex, coincidencia exacta, validez del JSON, presencia de las claves obligatorias. Potente para verificar "debe devolver siempre este formato": rápido y barato.
Haz que otro LLM califique según una rúbrica. Para tareas donde la respuesta no es única: calidad del resumen, tono, relevancia.
Compara las puntuaciones sobre el mismo conjunto de datos antes y después de un cambio de prompt o modelo. Detecta una "regresión oculta" donde el conjunto sube pero una parte baja.
Puntúa y observa de forma continua los registros en vivo. Vigila la tasa de fallos, el coste, la latencia y la deriva de las entradas para detectar la degradación a tiempo.
| Método | Encaja en | Coste | Objetividad |
|---|---|---|---|
| ① Verdad de referencia | Clasificación, extracción, decisiones | Bajo | ◎ Alta |
| ② Por reglas | Comprobaciones de formato / estructura | Bajo | ◎ Alta |
| ③ LLM-as-judge | Resumen, generación, calidad del diálogo | Medio | ○ Depende de la rúbrica |
| ④ Regresión | Detectar regresiones por cambios | Medio | ◎ Relativa |
| ⑤ Monitorización en producción | Detectar degradación en vivo | Medio-Alto | ○ Continua |
La clave está en las capas: "mide mecánicamente lo que puedas (① ②), usa LLM-as-judge para la calidad que no puedas (③) y sigue ejecutándolo mediante regresión y producción (④ ⑤)". LLM-as-judge (③) es cómodo, pero el propio LLM que juzga varía, así que redacta la rúbrica de forma explícita y, cuando sea posible, calíbrala contra calificaciones humanas.
4. Evaluación específica de agentes
Para una única respuesta (una entrada → una salida), los cinco métodos anteriores bastan. Pero un agente de IA da varios pasos, llama a herramientas por sí mismo y toma decisiones por el camino. Por eso debes evaluar no solo la salida final, sino el proceso.
¿Logró el objetivo al final (p. ej., reservó la cita correcta)? La métrica principal del agente.
¿Llamó a la herramienta adecuada, con los argumentos correctos y en el orden correcto? Detecta llamadas erróneas o redundantes.
¿Es razonable el recorrido de pasos y decisiones? Evalúa rodeos, bucles infinitos y reintentos innecesarios.
Para el mismo éxito, menos tokens, pasos y menos latencia es mejor. Importa en producción.
Observar esto exige trazado (tracing) que registre cada paso (entrada, razonamiento, llamada a herramienta, resultado). Muchos frameworks y las herramientas de abajo incluyen trazado y evaluación juntos. Para una configuración multiagente, mantén trazas jerárquicas para poder identificar qué agente falló.
5. Cómo empezar: construye en pequeño
No necesitas una plataforma de evals perfecta desde el primer día. Empezar con un conjunto de datos de 20 casos es realista.
- Recopila ejemplos de fallo: primero, 10-20 "entradas que salieron mal". Los registros reales y las quejas son una mina de oro: este es el núcleo del conjunto de eval.
- Escribe el comportamiento esperado: adjunta una "respuesta correcta" o "condiciones que cumplir" a cada entrada. No todo necesita una respuesta estricta (mide la calidad con ③).
- Elige un puntuador: comprobaciones de formato → ② por reglas; respuesta fija → ① verdad de referencia; calidad → ③ LLM-as-judge. Basta con uno o dos para empezar.
- Ejecuta una vez y fija una línea base: registra la puntuación actual. Ese es tu punto de referencia.
- Ejecútalo en cada cambio: tras un cambio de prompt o modelo, vuelve a ejecutar y compara con ④ regresión. Si baja, no lo lances.
- Añade observación en producción: una vez en vivo, sigue vigilando la tasa de fallos y el coste con ⑤ monitorización, y realimenta el conjunto de eval con los ejemplos reales malos.
💡 Consejo: sesga tu conjunto de eval hacia "los fallos que no quieres que ocurran" en lugar de "los éxitos habituales". Incluir casos límite, entradas adversarias y peticiones vagas te permite protegerte de forma proactiva frente a lo que se rompe con cada cambio. Una buena rúbrica, como un buen diseño de prompts, se vuelve más reproducible cuanto más concreta es.
6. Errores habituales
- Conjunto de datos demasiado pequeño / demasiado sesgado: recopilar solo éxitos pasa por alto los fallos del mundo real. Mezcla deliberadamente fallos y casos límite.
- Confiar ciegamente en LLM-as-judge: el LLM que juzga también varía y tiene sesgos. Redacta la rúbrica de forma explícita y calíbrala periódicamente contra calificaciones humanas. Cuidado con el autobombo (el mismo modelo escribe y alaba su propia salida).
- Mirar solo la salida final: en los agentes, el proceso lo es todo. Sin llamadas a herramientas, trayectoria y coste, bendecirás un resultado "que tuvo suerte".
- Decidir con una sola ejecución: como es probabilístico, para las evals importantes ejecuta varias veces y observa la varianza.
- No actualizar las evals: las especificaciones y el uso cambian. Sigue añadiendo nuevos fallos de producción al conjunto de eval.
7. Herramientas clave
Puedes empezar con tus propios scripts, pero hay un conjunto creciente de herramientas dedicadas que manejan trazado y evaluación juntos. Ejemplos representativos (todos sitios oficiales).
| Herramienta | Qué hace |
|---|---|
| Anthropic Console / Evals | Probar y evaluar prompts para Claude en una interfaz. También para comparar opciones de modelo. |
| OpenAI Evals | Un framework OSS para definir y ejecutar evals. La forma básica de conjunto de datos + puntuador. |
| LangSmith | Trazado + evaluación. Registra cada paso del agente, desde la regresión hasta la monitorización en producción. |
| Langfuse | Observabilidad de LLM OSS. Trazado, evaluación y monitorización de coste juntos. |
| Ragas | Evaluación especializada en RAG (generación aumentada por recuperación): relevancia, fidelidad y más. |
Uses la que uses, la esencia es la misma: un conjunto de datos + un puntuador + la disciplina de comparar. Las herramientas solo lo facilitan. El mejor comienzo es un pequeño conjunto de eval, aunque sea en un script en tu propia máquina.
Resumen
- Qué son las evals: "calificar" que mide la salida y el comportamiento de la IA con números, decidiendo mejor/peor con datos y no con intuición.
- Por qué las necesitas: los LLM son probabilísticos y varían, así que las pruebas unitarias no encajan y las regresiones y los casos límite se cuelan.
- Cinco métodos: ① verdad de referencia ② por reglas ③ LLM-as-judge ④ regresión ⑤ monitorización en producción. Mide mecánicamente lo que puedas, juzga la calidad con un LLM y sigue ejecutándolo.
- Los agentes también necesitan evaluación del proceso: tasa de éxito de la tarea, llamadas a herramientas, trayectoria, coste. El trazado es el requisito previo.
- Cómo empezar: 20 ejemplos de fallo. Fija su línea base y luego ejecútalo en cada cambio.
Entre "lo construí" y "es utilizable" hay un puente llamado evals. Si las guardrails son la defensa que frena el comportamiento descontrolado, las evals son el ataque que mide la calidad y la sigue elevando. Un único y pequeño conjunto de eval convierte el desarrollo de agentes de "intuición" en ingeniería.
FAQ
P. ¿En qué se diferencian las evals de las pruebas unitarias normales?
Las pruebas unitarias comprueban "¿coincide la salida exactamente con el valor esperado?". Pero un LLM es probabilístico y produce una salida distinta cada vez, así que la coincidencia exacta no sirve tal cual. Las evals se diferencian al combinar mediciones adecuadas a la salida probabilística —comprobaciones por reglas, calificación por un LLM y observación de la varianza en varias ejecuciones— además de la coincidencia con la verdad de referencia.
P. ¿Puedo fiarme de LLM-as-judge (dejar que una IA califique)?
Es cómodo, pero no es una bala de plata. El LLM que juzga puede variar y tener sesgos. Lo importante es redactar una rúbrica concreta, calibrar contra calificaciones humanas periódicamente y separar los roles/modelos de generación y calificación para evitar el autobombo. La comparación relativa (cuál de A o B es mejor) tiende a ser más estable que las puntuaciones absolutas.
P. ¿Cuántos casos de eval necesito?
Puedes empezar bien con 10-20. Aun con unos pocos ayudan en la comparación relativa de "¿subió o bajó la puntuación tras un cambio?". De forma realista, hazlo crecer añadiendo los fallos encontrados en producción. Más importante que la cantidad es incluir correctamente fallos, excepciones y casos límite.
P. ¿De verdad necesito evaluar la "trayectoria" de un agente?
Si lo ejecutas en producción, sí. Incluso cuando la salida final es correcta, los rodeos, las llamadas innecesarias a herramientas y los bucles infinitos perjudican el coste y la fiabilidad. Añade trazado que registre cada paso y mira el proceso junto con la tasa de éxito de la tarea. Cuanto más implique el caso de uso permisos y efectos secundarios —como los casos de uso de automatización empresarial o la automatización de operaciones en la nube—, más compensa la evaluación del proceso.
