Chunking nie działa? 12 symptomów złej segmentacji dokumentów i jak ją naprawić testami

1. Wprowadzenie: dlaczego chunking decyduje o jakości RAG

W systemach RAG (Retrieval-Augmented Generation) jakość odpowiedzi rzadko zależy wyłącznie od „mocy” modelu. Najczęściej rozbija się o to, jakie fragmenty źródeł model dostaje w kontekście. A to z kolei jest wprost konsekwencją chunkingu, czyli sposobu segmentacji dokumentów na mniejsze części do indeksowania i wyszukiwania.

Chunking działa jak „sito” między dokumentami a modelem: determinuje, co w ogóle da się odnaleźć, jak precyzyjnie, w jakim sąsiedztwie informacji i z jaką liczbą fałszywych trafień. Nawet najlepsze embeddingi i najlepszy reranking nie uratują sytuacji, jeśli segmentacja rozrywa sens, miesza konteksty albo pakuje do jednego fragmentu zbyt wiele tematów.

W praktyce chunking wpływa na trzy krytyczne obszary jakości RAG:

• Retrieval (trafność wyszukiwania) – dobrze pocięte dokumenty tworzą fragmenty, które „pasują” do pytań użytkownika i dają się jednoznacznie skojarzyć z intencją. Złe cięcie sprawia, że wyszukiwarka zwraca fragmenty przypadkowe, zbyt ogólne albo pozbawione kluczowego zdania, które decyduje o odpowiedzi.
• Grounding (oparcie odpowiedzi na źródłach) – model generuje najpewniej, gdy widzi pełny, spójny dowód: definicję, warunek, wyjątek, limit, datę obowiązywania. Segmentacja, która rozdziela te elementy, prowadzi do odpowiedzi „prawie poprawnych”, bez zastrzeżeń i kontekstu.
• Koszt i stabilność – chunking bezpośrednio wpływa na liczbę fragmentów w indeksie, liczbę fragmentów w kontekście oraz powtarzalność treści. To przekłada się na koszty obliczeń, ryzyko przekroczenia okna kontekstu i skłonność modelu do konfuzji, gdy dostaje redundantne lub sprzeczne fragmenty.

Warto też rozróżnić dwa powiązane, ale różne cele segmentacji: podział do indeksowania (żeby wyszukiwarka mogła znaleźć właściwy kawałek) oraz podział do czytania przez model (żeby fragment był zrozumiały i samowystarczalny). Niekiedy najlepszy „retrieval chunk” nie jest najlepszym „reading chunk” i odwrotnie — a kompromis trzeba świadomie kontrolować.

Dlaczego więc czasem słyszysz, że „chunking nie działa”? Zwykle nie chodzi o to, że sama idea jest błędna, tylko o to, że segmentacja nie odpowiada strukturze dokumentów i typom pytań. Dokumenty mają nagłówki, listy, przypisy, tabele, definicje, wyjątki, cross-linki i „to zależy” ukryte w jednym zdaniu. Jeśli granice chunków przecinają te elementy w złym miejscu, RAG zaczyna zachowywać się tak, jakby źródła były niekompletne.

Dobry chunking to nie „jeden magiczny rozmiar”, ale praktyka projektowa: wyznaczanie granic tam, gdzie kończy się myśl, pilnowanie minimalnego kontekstu oraz kontrolowanie tego, co dzieje się na styku sąsiadujących fragmentów. Efekt końcowy jest prosty do opisania: model częściej widzi dokładnie to, czego potrzebuje, a rzadziej musi zgadywać.

12 symptomów złej segmentacji: jak rozpoznać problemy w praktyce

Jeśli RAG „niby działa”, ale odpowiedzi są chwiejne, niespójne lub zaskakująco ogólne, bardzo często problem nie leży w modelu ani w samym wyszukiwaniu, tylko w tym, jak dokumenty zostały pocięte na fragmenty. Zła segmentacja potrafi ukryć kluczowe informacje w nieczytelnych kawałkach, rozbić definicje od kontekstu albo połączyć kilka tematów w jeden fragment, przez co retriever nie trafia w sedno. Podczas szkoleń Cognity ten temat wraca regularnie – dlatego zdecydowaliśmy się go omówić również tutaj. Poniżej znajdziesz 12 symptomów, które najczęściej widać w praktyce — w logach, w podglądzie zwracanych źródeł i w zachowaniu odpowiedzi.

• 1) Model odpowiada poprawnie „ogólnie”, ale nie trafia w konkret z dokumentu
  Jak to wygląda: odpowiedź jest sensowna, lecz bez liczb, warunków, wyjątków i cytowalnych szczegółów, mimo że dokument je zawiera.
  Co to sugeruje: istotne zdania są rozproszone między chunkami albo docinane tak, że nie tworzą samodzielnej jednostki znaczeniowej.
• 2) Źródła są „prawie” o tym samym, ale brakuje kluczowego akapitu
  Jak to wygląda: zwrócone fragmenty są z właściwego rozdziału, ale nie zawierają dokładnie tej definicji/procedury, o którą pyta użytkownik.
  Co to sugeruje: granice chunków omijają istotne akapity albo wyszukiwarka nie potrafi ich wyróżnić, bo fragment ma zbyt dużo pobocznej treści.
• 3) Odpowiedzi są wewnętrznie sprzeczne lub „zmieniają zdanie” w kolejnych pytaniach
  Jak to wygląda: na podobne pytania system raz podaje wersję A, raz B, bo raz trafia na inny fragment tego samego tematu.
  Co to sugeruje: informacje o jednym pojęciu są rozbite na wiele chunków, a każdy z nich wygląda jak kompletna prawda, choć jest tylko wycinkiem (np. wyjątek jest w innym fragmencie).
