Das Problem mit statischen Testsuiten
Jedes Team, das mit LLMs baut, schreibt irgendwann eine Testsuite. Ihr wählt ein paar Dutzend Inputs aus, notiert, wie eine gute Antwort aussieht, und lasst sie vor jedem Deploy laufen. Das fängt offensichtliche Regressionen auf und gibt euch etwas, auf das ihr zeigen könnt, wenn jemand fragt: "Woher wisst ihr, dass es funktioniert?"
Das Problem ist, dass Testsuiten fast sofort veralten.
Die Beispiele, die ihr letztes Quartal geschrieben habt, spiegeln wider, was ihr dachtet, dass eure Nutzer fragen würden. Echte Nutzer schreiben anders — unordentlichere Inputs, unerwartete Kombinationen, fachspezifischen Jargon, den ihr nicht antizipiert habt. Mit der Zeit driftet die Verteilung eurer Testsuite immer weiter von der Verteilung eures tatsächlichen Traffics weg. Ihr besteht weiterhin die Tests und verpasst die Fehler.
Dazu kommt das Wartungsproblem. Edge Cases, die euch heute wichtig sind, waren nicht in eurer ursprüenglichen Testsuite. Ihr findet eine schlechte Antwort in der Produktion, macht euch einen mentalen Vermerk, sie zur Testsuite hinzuzufügen, und kommt nie dazu. Die Faelle, die am meisten zählen, sind genau die, die es nicht in die Fixture-Dateien schaffen.
Das tiefere Problem ist, dass statische Eval-Sets erfordern, dass ihr voraussagt, was wichtig ist. Produktionstraffic nicht. Er zeigt es euch.
Euer Traffic ist bereits eine Testsuite
Die Requests, die täglich durch eure AI-Pipeline fließen, enthalten etwas, das eine kuratierte Fixture-Datei niemals bieten kann: Ueberraschungen. Echte Nutzer stoßen auf Faelle, die ihr nicht entworfen habt. Sie schreiben Prompts, die Luecken in eurem System-Prompt aufdecken. Sie kombinieren Inputs auf eine Art, die euer Modell zum Halluzinieren bringt, vom Thema abweichen laesst oder Outputs produziert, die ihr nicht shippen wuerdet.
Diese Information liegt bereits in euren Logs. Das einzige Problem ist, dass sie unstrukturiert ist — ein Datenstrom aus Traffic ohne Moeglichkeit, die interessanten Teile systematisch zu erfassen und wiederzuverwenden.
Das ist es, was Grepture Datasets loest. Es gibt euch die Werkzeuge, um Produktionstraffic in ein strukturiertes, wiederverwendbares Eval-Set zu verwandeln — ohne dass ihr Daten exportieren, eine Pipeline aufbauen oder ein separates System pflegen muesst.
Drei Wege, ein Dataset zu erstellen
Nicht alle Datasets haben denselben Ursprung. Grepture unterstuetzt drei Modi, und in der Praxis nutzt ihr alle drei.
1. Manuelle Kuration
Manchmal wisst ihr genau, was ihr wollt. Ihr habt eine Reihe von Inputs, die wichtige Nutzerszenarien repraesentieren — einen Onboarding-Flow, eine bestimmte Art von Support-Ticket, eine komplexe mehrstufige Reasoning-Aufgabe. Das Dataset wird manuell aufgebaut, indem jedes Input/Output-Paar direkt angegeben wird.
Das ist der richtige Ansatz fuer Szenarien, fuer die ihr Abdeckung garantieren wollt. Ein Golden Set von 20-30 hochwertigen Beispielen, das ihr bewusst pflegt. Langsam aufzubauen, aber mit hohem Signal.
2. Import aus Traffic-Logs
Das ist der haeufigere Weg. Ihr reviewt eure Traffic-Logs — vielleicht untersucht ihr eine Beschwerde, prueft Scores aus einem aktuellen Eval-Run oder macht einfach einen Quality-Spot-Check — und seht einen Request, der es wert ist, aufbewahrt zu werden.
In Grepture erfordert das Hinzufuegen zu einem Dataset einen einzigen Klick. Traffic-Log durchsuchen, den Request finden und auf "Add to Dataset" klicken. Ihr koennt ihn zu einem bestehenden Dataset hinzufuegen oder sofort ein neues erstellen. Input, Output, Modell und Metadaten kommen alle mit.
Im Laufe der Zeit werden eure besten Datasets so aufgebaut. Nicht in einer einzigen Planungssession, sondern als natuerliches Nebenprodukt von Qualitaetsarbeit — interessante Faelle erfassen, sobald man auf sie stoesst, nicht rueckwirkend.
3. Auto-Collection-Rules
Der maechtigste Modus. Anstatt Requests manuell auszuwaehlen, definiert ihr einen Filter und Grepture erfasst passenden Traffic automatisch, sobald er eintrifft.
Rules koennen nach folgenden Kriterien filtern:
- Modell oder Provider — nur Traffic erfassen, der ueber ein bestimmtes Modell geroutet wird
- Prompt — nur Requests erfassen, die einen bestimmten Managed Prompt verwendet haben
- Status-Code — Fehler oder Erfolge selektiv erfassen
- Evaluator-Scores — Requests erfassen, die bei eurem Halluzinations-Evaluator unter 0,5 gescort haben, zum Beispiel
Letzteres ist besonders nuetzlich. Wenn ihr Evaluatoren auf Produktionstraffic laufen habt, koennt ihr Auto-Collection auf den niedrig scorenden Tail richten. Jeder Request, bei dem euer Judge ein potenzielles Problem markiert hat, landet automatisch in einem Dataset. Am Ende habt ihr eine kontinuierlich wachsende Sammlung der tatsaechlichen Failure-Faelle — keine handverlesene Auswahl, sondern eine lebendige Aufzeichnung davon, wo euer System Schwierigkeiten hat.
Einmal einrichten und vergessen. Das Dataset waechst von selbst.
Experimente gegen ein Dataset ausfuehren
Ein Dataset ist am nuetzlichsten, wenn ihr systematisch dagegen testen koennt. Dafuer sind Experimente da.
Grepture-Experimente haben zwei Modi, und der Unterschied ist wichtig.
Der Run-Modus nimmt eine Prompt-Version und ein Modell, fuehrt jeden Input im Dataset gegen diese Konfiguration aus und bewertet die Ergebnisse dann mit euren gewaehlten Evaluatoren. Damit beantwortet ihr Fragen wie: "Wenn ich auf diesen neuen Prompt wechsle, wie performt er auf meinen bekannten Edge Cases?" Ihr generiert neue Outputs und messt sie.
Der Evaluate-Modus bewertet bestehende Outputs neu. Vielleicht habt ihr vor drei Wochen ein Dataset gesammelt und wollt jetzt einen neuen Evaluator anwenden, den es damals noch nicht gab. Oder ihr wollt dieselben Outputs mit einem strengeren Judge bewerten. Ihr fuehrt die Prompts nicht erneut aus — ihr wendet neue Bewertungskriterien auf Outputs an, die bereits vorhanden sind.
So startet ihr ein Experiment:
- Dataset auswaehlen
- Prompt-Version (aus euren Managed Prompts) und Modell waehlen
- Einen oder mehrere Evaluatoren auswaehlen
- Ausfuehren
Grepture fuehrt jeden Dataset-Eintrag aus, bewertet jeden Output mit eurem Judge und speichert die Ergebnisse. Ihr bekommt pro Item Scores (0 bis 1) zusammen mit der schriftlichen Begruendung des Judges, warum er diesen Score vergeben hat. Verbrauchte Tokens, Kosten und Dauer werden pro Item getrackt, damit ihr wisst, was das Experiment zu laufen gekostet hat.
Das ist bereits fuer sich genommen nuetzlich. Aber es wird nuetzlicher, wenn ihr ein zweites Experiment ausfuehrt und vergleicht.
Experimente vergleichen
Prompt-Aenderungen sind guenstig durchzufuehren und teuer, wenn sie falsch bewertet werden. Einen Prompt laesst sich in fuenf Minuten umschreiben — und dann verbringt man Wochen damit, die eingebrachten Regressionen zu finden.
Die Vergleichsansicht in Grepture zeigt zwei Experimente nebeneinander, Item fuer Item. Fuer jeden Input in eurem Dataset seht ihr:
- Den Output aus Experiment A
- Den Score aus Experiment A
- Den Output aus Experiment B
- Den Score aus Experiment B
Items, bei denen B besser abgeschnitten hat als A, sind hervorgehoben. Genauso Items, bei denen A besser war. Items mit signifikanten Score-Aenderungen — in beide Richtungen — sind leicht auffindbar.
Das verwandelt, was frueher ein subjektives Urteil war ("Ich glaube, der neue Prompt ist besser"), in ein strukturiertes Diff. Ihr seht nicht nur die Gesamt-Score-Aenderung, sondern genau, welche Inputs sie verursacht haben. Ein Prompt, der im Durchschnitt besser ist, aber bei einer bestimmten Klasse von Edge Cases schlechter abschneidet, ist sofort sichtbar — anstatt etwas zu sein, das ihr zwei Wochen spaeter durch einen Produktionsvorfall entdeckt.
Ihr koennt ueber Prompt-Versionen, ueber Modelle oder ueber beides hinweg vergleichen. Wenn ihr bewertet, ob ihr von GPT-4o auf ein neueres Modell wechseln sollt, fuehrt dasselbe Dataset gegen beide Konfigurationen aus und vergleicht die Ergebnisse. Der Score-Unterschied ist eure Antwort.
Der Workflow in der Praxis
Die einzelnen Features — Datasets, Auto-Collection, Experimente, Vergleich — passen zu einem Workflow zusammen, der die Prompt-Iteration systematischer macht.
Ihr beginnt mit dem Aufbau eines Datasets. Ein paar manuell kuratierte Beispiele zum Start, plus eine Auto-Collection-Rule, die auf euren niedrig scorenden Traffic zeigt. Eine Woche laufen lassen. Jetzt habt ihr ein Dataset mit euren Golden Cases und einer wachsenden Sammlung echter Fehler.
Wenn ihr einen Prompt aendern wollt, oeffnet ihr das Dataset, startet ein Experiment und fuehrt die neue Prompt-Version dagegen aus. Ihr seht, wie sie bei den Beispielen performt, die euch wichtig sind, und bei den Failure-Faellen, die ihr gesammelt habt. Wenn die neue Version die Scores bei den Fehlern verbessert, ohne bei den Golden Cases zu regressieren, habt ihr Belege dafuer, dass es eine echte Verbesserung ist.
Ihr published den Prompt. Ihr behaltet das Dataset. Wenn ihr das naechste Mal den Prompt aendert, fuehrt ihr ihn wieder gegen dasselbe Dataset aus. Mit der Zeit wird das Dataset zu einem Protokoll eures Quality-Floors — dem Mindeststandard, den eure Prompts erfuellen muessen, bevor ihr shipped.
Das ist die Schleife: Edge Cases aus der Produktion erfassen, Dataset aufbauen, Prompt-Aenderungen gegen das Dataset testen, mit Zuversicht shippen. Es ist dieselbe Disziplin, die Software-Engineering systematisch macht, angewandt auf die Prompt-Ebene.
Datasets und Evaluatoren sind gemeinsam staerker
Datasets sind ein Pro-Tier-Feature und wurden so entwickelt, dass sie mit Evaluatoren zusammenarbeiten. Wenn ihr bereits Evals auf Produktionstraffic ausfuehrt, habt ihr zwei Dinge, die Datasets benoetigen: einen Strom von gescorten Requests, um Auto-Collection-Rules zu befuellen, und Judge-Prompts, die als Experiment-Evaluatoren verwendet werden koennen.
Wenn ihr noch keine Evals laufen habt, ist der Evals-Tab der richtige Ausgangspunkt. Bringt einen Relevanz- oder Halluzinations-Evaluator auf eurem Traffic zum Laufen, lasst etwas History aufbauen, und beginnt dann damit, niedrig scorende Requests in einem Dataset zu sammeln. Innerhalb von ein bis zwei Wochen habt ihr eine aussagekraeftige Sammlung, gegen die ihr Experimente laufen lassen koennt.
Die Kombination veraendert, wie Qualitaetsarbeit aussieht. Anstatt einmaliger Spot-Checks und Bauchgefuehlsurteilen darueber, ob eine Prompt-Aenderung besser ist, habt ihr einen wiederholbaren Prozess: Dataset aus echten Fehlern aufbauen, Aenderungen dagegen testen, das Delta messen, den Gewinner shippen.