Jak Budować Niezawodny RAG: Głębokie Zanurzenie w 7 Punktach Awaryjnych i Ramach Oceny

Retrieval-Augmented Generation (RAG) jest kluczowy dla nowoczesnej architektury AI, służąc jako podstawowa ramka dla budowy agentów świadomych kontekstu.

Ale przechodzenie od podstawowego prototypu do systemu gotowego do produkcji wymaga nawigowania wokół znaczących przeszkód w odzyskiwaniu danych, konsolidacji kontekstu i syntezie odpowiedzi.

Ten artykuł zapewnia głębokie zanurzenie w siedmiu typowych punktach awaryjnych RAG i metrykach oceny z praktycznymi przykładami kodowania.

Anatomia Awarii RAG – 7 Punktów Awaryjnych (FPs)

Zgodnie z badaniami Barnett et al., Systemy Retrieval Augmented Generation (RAG) napotykają siedem konkretnych Punktów Awaryjnych (FPs) na całym procesie.

Poniższy diagram ilustruje te etapy:

Figure A. Indexing and Query processes required for creating a RAG system. The indexing process is done at development time and queries at runtime. Failure points identified in this study are shown in red boxes (source)

Rozważmy każdy FP, uporządkowany według sekwencji procesu, postępując od lewego górnego rogu do prawego dolnego rogu, jak pokazano w Figure A.

FP1. Brakująca Treść

Brakująca treść występuje, gdy system jest pytany o coś, czego nie może odpowiedzieć, ponieważ odpowiednie informacje nie są obecne w dostępnym magazynie wektorowym w pierwszej kolejności.

Awaria występuje, gdy LLM dostarcza brzmiącą prawdopodobnie, ale nieprawidłową odpowiedź, zamiast stwierdzić, że nie wie.

FP2. Przegapione Dokumenty Najlepiej Wycenione

Jest to sytuacja, w której poprawny dokument istnieje w magazynie wektorowym, ale odzyskiwacz nie jest w stanie nadać mu wystarczająco wysokiej oceny, aby uwzględnić go w dokumentach top-k dostarczonych do LLM jako kontekst.

W konsekwencji poprawna informacja nigdy nie dociera do LLM.

FP3. Poza Kontekstem (Ograniczenia Strategii Konsolidacji)

Jest to sytuacja, w której poprawny dokument istnieje i jest odzyskany z magazynu wektorowego, ale jest wykluczony podczas procesu konsolidacji.

To się dzieje, gdy zbyt wiele dokumentów jest zwróconych, a system musi je przefiltrować, aby zmieścić się w oknie kontekstu LLM, limitach tokenów lub limitach stawki.

FP4. Nie Wyciągnięte

Jest to sytuacja, w której LLM nie jest w stanie zidentyfikować poprawnej informacji w kontekście, nawet jeśli poprawna informacja była w magazynie wektorowym i została pomyślnie odzyskana / skonsolidowana.

To się dzieje, gdy kontekst jest zbyt hałaśliwy lub zawiera sprzeczne informacje, które mylą LLM.

FP5. Niepoprawny Format

Jest to sytuacja, w której magazynowanie, odzyskiwanie, konsolidacja i interpretacja LLM są obsługiwane pomyślnie, ale LLM nie jest w stanie postępować zgodnie ze specyficznymi instrukcjami formatowania podanymi w prompcie, takimi jak tabela, lista punktowa lub schemat JSON.

FP6. Niepoprawna Szczegółowość

Wyjście LLM jest technicznie obecne, ale albo zbyt ogólne, albo zbyt złożone w porównaniu z potrzebami użytkownika.

Na przykład LLM generuje proste odpowiedzi na zapytanie użytkownika o złożonym profesjonalnym celu.

FP7. Niekompletne Odpowiedzi

Jest to sytuacja, w której LLM generuje wyjście, które nie jest koniecznie błędne, ale brakuje mu kluczowych informacji, które były dostępne w kontekście.

Na przykład, gdy użytkownik pyta o złożone pytanie, takie jak “Jakie są kluczowe punkty w dokumentach A, B i C?”, LLM rozważa tylko jeden lub dwa źródła.

Jak FPs Naruszają Wydajność Potoku RAG

Każdy z tych FPs wpływa na wydajność potoków RAG:

Integralność Danych i Awaria Zaufania

