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

Każde pokolenie inżynierów odkrywa na nowo prostą prawdę: potoki danych starzeją się jak owoce. Na początku wyglądają dobrze, potem cicho się psują, aż w końcu zaczyna coś śmierdzieć. Systemy Retrieval-Augmented Generation (RAG) nie są wyjątkiem. Prototyp może wyglądać elegancko na tablicy - zapytanie użytkownika, wyszukiwanie wektorowe, przyjazny LLM - ale rzeczywistość produkcyjna jest bardziej skomplikowana. Dokumenty są niespójne. Metadane znikają. Okna kontekstowe się przepełniają. Łączność rośnie jak odsetki od długu.

Jeśli chcesz, aby system RAG przetrwał w dziczy, musisz myśleć jak architekt, a nie inżynier promptów. Przeanalizujmy, jak wygląda ta architektura i jak zoptymalizować jej najbardziej niedocenianą warstwę: potok przetwarzania dokumentów.

Architektura w działaniu

Wyobraź sobie system RAG jako rozmowę między dwoma ekspertami. Jeden to bibliotekarz, biegły w zakresie osadzeń i odległości wektorowych; drugi to narrator, czyli LLM, który przekształca pobrane fakty w znaczącą treść.

Aby ten duet działał, ktoś musi zarządzać choreografią - pętlą pobierania, indeksowania i wyszukiwania, która gwarantuje, że narrator zawsze otrzymuje informacje z odpowiednich źródeł.

Gotowy do produkcji system RAG zwykle obejmuje następujące etapy:

1. Pobieranie i normalizacja - przekształcanie surowego tekstu z plików PDF, HTML, API lub baz danych w spójną strukturę.
2. Dzielenie na fragmenty i osadzanie - dzielenie tekstu na semantycznie znaczące jednostki i konwersja ich na reprezentacje wektorowe.
3. Baza wektorów i wyszukiwanie - efektywne przechowywanie i wyszukiwanie osadzeń, zazwyczaj przy użyciu metod przybliżonego najbliższego sąsiada.
4. Ponowne rangowanie i tworzenie promptów - udoskonalanie wyników wyszukiwania i pakowanie ich dla LLM w ramach limitów tokenów.
5. Monitorowanie, buforowanie i aktualizacje - kontrola opóźnień, kosztów i świeżości danych.

Architektura RAG to bardziej ekosystem niż potok. Każdy etap przenosi założenia do następnego: dzielenie na fragmenty wpływa na wyszukiwanie, wyszukiwanie wpływa na tworzenie promptów, a promptowanie wpływa na koszt modelu. Optymalizacja odbywa się na granicach.

Pipeline przetwarzania dokumentów

Pipeline przetwarzania dokumentów to miejsce, w którym Twoja "wiedza" staje się czytelna dla maszyny. To również tutaj zaczyna się większość problemów produkcyjnych.

Wymagania dotyczące przetwarzania wstępnego

Ekstrakcja metadanych

Metadane to kontekst. Przechwytuj znaczniki czasu, autorów, tytuły sekcji i identyfikatory źródeł. Pozwalają one później filtrować, debugować i rangować wyniki. Systemy pomijające metadane nieuchronnie kończą się kolizjami semantycznymi — ten sam fakt dwa razy, z dwóch różnych czasów, bez możliwości określenia, który wygrywa.

Normalizacja formatu

Każdy format dokumentu to dialekt chaosu. Pliki PDF zawierają pozorne przerwy wiersza, HTML ukrywa tekst za CSS, a eksport z Worda produkuje tekst jak notę okupacyjną. Normalizuj wcześnie: wyodrębnij tekst, spłaszcz strukturę, ale zachowaj hierarchię. Będziesz potrzebować tych granic nagłówków później do hierarchicznego dzielenia na fragmenty.

Wykrywanie języka i podział

Wielojęzyczne korpusy wymagają świadomości językowej. Mieszanie osadzeń z różnych języków dezorientuje przestrzeń podobieństwa — to tak, jakby sortować według dźwięku zamiast znaczenia. Wykryj język, podziel według sekcji i oznacz odpowiednio.

Deduplikacja i zachowanie struktury

Duplikaty zatruwają dokładność wyszukiwania i zawyżają koszty. Zachowaj tylko wersje kanoniczne. Zachowaj strukturę, gdy to możliwe — numery stron, sekcje, tabele. Nie są one szumem; są semantycznymi wskazówkami.

Dzielenie na fragmenty: Cięcie tekstu w naturalnych miejscach zgięcia

Dzielenie na fragmenty określa, jak „oddychają” Twoje dokumenty. To sposób decydowania o tym, co model może zapamiętać jednym spojrzeniem. Zbyt grube fragmenty powodują, że wyszukiwanie zwraca bloki niepowiązanych kontekstów. Zbyt drobne fragmenty prowadzą do utraty spójności.

