Verdad objetiva flotante: fijación de la versión del conjunto de datos en las suites de evaluación de LLM

Cuando la puntuación de un benchmark de LLM varía entre dos pruebas, uno quiere saber si fue el modelo el que cambió o los datos con los que se evaluó. En la mayoría de las configuraciones de evaluación abierta, no hay nada que registre esta segunda posibilidad. Una auditoría reciente del catálogo de tareas en lm-evaluation-harness, uno de los sistemas más utilizados para calcular puntuaciones de modelos abiertos, encontró exactamente una configuración entre 841 que incluía un campo de revisión del conjunto de datos, y ese único valor resultó no ser en absoluto un identificador de versión. Este artículo explica cómo se obtuvo ese número, por qué el denominador es tan importante como el numerador, cómo otro conjunto de herramientas tomó una decisión opuesta, y cómo se puede realizar la misma verificación en las propias evaluaciones.

El número principal y el que fue descartado

La medición merece ser estudiada en parte debido a cómo se equivocó al principio. Una versión temprana del conteo indicó que una configuración de 13,986 fijaba sus datos, una cifra mucho más elevada. Ese resultado fue descartado en cuestión de horas. De esos 13,986 archivos, 10,391 no especifican un conjunto de datos por sí mismos sino que heredan uno de un archivo padre a través de include:, y 2,966 son archivos grupales que no indican ningún conjunto de datos en absoluto. Ninguno de estos tipos tiene nada que fijar, por lo que contarlos infla el denominador y hace que el hallazgo parezca mucho más sólido de lo que realmente es. Los analistas señalaron que esta era la segunda vez en una sola semana que se obtenía una cifra impresionante por no haberse revisado qué contenía el denominador, lo cual constituye una advertencia útil para quienes generan sus propias métricas.

Tras la corrección, el hallazgo es el siguiente: en lm-evaluation-harness, 841 configuraciones de tarea nombran directamente un conjunto de datos, y solo una de ellas llena un campo de revisión. Ese campo contiene refs/convert/parquet, una referencia que selecciona un formato de almacenamiento en lugar de una versión específica de los datos. En términos prácticos, ninguna configuración está fijada. Cada ejecución se evalúa según el estado en que se encuentre el conjunto de datos original el día en que se ejecuta.

Principales hallazgos de un vistazo

• De las 13,986 configuraciones de tarea, 841 nombran directamente un conjunto de datos. Las otras 13,145 se dividen en 10,391 archivos que heredan un conjunto de datos a través de include: y 2,966 archivos de agrupación que no tienen su propio conjunto de datos.
• Solo una de esas 841 configuraciones establece una clave de revisión o SHA, y lo que contiene, refs/convert/parquet, elige un formato de archivo en lugar de fijar una versión.

De los 673 archivos de tareas de Python, solo 15 invocan a load_dataset, y solo 2 de ellos incluyen revision=.

Las configuraciones apuntan a 273 conjuntos de datos distintos. En el caso del conjunto de datos mediano, ninguna configuración que lo referenciara había sido modificada en 547.9 días. De los 273, 196 (71.8%) tenían más de un año y 245 (89.7%) más de seis meses.

openai/evals sigue un enfoque opuesto: 455 de sus 463 evaluaciones leen un archivo samples_jsonl dentro del repositorio, respaldado por 722 archivos de datos comprometidos en el mismo. Su valor de referencia no puede desviarse, pero sí puede volverse obsoleto.

No se verificó si algún conjunto de datos original realmente había cambiado, ya que huggingface.co no era accesible desde el entorno de auditoría. La conclusión es que la desviación pasaría desapercibida, no que realmente haya ocurrido.

En resumen

