Modellwahl: das billigste Modell, das den Boden hält

Die Frage kommt als Einzeiler: „Modell X kostet ein Drittel. Können wir wechseln?“ Es gibt drei schlechte Antworten darauf. Erstens: auf ein Leaderboard zeigen. Das misst die Aufgabe von jemand anderem. Zweitens: die eigenen hundert Fälle einmal laufen lassen, zwei Prozentzahlen ablesen und die höhere nehmen. Drittens: in der Produktion umschalten und auf die Tickets warten.

Dieses Kapitel ist der vierte Weg. Nichts darin ist neu. Jeder Baustein steht schon in diesem Leitfaden. Aber bei der Modellfrage müssen die Bausteine zusammenspielen. Und sie ist die Entscheidung, für die Teams ihre Eval-Sets am häufigsten wirklich nutzen. Der Reihe nach:

1. Rechnen Sie aus, was der Wechsel höchstens sparen kann. Ist das wenig, hören Sie hier auf.
2. Legen Sie vorher fest, wie viel schlechter das neue Modell sein darf.
3. Lassen Sie beide Modelle über Ihre Fälle laufen. Lesen Sie die Fehler des neuen Modells, bevor Sie seinen Wert lesen.
4. Prüfen Sie die Böden: die Prüfungen, die kein Rauschen erlauben.
5. Schlüsseln Sie das Ergebnis nach Art der Anfrage auf.
6. Prüfen Sie den Judge an den Antworten des neuen Modells nach.
7. Sammeln Sie genug Fälle für die Entscheidung. Dann entscheiden Sie.
8. Zählen Sie Kosten pro Anfrage, nicht pro Token.

Das ganze Kapitel folgt einem Fall. Alles darin ist erfunden, wie im durchgerechneten Beispiel. Es ist dieselbe Firma wie dort, aber ein anderes Feature: der Assistent im Produkt. Er beantwortet Planern Fragen zu Dienstplanregeln, etwa: „Darf Meier am Freitag die Nachtschicht übernehmen, wenn er Donnerstag gearbeitet hat?“ Die Antwort kommt aus dem Regelwerk des Kunden plus der Doku.

Zuerst: Was der Wechsel überhaupt wert ist

Bevor Sie irgendetwas laufen lassen, rechnen Sie aus, was der Wechsel höchstens sparen kann. Angenommen, der Kandidat ersetzt das aktuelle Modell ohne jeden Verlust. Dann sinken die Kosten von 6.800 € auf etwa 2.300 €. Das sind 4.500 € im Monat. Dafür lohnt sich eine Woche Arbeit.

Machen Sie diesen Schritt, denn er beendet die Übung oft. Der Entwurfsassistent aus dem durchgerechneten Beispiel bearbeitet 2.800 Entwürfe im Monat. Derselbe Wechsel spart dort unter 10 €. Die Woche lohnt sich nicht. Ihr erstes Eval in einer Woche nennt die Fälle, in denen Evals sich nicht lohnen. Ein Modellwechsel, der weniger spart, als die Bewertung kostet, gehört dazu.

Die Frage heißt „nicht schlechter“, nicht „besser“

Sie wollen nicht zeigen, dass der Kandidat besser ist. Sie wollen zeigen, dass er nicht um mehr schlechter ist als einen vorher festgelegten Betrag. Legen Sie diesen Betrag fest, bevor Sie eine einzige Zahl sehen. Wie viel Qualität würden Sie für die Ersparnis hergeben? Zwei Punkte? Fünf? Statistiker nennen das die Nicht-Unterlegenheitsmarge. Die einfache Frage lautet: „Wie viel schlechter darf es sein?“ Das ist eine Produktentscheidung, keine statistische.

