Die Modellauswahl beginnt meist mit der falschen Frage. Ein Team fragt, welches Modell das beste sei, schaut auf ein öffentliches Leaderboard und nimmt das, was diesen Monat oben steht. Das Problem: Dieses Leaderboard wurde nicht an Ihrer Aufgabe gemessen. Es kennt weder Ihre Geschäftsberichte noch Ihre Abstimmungsregeln, noch was Sie eine falsche Antwort zum Quartalsende kostet.
Deshalb setzen wir an anderer Stelle an. Beschreiben Sie die Aufgabe in klaren Worten und bauen Sie daraus ein kleines Eval-Set aus echten Beispielen. Fünfzig oder hundert Fälle reichen oft schon aus, um aussagekräftig zu sein: der Input, die Antwort, die Sie akzeptieren würden, und die Antworten, die Sie ablehnen würden. Gegen dieses Eval-Set optimieren Sie tatsächlich. Sobald es existiert, wird die Modellauswahl zu einem Experiment, das Sie durchführen können, statt zu einer Meinung, die Sie verteidigen müssen.
Was das Eval-Set Ihnen sagt, ein Leaderboard aber nicht
Ein Leaderboard meldet einen Durchschnitt über Aufgaben, die nicht die Ihren sind. Ihr Eval-Set zeigt, wie ein Modell bei der Extraktion aus Ihren chaotischen PDF-Geschäftsberichten abschneidet oder bei der Entitätsauflösung über die Anbieter, mit denen Sie tatsächlich arbeiten. Das sind verschiedene Fragen, und sie haben oft verschiedene Gewinner.
Das Eval-Set deckt zudem die Fehler auf, die im Finanzbereich zählen und sonst nirgends. Ein Modell, das bei allgemeinen Benchmarks gut abschneidet, kann trotzdem einen Reason Code halluzinieren, ein Restatement übersehen oder klammheimlich einen Wert auslesen, den es zum betreffenden Stichtag gar nicht gab. Das sehen Sie nur, wenn Ihr Eval-Set Fälle enthält, die genau darauf abzielen. Ein generischer Benchmark tut das nie.
Führen Sie den Vergleich einmal durch, und Sie stellen meist fest, dass das Ranking ein anderes ist als vom Leaderboard suggeriert. Manchmal liegt ein günstigeres Modell bei Ihrer Aufgabe nur einen Punkt hinter dem Frontier-Modell. Manchmal ist der Abstand groß, und auch das wissen Sie nun.
Die Kompromisse, die Sie tatsächlich einkaufen
Die Entscheidung zwischen Open-Weight- und Frontier-Modellen dreht sich selten allein um die reine Qualität. Sobald einige Modelle Ihre Eval-Schwelle überspringen, verlagert sich die Wahl auf vier Aspekte:
- Kosten. Ein Frontier-API-Preis pro Token, der in einer Demo trivial wirkt, wird real, sobald Sie jeden Geschäftsbericht eines gesamten Coverage-Universums verarbeiten. LLM-Kosten und -Latenz bewegen sich tendenziell gemeinsam, und beide skalieren mit dem Volumen auf eine Weise, die ein Prototyp verschleiert.
- Latenz. Ein interaktives Analystentool und ein nächtlicher Batch-Job haben völlig unterschiedliche Toleranzen. Ein Modell, das für eine Chat-Oberfläche zu langsam ist, kann für einen Job, der läuft, während alle schlafen, vollkommen ausreichen.
- Kontextlänge. Manche Workloads brauchen einen kompletten 10-K auf einmal im Kontextfenster; andere fahren mit Retrieval über ein langes Dokument besser als mit einem Modell, das vorgibt, das Ganze in einem Rutsch zu schlucken.
- Datenresidenz. Wenn die Daten eine Jurisdiktion oder ein privates Netzwerk nicht verlassen dürfen, kommt eine gehostete Frontier-API womöglich nicht in Frage, egal wie gut sie abschneidet. Ein Open-Weight-Modell, das Sie on-prem betreiben, hält sensible Datensätze innerhalb Ihrer eigenen Grenzen, und das ist mitunter die entscheidende Randbedingung, noch bevor Qualität überhaupt zur Sprache kommt.
Genau hier kann ein kleines, feinjustiertes oder offenes Modell eine Frontier-API schlicht ausstechen. Bei einer engen, repetitiven Aufgabe erreicht ein kleineres, auf Ihren Beispielen trainiertes Modell in Ihrem Eval-Set oft das große, läuft schneller, kostet weniger pro Aufruf und kann auf Hardware sitzen, die Sie selbst kontrollieren. Universalität lohnt sich nicht zu bezahlen, wenn die Aufgabe nicht universell ist.
Lock-in und das Problem der stillen Updates
Eine Frontier-API ist ein bewegliches Ziel. Der Anbieter kann das Modell hinter demselben Endpoint austauschen, und Ihre Eval-Werte können sich verschieben, ohne dass sich eine einzige Zeile Ihres Codes ändert. Für ein System, das einen Prüfpfad erzeugt, ist das ein echtes Risiko: Das Modell, das im letzten Quartal einen Adverse-Action-Bescheid generiert hat, ist womöglich nicht dasselbe, das heute antwortet, und Sie haben unter Umständen keinen Nachweis über den Wechsel. Das Pinnen von Versionen hilft dort, wo der Anbieter es ermöglicht. Der kontinuierliche Einsatz Ihres Eval-Sets hilft mehr, denn er verwandelt ein stilles Update in eine sichtbare Regression, die Sie erkennen und auf die Sie reagieren können.
Open Weights beseitigen genau dieses Risiko. Das Modell ändert sich nicht, es sei denn, Sie ändern es, und Sie können ein früheres Ergebnis exakt reproduzieren. Diese Reproduzierbarkeit hat ihren eigenen Preis bei Hosting und Wartung, sie ist also ein Kompromiss und kein geschenkter Vorteil. Wir wägen das von Fall zu Fall ab.
Verteilen Sie die Arbeit, statt einen einzigen Sieger zu küren
Es gibt selten ein einziges bestes Modell für eine ganze Pipeline, und Sie müssen sich auch nicht auf eines festlegen. Verschiedene Teilaufgaben haben verschiedene Anforderungen. Ein günstiges, schnelles Modell kann Klassifikation oder Extraktion in hohem Volumen übernehmen; ein stärkeres Modell kann die schwierigeren Reasoning-Schritte stemmen; ein selbst gehostetes Modell kann die Datensätze verarbeiten, die das Haus nicht verlassen dürfen. Jeder Abschnitt erhält das Modell, das seinen eigenen Ausschnitt des Eval-Sets gewinnt.
Ein solches Routing bedeutet mehr bewegliche Teile, die gewartet werden müssen, und wir setzen es nur dort ein, wo das Eval-Set zeigt, dass es sich rechnet. Doch so sieht ein reales System am Ende meist aus, denn die Alternative besteht darin, ein Frontier-Modell teuer dafür zu bezahlen, Arbeit zu erledigen, die ein kleineres genauso gut leistet.
Die Methode ist der Punkt. Beginnen Sie bei der Aufgabe, messen Sie an Daten, die aussehen wie der Produktivbetrieb, und lassen Sie das Eval-Set entscheiden. Das Leaderboard ist der Benchmark von jemand anderem. Ihrer ist der einzige, der Ihre Rechnungen bezahlt.