Siedem architektur RAG wykraczających poza proste podejście oraz sytuacje, w których każda z nich jest odpowiednia.

Pierwszy pipeline RAG, który buduje większość ludzi, jest prosty: dzieli dokumenty na fragmenty, tworzy embeddingi, pobiera kilka najlepszych dopasowań, umieszcza je w promptzie i pozwala modelowi LLM udzielić odpowiedzi. Dema działa, a odpowiedzi brzmią przekonująco. Potem pojawiają się prawdziwe pytania. Zwraca się niewłaściwy fragment. Pojawia się właściwy dokument, ale brakuje potrzebnego ustępu. Czasami informacja znajduje się w bazie danych, ale model nigdy jej nie widzi.

Dziwne jest to, że żaden komponent nie jest uszkodzony. System działa dokładnie tak, jak został zaprojektowany. Tutorials rzadko podkreślają prawdziwą lekcję: wypełnianie bazy danych wektorowych jest proste, natomiast dostarczenie odpowiednich informacji modelowi stanowi trudny problem. Ten pierwszy projekt to proste podejście RAG. Ma swoje zastosowania, będąc naturalnym punktem wyjścia, ale gdy dokumenty stają się chaotyczne, pytania trudniejsze lub ważna jest niezawodność, taki cykl pobierania i odpowiadania osiąga swoje granice. Następują siedem bardziej zaawansowanych architektur, z których każda rozwiązuje określony problem, ma swoje prawdopodobne punkty awarii oraz sposób na ocenę, czy dany system ich potrzebuje.

Dlaczego istnieje RAG

LLM zna tylko to, czego nauczyło się podczas treningu. Gdy zadasz pytanie dotyczące wewnętrznych dokumentów firmy lub ostatnich wydarzeń, albo przyzna do braku wiedzy, albo, co gorsza, wymyśli pewną siebie odpowiedź. RAG rozwiązuje ten problem w podobny sposób jak umożliwienie uczniowi zabrania notatek na egzamin. System najpierw znajduje odpowiednie materiały i przekazuje je jako odniesienie, dzięki czemu model nie musi odpowiadać wyłącznie na podstawie pamięci.

Bazowy proces jest przedstawiony poniżej.

Gdy użytkownik zadaje pytanie, system wykonuje cztery kroki:

1. Szuka w zewnętrznej bazie wiedzy odpowiednich materiałów
2. Pobiera najbardziej pasujące fragmenty
3. Dodaje te fragmenty do zapytania jako uzupełnienie
4. Przesyła wszystko do LLM, które tworzy odpowiedź na podstawie tego kontekstu

W skrócie: pytanie, wyszukiwanie, pobieranie danych, dodawanie kontekstu, LLM, odpowiedź. To rozwiązanie dobrze funkcjonuje przy małych, uporządkowanych zbiorkach dokumentów. Prawdziwe dane rzadko zachowują się w ten sposób, i zwykle pojawiają się pięć słabości:

• Kawałki tekstu tracą kontekst. Fragment mówiący o wzroście przychodów o 3% nie wskazuje, o której firmie czy kwartale mowa.
• Informacje mogą zostać przeoczone. Tabele, wykresy oraz zeskanowane strony często nie przetrwają procesu wyszukiwania opartego na tekście.
• Pierwsze wyszukiwanie może być błędne, a podstawowe rozwiązania typu RAG nie próbują wykonać innego wyszukiwania.
• Wcześniejsze rozmowy znikają. Bez pamięci każda sesja zaczyna się od zera.
• Fakty pozostają niespójne. Gdy informacje są rozproszone w różnych dokumentach, może być konieczne ich połączenie, aby odpowiedź miała sens.

To nie są pięć przypadkowych problemów. Wyjaśniają one, dlaczego istnieją różne architektury, a każdy z wymienionych problemów dotyczy innego błędu w podstawowym procesie przetwarzania danych.

1. Uwagi do fragmentów kontekstowych