Befund: Das ist ein Standardproblem klinischer Studien. Dort muss eine billigere oder verträglichere Behandlung zeigen, dass sie nicht schlechter ist als die etablierte. Walker und Nowacki definieren die Marge als „the maximum clinically acceptable difference that one is willing to accept in return for the secondary benefits of the new therapy“. Sie zeigen außerdem: Die Stichprobengröße hängt weit stärker an der Marge als bei einem Überlegenheitsnachweis. In ihrem Beispiel verdoppelte sich das nötige n beinahe, als die Marge von 12 auf 8 Prozentpunkte schrumpfte.

Quelle: Walker & Nowacki, Understanding Equivalence and Noninferiority Testing, J Gen Intern Med 26(2), 2011 · DOI 10.1007/s11606-010-1513-8

Der Test selbst ist der gepaarte Vergleich aus Statistik: beide Modelle auf denselben Fällen, Fall für Fall verglichen. Zählen Sie die Fälle, die nur das alte Modell bestanden hat. Zählen Sie die Fälle, die nur das neue Modell bestanden hat. Die Differenz ist der Verlust. Dazu kommt das Rauschen, also der Teil des Verlusts, der Zufall sein könnte. Dann prüfen Sie, ob Verlust plus Rauschen unter der Marge bleibt. Für eine Marge von 5 Punkten:

verlust   = (nur alt bestanden − nur neu bestanden) / n
rauschen  = 1,96 × Wurzel(nur alt + nur neu) / n
besteht, wenn  verlust + rauschen ≤ 0,05

Zwei Dinge folgen daraus. Erstens muss die Marge vorher aufgeschrieben sein. Sobald die Zahlen da sind, wandert sie dorthin, wo die Zahlen gelandet sind. Zweitens braucht dieser Test mehr Fälle als ein Vergleich nach dem Motto „welches ist besser“. Sie wollen einen kleinen Unterschied festnageln, nicht einen großen entdecken. Modell-Benchmarks richtig lesen sagt: Hundert Fälle gegen vier Modelle sind ein Nachmittag. Das stimmt, solange Sie Modelle ausschließen wollen. Um einen knappen Fall auf wenige Punkte genau zu bestätigen, reicht das bei weitem nicht. Der Fall unten zeigt, um wie viel.

Erst die Fehler des Kandidaten lesen, dann seinen Wert

Das Team ließ beide Modelle mit demselben Prompt über die 200 Fälle laufen. Das aktuelle Modell bestand 152 (76 %), der Kandidat 131 (65,5 %). Bei dieser Zahl hören die meisten Teams auf.

Das Team las stattdessen alle 69 Fehlschläge des Kandidaten. Es ging so vor, wie Fehleranalyse Traces liest: ein Satz je Fall, nur der erste Fehler, keine Kategorien. Zwei Arten von Fehlern waren vorher nie aufgetaucht:

Deshalb täuscht der Wert allein: Ihr Eval-Set beschreibt die Fehler des alten Modells. Es wurde aus dessen Traces gebaut. Sein Judge wurde an dessen Antworten eingestellt. Seine Fälle wurden um dessen Schwachstellen herum gewählt. Ein anderes Modell scheitert anders. Oft scheitert es in Fehlerarten, zu denen das Set gar keine Fälle hat. Solange Sie seine Fehler nicht gelesen haben, sagt sein Wert nur eines: wie gut es die Probleme des alten Modells löst.

Dann sortieren Sie die neuen Fehler so, wie Tag 2 es tut: Was ist ein Bug, was ist das Modell? Der Fließtext vor dem JSON verschwand durch zwei Änderungen: den Structured-Output-Modus des Anbieters und eine Zeile in der Formatanweisung. Beides änderte das Team am Entwicklungsset, nie am Testset (Datensatz-Design erklärt die beiden). Neuer Lauf: 143 von 200. Die erfundenen Regelabschnitte blieben. Das ist das Modell.

Erst Böden, dann Teilmengen