Gdy brakuje lub jest niepoprawna informacja, system nie jest już wiarygodnym źródłem informacji. Główne FPs obejmują:

• FP1 (Brakująca Treść): Odpowiedź nie jest w dokumencie w pierwszej kolejności.
• FP4 (Nie Wyciągnięte): LLM decyduje się zignorować poprawną odpowiedź w dokumencie.
• FP7 (Niekompletne): LLM dostarcza półprawdy, brakuje mu ważnych kawałków.

Odzyskiwanie i Bottleneck Wydajności

Potok RAG może być niewydajny, gdy pomija kluczowe informacje na etapach odzyskiwania i konsolidacji. Główne FPs obejmują:

• FP2 (Przegapione Dokumenty Najlepiej Wycenione): Model osadzania nie jest w stanie wybrać najlepszych osadzeń.
• FP3 (Strategia Konsolidacji): Skrypt do przycinania dokumentów, aby zmieścić się w limitach LLM, upuszcza najważniejsze części.

Doświadczenie Użytkownika i Błędy Formatowania

Chociaż poprawna, wyjście z słabą czytelnością lub w niewłaściwym formacie może naruszyć doświadczenie użytkownika. Główne FPs obejmują:

• FP5 (Niepoprawny Format): LLM nie jest w stanie postępować zgodnie ze specyficznym formatem wyjścia, takim jak JSON.
• FP6 (Niepoprawna Szczegółowość): LLM generuje obszerną odpowiedź na proste tak/nie pytanie, lub odwrotnie (zbyt krótką odpowiedź na skomplikowane pytanie).

Stos Oceny: Ramy do Zmniejszania FPs

Metryki oceny są zaprojektowane, aby systematycznie zmniejszać te FPs.

Ten rozdział bada główne metryki oceny z praktycznymi przypadkami użycia.

Główne Metryki Oceny RAG:

• DeepEval
• RAGAS
• TruLens
• Arize Phoenix
• Braintrust

DeepEval – Jednostka Testowa Przed Wdrożeniem

DeepEval oblicza wynik ważony na podstawie kryteriów.

LLM-as-a-judge (np. GPT-4o) ocenia każde kryterium w stosunku do wyjścia LLM:

DeepEval wykorzystuje G-eval, chain-of-thought (CoT) framework, który przyjmuje podejście wieloetapowe do oceny wyjścia:

1. Definiuj kryterium do pomiaru (np. “spójność”, “płynność” lub “istotność”).
2. Generuj kroki oceny (korzystając z oceniającego LLM).
3. Postępuj zgodnie z krokami oceny i analizuj wejście i wyjście LLM.
4. Oblicz oczekiwany ważony sum wyniku każdego kryterium.

Typowy Przypadek w Praktyce

• Sytuacja: Asystent techniczny dokumentacji (bot) dla złożonego oprogramowania wydaje się działać każdego razu, gdy zespół inżynierów aktualizuje kod.
• Problem: Brak ilościowego dowodu, czy bot może nadal odpowiedzieć na zapytanie użytkownika (tylko “myślisz”, że działa…).
• Rozwiązanie: Zintegruj funkcję PyTest jako regresję CI/CD w Github Action, gdzie DeepEval uruchamia G-Eval i inne metryki nad przypadkiem testowym:

• Oczekiwane wyniki: Jeśli którykolwiek wynik metryk spadnie poniżej progu (0,85), PyTest podnosi AssertionError – niezwłocznie powodując awarię budowy CI, uniemożliwiając cichej regresji osiągnięcie produkcji.

Zalety

• Istnieje wiele metryk (50+) w tym specjalistyczne kontrole i testy na stronę.
• Bezproblemowo integruje się z istniejącymi potokami CI/CD.
• Brak potrzeby odniesienia. Ocena wyjścia oparta wyłącznie na prompcie i dostarczonym kontekście.

Wady

• Jakość oceny zależy głównie od możliwości sędziego LLM.
• Nieekonomiczne obliczeniowo, gdy sędzia LLM jest wysokiej jakości modelem.

Uwaga Deweloperska – Przypadek Testowy dla DeepEval
Zestaw LLMTestCase obiektów definiuje przypadek testowy, który DeepEval uruchamia.

W praktyce ten przypadek testowy powinien zawierać najważniejsze zapytania użytkownika i oznaczone wyjścia z odzyskanym kontekstem.

