Trzy przyczyny niepowodzeń systemów RAG w praktyce: fragmentaryczny kontekst, dewiacje i niewłaściwe wykorzystanie.

Dlaczego demo RAG działają, a systemy produkcyjne nie

Generowanie wzbogacone o wyszukiwanie stało się standardową architekturą w sztucznej inteligencji korporacyjnej. Asystenci, narzędzia do przechowywania wiedzy wewnętrznej, doradcy ds. zgodności oraz inteligentne systemy wyszukiwania w bankowości, ubezpieczeniach, ochronie zdrowia, telekomunikacji, handlu detalicznym i administracji publicznej wykorzystują je do łączenia modeli językowych z własną wiedzą firmy. Pomysł wydaje się prosty: pobrać istotne fragmenty z bazy wiedzy i przekazać je modelowi przed udzieleniem odpowiedzi. Realizacja tego w środowisku produkcyjnym jest znacznie trudniejsza, niż sugeruje proof of concept.

Wiele zespołów udaje im się uruchomić prototyp, ale później napotyka nowe problemy w skali większej. Odpowiedzi, które otrzymują, są niekompletne. Jakość wyszukiwania pogarsza się wraz ze wzrostem ilości danych. Brakuje kluczowego kontekstu, pojawiają się halucynacje, opóźnienia rosną, a użytkownicy otrzymują odpowiedzi, które są technicznie poprawne, ale praktycznie bezużyteczne. Czasami system wyszukiwania znajduje dokładnie odpowiednie dokumenty, a model i tak podaje błędną odpowiedź.

Ustawienia korporacyjne pogarszają sytuację, ponieważ wiedza jest rozproszona w tysiącach dokumentów, polityk, procedur, instrukcji operacyjnych oraz wytycznych regulacyjnych. Jedna decyzja biznesowa może zależeć od szczegółów rozproszonych w różnych sekcjach repozytorium, co sprawia, że jakość wyszukiwania jest równie ważna jak możliwości modelu.

Powszechnym błędem jest przekonanie, że lepszy RAG oznacza przede wszystkim lepszy LLM. Wybór modelu jest ważny, ale wiele problemów w produkcji ma inne źródło: dzielenie na fragmenty, architektura wyszukiwania, zarządzanie kontekstem, procesy rankowania oraz ocena. Dobrze zaprojektowany system wyszukiwania w połączeniu z wydajnym modelem często przewyższa nieudolny system korzystający z najnowocześniejszego modelu. W sektorach regulowanych, takich jak bankowość, znajomość tych sposobów awarii jest zazwyczaj cenniejsza niż znajomość wewnętrznych mechanizmów najnowszych modeli, ponieważ sukces w produkcji rzadko zależy od jednej tylko aktualizacji modelu. Zależy to od tego, jak dobrze informacje są wyszukiwane, rankowane, formułowane i prezentowane.

Trzy scenariusze pokazują, jak mogą wystąpić błędy:

• System znajduje istotne materiały, ale nadal pomija kluczowe niuanse.
• Jakość wyszukiwania pogarsza się wraz ze wzrostem bazy wiedzy.

Model udziela błędnej odpowiedzi, mimo że znaleziono właściwe dokumenty.

Podstawowa lekcja z tych trzech przypadków jest taka, że dobry RAG wynika z lepszego wyszukiwania, zarządzania kontekstem, oceny i projektowania systemu, a nie tylko z lepszych modeli.

Sytuacja pierwsza: istotny tekst, brak sedna

Jedną z najbardziej irytujących sytuacji jest ta, gdy narzędzie wyszukiwania znajduje odpowiednie fragmenty, ale odpowiedź nadal wydaje się powierzchowna. Może być poprawna pod względem faktograficznym, ale brakuje jej kontekstu, subtelnych szczegółów lub biznesowych niuansów, które ekspert człowiek dostrzegłby od razu. Staje się to coraz częstsze w przypadku długich dokumentów, których informacje są rozproszone w kilku sekcjach.

