Die Aenderung, die Sie nicht testen koennen
Eine Einzeiler-Aenderung an Ihrer LLM-Schicht kann stillschweigend eine ganze Klasse von Anfragen kaputtmachen, an die Sie gerade nicht gedacht haben. Einen System-Prompt verschaerfen, auf eine neue Modellversion wechseln, einen Satz gegen das Abschweifen hinzufuegen - jede dieser Aenderungen kann Ausgaben verschlechtern, die Sie nicht kommen sehen.
Es gibt keine guenstige Moeglichkeit, das zu erkennen, bevor Ihre Nutzer es tun. Die meisten Test-Suites enthalten ein Dutzend handgeschriebener Eingaben, die echtem Traffic nicht aehneln - also wird die Auslieferung in die Produktion zum eigentlichen Test, und dann sitzt die Regression bereits vor den Kunden. Die Anfragen, die am ehesten kaputtgehen, sind genau die, fuer die niemand ein Fixture geschrieben hat.
Replay schliesst diese Luecke: Nehmen Sie eine Anfrage, die bereits passiert ist, lassen Sie sie durch Ihre geplante Aenderung laufen und vergleichen Sie.
Was Replay tatsaechlich ist
Jede Anfrage, die durch Ihr Gateway laeuft, wird protokolliert - die gesendeten Nachrichten, die zurueckgegebene Antwort, das Modell, die Tokens, die Kosten. Eine protokollierte Anfrage ist eine echte, repraesentative Eingabe. Replay nimmt eines dieser Logs und fuehrt es erneut aus.
In Grepture oeffnen Sie eine beliebige Anfrage in Ihrem Traffic-Log, klicken auf Replay, und die Anfrage wird genau so in den Playground geladen, wie sie gesendet wurde: der Body, das Modell, der Ziel-Endpunkt. Von dort aendern Sie eine Sache - den Prompt bearbeiten, das Modell wechseln, einen Parameter anpassen - und fuehren sie erneut gegen den Live-Anbieter aus. Sie erhalten die neue Antwort direkt neben dem Original.
Das ist der Unterschied zwischen Replay und einem synthetischen Testfall. Sie raten nicht, wie eine schwierige Eingabe aussieht. Sie verwenden eine, die Ihr System wirklich getroffen hat, mit dem gesamten Chaos, das echte Nutzer mitbringen: die seltsame Formulierung, die halbfertige Frage, der Grenzfall, der nur in der Produktion auftaucht.
Bewusst die redigierte Anfrage abspielen
Ein Detail verdient eine explizite Erwaehnung, weil es eine bewusste Designentscheidung ist und keine Einschraenkung.
Replay sendet die Anfrage nach der Redigierung erneut - exakt den Body, der nach dem Durchlauf der PII-Pipeline von Grepture stromaufwaerts weitergeleitet wurde, nicht die urspruengliche Roh-Eingabe. Wenn die E-Mail-Adresse eines Kunden beim ersten Mal maskiert wurde, bevor die Anfrage Ihr Gateway verliess, bleibt sie auch im Replay maskiert. PII wird in einer abgespielten Antwort niemals wiederhergestellt.
Das macht Replay bedenkenlos einsetzbar. Sie koennen jede Produktionsanfrage abspielen - auch solche, die urspruenglich sensible Daten enthielten - ohne diese Daten erneut einem Modell oder der testenden Person preiszugeben. Im Playground ist das Original mit "Redigiert - sicher abzuspielen" gekennzeichnet, damit kein Zweifel besteht, was Sie senden. Abgespielte Durchlaeufe werden ausserdem in ihren Metadaten markiert und aus Ihren Analysen ausgeschlossen, sodass ein Tag voller Regressionstests Ihre echten Traffic-Zahlen oder Kostenberichte nicht verfaelscht.
Der Kompromiss: Replay ist eine erneute Ausfuehrung gegen ein Live-Modell, kein bit-genauer Snapshot. Sampling, Temperatur und anbieterseitige Aenderungen bedeuten, dass die neue Ausgabe nicht deterministisch ist. Das ist in Ordnung - und wohl auch korrekt. Sie behaupten nicht, dass das Modell jedes Mal dieselben Zeichen zurueckgibt. Sie fragen, ob Ihre Aenderung die Ausgaben bei echten Eingaben besser oder schlechter macht.
Vergleichen auf die Art, die zaehlt: Bewertungen statt Augenmass
Zwei Ausgaben nebeneinander zu lesen und zu entscheiden, welche besser ist, funktioniert bei einer Anfrage. Bei fuenfzig funktioniert es nicht, und wenn "besser" subjektiv ist, funktioniert es gar nicht.
Deshalb bewertet Replay die neue Ausgabe gegen das Original mit Ihren Evaluatoren. Wenn Sie bereits LLM-as-a-Judge-Evaluationen auf Produktions-Traffic laufen lassen, gelten dieselben Judge-Prompts auch hier. Wenn Sie eine abgespielte Anfrage erneut ausfuehren, bewertet Grepture die neue Ausgabe, stellt sicher, dass das Original mit denselben Evaluatoren bewertet wird, und zeigt Ihnen beide samt der Differenz dazwischen:
Relevanz 0.62 → 0.81 +0.19
Anweisungstreue 0.90 → 0.74 −0.16
Praegnanz 0.55 → 0.88 +0.33
Jetzt hat die Aenderung eine Form. Die Prompt-Bearbeitung, mit der Sie die Antworten straffen wollten? Sie hat Praegnanz und Relevanz verbessert, Sie aber bei dieser Anfrage Anweisungstreue gekostet. Vielleicht ist das ein akzeptabler Kompromiss. Vielleicht ist es eine Regression, die Sie beim blossen Ueberfliegen des Textes nie bemerkt haetten. So oder so treffen Sie die Entscheidung mit einer Zahl vor Augen statt mit einem Bauchgefuehl.
Die Bewertungen sind farblich kodiert - gruen ueber 0.7, gelb zwischen 0.4 und 0.7, rot darunter - sodass eine Regression etwas ist, das Sie sehen, und nicht etwas, das Sie suchen muessen.
Von einer Anfrage zu einer echten Test-Suite
Replay einzelner Anfragen ist das richtige Werkzeug, wenn Sie eine bestimmte schlechte Ausgabe untersuchen oder eine schnelle Prompt-Aenderung pruefen. Aber dieselbe Idee skaliert, und dort wird sie zu einem echten Regressionstest-Workflow.
Wenn Sie eine erhaltenswerte Anfrage finden - einen Fehlerfall, einen kniffligen Grenzfall, ein repraesentatives Beispiel - fuegen Sie sie mit einem Klick zu einem Dataset hinzu. Noch besser: Richten Sie eine Auto-Sammelregel ein - jede Anfrage, die bei Ihrem Halluzinations-Evaluator unter 0.5 liegt, landet automatisch in einem Dataset. Innerhalb einer Woche sammeln Sie eine lebendige Kollektion genau der Eingaben, mit denen Ihr System Probleme hat - keine handverlesene Stichprobe, sondern den echten Long Tail.
Dann fuehren Sie ein Experiment durch. Nehmen Sie ein Dataset, richten Sie es auf eine neue Prompt-Version oder ein anderes Modell, und Grepture spielt jedes Element erneut ab, bewertet jede Ausgabe mit Ihren Evaluatoren und erfasst Tokens, Kosten und Dauer pro Element. Vergleichen Sie zwei Experimente, und Sie erhalten einen Diff pro Element: welche Eingaben sich verbessert haben, welche zurueckgefallen sind und um wie viel.
Es ist dieselbe Schleife wie beim Replay einzelner Anfragen, nur in grossem Massstab:
- Erfassen Sie echte Anfragen aus dem Produktions-Traffic.
- Spielen Sie sie gegen Ihre geplante Aenderung ab.
- Bewerten Sie die neuen Ausgaben gegen die Baseline.
- Liefern Sie nur aus, wenn die Differenzen dort gruen sind, wo es darauf ankommt.
Der Ein-Klick-Replay beantwortet "hat das diese Anfrage kaputtgemacht?". Der Dataset-plus-Experiment-Ablauf beantwortet "hat das irgendeine der Anfragen kaputtgemacht, die mir wichtig sind?". Sie greifen zu dem, was der Moment verlangt.
Warum das Gateway der richtige Ort dafuer ist
Replay funktioniert nur, wenn die Anfragen bereits vorhanden sind - vollstaendig und mit genug Kontext, um sie erneut auszufuehren und neu zu bewerten. Genau das hat ein Gateway.
Grepture liegt bereits im Pfad jedes KI-Aufrufs. Es hat den Anfrage-Body, die Antwort, das Modell und die Kosten bereits protokolliert. Es hat bereits Ihre Redigierungs-Pipeline ausgefuehrt und weiss daher, welche Version der Anfrage sicher abzuspielen ist. Und es hat bereits Ihre Evaluatoren und kann das Ergebnis ohne separate Pipeline bewerten. Replay ist kein neues System, das Sie integrieren - es ist das, was natuerlich entsteht, wenn das Gateway bereits alles erfasst hat.
Das ist dasselbe Muster wie hinter Evals auf echtem Traffic und Prompt-Management: Sobald Sie im Pfad jeder Anfrage liegen, sind neue Faehigkeiten inkrementell statt architektonisch. Ein eigenstaendiges Replay-Werkzeug muesste Sie Logs exportieren, Anfrage-Bodies neu aufbauen, einen Modell-Client verdrahten und die Redigierung selbst verwalten lassen. Am Gateway ist das alles bereits geloest.
Wann Sie zu Replay greifen sollten
Ein paar Momente, in denen sich das auszahlt:
- Bevor eine Prompt-Aenderung ausgeliefert wird. Rufen Sie die Anfragen auf, die die Aenderung motiviert haben, spielen Sie sie gegen den neuen Prompt ab und bestaetigen Sie, dass er sie wirklich behebt, ohne den Rest zu verschlechtern.
- Wenn ein Anbieter ein Modell abkuendigt. Sie werden auf eine neue Version gezwungen. Spielen Sie einen repraesentativen Ausschnitt des Traffics dagegen ab und pruefen Sie, ob Ihre Qualitaetswerte halten, bevor Sie umschalten.
- Nach einem Vorfall. Sie haben eine schlechte Ausgabe in der Produktion gefunden. Spielen Sie sie gegen einen moeglichen Fix ab und verifizieren Sie, dass der Fix bei der echten Eingabe funktioniert, nicht bei einer Naeherung davon.
- Beim Aufbau einer Regressions-Suite. Sammeln Sie niedrig bewerteten Traffic automatisch in einem Dataset und fuehren Sie es bei jeder Prompt-Aenderung als Experiment aus, damit derselbe Fehler nie zweimal ausgeliefert wird.
Wenn Sie Grepture nutzen, oeffnen Sie vor Ihrer naechsten Prompt-Aenderung eine beliebige Anfrage in Ihrem Traffic-Log und klicken Sie auf Replay. Falls noch nicht, legen Sie los - leiten Sie Ihren Traffic durch das Gateway, und Sie haben Replay, Evals und Kostentransparenz vom ersten Tag an.
- Wie Grepture funktioniert - Architekturueberblick
- LLM-Evals auf echtem Traffic - die Bewertung, die den Replay-Vergleich antreibt
- Datasets: Produktions-Logs als Test-Suites - Replay in grossem Massstab
- Prompt-Management und Versionskontrolle - versionieren Sie die Prompts, die Sie testen