Strategie chunkování RAG: 7 metod hodnocených podle dat o vyhledávání (2026)

Strategie chunkování RAG: 7 metod hodnocených podle dat o vyhledávání (2026)

Strategie chunkování RAG rozhodují o tom, co váš retriever najde, ještě než se spustí první dotaz. Studie Chromy z července 2024 proběhla na 472 dotazech napříč pěti korpusy nad modelem text-embedding-3-large a volba splitteru posouvá recall zhruba o pět bodů: 86,7 % u prostého tokenového splitteru, 91,7 % u toho založeného na GPT-4o, při pěti dohledaných chuncích na dotaz. Precize kolísá mnohem víc. V celém reportu se pohybuje od 1,5 % do 8,0 %, takže volba velikosti chunku je v jádru rozhodnutí o nákladech převlečené za rozhodnutí o kvalitě. A každý návod na první stránce Googlu vypisuje stejných sedm metod, aniž by ukázal, která dohledává lépe.

Klíčové poznatky

• Chunkování dělí dokumenty před embeddingem; body dělení určují, co váš retriever najde a co ne.
• Ve studii Chromy z července 2024 se 472 dotazy dosahoval recall 86,7 % až 91,7 % napříč měřenými splittery.
• Precize kolísá několikanásobně víc než recall, takže velikost chunku je hlavně rozhodnutí o ceně tokenů.
• Začněte na 512 tokenech s 10% překryvem a pak ladte podle vlastní eval sady.

Jakou strategii chunkování RAG zvolit? (Žebříček)

Pro většinu týmů, které staví na prostém textu, je správný default rekurzivní znakové chunkování na 512 tokenech s 10% překryvem. Respektuje hranice odstavců a vět, nestojí nic navíc a v benchmarku Chromy se 472 dotazy skončilo 3,2 bodu recallu za LLM splitterem. Odkloňte se od něj jen tehdy, když mají vaše dokumenty silnou strukturu nebo když vaše eval sada prokáže opak.

Naše čtení: začněte rekurzivním znakovým chunkováním. V datech Chromy zaostává jen za clusterovým a LLM splitterem a 3,9% precize LLM splitteru znamená, že generátoru krmíte zhruba dvakrát víc šumu na relevantní token. Většina týmů nemá problém s chunkováním; má problém s velikostí chunku, který nikdy nezměřila.

Co vlastně říkají data o velikosti chunku?

Jediné veřejné head-to-head srovnání strategií chunkování RAG je technický report Chromy „Evaluating Chunking Strategies for Retrieval" (Brandon Smith a Anton Troynikov, publikováno 3. července 2024). Autoři spustili 472 dotazů napříč 5 korpusy (328 208 tokenů), vše embedovali modelem OpenAI text-embedding-3-large a na dotaz dohledali 5 chunků. Řádky níže pocházejí z tabulky v příloze reportu pro všechny korpusy nad text-embedding-3-large při 5 dohledaných chuncích, takže jsou vzájemně přímo porovnatelné:

Tabulka hlavních výsledků Chromy, která reportuje jiné nastavení vyhledávání, uvádí nejlepší precizi clusterového chunkeru 8,0 % při recallu 87,3 % a rozpětí precize všech splitterů od 1,5 % (KamradtSemanticChunker) do 8,0 %. Zdroj: Chroma Research, Evaluating Chunking Strategies

„Introducing Contextual Retrieval" od Anthropicu (publikováno 19. září 2024) útočí na problém z jiného úhlu. Základní míra selhání vyhledávání top-20 byla 5,7 %; samotné kontextové embeddingy ji stlačily na 3,7 % (pokles o 35 %), kontextové BM25 navrch na 2,9 % (49 %) a reranking na 1,9 % (67 %). Anthropic nezveřejňuje přesnou velikost chunku ani překryv, takže tato čísla berte jako důkaz na úrovni metody, ne velikosti. Zdroj: Anthropic, Contextual Retrieval.