• 4) Model powołuje się na nieadekwatny kontekst (np. inny produkt, region, wersję)
  Jak to wygląda: odpowiedź jest merytoryczna, ale dotyczy „złego wariantu” — np. innego planu, cennika, kraju, wersji regulaminu.
  Co to sugeruje: chunk miesza kilka wariantów w jednym fragmencie albo brakuje sygnałów pozwalających odróżnić warianty (np. rozdzielonych sekcji lub czytelnych nagłówków w chunkach).
• 5) W wynikach retrieval powtarzają się bardzo podobne fragmenty
  Jak to wygląda: top-k to kilka niemal identycznych chunków, a „różnorodność” źródeł spada.
  Co to sugeruje: segmentacja generuje duplikaty (np. przez złe overlap) albo sztucznie rozbija ten sam akapit na wiele, przez co retriever „marnuje” miejsca na powtórzenia.
• 6) Fragmenty urywają zdania, listy i odwołania
  Jak to wygląda: chunk zaczyna się od połowy zdania, ma niedomkniętą listę, brakuje początku definicji albo końca procedury.
  Co to sugeruje: cięcie po stałej liczbie znaków/tokenów bez respektowania struktury tekstu lub błędy ekstrakcji (np. z PDF), które rozbijają akapity.
• 7) W chunkach jest dużo „szumu”: stopki, nagłówki stron, nawigacja, powtarzalne elementy
  Jak to wygląda: w źródłach pojawiają się numery stron, copyright, menu, breadcrumb, linki „następna strona”.
  Co to sugeruje: segmentacja nie została poprzedzona czyszczeniem i normalizacją treści albo chunking wciąga elementy layoutu jako treść merytoryczną.
• 8) Najlepsze wyniki są zbyt długie i „o wszystkim”, a odpowiedź gubi wątek
  Jak to wygląda: chunk zawiera kilka tematów; model cytuje losowy fragment, pomija istotną część, generuje dygresje.
  Co to sugeruje: chunk jest za duży lub obejmuje wiele sekcji naraz, przez co sygnał semantyczny jest rozmyty, a generacja ma zbyt szeroki kontekst.
• 9) Najlepsze wyniki są zbyt krótkie i nie dają się wykorzystać bez sąsiednich fragmentów
  Jak to wygląda: zwracany chunk to pojedyncze zdanie bez definicji, bez warunków brzegowych, bez „co to znaczy w praktyce”.
  Co to sugeruje: chunk jest za mały; kontekst nie mieści się w jednym fragmencie, a system nie potrafi stabilnie dobrać sąsiednich części.
• 10) Retrieval trafia w „złe miejsce” przez słowa-klucze w nagłówkach lub spisie treści
  Jak to wygląda: w źródłach pojawia się spis treści, indeks albo nagłówek rozdziału, ale bez właściwej treści, której dotyczy pytanie.
  Co to sugeruje: segmentacja traktuje elementy strukturalne jak pełnoprawną treść i tworzy z nich chunki, które są łatwe do znalezienia, ale mało użyteczne.
• 11) Źródła są „dobre”, a mimo to odpowiedź jest błędna lub wymijająca
  Jak to wygląda: użytkownik widzi, że w zwróconym fragmencie jest potrzebna informacja, ale model jej nie wykorzystuje albo interpretuje opacznie.
  Co to sugeruje: chunk zawiera sprzeczne lub rozproszone stwierdzenia (np. zasada + wyjątek w różnych częściach), albo kluczowe zdanie jest ukryte wśród wielu pobocznych treści.
• 12) Duża wrażliwość na drobne zmiany pytania
  Jak to wygląda: minimalna parafraza sprawia, że system zwraca zupełnie inne źródła, a odpowiedź zmienia jakość skokowo.
  Co to sugeruje: fragmenty nie są stabilnymi jednostkami znaczeniowymi; wyszukiwanie „łapie” przypadkowe dopasowania, bo granice chunków nie pokrywają się z naturalnymi segmentami informacji.

Jeżeli rozpoznajesz kilka z powyższych symptomów naraz, to dobry sygnał, że warto przestać oceniać RAG wyłącznie po „jakości odpowiedzi” i zacząć patrzeć na to, jakie dokładnie chunki wracają, czy są użyteczne samodzielnie oraz czy niosą właściwy kontekst bez nadmiaru szumu.

3. Strategie segmentacji: nagłówki i struktura dokumentu, semantyka, overlap, okna i metadane

Nie ma jednej „najlepszej” metody chunkingu. Dobra segmentacja to zestaw decyzji: skąd brać granice chunków, jak kontrolować ich długość, ile kontekstu powtarzać oraz jakie metadane dołączyć, by wyszukiwanie i odpowiedzi były stabilne. Poniżej najczęściej stosowane strategie i ich typowe zastosowania.

3.1. Segmentacja po strukturze dokumentu (nagłówki, akapity, listy)

Najbardziej naturalne podejście: kroisz dokument według istniejącej struktury (H1–H6, sekcje, akapity, punkty list). To zwykle daje chunki, które „trzymają temat” i są łatwe do cytowania.

• Kiedy działa najlepiej: dokumentacja techniczna, regulaminy, artykuły z wyraźną hierarchią, wiki z poprawną strukturą.
• Ryzyka: nierówne rozmiary (za długie sekcje), źle wyekstrahowane nagłówki (np. PDF), sekcje „kombajny” z wieloma tematami.
• Praktyka: często łączy się granice strukturalne z limitem długości (np. docinanie długich sekcji na mniejsze podchunki).

3.2. Segmentacja semantyczna (wg znaczenia, nie formatowania)

Gdy struktura jest słaba lub myląca, lepiej dzielić tekst według zmiany wątku: grupować zdania, które opisują jeden koncept, definicję, procedurę albo warunek.

