Online-Evaluation und Qualitätsüberwachung am Gateway

Dieser Beitrag beschreibt ein Architekturmuster, das Sie mit dem AI Gateway von TrueFoundry umsetzen können. Beachten Sie, dass die Online-Evaluierung keine native Funktion ist – sie ist etwas, das Sie auf Basis der Observability- und Routing-Funktionen des Gateways aufbauen.

Sie können nach Kosten routen, bei Ausfällen auf andere Modelle ausweichen und aggressiv cachen – und dennoch eine Änderung veröffentlichen, die Ihre Antworten schleichend verschlechtert. Kosten, Latenz und Fehlerrate sind die drei Signale, die jedes Produktionssystem überwacht, doch sie können alle im grünen Bereich bleiben, während das vierte – die Antwortqualität – abfällt. Dieser Beitrag zeigt, wie Sie dieses vierte Signal in der Produktion messen: durch Online-Evaluierung, Scoring mittels LLM-as-a-Judge (samt ehrlicher Einschätzung der Grenzen), Sampling, Regressionserkennung und die Rückführung dieser Erkenntnisse in die Routing-Entscheidungen.

Leena, eine ML-Ingenieurin, setzte eine Änderung um, die sich alle wünschten. Eine Support-Route mit hohem Volumen lief über das Flaggschiff-Modell, und ein günstigeres Modell schnitt im Test fast genauso gut ab. Also stellte sie die Route um – eine einfache Kostenersparnis von 60 % bei einem großen Teil des Traffics. Jedes Dashboard bestätigte den Erfolg: Die Latenz blieb stabil, die Fehlerrate war unverändert, die Ausgaben sanken wie geplant. Die Änderung ging live, die Einsparungen wurden realisiert und das Team machte weiter. Zwei Wochen später häuften sich die Eskalationen im Support. Eine Inhaltsprüfung ergab, dass sie auf subtil schlechtere Antworten genau dieser Route zurückzuführen waren – vager und gelegentlich falsch, ohne jedoch Fehlercodes auszulösen. Die Qualität war an dem Tag gesunken, an dem sie die Änderung veröffentlichte. Da nichts dies maß, bemerkte es zwei Wochen lang niemand.

Dies ist der blinde Fleck im Zentrum des LLM-Betriebs. Die Signale, die leicht zu messen sind – Kosten, Latenz, Fehler –, sind nicht die Signale, die bestimmen, ob das Produkt gut ist. Qualität ist schwerer zu messen und wird daher oft vernachlässigt. Eine Änderung, die Qualität gegen Kosten tauscht, sieht wie ein reiner Gewinn aus, bis die Beschwerden eintreffen. Online-Evaluierung ist der Weg, wie Sie das vierte Signal beziffern und genauso überwachen wie die anderen drei.

1. Das Signal, das Ihnen fehlt: Qualität in der Produktion

Drei Produktionssignale sind nahezu kostenlos, da die Infrastruktur sie ohnehin ausgibt: Latenz ist ein Zeitwert, Kosten sind Tokens multipliziert mit einem Satz, Fehler sind Statuscodes. Qualität ist nichts davon. Eine Antwort kann schnell und günstig sein und einen sauberen 200-Statuscode zurückgeben, während sie gleichzeitig vage, subtil falsch, nicht richtlinienkonform oder wenig hilfreich ist – und keine operative Metrik schlägt an. Diese Asymmetrie ist der Grund, warum Teams die drei einfachen Signale instrumentieren, aber bei dem Signal, das das Produkt tatsächlich definiert, blind fliegen.

Qualität beobachtbar zu machen bedeutet, ein Signal zu erzeugen, das nicht von selbst entsteht: echte Antworten stichprobenartig erfassen, sie anhand dessen bewerten, was "gut" für den Anwendungsfall bedeutet, und diesen Wert über die Zeit und bei Änderungen hinweg verfolgen – direkt neben Kosten und Latenz. Der Rest dieses Beitrags zeigt, wie Sie dieses Signal glaubwürdig erzeugen – inklusive einer ehrlichen Einschätzung der Rauschintensität – und wo Sie es ausführen, damit es direkt mit den Routing-Entscheidungen verknüpft ist, die es beeinflussen.

2. Offline- vs. Online-Evaluierung

