Strategie chunkowania RAG: 7 metod w rankingu na danych retrieval (2026)

Strategie chunkowania RAG: 7 metod w rankingu na danych retrieval (2026)

Strategie chunkowania RAG decydują o tym, co Twój retriever jest w stanie znaleźć, zanim jeszcze padnie pierwsze zapytanie. W badaniu Chroma z lipca 2024 roku uruchomiono 472 zapytania na pięciu korpusach z modelem text-embedding-3-large, a wybrany splitter przesuwa recall o około pięć punktów: 86,7% dla zwykłego splittera tokenowego, 91,7% dla splittera opartego na GPT-4o, przy pięciu fragmentach pobieranych na zapytanie. Precision wahają się znacznie mocniej. W całym raporcie wynoszą od 1,5% do 8,0%, co sprawia, że wybór rozmiaru chunka to decyzja kosztowa przebrana za decyzję o jakości, a każdy poradnik z pierwszej strony SERP wymienia te same siedem metod, nie pokazując, która z nich lepiej odzyskuje dane.

Kluczowe wnioski

• Chunkowanie dzieli dokumenty przed embeddingiem; punkty podziału decydują, co retriever znajdzie, a czego nie.
• W badaniu Chroma z lipca 2024 (472 zapytania) recall wynosił od 86,7% do 91,7% dla zmierzonych splitterów.
• Precision zmienia się kilkukrotnie bardziej niż recall, więc rozmiar chunka to głównie decyzja o koszcie tokenów.
• Zacznij od 512 tokenów z 10% nakładania, a następnie dostrajaj na własnym zestawie ewaluacyjnym.

Którą strategię chunkowania RAG wybrać? (Ranking)

Dla większości zespołów pracujących na płaskim tekście rekurencyjne chunkowanie znakowe przy 512 tokenach z 10% nakładania jest właściwym domyślnym wyborem. Respektuje granice akapitów i zdań, nie kosztuje nic dodatkowego, a w benchmarku Chroma (472 zapytania) straciło tylko 3,2 punktu recall do splittera opartego na LLM. Odejdź od niego tylko wtedy, gdy Twoje dokumenty mają silną strukturę lub Twój zestaw ewaluacyjny dowodzi czegoś innego.

Nasza interpretacja: zacznij od rekurencyjnego znakowego. W danych Chroma ustępuje pod względem recall tylko splitterowi klastrowemu i LLM-owemu, a precision 3,9% splittera LLM-owego oznacza, że podajesz generatorowi mniej więcej dwa razy więcej szumu na każdy trafny token. Większość zespołów nie ma problemu z chunkowaniem; ma problem z rozmiarem chunka, którego nigdy nie zmierzyła.

Co właściwie mówią dane o rozmiarze chunka?

Jedyne publiczne porównanie head-to-head strategii chunkowania RAG to raport techniczny Chroma „Evaluating Chunking Strategies for Retrieval" (Brandon Smith i Anton Troynikov, opublikowany 3 lipca 2024). Uruchomili 472 zapytania na 5 korpusach (328 208 tokenów), osadzili wszystko modelem OpenAI text-embedding-3-large i pobrali 5 fragmentów na zapytanie. Wiersze poniżej pochodzą z tabeli w załączniku raportu dla wszystkich korpusów na text-embedding-3-large przy 5 pobranych fragmentach, więc są bezpośrednio porównywalne:

Główna tabela wyników Chroma, która raportuje inne ustawienie retrieval, podaje najlepszą precision splittera klastrowego na poziomie 8,0% przy recall 87,3% i rozciąga zakres precision wszystkich splitterów od 1,5% (KamradtSemanticChunker) do 8,0%. Źródło: Chroma Research, Evaluating Chunking Strategies

„Introducing Contextual Retrieval" Anthropic (opublikowany 19 września 2024) podchodzi do problemu z innej strony. Bazowy wskaźnik nieudanych pobrań top-20 wynosił 5,7%; same embeddingi kontekstowe zbiły go do 3,7% (redukcja o 35%), kontekstowe BM25 dołożone na wierzch dały 2,9% (49%), a reranking zepchnął go do 1,9% (67%). Anthropic nie publikuje dokładnego rozmiaru chunka ani nakładania, więc traktuj te liczby jako dowód na poziomie metody, a nie rozmiaru. Źródło: Anthropic, Contextual Retrieval.