• Kiedy działa najlepiej: surowe transkrypcje, notatki, zlepione HTML, teksty po OCR, długie sekcje bez nagłówków.
• Ryzyka: większa złożoność i zmienność wyników; semantyka może „przestrzelić” i rozciąć fragment, który użytkownik chciałby mieć razem (np. definicja + wyjątki + przykład).
• Praktyka: semantyczne granice zwykle stabilizuje się limitami długości oraz minimalną wielkością chunka.

3.3. Overlap (nakładanie) – kontrolowany „bufor kontekstu”

Overlap to powtarzanie fragmentu na granicy chunków, aby kluczowe zdania nie „uciekały” między segmentami. To kompromis między ciągłością kontekstu a redundancją w indeksie.

• Po co: pytania często zahaczają o granice (np. nagłówek w jednym chunku, szczegóły w następnym).
• Skutki uboczne: większy koszt indeksowania i ryzyko, że wyniki będą zbyt podobne do siebie (duplikaty w top-k).
• Wskazówka: overlap ma sens szczególnie w segmentacji czysto „po znakach/tokenach”; przy chunkach strukturalnych często można go zmniejszać.

3.4. Okna (sliding windows) i segmentacja stałej długości

Najprostsza technicznie metoda: dzielisz na fragmenty o stałej długości (np. N tokenów) i ewentualnie przesuwasz okno z overlapem. Jest odporna na chaos formatowania, ale ignoruje znaczenie.

• Kiedy używać: jako baseline, przy danych „brudnych”, do szybkiego prototypu, gdy ekstrakcja struktury jest zawodna.
• Ryzyka: cięcie w środku definicji, tabeli, listy kroków; trudniejsze cytowanie; większa zależność jakości od doboru N i overlapu.
• Praktyka: często łączy się z prostą heurystyką „nie tnij w środku akapitu/zdania”, aby poprawić spójność.

3.5. Metadane: co dołączyć do chunka, by ułatwić retrieval

Nawet idealnie pocięte fragmenty mogą przegrywać w wyszukiwaniu, jeśli tracą kontekst dokumentu. Metadane pozwalają „dopowiedzieć” skąd pochodzi chunk i jak go użyć.

• Metadane źródłowe: identyfikator dokumentu, URL/ścieżka, wersja, data, język.
• Metadane strukturalne: tytuł dokumentu, ścieżka nagłówków (np. H1>H2>H3), numer sekcji, pozycja w dokumencie.
• Metadane użytkowe: typ treści (FAQ/procedura/polityka), tagi domenowe, uprawnienia/visibility (ważne przy filtrach).
• Praktyka: część metadanych warto także wstrzyknąć do treści chunka (np. nagłówek sekcji), jeśli model ma z tego korzystać bez polegania na filtrach.

3.6. Kiedy którą strategię wybrać? (szybkie porównanie)

3.7. Minimalny wzorzec implementacyjny (bez wchodzenia w szczegóły)

W praktyce najczęściej wygrywa hybryda: struktura → limity długości → opcjonalny overlap → metadane. Poniższy szkic pokazuje ideę, nie pełny pipeline:

// 1) wyodrębnij sekcje po strukturze (nagłówki/akapity)
sections = parseStructure(document)

// 2) długie sekcje dotnij do rozsądnej długości
chunks = splitByLength(sections, maxTokens)

// 3) dodaj kontrolowany overlap na granicach
chunks = addOverlap(chunks, overlapTokens)

// 4) dołącz metadane (źródło, ścieżka nagłówków, pozycja)
chunks = attachMetadata(chunks, {
  docId, url, title, headingPath, sectionIndex
})

4. Automatyczne testy jakości chunków: coverage, redundancy i retrieval sanity checks

Chunking warto traktować jak komponent, który podlega testom automatycznym: jeśli segmentacja jest „prawie dobra”, to w RAG potrafi regularnie psuć wyniki w sposób trudny do zauważenia na pojedynczych przykładach. Zamiast polegać na ręcznym przeglądzie kilku chunków, zbuduj zestaw prostych testów jakości, które uruchamiasz przy każdej zmianie parsera, reguł segmentacji, overlapu, czyszczenia tekstu czy metadanych. Doświadczenie Cognity pokazuje, że rozwiązanie tego problemu przynosi szybkie i zauważalne efekty w codziennej pracy.

W praktyce testy dzielą się na trzy grupy:

• Coverage – czy informacje z dokumentów faktycznie „lądują” w chunkach i dają się odnaleźć?
• Redundancy – czy nie duplikujesz tej samej treści w nadmiarze (koszt i szum)?
• Retrieval sanity checks – czy wyszukiwanie zwraca rozsądne fragmenty dla typowych zapytań?

4.1. Coverage: czy segmentacja nie gubi treści

Testy coverage wykrywają sytuacje, w których:

• część tekstu znika w wyniku czyszczenia/parsowania (np. tabele, listy, nagłówki),
• granice chunków „przecinają” kluczowe definicje i zależności,
• metadane nie są przenoszone do indeksu (np. tytuł, rozdział, identyfikator źródła),
• chunkowanie tworzy fragmenty zbyt krótkie lub zbyt długie, przez co treść staje się trudniej odzyskiwalna.

Minimalny zestaw metryk coverage (do CI lub jako nightly job):

• Text retention: stosunek liczby znaków/słów po chunkingu do liczby znaków/słów po ekstrakcji z dokumentu (przed chunkingiem). Duże spadki to alarm.
• Anchor coverage: zdefiniuj „kotwice” (krótkie frazy/ID/numery punktów), które muszą pojawić się w co najmniej jednym chunku. Braki oznaczają utratę lub złą normalizację.
• Metadata coverage: odsetek chunków z wymaganymi polami (np. source_url, doc_id, section_path). Braki utrudniają debug i filtrowanie.

