Wie man ein KI-Modell für ein reales Produkt auswählt

Die Modellauswahl wird meist als Rangfolgenproblem behandelt: das beste Modell finden und verwenden. Dieser Ansatz führt zu zwei vorhersehbaren Ergebnissen – einem teuren System, das einfache Arbeit verrichtet, oder einem billigen System, das auf ungetestete Weise versagt.

Ein besserer Ansatz ist Beschaffung. Erst die Rahmenbedingungen, dann die Vorauswahl, dann der Test. Die Rahmenbedingungen leisten den Großteil der Arbeit, und sie sind Eigenschaften Ihres Produkts, keine Meinungen über Modelle.

Die sechs Eigenschaften, die über die Eignung entscheiden

Qualität bei Ihrer Aufgabe. Nicht allgemeine Qualität. Ein Modell, das wunderschöne Prosa schreibt, kann bei der Extraktion strukturierter Felder schwach sein, und ein Modell, das mathematisch gut argumentiert, kann bei Klassifikationsaufgaben unnötig langsam sein. Allgemeine Ranglisten dienen als Vorauswahl dafür, welche Modelle man testet, nicht als Ersatz für den Test selbst.

Kosten pro Anfrage. Bepreist in Input- und Output-Tokens, multipliziert mit Ihrem tatsächlichen Traffic. Die entscheidende Zahl ist die monatliche Ausgabe beim prognostizierten Volumen, und es lohnt sich, sie vorher statt nachher zu berechnen. Zu beachten ist, dass Reasoning-Modelle ihre interne Überlegung als Output-Tokens abrechnen, sodass die effektiven Kosten pro abgeschlossener Aufgabe ein Vielfaches des angegebenen Satzes betragen können.

Latenz. Zwei Zahlen, nicht eine. Time to First Token bestimmt die gefühlte Reaktionsschnelligkeit in jeder Streaming-Oberfläche. Gesamte Generierungszeit bestimmt den Durchsatz bei Batch-Arbeiten. Ein interaktives Produkt kümmert sich meist stärker um Ersteres; eine nächtliche Pipeline nur um Letzteres.

Kontextfenster. Messen Sie Ihre tatsächliche Input-Verteilung beim 95. Perzentil. Die Auswahl nach einem seltenen Maximalwert bedeutet, bei jeder Anfrage für eine Kapazität zu zahlen, die Sie nur wenige Male im Monat nutzen.

Integrationsfähigkeiten. Zuverlässigkeit des Tool-Callings, schemakonforme Ausgaben, Streaming-Verhalten, Bild- oder Audio-Input, falls benötigt. Diese Eigenschaften unterscheiden sich zwischen Modellen weit stärker, als allgemeine Qualitätswerte vermuten lassen, und sie entscheiden häufig darüber, ob eine Integration überhaupt funktioniert, nicht nur wie gut.

Einsatz- und Datenbeschränkungen. Wo die Daten verarbeitet werden dürfen, welche Aufbewahrungsfristen gelten, ob ein regionaler Endpunkt existiert, ob das Modell in der eigenen Umgebung laufen kann. Diese Fragen werden oft außerhalb des Engineering-Teams entschieden, und sie scheiden Kandidaten unabhängig von allen anderen Eigenschaften aus.

An eigenen Fällen testen

Mit einer Vorauswahl von zwei oder drei Kandidaten wird die Entscheidung durch Tests getroffen, und der Test muss nicht aufwendig sein.

Nehmen Sie fünfzig reale Fälle aus Ihrem eigenen Traffic, lassen Sie jeden Kandidaten darauf laufen und vergleichen Sie fallweise statt im Durchschnitt. Der Durchschnitt sagt fast nichts aus; die interessante Information ist, bei welchen konkreten Fällen jedes Modell versagt und ob diese Fälle wichtig sind. Ein Modell, das insgesamt etwas schwächer ist, aber bei der teuren Kategorie nie versagt, ist die bessere Wahl, und kein aggregierter Wert wird Ihnen das verraten.