Załóżmy, że repozytorium wiedzy banku przechowuje zasady onboardingu klientów. Główne wymagania znajdują się w jednym rozdziale, obsługa wyjątków w innym, a wymagania regulacyjne w odrębnej sekcji zarządzanej przez dział ds. ryzyka. Klient pyta, czy określony dokument wystarcza do otwarcia konta. System wyszukiwania zwraca odpowiednią politykę onboardingu, pomijając jednak wyjątki regulacyjne udokumentowane w innym miejscu. Odpowiedź modelu jest poprawna biorąc pod uwagę to, co widział, ale nadal niepełna z punktu widzenia potrzeb biznesu. To przykład systemu, który postrzega tylko część dokumentu i nie dostrzega całościowej sytuacji.

Inżynierowie najczęściej podejrzewają model jako przyczynę problemu. Zwykłym winowajcą jest architektura wyszukiwania.

Kawałki o stałej wielkości przerywają ciągłość myśli

Pierwszą rzeczą, którą należy sprawdzić, jest podział na fragmenty. Wiele implementacji wykorzystuje fragmenty o stałej wielkości, ponieważ są łatwe do stworzenia i dobrze funkcjonują w eksperymentach – dzielą one dokumenty co kilkaset tokenów i przechowują te fragmenty w bazie danych wektorowej. Jest to proste rozwiązanie, ale często niszczy logiczne związki pomiędzy elementami. Dokumenty nie są pisane w blokach o wielkości tokena; są zorganizowane wokół idei, sekcji, polityk, procedur i koncepcji biznesowych. Gdy granica przecina któryś z tych elementów, kontekst ulega rozdrobnieniu. Definicja polityki może znaleźć się w jednym fragmencie, a jej wyjątek w innym. Narzędzie do wyszukiwania pobiera definicję, ale nigdy nie znajduje wyjątku, w rezultacie model wyciąga wnioski na podstawie niepełnych dowodów.

Rozwiązania problemu rozdrobnionego kontekstu

Semantyczne dzielenie na fragmenty to standardowe rozwiązanie. Zamiast dzielić tekst według arbitralnej liczby tokenów, uwzględnia ono naturalną strukturę, taką jak nagłówki, sekcje, akapity oraz zmiany tematu, co pozwala zachować powiązania między elementami i znacznie poprawia możliwości wyszukiwania.

Nawet w takim przypadku ważne informacje często znajdują się na granicy między dwoma fragmentami. Jeśli fragmenty są całkowicie niezależne, wyszukiwarka może je przeoczyć. Wtedy przydają się nakładające się na siebie fragmenty – umożliwiają one ciągłość pomiędzy nimi, ponieważ to, co zamyka jeden fragment, jednocześnie otwiera następny, co zmniejsza szanse na utratę istotnego kontekstu.

Gdy dokumenty stają się coraz bardziej złożone, projekt typu rodzic-dziecko okazuje się korzystny. Małe fragmenty są włączane i wyszukiwane, ponieważ zapewniają większą precyzję. Gdy jeden z takich małych fragmentów odpowiada kryteriom, system pobiera większą sekcję rodzicielską, w której się on znajduje, dzięki czemu model może zobaczyć zarówno odpowiadający fragment, jak i jego otoczenie. To tak, jakby znaleźć odpowiedni akapit, a następnie przeczytać całą sekcję zamiast kilku pojedynczych zdań.

Systemy produkcyjne pokazują również, że najlepsza odpowiedź rzadko znajduje się w pojedynym fragmencie. Informacje pomocnicze często znajdują się tuż przed lub po najlepiej ocenionym wyniku, więc pobranie tylko tego fragmentu może sprawić, że rozumowanie będzie niekompletne. Rozszerzenie procesu wyszukiwania o sąsiednie fragmenty obok głównego rezultatu zapewnia ciągłość i umożliwia modelowi zobaczenie, w jaki sposób poszczególne elementy się ze sobą łączą.

