Cómo evaluar de forma reproducible modelos de Hugging Face ante cambios en código de repositorios

La pregunta clave de la evaluación: ¿el modelo realizó un cambio probado en el repositorio?

Para evaluar cambios de código en un repositorio, mide el flujo de trabajo que esperas del modelo: comprender una instantánea del repositorio, proponer un parche y superar las pruebas pertinentes. Una puntuación de autocompletado de código o un diff convincente no demuestran que el cambio funcione en contexto.

Una comparación práctica utiliza las mismas tareas reservadas, el mismo estado del repositorio, la misma plantilla de prompt y los mismos parámetros de generación para cada modelo. Evalúa por separado al menos dos resultados: ¿se pudo aplicar la salida como parche? y ¿se superaron las pruebas seleccionadas? Ninguno de los dos resultados, por sí solo, demuestra que el cambio sea correcto o seguro.

Esto coincide con las recomendaciones centrales de un debate de la comunidad de Hugging Face sobre benchmarking: empezar por la tarea objetivo, comparar modelos con la misma configuración, examinar ejemplos de fallos y considerar los benchmarks públicos como una segunda capa, no como prueba de una mejora específica para la tarea. El hilo también recomienda registrar los detalles de la configuración para que otras personas puedan reproducir la evaluación. Fuente: debate de la comunidad de Hugging Face, “What’s your method for benchmarking?”

1. Crear tareas reservadas del repositorio

Cada tarea debe incluir un commit del repositorio, una descripción concisa del problema y un comando de prueba u otro criterio de aceptación explícito. Mantén las tareas de evaluación fuera del entrenamiento del modelo y de la iteración de prompts. Si ajustas prompts repetidamente con las mismas tareas, estas se convierten en ejemplos de desarrollo y dejan de ser un conjunto de prueba reservado limpio.

Elige tareas que reflejen los cambios que te interesan: correcciones de errores habituales, casos límite, cambios que abarquen varios archivos y situaciones en las que lo adecuado sea indicar que no hay información suficiente. Da preferencia a tareas con pruebas que distingan el comportamiento previsto del comportamiento existente. Registra las carencias conocidas: puede que el conjunto de pruebas no abarque la seguridad, el rendimiento, la compatibilidad o todas las regresiones.

Usa un manifiesto para poder reconstruir cada tarea:

No varíes silenciosamente el estado del repositorio entre modelos. Guarda el manifiesto y las entradas de las tareas junto con los resultados de la evaluación, respetando los requisitos de licencia o privacidad del repositorio.

2. Fijar el modelo de Hugging Face y la configuración de generación

Usa una revisión específica del modelo, no una referencia móvil sin especificar. Registra el ID y la revisión del modelo, la versión de Transformers, el tokenizador y la plantilla de chat, el hardware y si usaste un adaptador, pesos fusionados o cuantización. El comportamiento de un modelo puede depender de estas decisiones.

El siguiente ejemplo es una configuración ilustrativa y no probada para generar una propuesta de parche con Transformers. Sustituye los marcadores y confirma la arquitectura y la plantilla de chat compatibles con el modelo antes de ejecutarlo. Genera texto; no aplica ni prueba el parche resultante.

from transformers import AutoModelForCausalLM, AutoTokenizer
import torch

model_id = "YOUR_HUGGING_FACE_MODEL_ID"
revision = "YOUR_PINNED_REVISION"

messages = [
    {
        "role": "user",
        "content": (
            "Given this repository context and issue, return a unified diff only. "
            "Do not claim tests passed.\n\n"
            "Repository context:\nYOUR_FIXED_REPOSITORY_CONTEXT\n\n"
            "Issue:\nYOUR_HELD_OUT_ISSUE"
        ),
    }
]

tokenizer = AutoTokenizer.from_pretrained(model_id, revision=revision)
model = AutoModelForCausalLM.from_pretrained(
    model_id,
    revision=revision,
    torch_dtype="auto",
    device_map="auto",
)

inputs = tokenizer.apply_chat_template(
    messages,
    tokenize=True,
    add_generation_prompt=True,
    return_tensors="pt",
).to(model.device)

with torch.inference_mode():
    output = model.generate(
        inputs,
        do_sample=False,
        max_new_tokens=1200,
    )

new_tokens = output[0, inputs.shape[1]:]
print(tokenizer.decode(new_tokens, skip_special_tokens=True))

La decodificación codiciosa (do_sample=False) elimina el muestreo como una fuente de variación, pero no garantiza salidas idénticas en todo hardware, biblioteca o kernel. Registra el entorno exacto. Si el flujo de trabajo previsto incluye muestreo, fija y registra la semilla y los parámetros de muestreo; repite las ejecuciones si necesitas entender la variabilidad de las salidas. No des por hecho que los parámetros del ejemplo son adecuados para todos los modelos.

3. Aplicar y probar parches de forma aislada

Para cada combinación de tarea y modelo, empieza desde una copia limpia del commit registrado. Guarda la salida sin procesar del modelo antes de analizarla. Comprueba que incluya un diff utilizable, aplícalo en un árbol de trabajo desechable o en un contenedor y ejecuta el comando de prueba predefinido. Mantén la generación del modelo separada de la ejecución de las pruebas para no confundir un parche fallido con un fallo de infraestructura o del ejecutor de pruebas.

Registra cada resultado por separado:

Que el comando de prueba finalice correctamente es una evidencia de que las pruebas seleccionadas se superaron en el entorno registrado. No demuestra que el cambio sea correcto más allá de esas pruebas. Informa por separado de los fallos de configuración de las pruebas y de los fallos del modelo; no cuentes como aprobada una prueba que no se haya ejecutado.

4. Comparar modelos sin ocultar regresiones

Ejecuta las mismas tareas con las mismas instantáneas del repositorio y el mismo prompt para los modelos de referencia y los candidatos. Informa del número de tareas, la tasa de aplicación de parches, la tasa de pruebas superadas y cuántas tareas se revisaron. Incluye los resultados por tarea o un resumen de fallos, no solo un promedio. Un modelo puede mejorar en un conjunto reducido de correcciones y empeorar en formato, control del alcance u otro subconjunto de tareas.

Si el conjunto de evaluación es pequeño, describe el resultado como un resultado de ese conjunto, no como una clasificación general. El debate citado señala que puede ser importante repetir las ejecuciones, porque las puntuaciones de conjuntos pequeños pueden fluctuar. Si las salidas son estocásticas, haz varias ejecuciones con semillas registradas e informa de la variación; si la generación es determinista, evita igualmente extraer conclusiones generales de unas pocas tareas.

5. Publicar las limitaciones junto con los resultados

Un informe reproducible debe incluir el modelo y su revisión, los commits de los repositorios, el método de selección de tareas, las exclusiones, el prompt, los parámetros de generación, el entorno de software y hardware, el analizador de parches, los comandos de prueba y las reglas de puntuación. Indica qué aspectos no mide la evaluación, por ejemplo, regresiones no probadas, calidad de la revisión de código, propiedades de seguridad, latencia o rendimiento, salvo que los hayas medido.

La conclusión útil es concreta: en estas tareas reservadas de repositorio y con esta configuración registrada, el modelo generó parches con los siguientes resultados de aplicación y pruebas. Esto aporta más información que una puntuación de clasificación cuando la pregunta real es si un modelo puede realizar cambios verificados en tu base de código.