Nasza interpretacja: trzy wnioski z arytmetyki. Po pierwsze, wybór splittera daje realny recall i Chroma mówi to wprost: niektóre strategie przewyższają inne nawet o 9% recall. W głównej tabeli wyników recall rozciąga się od 83,6% (KamradtSemanticChunker) do 91,9% (LLMSemanticChunker), a w wierszach retrieve-5 powyżej wciąż obejmuje 86,7% do 91,7%. Precision na tych samych danych porusza się kilkukrotnie mocniej: od 1,5% do 8,0%, czyli rozrzut 5,3x wobec 1,1x dla recall. Zatem recall to miejsce, gdzie zyskujesz kilka punktów, a precision i koszt tokenów to miejsca, gdzie wybór naprawdę boli. Po drugie, splitter oparty na LLM kupuje najwyższy recall za cenę najgorszej precision: płacisz wywołaniem LLM za dokument i podajesz generatorowi więcej szumu. Po trzecie, liczby Anthropic pokazują, że wzbogacanie chunków kontekstem (z 5,7% do 3,7%) przesunęło wskaźnik błędów bardziej niż jakikolwiek wybór splittera w tabeli Chroma. Wzbogać chunki, zanim zaczniesz przestrajać splitter. Reranking odzyskuje fragmenty, które splitter zniekształcił, a wyszukiwanie hybrydowe łączy BM25 z retrieval wektorowym z tego samego powodu.

Uczciwe ograniczenia: oba badania używają jednego modelu embeddingowego, korpusów tylko po angielsku i żadne nie jest kontrolowanym testem na Twoim korpusie. Na 472 zapytania różnica między najlepszym a najgorszym splitterem wynosiła około 5 punktów recall przy 5 pobranych fragmentach oraz proporcjonalnie znacznie większą różnicę w precision.

Dlaczego rozmiar chunka decyduje o jakości retrieval?

Rozmiar chunka ustala ziarnistość klucza retrieval. Chunk 400-tokenowy tworzy skupiony embedding, który pasuje do konkretnych zapytań; chunk 4000-tokenowy uśrednia wiele tematów i nie pasuje precyzyjnie do niczego. Małe chunki odzyskują dokładny fragment, ale mogą rozdrobnić odpowiedź między wyniki. Duże chunki trzymają kontekst w całości, ale osłabiają sygnał embeddingu.

Sufit kontekstu modelu embeddingowego też ma znaczenie. Jeśli Twój model ma limit 512 tokenów wejściowych, a podasz mu 800, końcówka zostanie cicho obcięta. Twój embedding reprezentuje dwie trzecie chunka. Żaden błąd się nie loguje.

Potem strona generatora. Liu i in. pokazali w „Lost in the Middle" (arXiv 2307.03172, 2023), że trafność LLM spada o ponad 20%, gdy właściwy dokument leży w środku długiego kontekstu. Pobranie pięciu chunków po 1000 tokenów wrzuca 5000 tokenów do promptu, a odpowiedź, której potrzebujesz, może wylądować na pozycji, którą model czyta najgorzej. Mniejsze chunki trzymają właściwy fragment bliżej pozycji, z którą model radzi sobie dobrze.

Pomyśl o tym jak o katalogu bibliotecznym. Karta z napisem „Sekcja 4.2, akapit 3: polityka zwrotów" prowadzi Cię do strony. Karta z napisem „wszystko o handlu w XX wieku" prowadzi Cię do budynku. Twój embedding jest tą kartą. Zbuduj aplikację RAG od początku do końca, żeby zobaczyć, gdzie chunkowanie siedzi w pipeline, i przeczytaj nasz przewodnik po inżynierii kontekstu, aby zrozumieć, jak pobrane fragmenty stają się tokenami promptu. Przewodnik po chunkowaniu Pinecone opisuje ten sam kompromis od strony bazy wektorowej.

Chunkowanie o stałym rozmiarze i rekurencyjne (zacznij tutaj)

