Wyzwania i rozwiązania, czyli jak wdrażać LLM w architekturze RAG

Duże modele językowe stają się coraz bardziej powszechne. Wiele firm zaczyna wdrożenia AI od budowy asystentów w architekturze RAG. Tak się składa, że mam w tym temacie pewne doświadczenie, którym chciałbym się z Tobą podzielić. 😉

Czym jest RAG?

Zacznijmy od tego, czym w ogóle jest tytułowa architektura. RAG (ang. Retrieval-Augmented Generation) to połączenie dwóch głównych podejścia do przetwarzania języka naturalnego: wyszukiwanie informacji (ang. retrieval) oraz generowanie odpowiedzi (ang. generation).

W skrócie RAG umożliwia modelom językowym nie tylko generowanie tekstu na podstawie wprowadzonego zapytania, ale także wyszukiwanie i integrowanie odpowiednich informacji z dużych baz danych lub nieustrukturyzowanych dokumentów, aby dostarczyć bardziej precyzyjne i wartościowe odpowiedzi.

Dzięki temu połączeniu architektura RAG może znacząco poprawić jakość odpowiedzi generowanych przez modele AI, szczególnie w kontekście złożonych zapytań, które wymagają dostępu do aktualnych i specyficznych informacji.

RAG a halucynacje

RAG jest do pewnego stopnia remedium na największy problem dużych modeli językowych – halucynacje. Gdy zadajemy pytanie do LLM, to w większości przypadków korzysta on ze swojej „pamięci”, zgromadzonych informacji i połączeń pomiędzy nimi. Można to porównać to sytuacji, w której nauczyciel odpytuje ucznia z informacji przedstawionych na poprzedniej lekcji. Uczeń sięga do pamięci, która jest oczywiście zawodna. W związku z tym zdarza się, że uczeń niekiedy pomiesza pewne fakty. 😉

W RAG dodawane są do promptów odpowiednie informacje, które ułatwiają modelowi odpowiedź na zadane pytanie. Porównując to do sytuacji z uczniem i nauczycielem, uczeń podczas odpowiedzi ma dostęp do przygotowanych notatek z ostatnich zajęć. Ciągle istnieje pewne prawdopodobieństwo, że coś pomyli lub że notatki zostały źle przygotowane, ale samo ryzyko halucynacji znacząco maleje. 🙂

Wyzwanie 1: Przygotowanie i jakość danych

Z mojego punktu widzenia, to bodaj największe wyzwanie. LLM i RAG wymagają dużych ilości danych do skutecznego działania. Problemy, jakie napotyka się w tym temacie, można wymieniać niemal bez końca: niekompletne, zduplikowane, błędne dane, etc. Nie wspominając o pdf-ach i docx-ach o nieustandaryzowanej i niespójnej strukturze.

Do tego wszystkiego dochodzą problemy z fragmentacją. Staramy się dostarczyć do modelu konkretne i precyzyjne informacje, z zachowaniem odpowiedniego kontekstu, ale bez tworzenia zbyt długich fragmentów prowadzących m.in. do problemów z wyszukiwaniem.

Rozwiązanie

Aby zapewnić wysoką jakość danych, ważne jest stosowanie technik czyszczenia danych oraz walidacja danych wejściowych. Nie radzę poświęcać na to zbyt dużo czasu, gdyż łatwo można ugrzęznąć, czego sam doświadczyłem. W moim odczuciu znacznie lepszym pomysłem jest zbudowanie dosyć generycznego parsera, z kilkoma parametrami wejściowymi, które będziemy mogli optymalizować z użyciem zbioru testowego i dopiero po wysyceniu tych możliwości zastanowić się, czy można poprawić coś w procesie parsowania dokumentów, np. lepiej czyszcząc poszczególne dokumenty, dodając metadane, etc.

Wyzwanie 2: Dobór odpowiedniego modelu embeddingowego

Kolejnym wyzwaniem jest wybór właściwego modelu embeddingowego, który będzie używany do reprezentowania i wyszukiwania informacji (retrieval) w architekturze RAG. Embeddingi to wektory liczbowe, które reprezentują tekst w sposób umożliwiający jego porównywanie i wyszukiwanie. W kontekście RAG dobry model embeddingowy musi być nie tylko wydajny, ale również dobrze dostosowany do specyfiki danych, z jakimi pracujemy.

Rozwiązanie

Wybór odpowiedniego modelu embeddingowego można rozwiązać na kilka sposobów. Po pierwsze, warto rozważyć różne modele dostępne na rynku, takie jak Sentence-BERT, OpenAI Ada, czy modele oparte na BERT (Bidirectional Encoder Representations from Transformers).

