Retrieval-Augmented Generation (RAG) obiecuje połączenie wiedzy z zewnętrznych źródeł z możliwościami modeli językowych. W teorii brzmi to prosto: znajdź właściwe dane, przekaż je modelowi i wygeneruj odpowiedź. W praktyce wiele wdrożeń kończy się rozczarowaniem.

Problem najczęściej nie leży w modelu ani w bazie wektorowej. Problemem jest nadmierna złożoność.

Jedna z najważniejszych lekcji wyniesionych z projektów realizowanych przez PCEUROPA jest bardzo prosta:

Jeżeli rozwiązanie jest zbyt skomplikowane, najczęściej nie osiągnie swojego celu. Będzie trudne w utrzymaniu, kosztowne, podatne na błędy, a w dłuższym czasie zostanie wyprzedzone przez prostsze i bardziej przewidywalne rozwiązania.

W świecie RAG ta zasada sprawdza się wyjątkowo dobrze.

Antywzorce = RAG piekło złożoności

Mechaniczne dzielenie tekstu

Sztuczne cięcie dokumentów na fragmenty po 500, 1000 czy 2000 znaków to jeden z najczęstszych błędów.

Takie podejście rozrywa zdania, niszczy relacje między akapitami i często rozbija tabele lub listy. W efekcie model otrzymuje pozbawione sensu fragmenty informacji.

Chunk powinien wynikać ze struktury dokumentu, a nie z arbitralnej liczby znaków.

Traktowanie PDF jako zwykłego tekstu

PDF nie jest plikiem tekstowym.

Zawiera strukturę, nagłówki, sekcje, tabele, wykresy i relacje przestrzenne. Zamiana wszystkiego na jeden ciąg znaków powoduje utratę ogromnej części wartości dokumentu jeszcze przed rozpoczęciem indeksowania.

Ślepa wiara w embeddingi

Baza wektorowa nie jest magiczną wyszukiwarką wiedzy.

Embeddingi dobrze odnajdują podobieństwa semantyczne, ale nie zawsze rozumieją różnice istotne biznesowo. W prawie, finansach, medycynie czy dokumentacji technicznej nawet niewielka pomyłka może prowadzić do błędnych odpowiedzi.

Przerzucanie odpowiedzialności na model

LLM nie sprawdza prawdziwości informacji.

Jeżeli do kontekstu trafią błędne dane, model będzie je traktował jako poprawne. Dlatego odpowiedzialność za jakość odpowiedzi zaczyna się na etapie przygotowania danych i wyszukiwania, a nie generowania.

Architektoniczne potwory

Często spotykanym zjawiskiem jest dokładanie kolejnych warstw:

  • model wyszukujący,
  • model oceniający,
  • model poprawiający,
  • model podsumowujący,
  • model walidujący.

Po kilku iteracjach nikt już nie rozumie, dlaczego system zwrócił konkretną odpowiedź.

Jeżeli rozwiązanie wymaga pięciu modeli, aby naprawić problemy pierwszego, prawdopodobnie problem znajduje się wcześniej w procesie.

Framework-driven development

Frameworki takie jak LangChain, LlamaIndex czy CrewAI świetnie nadają się do eksperymentów i prototypowania.

Problem zaczyna się wtedy, gdy architektura produkcyjna zostaje zbudowana wokół frameworka zamiast wokół problemu biznesowego.

Po kilku miesiącach pojawiają się trudności z debugowaniem, wydajnością i aktualizacjami.

Reindeksowanie wszystkiego

Zwiększenie rozmiaru chunków i ponowne indeksowanie całej bazy często jest próbą leczenia objawów.

Jeżeli dane są źle przygotowane lub strategia wyszukiwania jest błędna, ponowny indexing jedynie powiela istniejące problemy.

Dobre wzorce

Odpowiedzialność za kontekst

Najważniejszym zadaniem systemu RAG jest dostarczenie modelowi właściwego kontekstu.

Nie chodzi o ilość danych, ale o ich trafność, wiarygodność i kompletność.

Dobry RAG nie maksymalizuje liczby dokumentów w kontekście. Maksymalizuje ich użyteczność.

Struktura ponad wielkość

Znacznie lepsze efekty daje zachowanie naturalnej struktury dokumentów:

  • rozdziałów,
  • akapitów,
  • tabel,
  • sekcji technicznych,
  • relacji między dokumentami.

W praktyce często lepiej działa mniejsza liczba dobrze przygotowanych fragmentów niż ogromna liczba losowych chunków.

Wyszukiwanie hybrydowe

Najlepsze rezultaty zwykle daje połączenie:

  • wyszukiwania semantycznego,
  • wyszukiwania pełnotekstowego
  • wyszukiwania grafowego
  • filtrów metadanych

Embeddingi odpowiadają za podobieństwo znaczeniowe, a klasyczne wyszukiwanie za precyzję.

Prostota architektury

To prawdopodobnie najważniejsza zasada.

Każdy dodatkowy komponent powinien odpowiadać na pytanie – „Jaki konkretny problem rozwiązuje?”

Jeżeli nie potrafimy tego jasno uzasadnić, komponent prawdopodobnie jest zbędny.

System, który składa się z kilku prostych, zrozumiałych elementów, zwykle osiąga lepsze wyniki niż skomplikowana architektura pełna agentów i warstw pośrednich.

Dane są ważniejsze od modeli

W większości projektów największy zwrot z inwestycji nie wynika z wymiany modelu na nowszy.

Największą poprawę daje:

  • lepsza jakość danych,
  • lepsze metadane,
  • poprawna struktura dokumentów,
  • lepsza strategia wyszukiwania.

To właśnie dane są produktem. Model jest jedynie narzędziem do ich wykorzystania.

Wniosek

Największym błędem przy budowie systemów RAG jest przekonanie, że bardziej zaawansowana architektura automatycznie oznacza lepszy rezultat.

Doświadczenie pokazuje coś odwrotnego.

Najskuteczniejsze systemy RAG są zwykle zaskakująco proste. Opierają się na wysokiej jakości danych, przejrzystym procesie wyszukiwania i minimalnej liczbie elementów pośrednich.

Pierwsza zasada RAG, którą warto zapamiętać, brzmi:

Jeżeli rozwiązanie jest zbyt skomplikowane, prawdopodobnie nie przetrwa wystarczająco długo, aby osiągnąć swój cel. Prostota nie jest ograniczeniem. Prostota jest przewagą konkurencyjną.