Jak przygotować dane do RAG – przewodnik po chunkowaniu

• Chunking to podział dokumentów na mniejsze fragmenty, które AI może efektywnie przetworzyć i osadzić jako embeddingi
• Wielkość chunka wpływa bezpośrednio na jakość odpowiedzi RAG – zbyt małe gubią kontekst, zbyt duże obniżają precyzję
• Istnieją różne strategie podziału: po znakach, zdaniach, akapitach lub semantycznie – wybór zależy od typu danych
• Overlap między chunkami zapobiega utracie informacji na granicach fragmentów

Większość problemów z RAG nie wynika z modelu – wynika z tego, jak przygotowałeś dane. Inżynierowie AI powtarzają to od lat. I mają rację.

Możesz mieć najlepszy model językowy na rynku, perfekcyjnie dobraną bazę wektorową i przemyślaną strategię retrieval. Jeśli źle podzielisz dokumenty na fragmenty, RAG będzie halucynował albo zwracał odpowiedzi w stylu "nie znalazłem informacji" – mimo że dane są w systemie.

Chunking – czyli podział dokumentów na mniejsze kawałki – to fundament każdego systemu RAG. Dlatego warto zrozumieć, jak to działa, zanim zaczniesz budować.

Dlaczego w ogóle dzielimy dokumenty na fragmenty

Wrzucasz do systemu RAG 200-stronicowy raport roczny firmy. Model językowy ma ograniczony kontekst – nawet GPT-5 nie przetworzy całości w jednym zapytaniu. Poza tym embeddingi (wektorowe reprezentacje tekstu) działają najlepiej na spójnych, tematycznie zwartych fragmentach.

Jeśli osadzisz cały dokument jako jeden wektor, stracisz precyzję. System nie będzie wiedział, która część dokumentu odpowiada na konkretne pytanie użytkownika. Zwróci całość – albo nic.

Dlatego dzielisz dokument na chunki – mniejsze fragmenty, które:

• Mieszczą się w limicie tokenów modelu embeddingowego (zazwyczaj 512-8192 tokeny)
• Są tematycznie spójne – jeden chunk = jeden wątek/myśl
• Zawierają wystarczająco dużo kontekstu, by model zrozumiał znaczenie
• Nie są na tyle duże, by rozmywać sygnał semantyczny

Podstawowe strategie podziału danych

Nie ma jednej uniwersalnej metody. Wybór zależy od typu danych, struktury dokumentów i tego, jak użytkownicy będą zadawać pytania.

Podział po znakach (character-based chunking)

Najprostsza metoda: dzielisz tekst co X znaków (np. co 500 znaków). Szybka, przewidywalna – ale całkowicie ignoruje strukturę treści. Możesz przeciąć zdanie w połowie, rozbić tabelę lub rozdzielić nagłówek od treści.

Kiedy używać: Gdy masz surowy tekst bez struktury (np. transkrypcje audio, surowe logi) i potrzebujesz szybkiego rozwiązania.

Przykład: Transkrypcja rozmowy telefonicznej – nie ma akapitów, nagłówków, tylko ciągły strumień słów.

Podział po zdaniach lub akapitach

Dzielisz tekst respektując granice zdań lub akapitów. Chunk może zawierać np. 5-10 zdań albo 2-3 akapity. To zachowuje podstawową spójność semantyczną.

Kiedy używać: Artykuły blogowe, dokumentacja techniczna, raporty – wszystko, co ma wyraźną strukturę akapitów.

Przykład: Analiza dokumentów PDF – dzielisz raport na akapity, każdy chunk to 2-3 akapity z jednym wątkiem tematycznym.

Podział semantyczny (semantic chunking)

Zamiast dzielić mechanicznie, analizujesz treść i łączysz fragmenty tematycznie powiązane. Używasz embeddingów do wykrycia, gdzie zmienia się temat – i tam dzielisz dokument.

