Jak tworzyć niezawodne systemy RAG: siedem punktów awarii i narzędzia ewaluacji

Retrieval-Augmented Generation (RAG) jest kluczowy dla nowoczesnej architektury AI, służąc jako podstawa 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 szczegółowy przegląd 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 Barnetta i współpracowników, systemy RAG napotykają siedem konkretnych punktów awaryjnych (FP) na całej drodze.

Poniższy diagram ilustruje te etapy:

Rysunek A. Procesy indeksowania i zapytań wymagane do tworzenia systemu RAG. Proces indeksowania odbywa się na etapie 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 na rysunku A.

FP1. Brakująca treść

Treści brakuje, gdy system otrzymuje pytanie, na które nie może odpowiedzieć, ponieważ potrzebnej informacji od początku nie ma w dostępnym magazynie wektorowym.

Błąd pojawia się, gdy LLM udziela wiarygodnie brzmiącej, ale niepoprawnej odpowiedzi, zamiast przyznać, że nie wie.

FP2. Pominięte dokumenty najwyżej ocenione

Jest to sytuacja, w której poprawny dokument istnieje w magazynie wektorowym, ale mechanizm wyszukiwania nie jest w stanie nadać mu wystarczająco wysokiej oceny, aby umieścić go wśród top-k dokumentów, które są podawane do LLM jako kontekst.

W rezultacie poprawna informacja nigdy nie dociera do LLM.

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.

Dzieje się tak, gdy zwracanych jest zbyt wiele dokumentów i system musi je ograniczyć, aby zmieścić się w oknie kontekstu LLM oraz limitach tokenów lub częstotliwości żądań.

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.

Dzieje się tak, gdy kontekst zawiera zbyt wiele szumu lub sprzecznych informacji, które dezorientują LLM.

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ść

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

Na przykład LLM generuje proste odpowiedzi na pytanie użytkownika mającego złożony cel zawodowy.

FP7. Niepełne odpowiedzi

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

Na przykład użytkownik zadaje złożone pytanie, takie jak „Jakie są najważniejsze informacje w dokumentach A, B i C?”, a LLM uwzględnia tylko jedno lub dwa źródła.

Jak punkty awaryjne pogarszają 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 informacji lub jest ona niepoprawna, 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 (Niepełny): 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 embeddingów nie jest w stanie wybrać top-k embeddingów.
• 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

Nawet poprawny wynik może pogarszać doświadczenie użytkownika, jeśli jest nieczytelny lub ma niewłaściwy format. 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 wynik dla prostego pytania 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, metodę łańcucha rozumowania (CoT), która stosuje wieloetapowe podejście do oceny wyjścia:

1. Definiuj kryterium do pomiaru (np. “spójność”, “płynność językowa” lub “trafność”).
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 oczekiwaną ważoną sumę wyniku każdego kryterium.

Typowy przypadek w praktyce

• Sytuacja: Asystent dokumentacji technicznej (bot) dla złożonego oprogramowania wydaje się działać za każdym razem, 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 Actions, 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 zgłasza AssertionError – natychmiast przerywając kompilację CI i zapobiegając przedostaniu się niezauważonej regresji do środowiska produkcyjnego.

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

Retrieval Augmented Generation Assessment (Ragas) ma na celu ocenę RAG bez zestawu danych opisanego przez ludzi przez generowanie syntetycznych zestawów testowych.

Następnie oblicza flagowe metryki:

Rysunek B. Diagram triady oceny RAGAS łączący pytanie, kontekst i odpowiedź za pomocą metryk precyzji, kompletności, wierności źródłom i istotności (stworzony przez Kuriko IWAI)

Flagowe metryki są sklasyfikowane w trzy grupy:

• Potok odzyskiwania (czarna, ciągła linia, Rysunek B): Precyzja kontekstu, kompletność kontekstu.
• Potok generacji (czarna, kropkowana linia, Rysunek B): Wierność źródłom, istotność odpowiedzi.
• Punkty odniesienia (czerwona ramka, Rysunek B): Podobieństwo semantyczne odpowiedzi, poprawność odpowiedzi.

Typowy przypadek w praktyce

• Sytuacja: System RAG do analizy umów pomija kluczowe klauzule. Nie jesteś pewien, czy problem leży w wyszukiwaniu (mechanizm wyszukiwania) 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 ze 100 parami pytań i dowodów. Następnie uruchom potok RAG na zestawie testowym, aby obliczyć precyzję kontekstu i kompletność 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, która wskazuje, jak dobrze odpowiedź realizuje intencję zapytania, 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 oparta na tych źródłach.
• Rozwiązanie: Użyj TruLens, aby zaimplementować funkcję sprzężenia zwrotnego sprawdzającą oparcie w źródłach, 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 – Mapa awarii

Arize Phoenix to narzędzie open source do obserwowalności 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.

W ocenie RAG Phoenix wyróżnia się w analizie embeddingów: wykorzystuje Uniform Manifold Approximation and Projection (UMAP) do redukcji wielowymiarowych embeddingów wektorowych do przestrzeni dwu- lub trójwymiarowej.

Analiza embeddingów matematycznie ujawnia, czy nieudane zapytania tworzą grupy powiązane znaczeniowo, co wskazuje na lukę w wektorowej bazie danych.

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 promptu

Braintrust jest zaprojektowany do częstych 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 promptu 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 pokazuje dokładnie, które spośród wszystkich N = 50 przykładów referencyjnych poprawiły się lub pogorszyły.

Podsumowanie

Przy zastosowaniu odpowiednich narzędzi 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 jednego uniwersalnego 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 wierności źródłom, aby zmierzyć awarie integralności danych (FP1, FP4, FP7).

TruLens wykorzystuje swoją precyzję i kompletność 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.