Qué son los evals y cómo diseñarlos para tu sistema de IA

Los evals (evaluaciones) son la diferencia entre un sistema de IA que parece funcionar y uno que sabes que funciona.

Sin evals, cada cambio que haces en el system prompt, el modelo o la estructura del contexto es un salto de fe. Con evals, tienes datos.

Qué son los evals exactamente

Un eval es un conjunto de casos de prueba que ejecutas contra tu sistema de IA para medir si las salidas son buenas. Cada caso incluye:

• Una entrada (prompt, documento, mensaje del usuario)
• Una salida esperada o criterio de evaluación
• Un método de puntuación (exacta, por LLM, por humano)

El objetivo es hacer que la evaluación sea reproducible, automatizable y comparable entre versiones.

Por qué son críticos

Imagina que tienes un agente de soporte al cliente. Cambias el system prompt para que sea más conciso. ¿Mejoró? ¿Empeoró? Sin evals, no lo sabes hasta que un cliente se queja.

Con evals, ejecutas 200 casos de prueba antes y después del cambio y tienes números en segundos.

Los evals te permiten:

• Detectar regresiones antes de que lleguen a producción
• Comparar modelos en tu caso de uso específico (no en benchmarks genéricos)
• Validar cambios en el contexto, el prompt o la arquitectura
• Medir mejoras de forma objetiva

Los 3 tipos de evals

1. Evals de respuesta exacta

Para casos donde la respuesta correcta es unívoca:

Entrada: "¿Cuál es la capital de Francia?"
Esperado: "París"
Puntuación: 1 si contiene "París", 0 si no

Son los más confiables pero solo aplican a un rango estrecho de tareas.

2. Evals basados en reglas

Para evaluar propiedades específicas de la respuesta:

- ¿La respuesta tiene menos de 200 palabras? ✓
- ¿Incluye un ejemplo de código? ✓
- ¿Menciona el nombre del producto? ✗

Útiles cuando sabes exactamente qué propiedades debe tener la salida.

3. Evals por LLM-as-judge

Un segundo LLM evalúa la calidad de la respuesta según criterios:

Prompt al juez: "Evalúa esta respuesta del 1 al 5 según:
- Precisión técnica
- Claridad
- Relevancia para la pregunta
Respuesta a evaluar: [...]"

Son los más flexibles pero introducen variabilidad. Funcionan mejor con criterios muy específicos y ejemplos de referencia.

Cómo estructurar un eval set

Un buen conjunto de evals tiene al menos estos componentes:

Casos positivos (happy path)

Los 20-30 casos más típicos de tu sistema. Si fallas aquí, hay un problema fundamental.

Casos límite (edge cases)

Entradas raras pero válidas:

• Preguntas muy cortas o muy largas
• Idiomas mezclados
• Temas fuera de alcance
• Preguntas ambiguas

Casos adversariales

Intentos de hacer fallar el sistema:

• Prompt injection
• Preguntas que parecen válidas pero no lo son
• Contradicciones en el contexto

Casos de regresión

Casos específicos que fallaron antes y corregiste. Siempre añade al eval set los bugs que encuentras.

Un framework mínimo para empezar

No necesitas herramientas sofisticadas para empezar. Un spreadsheet con este esquema sirve:

| id | input | contexto | salida_esperada | criterio | resultado | notas | |----|-------|----------|-----------------|----------|-----------|-------| | 001 | "¿Puedo devolver un producto?" | Policy doc v2 | Menciona 30 días | contiene "30 días" | pass | |

El proceso:

1. Recolecta 50 casos reales de uso
2. Etiquétalos manualmente (bueno / malo / parcial)
3. Automatiza los que puedas con reglas
4. Usa LLM-as-judge para el resto
5. Ejecuta antes de cada cambio importante

Cuántos evals necesitas

Para empezar: 50-100 casos cubren el 80% de los problemas reales.

Para producción seria: 200-500 casos divididos entre tipos.

Para sistemas críticos: 1000+ con evals automatizados en CI/CD.

La regla: empieza pequeño y añade casos cada vez que encuentres un fallo real.

Herramientas

• Braintrust — plataforma completa para evals y trazas
• LangSmith — integrado con LangChain, bueno para debugging
• Promptfoo — open source, fácil de integrar en CI/CD
• Código propio — para casos simples, un script de Python es suficiente

El ciclo de mejora continua

Los evals son inútiles si los ejecutas una vez. El valor está en el ciclo:

1. Ejecuta evals → encuentras fallos
2. Corriges (prompt, contexto, modelo)
3. Ejecutas evals de nuevo → confirmas mejora sin regresión
4. Añades nuevos casos basados en lo aprendido
5. Repite

Un sistema con 100 evals bien diseñados y ejecutados regularmente supera a uno con 1000 evals ejecutados una vez.

Errores frecuentes

Evals demasiado fáciles — si siempre pasas el 95%, los evals no están midiendo lo que importa.

No tener evals adversariales — los fallos de producción suelen venir de casos que no anticipaste.

Evaluar salida en lugar de comportamiento — a veces lo que importa no es el texto exacto sino si el usuario obtuvo lo que necesitaba.

No actualizar el eval set — los evals que no evolucionan dejan de reflejar cómo se usa el sistema.