Stały rozmiar to baza, do której mierzysz wszystko; rekurencyjne to to, co faktycznie wdrażasz.

Chunkowanie tokenowe o stałym rozmiarze

Dziel co N tokenów niezależnie od treści.

def fixed_size_chunks(text: str, size: int = 512, overlap: int = 50) -> list[str]:
    tokens = text.split()  # whitespace proxy; use tiktoken for real token counts
    chunks = []
    step = size - overlap
    for i in range(0, len(tokens), step):
        chunk = " ".join(tokens[i : i + size])
        chunks.append(chunk)
        if i + size >= len(tokens):
            break
    return chunks

Właściwa odpowiedź dla: płaski tekst bez struktury nagłówków, szybkie prototypy i każde porównanie bazowe. To nie jest głupie. To grupa kontrolna.

Rekurencyjne chunkowanie znakowe

RecursiveCharacterTextSplitter z LangChain dzieli po hierarchii separatorów: najpierw \n\n (akapity), potem \n (linie), potem . (zdania), potem (słowa). Każdy chunk zostaje poniżej chunk_size, respektując największą naturalną granicę, która się mieści.

from langchain_text_splitters import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=50,
    separators=["\n\n", "\n", ". ", " ", ""],
    length_function=len,  # swap for tiktoken len for true token counts
)
chunks = splitter.split_text(document)

Lista separatorów to część, którą każdy konkurent pomija. Splitter próbuje najpierw \n\n i przechodzi do . dopiero wtedy, gdy akapit przekracza chunk_size. Jeśli Twój Markdown ma nagłówki, dodaj "## " przed "\n\n", żeby sekcje zostały nienaruszone.

Arytmetyka nakładania chunków: przy 512 tokenach z 50-tokenowym nakładaniem krok wynosi 462. Dokument 10 000-tokenowy daje ceil(10000 / 462) = 22 chunki. Łączna liczba osadzonych tokenów: 22 x 512 = 11 264, co oznacza, że ponownie osadzasz około 12,6% korpusu jako nakładanie. Taki jest koszt przechowywania i API za to, żeby zdania na granicach nie zostawały osierocone.

Jak działa chunkowanie semantyczne i czy jest warte swojej ceny?

Chunkowanie semantyczne osadza każde zdanie, mierzy odległość cosinusową między embeddingami sąsiednich zdań i dzieli tam, gdzie ta odległość przekracza próg percentylowy (zwykle 95.). Chunki łamią się na zmianach tematu, a nie na arbitralnej liczbie tokenów. Notebook Grega Kamradta „5 Levels of Text Splitting" zapoczątkował to podejście percentylowego punktu przełamania, a badanie Chroma benchmarkuje jego chunkery z nazwy.

from langchain_experimental.text_splitter import SemanticChunker
from langchain_openai import OpenAIEmbeddings

embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
splitter = SemanticChunker(
    embeddings,
    breakpoint_threshold_type="percentile",
    breakpoint_threshold_amount=95,
)
chunks = splitter.split_text(document)

Matematyka kosztów to część, której nikt nie wykłada na stół. Chunkowanie semantyczne osadza korpus dwa razy: raz, żeby obliczyć odległości między zdaniami i znaleźć punkty przełamania, i raz, żeby osadzić wynikowe chunki do indeksowania. Przy cenie OpenAI text-embedding-3-large wynoszącej 0,13 USD za 1 mln tokenów korpus 10 mln tokenów kosztuje 1,30 USD przy zwykłym indeksowaniu i 2,60 USD przy chunkowaniu semantycznym. Płacisz podwójnie, zanim padnie pierwsze zapytanie.