Kiedy używać: Gdy jakość odpowiedzi jest krytyczna i możesz poświęcić więcej czasu na preprocessing (np. bazy wiedzy dla klientów premium, systemy medyczne).

Przykład: Podręcznik obsługi urządzenia – dzielisz według sekcji funkcjonalnych ("Instalacja", "Konfiguracja WiFi", "Rozwiązywanie problemów"), nie według liczby znaków.

Podział rekursywny (recursive chunking)

Dzielisz dokument hierarchicznie: najpierw na rozdziały, potem na sekcje, potem na akapity – aż osiągniesz docelowy rozmiar chunka. Zachowujesz strukturę dokumentu.

Kiedy używać: Dokumenty ze złożoną strukturą (książki, specyfikacje techniczne, dokumentacja API).

Przykład: Dokumentacja API – dzielisz według endpointów, każdy endpoint to osobny chunk z opisem, parametrami i przykładami.

Wielkość chunka – ile to jest "za dużo"

Typowe rozmiary chunków to 256-1024 tokeny (około 200-800 słów). To tylko punkt wyjścia.

Małe chunki (128-256 tokenów):

• Wysoka precyzja – zwracasz dokładnie fragment, który odpowiada na pytanie
• Ryzyko utraty kontekstu – chunk może być za krótki, by model zrozumiał znaczenie
• Więcej chunków = więcej embeddingów = wyższe koszty storage i retrieval

Duże chunki (512-1024 tokeny):

• Więcej kontekstu – model widzi szerszy obraz
• Niższa precyzja – zwracasz fragment z "szumem" (informacjami nieistotnymi dla pytania)
• Mniej chunków = niższe koszty, szybszy retrieval

Zacznij od 512 tokenów i testuj. Jeśli RAG zwraca za dużo nieistotnych informacji – zmniejsz. Jeśli odpowiedzi są urywane i brakuje kontekstu – zwiększ.

Overlap – dlaczego chunki powinny się nakładać

Dzielisz dokument co 500 znaków. Granica chunka wypada w połowie zdania o kluczowej informacji. Chunk 1 kończy się na "Aby aktywować funkcję, należy..." – a chunk 2 zaczyna się od "...przejść do ustawień zaawansowanych".

Żaden z chunków nie zawiera pełnej instrukcji. RAG nie znajdzie odpowiedzi.

Rozwiązanie: overlap – nakładanie się chunków. Ostatnie 50-100 tokenów chunka 1 powtarzasz na początku chunka 2. Tak zachowujesz ciągłość kontekstu.

Typowy overlap to 10-20% rozmiaru chunka. Jeśli chunk ma 512 tokenów, overlap wynosi 50-100 tokenów.

Koszt? Duplikujesz część danych – więcej embeddingów, wyższe koszty storage. Zyskujesz pewność, że żadna informacja nie "wpadnie" w szczelinę między chunkami.

Przykład z życia wzięty

Budujesz RAG dla działu HR – system ma odpowiadać na pytania o politykę urlopową. Regulamin ma sekcję:

"Pracownik może wykorzystać urlop wypoczynkowy po przepracowaniu co najmniej 3 miesięcy. Wnioski należy składać z 14-dniowym wyprzedzeniem. W przypadku urlopu na żądanie wystarczy zgłoszenie z 1-dniowym wyprzedzeniem."

Bez overlapu chunk 1 kończy się na "Wnioski należy składać z 14-dniowym wyprzedzeniem." Chunk 2 zaczyna się od "W przypadku urlopu na żądanie..."

Użytkownik pyta: "Ile dni wcześniej zgłosić urlop na żądanie?"

RAG zwraca chunk 2 – ale bez kontekstu z chunka 1 może nie zrozumieć różnicy między urlopem standardowym a na żądanie. Z overlapem chunk 2 zawiera ostatnie zdanie chunka 1 – i odpowiedź jest pełna.

Metadane – niewidoczny bohater chunkingu

