Architektura RAG od podstaw: komponenty, przepływ danych i decyzje projektowe

RAG można pokazać na prostym diagramie: użytkownik zadaje pytanie, system znajduje właściwy fragment wiedzy, a model generuje odpowiedź. Taki schemat dobrze tłumaczy ideę. Nie wystarcza jednak do zaprojektowania rozwiązania, które ma pracować na firmowych danych i działać przewidywalnie na produkcji.

Architektura RAG obejmuje cały przepływ informacji: od źródeł wiedzy, przez przygotowanie danych i indeks, po retrieval oraz model generujący odpowiedź. Jeśli wynik jest słaby, problem nie musi leżeć w LLM. System mógł wcześniej znaleźć niewłaściwy materiał albo nie dostarczyć modelowi potrzebnego kontekstu.

Jakie warstwy tworzą system RAG?

Na wysokim poziomie można wyróżnić źródła danych, proces ich przygotowania, reprezentację wektorową, indeks wyszukiwawczy, warstwę retrieval oraz generowanie odpowiedzi.

Źródłem mogą być dokumenty, procedury, baza wiedzy lub dane z istniejących systemów. Treść trzeba przygotować do wyszukiwania i zapisać w indeksie, z którego system pobiera fragmenty powiązane z pytaniem.

RAG LLM nie jest więc jednym „modułem AI”. To kilka współpracujących elementów, które powinny dać się osobno testować i obserwować.

Dlaczego warto rozdzielić ścieżkę danych od ścieżki zapytania?

W architekturze RAG działają dwa różne cykle.

Pierwszy odpowiada za przygotowanie wiedzy: pobiera materiały ze źródeł, przetwarza je i zapisuje w indeksie. Drugi uruchamia się, gdy użytkownik zadaje pytanie: wyszukuje kontekst i przekazuje go do modelu.

Mają inne profile obciążenia i inne punkty awarii. Problem z przetworzeniem nowego dokumentu nie powinien zatrzymywać funkcji, która nadal może odpowiadać na podstawie wcześniej przygotowanej wiedzy.

Gdzie kończy się prototyp, a zaczyna produkcja?

Proof of concept może działać na kilku dokumentach i domyślnych ustawieniach. Produkcja szybko dodaje kolejne pytania.

Co dzieje się po zmianie źródła? Jak rozpoznać aktualną wersję dokumentu? Czy można wskazać podstawę odpowiedzi? Jak sprawdzić, czy problem powstał podczas retrievalu, czy dopiero przy generowaniu?

Dlatego już na etapie projektu trzeba przewidzieć identyfikację źródeł, metadane i możliwość obserwacji poszczególnych etapów. Bez tego system RAG staje się czarną skrzynką: wiadomo, że odpowiedź jest zła, ale nie wiadomo, gdzie szukać przyczyny.

Które decyzje trudno później odwrócić?

Nie wszystkie elementy architektury mają taki sam koszt zmiany. Model embeddingowy, sposób przygotowania fragmentów czy struktura metadanych wpływają na cały indeks. Ich późniejsza zmiana może oznaczać ponowne przetworzenie wiedzy.

Jak Prognetics podchodzi do architektury RAG?

W Prognetics traktujemy RAG jako część istniejącego systemu i procesu, nie osobny eksperyment z AI. Najpierw trzeba zrozumieć źródła wiedzy, sposób ich aktualizacji, typ użytkowników i to, jak odpowiedź będzie wykorzystywana.

Dopiero wtedy ma sens dobór komponentów. Celem nie jest architektura, która dobrze wygląda na diagramie. Celem jest system, który można testować, rozwijać i utrzymywać po release’ie.

Od czego zacząć rozmowę?

Wystarczą trzy informacje:

• źródła wiedzy,
• sposób zadawania pytań,
• to, co musi dać się zweryfikować po wygenerowaniu odpowiedzi.

To dobry punkt startu do rozmowy o architekturze RAG - zanim wybór technologii zacznie narzucać rozwiązanie.