Auf dieser Seite
Die kurze Antwort
Ein nützlicher Bewertungsdatensatz zeichnet die Eingabe, den relevanten Kontext, das erwartete Verhalten, die Herkunft und die Fehlerkategorie für jeden Fall auf. Kombinieren Sie autorisierte reale Beispiele mit sorgfältig überprüften synthetischen Fällen und bewahren Sie einen vorgehaltenen Satz für Entscheidungen auf, die durch das Tuning nicht beeinflusst werden sollten.
Was zum Mitnehmen
- Speichern Sie, warum ein Fall existiert, nicht nur seine Aufforderung und Antwort.
- Synthetische Beispiele erweitern die Abdeckung, erfordern jedoch eine unabhängige Validierung.
- Halten Sie Datensatzänderungen versioniert und überprüfbar.
Quellen überprüft . Forschungssynthese und Rubrex-Empfehlungen. Beispiele und lokale Experimente sind gekennzeichnet; es handelt sich nicht um Kundenergebnisse.
Neuere Arbeiten machen die Datensatzstruktur zu einer Designentscheidung
HieraRAG, ein Preprint vom Juni 2026, untersucht die Granularität synthetischer Fragen in RAG-Benchmarks. Es definiert die Granularität als etwas, das innerhalb einer bestimmten Abrufkonfiguration bewertet werden muss. Dies unterstützt die Frage, welche Unterschiede ein Datensatz aufzeigt, anstatt davon auszugehen, dass mehr Fragen automatisch zu einem besseren Benchmark führen.
Evaluationsdaten und Trainingsdaten dienen unterschiedlichen Entscheidungen
Trainingsbeispiele helfen dabei, das Verhalten eines Modells zu ändern. Ein Bewertungsdatensatz testet ein definiertes Verhalten anhand von Referenznachweisen oder Bewertungskriterien. Rubrex empfiehlt, die zur Optimierung von Eingabeaufforderungen oder Modellen verwendeten Fälle getrennt von einem zurückgehaltenen Entscheidungssatz aufzubewahren. Wenn das Team einen fehlgeschlagenen Test untersucht und das System ändert, um ihn zu bestehen, behalten Sie diesen Fall als Regressionsprüfung bei, verwenden jedoch neue zurückgehaltene Fälle, um zu beurteilen, ob sich die Änderung verallgemeinert.
Synthetische Beispiele können dabei helfen, ungewöhnliche Eingaben, fehlende Beweise oder Berechtigungsgrenzen abzudecken. Vergleichen Sie jede Frage und das erwartete Ergebnis mit dem Quellmaterial, bevor Sie sie annehmen. Notieren Sie, wie das Beispiel erstellt wurde und welchen Fehler es darstellt. Ein großer Trainingskorpus oder eine Sammlung automatisch generierter Frage-Antwort-Paare ist an sich kein validierter Bewertungssatz.
Definieren Sie den Datensatz, bevor Sie Beispiele sammeln
Rubrex empfiehlt einen Falldatensatz mit einer unveränderlichen Kennung, Eingabe, zulässigem Kontext, erwartetem Verhalten, Quellkategorie, Erfassungsdatum und Prüferstatus. Geben Sie für einen Tool-verwendenden Workflow den Anfangszustand und den autorisierten Endzustand an. Verwenden Sie für offenes Schreiben eine verankerte Rubrik, anstatt einen genauen Satz zu verlangen.
Notieren Sie, ob der Fall aus der Produktion, einer Support-Eskalation, einem Domänenspezialisten oder einer synthetischen Generierung stammt. Behalten Sie eine öffentlich zugängliche Beschreibung seines Ursprungs bei, auch wenn die rohe Interaktion nicht beibehalten werden kann. Ein Datensatz sollte nicht stillschweigend vertrauliche Informationen erfassen, nur weil ein Protokollexport praktisch ist.
Bauen Sie die Abdeckung bewusst auf
Ordnen Sie das Produkt in sinnvolle Slices zu, bevor Sie Eingabeaufforderungen schreiben. Beispiele hierfür sind Aufgabentyp, Dokumentalter, Eingabelänge, Beweisverfügbarkeit, Sprache und Benutzerberechtigung. Vermeiden Sie das vollständige kartesische Produkt, wenn es Kombinationen erzeugt, die nicht auftreten können. Priorisieren Sie Kombinationen mit tatsächlicher Exposition oder einer spezifischen Fehlerhypothese.
Geben Sie für synthetische Fälle das betonte Verhalten an und lassen Sie in einem separaten Überprüfungsschritt überprüfen, ob die Eingabe plausibel ist und die Referenz unterstützt wird. Ein Modell kann sowohl eine fehlerhafte Frage als auch eine passende fehlerhafte Antwort generieren. Die Übereinstimmung zwischen diesen beiden Artefakten ist keine unabhängige Validierung.
| Feld | Zweck |
|---|---|
| case_id | Stabile Identität über Läufe und Revisionen hinweg |
| erwartetes_verhalten | Die beobachtbare Anforderung, einschließlich akzeptabler Unsicherheit |
| Herkunft | Herkunft, Nutzungsberechtigung und Sammlungskontext |
| Slice_tags | Die dargestellten Aufgaben- und Fehlerbedingungen |
| review_status | Wer oder was hat die Referenz validiert und ob Unklarheiten bestehen bleiben |
Anschauliches Beispiel: versionierte Richtlinienfragen
Ein Leistungsassistent erhält Fragen zu einer aktuellen Police und einer archivierten Police. Erstellen Sie unterschiedliche Fälle für aktuelle Fragen, explizit historische Fragen und Fragen ohne Datum. Das erwartete Verhalten weicht ab: Verwenden Sie die aktuelle Regel, antworten Sie historisch oder klären Sie das geltende Datum. Eine bloße Namensänderung in einem einfachen Beispiel würde diese Unterscheidung verfehlen.
Behalten Sie die Verknüpfung dieser Fälle mit den Richtlinienversionen bei, damit eine echte Richtlinienaktualisierung nicht als Modellregression erscheint. Beseitigen Sie ungültige Erwartungen durch eine Überprüfung mit einer Erklärung, anstatt schwierige Fälle aus dem Datensatz zu löschen.
Behandeln Sie den Datensatz als gepflegtes Produktartefakt
Trennen Sie einen Entwicklungssatz von einem Entscheidungssatz und zeichnen Sie den Zugriff auf jeden auf. Fügen Sie neue Fehlerfälle über eine schlanke Überprüfungswarteschlange hinzu. Identifizieren Sie beim Melden einer Bewertung die Datensatzversion und erläutern Sie wesentliche Änderungen. Der Vergleich der Ergebnisse des letzten Monats bei einem Aufgabenmix mit dem Ergebnis dieses Monats bei einem anderen kann dazu führen, dass Verkehrsänderungen mit Modellverbesserungen verwechselt werden.
Grenzen der Beweise
Ein Datensatz ist eine erstellte Stichprobe und kein vollständiges Modell des zukünftigen Verkehrs. Die Ergebnisse von HieraRAG beziehen sich auf einen bestimmten Forschungsaufbau. Das Beispiel für die Aufzeichnungsgestaltung und die Richtlinien hier sind Rubrex-Empfehlungen und keine Reproduktion dieser Studie.
Häufige Fragen
Kann der Datensatz vollständig synthetisch sein?
Es kann während des frühen Entwurfs nützlich sein, sein Realismus und seine Abdeckung müssen jedoch validiert werden. Machen Sie den synthetischen Ursprung deutlich und vergleichen Sie ihn mit der autorisierten tatsächlichen Verwendung, sofern verfügbar.
Sollten Referenzen genaue Antworten sein?
Verwenden Sie exakte Antworten für exakte Aufgaben. Definieren Sie für offene Ausgaben erforderliche Fakten, inakzeptables Verhalten und akzeptable Variationen.
Quellen & weiterführende Literatur
Primäre Quellen hinter diesem Briefing. Die Erkenntnisse einer Quelle gelten für ihre eigenen Studienbedingungen; Die Veröffentlichung auf arXiv begründet kein Peer-Review.
- Wie feinkörnig sollte ein RAG-Benchmark sein? Ein hierarchisches Framework für die Generierung synthetischer Fragen arXiv · 2026 · VorabdruckBewertet: Zusammenfassung und Veröffentlichungsnachweis. Zugriff 25. Sept. 2026.
Fragen oder Korrekturen? Schreiben Sie an Rubrex. Lesen Sie unseren redaktionellen Ansatz.