Naše čtení: z té aritmetiky plynou tři závěry. Zaprvé, volba splitteru stojí za reálný recall a Chroma to říká přímo: některé strategie překonávají jiné až o 9 % recallu. V tabulce hlavních výsledků se recall pohybuje od 83,6 % (KamradtSemanticChunker) do 91,9 % (LLMSemanticChunker) a i v řádcích s 5 dohledanými výše stále sahá od 86,7 % do 91,7 %. Precize se na stejných datech hýbe několikanásobně víc: 1,5 % až 8,0 %, tedy 5,3× rozpětí proti 1,1× u recallu. Recall je místo, kde získáte pár bodů, ale precize a cena tokenů jsou místo, kde volba opravdu bolí. Zadruhé, LLM splitter kupuje nejlepší recall za nejhorší precizi: platíte LLM volání za dokument a krmíte generátor větším šumem. Zatřetí, čísla Anthropicu ukazují, že obohacení chunků o kontext (5,7 % na 3,7 %) posunulo míru selhání víc než kterákoli volba splitteru v tabulce Chromy. Obohaťte chunky kontextem dřív, než začnete přeladěte splitter. Reranking zachrání chunky, které váš splitter zmrzačil, a hybridní vyhledávání kombinuje BM25 s vektorovým vyhledáváním ze stejného důvodu.

Upřímné limity: obě studie používají jediný embeddingový model, pouze anglické korpusy a ani jedna není kontrolovaný test na vašem korpusu. Napříč 472 dotazy činil rozdíl mezi nejlepším a nejhorším splitterem zhruba 5 bodů recallu při 5 dohledaných chuncích a proporčně mnohem větší rozdíl v precizi.

Proč velikost chunku rozhoduje o kvalitě vyhledávání?

Velikost chunku nastavuje zrnitost vašeho vyhledávacího klíče. Chunk o 400 tokenech vytvoří soustředěný embedding, který odpovídá konkrétním dotazům; chunk o 4 000 tokenech zprůměruje mnoho témat a neodpovídá přesně ničemu. Malé chunky dohledají přesný úryvek, ale mohou rozdrobit odpověď napříč výsledky. Velké chunky udrží kontext pohromadě, ale oslabují signál embeddingu.

Záleží i na kontextovém stropu embeddingového modelu. Pokud má model strop 512 vstupních tokenů a vy mu pošlete 800, konec se tiše ořízne. Váš embedding reprezentuje dvě třetiny chunku. Žádná chyba v logu.

Pak strana generátoru. Liu a kol. v článku "Lost in the Middle" (arXiv 2307.03172, 2023) ukázali, že přesnost LLM klesne o víc než 20 %, když relevantní dokument leží uprostřed dlouhého kontextu. Dohledání pěti 1 000tokenových chunků nandá do promptu 5 000 tokenů a odpověď, kterou potřebujete, může skončit na pozici, kterou model čte nejhůř. Menší chunky drží relevantní úryvek blíž pozici, kterou model zvládá dobře.

Představte si to jako katalog v knihovně. Lístek „sekce 4.2, odstavec 3: pravidla pro vrácení peněz" vás dostane na stránku. Lístek „všechno o obchodu ve 20. století" vás dostane tak do budovy. Váš embedding je ten lístek. Postavte RAG aplikaci od začátku do konce, abyste viděli, kde chunkování v pipeline sedí, a přečtěte si náš průvodce context engineeringem o tom, jak se dohledané chunky mění na tokeny promptu. Průvodce chunkováním od Pineconu popisuje tentýž trade-off ze strany vektorové databáze.

Pevná velikost a rekurzivní chunkování (začněte tady)

Pevná velikost je základní laťka, vůči které měříte vše ostatní; rekurzivní chunkování je to, co skutečně nasadíte.

Tokenové chunkování pevné velikosti

Rozdělte každých N tokenů bez ohledu na obsah.

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

Správná odpověď pro: prostý text bez nadpisů, rychlé prototypy a jakékoli srovnávací měření. Není to hloupost. Je to kontrolní skupina.

