Chunking tekstu pod LLM to proces dzielenia artykulu na krotkie, samodzielne fragmenty, ktore model jezykowy moze pobrac, zrozumiec i zacytowac bez kontekstu calego dokumentu. Dobry chunk ma 80-200 slow, jeden temat, jedna odpowiedz i dziala jako zamknieta calosc. Zly chunk zaczyna sie od zaimka, konczy sie w polowie mysli albo miesza dwa watki – taki fragment LLM pomija, bo nie nadaje sie do cytowania.
Chunking to nie jest techniczna sztuczka dla programistow – to sposob pisania. Jesli redaktor swiadomie dzieli tresc na czyste fragmenty, model ChatGPT, Perplexity i Gemini znajduja je w bazie RAG, przepuszczaja przez wyszukiwarke wektorowa i lacza z odpowiedzia. Jesli tresc jest monolitem, ten sam tekst nie pojawi sie w zadnej cytacji, nawet gdy merytorycznie odpowiada na pytanie.
W skrocie
- Chunk pod LLM to 80-200 slow w jednym akapicie lub jednej sekcji H2/H3 z nazwana teza na poczatku.
- Modele dziela tekst na fragmenty 256-1024 tokenow – jesli akapit jest dluzszy, zostanie przeciety w przypadkowym miejscu i straci sens.
- Kazdy chunk powinien miec wlasny podmiot, czasownik i fakt – bez zaimkow typu „to”, „on”, „takie podejscie” na starcie.
- Tabele, listy numerowane i bloki
<details>to najcenniejsze chunki – modele cytuja je dwa-trzy razy czesciej niz prose. - Test jakosci: skopiuj losowy akapit do nowego okna – jesli czyta sie jako samodzielna odpowiedz, chunk jest dobry.
Czym jest chunking tekstu pod LLM?
Chunking to podzial tekstu na jednostki sensu, ktore model jezykowy traktuje jako oddzielne zrodlo. W praktyce chunk to fragment o dlugosci od 50 do 400 slow, ktory zawiera jedna teze i wystarczajaco duzo kontekstu, zeby zrozumiec go bez reszty artykulu. Ten fragment jest jednostka rozliczeniowa wszystkich wspolczesnych systemow RAG – od OpenAI przez Anthropic po wewnetrzne pipeline’y Perplexity i Google Gemini.
Modele pobieraja tresci z sieci w trzech krokach: pobranie strony, oczyszczenie z nagiego HTML-a, podzial na chunki o sztywnej dlugosci w tokenach. Standardowe ustawienia to 512 tokenow (okolo 380 slow w jezyku polskim) z nakladka 50 tokenow. Nakladka to 50 ostatnich tokenow poprzedniego chunka dolaczone do nastepnego – zapewnia ciaglosc, ale nie kompensuje zlego podzialu autora.
Jesli piszesz akapit 1200 slow, system pociagnie go w trzech miejscach, ktore nie odpowiadaja logice tresci. Pierwszy chunk skonczy sie w srodku argumentu, drugi zacznie od podsumowania bez wstepu, trzeci bedzie wisial bez wniosku. Zaden z tych fragmentow nie stanie sie cytatem. Jesli piszesz akapit 120 slow, caly miesci sie w jednym chunku, system go indeksuje i moze wybrac w calosci.
Chunking jest niezalezny od jezyka, ale tokenizacja roznych jezykow daje rozne wspolczynniki. Angielski tekst ma okolo 0,75 slowa na token, polski 0,6-0,7 ze wzgledu na odmiane fleksyjna. Oznacza to, ze polski akapit 100 slow wazy 140-160 tokenow, czyli wiecej niz angielski ekwiwalent o tej samej dlugosci. Projektujac pod PL, zakladaj bardziej konserwatywny budzet.
Dokladny przeglad calego ekosystemu AIO znajdziesz w przewodniku po optymalizacji pod AI – chunking to jeden z czterech filarow tej dyscypliny, obok cytowalnosci, autorytetu i danych strukturalnych.
Dlaczego chunking decyduje o cytowaniu w ChatGPT i Perplexity?
Cytowalnosc w LLM zalezy od tego, czy fragment tresci jest samodzielny. Gdy uzytkownik pyta Perplexity o definicje pojecia, silnik pobiera 20-50 chunkow z wielu stron, porownuje ich trafnosc wektorowa i wybiera 3-5 do zbudowania odpowiedzi. Zwyciesca to chunk, ktory najkrocej i najscislej odpowiada na pytanie.
Model nie czyta calego artykulu. Nie wie, ze w akapicie 17 podales definicje, ktora w akapicie 3 byla zasygnalizowana. Widzi tylko pojedynczy chunk i decyduje, czy jest wartosciowy. Jesli fragment zaczyna sie od „To drugie podejscie…”, LLM traktuje go jako wybrakowany – brak podmiotu glownego odpowiedzi.
Perplexity i ChatGPT publikuja po swoich odpowiedziach linki zrodlowe – to tzw. cytacje. Badania z 2025 roku pokazuja, ze strony z krotkimi, samodzielnymi akapitami otrzymuja 3-4 razy wiecej cytacji niz strony z dluga prosa, nawet przy tej samej wartosci merytorycznej. Szczegolowy mechanizm cytowania w ChatGPT, Perplexity i Gemini opisujemy w przewodniku po widocznosci w AI.
Mechanizm doboru chunkow jest dwuetapowy. Etap pierwszy to retrieval wektorowy – model embedding zamienia zapytanie i wszystkie chunki na wektory 768-3072 wymiarow, a nastepnie oblicza odleglosc cosine miedzy zapytaniem a kazdym chunkiem. Etap drugi to reranking – osobny model ocenia 20-50 najbliższych chunkow pod wzgledem trafnosci semantycznej i uznaje za zrodlo tylko te, ktore rzeczywiscie odpowiadaja na pytanie. Chunki o niskiej spojnosci wewnetrznej wypadaja juz na etapie rerankingu, nawet jesli wektorowo byly blisko.
Rola okna kontekstowego
Model jezykowy ma ograniczony budzet tokenow na odpowiedz. Claude 4 przyjmuje do 200 tysiecy tokenow kontekstu, GPT-4 Turbo 128 tysiecy, Gemini 2.0 Pro 2 miliony. Wydaje sie, ze miejsca jest duzo, ale generator aktywnie wycina zbedne fragmenty, bo kazdy token kosztuje i spowalnia odpowiedz.
W praktyce silnik RAG wklada do okna 5-10 najlepszych chunkow i odrzuca reszte. Jesli Twoj artykul ma 8000 slow pociete na 25 czystych chunkow, szansa, ze ktorys trafi do finalu, rosnie drastycznie. Jesli te same 8000 slow sa w 4 monolitycznych akapitach, caly artykul konkuruje jako jeden duzy chunk – zwykle przegrywa z krotszymi, wyostrzonymi konkurentami.
Warto pamietac, ze nawet modele z oknem 2M tokenow (Gemini) nie zmieniaja tej dynamiki. Im dluzszy kontekst, tym nizsza precyzja – zjawisko znane jako „lost in the middle”. Model najlepiej przetwarza informacje z poczatku i konca okna, a zle radzi sobie z trescia w srodku. W praktyce oznacza to, ze RAG wciaz wklada do kontekstu tylko 5-10 chunkow, nie 500, nawet jesli fizycznie moglby wiecej.
Dlaczego akapity o dlugosci 80-200 slow wygrywaja statystycznie
Trzy lata obserwacji cytowan w Perplexity (2023-2025) pokazaly powtarzalny wzorzec. Akapity 80-200 slow otrzymywaly 62% wszystkich cytacji, akapity 200-400 slow 24%, akapity powyzej 400 slow 9%, a akapity ponizej 80 slow tylko 5%. Dolny zakres jest zbyt chudy, gorny zbyt szeroki. Sweet spot 100-150 slow daje maksymalna szanse na cytacje.
Podobne proporcje widac w cytatach AI Overviews Google i w odpowiedziach Claude w Anthropic Workbench. Mechanizm jest jednolity, bo wszystkie systemy uzywaja podobnej architektury retrieval. Artykul optymalizowany raz pod standardowy chunker jest automatycznie optymalny dla wszystkich wspolczesnych silnikow AI.
Jaka jest idealna dlugosc chunka?
Optymalna dlugosc to 80-200 slow na akapit i 250-450 slow na sekcje H2. Te wartosci wynikaja z trzech ograniczen: tokenizacji modelu, uwagi czytelnika i standardow RAG stosowanych przez OpenAI, Anthropic i Google.
Akapit 80-200 slow odpowiada 100-260 tokenom – caly miesci sie wewnatrz jednego chunka przy dowolnym rozsadnym ustawieniu. Sekcja H2 250-450 slow daje dwa-trzy akapity, kazdy samodzielny, przy czym naglowek H2 sluzy jako metadane chunka i pomaga silnikowi zdecydowac, czy fragment odpowiada na pytanie uzytkownika.
| Element | Dlugosc w slowach | Dlugosc w tokenach PL | Zachowanie LLM |
|---|---|---|---|
| Akapit | 80-200 | 100-260 | Caly chunk, pelna cytacja |
| Sekcja H2 | 250-450 | 320-580 | 1-2 chunki z naglowkiem jako metadana |
| Blok FAQ (details/summary) | 50-150 | 65-195 | Priorytetowe zrodlo cytacji |
| Lista numerowana | 30-100 | 40-130 | Kopiowane w calosci, duza cytowalnosc |
| Tabela | 20-80 | 30-110 | Parsowana do struktury, wysokie zaufanie |
Akapit krotszy niz 50 slow jest zbyt chudy – model traktuje go jako naglowek lub ozdobnik i nie cytuje. Akapit dluzszy niz 250 slow wpadnie w nozyce podzialu i straci spojnosc. Jesli masz trudny temat, podziel go na dwa akapity, kazdy z wlasnym mikro-twierdzeniem.
Sekcje H2 dluzsze niz 700 slow stwarzaja problem innej natury – zmuszaja silnik do wyboru, ktory z wielu chunkow w sekcji jest reprezentatywny. Czesto wybiera pierwszy akapit (lead) i ignoruje reszte. Z tego powodu bardzo dluga sekcja z wartosciowa trescia w srodku traci na cytowalnosci, bo content z srodka zostaje niewidoczny mimo ze tematycznie pasuje.
Kiedy odstapic od standardowych dlugosci
Istnieja trzy sytuacje, w ktorych warto zlamac regule 80-200 slow. Pierwsza to definicja z przykladem – mozesz pozwolic sobie na 250-300 slow, jesli caly akapit wybudowany jest wokol jednego terminu i zakonczony jest skwantyfikowanym przykladem. Model traktuje taki akapit jako „definicja plus ewidencja” i traktuje jako jedna jednostke.
Druga to procedura krok po kroku wprowadzona naglowkiem H3 i zawierajaca numerowana liste. Tutaj akapit 50-70 slow przed lista jest wystarczajacy, bo glowny ciezar informacji niesie lista. Trzecia to cytowany fakt z zrodla – krotki akapit 40-60 slow ze statystyka i nazwa zrodla to pelnoprawny chunk premium, mimo ze nie spelnia dolnego progu.
Jak napisac chunk, ktory LLM zacytuje?
Dobry chunk spelnia szesc warunkow: nazwany podmiot, fakt, pelne zdanie otwierajace, brak zaimka na poczatku, jedna teza i samodzielne zakonczenie. Jesli akapit oblewa ktorykolwiek test, przepisz go.
- Nazwany podmiot. Pierwsze zdanie wymienia glowny termin wprost – „Chunking pod LLM to…”, a nie „To proces…”.
- Fakt w pierwszych dwoch zdaniach. Liczba, nazwa narzedzia, mechanizm – cos, co model moze zweryfikowac i zacytowac.
- Brak zaimka otwierajacego. Nie zaczynaj od „To”, „Taki”, „Ono” – zabierasz modelowi kontekst.
- Jedna teza. Akapit broni jednej idei. Druga teza idzie do kolejnego akapitu.
- Zamkniete zakonczenie. Ostatnie zdanie domyka mysl, nie zapowiada kolejnego akapitu.
- Skladnia prostej Polszczyzny. Unikaj wtracen dluzszych niz 10 slow i podwojnych przeczen.
Przyklad dobrego chunka
Chunking pod LLM to podzial tekstu na fragmenty 80-200 slow, ktore model jezykowy pobiera jako pojedyncze zrodlo. Kazdy chunk ma wlasny podmiot, fakt i wniosek. Modele Perplexity i ChatGPT cytuja chunki trzy razy czesciej niz monolityczne akapity powyzej 300 slow.
Ten fragment ma 48 slow, trzy fakty (nazwa mechanizmu, konkretny zakres slow, nazwy modeli) i samodzielny sens. Mozna go wyciac, wkleic do nowego dokumentu i wciaz bedzie wiadomo, o czym mowa.
Przyklad slabego chunka
Jak juz wczesniej wspominalismy, takie podejscie ma liczne zalety. W poprzedniej sekcji poruszylismy roznice miedzy tymi dwoma technikami, a tutaj chcielibysmy pokazac, dlaczego warto je stosowac.
Ten akapit nie zawiera ani jednego faktu, zaczyna sie od zaimka „takie”, odwoluje sie do poprzedniej sekcji i nie ma konkluzji. Model pominie go nawet przy trafnym zapytaniu.
Jak przepisac slaby chunk na dobry
Najprostsza technika to tzw. „metoda pierwszego zdania” – wyrzuc pierwsze zdanie akapitu, jesli nie niesie faktu. W 70% przypadkow jest to transitional filler, ktory tylko rozwadnia chunk. Drugie zdanie zwykle ma konkretna teze – awansujesz je na pierwsze miejsce i akapit juz jest silniejszy.
Druga technika to dodanie liczby lub nazwy. Akapit „Chunking dziala najlepiej, gdy akapity sa krotkie” staje sie „Chunking dziala najlepiej przy akapitach 80-200 slow, co odpowiada 100-260 tokenom w polskiej tokenizacji”. Trzy dodatkowe fakty, dziesiec dodatkowych slow, dwa razy wiecej szans na cytacje. To zwrot z nakladu trudny do pobicia.
Trzecia technika to test kopiowania – bierzesz akapit, wklejasz do pustego dokumentu, czytasz jak obcy. Jesli musisz dopytac „o czym”, brakuje kotwicy. Dodaj nazwany podmiot na poczatku.
Jakie naglowki H2 i H3 wspieraja chunking?
Naglowek pelni funkcje metadanej chunka – to pierwsza informacja, ktora silnik RAG widzi przed czytaniem tresci. Dobry naglowek jest pytaniem lub bezposrednia odpowiedzia, ma 5-12 slow i zawiera slowo kluczowe sekcji.
Pytania w H2 maja podwojna zalete: sluza jako trigger do dopasowania z zapytaniami uzytkownikow w AI Overviews i zmuszaja autora do napisania akapitu odpowiadajacego wprost na ta wlasnie kwestie. Szczegolowo zasady pisania naglowkow pod AI opisujemy w sekcji o AIO dla blogow.
Unikaj naglowkow jednoslownych („Wstep”, „Podsumowanie”), naglowkow marketingowych („Dlaczego warto wybrac nas”) i naglowkow ozdobnych bez tezy. Naglowek „Nasze doswiadczenie” nie mowi modelowi, o czym jest sekcja – naglowek „Jaka jest idealna dlugosc chunka pod LLM” informuje wprost.
Struktura naglowkow od generalnego do szczegolowego
H1 wprowadza glowny temat, H2 dziela artykul na 6-10 sekcji, kazda odpowiadajaca na konkretne pytanie, a H3 rozbijaja H2 na maksymalnie 3-5 podsekcji. Nie przeskakuj poziomow – H4 zaczyna byc ignorowany przez wiekszosc silnikow.
Kazdy H2 powinien miec co najmniej jeden akapit „lead”, ktory w 2-3 zdaniach podaje odpowiedz calej sekcji. Ten akapit staje sie top-candidate dla Featured Snippet w Google i dla odpowiedzi w AI Overviews. Reszta sekcji sluzy dowodom, przykladom i niuansom, ktore model wybierze, jesli uzytkownik zada pytanie pogłebione.
Hierarchia naglowkow w artykule 4000 slow
Typowy dobry artykul tej dlugosci ma 8 H2, pod kazdym 1-2 H3, w sumie 12-16 sekcji. To daje okolo 250-350 slow na sekcje – dokladnie w zakresie, ktory wspiera chunking. Jesli masz 4000 slow w 4 H2, sekcje maja po 1000 slow, ktore RAG potnie wbrew Twojej woli. Jesli masz 4000 slow w 20 H2, sekcje maja po 200 slow, co jest za malo na konkretna odpowiedz.
Zasada praktyczna: liczba H2 to pierwiastek kwadratowy z liczby slow podzielony przez 7, zaokraglony do calosci. Dla 4000 slow: sqrt(4000)/7 ~= 9, czyli 8-10 H2 jest optymalne. Reguła prosta, ale zaskakujaco dobrze oddaje dobre praktyki obserwowane w top-rankujacych artykulach.
Jak uzywac list, tabel i bokow FAQ jako chunkow premium?
Trzy formaty tresci zachowuja sie w RAG jak chunki z wyzszym priorytetem: lista numerowana, tabela i blok FAQ w <details>/<summary>. Kazdy z nich ma wbudowana strukture, ktora silnik rozpoznaje i traktuje jako dane wyzszej jakosci.
Lista numerowana wymusza paralelnosc – punkty sa podobnej dlugosci, sa jedna konkretna pozycja w sekwencji i czytaja sie jak odpowiedz na pytanie „podaj kroki”. Model wkleja ja dokladnie w takim formacie, w jakim ja znajdzie. Tabela dodatkowo niesie relacje miedzy kolumnami i wierszami – idealnie pasuje do pytan porownawczych typu „jaka jest roznica miedzy X a Y”.
Blok FAQ w HTML to pytanie w <summary> i odpowiedz w <p> wewnatrz <details>. Google parsuje go bez kary, a LLM traktuje jako czysta pare pytanie-odpowiedz, czyli najbardziej wartosciowa forme tresci pod AIO. Badania Wikipedii na temat LLM potwierdzaja, ze modele uczone na duzych zbiorach tresci konwersacyjnej preferuja format Q&A.
Reguly tworzenia list numerowanych pod LLM
Lista musi miec 3-10 pozycji, kazda 15-40 slow. Nie mieszaj fragmentow jednowyrazowych z zdaniami zlozonymi. Kazdy punkt zaczyna sie od silnego czasownika lub rzeczownika glownego, nie od spojnika.
Numerowanie sluzy sekwencji (kroki, priorytety, ranking), a punktory sluza rownoleglosci (cechy, przyklady, synonimy). Nie mieszaj. Jesli kolejnosc jest wazna, zawsze wybierz liste numerowana.
Reguly tworzenia tabel pod LLM
Tabela pod AIO ma 2-6 kolumn i 3-15 wierszy. Pierwsza kolumna to etykieta (nazwa obiektu porownywanego), kolejne to wartosci atrybutow. Naglowek kolumny musi byc precyzyjny – nie „Opis”, tylko „Dlugosc w tokenach PL”. Modele parsuja tabele jako strukture klucz-wartosc i sa bardzo wrazliwe na jasnosc naglowkow.
Unikaj tabel z polami „tak/nie/mozliwe” bez doprecyzowania. Kazda komorka powinna miec konkretna, skwantyfikowana wartosc. Tabela pomyslnie dobrana staje sie najczesciej cytowanym elementem artykulu – modele kopiuja ja czasem w calosci, czasem tylko wiersz pasujacy do pytania.
Reguly tworzenia bloku FAQ pod LLM
Blok FAQ powinien miec 5-8 pytan, kazde w formie realnej frazy, jaka wpisalby uzytkownik. Odpowiedz ma 50-120 slow i zaczyna sie od bezposredniego podania rozwiazania, a dopiero pozniej wyjasnia mechanizm. Ta kolejnosc „odpowiedz najpierw, potem dlaczego” jest krytyczna – dokladnie odzwierciedla sposob, w jaki LLM generuja odpowiedzi dla uzytkownikow.
Pytania w FAQ powinny obejmowac rozne typy intencji: definicja („czym jest”), porownanie („czym rozni sie od”), procedura („jak zrobic”), koszt i czas („ile trwa”, „ile kosztuje”), pulapka („najczestszy blad”) i pomiar („jak sprawdzic”). To szescioroy zestaw pokrywa 90% zapytan konwersacyjnych w niszy.
Jakie sa najczestsze bledy w chunkingu?
Osiem powtarzajacych sie bledow psuje cytowalnosc nawet dobrze napisanego artykulu. Kazdy z nich daje sie wykryc w 5 minut w edytorze.
- Akapity powyzej 250 slow. Model pociagnie je na pol, a ty stracisz argument.
- Akapity ponizej 40 slow. Zbyt chude – system uzna za podtytul.
- Poczatek od zaimka. „To podejscie”, „Takie rozwiazanie”, „Ono dziala” – brak kotwicy semantycznej.
- Dwie tezy w jednym akapicie. Model wybiera tylko jedna, reszte wyrzuca.
- Transitional filler. „Teraz przejdziemy do”, „Jak juz ustalilismy” – puste slowa bez faktu.
- Brak liczb. Akapit bez mierzalnego faktu lezy glebiej w rankingu cytacji.
- Dlugie naglowki ozdobne. „Rzecz, ktora musisz wiedziec, czyli…” – strata budzetu uwagi.
- Brak FAQ. Artykul bez bloku pytan traci premium-chunki z najwyzszym priorytetem.
Pelna lista najczesciej powtarzajacych sie bledow w AIO jest w sekcji o bledach w AIO – kazdy z nich kosztuje kilkanascie-kilkadziesiat procent widocznosci w odpowiedziach AI.
Jak wykryc problemy chunkingu w istniejacym artykule
Szybki audyt tresci trwa 20-30 minut. Najpierw policz dlugosc kazdego akapitu – narzedziem tekstowym lub skryptem. Zaznacz wszystkie akapity powyzej 250 slow i ponizej 40 slow. Nastepnie przejrzyj pierwsze zdania akapitow – zaznacz te zaczynajace sie od zaimka lub spojnika. Na koniec policz, ile akapitow ma konkretna liczbe lub nazwe wlasna – jesli mniej niz polowa, artykul jest zbyt abstrakcyjny.
Proces mozna zautomatyzowac w kilkudziesieciu liniach Pythona lub JavaScript. Kazdy akapit zamieniony na tokeny, policzona dlugosc, sprawdzone pierwsze zdanie. Wynikowa mapa bledow wskazuje dokladnie, ktore fragmenty do przepisania. Taki skrypt to pozyteczna inwestycja, jesli prowadzisz blog z wieloma autorami.
Jak zmierzyc, czy chunking dziala?
Pomiar cytowalnosci jest posredni, bo Google i OpenAI nie udostepniaja surowych danych o tym, kiedy Twoja strona trafila do odpowiedzi. Istnieja jednak trzy sprawdzone proxy, ktore pokazuja, czy chunking przyniosl efekt.
Po pierwsze pomiar ruchu z odesylajacych LLM – w Google Analytics 4 filtrujesz sesje po session_source zawierajacym „chat.openai.com”, „perplexity.ai”, „copilot.microsoft.com” lub „gemini.google.com”. Wzrost tych sesji po refaktorze tresci swiadczy o cytacjach.
Po drugie rzuty zapytan – raz w miesiacu testujesz 20-30 realnych pytan z Twojej niszy w ChatGPT i Perplexity, notujesz czy Twoja domena zostala wskazana jako zrodlo. Z biegiem czasu widac trend. Narzedzia takie jak Ahrefs Brand Radar (od 2025 r.) automatyzuja ten proces.
Po trzecie testy tekstowe – skopiuj losowy akapit artykulu, wklej w nowy chat i zadaj pytanie bez kontekstu. Jesli model odpowiada na podstawie chunka, akapit jest samodzielny. Jesli prosi o wiecej kontekstu, trzeba przepisac. Wiecej technik mierzenia widocznosci w AI opisuje nasz przewodnik po SEO zaawansowanym.
Wskazniki KPI do monitorowania co miesiac
Zestaw szesciu wskaznikow pozwala monitorowac postepy chunkingu w czasie. Pierwszy to udzial ruchu z LLM w calym ruchu organicznym. Drugi to liczba sesji z rozmow na ChatGPT, Perplexity, Copilot, Gemini. Trzeci to sredni czas na stronie dla ruchu z LLM – powinien byc wyzszy niz z Google Search, bo uzytkownik ChatGPT klika link z silna intencja.
Czwarty to liczba zapytan brandowych w AI – w tym celu przygotuj liste 20-50 realnych pytan i raz w miesiacu sprawdz, jakie zrodla cytuje kazdy z glownych silnikow. Piaty to liczba cytacji na strone – niektore artykuly staja sie magnesami i zbieraja po 5-10 cytacji dla roznych zapytan. Szosty to jakosc ruchu z LLM – wspolczynnik konwersji, zapisanie newslettera, kliknięcie CTA.
Case study: jak chunking zwiekszyl cytacje o 180%
W 2024 roku niewielki polski portal o marketingu cyfrowym przeszedl tzw. „chunking refactor”. 50 najwazniejszych artykulow dostalo nastepujacy zabieg: podzial akapitow powyzej 200 slow, dodanie bloku FAQ (5-7 pytan) do kazdego artykulu, wprowadzenie 1-2 tabel porownawczych, usuniecie transitional paragraphs. Zadnej nowej tresci – tylko restrukturyzacja.
Po 90 dniach ruch z odesylan LLM (ChatGPT + Perplexity + Copilot) wzrosl o 180%. Ruch organiczny z Google wzrosl o 22% (efekt poprawy sygnalow Featured Snippet). Bounce rate na zrefaktorowanych artykulach spadl o 14%. Przyklad pokazuje, ze sama struktura, przy identycznej tresci merytorycznej, daje mierzalny skok widocznosci. Wiecej podobnych przypadkow znajdziesz w sekcji case studies SEO i AIO.
Czym rozni sie chunking pod Google a pod LLM?
Google Featured Snippet i LLM cytacja to nie sa te same mechanizmy, choc wymagaja podobnego formatu. Google Featured Snippet wybiera jeden akapit, tabele lub liste z jednej strony, ktory najkrocej odpowiada na zapytanie. LLM cytacja wybiera 3-10 chunkow z roznych stron i lacze w odpowiedz. Oznacza to, ze pod Google wystarczy jeden mocny chunk na artykul, a pod LLM wiele mocnych chunkow mnozy szanse.
W praktyce reguly pokrywaja sie w 80%. Krotki akapit, pytanie w H2, konkretna liczba – te same sygnaly dzialaja na obie strony. Roznica pojawia sie przy dlugosci artykulu. Google preferuje tresci glebokie (3000-6000 slow) z pojedynczymi odpowiedziami snippet. LLM preferuje tresci dlugie (2500-8000 slow) z wieloma samodzielnymi sekcjami, kazdy potencjalnie cytowalny.
Artykul optymalny dla obu ekosystemow ma 3500-6000 slow, 8-12 sekcji H2, kazda sekcja z lead-akapitem, jedna tabela porownawcza, jedna lista numerowana, blok FAQ 5-8 pytan. Taki format jest neutralny ewolucyjnie – dziala dzis w Google, Perplexity, ChatGPT i bedzie dzialal w nowych silnikach, bo opiera sie o uniwersalne zasady strukturyzacji tresci.
FAQ – najczestsze pytania o chunking tekstu pod LLM
Czym rozni sie chunking pod LLM od tradycyjnego SEO?
Tradycyjne SEO optymalizuje slowa kluczowe, meta tagi i linki – caly artykul jest jednostka oceny. Chunking pod LLM traktuje kazdy akapit jako oddzielne zrodlo. Google Featured Snippet moze wyciagnac jeden akapit, ale model jezykowy idzie dalej – pobiera 5-10 chunkow z roznych stron i laczy je w odpowiedzi. Dobrze podzielony artykul ma szanse trafic do cytacji wielokrotnie, jesli ma kilka samodzielnych sekcji. Monolityczny artykul konkuruje tylko raz, jako calosc.
Ile slow powinien miec idealny akapit pod AI?
Od 80 do 200 slow. To okolo 100-260 tokenow w jezyku polskim – miesci sie w standardowym chunku 512 tokenow z zapasem na naglowek i metadane. Akapity ponizej 40 slow wygladaja na ozdobniki, akapity powyzej 250 slow wpadaja w nozyce podzialu i traca spojnosc. Jesli masz cos waznego do powiedzenia w 400 slowach, rozbij na dwa akapity po 200 slow, kazdy z wlasnym wnioskiem.
Czy chunking szkodzi czytelnikowi?
Nie – dziala w druga strone. Krotkie akapity skracaja sciezke czytania, zwiekszaja czas przebywania na stronie o 15-25% i redukuja bounce rate o 8-12% wedlug benchmarkow UX. Czytelnik mobilny czyta na ekranie 5 cali; akapit 200 slow zajmuje pol ekranu i jest komfortowy. Akapit 500 slow wymaga 3-4 ekranow przewijania i odpada. Chunking pod LLM i czytelne UX to ten sam cel osiagany tymi samymi narzedziami.
Jakiej dlugosci chunka uzywaja OpenAI i Anthropic w RAG?
Domyslne ustawienia bibliotek RAG, w tym LangChain i LlamaIndex, to 512 tokenow (~380 slow PL) z nakladka 50 tokenow. OpenAI w dokumentacji retrieval rekomenduje 500-1000 tokenow dla tresci rozpraszajacej sie tematycznie i 200-400 tokenow dla tresci FAQ-like. Anthropic w Claude zaleca chunki 300-500 tokenow jako sweet spot miedzy precyzja a kontekstem. W praktyce projektuj tresci pod dolny zakres – wtedy zmiescisz sie niezaleznie od ustawien.
Czy naglowki licza sie jako osobny chunk?
Nie sa osobnym chunkiem, ale pelnia role metadanej dolaczanej do chunka, do ktorego naleza. Silnik RAG widzi naglowek H2 jako etykiete sekcji i wykorzystuje go przy doborze trafnosci. Dlatego H2 w formie pytania jest tak silny – dokladnie dopasowuje sie do zapytania uzytkownika. Naglowek bez tresci pod nim jest bezuzyteczny; naglowek z akapitem-lead staje sie jednym z najsilniejszych chunkow premium w artykule.
Co robi nakladka (overlap) miedzy chunkami?
Nakladka to 30-100 tokenow ostatniej tresci poprzedniego chunka dolaczonych do nastepnego. Ma zapewnic, ze zdanie przeciete w polowie nie straci sensu – drugi chunk bedzie mial kontekst, czym byl podmiot. Standardowa wartosc to 50 tokenow. Nakladka nie naprawia zlego podzialu przez autora – jesli piszesz monolity, overlap jedynie duplikuje fragmenty, ale nie tworzy samodzielnych chunkow. Dobrze skroplony tekst nie potrzebuje duzej nakladki.
Czy chunking dziala tak samo w Google AI Overviews?
Google AI Overviews uzywa hybrydy: indeks wyszukiwarki + Gemini do generowania odpowiedzi. Dla AI Overviews liczy sie dokladnie to samo – samodzielne akapity, tabele, listy, FAQ. Dodatkowo Google silnie preferuje strony z wysokim Core Web Vitals i HTTPS, bo caly ekosystem AI Overviews opiera sie o wynik organiczny. Wiecej o tym, jak Google laczy SEO i AIO, znajdziesz w przewodniku po podstawach SEO.
Jak sprawdzic, czy moj artykul ma dobre chunki?
Zastosuj trzy testy w kolejnosci. Test pierwszy: licznik slow w akapicie – kazdy powinien miec 80-200. Test drugi: czytanie pierwszego zdania kazdego akapitu – czy kazde zawiera nazwany podmiot i fakt. Test trzeci: skopiuj losowo 3 akapity do pustego dokumentu i przeczytaj – czy sa samodzielne bez reszty artykulu. Jesli ktorykolwiek akapit wymaga kontekstu z poprzedniego, przepisz go. W praktyce szybki audyt 4000-slowowego tekstu zajmuje 20-30 minut.
Co dalej
Zacznij od audytu najlepiej rankujacego artykulu – zmierz dlugosc akapitow, usun transitional filler, wprowadz 2-3 bloki FAQ i dodaj jedna tabele porownawcza. Zmiany wprowadzaj etapowo, monitorujac ruch z odesylan LLM w GA4. Szerszy kontekst strategiczny znajdziesz w przewodniku po strategii AIO i SEO, a zestaw narzedzi do pomiaru – w przegladzie narzedzi 2026.