Zwei praktische Warnungen. Verwenden Sie im ersten Durchgang für jeden Kandidaten denselben Prompt, um eine faire Ausgangsbasis zu erhalten – wenden Sie dann, bevor Sie entscheiden, etwas Zeit auf, um den Prompt für den führenden Kandidaten zu optimieren, denn Modelle reagieren unterschiedlich, und ein für ein Modell optimierter Prompt kann ein anderes unterbewerten. Und messen Sie Latenz und Kosten im selben Durchlauf, damit alle drei Dimensionen aus einem Experiment stammen statt aus dreien.

Die meisten Anfragen brauchen nicht das stärkste Modell

Dies ist die Beobachtung mit der größten finanziellen Tragweite, und sie gilt für nahezu jedes Produkt.

Realer Traffic ist nicht gleichmäßig schwierig. Ein Support-Assistent beantwortet eine große Zahl von Routinefragen und eine kleine Zahl wirklich schwieriger. Eine Klassifikations-Pipeline sieht überwiegend eindeutige Fälle. Alles an das stärkste verfügbare Modell zu schicken bedeutet, für die einfachste Arbeit den Preis des schwierigsten Falls zu zahlen.

Das übliche Mittel dagegen ist Routing: Ein kleines, schnelles Modell übernimmt die Masse, mit Eskalation an ein größeres Modell, wenn ein Konfidenzsignal, eine Kategorie oder ein Validierungsfehler auf Schwierigkeit hindeutet. Die Ersparnis ist oft erheblich – im volumenstarken Bereich steckt das meiste Geld –, und die Qualitätsobergrenze bleibt für die Fälle erhalten, die sie brauchen.

Routing hat eigene Kosten: zwei Modelle zu evaluieren, eine Routing-Regel zu pflegen und einen neuen Fehlermodus, bei dem der Router einen schwierigen Fall an das kleine Modell schickt. Bei hohem Volumen lohnt es sich, unterhalb einer bestimmten Schwelle nicht. Diese Schwelle ist spezifisch für Ihren Traffic, und sie zu berechnen ist eine Sache von einem halben Tag.

Für den Wandel wählen

Was auch immer Sie wählen, wird abgelöst werden. Die in einem Jahr verfügbaren Modelle werden günstiger, schneller oder besser sein, und die Entscheidung, die Sie jetzt treffen, sollte sich nicht teuer revidieren lassen.

Drei Gewohnheiten halten diese Kosten niedrig. Behalten Sie Prompts, Tool-Definitionen und das Parsen der Ausgabe im eigenen Code, damit ein Anbieterwechsel eine Konfigurationsänderung ist statt einer Neuentwicklung. Behalten Sie das Eval-Set, denn es macht die Bewertung eines neuen Kandidaten zu einer Sache von einem Tag statt zu einem Projekt. Und fixieren Sie die Modellversion explizit, statt einem beweglichen Alias zu folgen, damit eine Verhaltensänderung etwas ist, das Sie planen, statt etwas, das Sie zufällig entdecken.

Der letzte Punkt verdient besondere Betonung. Ein System, das dem neuesten Alias eines Anbieters folgt, erbt automatisch jede Verhaltensänderung, einschließlich jener, die einen sorgfältig abgestimmten Prompt zerstören. Fixieren Sie die Version, führen Sie den Eval aus, wenn eine neue erscheint, und aktualisieren Sie bewusst.

Die kurze Methode

1. Schreiben Sie die fünf Rahmenbedingungen als Zahlen auf.
2. Filtern Sie Kandidaten, die sie erfüllen – meist zwei oder drei.
3. Lassen Sie fünfzig reale Fälle durch jeden laufen und messen Sie Qualität pro Fall, Latenz und Kosten gemeinsam.
4. Optimieren Sie den Prompt für den Favoriten und wiederholen Sie den Durchlauf.
5. Wählen Sie den günstigsten Kandidaten, der besteht, nicht den mit der höchsten Punktzahl.
6. Fixieren Sie die Version, behalten Sie das Eval-Set, und überprüfen Sie die Wahl, wenn etwas Neues erscheint.

Schritt fünf ist der Punkt, an dem das meiste Geld gespart wird, und es ist der Schritt, den viele überspringen, weil die Wahl des stärksten Modells sicherer erscheint als die Wahl des ausreichenden. Pro Anfrage, über ein Jahr gerechnet, ist das in der Regel nicht der Fall.