Rozwiązywanie problemów w RAG poprzez znalezienie pierwszego etapu, który zawiodł

Gdy asystent wiedzy udziela słabej odpowiedzi, łatwą reakcją jest zmiana zapytania. Jest to przydatne tylko wtedy, gdy model otrzymał wystarczające dowody, a następnie je niewłaściwie przetworzył.

Nieobecny dokument, niekompletne wydobywanie informacji oraz nieuzasadniona konkluzja to różne rodzaje błędów. Traktowanie ich jako jednej oceny jakości spowalnia debugowanie, ponieważ ocena ta nie wskazuje, którą część należy zmienić.

Pракtyczny cykl oceny powinien zachować ścieżkę od materiału źródłowego do odpowiedzi, którą zobaczył użytkownik.

Buduj przykłady z dowodami, a nie tylko odpowiedziami

Dla każdego pytania testowego zapisz fragmenty tekstu, które wspierają akceptowalną odpowiedź. Włącz informacje o tym, co odpowiedź musi zachować, oraz o twierdzeniach, których należy unikać.

Pryzmatyczny przypadek może wyglądać w ten sposób:

{
  "question": "When should this deployment be rolled back?",
  "required_evidence": ["handbook-v3:section-8"],
  "must_include": ["the failed health-check condition"],
  "must_not_claim": ["every warning requires rollback"],
  "answerable": true
}

To zapis jest bardziej przydatny niż pojedyncze oczekiwane zdanie. Pozwala na kilka dobrze napisanych odpowiedzi, zachowując jednocześnie warunki sprawiające, że są one poprawne.

Dodaj pytania, na które korpus nie potrafi odpowiedzieć. W przeciwnym razie system, który zawsze coś generuje, może wydawać się silniejszy od tego, który prawidłowo przyznaje brak dowodów.

Najpierw sprawdź najwcześniejszą nieudaną próbę

Zacznij od źródła. Czy wymagane informacje istnieją w tekstach zindeksowanych i czy należą do określonego dokumentu? Jeśli nie, popraw przetwarzanie źródeł.

Następnie sprawdź proces wyodrębniania informacji. Czy istotne dowody trafiły do grupy kandydatów? Jeśli tak, to czy przetrwały filtrację, ponowne sortowanie oraz tworzenie kontekstu? To są odrębne punkty kontrolne. Fragment znaleziony podczas wyszukiwania, ale usunięty przed generowaniem odpowiedzi, nie może służyć jako podstawa ostatecznej odpowiedzi.

Na koniec sprawdź odpowiedź. Czy dokładnie odzwierciedlała ona dostępne dowody, zachowała wyjątki i unikała nieudokumentowanych twierdzeń? Jeśli kontekst był wystarczający, a odpowiedź zawiodła, celem staje się optymalizacja zachowania podczas generowania lub udzielania wskazówek.

Taki układ zapobiega temu, by silny model maskował słabe wyniki przy łatwych pytaniach, a następnie nieprzewidywalnie zawodził przy pytaniach, na które nie może odpowiedzieć na podstawie wcześniejszej wiedzy.

Używaj metryk, które ujawniają różne błędy

Pamięć przy wybranym progu mierzy udział oznaczonych, istotnych elementów, które udało się odzyskać. Dokładność mierzy udział zwróconych elementów, które są rzeczywiście istotne. Wskaźnik częstości trafień sprawdza, czy pojawił się przynajmniej jeden istotny element; jest to mniej wymagające niż odzyskanie wszystkich dowodów potrzebnych do odpowiedzi wieloetapowej.

Metryki rankingu pomagają odróżnić dowody znajdujące się na pierwszym miejscu od tych ukrytych blisko progu decyzyjnego. Jednak etykietowanie istotności wymaga ostrożności: jeden akapit może wspominać o temacie, podczas gdy inny bezpośrednio odpowiada na pytanie. Traktowanie ich jako równie użytecznych może nagradzać niewłaściwe zachowanie.

Podczas generowania należy oddzielnie oceniać wsparcie, poprawność, kompletność oraz zgodność z cytatami. Odpowiedź może dokładnie powtarzać przestarzały źródło. Może też zawierać prawidłowe stwierdzenie, którego nie potwierdzają dostarczone dowody. W takich przypadkach potrzebne są różne sposoby korekty.

Zachowaj jakość operacyjną w tym samym eksperymencie

Zapisuj czas reakcji, błędy oraz zużycie zasobów razem z ocenami jakości. Zachowaj wersję korpusu, ustawienia wyszukiwania, wersję promptu oraz identyfikator modelu, aby porównania były możliwe do zinterpretowania.

Podczas diagnozowania regresji zmieniaj jedną główną zmienną na raz. Na przykład porównaj reranking włączony i wyłączony, utrzymując przy tym stały zbiór kandydatów. Zmiana jednocześnie sposobu dzielenia na fragmenty, procesu wydobywania danych oraz promptu może poprawić wynik, ale nie ujawni przyczyny problemu.

Zautomatyzowani sędziowie mogą pomóc w przeglądaniu wielu wyników, ale niezgodności oraz delikatne przypadki krawędziowe należy sprawdzać ręcznie. Wynik sędziego to kolejna miara o ograniczeniach, a nie zamiennik wyraźnej rubryki oceniania.

Ocena tego, co dociera do użytkownika

Prawidłowa odpowiedź serwera może nadal pojawić się przy niewłaściwej zapytaniu, jeśli interfejs akceptuje przestarzałe żądania. Należy włączyć interakcję wyszukiwania w React do testów end-to-end.

Korzystnym rezultatem oceny jest konkretna dalsza akcja: naprawa wydobywania informacji, rozszerzenie możliwości wyszukiwania, zachowanie kontekstu, poprawa generowania treści lub naprawa sposobu ich dostarczania. To znacznie lepszy wynik niż samo stwierdzenie, że odpowiedź „wydała się błędna”.

Literatura pokrewna

• Migracja API Express do Next.js App Router Route Handlers — Dowiedz się, jak przekształcić trasy Express, middleware oraz wzorce danych na Next.js App Router z użyciem Server Components oraz jakie są kwestie związane z wdrożeniem.