Hugging-Face-Modelle anhand von Codeänderungen in Repositories reproduzierbar bewerten

Die entscheidende Frage: Hat das Modell eine getestete Repository-Änderung erstellt?

Bewerten Sie bei Codeänderungen auf Repository-Ebene den Workflow, den das Modell ausführen soll: einen Snapshot des Repositorys verstehen, einen Patch vorschlagen und relevante Tests bestehen. Ein Codevervollständigungs-Score oder ein überzeugend wirkender Diff belegt nicht, dass eine Änderung im jeweiligen Kontext funktioniert.

Ein praxisnaher Vergleich verwendet für jedes Modell dieselben zurückgehaltenen Aufgaben, denselben Repository-Stand, dieselbe Prompt-Vorlage und dieselben Generierungseinstellungen. Bewerten Sie mindestens zwei Ergebnisse getrennt: Lässt sich die Ausgabe als Patch anwenden? und Wurden die ausgewählten Tests bestanden? Keines dieser Ergebnisse beweist für sich allein, dass die Änderung korrekt oder sicher ist.

Das entspricht den zentralen Empfehlungen aus einer Diskussion in der Hugging-Face-Community zum Benchmarking: Beginnen Sie mit der Zielaufgabe, vergleichen Sie Modelle unter denselben Bedingungen, prüfen Sie einzelne Fehlschläge und betrachten Sie öffentliche Benchmarks als Ergänzung, nicht als Nachweis einer aufgabenspezifischen Verbesserung. Im Thread wird außerdem empfohlen, die Einrichtungsdetails festzuhalten, damit andere die Bewertung reproduzieren können. Quelle: Diskussion in der Hugging-Face-Community, „What’s your method for benchmarking?“

1. Zurückgehaltene Repository-Aufgaben erstellen

Jede Aufgabe sollte einen Repository-Commit, eine prägnante Problembeschreibung und einen Testbefehl oder eine andere explizite Abnahmebedingung enthalten. Halten Sie die Evaluationsaufgaben von Modelltraining und Prompt-Iteration getrennt. Wenn Sie Prompts wiederholt anhand derselben Aufgaben abstimmen, sind diese Aufgaben keine saubere zurückgehaltene Testmenge mehr, sondern Entwicklungsbeispiele.

Wählen Sie Aufgaben, die die für Sie relevanten Änderungen abbilden: gewöhnliche Fehlerbehebungen, Randfälle, Änderungen über mehrere Dateien hinweg und Fälle, in denen die richtige Reaktion darin besteht, auf unzureichende Informationen hinzuweisen. Bevorzugen Sie Aufgaben mit Tests, die das gewünschte Verhalten vom bisherigen Verhalten unterscheiden. Halten Sie bekannte Lücken fest: Eine Testsuite deckt möglicherweise nicht Sicherheit, Performance, Kompatibilität oder alle Regressionen ab.

Verwenden Sie ein Manifest, damit sich jede Aufgabe rekonstruieren lässt:

Verändern Sie den Repository-Stand nicht stillschweigend zwischen den Modellen. Speichern Sie das Manifest und die Aufgabeneingaben zusammen mit den Evaluierungsergebnissen und beachten Sie dabei die Lizenz- und Datenschutzanforderungen des jeweiligen Repositorys.

2. Hugging-Face-Modell und Generierungseinstellungen fixieren

Verwenden Sie eine bestimmte Modellrevision statt einer nicht näher spezifizierten, veränderlichen Referenz. Dokumentieren Sie die Modell-ID, Revision, Transformers-Version, den Tokenizer und das Chat-Template, die Hardware sowie, ob Sie einen Adapter, zusammengeführte Gewichte oder Quantisierung eingesetzt haben. Das Verhalten eines Modells kann von diesen Entscheidungen abhängen.

Das folgende Beispiel zeigt eine illustrative, nicht getestete Konfiguration, um mit Transformers einen Patchvorschlag zu generieren. Ersetzen Sie die Platzhalter und prüfen Sie vor der Ausführung, ob die unterstützte Architektur und das Chat-Template des Modells stimmen. Die Konfiguration generiert Text; sie wendet den resultierenden Patch weder an noch testet sie ihn.

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