Rekurzivní znakové chunkování

RecursiveCharacterTextSplitter od LangChainu dělí podle hierarchie oddělovačů: nejdřív \n\n (odstavce), pak \n (řádky), pak . (věty) a pak (slova). Každý chunk zůstane pod chunk_size a respektuje největší přirozenou hranici, která se vejde.

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)

Seznam oddělovačů je část, kterou každý konkurent vynechává. Splitter zkouší nejdřív \n\n a na . spadne jen tehdy, když odstavec překročí chunk_size. Pokud váš Markdown obsahuje nadpisy, přidejte "## " před "\n\n", aby sekce zůstaly celé.

Aritmetika překryvu chunků: při 512 tokenech s překryvem 50 tokenů je krok 462. Dokument o 10 000 tokenech vytvoří ceil(10000 / 462) = 22 chunků. Celkem embedovaných tokenů: 22 × 512 = 11 264, tedy znovu embedujete zhruba 12,6 % korpusu jako překryv. To je cena za úložiště a API, kterou platíte, aby se hraniční věty neosamostatnily.

Jak funguje sémantické chunkování a vyplatí se ta cena?

Sémantické chunkování embeduje každou větu, změří kosinovou vzdálenost mezi embeddingy sousedních vět a dělí tam, kde vzdálenost překročí percentilový práh (běžně 95.). Chunky se lámou na změnách tématu, ne na libovolném počtu tokenů. Notebook Grega Kamradta "5 Levels of Text Splitting" tento přístup s percentilovým breakpointem založil a studie Chromy benchmarkuje jeho chunkery jmenovitě.

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)

Výpočet ceny je část, kterou nikdo neříká na rovinu. Sémantické chunkování embeduje váš korpus dvakrát: jednou pro výpočet vzdáleností vět a nalezení breakpointů, podruhé pro embedding výsledných chunků do indexu. Při ceně OpenAI text-embedding-3-large 0,13 $ za 1M tokenů stojí korpus o 10M tokenech 1,30 $ při běžném indexování a 2,60 $ se sémantickým chunkováním. Platíte dvojnásobek dřív, než se spustí jediný dotaz.

Co za to dostanete? V řádcích s 5 dohledanými dosáhl clusterový sémantický chunker recallu 89,0 % a precize 6,7 % proti 88,5 % a 7,0 % u rekurzivního při stejné velikosti 200 tokenů. V tabulce hlavních výsledků tentýž chunker vykazuje nejlepší precizi studie, 8,0 %, při recallu 87,3 %. Půl bodu recallu sem nebo tam a výsledek precize, který mění znaménko podle toho, které nastavení vyhledávání čtete, za dvojnásobný účet za embeddingy. Náš verdikt: sémantické chunkování se vyplatí u tématicky pestrých korpusů (zpravodajské archivy, sbírky článků), kde pevné hranice běžně dělí uprostřed tématu. Pro homogenní korpusy (produktová dokumentace, jedna knowledge base) vám rekurzivní chunkování dá 95 % kvality za poloviční cenu. Pokud provozujete embeddingové modely lokálně s Ollamou, dvojnásobná cena za embeddingy klesne na výpočetní čas.

Chunkování podle dokumentu: Markdown, HTML a kód

Dělení podle struktury využívá vlastní hranice dokumentu (nadpisy, položky seznamů, definice funkcí) místo počtu znaků. Markdown H2 je sémantická hranice, kterou člověk umístil záměrně; znakový splitter ji roztrhá.

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": "..."}

U kódu jsou hranicemi uzly AST. NodeParsery LlamaIndexu obsahují splittery podle jazyka, které dělí na definicích funkcí a tříd. Zásadní detail: nechte blok importů a podpis obklopující třídy připojený ke každému chunku funkce. Tělo funkce bez importů je neembedovatelný šum, takže obojí přidejte na začátek každého chunku a embedding zachytí, co funkce dělá i na čem závisí.

Konkrétně pro kódový RAG: dělení podle hranic AST, importy na začátku, 256-512 tokenů na funkci, nulový překryv.