Die Offline-Evaluierung führt einen festen Testdatensatz gegen ein Modell oder einen Prompt aus, bevor Sie veröffentlichen – eine kuratierte Menge an Eingaben mit bekannten guten Antworten oder Rubriken, die in der CI bewertet werden. Das ist essenziell, aber nicht ausreichend. Ein statischer Testdatensatz enthält nur die Fälle, an die Sie gedacht haben; Produktions-Traffic enthält die Fälle, an die Sie nicht gedacht haben, sowie Verteilungsverschiebungen, wenn sich das Nutzerverhalten und die Welt ändern. Leenas günstigeres Modell bestand den Offline-Test genau deshalb, weil der Testdatensatz nicht die chaotische "Long Tail"-Realität der Live-Support-Route widerspiegelte.

Die Online-Evaluierung bewertet echten Produktions-Traffic im Nachhinein anhand einer Stichprobe. Sie fängt das ein, was die Offline-Evaluierung übersieht: Grenzfälle außerhalb Ihres Testdatensatzes, schleichende Drift und Regressionen, die durch Änderungen am Live-System entstehen. Beide Ansätze ergänzen sich: Offline ist Ihr Pre-Flight-Check gegen bekannte Fälle, Online ist Ihr kontinuierliches Messinstrument für die Realität. Dieser Beitrag konzentriert sich auf Online, da genau diese Lücke dazu führte, dass eine zweiwöchige Regression unbemerkt blieb.

3. Wie Sie eine Antwort bewerten: LLM-as-a-Judge, Heuristiken und Guardrail-Signale

Es gibt drei praktische Möglichkeiten, eine Antwort zu bewerten, und meist kombiniert man sie. Heuristiken sind kostengünstige, deterministische Prüfungen: Wurde die Ausgabe als gültiges JSON geparst? Zitiert sie eine Quelle, wenn sie es sollte? Ist sie in einer vernünftigen Länge? Enthält sie eine Verweigerung? Guardrail-Signale nutzen die Detektoren aus dem früheren Teil dieser Serie wieder – ein PII-Treffer, ein Toxizitäts-Flag oder ein Injection-Detektor, der bei der Ausgabe anschlägt, sind ebenfalls Qualitätssignale. Und LLM-as-Judge verwendet ein Modell, um eine Antwort anhand eines Bewertungsrasters zu beurteilen. Dies ist die einzige der drei Methoden, die offene Qualitätsmerkmale wie Hilfsbereitschaft, Genauigkeit oder Tonalität bewerten kann.

LLM-as-Judge-Bewerter mit explizitem Bewertungsraster (illustrativ)

JUDGE_PROMPT = """You are grading a support answer against a rubric.
Rate each dimension 1-5 and return ONLY JSON.
- faithful: supported by the provided context, no fabrication
- helpful: directly addresses the user's question
- safe: no PII leakage, no policy violation
Question: {question}
Context: {context}
Answer: {answer}
Return: {{"faithful": int, "helpful": int, "safe": int, "reason": str}}"""

def judge(question, context, answer):
    raw = judge_model.complete(JUDGE_PROMPT.format(...), temperature=0)
    return parse_json(raw)   # trend these scores; do not treat as ground truth

4. Sampling: Man kann (und sollte) nicht alles bewerten

Die Bewertung verursacht eigene Kosten und Latenzzeiten – ein LLM-as-Judge-Aufruf ist ein zusätzlicher Modellaufruf –, daher lohnt es sich selten, 100 % des Datenverkehrs zu bewerten, da dies die Kosten des Datenverkehrs selbst erreichen kann. Die Lösung ist Sampling, gepaart mit ein wenig statistischer Ehrlichkeit. Ein kleiner, zufälliger Bruchteil jeder Route liefert eine unverzerrte Schätzung der Gesamtqualität; gezieltes Sampling erhöht die Rate bei den Routen, die Ihnen am wichtigsten sind – solche mit hohem Volumen, hoher Relevanz oder kürzlichen Änderungen. Da Sie auf Basis einer Stichprobe schätzen, ist jeder Qualitätswert mit Unsicherheit behaftet, und eine kleine Stichprobe auf einer Route mit geringem Volumen kann sich aus Gründen verändern, die nichts mit einer tatsächlichen Änderung zu tun haben.

Asynchrones Sampling und Scoring außerhalb des kritischen Pfads (illustrativ)

# Scoring runs after the response is returned — never adds latency to the user.
def on_response(req, resp):
    rate = 0.20 if req.route in HIGH_RISK_ROUTES else 0.02   # targeted + baseline
    if random() < rate:
        enqueue_for_scoring(                                  # async; off the hot path
            response=resp,
            tags={"model": req.model, "route": req.route,
                  "prompt_version": req.prompt_version},      # slice keys
        )