4.2. Redundancy: czy overlap i reguły nie produkują szumu

Redundancy testuje, czy chunking nie tworzy „inflacji” treści: wiele niemal identycznych chunków, powtarzające się nagłówki/stopki, lub powielone definicje przez zbyt agresywny overlap. Skutki są podwójne: rosną koszty indeksowania i retrieval częściej zwraca duplikaty zamiast uzupełniających się fragmentów.

Proste metryki redundancy:

• Duplicate ratio: odsetek chunków identycznych (po normalizacji whitespace/case). Nawet niewielki procent może oznaczać błąd w pipeline.
• Near-duplicate ratio: odsetek par chunków o bardzo wysokim podobieństwie (np. Jaccard na shingles lub cosine na embeddingach). Służy do wykrywania „prawie tych samych” fragmentów.
• Header/footer repetition: częstość występowania tych samych krótkich fraz w wielu chunkach (np. nazwy stron, stopki PDF). To sygnał, że czyszczenie nie działa.

4.3. Retrieval sanity checks: szybkie testy „czy to ma sens”

To testy czarnoskrzynkowe, które uruchamiasz na zbudowanym indeksie: podajesz zapytania i sprawdzasz, czy top-N wyników wygląda wiarygodnie. Nie zastępują pełnej ewaluacji RAG, ale świetnie łapią regresje po zmianach chunkingu.

Jak je konstruować, bez rozbudowanej infrastruktury:

• Przygotuj mały zestaw zapytań reprezentujących typowe potrzeby (definicje, procedury, wyjątki, limity, porównania).
• Dla każdego zapytania zapisz oczekiwane źródło (doc_id/sekcja) albo przynajmniej listę kotwic, które powinny pojawić się w top wynikach.
• Weryfikuj, czy w top-N jest przynajmniej jeden chunk z właściwego dokumentu/sekcji oraz czy wyniki nie są zdominowane przez duplikaty.

Przykładowe asercje sanity check (celowo proste):

• Hit@N (source): czy w top-5/top-10 pojawia się chunk z oczekiwanego doc_id?
• Section coherence: czy top wyniki pochodzą z jednej sensownej okolicy dokumentu, a nie z przypadkowych rozdziałów?
• Diversity: czy w top-N nie ma nadmiernej liczby wyników prawie identycznych (sygnał złej redundancji)?
• Anchor presence: czy w wynikach pojawia się fraza-kotwica, która jednoznacznie wskazuje, że retrieval trafił w temat?

# Pseudokod: minimalny retrieval sanity check
# inputs: queries[], index.search(q, k), expected_doc_ids[q]

failures = []
for q in queries:
  results = index.search(q, k=10)  # zwraca listę {text, doc_id, section_path}
  hit = any(r.doc_id in expected_doc_ids[q] for r in results)
  if not hit:
    failures.append({"query": q, "reason": "no expected source in top10"})

assert len(failures) == 0

4.4. Jak spiąć to w praktyce: szybki „pakiet testów” dla chunkingu

Żeby testy były użyteczne, muszą być tanie i powtarzalne. Najczęściej wystarczy uruchamiać je na stałej próbce dokumentów (np. kilkadziesiąt–kilkaset), a nie na całej bazie.

• Testy jednostkowe: parsowanie → chunkowanie → walidacje (retention, metadane, rozkład długości chunków).
• Testy na próbce indeksu: budowa małego indeksu i sanity checks (Hit@N, diversity, anchor presence).
• Progi i alerty: ustal progi akceptacji (np. minimalny retention, maksymalny duplicate ratio) i traktuj ich przekroczenie jako regresję.

Najważniejsze: te testy nie mają „udowodnić”, że chunking jest idealny. Mają szybko wykrywać utratę treści, nadmiarową duplikację oraz oczywiste przypadki, w których retrieval przestaje trafiać w właściwe fragmenty.

5. Proces iteracji i strojenia: od hipotezy do poprawki (pipeline, logi, regresje)

Chunking rzadko „działa” od razu, bo jest elementem łańcucha zależności: źródło → ekstrakcja tekstu → segmentacja → embeddingi → indeks → retrieval → kontekst → odpowiedź. Dlatego strojenie trzeba prowadzić jak iterację inżynierską: stawiasz hipotezę o przyczynie problemu, wprowadzasz małą zmianę, mierzysz efekt na stałym zestawie zapytań i pilnujesz, by nie popsuć innych przypadków (regresje).

5.1. Minimalny pipeline iteracyjny (bez nadmiaru)

• Zdefiniuj cel: co ma się poprawić (trafność, kompletność odpowiedzi, stabilność, koszt/tokeny), a co nie może ucierpieć.
• Ustal stały zestaw testowy: kilka–kilkadziesiąt reprezentatywnych pytań i oczekiwane źródła (niekoniecznie idealne odpowiedzi końcowe).
• Wybierz jeden „pokrętło” na raz: np. granice chunków, overlap, respektowanie nagłówków, łączenie krótkich akapitów, metadane.
• Uruchom porównanie A/B: stara konfiguracja vs nowa, na tym samym korpusie i tych samych zapytaniach.
• Oceń i zdecyduj: jeśli poprawa jest istotna, promujesz zmianę; jeśli nie, cofasz i formułujesz kolejną hipotezę.

Kluczowe jest utrzymanie powtarzalności: ta sama wersja danych wejściowych, ten sam sposób embedowania, ten sam indeks (albo jednoznacznie wersjonowany).

5.2. Hipotezy → typowe poprawki (mapa decyzji)

Gdy retrieval „nie trafia”, intuicyjnie kusi zmiana modelu. W praktyce często szybciej i taniej jest naprawić segmentację. Poniżej prosta mapa: objaw → hipoteza → kierunek poprawki (bez wchodzenia w implementacyjne detale).

