System RAG nie cytuje całego artykułu, tylko jeden fragment: zwykle kilkaset tokenów wycięte z tekstu bez reszty kontekstu. Chunking treści pod RAG to dopasowanie długości sekcji, nagłówków i sposobu pisania do tego mechanizmu, żeby wycięty fragment nadal miał sens i dało się go zacytować. Ten tekst pokazuje, jak parametry podziału wpływają na odzyskiwanie fragmentów i jak sprawdzić własną stronę na prostym prototypie.
W skrócie
- Domyślne rozmiary fragmentów w popularnych bibliotekach to 256–1000 tokenów; sekcja dłuższa niż to zostanie przecięta w losowym miejscu.
- Nagłówek H2 lub H3 często trafia do metadanych fragmentu, więc powinien sam nazywać temat, a nie być grą słów.
- Fragment ma być samodzielny: bez „jak wyżej”, „w poprzednim punkcie” i zaimków bez odniesienia.
- Tabele i listy przetrwają podział tylko wtedy, gdy mają nagłówek i mieszczą się w jednym fragmencie.
- Test na własnym RAG (kilkadziesiąt linii kodu) pokazuje, które sekcje strony w ogóle nie są odzyskiwane.
Jak działa podział dokumentu na fragmenty
Podział zaczyna się od pobrania strony, usunięcia nawigacji i stopki, a potem pocięcia pozostałego tekstu na fragmenty o stałej maksymalnej długości. Najczęściej używany algorytm, rekurencyjny splitter znany z LangChain, próbuje ciąć kolejno po podwójnym znaku nowej linii (akapit), pojedynczym (linia), spacji i dopiero na końcu po znaku. Domyślne ustawienia tej biblioteki to 1000 znaków fragmentu i 200 znaków nakładki, czyli mniej więcej 150–200 polskich słów.
Każdy fragment trafia osobno do modelu embeddingów, który zamienia go w wektor liczbowy. Zapytanie użytkownika przechodzi przez ten sam model, a system porównuje wektory i zwraca kilka najbliższych fragmentów, zwykle od 3 do 10. Mechanikę osadzeń i to, jak wpływa na dopasowanie zapytań, opisujemy w tekście o vector embeddings dla SEO.
Dla autora treści wniosek jest prosty: model nigdy nie widzi artykułu w całości. Widzi trzy do dziesięciu wycinków z różnych źródeł, ułożonych obok siebie, i z nich składa odpowiedź. Ogólne strategie dzielenia tekstu zebraliśmy w przewodniku po chunkowaniu treści; tutaj skupiamy się na tym, co zmienić w samym pisaniu.
Optymalna długość sekcji w praktyce
Sekcja pod jednym nagłówkiem powinna mieścić się w jednym fragmencie, czyli w praktyce liczyć 120–250 słów. Polski tekst tokenizuje się gorzej niż angielski: jeden wyraz to często 2–3 tokeny, więc limit 512 tokenów oznacza około 200 słów, nie 380 jak w angielskim. Sekcja na 600 słów zostanie pocięta na trzy lub cztery kawałki, z których tylko pierwszy „wie”, o czym jest.
| Długość sekcji (H2/H3) | Co robi splitter przy 512 tokenach | Ryzyko dla cytowania |
|---|---|---|
| do 120 słów | Jeden fragment, często sklejony z sąsiednią sekcją | Fragment miesza dwa tematy, gorsze dopasowanie |
| 120–250 słów | Jeden fragment, granica na nagłówku | Najniższe: fragment ma temat, kontekst i dane |
| 250–500 słów | Dwa fragmenty z nakładką | Drugi fragment traci nagłówek i podmiot |
| powyżej 500 słów | Trzy i więcej fragmentów | Środkowe kawałki bez kontekstu, rzadko odzyskiwane |
Krótsze sekcje mają też drugi efekt: każda z nich dostaje własny wektor, więc strona z dwunastoma sekcjami po 180 słów odpowiada na dwanaście różnych zapytań, a nie na jedno ogólne. To odwrotność logiki długiego przewodnika pisanego pod pozycję w Google, gdzie liczy się kompletność jednej strony.
Nagłówki jako nośnik kontekstu
Nagłówek jest jedyną częścią sekcji, którą splitter potrafi zachować niezależnie od miejsca cięcia. Narzędzia dzielące po strukturze HTML lub Markdown (na przykład MarkdownHeaderTextSplitter) dopisują ścieżkę nagłówków do metadanych każdego fragmentu: „Chunking treści pod RAG > Optymalna długość sekcji”. Fragment bez nagłówka w treści nadal niesie temat, jeśli nagłówek trafił do metadanych.
Z tego wynikają trzy zasady pisania nagłówków. Po pierwsze, nagłówek nazywa temat rzeczownikowo lub jako pytanie: „Ile tokenów ma polski akapit”, nie „Zaskoczenie w liczbach”. Po drugie, każdy H2 zawiera pełną nazwę podmiotu, bo fragment z nagłówkiem „Wady” nie mówi, czego wady. Po trzecie, hierarchia H2 i H3 musi być prawdziwa: H3 pod niewłaściwym H2 dziedziczy zły kontekst w metadanych.
Nazwa własna w nagłówku działa jak kotwica encji. Jeśli marka ma spójny opis w danych strukturalnych, model łatwiej łączy fragment z podmiotem; jak to ustawić, pokazuje tekst o schema Organization i sameAs. Anthropic w badaniu z września 2024 pokazał, że dopisanie do każdego fragmentu krótkiego zdania kontekstu (tzw. contextual retrieval) obniżyło odsetek nieudanych odzyskań o 49%, a z rerankingiem o 67%. Dobry nagłówek daje część tego efektu za darmo, bo systemy i tak go dokładają.
Samodzielność fragmentu: unikanie odwołań do reszty tekstu
Fragment jest samodzielny, gdy czytelnik (lub model) zrozumie go bez poprzednich akapitów. Najczęściej psują to trzy nawyki: zaimki bez odniesienia („to rozwiązanie”, „ta metoda”), odwołania pozycyjne („jak wyżej”, „w tabeli poniżej”, „w poprzednim punkcie”) i skróty zdefiniowane raz na początku artykułu.
Zamiast tego pierwsze zdanie każdej sekcji powtarza podmiot pełną nazwą i od razu podaje odpowiedź. Zamiast „Ta technika skraca czas indeksowania” piszcie „Podział po nagłówkach skraca czas przygotowania bazy wiedzy, bo…”. Skrót rozwijajcie przy pierwszym użyciu w każdej sekcji, nie tylko w całym tekście. Powtórzenie, które w klasycznym SEO wyglądałoby na przesadę, w RAG jest warunkiem odzyskania.
Dobrą miarą jest test wycinka: skopiujcie sekcję do pustego dokumentu i przeczytajcie ją bez tytułu. Jeśli pojawia się pytanie „czego to dotyczy?”, sekcja nie przetrwa podziału.
Tabele, listy i dane liczbowe we fragmentach
Tabela w HTML jest dla splittera ciągiem wierszy i splitter przetnie ją w środku tak samo jak akapit. Tabela o 4–6 wierszach z nagłówkiem kolumn i zdaniem wprowadzającym mieści się w jednym fragmencie; tabela o 30 wierszach zostanie rozbita na kilka kawałków, z których tylko pierwszy ma nagłówki kolumn. Jeśli dane porównawcze są długie, podzielcie je na kilka tabel z osobnymi nagłówkami H3.
Liczby wymagają jednostki i daty w tym samym zdaniu, bo fragment nie zobaczy legendy z początku artykułu: „koszt 0,02 USD za 1 tys. tokenów (cennik z marca 2026)”, a nie „0,02″. Ta sama zasada dotyczy danych o produkcie, gdzie cenę i dostępność najlepiej podać w treści i w znacznikach; szczegóły opisuje artykuł o product schema pod AI. Listy punktowane działają dobrze, gdy każdy punkt jest pełnym zdaniem; lista samych haseł traci znaczenie po odcięciu od zdania wprowadzającego.
Jak przetestować własną treść na prostym RAG
Prototyp do testu mieści się w kilkudziesięciu liniach Pythona i pokazuje, które sekcje strony w ogóle nie są odzyskiwane. Kolejność prac:
- Pobierzcie 20–50 własnych URL-i i wyciągnijcie treść z elementu artykułu (bez menu, stopki i komentarzy).
- Podzielcie tekst rekurencyjnym splitterem na 512 tokenów z nakładką 64 i zapiszcie dla każdego fragmentu URL oraz ścieżkę nagłówków.
- Policzcie embeddingi dowolnym modelem (lokalny model wielojęzyczny wystarczy) i wrzućcie je do prostego indeksu w pamięci.
- Przygotujcie 30 pytań, na które strona powinna odpowiadać, i dla każdego sprawdźcie, czy właściwy fragment jest w pierwszej piątce wyników.
- Zapiszcie wynik jako trafność w top-5 oraz listę sekcji, które nie pojawiły się dla żadnego pytania: te sekcje trzeba przepisać lub podzielić.
Ten test nie odtwarza dokładnie tego, co robi Google, Perplexity czy ChatGPT, bo każdy z nich ma własne parametry. Odtwarza jednak sam mechanizm i wyłapuje sekcje, które nie mają szans w żadnej konfiguracji. Google w przewodniku o funkcjach AI w wyszukiwarce podkreśla, że nie ma osobnej „optymalizacji pod AI” poza czytelną, dobrze ustrukturyzowaną treścią (więcej w dokumentacji Google Search Central). Jeśli test uruchamiacie na danych z produkcji z logowaniem pytań użytkowników, pamiętajcie o zgodach; wdrożenie opisuje poradnik o Consent Mode v2 w GTM.
Błędy, które rozbijają kontekst
Najdroższy błąd to jedna sekcja na 800 słów pod nagłówkiem „Wszystko, co musisz wiedzieć”: środek takiej sekcji nie ma ani nagłówka, ani podmiotu, ani danych. Drugi to nagłówki-hasła („Krok 3″, „Podsumowanie”, „Uwaga”), które w metadanych fragmentu nie znaczą nic. Trzeci to definicja terminu podana raz we wstępie i używana przez resztę tekstu w formie skrótu.
Częste są też problemy techniczne: treść ładowana skryptem po stronie przeglądarki, którą crawler RAG w ogóle nie widzi; boksy „przeczytaj też” wstrzykiwane w środek artykułu, które lądują w połowie fragmentu; wreszcie FAQ ukryte w akordeonie, którego HTML nie zawiera tekstu odpowiedzi, dopóki użytkownik nie kliknie. Elementy <details> są bezpieczne, bo tekst jest w kodzie strony od razu.
FAQ: chunking treści pod RAG
Ile słów powinna mieć sekcja pod jednym nagłówkiem?
Dla polskiego tekstu 120–250 słów. Przy typowym limicie 512 tokenów i tokenizacji 2–3 tokeny na wyraz sekcja do 200 słów mieści się w jednym fragmencie razem z nagłówkiem. Dłuższe sekcje są cięte, a środkowe kawałki tracą kontekst.
Czy nagłówki H2 i H3 naprawdę trafiają do systemu RAG?
Tak, jeśli system dzieli tekst po strukturze dokumentu. Splittery oparte na Markdown lub HTML zapisują ścieżkę nagłówków w metadanych fragmentu, a wiele wdrożeń dokleja ją do treści przed policzeniem embeddingu. Nagłówek działa wtedy jak etykieta całego fragmentu.
Czym jest nakładka (overlap) i czy autor treści ma na nią wpływ?
Nakładka to fragment tekstu powtórzony na końcu jednego i początku następnego chunku, zwykle 10–20% długości. Autor nie ustawia jej, ale może zmniejszyć zależność od niej: jeśli każda sekcja zaczyna się od pełnego podmiotu i odpowiedzi, nakładka przestaje być potrzebna do zrozumienia fragmentu.
Czy krótsze sekcje nie zaszkodzą pozycjom w Google?
Nie, jeśli suma sekcji dalej wyczerpuje temat. Google ocenia całą stronę, a RAG pojedyncze fragmenty; artykuł z dwunastoma sekcjami po 180 słów spełnia oba warunki. Problemem byłoby dopiero sztuczne dzielenie jednej myśli na kilka nagłówków bez treści.
Jak sprawdzić, czy moja strona jest odzyskiwana przez RAG, bez pisania kodu?
Zadajcie w Perplexity lub ChatGPT z przeglądaniem 10–15 pytań, na które strona odpowiada, i sprawdźcie, czy w cytowaniach pojawia się właściwy URL i właściwa sekcja. To test jakościowy; ilościowy wymaga własnego prototypu z listy powyżej.
Co dalej
Najpierw uruchomcie test na 20–30 stronach i policzcie, ile sekcji nie odzyskuje się dla żadnego pytania: to lista do przepisania. Dopiero potem warto wchodzić w szczegóły samego mechanizmu, które opisuje tekst o RAG dla marketerów, i w dobór modelu embeddingów.