Ein Frontier-Modell als Standard wirkt einfach. Es vermeidet frühe Routingentscheidungen und liefert in Demos häufig gute Resultate. Im Betrieb bedeutet diese Wahl aber, dass Klassifikation, Extraktion, Recherche und komplexe Entscheidungen dieselbe Kosten- und Latenzklasse verwenden.
Gutes Routing beginnt nicht mit einer Preisliste. Es beginnt mit klar getrennten Aufgabentypen und einer messbaren Qualitätsgrenze.
Aufgaben statt Abteilungen routen
"Marketing" oder "Support" sind keine Modellrouten. Innerhalb einer Abteilung gibt es sehr verschiedene Aufgaben: Sprache erkennen, Felder extrahieren, Dokumente zusammenfassen, Antworten entwerfen oder eine sensible Empfehlung begründen.
Definieren Sie Routen nach der konkreten Arbeit. Je enger der Aufgabentyp, desto besser lassen sich Qualität, Kosten und Fehler messen.
Vier Kriterien für eine Route
Eine Route sollte mindestens berücksichtigen:
- Schwierigkeit und benötigte Reasoning-Tiefe,
- Auswirkung eines Fehlers,
- Datenklasse und erlaubte Provider,
- Latenz- und Kostenbudget.
Kontextlänge, Tool Calling und strukturierte Ausgaben kommen als technische Anforderungen hinzu. Ein günstiges Modell ist keine Option, wenn es das benötigte Ausgabeformat nicht stabil erfüllt.
Erst evaluieren, dann routen
Erstellen Sie pro Aufgabentyp ein kleines, realistisches Evaluationsset. Es sollte normale Fälle, schwierige Fälle und klare Ausschlussfehler enthalten. Vergleichen Sie Modelle auf denselben Eingaben und mit derselben Bewertung.
Routen Sie nur innerhalb einer akzeptierten Qualitätsgrenze nach Kosten. Wenn ein Modell häufiger Retries oder menschliche Korrekturen erzeugt, kann es trotz niedriger Tokenpreise teurer sein.
Statische und dynamische Auswahl
Statisches Routing ordnet einen Aufgabentyp fest einem Modell zu. Das ist leicht zu prüfen und für viele Unternehmensworkflows der beste Start.
Dynamisches Routing schätzt Schwierigkeit oder Risiko pro Anfrage. Es kann effizienter sein, ist aber selbst ein Modell- oder Regelsystem, das evaluiert werden muss. Prüfen Sie insbesondere, ob sensible oder schwierige Fälle zuverlässig hochgestuft werden.
Eskalation statt unsichtbarer Wiederholung
Wenn ein günstiges Modell scheitert, sollte der Workflow nicht unbegrenzt zu stärkeren Modellen wechseln. Definieren Sie eine Eskalationskette mit maximalen Versuchen und sichtbarer Kostenzuordnung.
Für kritische Aufgaben kann der letzte Schritt eine menschliche Prüfung sein. Der Gateway-Log sollte zeigen, warum eine Eskalation stattfand und welches Modell das endgültige Resultat erzeugte.
Modellupdates sind Produktionsänderungen
Provider ändern Modelle, Versionen und Standardverhalten. Eine neue Version darf nicht automatisch alle Routen übernehmen. Führen Sie das Evaluationsset erneut aus, vergleichen Sie Qualität, Latenz und Kosten und dokumentieren Sie die Entscheidung.
Dasselbe gilt für lokale oder offene Modelle. Ein neues Benchmarkresultat ist kein Ersatz für Tests auf den eigenen Aufgaben.
Quellen
- OpenAI Evals: https://platform.openai.com/docs/guides/evals
- Anthropic, Define success criteria and build evaluations: https://docs.anthropic.com/en/docs/test-and-evaluate/define-success
- LiteLLM, Routing und Load Balancing: https://docs.litellm.ai/docs/proxy/load_balancing
- NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
Nächster Schritt
Wählen Sie drei häufige Aufgabentypen mit unterschiedlichem Risiko. Erstellen Sie je zehn bis zwanzig reale Testfälle, legen Sie Ausschlussfehler fest und vergleichen Sie zwei Modellklassen. Routen Sie erst dann anhand der Kosten pro akzeptiertem Ergebnis.