5.3. Logi, które realnie pomagają (i co w nich zapisywać)

Bez logów iteracja zamienia się w zgadywanie. Wystarczą proste, ale konsekwentne rekordy na poziomie: dokument → chunk → retrieval → odpowiedź.

• Rejestr chunków: doc_id, chunk_id, liczba znaków/tokenów, offset (start/koniec), ścieżka nagłówków, hash treści (do wykrywania duplikatów).
• Rejestr retrieval dla każdego zapytania: parametry wyszukiwania (top_k, filtrowanie), lista zwróconych chunk_id z wynikami (score/rank), informacja czy pojawił się „oczekiwany” fragment.
• Rejestr kontekstu: ile tokenów weszło do promptu, ile ucięto, które chunky zostały odrzucone przez limit.
• Artefakty do debug: podgląd 2–3 najlepszych chunków wraz z nagłówkami i sąsiednimi fragmentami (łatwiej zobaczyć złą granicę).

W praktyce najwięcej czasu oszczędza możliwość odpowiedzi na pytania: „który chunk był #1?”, „czy w ogóle istnieje chunk z potrzebną informacją?”, „czy informacja została ucięta?”.

5.4. Regresje: jak nie psuć tego, co działa

Zmiana chunkingu potrafi poprawić jeden typ pytań i równocześnie zepsuć inny (np. mniejsze chunky pomagają w precyzji, ale pogarszają pytania wymagające szerszego kontekstu). Dlatego potrzebujesz lekkiej „siatki bezpieczeństwa”:

• Zestaw regresyjny: mała pula krytycznych zapytań (te, które muszą działać zawsze) oraz kilka „trudnych” przypadków granicznych.
• Porównanie rozkładów: zamiast patrzeć tylko na średnią, sprawdzaj, czy nie rośnie liczba zapytań z całkowitą porażką retrieval (brak trafnych chunków w top-k).
• Kontrola kosztu: tokeny kontekstu i liczba chunków w indeksie po zmianie (strojenie nie może po cichu podwoić kosztów).
• Wersjonowanie: wersja konfiguracji chunkingu i wersja danych muszą być zapisywane razem z wynikami testów, inaczej nie da się odtworzyć wniosków.

5.5. Rytm pracy: małe kroki, szybka pętla feedbacku

Najlepsze efekty daje powtarzalny rytm: 1) diagnoza na logach → 2) hipoteza → 3) minimalna zmiana → 4) A/B na zestawie testowym → 5) decyzja + zapis wniosków. Dzięki temu chunking przestaje być „sztuką”, a staje się kontrolowanym procesem, w którym każda poprawka ma uzasadnienie i mierzalny efekt.

# Szkic: format wpisu z porównania A/B (przykładowa struktura)
{
  "run_id": "2026-03-24_chunking_v7",
  "chunking_config": {"strategy": "structure+overlap", "overlap": 80},
  "query_id": "Q12",
  "expected_doc_ids": ["doc_45"],
  "retrieved": [
    {"chunk_id": "doc_45:17", "rank": 1, "score": 0.62},
    {"chunk_id": "doc_12:03", "rank": 2, "score": 0.58}
  ],
  "context_tokens": 1420,
  "passed": true
}

6. Checklista diagnostyczna: szybki audyt chunkingu przed wdrożeniem

Ta checklista ma pomóc w szybkiej ocenie, czy segmentacja dokumentów (chunking) jest wystarczająco dobra do produkcyjnego RAG. Nie wchodzi w implementacyjne detale ani dobór parametrów; skupia się na tym, co sprawdzić i jakim sygnałem rozpoznać ryzyko.

6.1. Dane wejściowe: czy w ogóle tniemy właściwy tekst?

• Ekstrakcja tekstu: czy z PDF/HTML/Word nie znikają fragmenty (tabele, listy, przypisy), a kolejność akapitów jest sensowna?
• Czystość: czy nie ma śmieci typu powtarzające się nagłówki/stopki stron, numery stron, artefakty OCR, podwójne spacje, urwane słowa?
• Język i kodowanie: czy polskie znaki i znaki specjalne są poprawne, a tokenizacja nie „rozsypuje” tekstu?
• Duplikaty dokumentów: czy w indeksie nie lądują te same dokumenty w kilku wariantach (np. PDF + HTML), zwiększając szum?

6.2. Granice chunków: czy segmentacja szanuje strukturę?

• Nagłówki: czy chunk nie zaczyna się/kończy w połowie nagłówka, numeracji sekcji lub podpisu tabeli?
• Jednostki znaczeniowe: czy definicje, kroki procedury i warunki (np. „jeśli… to…”) nie są rozcięte na dwie części bez kontekstu?
• Listy i tabele: czy elementy listy nie są rozdzielone tak, że tracą odniesienie do wprowadzenia; czy wiersze tabel nie są poszatkowane losowo?
• Cytowania i odwołania: czy fragmenty „patrz rozdział X” mają w chunkach kontekst, który pozwala je zrozumieć?

6.3. Rozmiar i „gęstość” informacji: czy chunk jest użyteczny w retrievalu?

• Za małe chunky: czy nie wyglądają jak pojedyncze zdania/linie, przez co tracą kontekst i zwiększają liczbę trafień „prawie pasujących”?
• Za duże chunky: czy nie są tak długie, że mieszają różne tematy i obniżają precyzję dopasowania?
• Spójność tematyczna: czy w jednym chunku nie ma kilku niepowiązanych wątków (np. definicja + cennik + instrukcja)?
• Stosunek treści do szumu: czy większość znaków to rzeczywista treść, a nie nawigacja, menu, stopki, boilerplate?

6.4. Overlap i „ciągłość” kontekstu: czy informacje nie urywają się na krawędziach?