Ein Boden ist eine Prüfung ohne Rauschen: die deterministischen Prüfungen und die benannten Vorfall-Fälle. Evals in der CI erklärt, warum sie keine Fehlerspanne bekommen. Ein Fall, der gestern bestanden hat und heute nicht, ist ein Vorfall, kein Zufall. Ein Kandidat muss dieselben Böden halten wie ein Release. Reißt er sie, ist er raus, bevor jemand eine Statistik rechnet.

Der Kandidat hielt die Mandantenprüfung (0 von 200, wie das aktuelle Modell). Nach der Formatkorrektur hielt er auch die Schemaprüfung. Die Zitatprüfung hielt er nicht: 6 von 200 Antworten zitierten Abschnitte, die es nicht gibt. Beim aktuellen Modell waren es 0. Und nichts in der Produktion würde das heute abfangen. Von den 52 benannten Vorfall-Fällen bestand er 46, das aktuelle Modell 50.

Als schlichter Ersatz für den gesamten Verkehr ist der Kandidat damit raus. Die meisten Teams würden hier aufhören, und das ist vertretbar. Das Team ging einen Schritt weiter und schlüsselte auf. Es teilte das Ergebnis nach Art der Anfrage, so wie das Judge-Kapitel es mit seinen 22 % tut:

Der Einbruch liegt vollständig in einer Zeile. Dort liegen auch alle sechs erfundenen Abschnitte. Beim schlichten Nachschlagen liegt der Kandidat zwei Fälle hinter dem aktuellen Modell. Diese Zeile ist mehr als die Hälfte des Verkehrs. Die Integrationszeile sieht nach einem Sieg des Kandidaten aus. Aber bei 40 Fällen sind vier Fälle Rauschen, und so behandelte das Team sie auch.

Diese Form ist zu erwarten. Ein billigeres Modell scheitert selten gleichmäßig. Es hält bei den Routineanfragen und bricht bei den schweren ein. Der Gesamtwert mittelt beides zu einer Zahl, die über beides falsch ist.

Der Judge wurde am alten Modell eingestellt

Die Supportleitung labelte 60 Antworten des Kandidaten zum Nachschlagen, bestanden oder nicht bestanden. Sie ging so vor, wie Tag 4 es beschreibt. 19 davon waren echte Fehler. Der Judge fand 15 der 19. Von den 41 guten Antworten ließ er 38 durch. Bei den Antworten des aktuellen Modells hatte er 23 von 28 gefunden. Das ist ungefähr gleich. Beide Zahlen tragen aber die breite Spanne, die 19 und 28 Fehler mit sich bringen. Die vier verpassten Fälle zeigten kein Muster, das an Länge oder Format hing.

Warum dieser Nachmittag nötig war: Die Trefferquote des Judges wurde an den Antworten des aktuellen Modells gemessen. Die Trefferquote sagt, wie viele echte Fehler er findet. Der Kandidat schreibt anders, hier kürzer und anders formatiert. Allein der Längen-Bias kann die Urteile eines Judges zwischen zwei gleich korrekten Modellen verschieben. Wären alle vier verpassten Fälle kurze Antworten gewesen, wäre der Judge für diesen Vergleich unbrauchbar. Und wäre der Kandidat zugleich das Judge-Modell, kämen die Befunde zur Selbstbevorzugung obendrauf. Dasselbe gilt, wenn das aktuelle Modell der Judge ist.

Lassen Sie diesen Schritt aus, dann hat jeder folgende Judge-Wert zum Kandidaten ein unbekanntes Vorzeichen.

Genug Fälle für die Entscheidung

Jetzt der Test aus dem zweiten Abschnitt. Er läuft auf der Zeile „Regel nachschlagen“, denn dorthin könnte der Kandidat gehen. Die Marge stand vor dem Lauf fest: 5 Punkte. Der Grund stand daneben: Die Antwort zeigt die zitierte Regel, und der Planer liest sie, bevor er handelt. Ein falsches Nachschlagen kostet also einen Klick, keine Schicht.