Każdy chunk powinien mieć metadane: tytuł dokumentu, datę, autora, sekcję, numer strony. Dlaczego? RAG może filtrować wyniki przed retrieval.

Przykład: Użytkownik pyta "Jaka była strategia sprzedażowa w Q3 2025?" System filtruje chunki po dacie (Q3 2025) i typie dokumentu ("strategia") – zamiast przeszukiwać całą bazę.

Metadane to także sposób na debugowanie. Jeśli RAG zwraca złą odpowiedź, sprawdzasz metadane chunka – i widzisz, że system wyciągnął dane z niewłaściwego dokumentu.

Typowe metadane:

• source_document (nazwa pliku/URL)
• page_number (jeśli PDF)
• section_title (nagłówek sekcji)
• created_at / updated_at (daty)
• author (kto stworzył dokument)
• document_type ("FAQ", "raport", "instrukcja")

narzędzia zastąpią Ci Claude i Codex. Lokalnie.">narzędzia do chunkingu – nie musisz pisać od zera

Chunking to rozwiązany problem. Nie musisz budować własnego parsera – chyba że masz bardzo specyficzne wymagania.

LangChain Text Splitters – biblioteka z gotowymi splitterami (CharacterTextSplitter, RecursiveCharacterTextSplitter, SemanticChunker). Obsługuje overlap, metadane, różne strategie podziału.

LlamaIndex – framework do budowania RAG, ma wbudowane narzędzia do chunkingu z automatycznym wykrywaniem struktury dokumentu.

Unstructured.io – API do parsowania dokumentów (PDF, Word, HTML) z automatycznym podziałem na chunki i ekstrakcją metadanych.

Jeśli dopiero zaczynasz, użyj LangChain. Jeśli budujesz produkcyjny system z tysiącami dokumentów, rozważ Unstructured.io – płatne, ale oszczędza tygodnie pracy.

Typowe błędy przy chunkowaniu

Chunk za mały: "Jakie są wymagania techniczne?" – RAG zwraca chunk z samym nagłówkiem "Wymagania techniczne", bez treści. Treść była w kolejnym chunku.

Chunk za duży: "Ile kosztuje subskrypcja Premium?" – RAG zwraca chunk z całą sekcją cennikową (5 planów, 20 opcji dodatkowych). Użytkownik musi sam szukać odpowiedzi w ścianie tekstu.

Brak overlapu: Informacja o warunkach zwrotu produktu jest rozdzielona między dwa chunki. RAG zwraca tylko jeden – odpowiedź jest niepełna.

Ignorowanie struktury dokumentu: Dzielisz tabelę w połowie. RAG zwraca chunk z nagłówkami kolumn, ale bez danych. Albo odwrotnie – dane bez nagłówków.

Brak metadanych: Masz 50 wersji tego samego dokumentu (różne lata). RAG zwraca chunk z danych z 2022 roku – użytkownik nie sprecyzował daty, a system nie miał jak filtrować.

Jak testować strategię chunkingu

Nie zgaduj – testuj. Przygotuj zestaw 20-30 pytań, które użytkownicy będą zadawać systemowi. Dla każdego pytania zaznacz, który chunk powinien zostać zwrócony.

Uruchom RAG z różnymi strategiami chunkingu (256 tokenów vs 512, overlap 10% vs 20%, podział po akapitach vs semantyczny). Sprawdź, która strategia zwraca właściwe chunki najczęściej.

Metryki do śledzenia:

• Precision: Ile zwróconych chunków było istotnych?
• Recall: Czy system znalazł wszystkie istotne chunki?
• Latency: Jak długo trwa retrieval? (Więcej chunków = wolniejsze wyszukiwanie)
• Cost: Ile kosztują embeddingi + storage dla danej strategii?

Najlepiej: zautomatyzuj testy. Przy każdej zmianie w strategii chunkingu uruchamiasz zestaw pytań i porównujesz wyniki. Podstawy Data Science pomogą Ci skonfigurować taki pipeline.

