Budowanie produkcyjnego RAG: Architektura, dzielenie na fragmenty i subtelna nauka kontekstu

Zbudowałem trzy systemy RAG, które trafiły do produkcji, i utrzymywałem dwa inne, zbudowane przez kogoś innego. Oto czego się nauczyłem: demonstracja jest najprostszą częścią. Stworzenie prototypu, który odpowiada na pytania z dokumentów, zajmuje weekend. Sprawienie, by odpowiadał poprawnie, spójnie, w skali, bez rujnowania budżetu chmurowego - to zajmuje miesiące pracy, o której nikt cię nie ostrzegał.

Większość tutoriali RAG kończy się na etapie demonstracji. Pokazują happy path: wgraj PDF, osadź go, wyślij zapytanie, dostań odpowiedź. Nie pokazują, co się dzieje, gdy masz 50 000 dokumentów w siedmiu formatach, połowa z nich aktualizowana kwartalnie, a system zaczyna pewnie cytować zeszłoroczne ceny w odpowiedzi na pytania klientów. Wtedy zaczyna się prawdziwa inżynieria.

Chcę przejść przez to, jak wygląda rzeczywisty system RAG w produkcji, ze szczególnym uwzględnieniem części, która powoduje najwięcej awarii: pipeline przetwarzania dokumentów. Jeśli budujesz lub utrzymujesz system RAG, to są rzeczy, które uratują cię przed stronami błędów o 3 nad ranem.

Architektura, której nikt nie rysuje na tablicach

Tablicowa wersja RAG to trzy pudełka i dwie strzałki: dokumenty wchodzą, wektory są przechowywane, zapytania dostają odpowiedzi. Wersja produkcyjna ma około piętnastu dodatkowych pudełek, z których większość dotyczy rzeczy, które poszły nie tak.

Produkcyjne RAG obejmuje te etapy, a każdy z nich to potencjalny punkt awarii:

Pobieranie i normalizacja - przekształcanie surowego tekstu z PDF-ów, HTML, API, wewnętrznych wiki i baz danych w spójną strukturę. Ten etap sam w sobie może zająć 40% całkowitego czasu rozwoju. Nie przesadzam.
Dzielenie na fragmenty i osadzanie - dzielenie tekstu na semantycznie znaczące jednostki i konwersja ich na reprezentacje wektorowe. To tutaj większość zespołów popełnia największe błędy.
Przechowywanie i pobieranie wektorów - efektywne przechowywanie i wyszukiwanie osadzeń, zwykle przy użyciu metod przybliżonego najbliższego sąsiada. Wybór typu indeksu określa kompromisy między opóźnieniem a dokładnością.
Przepraszanie i tworzenie podpowiedzi - dopracowywanie wyników wyszukiwania i pakowanie ich dla LLM w ramach limitów tokenów. To różnica między trafnymi odpowiedziami a halucynowanymi.
Monitorowanie, buforowanie i aktualizacje - kontrola opóźnień, kosztów i świeżości danych. Bez tego system pogarsza się po cichu, aż ktoś zauważy, że odpowiedzi są błędne.

Każdy etap przecieka założeniami do następnego. Dzielenie na fragmenty wpływa na jakość pobierania. Jakość pobierania wpływa na konstrukcję podpowiedzi. Konstrukcja podpowiedzi wpływa na koszt i dokładność modelu. Nie można optymalizować żadnego etapu w izolacji. System jest tak dobry, jak jego najsłabsza granica.

Demo jest proste. Prawdziwe wyzwanie inżynierskie zaczyna się, gdy system RAG musi odpowiadać poprawnie, spójnie i na dużą skalę.

Pipeline przetwarzania dokumentów: tam, gdzie zaczynają się awarie produkcyjne

Spędziłem trzy tygodnie na debugowaniu systemu RAG, który dawał niespójne odpowiedzi na to samo pytanie. Model był w porządku. Baza wektorowa była w porządku. Problem leżał w pipeline przetwarzania dokumentów: zindeksowano dwie wersje tego samego dokumentu polityki, jedną z eksportu PDF i drugą z strony Confluence. Miały różne formatowanie, różne metadane i nieco różniące się sformułowania. System pobierał fragmenty z obu, a LLM próbował pogodzić sprzeczności, które nie powinny istnieć.

To typowe. Pipeline przetwarzania dokumentów to miejsce, w którym Twoja "wiedza" staje się czytelna dla maszyny, i to tam zaczyna się większość awarii produkcyjnych.

Metadane: kontekst, którego będziesz żałować, że nie masz

Podczas indeksowania przechwytuj znaczniki czasu, autorów, tytuły sekcji, wersje dokumentów i identyfikatory źródeł. Nie później. Podczas indeksowania. Nie mogę tego wystarczająco podkreślić.

