Índice
Afinaste tus prompts, añadiste conocimiento con RAG y quizá incluso hiciste fine-tuning: entonces, ¿cómo confirmas que "realmente mejoró"? Aquí es donde las AI evals (evaluación) toman protagonismo. Para 2026, la evaluación se ha vuelto tan esencial para construir IA que la gente la llama "infraestructura".
Este artículo explica, para principiantes, qué son las AI evals, por qué las necesitas, los dos métodos de evaluación, cómo funciona el tan comentado "LLM-as-judge" y sus trampas, y cómo aplicarlo en la práctica.
Mide con código; juzga el criterio con IA
— convierte el "parece suficientemente bueno" en un número
Define los criterios
Convierte "una buena salida" en una vara de medir concreta.
Puntúa automáticamente
Califica de forma consistente cada vez, con código o IA.
Sigue el cambio
Observa de forma continua qué mejoró o empeoró.
1. ¿Qué son las AI evals?
Las AI evals consisten en medir sistemáticamente la calidad de las salidas de un LLM. "¿Es precisa esta respuesta?", "¿Hay alucinaciones (datos inventados)?", "¿Sigue el formato requerido?", "¿Es adecuado el tono?": puntúas estos aspectos con una vara de medir fija en lugar de hacerlo a ojo en el momento.
Imagínalo como "corregir un examen". Le das al estudiante (la IA) una pregunta (la entrada) y la puntúas contra una respuesta modelo o una rúbrica. Una vez que puedes puntuar, por fin ves "qué cambio la mejoró y cuál la empeoró". Sin evals, la mejora es solo una corazonada.
💡 En una línea: evals = "un sistema que puntúa las salidas de la IA". Los ajustes de prompt y el fine-tuning solo significan algo cuando tienes una vara de medir para evaluarlos.
2. Por qué las necesitas: no publiques por intuición
Un programa corriente es fijo —"la entrada A siempre da la salida B"—, pero la IA varía incluso con la misma entrada (no es determinista), y "bueno o malo" suele ser subjetivo. Por eso, "probé unos cuantos y se veían bien, a publicar" es arriesgado. Los pocos que viste por casualidad pueden haber salido bien solo por suerte.
Sistematizar la evaluación te permite hacer esto:
- Juzgar los cambios con los números: cuando cambias un prompt o un modelo, compara por puntuación
- Detectar regresiones: ver si una "mejora" rompió otra cosa
- Vigilar la calidad en producción: notar cuándo el rendimiento de la IA decae en operación
Esto combina bien con el desarrollo guiado por especificaciones. Decide "qué construir" (la especificación) y "mide si lo construiste" (las evals): con ambos en su sitio, el desarrollo de IA por fin se vuelve algo manejable.
3. Dos métodos: código vs. LLM-as-judge
Hay, a grandes rasgos, dos formas de evaluar. Medir mecánicamente con código; dejar que una IA califique lo subjetivo: esa división es el principio básico.
Juzga mecánicamente con reglas
- Coincidencia exacta, formato requerido (JSON, etc.)
- Contiene una palabra requerida / evita una prohibida
- Rápido, barato, mismo resultado cada vez
- Ideal para ítems con una respuesta correcta clara
Haz que una IA califique a una IA
- Alucinación, relevancia, utilidad, tono
- Ítems subjetivos sin una única respuesta correcta
- Más rápido y barato que las personas, a gran escala
- Pero cuidado con sus manías (sesgos)
La regla práctica: "no hagas que una IA califique lo que puedes medir con código". La evaluación por código es más rápida, más barata y más estable. Reserva LLM-as-judge para ítems subjetivos que al código le cuesta juzgar, como si hay una alucinación.
4. Cómo funciona LLM-as-judge
LLM-as-judge significa usar un LLM potente como "árbitro" para puntuar la salida de otra IA. Le entregas al LLM juez un prompt que contiene los criterios, la entrada y la salida, y este devuelve una puntuación, un pass/fail o "cuál es mejor". Hay dos estilos principales.
Comparación pairwise (por pares)
Pon dos respuestas una al lado de la otra y pregunta "¿cuál es mejor?" La IA es buena juzgando cuál es relativamente más fuerte. Ideal para comparación A/B.
Puntuación de una sola salida
Evalúa una respuesta contra una rúbrica para darle una puntuación. Útil para seguir la calidad absoluta a lo largo del tiempo.
⚠️ Una escala gruesa es más precisa: la IA es mala con la puntuación fina de 1–10 y oscila. Una escala gruesa como "pass/fail" o "1–3" en realidad da resultados más estables.
5. La trampa: sesgos del juez
LLM-as-judge tiene sus "manías de árbitro". Si no las conoces, confiarás demasiado en las puntuaciones y harás las mejoras equivocadas. Ten presentes estas tres grandes.
① Sesgo de verbosidad
Tiende a puntuar más alto las respuestas más largas y complejas: incluso un contenido pobre gana solo por su extensión.
② Sesgo de posición
El orden en que listas las respuestas (p. ej., la que se muestra primero) crea una ventaja o una desventaja.
③ Preferencia por sí mismo
Tiende a valorar más alto las respuestas escritas por sí mismo (la misma familia de modelo).
Las contramedidas son sencillas.
- Usa un modelo distinto como calificador: no califiques salida de GPT con GPT. Que arbitre una familia diferente —Claude, Gemini, etc.— para evitar la preferencia por sí mismo.
- Intercambia el orden y califica dos veces: conserva el resultado si ambos coinciden, descártalo si se contradicen (control del sesgo de posición).
- Incluye la "concisión" en la rúbrica: solo decir "no juzgues por la longitud" no basta. Añade un criterio de concisión e instruye al juez para que penalice la verbosidad.
- Calibra contra el juicio humano: haz que una persona califique una pequeña muestra y ajusta los criterios para que coincidan con las puntuaciones de la IA. Este es el paso más eficaz.
6. En la práctica: la evaluación como "infraestructura"
En la práctica de 2026, la evaluación no es algo puntual: el estándar es ejecutarla de forma continua en tres niveles ("la evaluación como infraestructura").
① Chequeo instantáneo en cada cambio
Ejecuta evals ligeras basadas en código de forma automática en cada cambio de código (CI). Bloquea al instante las roturas evidentes.
② Pruebas de regresión nocturnas
Califica la calidad en masa durante la noche con LLM-as-judge. Detecta la degradación lenta y progresiva.
③ Monitoreo continuo en producción
Vigila las salidas en vivo y alerta cuando la calidad cae. Limita el impacto sobre los usuarios reales.
Las herramientas también han madurado. Para ejecuciones ligeras de CI, DeepEval (que se siente como pytest) o Promptfoo; para RAG en concreto, RAGAS (que mide fidelidad, relevancia y más). Para revisión humana, dashboards y monitoreo en producción, plataformas como Braintrust, LangSmith y Arize. En la práctica, combinar "una herramienta ligera de CI" con "una plataforma de monitoreo" es lo habitual. La misma maquinaria de evaluación también sostiene la calidad al construir agentes de IA.
※ Los nombres de herramientas y los métodos se citan de diversas guías y publicaciones (a junio de 2026). La mejor configuración varía según el tamaño del equipo y el caso de uso.
Resumen
Tres ideas clave sobre las AI evals.
- Qué son: un sistema que puntúa las salidas de un LLM, convirtiendo la mejora de una "corazonada" en "números". Un paso esencial en el desarrollo de IA.
- Dos métodos: evals de código para los ítems deterministas, LLM-as-judge para los subjetivos. Mide con código todo lo que el código pueda medir.
- Cuidado: LLM-as-judge tiene sesgos de verbosidad, posición y preferencia por sí mismo. Gestiónalos con un modelo calificador distinto, una escala gruesa y calibración humana.
Empieza reuniendo 10 "buenas salidas" y 10 "malas salidas" de tu propia IA y puntuándolas contra criterios sencillos. Eso se convierte en tu primera vara de medir. Lee fine-tuning e ingeniería de contexto junto con esto para tener el panorama completo de cómo mejorar la IA.
FAQ
Q. ¿De verdad se puede confiar en que una IA califique a otra IA?
A. No a ciegas. Por los sesgos de verbosidad, posición y preferencia por sí mismo, es importante calificar con una familia de modelo distinta y calibrar contra una pequeña muestra juzgada por humanos. Una vez calibrada, funciona a gran escala con una precisión casi humana.
Q. ¿Cuántos ejemplos de eval necesito?
A. Puedes empezar perfectamente con solo unas pocas decenas. El truco es reunir ejemplos reales buenos y malos y construir primero un conjunto pequeño de evals. En lugar de buscar la perfección, haz crecer los criterios sobre la marcha: es más práctico.
Q. Evals de código o LLM-as-judge, ¿cuál debería usar?
A. Ambos. Usa evals de código para lo medible mecánicamente, como el formato y las palabras requeridas; usa LLM-as-judge para cosas subjetivas como la alucinación y el tono. No hace falta que una IA califique lo que puedes medir de forma determinista.
Q. ¿Los desarrolladores en solitario necesitan evals?
A. Ayudan sin importar la escala. Incluso un pequeño "estándar de buena salida" te permite saber si un cambio de prompt o de modelo es una mejora o una regresión. Calificar un puñado a mano ya es un comienzo útil.