Mogą one być pobrane z pliku JSON lub CSV.

RAGAS – Optymalizator Igły w Stogu Siana

Ocena Generacji Wzmacnianego Odzyskiwaniem (RAGAS) ma na celu ocenę RAG bez zestawu danych zannotowanych przez człowieka, generując syntetyczne zestawy testowe.

Następnie oblicza flagowe metryki:

Figure B. The RAGAS evaluation triad diagram connecting Question, Context, and Answer through Precision, Recall, Faithfulness, and Relevancy metrics (Created by Kuriko IWAI)

Flagowe metryki są sklasyfikowane w trzy grupy:

• Pipeline odzyskiwania (czarna, ciągła linia, Figure B): Precyzja kontekstu, recall kontekstu.
• Pipeline generacji (czarna, kropkowana linia, Figure B): Wierność, relevancy odpowiedzi.
• Prawda podstawowa (czerwona ramka, Figure B): Podobieństwo semantyczne odpowiedzi, poprawność odpowiedzi.

Typowy Przypadek w Praktyce

• Sytuacja: System RAG dla umów prawnych jest pozbawiony kluczowych klauzul. Nie jesteś pewien, czy problem leży w wyszukiwaniu (Odzyskiwacz) czy w czytaniu (Generator).
• Problem: Brak pomysłu na optymalny top-k (liczba pobranych fragmentów).
• Rozwiązanie: Użyj RAGAS, aby utworzyć syntetyczny zestaw testowy z 100 par zapytań i dowodów. Następnie uruchom potok RAG przeciwko zestawowi testowemu, aby obliczyć recall kontekstu i precyzję kontekstu:
• Oczekiwany wynik: W zależności od wyników metryk, plan działania może być następujący:

Tabela 1. RAGAS Plan Działania Diagnostycznego – Mapowanie Wyników na Dostosowania Systemu.

Zalety

• Doskonały dla wczesnego projektu bez zbiorów danych podstawowych (jak widzieliśmy w przykładzie kodu, RAGAS może utworzyć syntetyczny zestaw testowy).

Wady

• Syntetyczny zestaw testowy może pominąć nuansowane błędy faktualne.
• Wymaga solidnego modelu ekstraktora, aby rozbijać odpowiedzi na poszczególne twierdzenia (użyłem gpt-4o w przykładzie).

TruLens – Specjalista Pętli Sprzężenia Zwrotnego

TruLens koncentruje się na wewnętrznych mechanizmach procesu RAG, a nie tylko na końcowym wyjściu, wykorzystując funkcje sprzężenia zwrotnego.

Wykorzystuje również LLM-oparty wynik, odzwierciedlający, jak dobrze odpowiedź spełnia intencję zapytania, używając 4-punktowej skali Likerta (0-3), co czyni go lepszym do klasyfikowania jakości różnych wyników wyszukiwania.

Typowy Przypadek w Praktyce

• Sytuacja: Bot doradcy medycznego odpowiada na pytanie użytkownika poprawnie, ale dodaje wskazówkę, która nie jest w podstawowym PDF.
• Problem: Dodana wskazówka może być pomocna, ale nie jest uzasadniona.
• Rozwiązanie: Użyj TruLens, aby zaimplementować funkcję sprzężenia zwrotnego z progiem, takim jak score > 0.8.

• Oczekiwane wyniki: Gdy LLM generuje odpowiedź, która zawiera informacje nieobecne w odzyskanych fragmentach, TruLens flaguje rekord w Twoim dashboardzie.

Zalety

• Wizualizuje łańcuch rozumowania, aby zidentyfikować dokładnie, gdzie agent zboczył z toru.
• Zapewnia wbudowane wsparcie dla uzasadnienia, aby złapać halucynacje w czasie rzeczywistym.

Wady

• Łączenie krzywej dla definiowania niestandardowych funkcji sprzężenia zwrotnego.
• Dashboard może wydawać się ciężki dla prostych skryptów.

Arize Phoenix – Mapa Awarii Cichej

Arize Phoenix to otwarte źródło obserwacyjności i narzędzie oceny do oceny wyjść LLM, w tym złożonych systemów RAG.

Zbudowany na OpenTelemetry przez Arize AI, koncentruje się na obserwacyjności, traktując ocenę LLM jako podzbiór MLOps.