Co late, hierarchické a agentské chunkování?

Tohle jsou pokročilé strategie chunkování RAG stojící za šumem kolem „RAG 2.0" a všechny tři mají pokrytí SERP 1/10.

Late chunking

Late chunking, které představili Günther a kol. v "Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models" (arXiv 2409.04701, září 2024), nejdřív embeduje celý dokument dlouhokontextovým modelem a pak sdružuje tokenové embeddingy do vektorů chunků, takže každý chunk nese kontext celého dokumentu a u „stojí 40 $ měsíčně" ví, co „to" znamená. Abstrakt tvrdí lepší vyhledávání napříč úlohami, ale nezveřejňuje žádné hlavní číslo, které bychom mohli ověřit. Článek Weaviate vysvětluje mechaniku a také se zastaví před kontrolovaným srovnáním. Stav důkazů: slibné, nekvantifikované.

Hierarchické (parent-child) chunkování

Indexujte malé chunky (256 tokenů) pro vyhledávání; vracejte parenta (1 024 tokenů) generátoru. Retriever najde jehlu; generátor dostane okolní kupku sena. Udržujete dvě úrovně indexu a mapování parent-child. Žádný veřejný benchmark tento efekt neizoluje.

Chunkování pomocí LLM / agentské chunkování

LLMSemanticChunker ze studie Chromy používá GPT-4o k určení bodů dělení pro každý dokument: recall 91,7 % (nejvyšší) a precize 3,9 % (nejnižší). Platíte LLM volání za dokument při indexování (zhruba 100 $ za korpus o 10 000 dokumentech) a krmíte generátor větším šumem. Rezervujte si ho pro opravdu nepravidelné korpusy: právní podání, skenovaná PDF bez extrahovatelných nadpisů.

Jaká velikost chunku sedí vašemu embeddingovému modelu?

Maximální počet vstupních tokenů vašeho embeddingového modelu je strop oříznutí, ne doporučení. Model, který přijme 8 192 tokenů, neembeduje lépe při 8 192 než při 512. Kvalita degraduje ředěním dávno před stropem: model průměruje význam přes víc tokenů a vektor se posouvá ke centroidu korpusu. Sloupec doporučení níže je interpretace Techsy, ne návod vendorů.

Zdroje: průvodce embeddingy OpenAI, dokumentace Cohere embed, dokumentace embeddingů Voyage, model card BGE.

Vzorec: modely s tvrdým stropem 512 tokenů (Cohere v3, BGE) vyžadují chunky výrazně pod 512, protože oříznutí je tiché. Pošlete jednomu 600 tokenů a posledních 88 z embeddingu zmizí bez chyby v logu. Modely s velkými stropy (OpenAI, Voyage, Cohere v4) snesou větší chunky, ale neodmění je. Maximální vstupní délka modelu je limit oříznutí, ne doporučení.

Zkombinujte to s naším přehledem nejlepších embeddingových modelů pro RAG, článkem co vlastně měří skóre MTEB a srovnáním embeddingy Voyage, OpenAI a Cohere vedle sebe, než se k modelu upíšete.

Jak chunkovat dokumenty v jiných jazycích než angličtině?

Tokenizéry nejsou jazykově neutrální. Petrov a kol. v "Language Model Tokenizers Introduce Unfairness Between Languages" (arXiv 2305.15425, 2023) ukázali, že stejný text přeložený mezi jazyky se může lišit tokenizovanou délkou až 15×. I znakové a bytové modely vykazují u některých jazykových párů rozdíl přes 4×. Chunk o 512 tokenech pojme v turečtině, arabštině nebo japonštině mnohem méně významu než v angličtině.