Rozwijające się bazy wiedzy zwiększają wymagania dotyczące jakości wyszukiwania. Wyszukiwanie wektorowe doskonale radzi sobie z znajdowaniem treści semantycznie podobnych, ale może pomijać dokładne terminy, nazwy produktów, identyfikatory polityk, odniesienia regulacyjne oraz słowa kluczowe specyficzne dla danej dziedziny. W bankowości klient może wspomnieć o konkretnej regulacji, typie konta lub kategorii transakcji, które wymagają dokładnego dopasowania. Hybrydowa strategia łącząca wyszukiwanie semantyczne z metodami opartymi na słowach kluczowych, takimi jak BM25, obejmuje obie te aspekty: wyszukiwanie semantyczne pozwala na uchwycenie znaczenia, a wyszukiwanie słowami kluczowymi – precyzję; razem zapewniają one lepsze wyniki niż każde z nich oddzielnie.

Ostatnimi krokami są ponowna klasyfikacja i optymalizacja kontekstu, zanim cokolwiek trafi do modelu. Nie każdy odzyskany fragment zasługuje na miejsce w końcowym poleceniu. Narzędzia do ponownej klasyfikacji wysuwają na górę najbardziej istotne materiały, a optymalizacja kontekstu eliminuje redundancje, aby maksymalnie wykorzystać dostępną przestrzeń. Celem nie jest jedynie odzyskanie istotnego tekstu – chodzi o to, by model uzyskał takie zrozumienie, jakie osoba posiadająca wiedzę uzyskałaby po przeczytaniu odpowiednich sekcji. Gdy proces odzyskiwania zachowuje relacje pomiędzy koncepcjami, zasadami, wyjątkami i dowodami, jakość odpowiedzi znacznie się poprawia, a subtelne informacje ukryte w długich dokumentach przestają być tracione.

Krótko mówiąc

W przypadku tego objawu należy przyjrzeć się warstwie wyszukiwania znajdującej się przed modelem. Należy przeanalizować strategię dzielenia na fragmenty, przejść na semantyczne dzielenie z nakładaniem się fragmentów, dodać funkcję wyszukiwania w ramach relacji rodzic-dziecko, rozszerzyć zakres o sąsiednie fragmenty oraz połączyć hybrydowe wyszukiwanie z ponownym sortowaniem wyników. Te zmiany zazwyczaj zapewniają modelowi bogatszy i lepiej powiązany kontekst, co jest tym, co najczęściej pomaga zachować subtelności w długich dokumentach.

Sytuacja druga: doskonałe w fazie rozwoju, niestabilne w produkcji

Często spotykana historia w firmach wygląda tak: system RAG świetnie radzi sobie podczas rozwoju, ale wkrótce po uruchomieniu zaczyna zwracać nieistotne lub niespójne wyniki. Dema przebiegła pomyślnie, zapytania testowe dawały dokładne odpowiedzi, funkcja wyszukiwania wydawała się niezawodna, a zaufanie do systemu było wysokie. Potem pojawił się rzeczywisty ruch użytkowników. Użytkownicy zadają różne pytania, do bazy wiedzy trafiają nowe dokumenty, zmieniają się procesy biznesowe, a objętość zapytań rośnie. Odpowiedzi, które kiedyś wydawały się poprawne, stają się niespójne, niekompletne lub nieodnoszące się do tematu.

Czy dane uległy zmianie?

Pierwszą sprawdzeniem jest to, czy rozkład danych uległ zmianie. Środowiska rozwojowe zawierają mały, starannie wybrany i uporządkowany zbiór danych. Środowisko produkcyjne może mieć tysiące lub miliony dokumentów napisanych przez różne zespoły w różnych formatach i standardach. Wyobraźmy sobie bank, który zaczyna od niewielkiego zestawu polityk integracyjnych, a następnie rozszerza go o procedury zgodności, dokumenty audytowe, wytyczne dotyczące oszustw, instrukcje produktów, korespondencję z klientami oraz powiadomienia regulacyjne. Zapytanie, które wcześniej wybierało spośród dziesięciu bardzo istotnych dokumentów, teraz musi konkurować z tysiącami częściowo powiązanych dokumentów. System wyszukiwania może nadal zwracać treści o podobnym brzmieniu, nie dostarczając jednak najbardziej przydatnych informacji, a to często jest pierwszym znakiem pogorszenia jakości wyszukiwania w miarę rozwoju bazy wiedzy.