Zwei Disziplinen sorgen hier für Verlässlichkeit: Führen Sie die Bewertung asynchron durch, damit sie die Antwortzeit für den Benutzer nicht beeinträchtigt, und geben Sie die Qualität zusammen mit der Stichprobengröße an, damit ein verrauschter Datensatz mit geringem Volumen nicht fälschlicherweise als Trend interpretiert wird. Sampling macht aus einem unbezahlbaren „Alles-bewerten“-Ansatz ein erschwingliches, statistisch valides Instrument.

5. Qualitätsmetriken nach Modell, Route und Prompt-Version

Ein einzelner globaler Qualitätswert ist für die Diagnose nahezu nutzlos – er kann Ihnen nicht sagen, dass eine Route schlechter geworden ist, während alle anderen stabil geblieben sind. Qualität muss genauso aufgeschlüsselt werden wie die Kosten in unserem Beitrag zur Kostenzuordnung: nach Modell, nach Route, nach Prompt-Version und nach jeder anderen Dimension, in der sich eine Änderung auswirken kann. Diese Aufschlüsselungs-Keys sind genau die Metadaten, die das Gateway ohnehin an jede Anfrage anhängt. Deshalb gehört die Qualität neben Kosten und Latenz und nicht in ein separates System.

Die Qualität auf dieselben Achsen wie Kosten und Latenz zu legen, macht den Zielkonflikt sichtbar, anstatt ihn zu verbergen. Leenas Änderung hätte sich sofort als Qualitätsabfall auf einer Route gezeigt, genau an dem Tag, an dem sie sie veröffentlichte – direkt neben der Kostensenkung, die sie feierte. Das sind die beiden Zahlen, die immer zusammen betrachtet werden sollten. TrueFoundry AI Gateway bietet das Observability-Substrat – Anfrage-/Antwort-Logs, Metadaten-Tagging, Tracing, Kosten, Latenz und Routing-Kontext, aufgeschlüsselt nach Modell, Team und Metadaten –, an das diese Bewertung anknüpft. Die hier beschriebene Judge-and-Score-Schleife ist ein Architekturmuster, das Sie auf dieser Telemetrie aufbauen, sofern es nicht über eine spezifische Evaluationsintegration eingebunden ist; Online-Evaluation ist das, was die Qualitätsschätzung zu den Signalen hinzufügt, die das Gateway ohnehin bereits erfasst.

Konkret ist die Einheit, die die Online-Evaluation ausgibt, ein Bewertungsereignis, das mit der ursprünglichen Antwort verknüpft ist. Ein praktikables Mindestschema sieht wie folgt aus – die Felder sind das, was ein verwertbares Signal von einem irreführenden unterscheidet:

6. Regression erkennen, wenn eine Änderung die Qualität verschlechtert

Die Aufschlüsselung der Qualität macht die Regressionserkennung erst möglich: Sie vergleichen die Qualitätsschätzung eines Segments vor und nach einer Änderung – ein neues Modell auf einer Route, eine Prompt-Anpassung, ein Update der Routing-Richtlinie – und erhalten eine Warnung, wenn der Wert stärker sinkt, als es das Rauschen erklären würde. Da die Bewertungen stichprobenartig und verrauscht sind, muss der Vergleich die Unsicherheit berücksichtigen: Ein Abfall innerhalb der Fehlertoleranz der Stichprobe ist keine Regression, und ein kleines Segment benötigt eine größere oder längere Stichprobe, bevor man der Veränderung vertrauen kann.

Vergleich eines Segments über eine Änderung hinweg unter Berücksichtigung von Stichprobenrauschen (illustrativ)

before = quality_scores(route="support", prompt_version="v3")   # baseline window
after  = quality_scores(route="support", prompt_version="v4")   # after the change

drop = before.mean() - after.mean()
if drop > THRESHOLD and significant(before, after):             # beyond sample noise
    alert(f"quality regression on support: {before.mean():.2f} -> {after.mean():.2f}")
    # optionally: auto-roll back the route to the prior version/model

Der entscheidende Vorteil ist das Timing. Eine Regressionsprüfung der relevanten Segmente verkürzt Leenas zweiwöchige Lücke auf eine Warnmeldung am selben Tag: Sobald die Qualitätsschätzung der Support-Route unter den Basiswert fällt – und zwar stärker als das Rauschen –, wird jemand alarmiert, lange bevor die Eskalationen das Problem aufgedeckt hätten. Ob man ein automatisches Rollback durchführt oder nur eine Warnung ausgibt, ist eine Ermessensentscheidung, die davon abhängt, wie sehr man dem Signal dieses Segments vertraut – genau deshalb ist die Kalibrierung aus Abschnitt 3 so wichtig.

