Chunking dokumentów w RAG

Chunking dokumentów to etap przygotowania bazy wiedzy dla RAG, w którym długi materiał dzielisz na mniejsze fragmenty. Każdy fragment dostaje własny embedding, metadane i identyfikator, a potem może zostać znaleziony jako osobny wynik. Nie chodzi więc o mechaniczne pocięcie PDF-a co kilka stron, lecz o przygotowanie jednostek, które zachowują sens i dają się bezpiecznie przekazać modelowi jako kontekst.

To ważne, bo jeden embedding całego obszernego dokumentu słabo reprezentuje wiele różnych tematów naraz. Gdy ekspert pyta o warunki wdrożenia, system powinien znaleźć sekcję o wdrożeniu, a nie ogólny dokument zawierający też bio, cennik i politykę prywatności. Mniejsze fragmenty pomagają wyszukiwaniu semantycznemu dopasować intencję pytania do właściwego miejsca w źródle.

Najprostsza strategia tnie tekst według stałej liczby znaków lub tokenów i dodaje niewielkie nakładanie się fragmentów. Overlap zmniejsza ryzyko, że zdanie zaczęte na końcu jednego fragmentu straci dalszy ciąg. Dokumentacja Azure AI Search zaleca zacząć od 512 tokenów oraz 25% nakładania się, ale to punkt startu do testów, nie uniwersalna recepta. Za duże fragmenty zmniejszają precyzję, za małe odbierają kontekst.

Lepsze dla treści eksperckich bywa dzielenie po strukturze: nagłówkach Markdown, pytaniach FAQ, etapach procesu, akapitach lub granicach zdań. Do fragmentu warto dołączyć tytuł dokumentu i nagłówek sekcji. Zdanie „trwa 60 minut” bez nazwy usługi jest bezużyteczne. To samo zdanie z kontekstem „Audyt AI 1:1: trwa 60 minut” staje się jednoznaczną informacją dla modelu i odbiorcy.

Praktyczny przykład: masz źródło prawdy o ofercie, zapis rozmów sprzedażowych i FAQ. Zamiast wrzucać trzy pliki do jednego promptu, dzielisz je na sekcje z metadanymi typu źródło, usługa, data aktualizacji i język. Pytanie „dla kogo jest konsultacja?” uruchamia wyszukiwanie, które zwraca dwa lub trzy fragmenty z aktualnej oferty. Dopiero wtedy model pisze odpowiedź oraz może wskazać, skąd ją wziął.

Chunking nie naprawi nieaktualnych, sprzecznych ani słabo opisanych danych. Może też zwiększyć koszt indeksowania i liczbę podobnych wyników, szczególnie gdy overlap jest za duży. Dlatego oceniaj system na realnych pytaniach klientów: czy zwrócony fragment zawiera pełną odpowiedź, czy ma właściwy kontekst i czy model nie miesza wersji oferty. Wrażliwe decyzje nadal wymagają kontroli człowieka.