Zawsze warto korzystać z MTEB (Massive Embedding Benchmark), aby znaleźć model, który najlepiej spełnia Twoje oczekiwania i najlepiej pasuje do danego zadania. Wybór modelu, który dostarcza lepsze i bardziej adekwatne reprezentacje numeryczne naszych fragmentów tekstu, może być zbawienny dla projektu.

Kluczem do sukcesu jest testowanie różnych rozwiązań na próbce danych, aby ocenić, który model najlepiej radzi sobie z danym zadaniem. Warto także brać pod uwagę czas przetwarzania zapytań oraz wielkość modeli. Ostatecznie, dobór odpowiedniego modelu pozwala na zwiększenie efektywności wyszukiwania i ograniczenie przypadków, gdzie wyniki wyszukiwania są mało precyzyjne lub nieadekwatne.

Wyzwanie 3: Przygotowanie parsera dokumentów

RAG często bazuje na dostępie do dużych, nieustrukturyzowanych źródeł danych, takich jak dokumenty PDF, arkusze kalkulacyjne czy strony internetowe. Jednym z kluczowych problemów jest prawidłowe przetwarzanie tych dokumentów i konwersja ich na formaty, które mogą być łatwo przeszukiwane i przetwarzane przez modele embeddingowe.

Rozwiązanie

Aby skutecznie zintegrować nieustrukturyzowane dane z architekturą RAG, konieczne jest opracowanie zaawansowanego parsera dokumentów. Narzędzia takie jak np. LangChain, czy PyMuPDF mogą być używane do ekstrakcji treści z różnych typów plików. Ważnym elementem jest nie tylko sam proces ekstrakcji, ale również jego optymalizacja pod kątem wydajności oraz precyzyjne mapowanie struktury dokumentu, np. podział na sekcje, nagłówki i treść główną, etc. Automatyczne oznaczanie kluczowych fragmentów tekstu oraz eliminacja zbędnych danych pozwala na zwiększenie efektywności procesu wyszukiwania i generowania odpowiedzi.

Wdrażanie dużych modeli językowych w architekturze RAG wymaga wielu działań optymalizacyjnych, począwszy od przygotowania danych, przez wybór odpowiednich modeli, aż po precyzyjne zarządzanie fragmentami tekstu. Jednak z doświadczenia mogę powiedzieć, że poprzez odpowiednią optymalizację i wykorzystanie dostępnych narzędzi, można osiągnąć znaczne usprawnienia, które uczynią RAG jeszcze bardziej skutecznym i wydajnym narzędziem do pracy z dużymi ilościami danych.

Wyzwanie 4: Zdefiniowanie odpowiedniej wielkości chunków

Kolejnym wyzwaniem, które napotykamy przy wdrażaniu RAG, jest określenie wielkości tzw. chunków, czyli fragmentów tekstu, które są poddawane przetwarzaniu przez LLM. Zbyt małe chunki mogą powodować, że model będzie miał niewystarczający kontekst, aby wygenerować odpowiednią odpowiedź, natomiast zbyt duże chunki mogą prowadzić do problemów z przetwarzaniem i powodować, że kluczowe informacje zostaną przeoczone.

Rozwiązanie

Optymalizacja wielkości chunków jest kluczowym elementem w procesie wdrażania RAG. Jednym z rozwiązań jest dynamiczne dostosowywanie wielkości chunków w zależności od typu zapytania. Na przykład, prostsze zapytania mogą wymagać mniejszych fragmentów tekstu, podczas gdy bardziej złożone, wymagające szerszego kontekstu, mogą korzystać z większych chunków. Można również zastosować różne techniki jak np. overlapping. Stosowanie ich pozwala na bardziej precyzyjne dostarczanie odpowiedzi, szczególnie w sytuacjach, gdzie wymagana jest precyzyjna analiza większych fragmentów tekstu.

Podsumowanie

Wdrażanie dużych modeli językowych w architekturze RAG to nie jest proste zadanie. Od jakości danych, przez dobór odpowiednich modeli embeddingowych, po optymalizację wielkości chunków i skuteczne przetwarzanie dokumentów – każdy z tych elementów ma duże znaczenie dla ostatecznej efektywności systemu. Kluczem do sukcesu jest ciągła optymalizacja na każdym etapie wdrożenia oraz umiejętne wykorzystanie dostępnych narzędzi, które mogą usprawnić zarówno proces wyszukiwania informacji, jak i generowania odpowiedzi.

Mam nadzieję, że ten wpis przypadł Ci do gustu. Daj, proszę, znać czy masz jakieś doświadczenia z architekturą RAG i co było dla Ciebie największym wyzwaniem przy jej wdrażaniu. 🙂