|Ben @ Grepture

LLM-Evals auf echtem Traffic — nicht nur Testsuiten

Grepture führt jetzt LLM-as-a-Judge-Bewertungen auf eurem tatsächlichen Produktionstraffic durch. Keine synthetischen Datensätze, keine separate Pipeline — kontinuierliche Qualitätsbewertung auf den Requests, die bereits durch euer Gateway fließen.

Die Eval-Lücke

Die meisten Teams wissen, dass sie ihre LLM-Outputs bewerten sollten. Nur wenige tun es tatsächlich in der Produktion.

Das typische Setup sieht so aus: Man baut eine Testsuite mit einer Handvoll Golden Examples, lässt sie in der CI vor Deploys laufen und hofft, dass diese Beispiele repräsentativ für das sind, was echte Nutzer tatsächlich senden. Manchmal stimmt das. Oft nicht. Die Prompts, die Nutzer in der Produktion schreiben, sind unordentlicher, länger und seltsamer als alles in euren Testfixtures. Die Edge Cases, die am meisten zählen, sind genau die, an die niemand gedacht hat.

Währenddessen liegen die wirklich interessanten Daten — die tatsächlichen Requests und Responses, die täglich durch eure AI-Pipeline fließen — in Logs, die niemand anschaut, bis etwas kaputtgeht.

Wir finden: Evals sollten dort laufen, wo die Daten bereits sind.

Evals in Grepture

Ab heute kann Grepture euren Produktions-AI-Traffic automatisch mit LLM-as-a-Judge-Scoring bewerten. Wenn ihr bereits Requests über unseren Proxy routet oder Traces über das SDK sendet, müsst ihr nichts Neues integrieren. Eure Traffic-Logs werden zum Evaluationsdatensatz.

So funktioniert es: Ihr erstellt einen Evaluator — entweder aus einem unserer Templates oder mit einem eigenen Judge-Prompt — und legt fest, welchen Traffic er bewerten soll. Grepture führt den Evaluator im Hintergrund gegen eure echten Logs aus und bewertet jede Antwort auf einer Skala von 0 bis 1, mit schriftlicher Begründung.

Keine synthetischen Datensätze. Keine separate Evaluations-Pipeline. Keine Batch-Jobs zum Verwalten. Euer Produktionstraffic ist die Testsuite.

Einen Evaluator einrichten

Evaluatoren sind Judge-Prompts mit Variablen. Mindestens braucht ihr {{output}} — die Antwort des LLMs. Zusätzlich könnt ihr {{input}} (die Nachricht des Nutzers) und {{system}} (den System-Prompt) für kontextbewussteres Scoring verwenden.

Wir liefern sechs Templates zum Einstieg:

  • Relevanz — adressiert die Antwort tatsächlich die Frage?
  • Nützlichkeit — ist die Antwort umsetzbar und hilfreich?
  • Toxizität — ist die Antwort sicher und angemessen?
  • Prägnanz — vermittelt die Antwort Informationen effizient?
  • Instruktionstreue — hält sich die Antwort an das, was der System-Prompt verlangt?
  • Halluzination — basiert die Antwort auf dem, was bereitgestellt wurde?

Template auswählen, den Prompt bei Bedarf anpassen und aktivieren. Das ist das Setup. Jeder Evaluator unterstützt außerdem Filter — nur Traffic von einem bestimmten Modell, Provider oder Prompt-ID bewerten — und eine Sampling-Rate, damit ihr kontrolliert, wie viel ihr für Judge-Tokens ausgebt.

Warum Produktionstraffic wichtig ist

Hier ist, was ihr aus der Bewertung von echtem Traffic lernt, das eine Testsuite nicht liefern kann:

Verteilungsverschiebungen. Eure Testsuite spiegelt wider, was ihr dachtet, das Nutzer fragen würden, als ihr sie geschrieben habt. Produktionstraffic zeigt, was sie heute tatsächlich fragen. Wenn sich das Nutzerverhalten ändert — und das tut es immer — fangen Evals auf echtem Traffic das auf. Eine statische Testsuite nicht.

Long-Tail-Fehler. Die Requests, die die schlechtesten Outputs verursachen, sind meist die, die niemand erwartet hat. Eine 5%-Halluzinationsrate über eure Testsuite kann eine 40%-Rate bei einer bestimmten Klasse von Nutzeranfragen verbergen, die ihr nie getestet habt. Kontinuierliche Evaluation macht diese Muster sichtbar.

Modell-Regressionen. Provider aktualisieren Modelle ohne Vorankündigung. Ein Minor-Version-Bump bei GPT-4o oder Claude kann die durchschnittliche Qualität verbessern, aber die Performance bei eurem spezifischen Anwendungsfall verschlechtern. Wenn ihr nur vor dem Deploy testet, fangt ihr keine Regressionen auf, die vom Modell-Provider eingeführt werden — nur die durch eure eigenen Codeänderungen.