W kontekście oceny RAG, Phoenix wyróżnia się w analizie osadzania, wykorzystując Uniform Manifold Approximation and Projection (UMAP) do redukcji wysokowymiarowych osadzania wektorowych do przestrzeni 2D/3D.

Ta analiza osadzania matematycznie ujawnia, czy nieudane zapytania są grupowane semantycznie, co wskazuje na lukę w bazie wektorowej.

Typowy Przypadek w Praktyce

• Sytuacja: Bot wsparcia klienta działa dobrze dla zwrotów, ale dostarcza nonsensowne odpowiedzi na roszczenia gwarancyjne.
• Problem: Dziura w danych w bazie wektorowej (nie można znaleźć w logach).
• Rozwiązanie: Użyj Arize Phoenix, aby wygenerować wizualizację Umap Embedding (UEV), mapę 3D dla bazy wektorowej – aby nałożyć zapytania użytkownika na fragmenty dokumentów.
• Oczekiwane wyniki: Wizualnie zobacz klaster zapytań użytkownika lądujących w ciemnej strefie, gdzie nie ma dokumentów, wskazując, że niektóre dokumenty zostały pominięte podczas przekazywania do magazynu wektorowego.

Zalety

• Native OpenTelemetry; integruje się z istniejącymi enterprise monitoring stackami.
• Najlepsze narzędzie do wizualizacji słabych punktów magazynu wektorowego.

Wady

• Mniej ukierunkowane na ocenianie, bardziej na obserwowanie.
• Może być nadmiarowe dla małych aplikacji lub pojedynczych narzędzi.

Braintrust – Sieć Bezpieczeństwa Regresji Promptu

Braintrust jest zaprojektowany dla cykli iteracji o wysokiej częstotliwości, wykorzystując porównanie między modelami.

Typowy Przypadek w Praktyce

• Sytuacja: Zespół inżynierów ulepsza promt od “Odpowiedz na pytanie” (Przypadek A) do bardziej złożonej 500-słownej instrukcji systemowej (Przypadek B).
• Problem: Ulepszanie promtu dla Przypadku B może nieumyślnie złamać Przypadek A.
• Rozwiązanie: Użyj Braintrust, aby utworzyć zestaw danych golden z zestawem N idealnych przykładów (np. N = 50). Pozwól Braintrust uruchomić porównanie bok-po-boku (SxS) za każdym razem, gdy zespół aktualizuje pojedyncze słowo w prompcie:

• Oczekiwany wynik: Raport różnic, pokazujący dokładnie, które przypadki zostały poprawione / pogorszone dla każdego z zestawu danych golden (N = 50).

Zalety

• Ekstremalnie szybki do testowania przed wdrożeniem.
• Świetny interfejs dla nie-technicznych stakeholderów do przeglądu i oceny wyjścia.

Wady

• Właściciel / SaaS-orientowany (chociaż mają otwarte komponenty).
• Mniej wbudowanych metryk deep-tech w porównaniu z DeepEval lub Ragas.

Podsumowanie

Gdy obsługiwane są przez odpowiednie ramy oceny, RAG może być konkurencyjnym narzędziem do dostarczania LLM kontekstu najbardziej istotnego dla zapytania użytkownika.

Strategia Wdrożenia: Mapowanie Metryk na Punkty Awaryjne

Chociaż nie ma rozwiązania pasującego do wszystkich, Tabela 2 pokazuje, które metryki oceny stosować dla każdego FP, które omówiliśmy w tym artykule:

Tabela 2. Macierz Zmniejszania Punktów Awaryjnych – Które Narzędzie Rozwiązuje Który FP?

DeepEval i RAGAS mogą wykorzystać swoje metryki wierności, aby zmierzyć awarie integralności danych (FP1, FP4, FP7).

TruLens wykorzystuje swoją precyzję kontekstu / recall, aby zmierzyć relevancy kontekstu do wyjścia – skutecznie oceniając FP2.

Arize Phoenix dostarcza wizualny ślad procesu odzyskiwania, ułatwiając zobaczenie, czy odzyskany dokument został utracony podczas konsolidacji (FP3).

Dla awarii UX, DeepEval tworzy niestandardowe metryki, aby ocenić awarie UX, podczas gdy Braintrust wyróżnia się w porównaniach zbiorów danych podstawowych.