«Welches ist das beste Modell?» fragt, wer noch keinen gebaut hat
Das Gespräch beginnt immer gleich. Jemand öffnet eine Rangliste, zeigt auf Platz eins und fragt, ob wir den Agenten damit bauen. Berechtigte Frage, und sie ist falsch gestellt, denn sie setzt voraus, dass ein Agent ein Modell nutzt. Agenten, die Produktion aushalten, nutzen nicht eines: Sie nutzen mehrere. Und die Entscheidung, auf die es ankommt, ist nicht welches, sondern die Verteilung.
Der Grund ist architektonisch und langweilig. Ein Agent macht keine Aufgabe: Er macht eine Kette. Er liest eine E-Mail und erkennt, worum es geht. Er sucht in deiner Dokumentation und zieht drei Passagen heraus. Er formuliert eine Antwort, die einer deiner Kunden lesen wird. Er entscheidet, ob das allein rausgeht oder über einen Menschen läuft. Vier Schritte, vier verschiedene Anforderungen: Eine E-Mail in sechs Kategorien einzusortieren ist seit Jahren gelöst; zu formulieren, was dein Kunde liest, ist der Moment, in dem dein Gesicht auf dem Spiel steht. Für alle vier das teuerste Modell zu bezahlen heißt, deinen besten Anwalt zum Fotokopieren zu schicken.
Das ist nicht unsere Meinung. OpenAIs Leitfaden zum Bau von Agenten sagt es unverblümt: Modelle haben unterschiedliche Stärken und Kompromisse bei Aufgabenkomplexität, Latenz und Kosten, und nicht jede Aufgabe braucht das klügste Modell. Ihr Beispiel ist genau das von oben: Eine einfache Recherche oder eine Intent-Klassifikation kann ein kleineres, schnelleres Modell erledigen, während die Entscheidung über eine Rückerstattung von einem leistungsfähigeren profitiert. Und sie empfehlen, für verschiedene Aufgaben desselben Ablaufs verschiedene Modelle zu erwägen statt eines für alles. Quelle: A practical guide to building agents, OpenAI, abgerufen am 12. September 2026.
In dieser Anleitung geht es darum, diese Entscheidung mit Absicht zu treffen: die drei Achsen, die wirklich entscheiden, die Reihenfolge, in der man sie abgeht, wie die Verteilung aussieht und welche Schicht du brauchst, damit ein Modellwechsel kein Umbau wird. Was sie nicht ist: eine Tabelle der «besten LLMs 2026» — die ist abgelaufen, bevor wir sie veröffentlichen — und auch nicht die Rechnung für KI im Betrieb, das ist ein anderes Gespräch mit anderen Zahlen.
Die drei Achsen, die wirklich entscheiden
Nimmt man den Lärm weg, steht die Wahl auf drei Fragen. Keine der drei beantwortet man, indem man das Datenblatt des Modells liest: Alle drei beantwortet man, indem man bei sich misst.
| Achse | Die Frage dahinter | Wie du sie bei dir misst |
|---|---|---|
| Trefferquote auf deiner Aufgabe | Wie viele meiner echten Fälle löst es richtig? | Eine Sammlung von 30-50 eigenen Fällen mit der richtigen Antwort daneben |
| Latenz | Hält es in dem Kanal, in dem der Agent lebt? | Das 95. Perzentil der Antwortzeit, niemals der Mittelwert |
| Kosten pro gelöstem Fall | Was kostet es, einen Fall von Anfang bis Ende zu lösen? | Kosten des gesamten Ablaufs geteilt durch gelöste Fälle, nicht Preis pro Million Token |
Die Trefferquote ist die Achse, die die meisten überspringen, weil sie Arbeit macht. «Trefferquote» ist keine allgemeine Note: Es ist der Prozentsatz DEINER Fälle, die richtig herauskommen. Dafür braucht es den langweiligen Teil — dreißig oder fünfzig echte Fälle, echte E-Mails mit ihren Tippfehlern und ihren seltsamen Anhängen, mit der richtigen Antwort daneben. Ohne diese Sammlung wählst du kein Modell aus: Du hast eine Meinung über Modelle, und die hält keiner Besprechung stand.
Latenz ist keine absolute Zahl: Sie ist eine Zahl gegen einen Kanal. Ein Chat auf deiner Website hat ein Budget von Sekunden, weil jemand auf den Bildschirm schaut. Ein nächtlicher Lauf, der Rechnungen abgleicht, hat die ganze Nacht. Dasselbe Modell ist im einen schnell und im anderen langsam, also bedeutet «ist es schnell?» nichts, solange du nicht sagst, wo. Anthropic stellt es als das dar, was es ist — ein Tausch: Agentische Systeme tauschen oft Latenz und Kosten gegen bessere Leistung bei der Aufgabe, und man sollte abwägen, wann sich dieser Tausch lohnt. Quelle: Building effective agents, Anthropic, 19. Dezember 2024, abgerufen am 12. September 2026.
Der Preis pro Million Token ist ein Listenpreis, nicht deine Rechnung. Ein billiges Modell, das drei Anläufe braucht, die Hälfte der Felder leer lässt und am Ende an einen Menschen eskaliert, kommt dich teurer als ein teures, das beim ersten Mal trifft. Die richtige Einheit ist der gelöste Fall: Gesamtkosten des Ablaufs — alle Aufrufe, alle Wiederholungen, auch die des gescheiterten Schritts — geteilt durch die Fälle, die richtig herauskamen, ohne dass jemand sie angefasst hat.
Die öffentliche Rangliste weiß nichts über deine Arbeit
Mit den drei Achsen auf dem Tisch wird klar, warum die Rangliste nicht entscheidet. Eine öffentliche Rangliste misst eine standardisierte Prüfung: Quizfragen, Spielzeug-Codeaufgaben, Logikrätsel. Deine Aufgabe ist das nicht. Deine Aufgabe sind die E-Mails deiner Kunden, euer internes Vokabular, eure schlecht gescannten PDFs und eure Rückgaberichtlinie — und keine dieser vier Sachen taucht in irgendeiner Tabelle auf. Wir haben das seinerzeit ausgeführt: LLM-Benchmarks sagen dein Ergebnis nicht voraus.
Wozu eine öffentliche Rangliste taugt, ist das Gegenteil dessen, wofür sie benutzt wird: Sie taugt zum Aussortieren, nicht zum Auswählen. Sie sagt dir, welche Modelle überhaupt im Gespräch sind und welche zwei Generationen zurückliegen, und das erspart dir, fünfzehn Kandidaten zu prüfen. Danach wird die kurze Liste — zwei, drei — mit deiner eigenen Fallsammlung sortiert. Diese Reihenfolge deckt sich selten mit der Rangliste, und wenn doch, ist es ein Zufall, auf den du beim nächsten Mal nicht setzen kannst.
Die Verteilung: billig zum Klassifizieren, teuer zum Entscheiden
Das Muster hat einen Namen und ist dokumentiert. Anthropic nennt es Routing: Ein erster Schritt klassifiziert die Eingabe und leitet sie an die spezialisierte Folgeaufgabe weiter, zu der sie gehört. Der Nutzen, so erklären sie, ist die Trennung der Zuständigkeiten und die Möglichkeit, spezialisiertere Prompts zu schreiben, denn ohne diese Verteilung verschlechtert die Optimierung für eine Eingabeart die Leistung bei den anderen. Und eines ihrer Beispiele ist buchstäblich die Kostenverteilung: einfache, häufige Fragen an kleinere, kostengünstige Modelle, schwierige oder ungewöhnliche an leistungsfähigere. Quelle: Building effective agents, Anthropic, 19. Dezember 2024, abgerufen am 12. September 2026.
Auf die Schritte eines typischen Agenten übertragen, fällt die Verteilung meist so aus. Die rechte Spalte ist ein Ausgangspunkt, kein Gesetz:
| Schritt des Agenten | Was er wirklich verlangt | Wo er meist landet |
|---|---|---|
| Eingabe klassifizieren und routen | Konsistenz und Tempo über einer geschlossenen Menge von Kategorien | Kleines Modell |
| Felder aus einem Dokument extrahieren | Stabiles Format; der Fehler fällt bei der Validierung auf | Kleines Modell mit Ausgabevertrag |
| In deinen Dokumenten suchen und zusammenfassen | Treue zur Quelle; die Qualität der Recherche entscheidet | Mittleres Modell |
| Über Geld, Personen oder regulierte Daten entscheiden | Urteilskraft und Nuance; der Fehler kostet Euro oder Ruf | Leistungsfähigstes Modell |
| Formulieren, was ein Kunde liest | Ton, Präzision und null Erfindung | Leistungsfähigstes Modell |
Bestätigen kann diese Tabelle nur deine eigene Fallsammlung. Es gibt Klassifikationen mit zwanzig überlappenden Kategorien, an denen das kleine Modell scheitert, und Formulierungen, die so eng gefasst sind — eine Eingangsbestätigung mit drei Variablen —, dass das kleine überqualifiziert ist. Deshalb wird die Verteilung durch Messen entschieden und überprüft, wenn sich der Modellkatalog oder dein Volumen ändert.
Eine Nuance, die Ärger spart: Routing lohnt sich nur, wenn die Kategorien wirklich verschieden sind und die Klassifikation präzise gelingt. Das ist die Bedingung, die Anthropic an dieses Muster knüpft, und sie ist die, die kippt, wenn jemand einen Router einbaut, wo keiner nötig war. Irrt der Klassifizierer, hast du nichts gespart: Du hast einen neuen Fehlerpunkt vor alles andere gesetzt, und zwar einen stillen, denn eine falsch geroutete Eingabe wirft keinen Fehler — sie liefert eine selbstbewusste Antwort der falschen Sorte.
Die richtige Reihenfolge: fang teuer an und geh runter, bis es auffällt
Mit klarer Verteilung bleibt das Wie. OpenAIs Leitfaden schlägt ein Rezept vor, das gegen jedermanns Instinkt läuft: den Prototyp mit dem leistungsfähigsten Modell für jede Aufgabe bauen, um eine Leistungs-Baseline zu setzen, und von dort kleinere Modelle einwechseln, um zu sehen, ob sie noch ein akzeptables Ergebnis liefern. Die Prinzipien, in dieser Reihenfolge: Evals aufsetzen, um die Baseline zu bestimmen, das Genauigkeitsziel mit den besten verfügbaren Modellen erreichen und erst danach Kosten und Latenz optimieren, indem große durch kleine ersetzt werden, wo es geht. Quelle: A practical guide to building agents, OpenAI, abgerufen am 12. September 2026.
- Bau die Fallsammlung, bevor du den Agenten anfasst. Dreißig oder fünfzig, echt, mit der richtigen Antwort daneben. Diesen Schritt überspringen alle, und er entscheidet, ob der Rest etwas taugt.
- Bau den ganzen Agenten mit dem leistungsfähigsten Modell in jedem Schritt. Du optimierst noch nicht: Du findest heraus, ob dein Genauigkeitsziel überhaupt erreichbar ist.
- Miss gegen die Sammlung. Kommst du hier nicht ans Ziel, liegt es nicht am Modell: Es sind der Prompt, deine Daten, die Recherche oder die Aufgabe — und ein kleineres Modell würde das nur verdecken.
- Ist das Ziel erreicht, geh einen Schritt nach dem anderen runter und lass die Sammlung erneut laufen. Eine Änderung, eine Messung. Zwei auf einmal, und du weißt nicht mehr, welche es war.
- Halt bei der Stufe vor der, die bricht. Und schreib auf, welcher Schritt welches Modell nutzt und mit welcher gemessenen Trefferquote — in drei Monaten erinnert sich niemand.
Der Grund gegen die umgekehrte Reihenfolge ist diagnostisch, nicht dogmatisch. Fängst du mit dem billigen Modell an und der Agent funktioniert nicht, hast du vier Verdächtige und keine Möglichkeit, sie zu trennen: das Modell, den Prompt, deine Daten oder eine Aufgabe, die nie sauber definiert war. Von oben angefangen weißt du, wenn beim Runtergehen etwas bricht, genau was es gebrochen hat — weil du nur eine Sache geändert hast.
Die Schicht, mit der du das Modell wechselst, ohne den Agenten anzufassen
Alles bisher hat ein Verfallsdatum. Der Modellkatalog dreht sich alle paar Monate, Preise bewegen sich, Anbieter stellen Versionen ab. Steht die heutige Entscheidung im Agenten — der Modellname an sieben Stellen im Code —, kannst du sie in sechs Monaten nicht neu treffen und landest bei dem Problem, das wir in wie du das Modell wechselst, ohne deine Automatisierungen zu zerlegen beschreiben: Der Ablauf bricht nicht mit einem Fehler, er bricht mit einem anderen Format und einem anderen Ton, lautlos.
Die Schicht, die das verhindert, sind fünf Teile, und keines davon ist raffiniert:
- Eine einzige Funktion, die das Modell aufruft. Alle Aufrufe gehen durch sie. Stehen an sieben Stellen im Code Modellnamen, hast du bereits Schulden.
- Die Modell-Kennung in der Konfiguration. Eine Datei mit dem Modell je Schritt. Ein Modellwechsel muss eine Zeile sein, nicht das Öffnen des Agenten.
- Ein geprüfter Ausgabevertrag. Bevor das Ergebnis irgendein System berührt, wird geprüft, ob es die vereinbarte Form hat. Das macht aus einer stillen Formatänderung einen sichtbaren Fehler.
- Die Fallsammlung, mit einem Befehl ausführbar. Kostet das Testen eines neuen Modells einen halben Vormittag Handarbeit, testet es niemand.
- Ein Protokoll, welches Modell welchen Fall bearbeitet hat. Ohne das kannst du weder vorher und nachher vergleichen noch erklären, warum es letzte Woche besser lief.
Das ist keine optionale Optimierung für Phase zwei. Es ist der Unterschied zwischen heute ein Modell wählen und in sechs Monaten wieder wählen können. Fehlt diese Schicht, wird die Modellentscheidung einmal getroffen und für immer geerbt — genau die falsche Form für ein System, das in einem Markt lebt, der sich jedes Quartal bewegt.
Die Verteilungstabelle: eine Seite, mit Verantwortlichem und Datum
Der Schluss ist derselbe wie bei den Anweisungen eines KI-Agenten: Was nicht aufgeschrieben ist, existiert nicht. Eine Seite reicht, und sie muss diese fünf Dinge beantworten.
- Welches Modell jeder Schritt nutzt, mit einer Zeile Begründung und der gegen die Sammlung gemessenen Trefferquote am Tag der Entscheidung.
- Was getestet und verworfen wurde. Der Kandidat, der es nicht wurde, und der Grund. Ohne das testet ihn jemand in vier Monaten wieder von null.
- Wer unterschreibt. Eine Person mit Namen. Eine Tabelle ohne Verantwortlichen wird nie überprüft.
- Was eine Überprüfung auslöst: ein relevantes neues Modell, die Abkündigung des genutzten Modells durch den Anbieter, ein Volumen, das sich um eine Größenordnung ändert, oder eine sinkende gemessene Trefferquote.
- Nächste Überprüfung. Ein Datum, auch wenn nichts passiert ist. Die Entscheidung verfällt von allein, und niemand sagt Bescheid.
Ist dein Agent schon produktiv und diese Seite existiert nicht, fang bei den Schritten an, die Geld berühren: welches Modell über eine Rückerstattung entscheidet, welches Modell formuliert, was dein Kunde liest, und mit welcher gemessenen Trefferquote. Der Rest kann eine Woche warten.
Wir bauen diese Schicht vor dem Agenten: gekapselter Aufruf, Modell in der Konfiguration, Ausgabevertrag und ausführbare Fallsammlung — als Teil der KI-Infrastruktur für Unternehmen, auf der danach die KI-Mitarbeiter gebaut werden. Das ist der Teil, den niemand in einer Demo zeigt, und der einzige, der entscheidet, ob du in einem Jahr das Modell an einem Nachmittag wechselst oder das System neu baust. Die ganze Logik steht in einen KI-Agenten bauen, der Produktion aushält.