Jak zbudować niezawodny RAG: Głębokie wprowadzenie do 7 punktów awaryjnych i ram ewaluacji

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

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

Ten artykuł zapewnia głębokie wprowadzenie do siedmiu typowych punktów awaryjnych RAG i metryk ewaluacji z praktycznymi przykładami kodowania.

Anatomia awarii RAG – 7 punktów awaryjnych (FP)

Według badaczy Barnett et al., systemy RAG napotykają siedem konkretnych punktów awaryjnych (FP) na całej drodze.

Poniższy diagram ilustruje te etapy:

Figure A. Procesy indeksowania i zapytań wymagane do tworzenia systemu RAG. Proces indeksowania odbywa się w czasie rozwoju, a zapytania w czasie wykonywania. Punkty awaryjne zidentyfikowane w tym badaniu są pokazane w czerwonych prostokątach (źródło)

Przejdźmy przez każdy punkt awaryjny, uporządkowany według sekwencji potoku, 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ś, co nie może być odpowiedzią, ponieważ odpowiednia informacja nie jest obecna w dostępnym magazynie wektorowym.

FP2. Pominięte dokumenty najwyżej ocenione

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 umieścić go wśród najlepszych dokumentów k, które są podawane do LLM jako kontekst.

FP3. Nie w kontekście (ograniczenia strategii konsolidacji)

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

FP4. Nie wyodrębniony

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 i skonsolidowana.

FP5. Błędny 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. Niewłaściwa szczegółowość

Wydruk LLM jest technicznie obecny, ale albo zbyt ogólny, albo zbyt złożony w porównaniu z potrzebami użytkownika.

FP7. Niedokończone odpowiedzi

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

Jak punkty awaryjne kompromitują wydajność potoku RAG

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

Awarie integralności danych i zaufania

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

• FP1 (Brakująca treść): Odpowiedź nie jest w dokumencie od samego początku.
• FP4 (Nie wyodrębniony): LLM decyduje się zignorować poprawną odpowiedź w dokumencie.
• FP7 (Niedokończony): LLM podaje półprawdy, brakuje mu ważnych elementów.

Wąskie gardła odzyskiwania i wydajności

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

• FP2 (Pominięte dokumenty najwyżej ocenione): Model embeddings nie jest w stanie wybrać najlepszych dokumentów k.
• FP3 (Ograniczenia strategii konsolidacji): Skrypt do obcinania dokumentów, aby zmieścić się w limitach LLM, usuwa najważniejsze części.

Błędy doświadczenia użytkownika i formatowania

Chociaż poprawny, wydruk z słabą czytelnością lub w niewłaściwym formacie może kompromitować doświadczenie użytkownika. Główne punkty awaryjne obejmują:

• FP5 (Błędny format): LLM nie jest w stanie postępować zgodnie ze specyficznym formatem wyjściowym, takim jak JSON.
• FP6 (Niewłaściwa szczegółowość): LLM generuje obszerny wydruk dla prostej odpowiedzi tak/nie, lub odwrotnie (zbyt krótką odpowiedź na skomplikowane pytanie).

Stos ewaluacji: Ramy do łagodzenia punktów awaryjnych

Metryki ewaluacji są zaprojektowane w celu systematycznego łagodzenia tych punktów awaryjnych.
Ten rozdział bada główne metryki ewaluacji z praktycznymi przypadkami użycia.

Główne metryki ewaluacji RAG:

• DeepEval
• RAGAS
• TruLens
• Arize Phoenix
• Braintrust

DeepEval – Test jednostkowy 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, ramę łańcucha myśli (CoT), która podejmuje wieloetapowe podejście do oceny wyjścia:

