🤖 AI

Towards Evaluation Engineering: An Empirical Study of ML Evaluation Harnesses in the Wild

Este artículo presenta un estudio empírico de 57 entornos de evaluación de aprendizaje automático que identifica la etapa de especificación como la principal fuente de desafíos operativos, clasifica 16.560 problemas por causa raíz para revelar que las funciones no implementadas, las lagunas en la documentación y la falta de validación de entradas representan más del 60% de los problemas, y establece una base para tratar la ingeniería de evaluación como una disciplina distinta de la ingeniería de software.

Autores originales: Zhimin Zhao, Zehao Wang, Abdul Ali Bangash, Bram Adams, Ahmed E. Hassan

Publicado 2026-05-26

📖 6 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Zhimin Zhao, Zehao Wang, Abdul Ali Bangash, Bram Adams, Ahmed E. Hassan

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que eres un chef tratando de juzgar una nueva receta. Tienes los ingredientes (los datos), la tarjeta de receta (el modelo) y una lista de reglas sobre qué hace que un plato sea "bueno" (las métricas). Pero antes de poder probar la comida, necesitas una cocina donde cocinar, un temporizador para controlar la cocción y una hoja de puntuación para anotar los resultados.

En el mundo de la Inteligencia Artificial (IA), esta "cocina" se llama Marco de Evaluación (Evaluation Harness). Es la herramienta de software que realmente ejecuta las pruebas, carga los datos, calcula las puntuaciones y te dice si el modelo de IA está haciendo un buen trabajo.

Este artículo es como una inspección masiva de 57 "cocinas de IA" diferentes para ver cómo funcionan, dónde fallan y por qué la gente se frustra con ellas. Los investigadores llaman a este nuevo campo "Ingeniería de Evaluación".

Aquí tienes el desglose de sus hallazgos usando analogías simples:

1. El flujo de trabajo de cinco etapas de la cocina

Los investigadores descubrieron que cada cocina de evaluación de IA pasa por cinco etapas específicas, como una línea de producción:

Provisionamiento (Preparando la cocina): Tener la estufa, las ollas y los ingredientes listos. Esto incluye instalar el software e iniciar sesión en las cuentas.
Especificación (Escribiendo la receta): Decidir exactamente qué vas a cocinar y qué ingredientes vas a usar. Aquí es donde cargas el modelo de IA y los datos de prueba.
Ejecución (Cocinando la comida): Ejecutar realmente el modelo de IA para generar respuestas.
Evaluación (Probando y puntuando): Comprobar las respuestas contra las correctas y calcular una puntuación.
Informe (Sirviendo el menú): Mostrar los resultados finales en un gráfico o un informe.

La gran sorpresa: La mayoría de estas cocinas son excelentes "cocinando" (Ejecución) pero terribles "sirviendo" (Informe). Muy pocas tienen alarmas automáticas para decirte si la comida sabe peor hoy que ayer.

2. Dónde las cosas salen mal (Las causas raíz)

El equipo revisó más de 16.000 quejas (llamadas "problemas") de los usuarios. Descubrieron que los problemas no suelen deberse a que las matemáticas estén mal o a que el código se caiga de manera dramática. En cambio, los problemas son mayormente burocráticos y por piezas faltantes.

Piénsalo como intentar construir un set de Lego donde faltan las instrucciones o la caja dice "incluye un ladrillo rojo" pero solo recibes uno azul.

Las tres razones principales por las que las cocinas fallan son:

Falta de funciones (24%): La herramienta prometió hacer algo (como manejar un tipo específico de datos), pero los desarrolladores nunca construyeron realmente esa parte. Es como un coche que tiene volante pero no tiene motor.
Instrucciones deficientes (20%): La herramienta funciona, pero el manual falta, está desactualizado o es confuso. Los usuarios no pueden entender cómo usarla.
Falta de controles de seguridad (17%): La herramienta no verifica si los ingredientes están frescos. Si le alimentas datos malos, no se detiene; simplemente cocina basura y te da una puntuación de basura.

3. Los diferentes tipos de cocinas

Los investigadores agruparon las 57 cocinas en cuatro "arquetipos" (tipos), y cada tipo tiene sus propios dolores de cabeza específicos:

La cocina de exámenes estandarizados (40%): Estas son las cocinas grandes y famosas que prueban muchos modelos contra exámenes estándar (como las pruebas SAT para la IA).
- Su mayor dolor de cabeza: Ruptura de dependencias. Dependen de ingredientes externos (conjuntos de datos) que cambian o desaparecen sin aviso. Si el proveedor cambia el empaque, toda la cocina deja de funcionar.
La herramienta especializada (21%): Estas son herramientas pequeñas que hacen una sola cosa perfectamente (como verificar si un robot puede caminar).
- Su mayor dolor de cabeza: Instrucciones deficientes. Como son tan simples, los desarrolladores olvidan escribir instrucciones claras sobre cómo configurarlas.
La sonda personalizada (21%): Estas prueban habilidades específicas (como programación o matemáticas).
- Su mayor dolor de cabeza: Errores matemáticos. Como inventan sus propias fórmulas de puntuación, a menudo se equivocan en las matemáticas, lo que lleva a errores silenciosos donde la puntuación parece correcta pero en realidad es errónea.
El restaurante de servicio completo (17%): Estas son las plataformas elegantes y todo-en-uno que lo hacen todo.
- Su mayor dolor de cabeza: Incompatibilidades de contrato. Como conectan tantas partes diferentes (como un juez remoto y un modelo local), las partes a menudo no hablan el mismo idioma, causando fallos de comunicación.

4. El "asesino silencioso"

El problema más peligroso que encontró el artículo son los Errores silenciosos de puntuación.

Imagina a un juez probando una sopa y dándole una calificación de 5 estrellas. El juez está seguro, la puntuación se imprime y todos están felices. Pero el juez olvidó añadir sal, y la sopa sabe terrible. La herramienta no se cayó; simplemente dio una puntuación incorrecta.

El artículo encontró que muchas herramientas calculan las puntuaciones incorrectamente (Errores algorítmicos) o no verifican si los datos tienen sentido (Brechas de validación), y como no hay una "segunda opinión" integrada en el sistema, nadie se da cuenta hasta mucho después.

5. Qué significa esto para el futuro

El artículo concluye que necesitamos tratar estas herramientas no solo como "scripts" sino como productos de ingeniería serios.

Los desarrolladores deben dejar de asumir que las matemáticas son perfectas y empezar a construir "redes de seguridad" (como verificar si la puntuación tiene sentido antes de imprimirla).
Los usuarios deben dejar de confiar ciegamente en la puntuación. Solo porque la herramienta diga "95% de precisión" no significa que sea verdad; necesitas verificar el trabajo.
Los investigadores necesitan inventar nuevas formas de probar estas herramientas, porque las viejas formas de probar software no funcionan cuando la "prueba" en sí misma es una IA que podría estar alucinando.

En resumen: Hemos construido máquinas increíbles para probar otras máquinas, pero las máquinas que hacen las pruebas a menudo carecen de instrucciones, tienen agujeros en su lógica y carecen de la capacidad de decirnos cuándo están confundidas. Arreglar estas "cocinas" es tan importante como construir mejores "chefs" (modelos de IA).

Resumen Técnico: Hacia la Ingeniería de Evaluación: Un Estudio Empírico de los Entornos de Evaluación de ML en la Práctica

1. Declaración del Problema

La evaluación del Aprendizaje Automático (ML) sustenta el progreso de la IA, sin embargo, la infraestructura de software que ejecuta estas evaluaciones —conocida como entornos de evaluación (evaluation harnesses)— ha recibido una atención limitada desde una perspectiva de ingeniería de software (SE). Mientras que la literatura existente se centra en qué evaluar (métricas, puntos de referencia, capacidades), trata a los propios entornos como herramientas transparentes en lugar de productos de software diseñados con flujos de trabajo operativos distintos, modos de fallo y compensaciones de diseño.

Esta brecha genera una falta de comprensión sobre la Ingeniería de Evaluación (EvalEng): las preocupaciones de SE que surgen al operacionalizar la evaluación, incluyendo el diseño del entorno, la gestión de dependencias, la corrección de la puntuación y la integridad de los resultados. Sin esta comprensión, la fiabilidad de la evaluación de ML se ve comprometida por problemas como la contaminación de los puntos de referencia, resultados irreproducibles y errores de puntuación silenciosos que son difíciles de detectar en infraestructuras complejas.