Mierzyć jakość wyszukiwania oddzielnie

Następnie należy ocenić proces wydobywania informacji oddzielnie od modelu językowego. Powszechnym błędem jest obwinianie modelu LLM za słabe odpowiedzi, gdy system wydobywania informacji w ogóle nie dostarczył odpowiedniego kontekstu. Wskaźniki takie jak Recall@K i Precision@K szybko to wyjaśniają: jeśli poprawny dokument nie znajduje się wśród najlepszych wyników, model nigdy nie miał szansy. Często sam proces wydobywania informacji wymaga poprawek.

Jedną z częstych przyczyn jest dewiacja embeddingów. Model embeddingowy, który dobrze funkcjonował przy małym zbiorze danych, może mieć trudności wraz z różnorodnieniem się dokumentów, ponieważ różne typy, style pisania oraz słownictwo specjalistyczne z czasem osłabiają jego skuteczność. Baza wiedzy banku może zawierać polityki zespołów ds. zgodności, instrukcje zespołów biznesowych oraz specyfikacje inżynierów. Wszystko to należy do jednej organizacji, ale język jest bardzo zróżnicowany, a jeśli embeddingi nie odzwierciedlają tych różnic, jakość spada.

Strategie dzielenia na fragmenty również mogą stać się przestarzałe. Metoda, która sprawdziła się przy setkach dokumentów, może zawieść przy setkach tysięcy, ponieważ źle sformułowane fragmenty dodają szumu do wyszukiwania podobieństw i utrudniają znalezienie tego, co istotne. Dlatego systemy RAG w warunkach produkcyjnych wymagają ciągłej oceny, a nie jednorazowej konfiguracji.

Prawdziwe zapytania różnią się od zapytań testowych

Wzorce zapytań wymagają uwagi. Testy rozwojowe opierają się na idealnych pytaniach, ponieważ inżynierowie już znają dane. Prawdziwi użytkownicy zadają niejasne lub niedokończone pytania i używają terminów, których nie ma w bazie wiedzy. Pracownik obsługi może szukać „zasad zamknięcia konta premium”, podczas gdy oficjalne dokumenty mówią o „procedurach zakończenia współpracy z klientami o wysokiej wartości”. Ludzie od razu dostrzegają powiązanie, ale systemy wyszukiwania mogą tego nie zrobić. Obserwowanie interakcji prawdziwych użytkowników zazwyczaj ujawnia słabości, których testy nigdy nie wykryją.

Zobacz, jak wygląda proces

Jeszcze jedną cenną techniką jest możliwość obserwacji procesu pobierania danych. Dla każdej zapytania w środowisku produkcyjnym widoczność powinna obejmować:

• dokumenty, które zostały przywrócone
• powód ich pobrania
• wskaźniki podobieństwa
• końcowy kontekst wysłany do modelu językowego
• wygenerowaną odpowiedź

Bez tego debugowanie polega na domysłach. Dzięki temu ślady działania często pokazują, czy problem pojawił się podczas pobierania danych, ponownego sortowania, tworzenia promptu czy generowania odpowiedzi.

W miarę wzrostu ilości danych przed wyszukiwaniem wektorowym mogą znajdować się dodatkowe warstwy, takie jak hybrydowe metody pobierania danych, filtry metadanych, klasyfikacja dokumentów, narzędzia do ponownego sortowania lub specjalistyczne procesy dla określonych dziedzin. Na przykład pytanie bankowe dotyczące kredytów hipotecznych powinno być wyszukiwane w materiałach na ten temat przed całą bazą wiedzy firmy. Zwężenie obszaru wyszukiwania poprawia zarówno dokładność, jak i jakość odpowiedzi.

Kluczowym wnioskiem jest to, że systemy RAG produkcyjne są żywymi systemami, które ewoluują wraz z danymi. Nie można zakładać, że rozwiązanie, które dobrze funkcjonuje od pierwszego dnia, będzie działać tak samo po sześciu miesiącach, dlatego ciągłe monitorowanie, ocena oraz ponowne szkolenie komponentów służących do wyszukiwania są niezbędne, aby utrzymać jakość na odpowiednim poziomie.

