Czym jest RAG? Retrieval-Augmented Generation wyjaśnione dla sektora MŚP

Ogólny model językowy nie zna Państwa wewnętrznych dokumentów. Został wytrenowany na danych publicznych i kończy się na określonej dacie granicznej. Gdy pracownik pyta o aktualną umowę dostawy z konkretnym dostawcą, model ma dwie możliwości: powie, że nie zna odpowiedzi, albo wymyśli taką, która brzmi wiarygodnie. Ta druga możliwość jest niebezpieczna.

RAG zamyka tę lukę. Przed każdą odpowiedzią system przeszukuje Państwa własne źródła, na przykład umowy, podręczniki, zgłoszenia lub wiki, i przekazuje modelowi odpowiednie fragmenty. Model formułuje wówczas odpowiedź opartą na tych konkretnych fragmentach i potrafi je zacytować. Z modelu, który musi zgadywać, powstaje system, który sprawdza źródła. Dalsze korzyści biznesowe opisaliśmy w Discover the Potential of AI in Business.

Pipeline RAG składa się z pięciu kroków, które można wyraźnie od siebie oddzielić.

1. Indeksowanie. Państwa dokumenty są dzielone na małe fragmenty i tłumaczone na wektory liczbowe, które odwzorowują ich znaczenie. Te wektory znajdują się w bazie danych wektorowej.
2. Retrieval. Dla danego pytania system oblicza pasujący wektor i pobiera z bazy danych najbardziej podobne fragmenty. To tutaj rozstrzyga się jakość późniejszej odpowiedzi.
3. Augmentacja. Znalezione fragmenty trafiają razem z pytaniem do promptu modelu.
4. Generowanie. Model formułuje odpowiedź na podstawie dostarczonego kontekstu, a nie ze swojej pamięci.
5. Podanie źródeł. System wskazuje dokumenty, z których pochodzi odpowiedź, dzięki czemu człowiek może je zweryfikować.

Ważny jest trzeci punkt tego rozdzielenia: mogą Państwo wymienić model bez ponownego przygotowywania danych, oraz mogą Państwo aktualizować dane bez ingerowania w model.

W praktyce najwięcej energii pochłania wybór modelu. Z naszego doświadczenia wynika, że dźwignia leży częściej po stronie retrievalu. Zadaliśmy to samo pytanie merytoryczne dużemu, hostowanemu modelowi oraz mniejszemu modelowi lokalnemu ze starannie dostrojonym retrieverem. Przy jednoznacznych pytaniach oba wypadały tak samo. W przypadkach niejednoznacznych, czyli tej mniejszości, która naprawdę się liczy, o użytecznej odpowiedzi decydowała jakość retrievalu, nie rozmiar modelu.

Powód jest prosty: większy model formułuje błędną odpowiedź jedynie bardziej elokwentnie, jeśli brakuje mu właściwego fragmentu. Dobrze dostrojony retriever dostarcza natomiast odpowiednie miejsce, i wtedy wystarcza mniejszy model. Tę samą obserwację opisaliśmy już szerzej w naszym wcześniejszym artykule o Retrieval-Augmented Generation.

RAG dobrze pasuje do architektury dbającej o ochronę danych, ponieważ wszystkie elementy składowe można eksploatować we własnym domu. Retriever, baza wektorowa i model mogą działać on-premise, dzięki czemu ani pytanie, ani znalezione dokumenty nie trafiają do zewnętrznej usługi. Dla firm pracujących z danymi osobowymi, umowami lub dokumentacją konstrukcyjną jest to często warunek, by projekt w ogóle mógł wystartować.

Który model nadaje się do pracy lokalnej i z jakim sprzętem, omawiamy w Lokalny LLM w firmie: sprzęt, koszty, rzeczywistość. Podstawowe rozważenie między pracą lokalną a chmurą znajduje się w On-Premise kontra Cloud-LLM: kiedy lokalna AI jest właściwym wyborem.

RAG opłaca się, gdy Państwa wiedza tkwi w dokumentach, regularnie się zmienia i jest odpytywana przez wiele osób. Typowe przypadki to wewnętrzne bazy wiedzy, wsparcie, weryfikacja ofert oraz wyszukiwanie w dokumentacji technicznej.

RAG opłaca się mniej, gdy odpowiedzią ma być dokładne obliczenie z bazy danych, ponieważ do tego klasyczne zapytanie jest precyzyjniejsze. Nie zastępuje też starannego utrzymania danych: jeśli dokumenty źródłowe są sprzeczne lub nieaktualne, nawet dobry retrieval dostarczy sprzeczne odpowiedzi. Pierwszym krokiem projektu RAG jest więc zwykle rzetelny przegląd istniejącej wiedzy, a nie wybór modelu.