Aufbau eines ehrlichen RAG-Evaluierungssets: Wie man die ersten 100-300 Fälle sammelt, ohne sich selbst zu betrügen
Microsoft
Der Artikel erörtert die Bedeutung eines manuellen Evaluierungssets für RAG-Systeme, getrennt von Smoke-Tests und Trainingsdaten. Es wird vorgeschlagen, 100-300 sorgfältig ausgewählte Fälle über mehrere Szenarien zu sammeln, Retrieval und Antwortgenerierung getrennt zu kennzeichnen und Metriken wie Recall@k, MRR@k und nDCG@k zu verwenden. Synthetische Daten und öffentliche Benchmarks reichen für die domänenspezifische Retrieval-Evaluierung nicht aus.
Der Autor argumentiert, dass öffentliche Benchmarks wie MTEB und BEIR keine gute Retrieval-Qualität bei domänenspezifischen Aufgaben garantieren, und dass synthetische Daten zu übermäßig aufgeräumten Formulierungen führen können. Stattdessen empfiehlt er, ein manuelles Evaluationsset aus 100-300 Fällen aufzubauen, mit einem praktischen Start von 120 Fällen, die aus Logs, Dokumentation, Experteninterviews und nach Überprüfung aus synthetischen Kandidaten stammen. Jeder Fall sollte Felder wie Abfrage, Szenario, erwartete Dokumenten-IDs, Gold-Evidenz-Abschnitte, erwartete Fakten, Beantwortbarkeit und warum es wichtig ist, enthalten. Das Set sollte in 6-8 Segmente unterteilt sein, die exakte Entitäten, Paraphrasierungen, lange Abschnitte, Tabellen, Versionen, Fälle ohne Antwort, schlechte Formulierungen und sensible Szenarien abdecken. Retrieval und Antwortgenerierung sollten getrennt bewertet werden, wobei die Retrieval-Metriken Recall@k, MRR@k und nDCG@k umfassen, und die Antwort-Metriken Fundiertheit, Vollständigkeit, Antwortrelevanz und korrekte Enthaltung. Der Autor betont, dass für Segmente ohne Antwort die Standard-Recall-Metrik bedeutungslos ist, und schlägt ein separates Freigabe-Gate vor. Er warnt auch davor, Trainingsdaten im Evaluationsset zu verwenden, und empfiehlt, die LLM-als-Judge-Methode anhand einer manuellen Teilmenge zu validieren.
Quelle: Habr — хаб ИИ —
Original