Un conjunto de evaluación es en realidad un grafo de dependencias, y los equipos de software fijan las dependencias por buenas razones. Al revisar cada configuración de tarea en lm-evaluation-harness, extraer el conjunto de datos contra el cual se evalúa cada una y buscar una versión fijada, se obtuvo un candidato que en realidad no era una versión fijada. Medir cuánto tiempo habían permanecido sin modificaciones esas configuraciones mostró que, en promedio, el conjunto de datos no había tenido ninguna configuración de referencia editada durante aproximadamente dieciocho meses. Nada de esto indica que algún número de benchmark publicado esté incorrecto. Lo que demuestra es que, si uno se volviera incorrecto debido a cambios en sus datos, el propio conjunto de evaluación no daría ninguna señal al respecto.

Por qué un benchmark necesita una versión fijada del conjunto de datos

El modelo que se está probando no es lo único que puede cambiar. Cada configuración de tarea hace referencia a un conjunto de datos, como por ejemplo alexandrainst/m_truthfulqa, OALL/ACVA o CogComp/mc_taco, y un conjunto de datos alojado en una plataforma pública es un artefacto dinámico. Tiene mantenedores y recibe correcciones, cambios en las licencias, nuevas particiones, configuraciones adicionales y, de vez en cuando, una corrección silenciosa de una etiqueta que se sabía que estaba errónea. Esa actividad es normal y, en su mayoría, beneficiosa.

El problema radica en el efecto que tiene sobre las comparaciones. Una puntuación solo tiene sentido en relación con un punto de referencia estable. Cuando una nueva versión del modelo genera una puntuación diferente, se ha aprendido algo sobre ese modelo. Pero cuando son los datos los que cambian, lo que se observa es un artefacto de medición que parece ser un hallazgo real. Sin una versión registrada, no hay forma de distinguir entre ambos, ni a posteriori ni en el momento en que se realiza la evaluación.

Una puntuación no fijada es una medición cuyos parámetros nunca se han anotado en el registro.

Este es el mismo razonamiento detrás de los archivos lockfile en los proyectos JavaScript: un rango en package.json, como ^4.2.0, permite que las compilaciones incorporen silenciosamente nuevo código, mientras que un archivo lockfile registra la versión exacta utilizada. Los datos de evaluación merecen el mismo trato.

Cómo se obtuvo la cuenta

La metodología es donde se toman la mayoría de las decisiones importantes, especialmente en lo que respecta al denominador.

• Repositorio: EleutherAI/lm-evaluation-harness, clonado con toda la historia utilizando --filter=blob:none --unshallow. Esto incluyó 4,115 commits desde el 27 de agosto de 2020 hasta un HEAD con fecha del 10 de septiembre de 2026, siendo la medición realizada el 12 de septiembre de 2026. El catálogo cambia constantemente, por lo que ejecuciones posteriores arrojarán números diferentes.
• Rutina de configuración: todos los archivos .yaml y .yml ubicados en lm_eval/tasks. Para cada archivo, la script extrajo dataset_path o hf_path, buscó la presencia de dataset_revision, revision, dataset_sha o sha, y registró si el archivo utilizaba la opción include:.

Denominador elegible: solo los archivos que nombran un conjunto de datos por sí mismos. Se excluyeron las configuraciones heredadas y los archivos de grupo que simplemente agrupan otras tareas, ya que no tienen nada propio al que hacer referencia.

Vencimiento: un git log por archivo indicó la fecha en que cada archivo fue añadido y modificado por última vez, midiéndose con respecto a la fecha del commit HEAD en lugar de la fecha actual, para que las cifras permanezcan fijas con el paso del tiempo.

Ese filtrado dejó 841 configuraciones elegibles que apuntan a 273 conjuntos de datos distintos.

¿Hasta qué punto están vencidas las configuraciones?

El vencimiento debe informarse de dos maneras, porque el cálculo obvio resultó ser engañoso, y eso solo quedó claro mediante una inspección manual.

Contando por configuración, el tiempo mediano desde la última modificación es de 729.8 días. De las 841 configuraciones, 691 (82.2%) no habían sido modificadas en más de un año, y 551 (65.5%) nunca habían sido editadas desde que se añadieron.