Krótko mówiąc

Gdy system radzi sobie dobrze w fazie rozwoju, ale słabo w środowisku produkcyjnym, najpierw należy oddzielić problemy związane z wyszukiwaniem od problemów związanych z generowaniem treści. Należy przeanalizować metryki wyszukiwania, sprawdzić pobrane dokumenty, ocenić jakość embeddingów, przeanalizować rzeczywiste wzorce zapytań oraz zapewnić możliwość obserwacji całego procesu. W miarę wzrostu objętości danych warto rozważyć hybrydowe wyszukiwanie, filtrowanie metadanych, ponowne sortowanie wyników oraz wyszukiwanie specyficzne dla danej dziedziny, aby wyniki były istotne i dokładne.

Szczegóły trzeci: właściwe dokumenty, błędna odpowiedź

Wielu inżynierów zakłada, że gdy funkcja wyszukiwania działa poprawnie, praca jest zakończona. Jednym z najtrudniejszych scenariuszy w RAG jest sytuacja przeciwna: system znajduje właściwe dokumenty, a model nadal udziela błędnych odpowiedzi. Jest to szczególnie frustrujące, ponieważ typowy instynkt debugowania skupia się wyłącznie na funkcji wyszukiwania, mimo że ten element może wykonywać swoją pracę doskonale. Problem leży w sposobie, w jaki model przetwarza i analizuje dostarczony kontekst.

Załóżmy, że asystent ds. zgodności bankowej odpowiada na pytania dotyczące przeciwdziałania praniu pieniędzy. Użytkownik pyta, czy konto klienta może pozostać aktywne, podczas gdy weryfikacja KYC jest w toku. Funkcja wyszukiwania zwraca odpowiednie dokumenty regulacyjne, a istotna zasada znajduje się w kontekście. Mimo to odpowiedź twierdzi, że konto może pozostać aktywne w nieskończoność. Potrzebne informacje były obecne, ale model nie potrafił ich prawidłowo wykorzystać.

Nadmiar kontekstu i problem „zagubienia się pośrodku”

Jedną z przyczyn jest przeładowanie kontekstem. Im więcej dokumentów zostanie pobraanych, tym więcej musi przetworzyć model, a nie wszystko ma takie samo znaczenie, więc kluczowe szczegóły mogą zostać pogrzebane w długim zapytaniu. Często nazywa się to problemem „zagubienia się pośrodku”: modele mają tendencję do skupiania się na treściach znajdujących się na początku i na końcu kontekstu, pomijając to, co jest pośrodku. Prawidłowa odpowiedź może dosłownie znajdować się w zapytaniu, a mimo to zostać zignorowana.

Rozwiązaniem jest priorytetowanie jakości kontekstu nad jego ilością. Zespoły często próbują zwiększyć dokładność, pozyskując więcej danych, ale większa ilość kontekstu nie gwarantuje lepszych odpowiedzi – kilka wysokiej jakości fragmentów często przewyższa zbiór słabo powiązanych ze sobą. W takich przypadkach przydatna jest ponowna klasyfikacja, która umieszcza najbardziej istotne fragmenty przed modelem. Przedstawienie modelowi trzech wysoce relevantnych dokumentów z jasnymi dowodami może przynieść lepsze rezultaty niż dziesięć dokumentów o umiarkowanej relewności.

Zapytania wymagające uzasadnienia

Również projekt zapytań ma znaczenie. Zamiast pozwalać modelowi odpowiadać swobodnie, należy mu polecić, aby odpowiedź była ściśle oparta na uzyskanym kontekście oraz aby jasno stwierdził brak wystarczających informacji, gdy dowody nie pozwalają sformułować odpowiedzi. To skutecznie ogranicza niesprawdzone rozumowanie.

