← Wszystkie artykuły

Czym jest RAG (Retrieval-Augmented Generation) i dlaczego ma znaczenie

Burncode Team 3 minuty czytania

Jeśli korzystaliście z asystenta AI, który zdaje się naprawdę znać wewnętrzną dokumentację waszej firmy albo trafnie odpowiada na pytania o konkretną instrukcję produktu, jest spora szansa, że prawdziwą pracę wykonuje za kulisami generowanie wspomagane wyszukiwaniem – RAG – a nie sam model językowy.

Problem, który rozwiązuje RAG

Duży model językowy „wie” tylko to, co widział podczas trenowania, a trenowanie odbyło się w określonym momencie, na określonym zbiorze publicznych tekstów. Model nie ma wbudowanego dostępu do wewnętrznej wiki waszej firmy, aktualnego cennika produktu, zgłoszeń z zeszłego tygodnia ani niczego, co nie istniało (lub nie było publiczne) w chwili trenowania. Zadajcie mu bezpośrednie pytanie o którąkolwiek z tych rzeczy, a albo powie, że nie wie, albo – znacznie częściej – z pewnością siebie zgadnie odpowiedź, która brzmi wiarygodnie, ale jest błędna.

Nie da się też po prostu wkleić całej bazy wiedzy do każdego zapytania – większość tych modeli ma twarde limity ilości tekstu, jaki mogą jednocześnie uwzględnić, a nawet gdy limit jest hojny, upychanie wszystkiego, co macie, jest wolne, drogie i często pogarsza odpowiedź zamiast ją poprawiać, bo naprawdę istotne treści giną w szumie.

Jak naprawdę działa RAG

Generowanie wspomagane wyszukiwaniem rozwiązuje ten problem prostym, dwuetapowym procesem, wykonywanym od nowa przy każdym pytaniu:

  • Wyszukiwanie (retrieve). Gdy użytkownik zadaje pytanie, system najpierw przeszukuje wasze własne dokumenty – bazę wiedzy, zestaw plików PDF, katalog produktów, cokolwiek jest istotne – i wybiera konkretne fragmenty, które najprawdopodobniej zawierają odpowiedź.
  • Generowanie (generate). Wyszukane fragmenty trafiają do modelu językowego razem z pierwotnym pytaniem, w zasadzie w formie: „Oto, co naprawdę mówi nasza dokumentacja. Teraz odpowiedz na to pytanie, korzystając wyłącznie z tych informacji”.

Model nie polega już na tym, co zapamiętał podczas trenowania – czyta prawdziwy materiał źródłowy, który mu przekazaliście, dokładnie w chwili udzielania odpowiedzi, i na nim ją buduje.

Dlaczego to tak bardzo poprawia trafność

Model pracujący na prawdziwym, aktualnym tekście źródłowym znacznie rzadziej zmyśla niż model polegający wyłącznie na pamięci, bo ma konkretny materiał, na którym może oprzeć odpowiedź, zamiast statystycznego zgadywania. To różnica między poproszeniem kogoś o odpowiedź z pamięci a wręczeniem mu właściwej instrukcji i poproszeniem, by odpowiedział na jej podstawie. Drugie podejście jest nie tylko zwykle trafniejsze – pozwala też pokazać użytkownikowi wyszukane fragmenty bezpośrednio, dzięki czemu może sam zweryfikować informację, zamiast wierzyć modelowi na słowo.

Gdzie RAG pojawia się w prawdziwych produktach

  • Asystenci obsługi klienta, którzy odpowiadają na podstawie waszej rzeczywistej dokumentacji pomocy, a nie ogólnego wyobrażenia o „obsłudze klienta”.
  • Wewnętrzne narzędzia wiedzy, które pozwalają pracownikom zadać pytanie zwykłym językiem i otrzymać odpowiedź opartą na firmowej wiki i dokumentach z zasadami.
  • Wyszukiwanie produktów i odpowiedzi na pytania dotyczące waszego konkretnego katalogu, stanów magazynowych czy specyfikacji – a nie ogólnej wiedzy o danej kategorii.

Czego RAG nie naprawia

RAG ogranicza zmyślone odpowiedzi, ale nie eliminuje ich całkowicie i jest tak dobry, jak etap wyszukiwania – jeśli system wybierze niewłaściwe fragmenty albo same dokumenty źródłowe są nieaktualne lub błędne, odpowiedź też taka będzie. Nie jest też darmowy: potrzebny jest prawdziwy, dobrze utrzymany pipeline, który zamienia dokumenty w przeszukiwalny indeks, a ten pipeline wymaga utrzymania wraz ze zmianami w dokumentacji.

Wniosek

Jeśli budujecie jakąkolwiek funkcję AI, która ma odpowiadać na pytania z wykorzystaniem informacji waszej firmy – a nie ogólnej wiedzy – RAG jest niemal zawsze właściwą architekturą, a nie miłym dodatkiem. To różnica między asystentem, który brzmi mądrze, a takim, który naprawdę ma rację.

Prawidłowe zbudowanie pipeline’u wyszukiwania – sensowny podział dokumentów na fragmenty, utrzymywanie aktualnego indeksu i obsługa przypadków brzegowych, w których wyszukiwanie nic nie zwraca – to większość prawdziwej pracy inżynierskiej przy funkcji RAG. Na tym właśnie skupia się Burncode, gdy wbudowujemy asystenta AI w produkt – długo po tym, jak szybkie demo wyglądałoby na gotowe.