Co to kupuje? W wierszach retrieve-5 Chroma splitter semantyczny oparty na klastrach osiągnął 89,0% recall i 6,7% precision wobec 88,5% i 7,0% dla rekurencyjnego przy tym samym rozmiarze 200 tokenów. W głównej tabeli wyników ten sam chunker notuje najlepszą precision w badaniu, 8,0%, przy recall 87,3%. Pół punktu recall w tę czy tamtą stronę i wynik precision, który zmienia znak w zależności od tego, które ustawienie retrieval czytasz, za podwójny rachunek za embedding. Nasz werdykt: chunkowanie semantyczne opłaca się na korpusach o różnorodnej tematyce (archiwa wiadomości, zbiory artykułów), gdzie stałe granice rutynowo tną w środku tematu. Dla korpusów jednorodnych (dokumentacja produktu, jedna baza wiedzy) rekurencyjne daje 95% jakości za połowę ceny. Jeśli uruchamiasz modele embeddingowe lokalnie z Ollama, koszt podwójnego embeddingu spada do czasu obliczeń.

Chunkowanie świadome dokumentu: Markdown, HTML i kod

Dzielenie świadome struktury używa własnych granic dokumentu (nagłówki, elementy list, definicje funkcji) zamiast liczby znaków. Nagłówek H2 w Markdown to granica semantyczna, którą człowiek umieścił celowo; splitter znakowy ją szatkuje.

from langchain_text_splitters import MarkdownHeaderTextSplitter

headers = [("#", "h1"), ("##", "h2"), ("###", "h3")]
splitter = MarkdownHeaderTextSplitter(headers_to_split_on=headers)
splits = splitter.split_text(markdown_doc)
# Each split carries metadata: {"h1": "...", "h2": "...", "h3": "..."}

Dla kodu granicami są węzły AST. NodeParsery LlamaIndex dostarczają splitters świadome języka, które łamią na definicjach funkcji i klas. Kluczowy szczegół: trzymaj blok importów i sygnaturę klasy nadrzędnej dołączone do każdego chunka funkcyjnego. Ciało funkcji bez importów to nieosadzalny szum, więc poprzedź oba przed każdym chunkiem, a embedding uchwyci, co funkcja robi i od czego zależy.

Konkretnie dla RAG na kodzie: dzielenie po granicach AST, importy poprzedzające, 256-512 tokenów na funkcję, zero nakładania.

A co z późnym, hierarchicznym i agentowym chunkowaniem?

To zaawansowane strategie chunkowania RAG stojące za szumem wokół „RAG 2.0" i wszystkie trzy mają pokrycie SERP na poziomie 1/10.

Późne chunkowanie

Późne chunkowanie, wprowadzone przez Günthera i in. w „Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models" (arXiv 2409.04701, wrzesień 2024), najpierw osadza cały dokument modelem długiego kontekstu, a potem grupuje embeddingi na poziomie tokenów w wektory chunków, dzięki czemu każdy chunk niesie kontekst całego dokumentu i „to kosztuje 40 USD/mies." wie, do czego odnosi się „to". Abstrakt deklaruje lepszy retrieval w różnych zadaniach, ale nie publikuje żadnej liczby nagłówkowej, którą moglibyśmy zweryfikować. Wpis Weaviate wyjaśnia mechanikę i też powstrzymuje się od kontrolowanego porównania. Stan dowodów: obiecujące, nieskwantyfikowane.

Chunkowanie hierarchiczne (rodzic-dziecko)

Indeksuj małe chunki (256 tokenów) do retrieval; zwracaj rodzica (1024 tokeny) do generatora. Retriever znajduje igłę; generator dostaje otaczający stóg siana. Utrzymujesz dwa poziomy indeksu i mapowanie rodzic-dziecko. Żaden publiczny benchmark nie izoluje tego efektu.

Chunkowanie oparte na LLM / agentowe

LLMSemanticChunker z badania Chroma używa GPT-4o do decydowania o punktach podziału dla każdego dokumentu: 91,7% recall (najwyższa) i 3,9% precision (najniższa). Płacisz wywołaniem LLM za dokument w momencie indeksowania (około 100 USD za korpus 10 000 dokumentów) i podajesz generatorowi więcej szumu. Zarezerwuj to dla naprawdę nieregularnych korpusów: dokumenty sądowe, skanowane PDF-y bez wydobywalnych nagłówków.

Jaki rozmiar chunka pasuje do Twojego modelu embeddingowego?

