Artykuł ma 5000 słów. Nie możesz wrzucić całego do jednego embeddingu — byłby zbyt ogólny i gubił szczegóły. Nie możesz embeddować każdego zdania osobno — straciłbyś kontekst i połączenia między myślami. Musisz podzielić artykuł na kawałki które są wystarczająco małe żeby mieć konkretne znaczenie, ale wystarczająco duże żeby zachować kontekst.
To jest chunking — i jest zaskakująco trudnym problemem.
Czym jest chunking
Chunking to proces dzielenia długich dokumentów na mniejsze fragmenty przed ich embeddingiem i indeksowaniem w vector database — kluczowy krok w budowaniu pipeline RAG, który bezpośrednio wpływa na jakość wyszukiwania semantycznego: zbyt małe chunki tracą kontekst, zbyt duże gubią szczegóły i zaburzają precision embeddingów.
Strategie chunkingu
Fixed-size chunking: dzielenie na fragmenty o stałej liczbie tokenów (np. 512 tokenów) z overlapem (np. 50 tokenów nakładki żeby nie przeciąć zdania w środku). Prosta implementacja, działa dobrze dla jednorodnych tekstów. Słaba dla treści z wyraźną strukturą (nagłówki, sekcje).
Semantic chunking: dzielenie według granic semantycznych — akapitów, sekcji oznaczonych nagłówkami H2/H3, list punktowanych. Każdy chunk jest naturalną jednostką treści. Lepsze dla dobrze sformatowanych dokumentów. Wymaga że dokument ma czytelną strukturę — co jest kolejnym argumentem za semantycznym HTML.
Sentence-level chunking: każde zdanie jako osobny chunk. Dobre dla FAQ i krótkich faktów. Słabe dla narracyjnych tekstów gdzie kontekst wymaga kilku zdań.
Hierarchical chunking: multi-level — duże chunki (akapit) zawierają małe chunki (zdanie). Przy retrieval agent dostaje mały chunk ale może poprosić o szerszy kontekst (parent chunk). Najlepsza jakość, najbardziej złożona implementacja.
Overlap jako kompromis
Overlap — nakładka między sąsiednimi chunkami — rozwiązuje problem przecięcia ważnych informacji na granicy chunku. Jeśli zdanie kluczowe dla odpowiedzi jest podzielone między dwa chunki, overlap zapewnia że każdy z nich ma wystarczający kontekst.
Typowy overlap: 10-20% wielkości chunku. Za duży overlap = redundancja i wyższe koszty. Za mały = przerwane informacje.
Chunking a jakość RAG
Zły chunking jest jedną z najczęstszych przyczyn słabej jakości RAG. Model embeddingowy może być świetny, vector database może być szybka — ale jeśli chunki są źle podzielone, retrieval zwraca niewłaściwe fragmenty i model odpowiada na podstawie złego kontekstu.
Dla właściciela strony który buduje RAG nad własną treścią: zacznij od semantic chunking opartego na strukturze HTML (H2/H3 jako granice chunku) — to naturalnie wyrównuje chunki z logiką treści strony.