Ein Zwischenstand, kein Launch. In Teil 2 haben wir gelernt, dass nur gemessene Zahlen zählen. In Teil 3 ging es darum, wie wir messen. Seit ein paar Wochen trainieren wir minimal_patcher, einen kleinen LoRA-Adapter, der Code-Patches schreibt. Hier steht, was funktioniert hat, was nicht und wo wir uns selbst getäuscht haben.

1. Zuerst haben wir die Messung repariert

Unsere frühen Evals sahen gut aus, und genau das war das Problem. Das Harness prüfte Patches per Mustererkennung (Regex). Ein Patch konnte also richtig aussehen und sich trotzdem nicht anwenden lassen. Wir haben es an zwei Stellen umgebaut:

  • Echtes git apply. Ein Patch zählt nur, wenn er sich wirklich auf das Repository anwenden lässt.
  • Gelöst ≠ angewendet. Ein Patch, der sich anwenden lässt, ist noch kein Fix. Als gelöst zählt eine Aufgabe erst, wenn danach die Tests durchlaufen.

Mit dem strengeren Harness sind einige unserer früheren „grünen“ Ergebnisse verschwunden. Das tat weh, aber jetzt können wir den Zahlen trauen.

2. Schöne Diffs gegen richtige Diffs

Wir haben die Versionen v4 bis v6 auf Modal-A100s trainiert. Unter dem neuen Harness erzählten v4 und v5 eine klare Geschichte: Ihre Patches ließen sich oft sauber anwenden, aber sie lösten 0 Smoke-Tasks. Das Modell hatte gelernt, wie ein guter Diff aussieht, aber nicht, wie man den Bug behebt.

3. v6: Exact-Line-SFT

Für v6 haben wir das Trainingsformat geändert. Jedes Beispiel besteht jetzt aus zwei Schritten:

  1. LOCATE: die genauen Zeilen benennen, die sich ändern müssen.
  2. EDIT: nur diese Zeilen umschreiben.

Trainiert haben wir mit 350 Beispielen. Der Loss lag am Ende bei etwa 0,066, der Lauf kostete rund 6 $ GPU-Zeit.

Im Smoke-Test mit 2 Aufgaben hat v6 weiterhin 0 gelöst. Ein Ergebnis ist aber neu: Bei der Aufgabe flit deckte die Änderung des Modells zum ersten Mal alle Gold-Zeilen ab. Der richtige Fix steckte sogar vollständig in der Vorhersage. Gescheitert ist sie an einem Over-Edit: Zusätzlich zur richtigen Änderung hat das Modell ein continue in ein pass umgeschrieben, und diese eine Zeile zu viel hat die Tests kaputt gemacht.

Unsere Overlap-Metrik stand trotzdem bei 1,0, weil sie zusätzliche Zeilen nicht bestraft. Das ist die zweite Lektion zum Thema Messung in diesem Beitrag. Das Modell findet die Stelle und schreibt sogar den Fix, weiß aber noch nicht, wann es aufhören soll.

4. Kleiner Adapter, harte Eval, echtes Budget

Wir halten uns bewusst an ein paar Regeln:

  • Kleiner Adapter. LoRA statt großem Modell.
  • Harte Heldout-Eval. Bewertet wird auf Aufgaben, die der Adapter im Training nie gesehen hat, und die Tests entscheiden.
  • Knappes Budget. Ein Trainingslauf kostet einstellige Dollarbeträge, bezahlt aus Modal-Free-Credits.

Der Großteil des „KI-Coding“-Felds konkurriert über Größe. Wir wollen wissen, wie weit ein kleines Modell kommt, wenn ehrlich gemessen wird.

Wie es weitergeht

  • Decoding und Filter gegen Over-Edits: nur Änderungen an LOCATE-Zeilen behalten und den Kandidaten mit den wenigsten Änderungen bevorzugen. Nach dem flit-Ergebnis ist das der günstigste nächste Hebel.
  • Eine größere Eval mit 32 Aufgaben statt des Smoke-Tests mit 2 Aufgaben.
  • Eine Entscheidung über den Paper-Umfang bis 10. November für den Paper-Track „David vs. Goliath“.

Laborkontext für Neugierige: sidekick-serpentis, PR #13.

Kein Release, keine Leaderboard-Claims, noch nichts zum Herunterladen. Nur der aktuelle Stand der Arbeit. Wir melden uns, sobald die Zahlen aus der 32er-Eval da sind.

Fortsetzung folgt.