Maksymalna liczba tokenów wejściowych Twojego modelu embeddingowego to sufit obcinania, a nie rekomendacja. Model, który przyjmuje 8192 tokeny, nie osadza lepiej przy 8192 niż przy 512. Jakość degraduje się przez rozcieńczenie na długo przed sufitem: model uśrednia znaczenie po większej liczbie tokenów i wektor dryfuje w stronę centroidu korpusu. Kolumna rekomendacji poniżej to interpretacja Techsy, a nie wskazówki dostawców.

Źródła: przewodnik po embeddingach OpenAI, dokumentacja Cohere embed, dokumentacja embeddingów Voyage, karta modelu BGE.

Wzorzec: modele z twardym sufitem 512 tokenów (Cohere v3, BGE) wymagają chunków dobrze poniżej 512, bo obcinanie jest ciche. Podaj takiemu 600 tokenów, a ostatnie 88 znika z embeddingu bez zalogowania błędu. Modele z dużymi sufitami (OpenAI, Voyage, Cohere v4) tolerują większe chunki, ale ich nie nagradzają. Maksymalna długość wejściowa modelu to limit obcinania, a nie rekomendacja.

Sparuj to z naszym zestawieniem najlepszych modeli embeddingowych do RAG, wyjaśnieniem, co naprawdę mierzy wynik MTEB, i porównaniem embeddingów Voyage, OpenAI i Cohere, zanim zdecydujesz się na model.

Jak chunkować dokumenty nieangielskie?

Tokenizery nie są neutralne językowo. Petrov i in. pokazali w „Language Model Tokenizers Introduce Unfairness Between Languages" (arXiv 2305.15425, 2023), że ten sam tekst przetłumaczony między językami może różnić się długością po tokenizacji nawet 15-krotnie. Nawet modele znakowe i bajtowe pokazują ponad 4-krotną różnicę dla niektórych par językowych. Chunk 512-tokenowy mieści znacznie mniej znaczenia po turecku, arabsku czy japońsku niż po angielsku.

Oto to samo zdanie stokenizowane kodowaniem cl100k_base z tiktoken (tokenizator GPT-4):

import tiktoken
enc = tiktoken.get_encoding("cl100k_base")
en = "The retrieval system returns relevant documents."
tr = "Erişim sistemi ilgili belgeleri döndürür."
ja = "検索システムは関連文書を返します。"
print(len(enc.encode(en)), len(enc.encode(tr)), len(enc.encode(ja)))
# 7 tokens, 19 tokens, 19 tokens: same meaning, 2.7x token spread

Liczby wygenerowane tiktoken cl100k_base, 30 lipca 2026.

Praktyczna wskazówka: przy stałym rozmiarze chunka 512 tokenów Twoje chunki tureckie i japońskie mieszczą mniej więcej 37% znaczenia, które mieszczą chunki angielskie, a chunki arabskie około 26%. Chunkuj według liczby znaków lub liczby zdań dla każdego języka albo proporcjonalnie podnieś budżet tokenów (około 1400 dla tureckiego, 2000 dla arabskiego). Języki CJK nie mają spacji jako granic słów, więc splittery znakowe zachowują się inaczej. Morfologia arabskiego pakuje wiele znaczników gramatycznych w pojedyncze tokeny, dodatkowo pompując liczby.

Drzewo decyzyjne wyboru strategii chunkowania

What kind of document?
├── Structured (Markdown / HTML / code)
│   └── Document-aware splitting on headers or AST boundaries
│       ├── Docs site → MarkdownHeaderTextSplitter, 512 tokens, 0 overlap
│       └── Codebase → AST/function splitter, 256-512 tokens, imports prepended
├── Flat prose (articles, reports, books)
│   └── RecursiveCharacterTextSplitter, 512 tokens, 50 overlap
│       └── Topic-diverse? → try SemanticChunker at 95th percentile
├── Conversational logs (chat, support tickets)
│   └── Split on turn boundaries, group 3-5 turns per chunk, 256 tokens
└── Mixed corpus
    └── Route by MIME type → apply per-type strategy above
        └── Then: how long are expected answers?
            ├── Short (1-2 sentences) → child 256, no parent
            └── Long (multi-paragraph) → hierarchical: child 256, parent 1,024