Neunzig Fälle können das nicht entscheiden. Auf 90 Fällen lagen die beiden Modelle zwei Fälle auseinander. Allein das Rauschen betrug rund 8 Punkte, mehr als die ganze Marge. Also zog das Team 300 frische Nachschlage-Traces, die das Eval-Set nie enthalten hatte. Es ließ beide Modelle mit dem angepassten Prompt laufen und bewertete mit dem nachgeprüften Judge. Das aktuelle Modell bestand 231 der 300, der Kandidat 227. Fall für Fall: 17 Fälle bestand nur das aktuelle Modell, 13 nur der Kandidat. Das ist ein Unterschied von vier Fällen auf 300.

verlust   = (17 − 13) / 300              = 0,013   →  1,3 Punkte
rauschen  = 1,96 × Wurzel(17 + 13) / 300 = 0,036   →  3,6 Punkte

verlust + rauschen = 4,9 Punkte  ≤  5    →  nicht schlechter, als die Marge erlaubt

Gerade so. Bei einer Marge von 3 Punkten hätte dasselbe Ergebnis rund 1.400 Fälle gebraucht. Die Marge bestimmt die Rechnung. Deshalb wird sie zuerst aufgeschrieben, und zwar von der Produktverantwortung, nicht von der Person, die die Zahlen fährt.

Kosten pro Anfrage, nicht pro Token

Die Preisliste sagte ein Drittel. Das Harness zeichnet Tokens je Fall auf. Also konnte das Team nachrechnen:

Der Kandidat schreibt auch nach der Formatkorrektur längere Antworten. Je Anfrage kostet er deshalb 40 % des aktuellen Modells, nicht ein Drittel. Bei Agenten ist die Lücke meist größer. Ein billigeres Modell braucht je Aufgabe vielleicht zwei Schritte oder einen Wiederholungsversuch mehr. Dann kann es je Aufgabe teurer sein als das teure. Zählen Sie Tokens, Wiederholungen, Schritte und Wanduhrzeit je Fall. Das Harness hat sie schon.

Für diesen Fall: 0,23 Cent gespart auf 55 % von 60.000 Anfragen am Tag sind etwa 76 € am Tag, rund 2.300 € im Monat. Das ist die Hälfte der Obergrenze aus dem ersten Abschnitt, weil die Hälfte des Verkehrs bleibt, wo sie ist.

Routing: Die Teilmengen-Tabelle ist die Routing-Tabelle

Das Ergebnis heißt nicht „wechseln“ oder „nicht wechseln“. Es heißt: Nachschlagen zum Kandidaten schicken, Konfliktauflösung beim aktuellen Modell lassen. Die Tabelle mit den drei Zeilen ist diese Routing-Tabelle. Es gibt sie nur, weil jeder Fall die Art der Anfrage als Metadatum mitführte. Datensatz-Design sagt: Hängen Sie das vom ersten Tag an dran.

Befund: Kaskaden und Router sind ein untersuchter Weg, den größten Teil der Qualität eines starken Modells zu einem Bruchteil seiner Kosten zu bekommen. FrugalGPT (2023) lernt „which combinations of LLMs to use for different queries“. Es berichtet, die Leistung des besten Einzelmodells „with up to 98% cost reduction“ auf seinen Aufgaben zu erreichen oder es bei gleichen Kosten um 4 % zu übertreffen. RouteLLM (2024) trainiert Router auf menschlichen Präferenzdaten. Es berichtet Kostensenkungen „by over 2 times in certain cases — without compromising the quality of responses“. Beide Zahlen gelten auf den Benchmarks der Aufsätze, nicht auf Ihrem Verkehr. Die Technik überträgt sich, die Zahlen nicht.

Quelle: FrugalGPT, Chen, Zaharia & Zou, 2023 · RouteLLM, Ong et al., 2024

