La evaluación en IA es engañosamente difícil porque lo que intentas medir — "¿es buena esta salida?" — es frecuentemente subjetivo, dependiente del contexto y multidimensional. La respuesta de un modelo a "explica el entrelazamiento cuántico" podría ser precisa pero demasiado técnica para la audiencia, o accesible pero ligeramente incorrecta, o perfectamente correcta pero aburrida. Las pruebas de software tradicional tienen criterios claros de pasa/falla. La evaluación de IA rara vez los tiene. Por eso el campo ha desarrollado múltiples enfoques complementarios: benchmarks automatizados para medición amplia de capacidades, evaluación humana para juicio de calidad, LLM-como-juez para aproximaciones escalables del juicio humano, y métricas específicas de tarea para dominios estrechos. Ningún enfoque individual es suficiente. Los equipos que evalúan bien usan todos en capas.
Los benchmarks públicos como MMLU, HumanEval, MATH y GPQA te dan una forma estandarizada de comparar modelos en tareas bien definidas. Son útiles para obtener una idea aproximada de las capacidades de un modelo y para rastrear el progreso a lo largo del tiempo. Pero tienen limitaciones serias que necesitas entender antes de depender de ellos. La contaminación de benchmarks es generalizada — los datos de entrenamiento frecuentemente incluyen preguntas de benchmarks, así que las puntuaciones altas pueden reflejar memorización en lugar de capacidad. La saturación de benchmarks significa que una vez que la mayoría de los modelos de frontera puntúan por encima del 90% en una prueba, deja de ser informativa. Y el problema más fundamental es que los benchmarks prueban habilidades estrechas y bien definidas, mientras que las aplicaciones reales requieren razonamiento amplio, desordenado y dependiente del contexto. Un modelo que puntúa 92% en MMLU y 87% en HumanEval podría seguir siendo terrible para tu caso de uso específico — escribir controladores de Symfony, resumir documentos legales en francés, o generar SQL para tu esquema particular. Los benchmarks te dicen lo que un modelo puede hacer en general. Tus propias evaluaciones te dicen lo que puede hacer para ti.
El trabajo de evaluación más valioso que puedes hacer es construir una suite de pruebas específica para tu aplicación. Empieza recolectando 50 a 100 ejemplos reales de entradas que tu sistema verá, junto con cómo se ve una buena salida. Estos pueden ser queries reales de usuarios, casos extremos sintéticos o entradas adversariales que prueban modos de fallo conocidos. Para cada ejemplo, define qué significa "correcto" lo más concretamente posible — palabras clave esperadas, estructura requerida, afirmaciones factuales que deben estar presentes o ausentes, criterios de tono. Luego automatiza la evaluación: ejecuta tu prompt contra cada ejemplo, califica las salidas (usando coincidencia exacta, regex o un LLM-como-juez), y rastrea los resultados a lo largo del tiempo. Herramientas como Braintrust, Langfuse y Promptfoo hacen esto más fácil, pero también puedes construirlo con una hoja de cálculo y un script. El punto es tener un proceso repetible para que cuando cambies un prompt, intercambies un modelo o actualices tu pipeline de recuperación, puedas ver inmediatamente si las cosas mejoraron o empeoraron.
Usar un LLM para evaluar la salida de otro LLM — el patrón "LLM-como-juez" — se ha convertido en el enfoque por defecto para evaluación escalable. Le das a un modelo fuerte (típicamente GPT-4 o Claude) la pregunta original, la respuesta del modelo y una rúbrica, y le pides que califique la respuesta en criterios como precisión, utilidad y seguridad. Esto funciona sorprendentemente bien para muchas tareas, especialmente cuando proporcionas rúbricas detalladas y ejemplos de calibración. Pero tiene puntos ciegos: los jueces LLM tienden a preferir respuestas más largas, pueden pasar por alto errores factuales sutiles, y exhiben sesgo de posición (favoreciendo cualquier respuesta que aparece primero en una comparación por pares). La evaluación humana sigue siendo el estándar de oro para aplicaciones sensibles a la calidad. Servicios como Scale AI y Surge proporcionan anotadores entrenados, pero incluso la revisión humana informal — hacer que tres miembros del equipo califiquen independientemente 50 salidas — captura modos de fallo que la evaluación automatizada pasa por alto. Los pipelines de evaluación más robustos usan métricas automatizadas como filtro rápido, LLM-como-juez para decisiones de confianza media, y revisión humana para casos de alto riesgo o ambiguos.
La parte más difícil de la evaluación no es técnica — es cultural. Los equipos que envían grandes productos de IA tratan la evaluación como una disciplina de ingeniería de primera clase, no como una ocurrencia tardía. Escriben evaluaciones antes de escribir prompts, de la misma forma que los buenos desarrolladores escriben pruebas antes de escribir código. Mantienen suites de evaluación vivas que crecen conforme descubren nuevos modos de fallo en producción. Y resisten la tentación de optimizar para puntuaciones de benchmarks a expensas del rendimiento en el mundo real. Si tu modelo pasa tu suite de evaluación pero los usuarios se están quejando, tus evaluaciones están mal, no tus usuarios. Los mejores frameworks de evaluación son los que te mantienen honesto sobre lo que tu sistema realmente hace, especialmente en los casos donde falla.