7. Den Kreis schließen: Qualitätsrückmeldung für das Routing

Der Grund, warum man die Qualität am Gateway und nicht in einer separaten Analyse-Pipeline misst, liegt darin, dass am Gateway auch die Routing-Entscheidungen getroffen werden – das Signal kann also direkt in die Entscheidung einfließen. Unser Beitrag zum Routing beschrieb qualitätsbasiertes Routing als ein Ziel, das ein Qualitätssignal benötigt, um Realität zu werden; die Online-Evaluierung ist dieses Signal. Mit den Qualitätsscores pro Segment ist Routing kein statisches Raten mehr, sondern ein Regelkreis: Ein günstigeres Modell wird nur so lange auf einer Route eingesetzt, wie die gemessene Qualität stabil bleibt. Bei Abweichungen erfolgt eine Warnung oder ein Rollback – was davon gewählt wird, hängt vom Risiko der Route und dem Vertrauen in das Signal des jeweiligen Segments ab.

Damit schließt sich der Kreis, den die Einleitung offen gelassen hat. Leenas kostensparende Änderung ist genau die Art von Entscheidung, die durch ein Live-Qualitätssignal abgesichert werden sollte: Das günstigere Modell bereitstellen, die Qualitätsschätzung auf dieser Route beobachten und die Einsparungen nur so lange beibehalten, wie die Qualität innerhalb der Toleranzgrenzen bleibt. Das Gateway ist der einzige Ort, der die Antworten bewertet und die Routing-Entscheidung zur Anpassung trifft – genau das macht es zum richtigen Ort für diesen Regelkreis, statt nur für die reine Messung.

8. Wo findet die Evaluierung statt: Gateway vs. Anwendung vs. Offline

Nicht jede Evaluierung gehört an denselben Ort, und es lohnt sich, hier präzise zu sein. Offline-Evaluierung findet in der CI statt, anhand fester Testdatensätze, um Deployments bei bekannten Fällen abzusichern. Anwendungsbasierte Evaluierung findet in der App statt, wenn für die Bewertung Kontext erforderlich ist, über den das Gateway nicht verfügt – etwa Ground Truth aus der Domäne, Geschäftsergebnisse oder ob die Aufgabe des Nutzers tatsächlich erfolgreich war. Die Online-Evaluierung auf Gateway-Ebene dient dem übergreifenden Signal: eine stichprobenartige, segmentierte Qualitätsschätzung auf Live-Traffic, verknüpft mit Kosten- und Latenz-Telemetrie, die das Routing steuert.

Das Gateway ersetzt die anderen beiden Ansätze nicht; es füllt die Lücke, die sie hinterlassen – durch kontinuierliche, konsistente Qualitätsüberwachung des gesamten Traffics an der Stelle, die sowohl Antworten beobachten als auch das Routing steuern kann. Das ist die Rolle, die das Gateway laut dieser Artikelserie spielt: die übergreifende Steuerungsebene, hier angewandt auf das Signal, das am schwersten zu messen ist und am meisten zählt.

9. Häufig gestellte Fragen (FAQs)

Warum reicht eine Offline-Evaluierung nicht aus?

Weil ein fester Testdatensatz nur die Fälle enthält, die man vorhergesehen hat. Die Produktion enthält den „Long Tail“, den man nicht auf dem Schirm hatte, dazu kommen Drift über die Zeit und Regressionen durch Live-Änderungen. Leenas günstigeres Modell hat die Offline-Tests bestanden und ist in der Produktion dennoch abgefallen, weil der Testdatensatz nicht dem echten Support-Traffic entsprach. Offline ist Ihr Pre-Flight-Check; Online ist Ihr kontinuierliches Instrument zur Messung der Realität. Sie brauchen beides.

Kann ich mich darauf verlassen, dass ein LLM ein anderes LLM bewertet?

Als Trendsignal mit Kalibrierung – ja, aber nicht als absolute Wahrheit. Bewertungsmodelle haben Verzerrungen (Länge, Selbstpräferenz, Position) und sind nicht perfekt konsistent. Kalibrieren Sie den Bewerter daher anhand von menschlich bewerteten Beispielen, um zu lernen, wie gut er menschliche Urteile für Ihre Aufgabe abbildet. Betrachten Sie Trends über Zeit und Segmente hinweg, anstatt auf Basis eines einzelnen Wertes zu handeln, und machen Sie eine Veröffentlichung niemals allein von einem unkalibrierten Bewerter abhängig. Es ist ein nützliches, aber unvollkommenes Instrument.

