Statische Coding-Benchmarks verfallen, sobald ihre Aufgaben in Trainingskorpora durchsickern. W2 synthetisiert Evaluierungsaufgaben per AST-Analyse direkt aus echten, versionierten Repositories – Kontamination wird zur messbaren Eigenschaft statt zum unsichtbaren Störfaktor.
Working PaperPilot gemessen – nur operative Ergebnisse · Resistenzstudie folgt
Benchmarks sickern durch. Die Scores ziehen nach.
Die Validität eines Benchmarks hängt daran, wie sauber seine Testdaten vom Trainingsset getrennt sind – und für öffentliche Coding-Suiten lautet die ehrliche Antwort: nicht sauber.
Frühe ausführungsbasierte Suiten etablierten den Test funktionaler Korrektheit, sind aber Single-File, synthetisch und inzwischen massiv in Trainingskorpora durchgesickert; gehärtete Varianten ergänzten mutationsgenerierte Tests, ohne die Kontamination zu lösen. Die Antwort des Forschungsfelds hat drei Formen angenommen: Post-Cutoff-Ernte (Probleme, die erst nach dem Wissens-Cutoff eines Modells veröffentlicht wurden), private Held-out-Repositories und automatisierte Generierung aus echten Repositories. W2 gehört zur dritten Familie – mit zwei bewussten Einschränkungen: Es läuft End-to-End auf einer einzelnen 32 GB-GPU, air-gapped, und es zielt auf eine sicherheitsrelevante Validierungsbibliothek, wo ein halluzinierter „Fix“ maximal teuer ist.
Zwei Lehren aus dieser Literatur prägen alles Folgende. Erstens: Kontaminationsresistenz ist erst durch einen Fresh-versus-Stale-Vergleich belegt – nicht durch den bloßen Akt der Generierung aus einem Repository. Zweitens: Der etablierte Standard für ein „Pass“ im Code ist execution-grounded – Erfolg heißt, dass Tests nach der Änderung des Modells bestehen, nicht dass der Output plausibel klingt.
Aufgaben aus einem fixierten Commit.
Eine strukturelle Extraktions-Engine liest ein Ziel-Repository und fertigt frische Aufgaben, die an die tatsächlichen Signaturen, Imports und Edge Cases dieses Codes gebunden sind – bis zu einer Aufgabe pro Kategorie und Datei.
Aufgaben sind eine reine Funktion von (Repo-Zustand, Extraktionsregeln) – Monate später aus exakt demselben Commit re-derivierbar, auch durch unabhängige Dritte. Das ist das Substrat, auf dem die Kontaminationskontrolle aufbaut.
Der Pilot, ehrlich gelesen.
Sechzig Aufgaben – zwanzig pro Kategorie – liefen End-to-End gegen Cerberus, eine sicherheitsrelevante Input-Validierungsbibliothek. Jede Aufgabe wurde abgeschlossen. Und genau deshalb ist das Ergebnis kein Capability-Score.
Nach der Diskriminationsregel, die dieses Programm an jede Rubric anlegt – ein Aufgabenset, auf dem jede Probe besteht, misst nichts –, ist ein 60/60-Ergebnis keine Capability-Aussage. Es besagt, dass die generierten Aufgaben unterhalb der Leistungsgrenze des Modells lagen. Das ist der zentrale Befund des Piloten: Die Extraktionspipeline läuft End-to-End, deterministisch, im VRAM-Budget – und die Schwierigkeitsverteilung muss angehoben werden, bevor irgendeine Zahl Signal trägt. Vertrauenswürdig ist hier die operative Messung: Durchsatz, Stabilität, Token-Bilanz unter fixiertem Single Stream.
Was der Pilot nicht zeigt.
Zwei Eigenschaften, die der Lauf nicht belegt – präzise benannt, weil jede in §05 zu einem messbaren Kriterium wird.
Fünf Kriterien, C1–C5.
Die Workstream-Hypothese: Aus lebenden Repositories regenerierte Aufgaben widerstehen der Memorierung – der Vorteil eines Modells auf gesehenem Code überträgt sich nicht auf strukturell gematchten, ungesehenen Code aus derselben Pipeline. Jede Aussage trägt Instrument und Schwelle und gilt als prognostiziert, bis sie gemessen ist.
C1 und C2 überführen die ehrlichen Grenzen des Piloten in gemessene Ergebnisse; C3–C5 formalisieren die Next-Steps-Liste. Alle fünf laufen auf demselben Single-GPU-Setup, air-gapped, plus der W1-Pipeline, die das Programm bereits enthält – und genau das ist der Punkt: Der gesamte Plan ist unter der Souveränitätsbedingung verifizierbar, für die der Pilot gebaut wurde.
Souveränes Modell-Vetting, End-to-End.
Das Vetting eines Open-Weight-Modells für eine air-gapped, sicherheitskritische Codebase – der Anwendungsfall, für den die Methode existiert.
- Situation. Ein Team pflegt eine proprietäre Input-Validierungsbibliothek unter einer Datensouveränitäts-Auflage – nichts darf das Netz verlassen. Öffentliche Coding-Benchmarks sind kontaminiert; ein Leaderboard-Rang ist für diese Codebase kein Beleg.
- Aufgabe. Eine belastbare On-Premises-Messung, ob ein Kandidatenmodell die Edge Cases und das Injection-Vektor-Reasoning dieses Repositories beherrscht – reproduzierbar aus dem exakten Commit, innerhalb einer 32 GB-GPU, ohne Cloud-Abhängigkeit im Evaluierungspfad.
- Vorgehen. Den AST-Extraktor auf den fixierten Commit richten; Aufgaben synthetisieren, gebunden an die echten Signaturen und Imports des Repos; deterministisch bei Temperatur 0 unter fixiertem Single Stream laufen lassen; Latenz, Tokens und Finish-Reasons pro Aufgabe loggen.
- Ergebnis. Eine vollständige Evaluierung in unter fünf Minuten, komplett on-premises und aus (Commit, Extraktionsregeln) re-derivierbar – belastbar auch in einem Audit Monate später. Das Deliverable ist eine vertrauenswürdige, souveräne Messung plus eine präzise Anweisung für die nächste Iteration – keine Zahl auf Treu und Glauben.
Jenseits der zwei Grenzen.
- Eine andere Aufgabenfamilie. AST-synthetisierte Aufgaben sind strukturell sauberer als Issue-Resolution-Aufgaben („löse dieses GitHub-Issue, sodass seine versteckten Tests bestehen“) – die Pipeline ergänzt Issue-basierte Evaluierung, statt sie zu ersetzen, und ihre Schwierigkeitsobergrenze ist ein Grund für die Sättigung des Piloten.
- Ein Operator, eine Hardware. Die operativen Zahlen (Durchsatz, Latenz) tragen diese externe Validitätsgrenze unabhängig von der Capability-Frage – per Design ein C4-Thema.
- Identifikation ist nicht Exploitation. Die Kategorie security_audit bewertet derzeit Identifikation; ein Befund, der korrekt klingt, muss es nicht sein – genau deshalb ist die Reproduktionspflicht aus C2 für diese Kategorie tragend.
- Die Quantisierung ist der offene Vorbehalt. Q4_K_M erhält Oberflächen-Validität zuverlässiger als tiefes mehrschrittiges Reasoning – Korrektheit unter Low-Bit-Gewichten ist, was Execution Grounding bestätigen muss, nicht annehmen darf.