W RAG nie chodzi o AI, lecz o inżynierię

(praca w toku)

RAG to wyzwanie inżynieryjne

Przeglądając grupę AI & Machine Learning Community, trafiłem na wpis [1] i prezentację pani Hastiki Cheddy, który uderzył w samo sedno. Jej teza dotycząca wdrożeń AI była brutalnie szczera:

„Przeprowadziłam audyt ponad 10 korporacyjnych wdrożeń RAG. Każde jedno z nich posypało się na produkcji. Nie przez LLM. Nie przez model embeddingowy. Przez wadliwą architekturę”.

Te słowa natychmiast ze mną zarezonowały. Skoro fundamenty zawodzą częściej niż same modele, jako inżynier, programista i architekt poczułem, że czas podzielić się doświadczeniem i spostrzeżeniami, by dorzucić swoje trzy grosze do dyskusji o budowaniu skutecznych systemów RAG.

RAG: 5 minut w tutorialu, 5 miesięcy w produkcji

Analizując powszechnie dostępne przykłady systemów RAG, trudno oprzeć się wrażeniu, że utknęliśmy w fazie naiwnych i zbyt pośpiesznych implementacji. Technologia ta, choć obiecuje złote góry, w rzeczywistości jest niezwykle wymagająca i kapryśna. Pokusa szybkiego odpalenia prostej sekwencji – „potnij tekst na kawałki, wrzuć do bazy wektorowej, wyszukaj” – jest tak silna, że kluczowe fundamenty inżynieryjne często schodzą na dalszy plan.

Aspekty takie jak rzetelna jakość danych, audytowalność procesu czy odporność na ataki dostają niebezpiecznie niski priorytet. Co gorsza, fundamentalne decyzje projektowe podejmuje się w biegu. Przykładem jest masowe stosowanie sztywnego dzielenia tekstu (fixed-size chunking), które w starciu z realnymi, biznesowymi dokumentami niemal zawsze przegrywa z bardziej wyrafinowanymi, semantycznymi technikami segmentacji.

Oczywiście istnieją bardziej zaawansowane systemy RAG, które mają solidne podstawy architektoniczne i sprawnie działają w środowiskach produkcyjnych. Nie są one jednak powszechnie omawiane w tutorialach – być może dlatego, że dla osób spragnionych szybkich efektów nie wydają się tak pociągające. Kojarzą się bowiem z długim i drobiazgowym budowaniem skomplikowanego, wielowarstwowego systemu.

W moim odczuciu to właśnie ta złożoność stanowi sedno zagadnienia i jest w nim najciekawsza. Dlatego zachęcam Cię, czytelniku, do spojrzenia na RAG jak na wyzwanie inżynierskie. Tutaj nie szukamy „niskowiszących owoców”, lecz podchodzimy do tematu z seniorską powagą – tak, jak podchodzi się do projektowania każdego krytycznego i złożonego systemu.

Od trzech kafelków na diagramie do potwora o stu głowach

Większość schematów, na które trafiamy w sieci, przedstawia RAG jako elegancki i niemal bezobsługowy mechanizm. Obrazek jest kuszący: dokument wpada do maszyny, zamienia się w wektory, przechodzi przez „trzy bloki na krzyż” i generuje idealną odpowiedź. Niestety, ta wizja „szczęśliwej ścieżki” (happy path) rzadko wytrzymuje pierwsze zderzenie z rzeczywistością.

Miejsc, w których te schematyczne uproszczenia maskują faktyczną złożoność procesu, jest pod dostatkiem:
(TBD: tutaj będzie lista przykładów)

W prawdziwym świecie Twoje dane to nie sterylnie czyste pliki tekstowe, lecz „brudne” PDF-y z wielopiętrowymi tabelami, stopkami i nieoczywistą strukturą. Do tego dochodzą użytkownicy, którzy rzadko zadają pytania w sposób przewidywalny i uporządkowany. Aby system przestał halucynować i zaczął realnie rozwiązywać problemy, musimy porzucić iluzję prostoty na rzecz solidnej inżynierii, która zabezpieczy proces na każdym jego etapie.

Dlaczego system produkcyjny potrzebuje 15+ modułów, a nie tylko trzech?

Prawdziwa anatomia profesjonalnego systemu RAG nie sprowadza się jedynie do trzech prostych kroków, które sugeruje sam akronim: pobierania (Retrieve), rozszerzania (Augment) i generowania (Generate). To tylko wierzchołek góry lodowej. Jeśli budujesz rozwiązanie, które ma być odporne na nieuporządkowane dane, zdezorientowanych użytkowników, a nawet złośliwe próby manipulacji, musisz spojrzeć znacznie głębiej.

Poniżej znajdziesz listę 20 komponentów, które należy rozważyć – a w warunkach biznesowych najczęściej po prostu zaimplementować – aby RAG przestał być tylko techniczną ciekawostką, a stał się niezawodnym narzędziem klasy enterprise.

Dopiero architektura uwzględniająca te aspekty pozwala stworzyć system gotowy na sytuacje kryzysowe, audyty czy ewentualne spory prawne. Warto zapamiętać jedną zasadę: w RAG-u największy wysiłek inżynieryjny wcale nie wiąże się z wyborem samego modelu językowego, lecz z budową „rur”, którymi płyną dane. To właśnie w tej niewidocznej na pierwszy rzut oka infrastrukturze rozstrzyga się, czy Twój system będzie realnym wsparciem, czy spektakularną porażką wdrożeniową.

RAG to nie gotowy produkt pudełkowy, lecz ciągły proces. Sukces nie zależy od wykupienia subskrypcji na najdroższe LLM, ale od żmudnej pracy nad jakością i przepływem informacji. Dysonans poznawczy zniknie tylko wtedy, gdy przestaniemy traktować AI jak magię, a zaczniemy widzieć w niej kolejny, złożony element nowoczesnej architektury oprogramowania.

...work in progress...