• Urywające się zdania: czy nie ma częstych sytuacji, gdzie pierwsze/ostatnie zdanie chunku jest ewidentnie niedokończone?
• Brak mostków kontekstowych: czy chunk zawiera minimalny kontekst (np. definicję pojęcia), czy tylko „środek” rozważań?
• Nadmierne powtórzenia: czy overlap nie powoduje, że wiele chunków jest niemal identycznych, przez co retrieval zwraca duplikaty?

6.5. Metadane i identyfikowalność: czy da się wskazać źródło i fragment?

• Identyfikator źródła: czy każdy chunk ma stabilne document_id i wersję dokumentu?
• Lokalizacja: czy da się odtworzyć miejsce w dokumencie (sekcja/rozdział, strona, offset, URL z kotwicą)?
• Tytuły i ścieżka nagłówków: czy chunk niesie ze sobą kontekst strukturalny (np. „Rozdział > Podrozdział”)?
• Uprawnienia: czy metadane pozwalają filtrować retrieval zgodnie z ACL (żeby model nie widział nieautoryzowanej treści)?

6.6. Szybkie testy „na oko”: 15-minutowy audyt próbek

Przed automatyzacją warto zrobić krótki przegląd próbek. Wybierz losowo (i celowo) kilka dokumentów oraz trudne fragmenty (definicje, procedury, tabelki).

• Próbka losowa: przejrzyj 30–50 chunków z różnych dokumentów i oceń: spójność, kompletność, ilość śmieci.
• Próbka krytyczna: wybierz 10 pytań, które system ma obsłużyć, i sprawdź czy odpowiednie chunky są „logicznie wycinane”.
• „Czy ja bym to zacytował?”: czy chunk nadaje się do wklejenia jako cytat/źródło bez dodatkowych dopowiedzeń?

6.7. Szybkie testy retrieval: minimalne sanity-checki

• Top-k bez zaskoczeń: dla kilku typowych zapytań top-3/top-5 powinno zawierać fragmenty wyraźnie związane z pytaniem (bez dominacji stopki, menu, spisu treści).
• Różnorodność wyników: czy wyniki nie są klonami tego samego chunku (problem nadmiernej redundancji)?
• Stabilność: czy drobna zmiana zapytania (synonim, odmiana) nie powoduje całkowitej utraty trafień?
• Filtry: czy filtrowanie po metadanych działa i nie „przecieka” między domenami/tenantami?

6.8. Tabela: szybka interpretacja wyników audytu

6.9. Minimalny zestaw kryteriów „go/no-go” przed wdrożeniem

• Go, jeśli: próbki chunków są spójne i czytelne, retrieval zwraca trafne fragmenty bez dominacji boilerplate, a metadane pozwalają wskazać źródło i zastosować filtry dostępu.
• No-go, jeśli: widzisz masowy szum z ekstrakcji, częste urywanie myśli na granicach chunków, duże duplikowanie wyników lub brak możliwości odtworzenia pochodzenia fragmentu.

// Mini-check do logów: co warto wypisać dla 1 requestu
// (nie implementacja testów, tylko szybki podgląd diagnostyczny)
{
  "query": "...",
  "top_k": [
    {
      "doc_id": "...",
      "chunk_id": "...",
      "section_path": "...",
      "score": 0.0,
      "preview": "pierwsze ~200 znaków..."
    }
  ]
}

7. Przykładowe przypadki i pułapki: PDF, HTML, wiki (oraz jak je naprawić)

W praktyce „chunking” psuje się najczęściej nie przez sam algorytm dzielenia tekstu, tylko przez źródło: inny typ dokumentu oznacza inną strukturę, inne artefakty ekstrakcji i inne oczekiwania użytkownika. PDF bywa wizualny i „poszatkowany” w tekście, HTML ma gniazdową hierarchię i dużo szumu nawigacyjnego, a wiki dokłada szablony, transkluzje i niejednoznaczne granice sekcji. Poniżej najczęstsze pułapki oraz proste kierunki naprawy, które zwykle dają największy zwrot.

PDF: układ graficzny udaje strukturę

PDF-y są projektowane do czytania oczami, a nie do przetwarzania tekstowego. Ekstrakcja często miesza kolejność, gubi nagłówki, rozrywa zdania i skleja elementy z różnych kolumn. W efekcie segmentacja oparta wyłącznie na długości znaków tworzy chunki, które wyglądają „poprawnie”, ale semantycznie są przypadkowe.

• Pułapka: wielokolumnowy układ i zła kolejność czytania. Tekst z lewej i prawej kolumny miesza się, a chunk zaczyna się w środku myśli i kończy w innym wątku.
  Jak naprawić: preferuj ekstrakcję z zachowaniem kolejności bloków (layout-aware), rozważ OCR dla skanów i weryfikuj, czy kolejność akapitów jest zgodna z wizualną.
• Pułapka: nagłówki, stopki, numery stron i powtarzalne elementy. Trafiają do każdego chunku, zwiększając szum i „podobieństwo” embeddingów między stronami.
  Jak naprawić: filtruj elementy powtarzalne (nagłówki/stopki), usuwaj numerację stron, normalizuj znaki i białe spacje zanim zaczniesz dzielić tekst.
• Pułapka: tabele, przypisy, listy i łamanie wyrazów. Treść tabel bywa „wciągnięta” liniowo, przypisy rozrywają zdania, a dzielenie wyrazów na końcu wiersza generuje śmieciowe tokeny.
  Jak naprawić: wykrywaj i traktuj osobno tabele (często jako osobne segmenty), sklejaj wyrazy dzielone dywizem, separuj przypisy od głównej narracji.
• Pułapka: skany i błędy OCR. Literówki i brak znaków interpunkcyjnych psują embeddingi i granice segmentów.
  Jak naprawić: stosuj korekty OCR (choćby podstawowe), normalizuj znaki, a dokumenty o niskiej jakości OCR oznaczaj metadanymi do ostrożniejszego użycia w odpowiedziach.

