SEAR: Schema-Based Evaluation and Routing for LLM Gateways

Das Paper stellt SEAR vor, ein schema-basiertes System für LLM-Gateways, das durch eine relational strukturierte Datenbank und LLM-basierte Signalgenerierung präzise Evaluierungssignale liefert, um fundierte Routing-Entscheidungen zu treffen und dabei Kosten zu senken sowie die Qualität zu erhalten.

Das Wesentliche

Stell dir vor, du betreibst ein riesiges, modernes Restaurant namens „LLM-Gateway". In diesem Restaurant gibt es nicht nur einen Koch, sondern viele verschiedene Köche (die verschiedenen KI-Modelle von Anbietern wie OpenAI, Anthropic, Google etc.). Jeder Koch hat seine Stärken: Einer ist schnell und billig, aber vielleicht etwas oberflächlich. Ein anderer ist ein Meister seines Fachs, aber sehr teuer und langsam.

Das Problem? Du weißt nicht immer, welcher Koch für welches Gericht am besten geeignet ist. Wenn du einem billigen Koch einen komplizierten, dreigängigen Menüauftrag gibst, wird das Essen schlecht. Gibst du einem teuren Meisterkoch einen einfachen Salat, verschwendest du Geld.

Bisher haben viele Restaurants versucht, das zu lösen, indem sie einfache Regeln aufstellten („Wenn der Kunde 'Code' sagt, nimm den teuren Koch") oder indem sie nach dem Essen einfach fragten: „War das gut?" (eine einfache 1-10 Bewertung). Das war oft ungenau, schwer zu verstehen und man konnte nicht genau sagen, warum das Essen schlecht war.

Hier kommt SEAR ins Spiel. SEAR ist wie ein super-organisiertes, digitales Qualitätsmanagement-System für dein Restaurant.

1. Das große Regelbuch (Das Schema)

Stell dir vor, SEAR führt für jeden Auftrag nicht nur ein einfaches Notizbuch, sondern ein riesiges, perfekt strukturiertes Excel-Tablett mit über 100 Spalten.

• Früher: Man schrieb nur „Das Essen war okay" auf einen Zettel.
• Mit SEAR: Man füllt ein Formular aus, das Fragen stellt wie:
  • „War der Auftrag klar?" (Kontext)
  • „Hat der Koch genau das gemacht, was bestellt wurde?" (Antwort-Charakteristik)
  • „War das Essen zu salzig, oder hat der Koch einfach nicht zugehört?" (Fehler-Ursache)
  • „Wie schwerwiegend war der Fehler?" (Qualitäts-Score)

Das Besondere an SEAR ist, dass dieses Formular nicht nur aus Text besteht, sondern aus klaren, maschinenlesbaren Kästchen (wie Ja/Nein oder „Sehr gut/Gut/Schlecht"). Das macht es möglich, später alles sofort zu durchsuchen und zu analysieren, ohne mühsam Texte lesen zu müssen.

2. Der „Koch-Prüfer" (Der LLM-as-Judge)

Wer füllt dieses riesige Formular aus? Ein spezieller KI-Koch, der als Qualitätsprüfer arbeitet.

• Der Trick: Früher haben diese Prüfer oft nur schnell hingeschaut und eine Note gegeben. SEAR zwingt den Prüfer, erst einmal nachzudenken (wie ein menschlicher Kritiker), bevor er das Formular ausfüllt.
• Die Methode: Der Prüfer denkt sich einen kurzen Gedankengang aus („Der Kunde wollte einen Code, aber der Koch hat nur Text geliefert..."), schreibt diesen in ein verstecktes Feld und füllt dann erst die offiziellen Kästchen aus. So werden Fehler vermieden, und die Ergebnisse sind viel genauer.
• Der Vorteil: Da der Prüfer genau warum etwas schlecht war, begründen kann (z. B. „Der Koch hat die Anweisung ignoriert"), kannst du später genau sehen, welcher Koch bei welchen Aufgaben versagt.

3. Der Daten-Fluss (Die Daten-Flywheel)

SEAR verbindet zwei Welten, die bisher getrennt waren:

1. Die Qualität: Wie gut war das Essen? (Die Ergebnisse des Qualitätsprüfers).
2. Die Betriebsdaten: Wie lange hat es gedauert? Wie viel hat es gekostet? (Die Daten vom Kassen-System).

Da beides in derselben Datenbank liegt, kannst du jetzt Fragen stellen wie:

• „Welcher Koch liefert bei einfachen Aufgaben das beste Essen zum günstigsten Preis?"
• „Bei welchem Anbieter dauert die Lieferung am längsten, obwohl das Essen gut ist?"

4. Die intelligente Steuerung (Routing)

Das ist der magische Teil. Basierend auf diesen Daten kann das Restaurant-System automatisch entscheiden, welcher Koch den nächsten Auftrag bekommt.

• Beispiel: Ein Kunde bestellt einen einfachen Salat. Das System sieht in der Datenbank: „Ah, der billige Koch 'Gemini' macht bei einfachen Aufgaben fast genauso gutes Essen wie der teure Chefkoch, kostet aber nur 10% davon." -> Entscheidung: Der Salat geht an den billigen Koch.
• Beispiel: Ein Kunde bestellt ein komplexes Menü. Das System sieht: „Der billige Koch versagt hier oft." -> Entscheidung: Der Auftrag geht an den teuren, aber zuverlässigen Chefkoch.

Warum ist das revolutionär?

Stell dir vor, du könntest in Echtzeit sehen, warum ein Gericht schlecht wurde, und sofort die Regeln für die nächste Bestellung ändern, um Geld zu sparen, ohne dass die Gäste (die Nutzer) schlechteres Essen bekommen.

• Kein Blackbox: Du weißt genau, warum eine Entscheidung getroffen wurde (weil die Daten es zeigen).
• Kostenersparnis: Du zahlst nicht mehr für teure Köche, wenn ein günstigerer das gleiche Ergebnis liefert.
• Qualitätssicherung: Du findest Fehler sofort, nicht erst Wochen später.

Zusammengefasst: SEAR ist wie ein hochintelligenter, datengetriebener Restaurantmanager, der für jeden Auftrag genau prüft, was passiert ist, und basierend auf diesen harten Fakten entscheidet, wer als nächstes kocht, damit das Restaurant immer das beste Preis-Leistungs-Verhältnis bietet.

Technische Zusammenfassung

1. Problemstellung

Mit dem Wachstum von Produktions-LLM-Traffic entstehen erhebliche Herausforderungen bei der Bewertung agenter Systeme und dem Routing von Anfragen über verschiedene Anbieter hinweg.

• Komplexität der Workloads: Produktionsumgebungen umfassen diverse Domänen (Gesundheit, Finanzen, Bildung), Multi-Turn-Konversationen und multimodale Eingaben. Kein einzelnes Modell oder Anbieter ist für alle Fälle optimal, und die Kosten variieren stark.
• Mangel an feingranularen Signalen: Bestehende Ansätze zur Bewertung (LLM-as-Judge) liefern oft unstrukturierte Texte, einzelne Gesamtscores oder starre Rubriken. Diese lassen sich schwer aggregieren, bieten keine tiefgehende Fehleranalyse (Root-Cause) und ermöglichen keine interpretierbaren Entscheidungen für das Routing.
• Black-Box-Routing: Herkömmliche Router nutzen oft heuristische Merkmale oder Klassifikatoren, die keine semantisch tiefgehenden Erklärungen liefern, warum ein bestimmtes Modell gewählt wurde. Dies macht Änderungen an Live-Systemen riskant.
• Trennung von Evaluation und Betrieb: Evaluierungsergebnisse und operative Metriken (Latenz, Kosten, Durchsatz) liegen oft in getrennten Systemen, was eine gemeinsame Analyse erschwert.

2. Methodik: Das SEAR-Framework

SEAR (Schema-Based Evaluation and Routing) ist ein System, das eine strukturierte, relationale Datenbank als zentrale Ebene für sowohl Evaluierungs-Signale als auch operative Metriken nutzt.

A. Datenmodell und Schema-Design

SEAR definiert ein erweiterbares relationales Schema mit etwa 100 typisierten, SQL-abfragbaren Spalten, verteilt auf fünf Tabellen:

1. context_info: Erfasst Kontext und Intent (Systemnachrichten, Benutzerinput, Referenzmaterial, Aufgabenart, Komplexität).
2. llm_response_info: Dokumentiert, was das Modell tatsächlich produziert hat (Tool-Calls, Code, Ablehnungen).
3. issue_attribution: Weicht potenzielle Lücken oder Fehler bestimmten Quellen zu (Benutzer, Kontext, Modellverhalten oder gemischt).
4. evaluation: Bewertet die Schwere von Problemen auf einer ordinalen Skala und liefert Qualitätsdimensionen (Relevanz, Vollständigkeit, Faktenkorrektheit, Sicherheit).
5. gateway_metrics: Eine von der Infrastruktur gefüllte Tabelle mit operativen Daten für jeden Request (Latenz, Kosten, Token-Nutzung, Fehlerstatus).

Cross-Table Consistency: Das Schema nutzt Fremdschlüssel, um logische Inkonsistenzen zu erkennen (z. B. wenn ein Tool-Call angefordert wurde, aber nicht ausgeführt wurde, muss die Fehlerursache und -schwere entsprechend gesetzt sein).

B. Der Schema-getriebene Judge (Bewerter)

Um diese komplexen strukturierten Daten zuverlässig zu generieren, verwendet SEAR einen spezialisierten „Judge"-LLM mit folgenden Techniken:

• Self-Contained Signal Instructions: Jede Spalte im JSON-Schema erhält eine eigenständige, detaillierte Anweisung (Definition, Gültigkeitsbereich, Zuweisungsregeln, Edge Cases), um Interferenzen zwischen Signalen zu minimieren.
• In-Schema Reasoning: Statt eines separaten Chain-of-Thought (CoT) im Freitext (was zwei API-Aufrufe erfordern würde), wird ein temporäres „reasoning"-Feld direkt in das JSON-Schema integriert. Der LLM generiert die Begründung als ersten Schritt innerhalb desselben Aufrufs, bevor er die eigentlichen Signale ausfüllt. Dies erhält die Struktur und reduziert die Token-Kosten.
• Multi-Stage Generation: Anstatt alle ~100 Spalten in einem Aufruf zu generieren, wird der Prozess in vier Stufen unterteilt (Kontext -> Antwort -> Fehlerzuordnung -> Bewertung). Jede Stufe erhält den Kontext und die Ergebnisse der vorherigen Stufe. Dies verbessert die Stabilität und Genauigkeit der Generierung.

C. Datengetriebenes Routing

Da alle Daten in einer SQL-Datenbank liegen, können Routing-Entscheidungen durch Standard-Abfragen getroffen werden:

• Offline-Policy-Updates: Teams können komplexe Abfragen nutzen, um Modelle basierend auf Qualitäts-Kosten-Trade-offs für spezifische Traffic-Slices (z. B. „einfache Aufgaben") zu vergleichen.
• Echtzeit-Routing: Ein leichtgewichtiger Klassifikator (z. B. GPT-5-nano) extrahiert im Gateway nur die Kontext-Signale (Aufgabetyp, Komplexität) und greift auf die zuvor berechneten SEAR-Routing-Richtlinien zu, um das Zielmodell zu wählen.

3. Wichtige Beiträge

1. Einheitliches Daten-System: Kombination von strukturierten LLM-Evaluierungsdaten mit Gateway-Metriken in einer SQL-abfragbaren Schicht.
2. Erweiterbares relationales Schema: Ein Schema mit Cross-Table-Consistency-Checks, das den gesamten Lebenszyklus einer LLM-Anfrage abdeckt.
3. Zuverlässige strukturierte Generierung: Ein Judge-Design mit eigenständigen Anweisungen, In-Schema-Reasoning und Multi-Stage-Generation, das hohe Genauigkeit bei komplexen Schemata erreicht.
4. Validierung in der Produktion: Nachweis, dass das System menschliche Bewertungen gut nachbildet und kosteneffiziente Routing-Entscheidungen trifft.

4. Ergebnisse

Die Evaluation basierte auf 3.000 Produktions-Sessions aus drei verschiedenen Organisationen.

• Genauigkeit des Judges:

  • Der Judge (GPT-5-mini mit hohem Reasoning-Effort) erreichte eine Genauigkeit von über 91 % für boolesche Signale und über 92 % für kategorische Signale.
  • Ordinale Signale (Schweregrad) zeigten eine MAE (Mean Absolute Error) von ca. 0,20–0,22 (normalisiert).
  • Cross-Table Consistency: Das Filtern von inkonsistenten Datensätzen verbesserte die Metriken deutlich, insbesondere bei schwächeren Modellkonfigurationen.
  • Meta-Task Confusion: Ein häufiger Fehlermodus, bei dem der Judge die eigenen Anweisungen mit der Benutzeranfrage verwechselt, konnte durch stärkeres Reasoning (GPT-5.2 High Effort) auf 0 % reduziert werden.

• Routing-Leistung (Case Study):

  • In einem Szenario mit „einfachen" Aufgaben konnte SEAR ein Ersatzmodell (gemini-2.5-flash-lite) identifizieren, das eine vergleichbare Qualität wie das eingesetzte Modell (claude-haiku-4-5) bot, aber 90 % niedrigere Eingabe-Kosten und 92 % niedrigere Ausgabe-Kosten verursachte.
  • Eine manuelle Überprüfung von 100 Sessions bestätigte, dass die Qualität erhalten blieb (48 % Gewinnrate für das neue Modell, Rest Unentschieden oder leichtes Verlieren).

• Echtzeit-Klassifikation:

  • Ein leichtgewichtiger Klassifikator (GPT-5-nano) konnte Kontext-Signale mit hoher Genauigkeit extrahieren (82 % boolesche Genauigkeit) und ermöglichte Echtzeit-Routing bei nur 1/16 der Kosten des vollen Evaluierungs-Pipelines.

5. Bedeutung und Ausblick

SEAR adressiert die Lücke zwischen oberflächlicher Metrik-Erfassung und tiefgehender, semantischer Analyse in LLM-Gateways.

• Interpretierbarkeit: Durch die strukturierte, SQL-basierte Darstellung erhalten Teams klare, nachvollziehbare Erklärungen für Routing-Entscheidungen (z. B. „Modell X wurde gewählt, weil es bei Code-Aufgaben 20 % weniger Fehler aufweist").
• Daten-Feedback-Schleife: Das System schafft einen Flywheel-Effekt, bei dem gesammelte Evaluierungsdaten kontinuierlich die Routing-Policies verbessern.
• Skalierbarkeit: Der Ansatz ist nicht auf spezifische Domänen beschränkt und kann durch Hinzufügen neuer Tabellen oder Spalten erweitert werden, ohne das Kernsystem zu stören.

Zusammenfassend bietet SEAR einen robusten, datengesteuerten Ansatz, um die Kosten von LLM-Produktionssystemen signifikant zu senken, ohne dabei die Qualität zu opfern, und stellt gleichzeitig die notwendige Transparenz für den Betrieb sicher.