Zanim fragment zostanie zapisany, dołącza się krótką notatkę wyjaśniającą, o czym jest, aby nadal miało to sens po opuszczeniu dokumentu źródłowego. Wyobraź sobie, że wyrwasz jeden akapit z książki i dasz go obcemu człowiekowi bez tytułu ani numeru rozdziału – nie będzie mógł stwierdzić, do czego odnosi się. Lepiej najpierw dodać notatkę: pochodzi to z Rozdziału 4, dotyczącego wyników finansowych firmy za drugi kwartał. To właśnie jest cała idea.

Sam fragment informuje jedynie o wzroście przychodów o 3% w porównaniu z poprzednim kwartałem, bez podania firmy i roku. Gdy dołączy się notatkę, staje się jasne, że pochodzi ona z raportu ACME Corp za drugi kwartał 2023 roku, a następnie podano tę samą zdanie.

Raw chunk:        "revenue grew 3% over the previous quarter"
                   -> which company? which year? unclear

With a note attached:  "From ACME Corp's Q2 2023 filing.
                        Revenue grew 3% over the previous quarter."
                   -> now it makes sense on its own

Zaletą jest to, że odzyskane fragmenty mają sens samodzielnie, a sama metoda wyszukiwania pozostaje nietknięta, ponieważ zmienia się tylko to, co jest przechowywane. Wadą jest koszt: notatka dla każdego fragmentu wymaga czasu i pieniędzy jeszcze przed rozpoczęciem wyszukiwania, a źle napisana notatka może skierować wyszukiwanie w złą stronę równie łatwo, jak dobra notatka – we właściwą.

2. Wyszukiwanie multimodalne

Dokumenty często wcale nie są tekstem prostym. Konwertowanie strony PDF na tekst i jej wyszukiwanie może zniekształcić tabele i wykresy, dlatego alternatywą jest umożliwienie systemowi przeglądania strony jako obrazu. Porównaj czytanie opisu kogoś dotyczącego wykresu z patrzeniem na sam wykres. Opis może pominąć szczegóły lub błędnie podać liczby, natomiast oryginał tego nie robi.

W starszym podejściu strona PDF jest konwertowana na tekst, przewiduje się układ tabeli, a następnie wyszukuje się tekst, przez co liczby i struktura mogą ulec zaburzeniu. W podejściu multimodalnym strona jest wyszukiwana bezpośrednio jako obraz.

Old way:  PDF page -> extract text -> guess at the table layout -> search the text
          (numbers and structure can get scrambled along the way)

Multimodal way:  PDF page -> search the page as an image directly
                 (the table stays a table, the chart stays a chart)

Obsługuje to tabele, wykresy oraz skany, które psują proces wydobywania tekstu, a także eliminuje krytyczny etap w łańcuchu przetwarzania. Kosztem jest intensywniejsze obliczanie w porównaniu z wyszukiwaniem w tekście prostym oraz młodszy ekosystem z mniejszą liczbą narzędzi i ograniczoną wiedzą społeczności.

3. Wyszukiwanie hybrydowe

Dwa rodzaje wyszukiwania działają jednocześnie – jedno rozumie znaczenie, a drugie dopasowuje dokładne słowa – a ich wyniki są łączone. Wyobraźmy sobie dwóch bibliotekarzy: jeden rozumie, co masz na myśli, nawet jeśli twoje sformułowanie jest nieprecyzyjne, natomiast drugi nie rozumie kontekstu, ale zawsze znajdzie dokument zawierający dokładnie wpisany przez ciebie kod. Chodzi właśnie o to, by mieć obu do dyspozycji.

Weźmy zapytanie „error E0502 borrow checker”. Wyszukiwanie oparte na znaczeniu znajduje dokumenty dotyczące pokrewnego tematu nawet bez dokładnej frazy, natomiast wyszukiwanie dokładnych słów znajduje dosłowny ciąg znaków „E0502”, a połączone wyniki łączą oba te wyniki.

Query: "error E0502 borrow checker"

Meaning-based search:   finds docs about a similar concept, even without that exact phrase
Exact-word search:      finds the literal string "E0502"
Combined:               merges both into one final list