Generowanie w oparciu o cytaty również pomaga. Gdy model musi podać nazwy konkretnych sekcji lub identyfikatory dokumentów, znacznie łatwiej jest sprawdzić, czy odpowiedź opiera się na uzyskanych dowodach, co jest istotne w regulowanych branżach takich jak bankowość, gdzie wymagane są możliwości audytu i wyjaśniania działań.

Sprzeczne źródła

Należy sprawdzić, czy uzyskane dokumenty są ze sobą sprzeczne. Duże organizacje często przechowują kilka wersji polityk, procedur i wytycznych, a jeśli system wyszukiwania zwróci jednocześnie przestarzałe i aktualne wersje, model może nie wiedzieć, która ma pierwszeństwo. Filtrowanie metadanych oraz wersjonowanie dokumentów stają się wtedy niezbędne.

Celem nie jest tylko pozyskanie informacji. Chodzi o to, aby upewnić się, że model potrafi zidentyfikować, ustalić priorytety i przeanalizować najbardziej istotne dowody zawarte w tych dokumentach. System RAG odnosi sukces tylko wtedy, gdy wyszukiwanie i rozumowanie działają razem.

Krótko mówiąc

Gdy odpowiednie dokumenty wracają, a odpowiedź nadal jest błędna, sprawdź, w jaki sposób model wykorzystuje kontekst: przeładowanie informacjami, efekt utraty informacji w trakcie przetwarzania, sprzeczne źródła oraz słaba podstawa analityczna. Warto spróbować takich rozwiązań jak ponowne sklasyfikowanie wyników, skrócenie kontekstu, odpowiedzi zawierające odniesienia do źródeł, filtry metadanych oraz instrukcje zmuszające model do opierania się wyłącznie na uzyskanych dowodach. Często problemem nie jest sama pozyskiwanie informacji, lecz sposób ich wykorzystania.

Co łączy te trzy przypadki

Budowa dobrego systemu RAG wymaga znacznie więcej niż po prostu podłączenia bazy danych wektorowej do modelu LLM. Przykłady implementacji typu proof-of-concept często wyglądają imponująco, ale prawdziwe wyzwania pojawiają się w momencie, gdy systemy trafiają do produkcji i muszą działać niezawodnie w dużych skali. W tych trzech sytuacjach występują fragmenty kontekstu w dużych dokumentach, jakość wyszukiwania pogarsza się wraz ze wzrostem ilości repositoriów, a nawet przy dostępie do właściwych informacji model może nie być w stanie nad nimi rozumować.

Częstym motywem jest to, że jakość wydobywania informacji ma takie samo znaczenie jak możliwości modelu. Najnowocześniejszy LLM nie może nadrobić braku kontekstu, źle skonstruowanych fragmentów, słabych strategii wydobywania danych lub nieistotnego materiału w instrukcjach, a ulepszenie architektury wydobywania informacji często przynosi większe korzyści niż wymiana modelu. Dla inżynierów, architektów i kierowników technicznych to przemyślane projektowanie odróżnia systemy produkcyjne od efektownych demonstracji: właściwe dzielenie na fragmenty, solidne procesy wydobywania danych, oparcie w kontekście, ponowna sortowanie oraz ciągła ocena. AI w przedsiębiorstwach to nie tylko generowanie odpowiedzi – chodzi o tworzenie odpowiedzi, które są istotne, uzasadnione, wyjaśnialne i stale niezawodne.

Literatura pokrewna

• Ingestia danych RAG do produkcji w bankach: pliki PDF, OCR, tabele i łączniki — Jak importować dokumenty bankowe do systemu RAG: klasyfikacja plików PDF, wykonywanie OCR z flagami do sprawdzenia, zachowanie struktury plików Word, obsługa tabel i obrazów oraz tworzenie odpornych łączników.
• Czyszczenie danych dla systemu RAG do produkcji: kodowanie, OCR, usuwanie duplikatów i ochrona danych osobowych — Jak przekształcić skonwertowane dokumenty firmowe w tekst gotowy do wyszukiwania: naprawa kodowania, usuwanie szablonów i duplikatów, flagi wskazujące na ryzykowne wyniki OCR, obsługa języków oraz maskowanie danych osobowych.