Metadane pozwalają filtrować, debugować i rangować wyniki. Bez nich masz kolizje semantyczne - ten sam fakt pojawia się dwukrotnie, z dwóch różnych okresów czasu, bez możliwości ustalenia, która wersja jest aktualna. Widziałem, jak to powodowało, że system klienta cytował funkcję produktu, która została wycofana sześć miesięcy wcześniej. Poprawka nie polegała na lepszym promptowaniu. Chodziło o lepsze metadane.

Normalizacja formatów: każdy format to dialekt chaosu

PDF-y mają ukryte znaki przejścia do nowej linii, które dzielą zdania w środku słowa. HTML ukrywa tekst za regułami CSS display. Eksport z Worda wygląda jak nota okupacyjna. Markdown z różnych narzędzi ma różne konwencje dla tabel i bloków kodu.

Normalizuj wcześnie. Wyciągnij tekst, spłaszcz strukturę, ale zachowaj hierarchię. Będziesz potrzebować tych granic nagłówków później do hierarchicznego dzielenia na fragmenty. Nauczyłem się tego na własnej skórze, gdy próbowałem dodać hierarchiczne dzielenie na fragmenty do systemu, który już spłaszczył całą strukturę. Musieliśmy ponownie zindeksować wszystko.

Wykrywanie języka dla wielojęzycznych korpusów

Jeśli Twoja organizacja działa w wielu językach, mieszanie osadzeń z różnych języków dezorientuje przestrzeń podobieństwa. Pracuję w środowisku dwujęzycznym - angielskim i polskim - i szybko nauczyłem się, że trzeba wykrywać język, dzielić według sekcji i odpowiednio oznaczać. Akapit po polsku osadzony obok akapitu po angielsku da nieprzewidywalne wyniki wyszukiwania.

Deduplikacja: duplikaty zatruwają wszystko

Duplikaty zawyżają koszty i pogarszają dokładność wyszukiwania. Zachowuj tylko wersje kanoniczne. Wykonuj deduplikację opartą na hash podczas indeksowania, a okresowo deduplikację semantyczną. Jeden system, który utrzymywałem, miał 30% zduplikowanej treści, ponieważ te same dokumenty były przesyłane przez trzy różne kanały. Posprzątanie tego poprawiło precyzję wyszukiwania o 15% bez żadnych zmian w modelu czy promptach.

Segmentacja: Najbardziej Niedoceniana Warstwa

Segmentacja decyduje o tym, jak „oddychają” Twoje dokumenty. Określa, co model może zobaczyć na pierwszy rzut oka. Zbyt grube segmenty powodują, że wyszukiwanie zwraca bloki niepowiązanego kontekstu. Zbyt drobne prowadzą do utraty spójności. Każda decyzja dotycząca segmentacji to kompromis, a poprawna odpowiedź zależy od Twojego konkretnego korpusu.

Segmentacja Semantyczna

Dziel tam, gdzie zmienia się znaczenie, a nie tam, gdzie wskazuje na to licznik tokenów. Obliczaj osadzenia dla małych okienek, mierz podobieństwo cosinusowe między sąsiednimi sekcjami i tnij, gdy podobieństwo spada poniżej progu. Jest to bardziej zasobożerne obliczeniowo, ale daje kontekstowo czyste segmenty. Używam tego dla dokumentacji technicznej i umów prawnych, gdzie precyzja jest ważniejsza od szybkości.

Okno Przesuwne z Nakładaniem

Praktyczny koń roboczy dla większości przypadków użycia. Pokrój tekst na segmenty o stałej długości z 20-30% nakładaniem. Nakładanie zapewnia ciągłość między granicami segmentów - kluczowe, gdy idee rozciągają się na wiele akapitów. Płacisz niewielką cenę za przechowywanie i osadzanie, ale unikasz utraty kontekstu na łączeniach. Dla większości wewnętrznych baz wiedzy zaczynam właśnie tutaj.

Segmentacja Hierarchiczna

Dokumenty mają strukturę, a ta struktura niesie znaczenie. Segmentacja hierarchiczna uchwytuje to, tworząc relacje rodzic-dziecko: podsumowania sekcji na górze, szczegółowe akapity poniżej. Wyszukiwanie może zaczynać się szeroko i powiększać, naśladując sposób, w jaki ludzie faktycznie przeszukują długie dokumenty. To podejście dobrze sprawdza się dla strukturalnej dokumentacji, takiej jak referencje API i podręczniki zgodności.

Segmentacja Świadoma Tokenów

Wszystkie strategie segmentacji muszą respektować okno kontekstowe LLM. Dla modelu o 8K oknie kontekstowym przydzielam około 1K na segment, zostawiając miejsce na instrukcje, zapytanie i wiele pobranych kontekstów. Przekroczenie okna prowadzi do cichego ucięcia - Twój system upuszcza informacje bez powiadomienia, a odpowiedzi pogarszają się subtelnie.