Nowoczesne systemy RAG traktują dzielenie na fragmenty jako połączenie sztuki i inżynierii. Oto dominujące strategie i ich zastosowania:

Dzielenie semantyczne

Dziel tam, gdzie zmienia się znaczenie, a nie tam, gdzie wskazuje na to licznik tokenów. Obliczaj osadzenia dla małych okien, mierz podobieństwo cosinusowe między sąsiednimi sekcjami i tnij, gdy spadnie poniżej progu. Jest to bardziej wymagające obliczeniowo, ale daje kontekstowo czyste fragmenty — idealne dla podręczników technicznych i prac naukowych.

Okno przesuwne (z nakładaniem)

Praktyczny koń roboczy. Tnij tekst na segmenty o stałej długości z 20–30% nakładaniem. Nakładanie zapewnia ciągłość między granicami fragmentów — kluczowe, gdy pomysły rozciągają się na wiele akapitów. Płacisz niewielką karę za przechowywanie i osadzanie, ale unikasz utraty kontekstu na łączeniach.

Dzielenie hierarchiczne

Dokumenty mają strukturę, a ta struktura niesie znaczenie. Dzielenie hierarchiczne uchwyca to, tworząc relacje rodzic-dziecko: podsumowania sekcji na górze, szczegółowe akapity poniżej. Wyszukiwanie może wtedy zaczynać szeroko i powiększać widok, naśladując sposób, w jaki ludzie przeszukują długie dokumenty.

Dzielenie świadome tokenów

To wszystko działa tylko wtedy, gdy fragmenty mieszczą się w pamięci LLM. Dla modelu z kontekstem 8K możesz przydzielić 1K na fragment, pozostawiając miejsce na instrukcje, zapytanie i wiele pobranych kontekstów. Przekroczenie limitu prowadzi do cichego ucinania — najdroższego sposobu utraty dokładności.

Optymalizacja pod kątem rzeczywistości

Elegancka architektura potoku nie ma znaczenia, jeśli nie spełnia umów SLA. Produkcyjne systemy RAG wymagają balansu: trafności, opóźnienia i kosztów, które ciągną w przeciwnych kierunkach.

Rozmiar fragmentu vs 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, 1–1,5K dla gęstych dokumentów technicznych.

Szybkość pobierania — Używaj indeksów przybliżonego najbliższego sąsiada (HNSW, IVFPQ). Opóźnienie pobierania powyżej 200 ms jest odczuwalne jako wolne w aplikacji czatu na żywo. Równolegle generuj osadzenia i cache’uj częste zapytania.

Kontrola kosztów — Ponownie osadzaj tylko przy zmianach treści. Cache’uj zarówno osadzenia, jak i wyniki generowania. Używaj mniejszych modeli do rerankingu tam, gdzie to możliwe.

Obserwowalność — Śledź precyzję i odwołanie pobierania, nie tylko czas pracy. Loguj, które fragmenty przyczyniają się do poprawnych odpowiedzi. W systemach RAG „działa” nie znaczy to samo co „pobiera dobrze”.

Pragmatyczna architektura stosu (The Pragmatic Stack)

Dla indywidualnych programistów lub małych zespołów konfiguracja produkcyjna może pozostać lekka: TypeScript + Node.js dla środowiska wykonawczego, PostgreSQL + pgvector do lokalnych eksperymentów, Qdrant lub Pinecone w celu skalowania, OpenAI text-embedding-3-large lub Cohere embed-v3-multilingual dla osadzeń oraz Vercel + GitHub Actions do automatycznego przetwarzania danych.

Ta architektura utrzymuje koszty na przewidywalnym poziomie, wdrożenia są proste, a opóźnienia na tyle niskie, że nadają się do aplikacji czasu rzeczywistego.

Podsumowanie: Precyzja ponad poezją

Produkcyjny RAG nie jest problemem inżynierii zapytań, lecz ukrytym wyzwaniem projektowania systemów. Różnica między demonstracją a niezawodnym systemem tkwi w skryptach przetwarzania wstępnego, logice dzielenia na fragmenty oraz cichej dyscyplinie higieny metadanych.

Traktuj każdy fragment jak akapit zbiorowej pamięci Twojej firmy. Jeśli odpowiednio go potniesz, oznaczysz i przechowasz, Twój LLM będzie mógł udzielać prawdziwych odpowiedzi bez udawania, że wie więcej, niż jest w stanie.

Dobre RAG-i nie halucynują mniej dlatego, że modele są mądrzejsze — halucynują mniej, ponieważ dane zachowują się poprawnie.