Esos números exageran la situación real. Solo cinco commits añadieron el 50.9% de las 841 configuraciones, y un único commit, decc533d, introdujo 272 de ellas en un solo día. Por lo tanto, la distribución por configuración no refleja 841 decisiones independientes que envejecen según sus propios plazos; refleja unas pocas contribuciones masivas además de una gran cantidad de casos menores.

Al agrupar por conjunto de datos en lugar de por archivo, ese agrupamiento desaparece:

• En el conjunto de datos mediano, habían pasado 547.9 días desde que se modificó alguna configuración que lo referenciaba.
• 196 de los 273 conjuntos de datos (71.8%) tenían más de un año.
• 245 de los 273 (89.7%) tenían más de 180 días.

El caso más descuidado había durado 994.1 días.

La cifra por conjunto de datos es la que realmente merece ser citada, ya que resiste la objeción relacionada con el agrupamiento. La mediana sigue siendo de unos dieciocho meses, y nueve de cada diez conjuntos de datos superan los seis meses.

Se admite el anclaje, aunque rara vez se utiliza

Sería injusto criticar el conjunto de herramientas si hiciera imposible el anclaje, pero no es así. El cargador subyacente es la biblioteca estándar Hugging Face datasets, y load_dataset acepta un parámetro de revisión. En la parte en Python del catálogo de tareas, 2 de los 15 archivos que llaman a load_dataset incluyen revision=, de un total de 673 archivos en Python en ese directorio; uno de esos dos archivos hace referencia a un pull-request.

Así que aunque la fijación está disponible, casi nadie la utiliza, y nada en el flujo de trabajo incentiva a los colaboradores a hacerlo. Cuando la opción predeterminada es flotante, aparecen 841 configuraciones de este tipo, ya que son las que realmente se usan en los grandes catálogos.

Si usted se encarga de las evaluaciones, la forma más económica de proceder es buscar hoy mismo en sus propias definiciones de tareas un campo de revisión y ver cuántos resultados obtiene.

El equilibrio opuesto: datos suministrados en openai/evals

openai/evals responde a la misma pregunta desde otra perspectiva, y su enfoque no es claramente inferior. De las 463 configuraciones de evaluación, 455 leen un archivo samples_jsonl almacenado en el propio repositorio, el cual contiene 722 archivos de datos para respaldarlas. La información de referencia está suministrada, lo que significa que está fijada por diseño: los datos se versionan con Git junto con todo lo demás.

La ventaja es la reproducibilidad perfecta: una evaluación realizada por primera vez en 2024 puede repetirse con datos idénticos hasta el último byte. El precio es la moneda. Una copia comercializada nunca recibe correcciones desde fuentes originales, por lo que, aunque el conjunto de herramientas no puede desviarse, puede convertirse gradualmente en algo obsoleto, evaluando nuevos modelos según una versión antigua cuyos errores ya fueron corregidos hace años.

Ninguno de los dos conjuntos sigue el tercer camino: fijar una versión específica y avanzarla intencionadamente. Uno evoluciona sin registro alguno; el otro se congela sin actualizaciones. En ambos casos, la elección se hace por defecto y no como resultado de una decisión consciente.

Lo que la medición no muestra

Los límites del análisis son tan importantes como sus resultados.

• No se observó ningún cambio en el conjunto de datos. La política de red del entorno de auditoría rechazó las conexiones a huggingface.co; el proxy devolvió un código 403 en las solicitudes CONNECT desde ambas máquinas probadas, por lo que no fue posible consultar la información de resolución ni de última modificación. Todo aquí se refiere a si se detectaría un cambio, no a si realmente ocurrió uno.
• El hecho de que no esté marcado como fijo no significa que esté incorrecto. Es probable que muchos de estos conjuntos de datos nunca hayan cambiado. La afirmación se refiere a la falta de un control, no a un error existente.
• Que esté desactualizado no significa que haya sido descuidado. Una configuración que nadie ha editado en 700 días podría estar completa y precisa. La antigüedad indica simplemente que nadie la ha revisado nuevamente, lo cual es diferente de tener un defecto.