Was hätte das Problem aus der Einleitung verhindert?

Ein stichprobenartiger Qualitätsscore auf der Support-Route, segmentiert nach Modell- und Prompt-Version, mit einer Regressionsprüfung gegen den Basiswert vor der Änderung. An dem Tag, als Leena die Modelle wechselte, wäre die Qualitätsschätzung der Route parallel zum Kostensenkungssprung gefallen und die Regressionswarnung hätte ausgelöst – so wäre aus einem zweiwöchigen blinden Fleck ein Signal am selben Tag geworden. Die Kosteneinsparung war nicht der Fehler; sie ohne Qualitätssignal live zu schalten, war es.

Wie viel Traffic muss ich bewerten?

Genug, damit das Segment, das Sie betrachten, statistisch aussagekräftig ist. Das hängt vom Volumen und davon ab, wie groß eine Änderung sein muss, um sie zu erkennen. Ein kleiner zufälliger Basiswert über alle Routen hinweg, kombiniert mit einer höheren gezielten Rate auf kritischen oder kürzlich geänderten Routen, ist eine sinnvolle Standardeinstellung. Geben Sie die Qualität immer mit der Stichprobengröße an und seien Sie bei Bewegungen in Segmenten mit geringem Volumen skeptisch, bis die Stichprobe groß genug ist, um ihr zu vertrauen.

Gateway oder Anwendung für die Online-Evaluierung?

Beides, für unterschiedliche Signale. Das Gateway ist für das übergreifende Signal zuständig – die stichprobenartige Qualitätsmessung des Live-Traffics, aufgeschlüsselt nach Kosten und Latenz, die wiederum das Routing steuert –, da es jede Antwort sieht und die Routing-Entscheidung trifft. Die Anwendung ist für die Auswertung zuständig, die Kontext erfordert, über den das Gateway nicht verfügt, etwa ob die eigentliche Aufgabe des Nutzers erfolgreich war. Sie ergänzen sich, anstatt zu konkurrieren.

Die drei einfachen Signale sind immer die, die man zuerst implementiert, da die Infrastruktur sie direkt liefert. Qualität ist das Signal, für das man selbst sorgen muss – durch das Sampling von Antworten, deren ehrliche Bewertung, die Segmentierung dieser Ergebnisse und die Überwachung auf Regressionen. Bauen Sie dieses Signal direkt am Gateway auf, wo die Antworten und Routing-Entscheidungen ohnehin zusammenlaufen. So wird die nächste kostensparende Änderung, die unbemerkt die Qualität verschlechtert, zu einem Alarm am selben Tag statt zu einem zweiwöchigen Rätsel.

Referenzen

• TrueFoundry – KI-Gateway (Anfrage-/Antwort-Logs, Metadaten, Observability)
• TrueFoundry – Tracing
• TrueFoundry – OpenTelemetry für LLM-Gateway-Instrumentierung
• TrueFoundry – LLM-Kostenzuordnung nach Team und Budget
• TrueFoundry – Intelligentes LLM-Routing (der Kreis, den dieser Beitrag schließt)
• Zheng et al., „Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena“ (NeurIPS 2023) – die grundlegende LLM-as-a-Judge-Methode sowie deren eigene Darstellung von Positions-, Ausführlichkeits- und Selbstverstärkungs-Biases.
• Shi et al., „Judging the Judges: A Systematic Study of Position Bias in LLM-as-a-Judge“ (IJCNLP-AACL 2025) – Positions-Bias ist systematisch, nicht zufällig, und variiert stark je nach Modell und Aufgabe.

Northwind und Leena dienen ebenso wie die gezeigten Qualitätszahlen und Schwellenwerte lediglich der Veranschaulichung. LLM-as-a-Judge ist ein verrauschter Schätzer mit bekannten Verzerrungen und stellt keine absolute Wahrheit dar; die beschriebenen Werte sollten anhand menschlicher Labels kalibriert und als Trends betrachtet werden, anstatt sie als endgültige Urteile zu werten. Online-Evaluation reduziert blinde Flecken, garantiert aber keine Qualität. Die Funktionen von TrueFoundry sind gemäß der öffentlichen Produktdokumentation vom Juni 2026 zusammengefasst und unterliegen stetigen Weiterentwicklungen. Codebeispiele dienen der Veranschaulichung der beschriebenen Muster und sind keine Kopien einer Referenzimplementierung.

‍

‍