Trzy szybkie recepty. Chatbot na dokumentacji: MarkdownHeaderTextSplitter przy 512 tokenach, zero nakładania, ścieżka nagłówków w metadanych. Asystent wyszukiwania w kodzie: dzielenie po granicach AST przy 256-512 tokenów na funkcję, importy poprzedzające. Mieszany korpus firmowy: kieruj według typu dokumentu przy ingescji i przechowuj w bazie wektorowej, w której trzymasz chunki, z metadanymi typu do późniejszego dostrajania per typ. To kierowanie per dokument to całość adaptacyjnego chunkowania dla aplikacji RAG.

Narzędzia: LangChain vs LlamaIndex vs Chonkie

Nie sprzedajemy żadnego z nich; trzy najwyżej notowane strony dla tego słowa kluczowego to blogi dostawców z CTA produktowymi.

Źródła: dokumentacja LangChain, NodeParsery LlamaIndex, dokumentacja Chonkie.

Wszystkie trzy implementują te same główne algorytmy, więc wybieraj na podstawie tego, czego już używa Twój pipeline. Po szerszy stos narzędzi RAG poza splitterami i porównanie Qdrant, Chroma i pgvector do przechowywania zajrzyj do naszych przewodników klastrowych.

Jak Techsy podchodzi do chunkowania

Przy klienckich wdrożeniach RAG zespół Techsy zaczyna od 512 tokenów z 10% nakładania i nie dotyka splittera, dopóki nie zbudujemy zestawu ewaluacyjnego 20-50 pytań z prawdziwych zgłoszeń wsparcia klienta. Zestaw ewaluacyjny powstaje pierwszy; potem zmieniamy jedną zmienną naraz: rozmiar, nakładanie, strategię. Żadnej wymiany splittera bez liczby przed i po na tych samych pytaniach. Umów się na bezpłatną konsultację, żeby uzyskać drugą parę oczu na Twój pipeline retrieval.

O autorze

Mert Batur jest współzałożycielem Techsy.io, gdzie zespół dostarcza agentów AI, systemy automatyzacji i pipeline głosowe/SDR dla klientów B2B. Pisze o stosie narzędzi LLM, którego zespół Techsy faktycznie używa w produkcji, w tym o pracy nad RAG i retrieval przy budowie klienckich baz wiedzy. Połącz się na LinkedIn.

Często zadawane pytania

Czym jest chunkowanie w RAG?

Chunkowanie to krok preprocessingu, który dzieli dokumenty na mniejsze segmenty przed embeddingiem, żeby retriever mógł dopasowywać zapytania do skupionych fragmentów, a nie do całych plików. Punkty podziału określają, co Twój system może, a czego nie może znaleźć w czasie zapytania.

Jaka jest najlepsza strategia chunkowania dla RAG?

Dla większości systemów produkcyjnych na ogólnych dokumentach rekurencyjne chunkowanie znakowe przy 512 tokenach z 10% nakładania jest najsilniejszym domyślnym wyborem. W badaniu Chroma (472 zapytania, lipiec 2024) osiągnęło 88,5% recall, w granicach 3,2 punktu od najdroższej metody opartej na LLM, przy zerowym dodatkowym koszcie.

Jaki jest optymalny rozmiar chunka dla RAG?

Zacznij od 512 tokenów. Zejdź do 256, jeśli Twój model embeddingowy ma sufit 512 tokenów wejściowych (Cohere v3, BGE) lub jeśli Twoje zapytania oczekują odpowiedzi jednozdaniowych. Wejdź na 1024 tylko wtedy, gdy Twój zestaw ewaluacyjny pokazuje, że odpowiedzi wieloakapitowe są rozdrabniane. Zawsze mierz na własnych pytaniach.

Jak duże nakładanie chunków stosować?

10-20% rozmiaru chunka (50-100 tokenów przy 512). Nakładanie zapobiega osieroceniu zdań granicznych: fakt rozdzielony między dwa chunki pojawia się w całości w co najmniej jednym. Powyżej 20% ponownie osadzasz zbyt dużą część korpusu przy malejących zwrotach. Większość zespołów ląduje na 10% i nigdy do tego nie wraca.

Czy chunkowanie semantyczne jest lepsze od chunkowania o stałym rozmiarze?