Zde je stejná věta tokenizovaná kódováním cl100k_base z tiktokenu (tokenizér 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

Počty vygenerovány pomocí tiktoken cl100k_base, 30. července 2026.

Praktické vodítko: při pevné velikosti chunku 512 tokenů pojmou vaše turecké a japonské chunky zhruba 37 % významu těch anglických a vaše arabské chunky asi 26 %. Chunkujte podle počtu znaků nebo vět pro každý jazyk, nebo zvyšte tokenový rozpočet úměrně (zhruba 1 400 pro turečtinu, 2 000 pro arabštinu). CJK jazyky nemají slovní hranice z mezer, takže znakové splittery se chovají jinak. Arabská morfologie balí několik gramatických značek do jednotlivých tokenů, což počty dál nafukuje.

Rozhodovací strom pro výběr strategie chunkování

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

Tři rychlé recepty. Dokumentační chatbot: MarkdownHeaderTextSplitter na 512 tokenech, nulový překryv, cesta nadpisů v metadatech. Asistent pro vyhledávání v kódu: dělení podle hranic AST po 256-512 tokenech na funkci, importy na začátku. Smíšený podnikový korpus: při ingestu směrujte podle typu dokumentu a ukládejte do vektorové databáze, kam chunky ukládáte, s metadaty typu pro pozdější ladění po typech. Právě toto směrování po dokumentech je celým adaptivním chunkováním pro RAG aplikace.

Nástroje: LangChain vs LlamaIndex vs Chonkie

Žádný z nich neprodáváme; tři nejlepší stránky v žebříčku pro toto klíčové slovo jsou vendorské blogy s produktovými CTA.

Zdroje: dokumentace LangChain, NodeParsery LlamaIndexu, dokumentace Chonkie.

Všechny tři implementují stejné základní algoritmy, takže vybírejte podle toho, co už vaše pipeline používá. Pro širší stack nástrojů RAG nad rámec splitterů a srovnání Qdrant, Chroma a pgvector pro úložiště se podívejte do našich průvodců clusterem.

Jak Techsy přistupuje ke chunkování

Na klientských RAG projektech tým Techsy začíná na 512 tokenech s 10% překryvem a splitteru se nedotkne, dokud nepostaví eval sadu o 20-50 otázkách z reálných support ticketů klienta. Eval sada je první; pak měníme jednu proměnnou po druhé: velikost, překryv, strategii. Žádná výměna splitteru bez čísla před a po na stejných otázkách. Získejte bezplatnou konzultaci pro druhý pár očí na vaši vyhledávací pipeline.

O autorovi

Mert Batur je spoluzakladatel Techsy.io, kde tým dodává AI agenty, automatizační systémy a hlasové/SDR pipeline pro B2B klienty. Píše o stacku nástrojů LLM, který tým Techsy skutečně používá v produkci, včetně práce na RAG a vyhledávání za klientskými stavbami knowledge base. Spojte se na LinkedIn.

Často kladené otázky

Co je chunkování v RAG?

Chunkování je předzpracovatelský krok, který dělí dokumenty na menší segmenty před embeddingem, aby retriever mohl párovat dotazy se soustředěnými úryvky místo s celými soubory. Body dělení určují, co váš systém v čase dotazu najde a co ne.

Jaká je nejlepší strategie chunkování pro RAG?

Pro většinu produkčních systémů na obecných dokumentech je nejsilnější default rekurzivní znakové chunkování na 512 tokenech s 10% překryvem. Ve studii Chromy se 472 dotazy (červenec 2024) dosáhlo recallu 88,5 %, tedy 3,2 bodu pod nejdražší LLM metodou, a to bez dodatečných nákladů.

Jaká je optimální velikost chunku pro RAG?

Začněte na 512 tokenech. Snižte na 256, pokud má váš embeddingový model strop 512 vstupních tokenů (Cohere v3, BGE) nebo pokud vaše dotazy čekají jednoslovné odpovědi. Zvyšte na 1 024 jen tehdy, pokud vaše eval sada ukazuje, že se víceodstavcové odpovědi drobí. Vždy měřte proti vlastním otázkám.

Jak velký překryv chunků použít?

10-20 % velikosti chunku (50-100 tokenů při 512). Překryv brání osamostatnění hraničních vět: fakt rozdělený do dvou chunků je kompletní alespoň v jednom. Nad 20 % znovu embedujete příliš velkou část korpusu za klesající přínos. Většina týmů skončí na 10 % a už se k tomu nevrací.

Je sémantické chunkování lepší než chunkování pevné velikosti?

Jen těsně, a za dvojnásobnou cenu embeddingů. Benchmark Chromy z července 2024 ukázal clusterový sémantický chunker na recallu 89,0 % a precizi 6,7 % proti recallu 88,5 % a precizi 7,0 % u rekurzivního při stejné velikosti tokenů, přičemž jeho nejlepší výsledek precize 8,0 % pochází z jiného nastavení vyhledávání. Vyplatí se u tématicky pestrých korpusů; u homogenních sad dokumentů se obhajuje těžko.

Závisí velikost chunku na embeddingovém modelu?

Ano. Modely se stropem 512 vstupních tokenů (BGE, Cohere v3) vyžadují chunky výrazně pod 512, protože oříznutí je tiché. Modely se stropy 8 192+ snesou větší chunky, ale neodmění je; kvalita embeddingu degraduje ředěním ještě před stropem. Počáteční body pro jednotlivé modely najdete v párovací tabulce výše.

Jak chunkovat kód pro RAG systém?

Dělte podle hranic AST (definice funkcí a tříd), ne podle počtu tokenů. Každý chunk držte na 256-512 tokenech na funkci, přidejte na začátek blok importů souboru a podpis obklopující třídy a použijte nulový překryv, protože funkce jsou soběstačné jednotky. CodeSplitter LlamaIndexu i jazykově povědomé splittery LangChainu to zvládnou.

Co je late chunking?

Late chunking nejdřív embeduje celý dokument dlouhokontextovým modelem a pak sdružuje tokenové embeddingy do vektorů chunků. Každý embedding chunku nese kontext celého dokumentu, což řeší problém „co znamená ‚to'?" Představili ho Günther a kol. (arXiv 2409.04701, září 2024). Žádný veřejný head-to-head benchmark zatím přínos nekvantifikuje.

Jak chunkovat dokumenty v jiných jazycích než angličtině?

Počty tokenů nejsou jazykově neutrální. Stejná věta zabrala v turečtině a japonštině 2,7× více tokenů než v angličtině a v arabštině 3,9× (tiktoken cl100k_base). Pevný rozpočet 512 tokenů tiše dává neanglickým chunkům méně významu. Chunkujte podle počtu znaků nebo vět pro každý jazyk, nebo zvyšte rozpočet úměrně.

Jak poznám, že moje chunkování skutečně funguje?

Postavte eval sadu o 20-50 otázkách z reálných uživatelských dotazů, než se splitteru vůbec dotknete. Proti současným chunkům změřte hit@5 a MRR. Změňte jednu proměnnou (velikost, překryv, strategii), spusťte znovu, porovnejte. Bez eval sady ladíte podle pocitu. Dwacet otázek na start stačí.

Shrnutí

• Začněte rekurzivním znakovým chunkováním na 512 tokenech s 10% překryvem. Správný default pro prostý text.
• Napříč čtyřmi rodinami splitterů, které kdy někdo změřil, posouvá 472 dotazů Chromy recall zhruba o 5 bodů a precizi několikanásobně víc. Laďte nejdřív precizi a náklady.
• Slaďte velikost chunku se vstupním stropem embeddingového modelu. Model se stropem 512 tokenů vyžaduje chunky pod 512.
• Obohaťte chunky kontextem (pokles míry selhání Anthropicu z 5,7 % na 3,7 %) dřív, než budete přeladěte splitter.
• Nejdřív postavte eval sadu. Každé rozhodnutí o splitteru bez čísla před a po je odhad.

Pro celou pipeline kolem vaší volby chunkování viz postavte RAG aplikaci od začátku do konce. Stále se rozhodujete mezi vyhledáváním a doladěním? RAG vs. doladění rozebírá, kdy vyhrává které.