Chunking dla różnych typów danych

PDF z tabelami i wykresami

Nie dziel tabeli w połowie. Użyj narzędzi typu Unstructured.io, które wykrywają tabele i traktują je jako osobne chunki. Metadane powinny zawierać informację "chunk_type: table".

Kod źródłowy

Dziel po funkcjach/klasach, nie po liczbie linii. Każdy chunk to jedna funkcja z docstringiem. Metadane: nazwa funkcji, plik, język programowania.

Transkrypcje audio/wideo

Dziel po timestampach (np. co 2 minuty) lub semantycznie (wykryj zmianę tematu). Metadane: timestamp, speaker_id (kto mówi).

FAQ

Każde pytanie + odpowiedź to osobny chunk. Proste, skuteczne. Metadane: kategoria pytania, tagi.

E-maile

Każdy e-mail to osobny chunk (jeśli krótki) albo dziel długie wątki na pojedyncze wiadomości. Metadane: nadawca, data, temat.

FAQ

Czy mogę używać różnych strategii chunkingu w jednym systemie RAG?

Tak. Możesz mieć różne strategie dla różnych typów dokumentów. FAQ dzielisz po pytaniach, raporty semantycznie, kod po funkcjach. W metadanych zaznaczasz strategię – i przy retrieval możesz filtrować lub ważyć wyniki inaczej w zależności od typu chunka.

Jak duży overlap jest optymalny?

Zacznij od 10-15% rozmiaru chunka. Jeśli widzisz, że RAG traci kontekst na granicach (odpowiedzi są urwane) – zwiększ do 20-25%. Jeśli koszty storage rosną za szybko – zmniejsz. Nie ma jednej uniwersalnej wartości – zależy od struktury danych i typu pytań.

Czy chunking wpływa na koszty RAG?

Bardzo. Mniejsze chunki = więcej embeddingów = wyższe koszty API (OpenAI, Cohere) i storage (Pinecone, Weaviate). Zbyt duże chunki = gorsza jakość odpowiedzi = więcej zapytań użytkowników = też wyższe koszty. Optymalizuj pod kątem jakości, nie tylko ceny – słaba jakość kosztuje Cię użytkowników.

Czy powinienem re-chunkować dane po zmianie strategii?

Tak. Jeśli zmieniasz strategię chunkingu (np. z 256 na 512 tokenów), musisz przetworzyć dokumenty od nowa i wygenerować nowe embeddingi. Stare chunki będą niekompatybilne z nową strategią. Dlatego testuj strategię na małym zbiorze danych przed wdrożeniem na produkcji.

Jak chunking wpływa na halucynacje modelu?

Bezpośrednio. Jeśli chunk jest za mały i nie zawiera pełnego kontekstu, model może "domyślić" brakujące informacje – czyli zahalucynować. Jeśli chunk jest za duży i zawiera sprzeczne informacje, model może je pomieszać. Dobry chunking = mniej halucynacji. Skuteczne prompty to druga połowa równania – ale bez dobrych danych nawet najlepszy prompt nie pomoże.

Chunking to fundament RAG – ale nie jedyny element. Musisz jeszcze wybrać model embeddingowy, bazę wektorową, strategię retrieval i funkcję podobieństwa. Każdy z tych elementów wpływa na jakość końcowych odpowiedzi.

Zacznij od chunkingu. Najlepszy model nie uratuje źle przygotowanych danych. Dobrze pocięte chunki mogą działać nawet z przeciętnym modelem.

Jeden krok na start: Weź jeden dokument, który chcesz dodać do RAG. Podziel go trzema metodami: po 500 znakach, po akapitach i semantycznie. Wygeneruj embeddingi dla każdej wersji. Zadaj 5 pytań i sprawdź, która strategia zwraca najlepsze chunki. To zajmie godzinę – i nauczy Cię więcej niż tydzień czytania dokumentacji.