2. Metodología

Los autores realizaron un estudio empírico a gran escala de 57 entornos de evaluación de código abierto y 19.638 incidencias de GitHub (informes de errores, solicitudes de características y preguntas de uso) recopiladas hasta el 6 de enero de 2026. El estudio empleó una metodología de cuatro etapas:

Recopilación de Entornos: Los investigadores identificaron 57 entornos de fuentes curadas (por ejemplo, Awesome Production ML List) y ampliaron la cobertura mediante búsquedas en GitHub basadas en palabras clave. Los criterios de inclusión requerían funcionalidad explícita de evaluación/puntuación, invocación de modelos y mantenimiento activo (más de 500 estrellas, actividad en los últimos 12 meses).
Extracción del Flujo de Trabajo: Utilizando la clasificación abierta iterativa y la comparación constante en la documentación y la ejecución local, el equipo derivó un modelo de flujo de trabajo jerárquico. Este proceso alcanzó la saturación teórica en el entorno número 51.
Minería de Incidencias: El equipo recuperó 19.638 incidencias de los 57 entornos (abarcando 59 repositorios).
Clasificación: Un enfoque híbrido combinó la anotación manual con la clasificación mediante Modelos de Lenguaje Grandes (LLM).
- Anotación Manual: Una muestra estadísticamente significativa de 377 incidencias fue etiquetada manualmente por dos autores para establecer una taxonomía de etapas del flujo de trabajo y causas raíz. La fiabilidad interevaluador fue alta ( $\kappa$ de Cohen > 0,87).
- Calibración del LLM: Un clasificador basado en Claude Haiku 4.5 fue calibrado frente a etiquetas de consenso humano y aplicado al corpus completo para mapear las incidencias a las etapas del flujo de trabajo y las categorías de causas raíz.

3. Contribuciones Clave

El artículo establece una base empírica para la EvalEng a través de cuatro contribuciones principales:

Un Modelo de Flujo de Trabajo Unificado: Un modelo de cinco etapas, nueve pasos y 34 estrategias que describe el ciclo de vida operativo de la evaluación de ML (Provisioning $\to$ Specification $\to$ Execution $\to$ Assessment $\to$ Reporting).
Mapeo Empírico de Incidencias: Una clasificación de 16.560 incidencias relevantes para el flujo de trabajo en GitHub a través de los 57 entornos, identificando dónde ocurre la fricción operativa.
Taxonomía de Causas Raíz: Una taxonomía de diez categorías de desafíos operativos, que distingue entre defectos de software (por ejemplo, errores algorítmicos) y brechas de capacidad (por ejemplo, características no implementadas).
Identificación de la Brecha de Adopción: Un análisis que revela brechas significativas en capacidades orientadas a la producción, como la cuantificación de la incertidumbre y la alerta de regresiones.

4. Resultados Clave

RQ1: Flujo de Trabajo Operativo

El estudio identificó un flujo de trabajo de cinco etapas:

Provisioning (Provisionamiento): Configuración del entorno y configuración de credenciales.
Specification (Especificación): Definición de entradas (modelos, conjuntos de datos) y jueces de puntuación.
Execution (Ejecución): Ejecución del Sistema Bajo Prueba (SUT).
Assessment (Evaluación): Cálculo de métricas y agregación de puntuaciones.
Reporting (Informes): Visualización de resultados y alerta sobre regresiones.

Hallazgos:

Dominio Offline: La mayoría de los entornos (40,4% de Suites Estandarizadas de LLM, 21,1% de Bibliotecas de Dominio Estrecho) están restringidos a flujos de trabajo estáticos y offline. Solo el 17,5% (Plataformas de LLM de Pila Completa) abarcan las cinco etapas.
Brechas de Estrategia: Aunque la instalación (git clone, paquetes de Python) es casi universal, el despliegue en contenedores es raro (21,1%). El muestreo de tráfico de producción es soportado solo por el 7,0% de los entornos.
Deficiencias en Informes: La generación de informes es la etapa menos soportada. Solo el 22,8% de los entornos cuantifica la incertidumbre y solo el 8,8% proporciona alerta de regresiones.