Zwei Dinge am Routing entdecken Teams spät. Der Router ist eine Komponente mit eigener Fehlerquote. Irgendetwas muss entscheiden, welche Anfragen Nachschlagen sind. Ist das ein Klassifikator oder ein kleiner Modellaufruf, schickt er einige Konfliktfragen zum billigen Modell. Das ist genau die Zeile, in der es schlecht ist. Messen Sie den Router wie jede andere Komponente. Lassen Sie das Ende-zu-Ende-Eval mit eingeschaltetem Routing laufen, denn das ist das System, das die Nutzer bekommen. Hier war der Router ein kleiner Modellaufruf für etwa 0,02 Cent je Anfrage. Das sind rund 360 € im Monat weniger Ersparnis.

Eine Kaskade braucht einen Prüfer, dem Sie schon trauen. Das billigste Muster von FrugalGPT versucht erst das billige Modell. Ist ein Prüfer unsicher, eskaliert es zum teuren. Dieser Prüfer ist ein Judge im Anfragepfad, und das macht ihn zu einem Guardrail. Ein Guardrail ist auf Precision getrimmt, wie Online-Evaluation erklärt. Er ist nicht der Judge, mit dem Sie messen. Setzen Sie keinen unvalidierten Judge in den heißen Pfad, um am Modell dahinter zu sparen.

Gleicher Prompt oder angepasster Prompt?

Umstritten: Ob man Modelle mit demselben Prompt vergleicht oder jedem einen eigenen, angepassten Prompt gibt. Derselbe Prompt misst den schlichten Ersatz. Das ist die Frage, die die meisten Teams tatsächlich stellen. Aber er benachteiligt den Kandidaten, denn der Prompt wurde monatelang am aktuellen Modell iteriert. Angepasste Prompts messen das Potenzial. Aber die Anpassung ist eine Optimierung gegen Ihr Eval-Set und muss am Entwicklungsset bleiben. Der Delimiter-Befund macht die Wahl wichtiger, als sie aussieht. Die tragfähige Regel: Vergleichen Sie erst als schlichten Ersatz. Scheitert der Kandidat knapp, passen Sie am Entwicklungsset an und entscheiden am Testset. Und sagen Sie beim Berichten, welches von beiden Sie gemessen haben.

Die Antwort hat eine Halbwertszeit

Das Ergebnis des Teams: 55 % des Verkehrs zum Kandidaten, netto rund 1.900 € im Monat gespart. Es gilt für zwei festgenagelte Modellversionen, einen Prompt-Hash und eine Preisliste. Alle drei ändern sich. Anbieter liefern neue Snapshots aus. Billige Modelle werden auf schweren Zeilen besser. Preise bewegen sich.

Die Modellentscheidung ist deshalb kein Dokument. Sie ist ein Eval-Lauf mit beiden Modellen im Harness, festgenagelt. Ein Pull Request kann ihn erneut ausführen, sobald sich eines der drei bewegt. Die Routing-Tabelle liegt in der Konfiguration neben den festgenagelten Versionen. Abgeschlossen wird die Entscheidung so, wie Online-Evaluation es beschreibt. Erst kommt ein Shadow-Betrieb: Das neue Modell beantwortet echte Anfragen, ohne dass jemand die Antworten sieht. Dann kommt ein A/B-Test auf der gerouteten Zeile mit einer Produktmetrik, etwa Rückfragequote, Daumen oder Eskalation. Der Eval-Wert ist nur ein Stellvertreter. Hier zeigt sich, ob er mitgelaufen ist.

Häufiger Fehler: Einen Modellwechsel am Gesamtwert des bestehenden Eval-Sets entscheiden. Dieses Set misst die Fehlermodi des alten Modells. Sein Judge wurde an den Antworten des alten Modells eingestellt. Seine gut hundert Fälle können einen Kandidaten ausschließen, aber nicht bestätigen. Lesen Sie die Fehler des Kandidaten, schlüsseln Sie auf, prüfen Sie den Judge nach, legen Sie die Marge zuerst fest und zählen Sie die Kosten je Anfrage. In dieser Reihenfolge.