Jedno wyszukiwanie obejmuje zarówno ogólne kwestie konceptualne, jak i precyzyjne terminy techniczne, co eliminuje powszechną słabość: samo wyszukiwanie oparte na znaczeniu często sprawdza się słabo w przypadku kodów, identyfikatorów i żargonu. Kosztem jest konieczność używania dwóch systemów wyszukiwania, a decydowanie o tym, jak dużą wagę powinny mieć wyniki każdego z nich, wymaga dokładnej kalibracji.

4. Wyszukiwanie w stylu grafów i map

Zamiast przechowywać izolowane fragmenty, ten podejście pokazuje, w jaki sposób osoby, firmy i pomysły zawarte w dokumentach są ze sobą powiązane, grupuje te powiązane elementy i z góry tworzy krótkie streszczenia dla każdej grupy. Gdy pytanie jest zbyt szerokie, by odnieść się do pojedynczego fragmentu, system korzysta z tych streszczeń grupowych i może nawet samodzielnie określić, które grupy wymagają dalszej analizy.

Załóżmy, że ktoś chce poznać główne tematy we wszystkim, co zostało opublikowane w tym roku. Żaden pojedynczy artykuł nie odpowiada na to pytanie. Gdyby organizacja była podzielona na działy, z których każdy miałby jednostronicowy podsumowanie swojej pracy, szybkie odpowiedzi uzyskalibyśmy, czytając właśnie te strony. To jest taka „mapa”. Mądrzejsza wersja funkcjonuje jak asystent, który najpierw określa, które działy są istotne dla zadanej pytania, zamiast czytać wszystkie podsumowania bez rozróżnienia.

Proces składa się z dwóch kroków. Najpierw, z góry, tworzy się tę „mapę”: ustala się, w jaki sposób ludzie i pomysły są ze sobą powiązani, grupuje się powiązane elementy i pisze podsumowanie dla każdej grupy. Następnie na podstawie tych podsumowań odpowiada się na szerokie pytanie.

Step 1, build the map (done once, ahead of time):

  Documents -> find how people/ideas connect -> group related ones
            -> write a short summary for each group

Step 2, answer a broad question:

  "What are the big themes here?"
  -> pick the relevant groups (a smart version does this pick automatically)
  -> read just their summaries -> combine into one answer

Zalety: szerokie pytania tematyczne mogą zostać odpowiedziane, gdy żaden pojedynczy fragment nie jest w stanie tego zrobić, można jednocześnie prześledzić powiązania pomiędzy wieloma dokumentami, a funkcja samousuwania pomija streszczenia, które nie są istotne. Wady: tworzenie takiej mapy wymaga rzeczywistego projektu, jej części muszą być ponownie budowane za każdym razem, gdy dokumenty ulegają znacznym zmianom, a krok wyboru grup to kolejne miejsce, w którym system może dokonać złego wyboru.

5. Iteracyjne wyszukiwanie za pomocą agentów

Mapa pomaga odpowiedzieć na pytania ogólne, ale niektóre wymagają kilku wyszukiwań, bez względu na to, jak dobra jest mapa. W tym przypadku system przeprowadza wyszukiwanie, sprawdza uzyskane wyniki, decyduje, czy to wystarczy, a w razie potrzeby powtarza proces. Porównaj to do asystenta badawczego: silnik wyszukiwania zwraca jedną listę i przestaje, natomiast asystent czyta wyniki, widzi, że są niewystarczające, i wraca po więcej informacji, wykorzystując zdobytą wiedzę, by za drugim razem szukać bardziej skutecznie.

Pętla funkcjonuje w ten sposób: pojawia się pytanie, przeprowadzane jest jedno wyszukiwanie, a system pyta, czy to wystarczy. Jeśli nie, przeprowadza kolejne wyszukiwanie, korzystając z uzyskanych informacji, a jeśli i to nie przynosi rezultatów, próbuje innego podejścia.

Question comes in
     -> Search once -> "Is this enough to answer?"
     -> No: search again, using what was just learned
     -> No, still not enough: search again, from a different angle
     -> Yes: now answer