RQ2: Causas Raíz de los Desafíos Operativos

El estudio clasificó 16.560 incidencias en diez causas raíz. Las tres causas principales representan el 61,7% de todas las incidencias:

Brecha de Característica No Implementada (24,3%): Falta funcionalidad requerida.
Deficiencia de Documentación (20,3%): Instrucciones faltantes o desactualizadas.
Brecha de Validación (17,2%): Falta de validación de entrada/salida.

Patrones Específicos por Arquetipo:

Suites Estandarizadas de LLM: Alto volumen de incidencias; la causa raíz secundaria es la Ruptura de Dependencias Externas (8,9%) debido a la dependencia de conjuntos de datos aguas arriba en constante cambio.
Sondas Específicas de Tareas: La causa raíz secundaria es el Error Algorítmico (11,9%), ya que la puntuación adaptada al dominio carece de implementaciones de referencia.
Plataformas de Pila Completa: La causa raíz secundaria es el Desajuste del Contrato de Interfaz (10,6%) debido a la compleja integración de múltiples componentes.
Bibliotecas de Dominio Estrecho: La Deficiencia de Documentación (31,8%) es la causa raíz principal, superando a las brechas de características.

RQ3: Distribución de Causas Raíz a través de las Etapas

Las causas raíz no están distribuidas uniformemente; se concentran en etapas específicas:

Provisioning: Dominado por la Incompatibilidad del Entorno (16,1%) y la Ruptura de Dependencias Externas (20,1%).
Specification: Concentrado en la Brecha de Característica No Implementada (32,8%) y la Deficiencia de Documentación (27,1%).
Assessment: Dominado por el Error Algorítmico (25,9%) y la Brecha de Validación (22,5%).
Transversal: La Brecha de Validación es la única causa raíz que aparece por encima del 10% en las cinco etapas, lo que indica una necesidad sistémica de una mejor validación semántica.

Cambio en el Flujo de Trabajo: Los desafíos cambian de problemas relacionados con el entorno en las etapas iniciales a problemas relacionados con la puntuación en las etapas posteriores.

5. Significado e Implicaciones

El artículo argumenta que la fiabilidad de la evaluación es una preocupación distinta de la ingeniería de software que requiere atención más allá del diseño de métricas.

Para Desarrolladores:
- Ir más allá de la validación de esquemas hacia contratos de API semánticos para prevenir fallos silenciosos (por ejemplo, tipos válidos pero semánticas incorrectas).
- Implementar verificación independiente del oráculo (por ejemplo, pruebas metamórficas, pruebas diferenciales) para las tuberías de puntuación, ya que las salidas de los entornos a menudo carecen de una verdad fundamental independiente.
- Adaptar el mantenimiento a los modos de fallo específicos del arquetipo (por ejemplo, fijar dependencias para suites de puntos de referencia, pruebas de contrato para plataformas de pila completa).
- Lanzar documentos de especificación legibles por máquina (similares a las tarjetas de modelo) que declaren la cobertura del flujo de trabajo, las dependencias y los patrones de desafíos conocidos.
Para Usuarios:
- No tratar la salida del entorno como verdad fundamental sin verificación independiente, especialmente al desviarse de las configuraciones de puntos de referencia diseñadas.
- Reconocer que la mayoría de los entornos carecen de cuantificación de la incertidumbre, lo que dificulta distinguir las brechas reales de capacidad de los artefactos del entorno.
Para Investigadores:
- Tratar la ingeniería de evaluación como un problema de investigación en SE. Los marcos existentes de MLOps y pruebas requieren adaptación estructural para manejar las restricciones únicas de los entornos de evaluación (por ejemplo, sensibilidad de los prompts, líneas base cambiantes y desplazamientos en la distribución de tráfico estático frente a producción).
- Investigar cómo definir umbrales de regresión y significancia estadística en entornos donde las líneas base no son estables.

El estudio concluye que mejorar la fiabilidad de la evaluación requiere un enfoque holístico del diseño del flujo de trabajo en todas las etapas, en lugar de mejoras aisladas en las métricas o los puntos de referencia. El modelo de flujo de trabajo y la taxonomía de causas raíz proporcionados ofrecen una línea base para la investigación longitudinal que rastree la maduración de la infraestructura de evaluación.