HTML: hierarchia jest, ale łatwo ją zgubić

HTML ma naturalną strukturę (nagłówki, sekcje, listy), ale bywa też pełen elementów nienależących do treści: menu, stopki, panele „polecane”, komentarze czy breadcrumbs. Jeśli do chunkingu trafia „goły tekst” bez kontekstu DOM, segmentacja zaczyna łączyć fragmenty z różnych części strony.

• Pułapka: szum nawigacyjny i elementy szablonu. Menu, stopki, cookie banner, „powiązane artykuły” i sidebar wchodzą do indeksu i dominują wyniki.
  Jak naprawić: ekstrahuj treść z głównego kontenera (main/article), odrzucaj typowe sekcje layoutu, wycinaj elementy powtarzalne na poziomie całej domeny.
• Pułapka: utrata nagłówków i granic sekcji. Po konwersji do tekstu znikają poziomy H1/H2/H3, a chunk nie niesie informacji „o czym jest”.
  Jak naprawić: zachowuj nagłówki jako część treści chunku lub jako metadane; pilnuj, by segmenty nie przecinały akapitów i list bez potrzeby.
• Pułapka: strony długie, z powtarzalnymi komponentami (FAQ, akordeony). Treści w akordeonach mogą być ukryte, zdublowane lub wczytywane dynamicznie.
  Jak naprawić: renderuj stronę w sposób zbliżony do przeglądarki, a treści interaktywne traktuj jako osobne podsekcje.
• Pułapka: fragmenty wyrwane z kontekstu (listy, definicje, ostrzeżenia). Sama lista punktów bez wprowadzenia staje się niejednoznaczna w RAG.
  Jak naprawić: dołączaj krótkie „kotwice kontekstu” (np. nagłówek sekcji i zdanie wprowadzające) do segmentów z listami i calloutami.

Wiki i dokumentacja: dużo logiki „w treści”

Wiki (w tym systemy oparte o składnię wiki lub MD) często mają bogatą strukturę, ale też mechanizmy, które komplikują ekstrakcję: szablony, transkluzje, sekcje generowane automatycznie, kategorie, infoboksy czy liczne odnośniki. Chunking musi tu uwzględniać, że część „tekstu” to metadane, a część kontekstu jest rozproszona.

• Pułapka: szablony i transkluzje mieszają porządek treści. Fragmenty wstawiane z innych stron tworzą segmenty, które semantycznie należą gdzie indziej.
  Jak naprawić: jeśli to możliwe, indeksuj treść po renderowaniu (po złożeniu transkluzji), a źródła transkluzji zapisuj jako metadane, by zachować pochodzenie.
• Pułapka: infoboksy, kategorie, „See also”, bibliografia. Zbyt łatwo dominują w wynikach wyszukiwania, mimo że rzadko odpowiadają na pytania użytkownika.
  Jak naprawić: traktuj je jako osobne typy bloków i indeksuj selektywnie; bibliografię i kategorie często lepiej pominąć albo odseparować.
• Pułapka: intensywne linkowanie i krótkie sekcje. Sekcje typu „W skrócie” lub pojedyncze zdania tworzą mikrochunki, które nie niosą wystarczającego kontekstu.
  Jak naprawić: łącz bardzo krótkie sekcje z sąsiadami w obrębie tej samej strony; zachowuj tytuły sekcji, a linki normalizuj (np. usuwaj nadmiar kotwic w tekście).
• Pułapka: wersjonowanie i duplikaty treści. Ta sama instrukcja występuje w kilku wersjach stron lub gałęziach dokumentacji, co prowadzi do sprzecznych kontekstów w RAG.
  Jak naprawić: oznacz wersję jako metadane i filtruj ją w retrievalu; wykrywaj duplikaty na poziomie bloków i ograniczaj indeksowanie powtórzeń.

Wspólny mianownik: napraw najpierw „wejście”, potem granice

Jeśli segmentacja „nie działa” dla PDF/HTML/wiki, najczęściej oznacza to, że pipeline pozyskania tekstu dostarcza treści zniekształcone, zaszumione lub pozbawione struktury. Dopiero po usunięciu szumu, zachowaniu nagłówków i rozdzieleniu bloków specjalnych (tabele, nawigacja, infoboksy) ma sens oceniać długości chunków i granice cięcia. W przeciwnym razie nawet dobrze dobrane parametry będą stabilnie produkować złe segmenty — tylko szybciej.

Strategia 7: Routing modeli i adaptacyjne budżetowanie – wybór tańszych modeli, fallbacki i mierzenie oszczędności

Jeśli masz wrażenie, że „chunking nie działa”, problemem bywa nie tylko segmentacja dokumentów, ale też to, kto (jaki model) i za ile próbuje te chunki zrozumieć. W praktyce jakość odpowiedzi w RAG jest wypadkową: jakości chunków, skuteczności retrievalu oraz zdolności modelu do syntezy i wnioskowania. Routing modeli i adaptacyjne budżetowanie to podejście, które pomaga utrzymać jakość, jednocześnie ograniczając koszty i opóźnienia — bez „karania” każdego zapytania najdroższym modelem.

Istota strategii polega na tym, że nie każde pytanie wymaga tego samego poziomu „mocy”. Proste, faktograficzne zapytania o pojedynczy fragment dokumentu mogą być obsłużone przez tańszy model, natomiast złożone przypadki (wielodokumentowe, z konfliktami w źródłach, wymagające precyzyjnych cytowań) powinny automatycznie trafiać do modelu mocniejszego. Kluczowe jest, by routing był sterowany sygnałami płynącymi z retrievalu i z diagnostyki odpowiedzi.

