Czym jest zbiór danych do oceny RAG i kiedy ma znaczenie w przypadku prywatnego wyszukiwania?
Zbiór danych do oceny RAG to powtarzalny zestaw zapytań oraz oczekiwanych dowodów lub zachowań odpowiedzi, używany do spójnego mierzenia zmian w prywatnym wyszukiwaniu.
Bez stałego zestawu testowego domowa baza wiedzy może wydawać się lepsza po zmianie rozmiaru fragmentów, modelu osadzania, rerankera lub reguły metadanych tylko dlatego, że wypróbowano inne pytania. Przydatny zbiór danych utrwala reprezentatywne zapytania domowników, oznacza dowody, które powinny zostać pobrane, rejestruje akceptowalne zachowanie odpowiedzi i uwzględnia przypadki, w których system powinien przyznać, że korpus nie zawiera odpowiedzi.
Zbiór ewaluacyjny utrwala pytania i oczekiwane dowody
Podstawową jednostką jest przypadek testowy, który można uruchomić ponownie po zmianach w potoku RAG. Może zawierać pytanie, odpowiedź referencyjną, odpowiednie fragmenty źródeł, tożsamość dokumentu, ograniczenia metadanych oraz uwagi dotyczące tego, jak powinna wyglądać prawidłowa odmowa odpowiedzi.
Stabilny test RAG może przed wielokrotnym pomiarem aplikacji łączyć pytania i oczekiwane odpowiedzi.
W przypadku prywatnego wyszukiwania etykiety dowodów są często cenniejsze niż sam tekst odpowiedzi, ponieważ pokazują, czy do kontekstu trafił właściwy plik i właściwa wersja, nawet gdy model językowy przypadkiem wygenerował wiarygodne zdanie końcowe.
Przypadek testowy powinien zachowywać tożsamość źródła z taką samą szczegółowością, z jaką system pobiera dane. Jeśli etykieta oceny oznacza tylko cały plik PDF, podczas gdy indeks zwraca fragmenty, błąd może ukryć się w pozornie prawidłowym dopasowaniu na poziomie dokumentu.
Prywatne wyszukiwanie wymaga trybów błędów z rzeczywistego domowego korpusu
Publiczne benchmarki rzadko zawierają zduplikowane nazwy plików, skany OCR, poprawione instrukcje, rodzinne słownictwo, dokładne numery seryjne, prywatne reguły folderów i nieaktualne wersje, które kształtują domową bazę wiedzy.
Różne korpusy mogą wymagać dziedzinowej oceny RAG, zamiast zakładać, że jeden ogólny benchmark pytań i odpowiedzi reprezentuje każde środowisko wyszukiwania.
Twórz przypadki na podstawie rzeczywistych dzienników wyszukiwania i znanych trudnych plików, a następnie dodawaj warianty syntetyczne tylko wtedy, gdy sprawdzają jasno zdefiniowaną granicę. Dokładne identyfikatory, parafrazy, synteza informacji z wielu dokumentów, konflikty między wersjami aktualnymi i nieaktualnymi oraz zapytania, na które nie ma odpowiedzi, nie powinny być reprezentowane przez jeden ogólny typ pytania.
Pobieranie i generowanie wymagają osobnych etykiet
Prawidłowa odpowiedź końcowa może ukrywać słabe pobieranie, jeśli model znał fakt z procesu wstępnego trenowania, a błędna odpowiedź może powstać nawet wtedy, gdy pobrano idealny fragment. Dlatego zbiór danych powinien obsługiwać metryki na poziomie poszczególnych etapów, a nie tylko jeden wynik typu „wszystko albo nic”.
Ustrukturyzowane próbki ewaluacyjne pozwalają metrykom oceniać jakość pobierania i odpowiedzi na podstawie spójnych danych testowych.
Dla każdego zapytania oznacz, jakie dowody muszą być obecne, jakie wersje są zabronione oraz jakie właściwości odpowiedzi mają znaczenie. Następnie porównuj osobno kompletność, jakość rankingu, precyzję kontekstu, wierność, poprawność odpowiedzi, tożsamość cytowanego źródła i zachowanie w przypadku odmowy.
Taki podział sprawia, że regresje można skutecznie diagnozować. Spadek wyniku odpowiedzi można przypisać dzieleniu na fragmenty lub pobieraniu, gdy dowody zniknęły z pierwszych k wyników, albo generowaniu, gdy dowody pozostały nienaruszone, lecz odpowiedź niewłaściwie je wykorzystała.
Przypadki negatywne i graniczne chronią przed sztucznym zawyżaniem wyników
Zbiór danych zawierający wyłącznie łatwe pytania, na które można odpowiedzieć, nagradza systemy, które zawsze odpowiadają z przekonaniem. Prywatne wyszukiwanie potrzebuje również zapytań, na które odpowiedź jest nieobecna, niejednoznaczna, ograniczona uprawnieniami, zastąpiona nowszą wersją lub zależna od więcej niż jednego źródła.
Przypadki spoza bazy wiedzy są niezbędne do pomiaru zachowawczego zachowania, a nie tylko kompletności dla znanych odpowiedzi.
Testy uprawnień są równie ważne w przypadku domowego indeksu. Wynik idealnie dopasowany semantycznie, lecz nieautoryzowany, powinien być uznany za błąd systemu, a nie za doskonałe pobieranie.
Uwzględnij przykłady niemal identycznych dokumentów i konfliktów między wersjami, aby system nie mógł poprawiać średnich metryk przez zwracanie większej liczby kandydatów. Oczekiwane dowody powinny wskazywać autorytatywne źródło, a nie tylko temat.
Wersjonowanie zbioru danych zmienia jednorazowe testy w kontrolę regresji
Korpus i pytania zmieniają się z czasem. Nowe urządzenia, przemianowane foldery, zaktualizowane zasady i inne słownictwo użytkowników mogą sprawić, że stary zbiór ewaluacyjny przestanie być reprezentatywny, dlatego same dane testowe wymagają kontrolowanego cyklu życia.
Wersjonowanie zbioru danych pozwala porównywać wyniki potoku ze znanym stanem przykładów ewaluacyjnych.
Przepływ pracy z prywatną bazą wiedzy jest warstwą aplikacji, natomiast zbiór ewaluacyjny sprawia, że zmiany w tym przepływie można mierzyć, zamiast oceniać je anegdotycznie.
Odświeżaj zbiór danych, gdy zmienia się korpus lub zachowanie użytkowników, ale zachowuj wersje historyczne, aby nowy zbiór ewaluacyjny nie usunął dowodów na to, że zmiana w pobieraniu pogorszyła starszy, krytyczny przepływ pracy.
Polecane produkty
Centrum Technologii i Sztucznej Inteligencji
Więcej do przeczytania
Czym jest stan Plexa i które jego elementy muszą być zachowane?
Trwały stan Plex to informacje, które zachowują konfigurację serwera po ponownym uruchomieniu i odbudowie; multimedia oraz tymczasowe dane transkodowania pełnią odrębne funkcje.
Jak Plex obsługuje uwierzytelnianie w sesjach lokalnych i zdalnych?
Uwierzytelnianie w Plex rozpoczyna się od tożsamości serwera i konta, a następnie lokalne lub zdalne ścieżki sieciowe określają dostępność oraz sposób nawiązywania bezpiecznego połączenia.
Dlaczego wyszukiwanie w Plex może zwalniać wraz ze wzrostem ilości danych biblioteki?
Sam wzrost biblioteki nie jest diagnozą. Zanim obwinisz rozmiar bazy danych, przetestuj kształt zapytań, indeksy, stan pamięci podręcznej, opóźnienia pamięci masowej i aktywność zapisu.
