Wie man in einer Woche ein Retrieval-Eval-Set baut.

Wenn Ihr RAG-System kein Eval-Set hat, ist jede Prompt-Änderung ein gefühlsbasierter Release. Die gute Nachricht: Sie können in einer Woche ein nützliches Eval-Set bauen. Kein perfektes — ein nützliches. Perfekt ist die Falle, die Teams davon abhält, überhaupt evals zu haben.

Hier ist das Rezept, das wir in Engagements verwenden, wo der Kunde an Tag eins 0–5 evals hat und am Ende der Woche 200 braucht.

Die Form

Sie wollen drei Dinge:

1. Ein eingefrorenes Corpus — die tatsächlichen Dokumente, über die Ihr System retrievet, zu einem Zeitpunkt gesnapshotet.
2. 200 Fragen, die ein echter Nutzer stellen könnte, mit Ground-Truth-Antworten und Zitaten.
3. Ein Held-out-Set — 30 dieser 200, weggeschlossen, niemals zum Tunen verwendet.

Das Held-out-Set ist das wichtigste und das am häufigsten übersprungene. Wir kommen darauf zurück.

Tag 1–2: Echte Fragen abbauen

Überspringen Sie „Was würden Nutzer fragen?"-Workshops. Sie produzieren Fragen, die nie ein Nutzer tatsächlich gestellt hat. Gehen Sie zu Ihren Quellen:

• Support-Tickets, die irgendein Thema erwähnen, das das RAG abdeckt.
• Suchlogs von Ihrer bestehenden Suchleiste, falls Sie eine haben.
• Slack-Channels, in denen Leute die Frage intern stellen.
• Die Chatlogs von Ihrem aktuellen LLM-System, falls Sie eines am Laufen haben.

Zielen Sie auf 250 rohe Fragen. Deduplizieren, Phrasing normalisieren, die offensichtlich-out-of-scope wegwerfen. Sie landen bei ~200.

Tag 3: Nach Schwierigkeit und Topic taggen

Bucketen Sie jede Frage:

• Schwierigkeit: trivial (Antwort ist in einem Absatz), mittel (Antwort erfordert Synthese aus 2–3 Dokumenten), schwer (erfordert Verständnis einer Prozedur oder Regel).
• Topic-Bereich — meist 5–15 Buckets, je nach Domäne.
• Adversarial-Flag — Fragen, die darauf ausgelegt sind, bekannte Failure-Modes zu triggern (out-of-scope, widersprüchliche Infos, kürzlich aktualisierte Infos).

Sie wollen einen Mix. Eine Suite mit 90% trivialen Fragen sagt Ihnen, dass Ihr System großartig ist, und Sie deployen eine Regression, weil die mittleren und schweren Fälle gebrochen sind.

Tag 4: Ground Truth

Für jede Frage brauchen Sie:

• Die erwartete Antwort — geschrieben, 1–3 Sätze, die Antwort, die ein Domänenexperte geben würde.
• Die unterstützenden Passagen — Pointer (Doc-IDs, Line-Ranges, Chunk-IDs) zu den Teilen des Corpus, die retrievet werden sollten, um die Frage zu beantworten.

Das ist der langsame Teil. Planen Sie ~3 Minuten pro Frage = ~10 Stunden für 200 Fragen. Zwei Personen parallel, eine halbe Woche. Verwenden Sie einen Domänenexperten.

Lohnt sich. Das ist der Teil, der „das LLM hat etwas Plausibles gesagt" in „das LLM hat die richtige Quelle zitiert und die richtige Antwort bekommen" verwandelt.

Tag 5: Baselines + Metriken

Lassen Sie Ihr aktuelles System (oder einen Stub, falls Sie keines haben) gegen die 170 sichtbaren Fragen laufen. Erfassen Sie:

• Retrieval@k: Enthielten die top-k retrieveten Chunks die erwarteten unterstützenden Passagen?
• Antwort-Korrektheit: bewertet von einem LLM-Judge gegen die erwartete Antwort, mit der Held-out-Referenz. Kalibrieren Sie den Judge gegen ~30 menschliche Bewertungen, um sicherzustellen, dass er nicht einfach durchwinkt.
• Zitations-Präzision: Welcher Bruchteil der zurückgegebenen Zitate stützt tatsächlich die Aussage?

Sie haben jetzt Baselines. Jede zukünftige Prompt- oder Retrieval-Änderung erscheint als Delta zu diesen.

Das „dies nicht optimieren"-Set

Die 30 Held-out-Fragen existieren aus einem Grund: Sie selbst zu ertappen.

Jedes Team, das ein Eval-Set baut, beginnt irgendwann, das System gegen das Eval-Set zu tunen. Neue Prompt-Revision, evals laufen lassen, Score ist gestiegen, ship. Drei Monate später ist Ihr In-Suite-Score bei 95% und Ihre Nutzerzufriedenheit unverändert, weil Sie überfittet haben.

Die Held-out-30-Fragen werden nur während vierteljährlicher Health-Checks ausgeführt. Wenn sie regredieren, während der Rest der Suite sich verbessert, ist das der Rauchmelder für Overfitting. Sie sind ein Check auf den Check.

Schauen Sie sie nicht an. Fügen Sie nichts hinzu. Substituieren Sie keine Äquivalente. Sperren Sie sie in einen Tresor.

Was Sie damit bekommen

• Ein reproduzierbares Signal, das Prompt- und Retrieval-Änderungen gatet.
• Eine Baseline, gegen die Sie neue LLM-Versionen evaluieren können.
• Eine verteidigbare Antwort auf „Woher wissen Sie, dass Ihr RAG irgendwas taugt?"

Bauen Sie die v1 in einer Woche. Iterieren Sie die Fragen monatlich. Ersetzen Sie das Held-out-Set einmal pro Jahr.

Sie werden nie Zeit haben, das perfekte Eval-Set zu bauen. Sie haben absolut Zeit, das nützliche zu bauen.