1. Definiuj kryterium do pomiaru (np. “spójność”, “poprawność” lub “istotność”).
2. Generuj kroki ewaluacji (korzystając z LLM ewaluatora).
3. Postępuj zgodnie z krokami ewaluacji 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 (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 odpowiadać na zapytanie użytkownika (tylko “myślisz”, że działa…).
• Rozwiązanie: Zintegruj funkcję PyTest jako zestaw regresji CI/CD w Github Action, gdzie DeepEval uruchamia G-Eval i inne metryki nad przypadkiem testowym:

• Oczekiwane wyniki: Jeśli którykolwiek wynik metryki spadnie poniżej progu (0,85), PyTest podnosi AssertionError – niezwłocznie kończąc budowę CI, uniemożliwiając cichą regresję przed osiągnięciem produkcji.

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żytkowników i etykietowane wyjścia z odzyskanym kontekstem.

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

RAGAS – Optymalizator igły w stogu siana

RAGAS ma na celu ocenę RAG bez zestawu danych z adnotacjami przez generowanie syntetycznych zestawów testowych.

Następnie oblicza flagowe metryki:

Figure B. Diagram triady oceny RAGAS łączący pytanie, kontekst i odpowiedź za pomocą metryk precyzji, odzyskiwania, lojalności i istotności (stworzony przez Kuriko IWAI)

Flagowe metryki są sklasyfikowane w trzy grupy:

• Potok odzyskiwania (czarna, ciągła linia, Figure B): Precyzja kontekstu, odzyskiwanie kontekstu.
• Potok generacji (czarna, kropkowana linia, Figure B): Lojalność, istotność odpowiedzi.
• Punkty odniesienia (czerwona skrzynka, Figure B): Podobieństwo semantyczne odpowiedzi, poprawność odpowiedzi.

Typowy przypadek w praktyce

• Sytuacja: System RAG dla umów prawnych brakuje 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 pytań i dowodów. Następnie uruchom potok RAG na zestawie testowym, aby obliczyć precyzję kontekstu i odzyskiwanie kontekstu:
• Oczekiwany wynik: W zależności od wyników metryk, plan działania może być następujący:

Tabela 1. Plan działania diagnostycznego RAGAS – Mapowanie wyników na dostosowania systemu.

TruLens – Specjalista od pętli sprzężenia zwrotnego

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

Używa również oceny LLM opartej na 4-punktowej skali Likerta (0-3), co sprawia, że jest lepszy w klasyfikowaniu 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 zweryfikowanej bazie PDF.
• Problem: Dodatkowa 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 panelu.

Arize Phoenix – Cicha mapa awaryjna

Arize Phoenix to otwarte narzędzie obserwacyjne i ewaluacji do oceny wyjść LLM, w tym złożonych systemów RAG.

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

Typowy przypadek w praktyce

• Sytuacja: Bot wsparcia klienta działa dobrze dla zwrotów, ale daje nonsensowne odpowiedzi na roszczenia gwarancyjne.
• Problem: Dziura w danych w magazynie wektorowym (nie można znaleźć w logach).
• Rozwiązanie: Użyj Arize Phoenix, aby wygenerować wizualizację Umap Embedding (UEV), 3D mapę dla magazynu wektorowego – aby nałożyć zapytania użytkowników na fragmenty dokumentów.
• Oczekiwane wyniki: Wizualnie zobacz klaster zapytań użytkowników lądujących w strefie ciemnej, gdzie nie ma dokumentów, co wskazuje, że niektóre dokumenty zostały zapomniane i nie zostały przesłane do magazynu wektorowego.

Braintrust – Sieć bezpieczeństwa regresji promtu

Braintrust jest zaprojektowany do wysokoczęstotliwości cykli iteracji przy użyciu porównania między modelami.

Typowy przypadek w praktyce

• Sytuacja: Zespół inżynierów ulepsza prompty od “Odpowiedz na pytanie” (przypadek A) do bardziej złożonej 500-słownej instrukcji systemowej (przypadek B).
• Problem: Poprawienie promtu dla przypadku B może nieumyślnie złamać przypadek A.
• Rozwiązanie: Użyj Braintrust, aby utworzyć zestaw danych z N idealnymi przykładami (np. N = 50). Pozwól Braintrust uruchomić porównanie równoległe (SxS) za każdym razem, gdy zespół aktualizuje pojedyncze słowo w prompcie:

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

Podsumowanie

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

Strategia wdrożeniowa: Mapowanie metryk na punkty awaryjne

Chociaż nie ma jednej uniwersalnej rozwiązania, Tabela 2 pokazuje, które metryki ewaluacji stosować dla każdego punktu awaryjnego, który omówiliśmy w tym artykule:

Tabela 2. Macierz łagodzenia punktów awaryjnych – Które narzędzie rozwiązuje który punkt awaryjny?

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

TruLens wykorzystuje swoją precyzję i odzyskiwanie kontekstu, aby zmierzyć istotność kontekstu w stosunku do wyjścia – skutecznie oceniając FP2.

Arize Phoenix zapewnia wizualny ślad procesu odzyskiwania, co ułatwia 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 odniesienia.