Zadaje sobie radę z pytaniami, które naprawdę wymagają wielokrotnych wyszukiwań, i nie rezygnuje po jednej nieudanej próbie, w odróżnieniu od stałych procesów. Kosztem jest dodatkowa podróż w obie strony za każde dodatkowe wyszukiwanie, co powoduje wzrost wydatków i czasu oczekiwania, a niewłaściwie dobrane podejście może sprawić, że stracone zostaną kilka prób, zanim zostanie zauważony błąd.

6. Wyszukiwanie z udziałem wielu agentów

Tutaj jeden system nie planuje, nie wyszukuje, nie sprawdza i nie pisze samodzielnie. Te zadania są rozdzielane pomiędzy mniejsze, specjalistyczne systemy, z których każdy doskonale wykonuje jedną funkcję, a koordynator zarządza całym procesem. Jedna osoba, która jednocześnie prowadzi badania, pisze i sprawdza fakty, zazwyczaj robi przeciętne wyniki we wszystkich trzech obszarach. Mały zespół, składający się z osoby planującej, badającej, weryfikującej i piszącej, zwykle radzi sobie lepiej w każdej z tych czynności.

Nadchodzi pytanie, planista decyduje, co należy sprawdzić, wyszukiwacze szukają odpowiedzi, czasami z różnych źródeł jednocześnie, a sprawdzający analizuje uzyskane wyniki pod kątem dokładności.

Question comes in
  -> Planner decides what needs to be looked up
  -> Searchers go look, sometimes from different sources at the same time
  -> Checker reviews what came back for accuracy
  -> Writer puts together the final answer

Każda część zadania jest traktowana z pełną uwagą, zamiast gdyby jeden system miał się nim zajmować we wszystkim, a poszukiwania równoległe oszczędzają czas. Z drugiej strony, większa liczba współpracujących systemów zwiększa koszt za każde pytanie, a błędna ostateczna odpowiedź wymaga sporego wysiłku, by ją wyśledzić poprzez kilka kroków.

7. Wyszukiwanie oparte na pamięci

W takim podejściu system szuka nie tylko w ustalonej kolekcji dokumentów, ale także we własnej historii interakcji z użytkownikiem, traktując wcześniejsze rozmowy jako coś, do czego można się odwołać, zamiast je zapominać po zakończeniu. Wyobraź sobie lekarza, który przed każdą wizytą czyta twoją kartę medyczną, w porównaniu z tym, który za każdym razem każe ci opowiadać całą historię swojej choroby. Większość tego, co powiedziałeś podczas ostatniej wizyty, nadal znajduje się gdzieś w folderze, a dobry system w podobny sposób przechowuje ważne informacje i korzysta z nich, gdy jest to konieczne.

Pozwala to systemowi przywoływać informacje wspomniane kilka dni lub tygodni wcześniej, bez konieczności ładowania wszystkiego jednocześnie, i pomaga w sprawach osobistych lub ciągłych, poza jednorazowymi wyszukiwaniami dokumentów. Wadą jest dodatkowy system pamięci dodany na wierzch wyszukiwania dokumentów, co oznacza większą liczbę elementów działających wspólnie, a także fakt, że starsze informacje są czasami kompresowane lub streszczane w celu zaoszczędzenia miejsca, przez co mogą zostać utracone szczegóły.

Wybór

Naive RAG zawodzi w sposób niewidoczny. Nigdy nie powoduje awarii ani błędów. Użytkownicy otrzymują po prostu odpowiedzi oparte na błędnych informacjach, a wszystko wygląda normalnie, dopóki ktoś tego nie sprawdzi.

Każda z opisanych powyżej architektur istnieje dlatego, że ktoś przypisał błędną odpowiedź jednej konkretnej, naprawialnej przyczynie. Dlatego najnowsza opcja nie jest automatycznie tą, którą należy wybrać. Wybierz taką, która odpowiada sposobowi, w jaki odbywa się pozyskiwanie informacji. Przyjrzyj się obecnemu procesowi i zapytaj siebie szczerze: gdy daje on błędną odpowiedź, czy wyszukiwarka znalazła zły wynik, czy jakaś część danych straciła swój kontekst, czy też system w ogóle nie sprawdził tego ponownie? Już samo to pytanie wskazuje na architekturę, która będzie potrzebna dalej.