Hier anfangen¶

Das Problem in einer Geschichte¶

Ich betreibe ein kleines Skript, das jeden Morgen ein paar hundert KI-Artikel liest und ein Sprachmodell die fünf auswählen lässt, die sich zu lesen lohnen. Es funktionierte. Dann ließ es eines Tages die guten aus.

Nichts war abgestürzt. Kein Test war fehlgeschlagen. Der Code war derselbe wie in der Woche davor. Geändert hatte sich das Verhalten des Modells — hier eine kleine Änderung am Prompt, dort ein Modell-Update — und Verhalten ist nichts, was ein Unit-Test prüft. Das Skript gab weiterhin fünf Artikel zurück. Nur eben die falschen fünf.

Das ist eine LLM-Regression: Dein System läuft noch, antwortet noch, besteht noch seine Tests — und ist unbemerkt schlechter als vorher.

Warum deine Tests das nicht sehen¶

Normale Tests vergleichen eine Ausgabe mit einem erwarteten Wert. Ein Sprachmodell liefert keinen erwarteten Wert. Stelle ihm zweimal die gleiche Frage, und du bekommst möglicherweise zwei verschiedene Antworten, die beide in Ordnung sind. Also testen Teams das Verhalten des Modells entweder gar nicht mehr, oder sie schreiben einen Test, der heute besteht und dir über morgen nichts sagen kann.

Die praktischen Fragen lauten dann:

• Verglichen womit? Du brauchst eine Referenz — das Verhalten, das du zuletzt akzeptiert hast.
• Wie viel schlechter? Ein Wert, der von 0.88 auf 0.86 wandert, kann Rauschen sein. Von 0.88 auf 0.73 ist eine Regression. Ohne zu wissen, wie stark das System von sich aus schwankt, kannst du beides nicht unterscheiden.
• Wer entscheidet, was „richtig“ heißt, und wo ist diese Entscheidung festgehalten?

Was digline macht¶

digline ist ein gate, das du vor diese Frage stellst. Du schreibst einmal auf, was du von deinem System erwartest, und zwar als Satz von checks — deterministische (die Antwort ist gültiges JSON, enthält keine Telefonnummern, nennt den Namen des Kunden) und bewertete (ein zweites Modell beurteilt die Antwort anhand einer Rubrik). Du führst sie auf deinem System aus. Wenn dir das Ergebnis gefällt, gibst du es mit promote frei: Es wird zur baseline — eine Datei, die neben dem Code in dein Repository eingecheckt wird.

Von da an wird jeder run mit dieser baseline verglichen, und der Bericht beantwortet die einzige Frage, auf die es ankommt:

Nichts ist gegenüber der Referenz schlechter geworden. 2 checks haben sich innerhalb des Rauschens bewegt. Jeder Fall konnte bewertet werden. 1 Fall ist ausgesetzt. Die Suite ist gegenüber der Referenz unverändert. 1 getestete Datei hat sich seit der Referenz geändert.

oder

14 checks sind gegenüber der Referenz schlechter geworden. 7 Fälle konnten nicht bewertet werden. Kein Fall ist ausgesetzt. Die Suite ist gegenüber der Referenz unverändert. Die getesteten Dateien sind dieselben wie bei der Referenz.

Die baseline ist eine Datei in git. Sie hat eine Historie, sie lässt sich diffen, und niemand außer dir gibt sie frei. Es gibt kein Dashboard, in das man sich einloggen muss, und keinen Dienst, der deine Daten erhält — digline läuft dort, wo dein Code läuft.

Dreißig Sekunden, mit Bildern¶

Folge 1 einer kurzen Reihe über LLM-Regression. Ausgeliefert von dieser Seite — kein Player von Dritten, keine Cookies.

Wie es weitergeht¶

• Warum — die Überlegungen hinter dem Entwurf, falls du darüber streiten willst.
• Guide — installieren und in wenigen Minuten zum ersten compare kommen.
• digline im Vergleich — wenn du schon ein Eval-Tool nutzt und wissen willst, was anders ist.

Zehn Wörter, die dir unterwegs begegnen: run, baseline, compare, promote, check, judge, Toleranz, noise floor, Regression, gate. Jedes wird beim ersten Auftreten im Guide erklärt.