¿Qué son los evals? Pruebas para saber si la IA hace bien su trabajo
Un eval es una prueba que da una entrada a un sistema de IA y califica su salida con criterios definidos. Partes, graders y cómo empezar con pocos casos.
¿Qué es un eval?
Un software tradicional responde lo mismo ante la misma entrada, así que un test compara una salida exacta. Un modelo de lenguaje puede responder de formas distintas y todas correctas. La documentación de OpenAI lo dice así: la IA generativa es variable, y por eso las pruebas de software estándar se quedan cortas. Un eval no pregunta “¿es igual a esto?”, sino “¿cumple estos criterios?”.
OpenAI define los evals como pruebas de que las salidas del modelo cumplen criterios de estilo y contenido que tú especificas. Anthropic añade para qué sirven en la práctica: hacen visibles los problemas y los cambios de comportamiento antes de que lleguen a los usuarios. Sin ellos, dice, depurar es reactivo: esperas quejas, reproduces el fallo a mano y confías en que nada más se haya roto.
¿Qué partes tiene un eval?
Anthropic describe una anatomía con estas piezas:
- Tarea: una prueba con entradas y criterios de éxito definidos.
- Intento (trial): cada ejecución de la tarea. Como las salidas varían entre corridas, se hacen varios intentos.
- Grader: la lógica que puntúa un aspecto del desempeño. Una tarea puede tener varios.
- Transcripción: el registro completo de un intento, con salidas, llamadas a herramientas y razonamiento.
- Resultado (outcome): el estado final en el entorno. Por ejemplo, si la reserva existe de verdad en la base de datos, no si el agente dijo que la hizo.
- Harness de evaluación: la infraestructura que corre los evals de principio a fin: ejecuta las tareas, registra, califica y agrega resultados.
El detalle que más se pasa por alto es el resultado. Un agente puede decir “listo” y no haber hecho nada. El eval debe mirar el estado real, no el texto de la respuesta.
¿Quién califica la salida?
Anthropic distingue tres tipos de grader, cada uno con su compromiso:
| Tipo | Ejemplos | Ventaja | Costo |
|---|---|---|---|
| Código | Coincidencia de texto, tests binarios, verificación del resultado | Rápido, barato y objetivo | Frágil; limitado en tareas subjetivas |
| Modelo | Rúbricas, comparación por pares, afirmaciones en lenguaje natural | Flexible y con matices | No determinista, más caro y hay que calibrarlo contra personas |
| Persona | Revisión de expertos, muestreo, pruebas A/B | Calidad de referencia | Caro y lento |
OpenAI propone la misma división (métricas, personas y un LLM como juez), avisa de sesgos del juez automático, como favorecer la posición o la longitud, y recomienda validarlo contra etiquetas humanas. Regla práctica: código donde el criterio sea objetivo, un modelo donde necesites matiz y personas para comprobar al juez.
¿Por qué le importa a un diseñador?
Porque los evals convierten “se siente mejor” en una decisión. Si cambias el prompt del asistente de tu producto, el eval te dice si la respuesta a una pregunta de facturación sigue correcta, si el tono se mantuvo y si el formato que espera la interfaz sigue llegando.
Además, los evals hablan el idioma del equipo. Un criterio como “si el usuario pide cancelar, el agente confirma antes de ejecutar” es una regla de diseño que se puede probar. Sin criterio escrito, la discusión termina en opiniones. Para ver dónde entra la supervisión humana, lee human-in-the-loop.
¿Cómo se empieza?
Anthropic recomienda empezar pequeño y pronto:
- Parte de lo que ya pruebas a mano y de los fallos que reportan los usuarios. Reúne de 20 a 50 casos tomados de fallos reales: quejas, respuestas que tuviste que corregir, errores de soporte.
- Escribe para cada caso el criterio de éxito de forma que dos expertos del tema lleguen de forma independiente al mismo veredicto de aprobado o reprobado.
- Incluye casos donde el comportamiento debe ocurrir y casos donde no debe. Anthropic lo ilustra con un asistente que busca en la web: hay preguntas que exigen buscar (el clima) y otras que se responden sin buscar (quién fundó Apple).
- Define cómo se califica cada caso (código, modelo o persona).
- Corre el conjunto en cada cambio y compara con la ejecución anterior. OpenAI lo llama desarrollo guiado por evals: evaluar pronto y a menudo. Anthropic ya decía en 2024 que la clave de cualquier función con LLM es medir el desempeño e iterar.
- Lee las transcripciones. Es el cierre del artículo de Anthropic, para confirmar que los graders funcionan y que los fallos son justos.
Al principio bastan muestras pequeñas, explica Anthropic: cada cambio suele tener un impacto claro y visible. Pero los evals se vuelven más difíciles de construir mientras más se espera.
Como las salidas varían, un solo intento no basta. Anthropic define pass@k como la probabilidad de acertar al menos una vez en k intentos, y pass^k como la probabilidad de que acierten los k. Su ejemplo: con 75 % de éxito por intento, la probabilidad de acertar los tres intentos es de alrededor de 42 %. Importa en agentes de cara al cliente, donde se espera un comportamiento fiable cada vez.
El flujo que documenta OpenAI es parecido: describes la tarea, defines el esquema de los datos de prueba, fijas los graders (sus “testing criteria”), corres el eval sobre un archivo JSONL y analizas los resultados para iterar el prompt.
Revisa también la herramienta que elijas. La documentación de OpenAI indica que los evals existentes de su plataforma son de solo lectura desde el 31 de octubre de 2026 y que el panel y la API están programados para cerrar el 30 de noviembre de 2026; su página de deprecaciones remite a una guía de migración a Promptfoo. Conviene que tus casos vivan en archivos propios, no solo dentro de una plataforma. Y un benchmark público de modelos (cómo leerlos) no sustituye a un eval de tu caso.
¿Cuándo NO conviene?
- Cuando no sabes qué significa “bien”. Un eval sin criterio claro solo produce números sin sentido.
- Cuando el caso es tan raro que no vale la pena medirlo. Empieza por lo que pasa a diario.
- Cuando piensas que un eval reemplaza a las personas. Anthropic coloca la revisión humana como la calidad de referencia, aunque sea cara y lenta.
Ejemplo
Ejemplo ilustrativo: tu producto tiene un asistente que responde preguntas de facturación. Recoges 30 preguntas de soporte del último mes. Para cada una escribes el criterio: “la respuesta menciona el plazo correcto y no promete reembolsos fuera de política”. Dos graders: uno de código revisa que aparezca la fecha correcta; otro, un modelo, revisa que no se prometa nada fuera de política. Corres el conjunto tres veces. Una pregunta que falla en dos de tres corridas es un problema real y no un accidente. Antes de fiarte del grader de modelo, revisas a mano diez transcripciones y compruebas que sus veredictos coinciden con los tuyos.
Errores comunes
- Medir sin criterio escrito. Los números sin definición no sirven para decidir.
- Usar un solo intento y creer el resultado. Con salidas variables, un acierto aislado no dice nada.
- Construir cientos de casos antes de correr el primero.
- Evaluar solo lo fácil y dejar fuera los casos que más duelen en soporte.
- No revisar las transcripciones y confiar en un grader que nunca contrastaste con una persona.
- Olvidar actualizar los evals cuando cambia el producto. Un eval viejo mide un producto que ya no existe.
Fuentes
- Demystifying evals for AI agents (Anthropic Engineering, 9 de enero de 2026): definición, anatomía, tipos de grader, 20 a 50 tareas, pass@k y pass^k, saturación.
- Guía de evals (OpenAI, documentación): definición de evals y pasos para crear uno.
- Buenas prácticas de evaluación (OpenAI, documentación): variabilidad de la IA generativa, desarrollo guiado por evals, tipos de grader y sesgos del juez automático.
- Deprecations (OpenAI, documentación): fechas de solo lectura (31 de octubre de 2026) y cierre (30 de noviembre de 2026) de la plataforma de Evals.
- Building effective agents (Anthropic Engineering, diciembre de 2024): medir el desempeño e iterar sobre las implementaciones.