Marginalnie i za podwójną cenę embeddingu. Benchmark Chroma z lipca 2024 pokazał splitter semantyczny oparty na klastrach z 89,0% recall i 6,7% precision wobec 88,5% recall i 7,0% precision dla rekurencyjnego przy tym samym rozmiarze tokenów, a jego najlepszy wynik precision 8,0% pochodzi z innego ustawienia retrieval. Warte tego dla korpusów o różnorodnej tematyce; trudne do obrony dla jednorodnych zbiorów dokumentów.

Czy rozmiar chunka zależy od modelu embeddingowego?

Tak. Modele z sufitem 512 tokenów wejściowych (BGE, Cohere v3) wymagają chunków dobrze poniżej 512, bo obcinanie jest ciche. Modele z sufitami 8192+ tolerują większe chunki, ale ich nie nagradzają; jakość embeddingu degraduje się przez rozcieńczenie przed sufitem. Zobacz tabelę parowania powyżej, aby poznać punkty startowe dla każdego modelu.

Jak chunkować kod dla systemu RAG?

Dziel po granicach AST (definicje funkcji i klas), a nie po liczbie tokenów. Trzymaj każdy chunk w granicach 256-512 tokenów na funkcję, poprzedź blok importów pliku i sygnaturę klasy nadrzędnej oraz stosuj zero nakładania, bo funkcje są samodzielnymi jednostkami. CodeSplitter z LlamaIndex i splitters świadome języka z LangChain oba to obsługują.

Czym jest późne chunkowanie?

Późne chunkowanie najpierw osadza cały dokument modelem długiego kontekstu, a potem grupuje embeddingi na poziomie tokenów w wektory chunków. Każdy embedding chunka niesie kontekst całego dokumentu, rozwiązując problem „do czego odnosi się »to«?". Wprowadzone przez Günthera i in. (arXiv 2409.04701, wrzesień 2024). Żaden publiczny benchmark porównawczy nie kwantyfikuje jeszcze zysku.

Jak chunkować dokumenty w językach innych niż angielski?

Liczby tokenów nie są neutralne językowo. To samo zdanie zajęło 2,7x więcej tokenów po turecku i japońsku niż po angielsku oraz 3,9x po arabsku (tiktoken cl100k_base). Stały budżet 512 tokenów po cichu daje chunkom nieangielskim mniej znaczenia. Chunkuj według liczby znaków lub zdań dla każdego języka albo proporcjonalnie podnieś budżet.

Skąd wiedzieć, czy moje chunkowanie faktycznie działa?

Zbuduj zestaw ewaluacyjny 20-50 pytań z prawdziwych zapytań użytkowników, zanim dotkniesz splittera. Mierz hit@5 i MRR na obecnych chunkach. Zmień jedną zmienną (rozmiar, nakładanie, strategia), uruchom ponownie, porównaj. Bez zestawu ewaluacyjnego dostrajasz na wyczucie. Dwadzieścia pytań wystarczy na start.

Podsumowanie

• Zacznij od rekurencyjnego chunkowania znakowego przy 512 tokenach, 10% nakładania. Właściwy domyślny wybór dla płaskiego tekstu.
• Spośród czterech rodzin splitterów, które ktokolwiek zmierzył, 472 zapytania Chroma przesuwają recall o około 5 punktów, a precision kilkukrotnie bardziej. Dostrajaj najpierw pod precision i koszt.
• Dopasuj rozmiar chunka do sufitu wejściowego modelu embeddingowego. Model z sufitem 512 tokenów wymaga chunków poniżej 512.
• Wzbogać chunki kontekstem (spadek wskaźnika błędów Anthropic z 5,7% do 3,7%), zanim zaczniesz przestrajać splitter.
• Najpierw zbuduj zestaw ewaluacyjny. Każda decyzja o splitterze bez liczby przed i po to zgadywanie.

Po pełny pipeline wokół Twojego wyboru chunkowania zajrzyj do zbuduj aplikację RAG od początku do końca. Nadal wybierasz między retrieval a dostrajaniem? RAG czy fine-tuning rozkłada, kiedy wygrywa każde z nich.