Ein feingetuntes Modell gegen das Modell testen, das es ersetzen soll

Abnahmekriterien vor dem ersten Ergebnis festlegen

Liegt ein Ergebnis erst auf dem Tisch, ist die Versuchung groß, einen Rückgang um zwei Punkte in einer Kategorie für unwichtig zu erklären. Legen Sie die Messlatte vorher mit dem Product Owner und der Fachperson fest, die mit dem Modell arbeiten wird. Für einen hypothetischen Ticket-Router, der ein gehostetes Frontier-Modell ablösen soll, könnten die Kriterien so lauten.

• Gesamt: Macro-F1 auf dem zurückgehaltenen Set nicht schlechter als beim aktuellen Modell
• Kritischer Ausschnitt: Recall bei rechtlichen Beschwerden mindestens so hoch wie beim aktuellen Modell, weil jede übersehene teuer ist
• Format: Jede Ausgabe lässt sich gegen das Routing-Schema parsen
• Latenz: p95 unter 800 Millisekunden im produktiven Serving-Setup
• Kosten: niedrigere Gesamtkosten pro 1.000 Anfragen, Serving und Betrieb eingerechnet

Jede Zeile nennt eine Metrik, einen Vergleich und einen Schwellenwert. Lässt sich eine Zeile nicht so genau formulieren, ist sich das Team noch nicht einig, was besser bedeutet.

Mit dem Setup vergleichen, das tatsächlich ersetzt würde

Die Fine-Tuning-Dokumentation von OpenAI, geschrieben für eine gehostete Plattform, die für neue Nutzer geschlossen ist, empfiehlt, vor dem Training Holdout-Daten abzutrennen und als Kontrollgruppe zu nutzen. Das Prinzip gilt für jedes Modell. Für das Geschäft zählt als Kontrolle nicht das ungetunte Basismodell, sondern das aktuelle Produktionssetup: dasselbe gehostete Modell, derselbe Prompt, dieselben Beispiele und dieselbe Nachverarbeitung wie heute. Wer eine schwache Vergleichsbasis schlägt, beweist wenig.

Geben Sie dem bisherigen Modell eine faire Chance. Wurde sein Prompt seit einem Jahr nicht angefasst, verbessern Sie ihn vor dem Vergleich. Lassen Sie beide Modelle durch dieselbe Testumgebung laufen, mit demselben Parsing und demselben Bewertungscode, damit Unterschiede von den Modellen kommen und nicht von der Infrastruktur drumherum.

Wie die zurückgehaltenen Fälle aussehen müssen

Das Vergleichsset darf keine Trainingsfälle und keine Beinahe-Kopien davon enthalten, und seine Aufteilung muss dem entsprechen, was auf das Modell zukommt: ein späterer Zeitraum bei wiederkehrender Arbeit, ungesehene Kunden oder Vorlagen, wenn solche hinzukommen werden. Wenn Sie seltene Fälle überrepräsentieren, um den kritischen Ausschnitt zu messen, weisen Sie diesen Ausschnitt getrennt aus oder gewichten Sie den Gesamtwert auf die Anteile in der Produktion zurück. Die Hinweise zu Hugging Face Evaluate empfehlen, 10 bis 30 Prozent eines Datensatzes für die Bewertung zurückzuhalten und das Testset so nah wie möglich an den Produktionsdaten auszurichten.

Kleine Unterschiede verlangen Sorgfalt, also vergleichen Sie die Modelle Fall für Fall. Angenommen, in einem hypothetischen Set von 600 Tickets liegt der Kandidat bei 31 Fällen richtig, bei denen das bisherige Modell falsch liegt, und bei 19 falsch, bei denen das bisherige Modell richtig liegt. Der Nettogewinn beträgt 12 Fälle oder 2 Prozent, und ein gepaarter Test wie der McNemar-Test zeigt, ob das über das Rauschen hinausgeht. Lesen Sie die 19 Verschlechterungen einzeln, denn ein schwerer Fehler kann den Nettogewinn aufwiegen.

So bewerten, wie die Entscheidung fällt

Genauigkeit verdeckt Fehler bei seltenen Klassen. Nutzen Sie bei unausgewogenen Klassen Precision und Recall pro Klasse oder F1 und bewerten Sie Extraktion Feld für Feld. Für Freitext empfiehlt der Evaluierungsleitfaden von OpenAI, Metriken mit menschlichem Urteil zu kombinieren und einem Modell als Bewerter erst zu vertrauen, wenn seine Noten mit den Labels Ihrer Fachleute übereinstimmen.

Für Ausgaben, die sich schlecht automatisch bewerten lassen, eignet sich ein blinder Paarvergleich: Eine Fachperson sieht zwei Antworten auf denselben Fall, ohne zu wissen, welches Modell welche geschrieben hat, und wählt die bessere oder vermerkt einen Gleichstand.

Kosten und Latenz in dieselbe Tabelle wie die Qualität

Die Evaluierungshinweise von Hugging Face benennen den Zielkonflikt klar: Ein etwas weniger genaues Modell kann die bessere Wahl sein, wenn es schneller ist und weniger Hardware braucht. Messen Sie die Latenz in dem Serving-Setup, das Sie betreiben würden, unter realistischer Last, und ermitteln Sie die Kosten pro Anfrage aus der vollständigen Rechnung, einschließlich ungenutzter GPU-Stunden, des gehosteten Fallbacks und des Nachtrainings. Die folgende Auswertung ist hypothetisch und geht von 1,5 Millionen Anfragen pro Monat aus, von einer dedizierten GPU, die für das feingetunte Modell rund um die Uhr läuft, und vom aktuellen Tokenpreis des gehosteten Modells.

• Aktuelles gehostetes Modell: Macro-F1 0,86, Recall bei rechtlichen Beschwerden 0,91, p95 1,6 s, 4,10 € pro 1.000 Anfragen
• Feingetuntes 8B-Modell: Macro-F1 0,88, Recall bei rechtlichen Beschwerden 0,89, p95 0,5 s, 1,30 € pro 1.000 Anfragen

Nach den obigen Kriterien fällt dieser Kandidat durch. Er ist günstiger und schneller, aber der Recall bei rechtlichen Beschwerden ist gesunken, und diese Zeile war als harte Anforderung vereinbart. Der nächste Schritt sind mehr gelabelte rechtliche Beschwerden und ein neuer Lauf, keine Debatte darüber, ob zwei Punkte wichtig sind.

Vom bestandenen Test in die Produktion

Ein bestandener Test auf zurückgehaltenen Daten ist ein Offline-Ergebnis. Lassen Sie den Kandidaten vor dem Wechsel im Schattenbetrieb auf Live-Traffic mitlaufen, während das aktuelle Modell weiter antwortet, und vergleichen Sie die Entscheidungen. Die Hinweise von Hugging Face unterscheiden Offline-Evaluierung vor dem Deployment und Online-Evaluierung auf Produktionsdaten, und ein Modellwechsel braucht beides.

Die Methode wird schwächer, wo die tatsächlichen Ergebnisse erst Monate später oder nie eintreffen, und bei offenen Aufgaben ohne feste Antwort. Dort hat das blinde Urteil von Fachleuten mehr Gewicht, und die Stichprobe muss größer sein. Behalten Sie das gehostete Modell als Fallback, bis die Online-Zahlen mit den Offline-Zahlen übereinstimmen.