Dlaczego pewna siebie odpowiedź może być gorsza niż brak odpowiedzi
Kończysz budowę wewnętrznego chatbota. Karmisz go każdą polityką HR, specyfikacją inżynieryjną i dokumentem onboardingowym, jakie posiada Twoja firma. Nowy pracownik pyta o limit wydatków na podróże podczas kolacji z klientem. Bot odpowiada natychmiast. Brzmi bardzo pewnie. Podany przez niego limit to 75 USD na osobę.
Rzeczywista polityka mówi o 50 USD. Bot zmyślił tę odpowiedź. Nigdy nie otworzył Twoich plików. Po prostu zgadł, opierając się na wzorcach ukrytych w danych treningowych sprzed lat. To brutalna rzeczywistość korzystania z surowych dużych modeli językowych (LLM) w odniesieniu do prywatnych dokumentów. Nie mają one dostępu do Twojej wewnętrznej wiedzy. Gdy fakty, których potrzebują, znajdują się poza ich wagami treningowymi, fabrykują odpowiedzi zamiast przyznać się do niewiedzy. W środowisku produkcyjnym przestaje to być zabawne, a zaczyna stanowić ryzyko.
Retrieval-Augmented Generation, czyli RAG, powstało właśnie po to, aby rozwiązać ten problem. Zamiast prosić model o zapamiętanie wszystkiego, pozwalasz mu wyszukiwać informacje.
Od zgadywania do czytania
Wyobraź sobie surowy model LLM jako genialnego kolegę z fotograficzną pamięcią, który jednak odszedł z firmy, zanim do niej dołączyłeś. Potrafi pisać kwiecistym językiem, rozwiązywać zagadki logiczne i wyjaśniać pojęcia w prosty sposób. Zapytaj go jednak o zmiany w API z ostatniego kwartału, a po prostu wymyśli coś, co brzmi wiarygodnie. Nie ma innego wyjścia.
RAG daje temu koledze dostęp do szafy z dokumentami. Gdy użytkownik zadaje pytanie, system nie rzuca go ślepo do modelu. Najpierw wyszukuje odpowiednie dokumenty, wkleja je do promptu jako kontekst, a dopiero potem prosi model o przeczytanie i udzielenie odpowiedzi. Model zmienia swój tryb z przywoływania faktów na rozumienie faktów, które znajdują się dosłownie przed nim.
Ten proces dzieli się wyraźnie na dwie części: przygotowanie offline oraz odpowiedź online.
Faza 1: Faza przygotowawcza (Offline)
Na długo przed tym, zanim ktokolwiek wpisze pytanie, musisz przekształcić swoją chaotyczną kolekcję dokumentów w przeszukiwalną bazę wiedzy. To przygotowanie decyduje o tym, czy Twój system RAG odniesie sukces, czy po cichu zawiedzie.
Document loaders to Twój punkt wyjścia. Te konektory wyciągają surowy tekst z plików PDF, przestrzeni roboczych Notion, folderów SharePoint, stron internetowych i wewnętrznych wiki. To tutaj pojawiają się pierwsze problemy. Ładowarka może wyodrębnić czysty tekst z dokumentu Word, ale „zadławi się” przy skanowanym pliku PDF, który jest w rzeczywistości tylko obrazem bez warstwy tekstu. Ładowarka zwraca pusty ciąg znaków, Twoja baza danych nic nie zapisuje, a użytkownik otrzymuje później odpowiedź „nie wiem” bez żadnego ostrzeżenia. Zawsze weryfikuj, co faktycznie wyodrębniły Twoje ładowarki. Wykonuj kontrole próbne na kilku dokumentach z każdego źródła, zanim zaufasz całemu procesowi (pipeline).
Następnie następuje text splitting, czyli dzielenie tekstu na fragmenty (chunking). Nie możesz wrzucić osiemdziesięciostronicowej polityki bezpieczeństwa do promptu w jednym kawałku; przekroczyłbyś limity kontekstu i pogrzebał istotne informacje w szumie. Zamiast tego dzielisz dokumenty na fragmenty (chunks). Kluczem jest wybór odpowiedniego rozmiaru. Zbyt małe fragmenty, np. pojedyncze zdania, często gubią krytyczny kontekst. Fragment brzmiący „Wszystkie żądania muszą być zatwierdzone przez menedżera” zapomina wspomnieć, że zasada ta dotyczy tylko podróży zagranicznych. Zbyt duże fragmenty, jak całe rozdziały, rozmywają embedding i mylą proces wyszukiwania, ponieważ obejmują piętnaście różnych tematów naraz. W praktyce wiele zespołów zaczyna od fragmentów o rozmiarze od 300 do 500 tokenów, z 50-tokenowym nakładaniem się (overlap), aby zdania przechodzące przez granicę podziału nie zostały zniekształcone. Dostosuj to do swoich treści. Dokumentacja API toleruje mniejsze fragmenty. Umowy prawne często wymagają większych, aby zachować logikę warunkową.
Po podzieleniu każdy fragment jest konwertowany na embedding. Oznacza to przepuszczenie tekstu przez model, który generuje listę liczb, czyli wektor, reprezentujący znaczenie semantyczne fragmentu. Podobne idee znajdują się blisko siebie w tej przestrzeni matematycznej. „polityka dopłat do 401k” i „zasady składek emerytalnych” będą znajdować się bliżej siebie niż „polityka dopłat do 401k” i „konfiguracja drukarki biurowej”. Te wektory są przechowywane w vector database (bazie wektorowej), takiej jak Pinecone, Weaviate lub otwartoźródłowej alternatywie, jak Chroma. Magazyn wektorowy to nie tylko miejsce na składowanie danych. To indeks zoptymalizowany pod kątem wyszukiwania najbliższych sąsiadów (approximate nearest-neighbor search), co pozwala znaleźć najbardziej trafne fragmenty w milisekundach, nawet spośród milionów dokumentów.
Faza 2: Ścieżka na żywo (Online)
When a user finally asks, "What is our travel reimbursement policy for client dinners?", the live pipeline kicks in.
The