Un arnés no representa todo el campo de estudio. Se midió la profundidad de un catálogo y se utilizó otro como contraste. Herramientas como promptfoo, deepeval y ragas son bibliotecas y no registros, por lo que carecen de un catálogo de tareas en YAML comparable; por eso el resultado no dice nada sobre ellas.

Excluir los archivos include: es una decisión subjetiva. Una interpretación más estricta podría preguntarse si las configuraciones padre fijan valores en nombre de sus hijos. Se verificó y resulta que no lo hacen.

Preguntas frecuentes

¿Entonces las puntuaciones de pruebas publicadas son poco fiables?

No, y se debe rechazar esa interpretación. Falta un control específico. Una puntuación solo se ve comprometida cuando los datos subyacentes cambian; la auditoría muestra que, en caso de que eso ocurra, el conjunto no mantiene ningún registro que permita detectarlo posteriormente.

¿Por qué no simplemente verificar si los conjuntos de datos han cambiado?

Eso requiere acceder a huggingface.co para determinar las revisiones de los conjuntos de datos, lo cual fue bloqueado por la política de red de la auditoría con un error 403 en el método CONNECT tanto en una máquina en la nube como en una local. En lugar de inferir desviaciones a partir de señales débiles, la afirmación se redujo a lo que podía verificarse únicamente desde el repositorio, y por eso el hallazgo se refiere al fijado en lugar del cambio.

¿Es el fijado siempre la respuesta correcta?

No automáticamente. Una evaluación fijada nunca detecta correcciones reales de etiquetas incorrectas, y es así como openai/evals puede ser perfectamente reproducible y, al mismo tiempo, gradualmente impreciso. Una política más defendible es la de fijar y actualizar: bloquear una revisión, avanzarla intencionadamente y registrar cada cambio, algo que prácticamente nadie hace.

¿Cómo puede verificar su propio conjunto de pruebas?

Recorra las definiciones de sus tareas, extraiga los nombres de campos del conjunto de datos y busque en esos archivos cualquier revisión o clave SHA. La relación entre el segundo conteo y el primero es la métrica de la que se habla aquí. La auditoría indicó aproximadamente treinta segundos de procesamiento por mil archivos, por lo que se trata de una verificación económica que se puede añadir al proceso CI.

Conclusión

• Trate los conjuntos de datos de evaluación como dependencias: registre una revisión exacta junto a cada puntuación que pretenda comparar.
• Suspecte de relaciones extremas hasta que haya inspeccionado el contenido del denominador; las configuraciones heredadas y agregadas casi convirtieron un hallazgo modesto en uno engañoso.
• Los datos flotantes y los datos congelados fallan en direcciones opuestas: uno se desvía sin dejar rastro, el otro envejece sin corrección. El método de fijación y ajuste, junto con un registro de cambios, evita ambos problemas.

La antigüedad y la falta de pines son señales de que faltan controles, no pruebas de resultados defectuosos.

La pregunta abierta para cualquier equipo que realice evaluaciones en CI es concreta: cuando la puntuación varía entre ejecuciones, ¿qué en su configuración le indica si fue el modelo o los datos los que cambiaron? Si la respuesta es nada, un campo de revisión en las definiciones de sus tareas es el punto de partida más económico. Puede inspeccionar directamente el catálogo de tareas lm-evaluation-harness y el registro openai/evals para comparar los dos enfoques.

Lecturas relacionadas

• Un mapa estratificado de conceptos de ingeniería de IA y cuándo son importantes — Aprenda qué conceptos de ingeniería de IA determinan si un sistema funciona en absoluto, cuáles son cruciales una vez que se desarrolla para producción y cuáles pueden esperar.
• Gestionando LLM como juez como sistema de producción vivo — Conozca cómo el ciclo de vida de cuatro etapas de Netflix —datos reales, entrenamiento ajustado con criterios específicos, despliegue seguro y monitoreo continuo— mantiene preciso a un LLM en escala.