Greedy Decoding (do_sample=False) beseitigt Sampling als eine mögliche Quelle von Abweichungen, garantiert aber keine identischen Ausgaben auf jeder Hardware, mit jeder Bibliothek oder jedem Kernel. Dokumentieren Sie die genaue Umgebung. Wenn Sampling zum vorgesehenen Workflow gehört, legen Sie Seed und Sampling-Parameter fest und halten Sie sie fest; wiederholen Sie die Läufe, wenn Sie die Variabilität der Ausgaben untersuchen müssen. Gehen Sie nicht davon aus, dass die Einstellungen im Beispiel für jedes Modell geeignet sind.

3. Patches isoliert anwenden und testen

Beginnen Sie für jedes Aufgaben-Modell-Paar mit einem sauberen Checkout des dokumentierten Commits. Speichern Sie die unverarbeitete Modellausgabe, bevor Sie sie parsen. Prüfen Sie, ob sie einen verwendbaren Diff enthält, wenden Sie diesen in einem entbehrlichen Worktree oder Container an und führen Sie den vorab festgelegten Testbefehl aus. Halten Sie die Modellgenerierung von der Testausführung getrennt, damit ein fehlgeschlagener Patch nicht mit einem Infrastruktur- oder Test-Runner-Fehler verwechselt wird.

Dokumentieren Sie die einzelnen Ergebnisse:

Ein erfolgreich ausgeführter Testbefehl belegt, dass die ausgewählten Tests in der dokumentierten Umgebung bestanden wurden. Er beweist nicht, dass die Änderung über diese Tests hinaus korrekt ist. Berichten Sie fehlgeschlagene Testeinrichtungen getrennt von Modellfehlern und werten Sie nicht ausgeführte Tests nicht als bestanden.

4. Modelle vergleichen, ohne Regressionen zu verschleiern

Führen Sie für das Baseline- und das Kandidatenmodell dieselben Aufgaben mit denselben Repository-Snapshots und demselben Prompt aus. Berichten Sie die Anzahl der Aufgaben, die Rate erfolgreicher Patch-Anwendungen, die Erfolgsrate der Tests und die Anzahl der geprüften Aufgaben. Fügen Sie Ergebnisse auf Aufgabenebene oder eine Zusammenfassung der Fehlschläge bei, statt nur einen Durchschnitt anzugeben. Ein Modell kann bei einer eng umrissenen Gruppe von Fehlerbehebungen besser werden und sich zugleich bei Formatierung, Begrenzung des Umfangs oder einer anderen Aufgabengruppe verschlechtern.

Beschreiben Sie das Ergebnis bei einer kleinen Evaluationsmenge als Ergebnis für genau diese Menge – nicht als allgemeines Ranking. In der Quelldiskussion wird darauf hingewiesen, dass wiederholte Läufe wichtig sein können, da die Scores kleiner Mengen schwanken können. Sind die Ausgaben stochastisch, führen Sie wiederholte Läufe mit dokumentierten Seeds durch und berichten Sie die Schwankungen. Ist die Generierung deterministisch, sollten Sie dennoch keine weitreichenden Schlussfolgerungen aus wenigen Aufgaben ziehen.

5. Einschränkungen zusammen mit dem Ergebnis veröffentlichen

Ein reproduzierbarer Bericht sollte Modell und Revision, Repository-Commits, Auswahlmethode für die Aufgaben, Ausschlüsse, Prompt, Generierungsparameter, Software- und Hardwareumgebung, Patch-Parser, Testbefehle und Bewertungsregeln enthalten. Legen Sie offen, was die Bewertung nicht erfasst, etwa ungetestete Regressionen, die Qualität von Code-Reviews, Sicherheitsmerkmale, Latenz oder Performance, sofern diese nicht gemessen wurden.

Die aussagekräftige Schlussfolgerung ist konkret: Bei diesen zurückgehaltenen Repository-Aufgaben und unter den dokumentierten Bedingungen erzeugte das Modell Patches mit den folgenden Ergebnissen bei Anwendung und Tests. Das ist informativer als ein Leaderboard-Score, wenn die eigentliche Frage lautet, ob ein Modell überprüfte Änderungen an Ihrer Codebasis vornehmen kann.