W praktyce używam kombinacji tych strategii. Podręczniki techniczne dostają segmentację semantyczną. FAQ-i dostają okno przesuwne. Strukturalne dokumenty polityk dostają hierarchiczną. Najgorszym podejściem jest wybranie jednej strategii i stosowanie jej jednolicie do wszystkiego.

Optymalizacja pod kątem rzeczywistości

Elegancka architektura na nic się nie zda, jeśli Twój system nie będzie w stanie spełnić SLA (Service Level Agreements). Systemy produkcyjne RAG (Retrieval-Augmented Generation) wymagają znalezienia równowagi między trzema siłami, które ciągną w przeciwnych kierunkach: relewantnością, opóźnieniem i kosztem.

Rozmiar fragmentu a jakość pobierania -- Większe fragmenty rozmywają tematyczne skupienie. Mniejsze dzielą znaczenie na części. Idealny punkt zależy od Twojego korpusu: około 500-800 tokenów dla FAQ i treści konwersacyjnych, 1-1,5K dla gęstych dokumentów technicznych. Testuję różne rozmiary na reprezentatywnym zestawie zapytań, zanim się na coś zdecyduję.

Szybkość pobierania -- Używaj indeksów przybliżonego najbliższego sąsiada, takich jak HNSW (Hierarchical Navigable Small World) lub IVFPQ (Inverted Frequency-based Vector Quantization). Opóźnienie pobierania powyżej 200 ms sprawia wrażenie ospałości w interfejsie czatu. Równolegle generuj embeddingi i cache'uj częste zapytania. W jednej organizacji cache'owanie 200 najczęstszych zapytań zmniejszyło średnie opóźnienie o 60%.

Kontrola kosztów -- Przekształcaj na embeddingi ponownie tylko wtedy, gdy treść się zmienia. Cache'uj zarówno embeddingi, jak i wyniki generowania. Używaj mniejszych modeli do rerankingu, gdzie to możliwe. W jednym projekcie przejście z dużego modelu na lekki cross-encoder zmniejszyło nasze miesięczne koszty o 35% przy minimalnym wpływie na dokładność.

Obserwowalność -- Śledź precyzję i odwołanie pobierania, a nie tylko czas działania. Loguj, które fragmenty przyczyniają się do poprawnych odpowiedzi. W systemach RAG "to działa" nie znaczy to samo co "pobiera dobrze". Ustawiam cotygodniowy przegląd próbek, podczas którego ręcznie sprawdzamy 50 losowych par zapytań i odpowiedzi. To żmudne. Ale wyłapuje problemy, które umykają automatycznym metrykom.

Pragmatyczny Stack

Dla samodzielnych developerów lub małych zespołów, setup produkcyjny może pozostać lekki. Oto co rekomenduję na podstawie tego, co faktycznie wdrożyłem:

TypeScript lub Python dla runtime’u, w zależności od mocnych stron zespołu. PostgreSQL z pgvector do lokalnych eksperymentów i małoskalowej produkcji. Qdrant lub Pinecone, gdy potrzebujesz skalować ponad to, co pgvector obsługuje komfortowo. OpenAI text-embedding-3-large lub Cohere embed-v3-multilingual dla embeddingów, w zależności od tego, czy potrzebujesz wsparcia wielojęzycznego. GitHub Actions do automatyzacji pipeline’ów zasysania danych.

Ten stack utrzymuje koszty przewidywalnymi, deployments proste, a latencję na tyle niską, że nadaje się do aplikacji czasu rzeczywistego. Nie potrzebujesz klastra Kubernetes, żeby uruchomić system RAG. Potrzebujesz czystych danych i dobrego chunkingu.

Czego ktoś nie powiedział mi wcześniej

Produkcyjny RAG to nie jest problem inżynierii promptów. To problem projektowania systemów, który wygląda jak problem inżynierii promptów, dopóki nie próbujesz go skalować. Różnica między demem a niezawodnym systemem tkwi w skryptach przetwarzania wstępnego, logice dzielenia na fragmenty i cichej dyscyplinie higieny metadanych.

Każdy fragment to akapit w zbiorowej pamięci twojej organizacji. Jeśli pokroisz, oznaczysz i przechowasz je dobrze, twój LLM może odpowiadać uczciwie, bez udawania, że wie więcej, niż wie. Jeśli zrobisz to źle, otrzymasz system, który brzmi pewnie i jest błędny - najbardziej niebezpieczny rodzaj awarii AI.

Dobre systemy RAG nie halucynują mniej dlatego, że modele są mądrzejsze. Halucynują mniej, ponieważ dane zachowują się dobrze.

Dobre RAG-i nie halucynują mniej dlatego, że modele są mądrzejsze. Halucynują mniej dlatego, że dane zachowują się poprawnie. Zacznij od tego.