Prompt-Drift. Wenn ihr Prompt-Management nutzt, ändert ihr Prompts ohne Code-Deployment. Das ist der Sinn der Sache. Aber jede Prompt-Änderung ist eine potenzielle Qualitätsänderung. Evals auf echtem Traffic geben euch ein kontinuierliches Qualitätssignal, das automatisch Prompt-Versionen folgt.

Was ihr seht

Jeder Evaluations-Score taucht an zwei Stellen auf.

Im Evals-Dashboard bekommt ihr das Gesamtbild: Score-Trends über die Zeit, Aufschlüsselung pro Evaluator, Durchschnittswerte und die Möglichkeit, in einzelne Bewertungen reinzuklicken und die Begründung des Judges zu lesen. Habt ihr letzten Dienstag einen Einbruch im Relevanz-Score bemerkt? Klickt durch und seht, welche Antworten niedrig bewertet wurden und warum.

Im Traffic-Log erscheinen Evaluations-Scores inline neben den Request-Details — Modell, Tokens, Kosten, Latenz und jetzt auch Qualitäts-Scores. Wenn ihr einen bestimmten Request untersucht, seht ihr alles an einem Ort: was gesendet wurde, was zurückkam, was es gekostet hat und wie gut es war.

Scores sind farbcodiert: Grün über 0,7, Gelb zwischen 0,4 und 0,7, Rot unter 0,4. Einfach genug zum schnellen Scannen, detailliert genug zum Untersuchen, wenn etwas auffällt.

Kosten kontrollieren

Ein Judge-LLM auf jeden Request laufen zu lassen wäre teuer und unnötig. Grepture gibt euch zwei Hebel:

Sampling-Rate. Stellt jeden Evaluator so ein, dass er 10 % des passenden Traffics bewertet, und ihr bekommt statistisch aussagekräftige Qualitätssignale zu einem Zehntel der Kosten. Bei hohem Volumen reichen sogar 1-5 %, um Trends und Regressionen zu erkennen.

Filter. Bewertet nur, was zählt. Scored Produktionstraffic, aber überspringt Entwicklungs-Requests. Bewertet nur euer kundengerichtetes Modell. Fokussiert euch auf einen bestimmten Managed Prompt, den ihr gerade aktiv iteriert. Filter halten den Judge auf Traffic fokussiert, wo Qualitätserkenntnisse umsetzbar sind.

Zwischen Sampling und Filtern geben die meisten Teams einen Bruchteil dessen aus, was sie erwarten — bei Qualitätstransparenz, die sie vorher nie hatten.

Warum das Gateway der richtige Ort dafür ist

Andere Evaluationstools verlangen, dass ihr Logs exportiert, eine separate Pipeline aufbaut und eine weitere Integration verwaltet. Das funktioniert, aber es ist Reibung — und Reibung bedeutet, dass die meisten Teams es nie umsetzen.

Grepture hat euren Traffic bereits. Jeder Request und jede Response ist bereits mit vollem Kontext geloggt: die gesendeten Nachrichten, die erhaltene Completion, das Modell, die Tokens, die Kosten. Evaluation ist eine natürliche Erweiterung dessen, was das Gateway bereits tut. Keine Daten zu exportieren, keine Pipeline zu bauen, keine Integration zu pflegen.

Das ist dasselbe Muster, das Trace-Modus und Prompt-Management in Grepture gut funktionieren lässt: Wenn man bereits im Pfad jedes AI-Calls ist, ist das Hinzufügen von Fähigkeiten inkrementell statt architektonisch.

Was als Nächstes kommt

Evals geben euch heute einen Qualitäts-Score im Dashboard. Das ist ein Startpunkt. Wir arbeiten daran, dass Evals euch aktiv informieren, wenn etwas schiefläuft:

  • E-Mail- und Slack-Alerts — werdet benachrichtigt, wenn Durchschnittswerte unter einen Schwellenwert fallen, damit ihr nicht das Dashboard überwachen müsst
  • Webhook-Integrationen — leitet Evaluationsergebnisse in eure bestehenden Monitoring- und Incident-Response-Workflows
  • Geplante Reports — wöchentliche Qualitätszusammenfassungen mit Score-Trends, Top-Regressionen und markierten Antworten

Das Ziel ist, Qualitätsmonitoring so hands-off zu machen wie den Rest von Greptures Pipeline. Evaluatoren einrichten, Schwellenwerte setzen und darauf vertrauen, dass ihr informiert werdet, wenn etwas schlechter wird.

Jetzt ausprobieren

Wenn ihr bereits auf Grepture seid, geht zum Evals-Tab in eurem Dashboard und erstellt euren ersten Evaluator. Startet mit einem der Templates — Relevanz oder Halluzination sind gute erste Picks —, setzt eine niedrige Sampling-Rate und lasst es einen Tag laufen. Morgen früh habt ihr echte Qualitätsdaten über euren Produktions-AI-Traffic.

Wenn ihr noch nicht auf Grepture seid, ist das ein guter Grund zum Einstieg. SDK einbinden, Traffic durch den Proxy leiten (oder Trace-Modus für latenzfreies Logging nutzen) und ihr habt Kostentransparenz und Qualitätsbewertung vom ersten Tag an.