• Routing – wybór ścieżki przetwarzania (tańszy vs mocniejszy model) na podstawie cech zapytania i kontekstu.
• Adaptacyjne budżetowanie – dynamiczne dobieranie limitów (np. liczby chunków, długości kontekstu, „dokładności” odpowiedzi) do realnej trudności zadania.
• Fallback – bezpieczny mechanizm eskalacji: gdy tańsza ścieżka nie spełnia kryteriów jakości, system ponawia próbę mocniejszym wariantem.

To podejście jest szczególnie ważne przy diagnozie chunkingu, bo pozwala odróżnić dwa scenariusze: (1) segmentacja i retrieval są w porządku, ale model jest zbyt słaby, by poprawnie zsyntetyzować odpowiedź; (2) model jest wystarczający, ale retrieval dostarcza nieadekwatne lub zbyt rozproszone chunki. Dobrze zaprojektowany routing sprawia, że „awarie” chunkingu nie są maskowane kosztem, ale też nie windują kosztów dla wszystkich zapytań.

Jak dobierać tańsze modele bez utraty jakości

Podstawowa zasada: tańszy model powinien obsługiwać te przypadki, w których decyzja i treść odpowiedzi są lokalne (oparte na jednym lub dwóch spójnych chunkach), a nie wymagają rozbudowanej syntezy. Zastosowania tańszej ścieżki to m.in. proste definicje, wyszukanie konkretu w regulaminie, odczyt wartości z opisu procedury, krótkie streszczenie pojedynczego fragmentu. W takich sytuacjach kluczowa jest nie „inteligencja”, lecz poprawne uziemienie w kontekście.

Droższy model warto rezerwować dla przypadków, gdy rośnie ryzyko błędu: zapytanie jest wieloetapowe, wymaga porównania źródeł, negocjowania sprzeczności, wyciągania wniosków z kilku sekcji dokumentów albo kiedy użytkownik oczekuje sformalizowanego, ostrożnego języka z precyzyjnymi zastrzeżeniami.

Fallbacki: kiedy eskalować i jak nie przepalać budżetu

Fallback to nie „plan B dla wszystkiego”, tylko kontrolowana eskalacja uruchamiana przez konkretne sygnały. Najczęstsze powody eskalacji to: niskie zaufanie do retrievalu (słabe dopasowanie, duży rozrzut tematyczny), niespójność odpowiedzi z kontekstem, brak pokrycia zapytania w dostarczonych chunkach albo przekroczenie tolerancji na halucynacje (np. odpowiedź pojawia się bez oparcia w źródłach).

Dobre fallbacki są oszczędne: zanim przełączysz model na droższy, możesz spróbować „tańszych” korekt w ramach tej samej ścieżki, takich jak zmiana liczby pobranych chunków, korekta parametrów retrievalu czy wymuszenie krótszej, bardziej cytującej odpowiedzi. Dopiero gdy to nie pomaga, eskalujesz model.

Mierzenie oszczędności i kosztu jakości

Routing ma sens tylko wtedy, gdy potrafisz policzyć zysk oraz upewnić się, że nie płacisz za niego spadkiem jakości. Minimalny zestaw miar powinien obejmować zarówno koszty, jak i skuteczność:

• Koszt jednostkowy na zapytanie (w podziale na ścieżki i typy zapytań) oraz trend w czasie.
• Odsetek eskalacji (ile spraw trafia do fallbacku) – zbyt wysoki sugeruje, że routing jest zbyt agresywny albo chunking/retrieval dostarcza zbyt słaby kontekst.
• Czas odpowiedzi (latencja) – routing powinien skracać medianę, ale pilnuj „ogona” (p95/p99), bo fallbacki go wydłużają.
• Miary jakości związane z RAG (np. zgodność z kontekstem, kompletność odpowiedzi, liczba odmów/niepewności) raportowane osobno dla ścieżki taniej i eskalowanej.

W kontekście diagnozy segmentacji szczególnie ważne jest rozdzielenie: „ile kosztuje ratowanie jakości” (eskalacje) od „ile kosztuje normalna praca” (tania ścieżka). Jeśli eskalacje rosną po zmianie chunkingu, to sygnał, że nowa segmentacja pogorszyła pokrycie lub spójność chunków — nawet jeśli średnia jakość odpowiedzi na oko wygląda podobnie.

Najczęstsze pułapki routingu w RAG

• Maskowanie problemów chunkingu: droższy model „domyśli się” braków, przez co błędy segmentacji nie wychodzą w testach, ale koszt rośnie w produkcji.
• Routing oparty wyłącznie na treści zapytania: bez sygnałów z retrievalu łatwo źle sklasyfikować trudność i eskalować niepotrzebnie.
• Brak kryteriów jakości dla fallbacku: eskalacja „na czuja” prowadzi do losowych kosztów i niestabilnej jakości.
• Zbyt agresywne cięcie kontekstu: adaptacyjne budżetowanie nie może obcinać kontekstu tak mocno, że retrieval traci szansę dostarczyć właściwe fragmenty.

Routing modeli i adaptacyjne budżetowanie traktuj jako warstwę sterowania, która pozwala utrzymać koszty w ryzach oraz szybciej zlokalizować, czy winny jest chunking, retrieval czy sam model. Dobrze ustawione progi eskalacji oraz mierzenie oszczędności „po ścieżkach” pomagają podejmować decyzje inżynierskie na podstawie danych, a nie intuicji. W Cognity łączymy teorię z praktyką – dlatego ten temat rozwijamy także w formie ćwiczeń na szkoleniach.

Jak czytać wykresy pudełkowe (boxplot) w raportach HR i finansów: interpretacja bez błędów 01 kwietnia 2026

RStudio: 10 trików w tidyverse, które skracają analizę o połowę (z przykładami) 30 marca 2026