Comment évaluer de manière reproductible les modèles Hugging Face sur des modifications de code de dépôt

Le critère d’évaluation : le modèle a-t-il produit une modification du dépôt testée ?

Pour évaluer des modifications de code dans un dépôt, évaluez le flux de travail que vous attendez du modèle : comprendre un instantané du dépôt, proposer un patch et réussir les tests pertinents. Un score de complétion de code ou un diff convaincant ne prouve pas que la modification fonctionne dans son contexte.

Pour comparer les modèles de manière pratique, utilisez les mêmes tâches tenues à l’écart, le même état du dépôt, le même modèle de prompt et les mêmes paramètres de génération. Évaluez séparément au moins deux résultats : la sortie pouvait-elle être appliquée sous forme de patch ? et les tests sélectionnés ont-ils réussi ? Aucun de ces résultats, pris isolément, ne prouve que la modification est correcte ou sûre.

Cette méthode reprend les conseils centraux d’une discussion de la communauté Hugging Face sur le benchmarking : commencer par la tâche cible, comparer les modèles avec les mêmes paramètres, examiner des exemples d’échec et considérer les benchmarks publics comme un complément, non comme une preuve d’amélioration pour une tâche particulière. La discussion recommande également de consigner les détails de configuration afin que d’autres puissent reproduire l’évaluation. Source : discussion de la communauté Hugging Face, “What’s your method for benchmarking?”

1. Créer des tâches de dépôt tenues à l’écart

Chaque tâche doit inclure un commit du dépôt, une description concise du problème et une commande de test ou un autre critère d’acceptation explicite. N’utilisez pas les tâches d’évaluation pour l’entraînement du modèle ou l’itération sur les prompts. Si vous ajustez régulièrement les prompts à partir des mêmes tâches, celles-ci deviennent des exemples de développement plutôt qu’un jeu de test réellement tenu à l’écart.

Choisissez des tâches représentatives des modifications qui vous intéressent : corrections de bugs courantes, cas limites, changements touchant plusieurs fichiers et cas où la bonne réponse consiste à signaler qu’il manque des informations. Privilégiez les tâches accompagnées de tests qui distinguent le comportement attendu du comportement existant. Consignez les lacunes connues : une suite de tests peut ne pas couvrir la sécurité, les performances, la compatibilité ni toutes les régressions.

Utilisez un manifeste pour pouvoir reconstituer chaque tâche :

Ne faites pas varier silencieusement l’état du dépôt d’un modèle à l’autre. Conservez le manifeste et les entrées des tâches avec les résultats de l’évaluation, tout en respectant les éventuelles exigences de licence ou de confidentialité du dépôt.

2. Épingler le modèle Hugging Face et sa configuration de génération

Utilisez une révision précise du modèle, plutôt qu’une référence mobile non spécifiée. Consignez l’ID du modèle, sa révision, la version de Transformers, le tokenizer et le chat template, le matériel utilisé, ainsi que le recours éventuel à un adapter, à des poids fusionnés ou à la quantification. Ces choix peuvent influer sur le comportement du modèle.

L’exemple suivant est une configuration illustrative non testée destinée à générer une proposition de patch avec Transformers. Remplacez les valeurs fictives et vérifiez l’architecture prise en charge par le modèle ainsi que son chat template avant de l’exécuter. Il génère du texte ; il n’applique pas le patch obtenu et ne le teste pas.

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))

Le décodage glouton (do_sample=False) élimine l’échantillonnage comme source de variation, mais ne garantit pas des sorties identiques sur tous les matériels, bibliothèques ou kernels. Consignez l’environnement exact. Si l’échantillonnage fait partie du flux de travail prévu, fixez et consignez la seed et les paramètres d’échantillonnage ; répétez les exécutions si vous devez mesurer la variabilité des sorties. Ne supposez pas que les paramètres de l’exemple conviennent à tous les modèles.

3. Appliquer et tester les patchs en isolation

Pour chaque paire tâche-modèle, partez d’un checkout propre du commit consigné. Enregistrez la sortie brute du modèle avant de l’analyser. Vérifiez qu’elle contient un diff exploitable, appliquez-le dans un worktree jetable ou un conteneur, puis exécutez la commande de test prédéfinie. Séparez la génération du modèle de l’exécution des tests afin de ne pas confondre l’échec d’un patch avec un problème d’infrastructure ou de test runner.

Consignez individuellement les résultats :

La réussite d’une commande de test indique que les tests sélectionnés ont réussi dans l’environnement consigné. Elle ne prouve pas que le code est correct au-delà de ces tests. Signalez séparément les échecs de configuration des tests et les échecs du modèle ; ne comptez pas un test non exécuté comme une réussite.

4. Comparer les modèles sans masquer les régressions

Exécutez les mêmes tâches, sur les mêmes instantanés de dépôt et avec le même prompt, pour le modèle de référence et les modèles candidats. Indiquez le nombre de tâches, le taux d’application des patchs, le taux de réussite aux tests et le nombre de tâches examinées. Incluez les résultats par tâche ou un récapitulatif des échecs, et pas seulement une moyenne. Un modèle peut améliorer un sous-ensemble restreint de corrections tout en régressant sur la mise en forme, la maîtrise du périmètre ou un autre type de tâche.

Pour un petit jeu d’évaluation, décrivez le résultat comme un résultat obtenu sur ce jeu, et non comme un classement général. La discussion citée indique que des exécutions répétées peuvent être importantes, car les scores sur de petits jeux peuvent varier. Si les sorties sont stochastiques, effectuez plusieurs exécutions avec des seeds consignées et indiquez la variation observée ; si la génération est déterministe, restez prudent avant de tirer des conclusions générales à partir de quelques tâches.

5. Publier les limites avec les résultats

Un rapport reproductible doit préciser le modèle et sa révision, les commits du dépôt, la méthode de sélection des tâches, les exclusions, le prompt, les paramètres de génération, l’environnement logiciel et matériel, l’analyseur de patchs, les commandes de test et les règles de notation. Indiquez ce que l’évaluation ne mesure pas : par exemple, les régressions non testées, la qualité de la revue de code, les propriétés de sécurité, la latence ou les performances, sauf si vous les avez mesurées.

La conclusion utile doit être précise : sur ces tâches de dépôt tenues à l’écart et avec cette configuration consignée, le modèle a produit des patchs présentant les résultats suivants en matière d’application et de tests. C’est plus instructif qu’un score de classement lorsque la vraie question est de savoir si un modèle peut apporter des modifications vérifiées à votre base de code.