Strategii de chunking RAG: 7 metode, clasate după date de regăsire (2026)

Strategii de chunking RAG: 7 metode, clasate după date de regăsire (2026)

Strategiile de chunking RAG decid ce poate găsi retriever-ul tău înainte să ruleze măcar o singură interogare. Studiul Chroma din iulie 2024 a rulat 472 de interogări pe cinci corpusuri cu text-embedding-3-large, iar splitter-ul pe care îl alegi mută recall-ul cu aproximativ cinci puncte: 86,7% pentru un splitter simplu pe tokeni, 91,7% pentru cel bazat pe GPT-4o, cu cinci chunk-uri regăsite per interogare. Precizia oscilează mult mai puternic. De-a lungul întregului raport, ea variază de la 1,5% la 8,0%, ceea ce face din alegerea dimensiunii chunk-ului o decizie de cost deghizată în calitate, iar fiecare ghid din prima pagină listează aceleași șapte metode fără să arate care regăsește mai bine.

Idei principale

• Chunking-ul împarte documentele înainte de embedding; punctele de divizare decid ce poate și ce nu poate găsi retriever-ul tău.
• În studiul Chroma din iulie 2024 cu 472 de interogări, recall-ul a variat între 86,7% și 91,7% pentru splitter-ele măsurate.
• Precizia variază de câteva ori mai mult decât recall-ul, deci dimensiunea chunk-ului este în mare parte o decizie de cost pe tokeni.
• Începe cu 512 tokeni și 10% suprapunere, apoi reglează pe propriul set de evaluare.

Ce strategie de chunking RAG ar trebui să folosești? (Clasament)

Pentru majoritatea echipelor care construiesc pe text simplu, recursive character chunking la 512 tokeni cu 10% suprapunere este varianta implicită corectă. Respectă limitele de paragraf și de propoziție, nu costă nimic în plus și, în benchmark-ul Chroma cu 472 de interogări, a terminat la 3,2 puncte de recall în spatele splitter-ului bazat pe LLM. Abate-te de la ea doar când documentele tale au o structură puternică sau când setul de evaluare dovedește contrariul.

Interpretarea noastră: începe cu recursive character. În datele Chroma, se clasează doar după splittere-le pe cluster și pe LLM la recall, iar precizia de 3,9% a splitter-ului LLM înseamnă că trimiți generatorului de aproximativ două ori mai mult zgomot per token relevant. Majoritatea echipelor nu au o problemă de chunking; au o problemă de dimensiune a chunk-ului pe care nu au măsurat-o niciodată.

Ce spun de fapt datele despre dimensiunea chunk-ului?

Singura comparație publică directă între strategiile de chunking RAG este raportul tehnic Chroma „Evaluating Chunking Strategies for Retrieval" (Brandon Smith și Anton Troynikov, publicat pe 3 iulie 2024). Ei au rulat 472 de interogări pe 5 corpusuri (328.208 tokeni), au embedat totul cu OpenAI text-embedding-3-large și au regăsit 5 chunk-uri per interogare. Rândurile de mai jos provin din tabelul din anexa raportului pentru toate corpusurile, cu text-embedding-3-large și 5 chunk-uri regăsite, deci sunt direct comparabile între ele:

Tabelul principal de rezultate al Chroma, care raportează o setare diferită de regăsire, plasează cea mai bună precizie a chunker-ului pe cluster la 8,0% cu 87,3% recall și întinde intervalul de precizie al tuturor splitter-elor sale de la 1,5% (KamradtSemanticChunker) la 8,0%. Sursă: Chroma Research, Evaluating Chunking Strategies

„Introducing Contextual Retrieval" al Anthropic (publicat pe 19 septembrie 2024) atacă problema dintr-un unghi diferit. Rata lor de eșec la regăsirea top-20 de bază era 5,7%; doar embedding-urile contextuale au coborât-o la 3,7% (reducere de 35%), BM25 contextual peste a adus-o la 2,9% (49%), iar reranking-ul a împins-o la 1,9% (67%). Anthropic nu publică dimensiunea exactă a chunk-ului sau suprapunerea folosită, deci tratează-le ca dovezi la nivel de metodă, nu de dimensiune. Sursă: Anthropic, Contextual Retrieval.

Interpretarea noastră: trei concluzii din aritmetică. Prima, alegerea splitter-ului valorează recall real, iar Chroma o spune răspicat: unele strategii le întrec pe altele cu până la 9% la recall. De-a lungul tabelului principal de rezultate, recall-ul variază de la 83,6% (KamradtSemanticChunker) la 91,9% (LLMSemanticChunker), iar în rândurile retrieve-5 de mai sus se întinde tot între 86,7% și 91,7%. Precizia se mișcă de câteva ori mai mult pe aceleași date: de la 1,5% la 8,0%, o răspândire de 5,3x față de 1,1x-ul recall-ului. Deci recall-ul este locul unde câștigi câteva puncte, iar precizia și costul pe tokeni sunt locul unde alegerea chiar doare. A doua, splitter-ul bazat pe LLM cumpără recall maxim cu precizia minimă: plătești un apel LLM per document și trimiți generatorului mai mult zgomot. A treia, cifrele Anthropic arată că îmbogățirea chunk-urilor cu context (de la 5,7% la 3,7%) a mișcat rata de eșec mai mult decât orice alegere de splitter din tabelul Chroma. Îmbogățește chunk-urile înainte să reglezi din nou splitter-ul. Reranking-ul recuperează chunk-urile pe care splitter-ul tău le-a ciuntit, iar căutarea hibridă combină BM25 cu regăsirea vectorială, din același motiv.

Limite oneste: ambele studii folosesc un singur model de embedding, corpusuri doar în engleză și niciunul nu este un test controlat pe corpusul tău. De-a lungul celor 472 de interogări, diferența dintre cel mai bun și cel mai slab splitter a fost de aproximativ 5 puncte de recall la 5 chunk-uri regăsite și o diferență proporțional mult mai mare la precizie.

De ce dimensiunea chunk-ului decide calitatea regăsirii?

Dimensiunea chunk-ului stabilește granularitatea cheii tale de regăsire. Un chunk de 400 de tokeni produce un embedding focalizat care se potrivește cu interogări specifice; un chunk de 4.000 de tokeni face o medie pe multe subiecte și nu se potrivește precis cu nimic. Chunk-urile mici regăsesc pasajul exact, dar pot fragmenta un răspuns pe mai multe rezultate. Chunk-urile mari țin contextul laolaltă, dar slăbesc semnalul embedding-ului.

Și plafonul de context al modelului de embedding contează. Dacă modelul tău are un maxim de 512 tokeni la intrare și îi dai 800, coada este trunchiată silențios. Embedding-ul tău reprezintă două treimi din chunk. Nicio eroare în jurnal.

Apoi partea de generator. Liu și colaboratorii au arătat în „Lost in the Middle" (arXiv 2307.03172, 2023) că acuratețea LLM-ului scade cu peste 20% când documentul relevant stă în mijlocul unui context lung. Regăsirea a cinci chunk-uri de 1.000 de tokeni aruncă 5.000 de tokeni în prompt, iar răspunsul de care ai nevoie poate nimeri în poziția pe care modelul o citește cel mai prost. Chunk-urile mai mici țin pasajul relevant mai aproape de o poziție pe care modelul o manevrează bine.

Gândește-te ca la indexul unei biblioteci. O fișă pe care scrie „Secțiunea 4.2, paragraful 3: politica de rambursare" te duce la pagină. O fișă pe care scrie „totul despre comerțul din secolul XX" te duce la clădire. Embedding-ul tău este fișa. Construiește o aplicație RAG de la cap la coadă ca să vezi unde se află chunking-ul în pipeline și citește ghidul nostru de context engineering pentru cum chunk-urile regăsite devin tokeni de prompt. Ghidul de chunking al Pinecone încadrează același compromis din partea bazei de date vectoriale.

Chunking pe dimensiune fixă și recursive (începe de aici)

Dimensiunea fixă este linia de referință față de care măsori totul; recursive este ceea ce livrezi de fapt.

Chunking pe tokeni la dimensiune fixă

Împarte la fiecare N tokeni, indiferent de conținut.

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

Răspunsul potrivit pentru: text simplu fără structură de titluri, prototipuri rapide și orice comparație de referință. Nu este prost. Este grupul de control.

Chunking recursive character

RecursiveCharacterTextSplitter de la LangChain împarte pe o ierarhie de separatoare: întâi \n\n (paragrafe), apoi \n (linii), apoi . (propoziții), apoi (cuvinte). Fiecare chunk rămâne sub chunk_size respectând cea mai mare limită naturală care se potrivește.

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 de separatoare este partea pe care fiecare concurent o omite. Splitter-ul încearcă întâi \n\n și coboară la . doar când un paragraf depășește chunk_size. Dacă Markdown-ul tău are headere, adaugă "## " înainte de "\n\n" ca secțiunile să rămână intacte.

Aritmetica suprapunerii chunk-urilor: la 512 tokeni cu 50 de tokeni suprapunere, pasul este 462. Un document de 10.000 de tokeni produce ceil(10000 / 462) = 22 de chunk-uri. Total tokeni embedate: 22 x 512 = 11.264, adică re-embedezi aproximativ 12,6% din corpus ca suprapunere. Acesta este costul de stocare și de API pentru a împiedica propozițiile de la graniță să rămână izolate.

Cum funcționează chunking-ul semantic și merită costul?

Chunking-ul semantic embedează fiecare propoziție, măsoară distanța cosinus între embedding-urile propozițiilor vecine și împarte acolo unde acea distanță depășește un prag percentilic (de obicei percentila 95). Chunk-urile se rup la schimbările de subiect, nu la numărări arbitrare de tokeni. Notebook-ul lui Greg Kamradt „5 Levels of Text Splitting" a originat această abordare pe puncte de rupere percentilice, iar studiul Chroma îi benchmark-uiește chunkerele pe nume.

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)

Matematica costului este partea pe care nimeni nu o pune înainte. Chunking-ul semantic îți embedează corpusul de două ori: o dată pentru a calcula distanțele între propoziții și a găsi punctele de rupere, o dată pentru a embeda chunk-urile rezultate pentru indexare. La prețul OpenAI pentru text-embedding-3-large de $0,13 per 1M tokeni, un corpus de 10M tokeni costă $1,30 de indexat normal și $2,60 cu chunking semantic. Plătești dublu înainte să ruleze măcar o singură interogare.

Ce cumperi cu asta? În rândurile retrieve-5 ale Chroma, chunker-ul semantic pe cluster a atins 89,0% recall și 6,7% precizie, față de 88,5% și 7,0% pentru recursive la aceeași dimensiune de 200 de tokeni. În tabelul principal de rezultate, același chunker înregistrează cea mai bună precizie a studiului, 8,0%, la 87,3% recall. Jumătate de punct de recall într-o direcție sau alta și un rezultat de precizie care își schimbă semnul în funcție de setarea de regăsire pe care o citești, pentru dublul facturii de embedding. Verdictul nostru: chunking-ul semantic se plătește pe corpusuri cu subiecte diverse (arhive de știri, colecții de lucrări), unde limitele fixe rup în mod obișnuit în mijlocul subiectului. Pentru corpusuri omogene (documentație de produs, o singură bază de cunoștințe), recursive îți aduce 95% din calitate la jumătate din cost. Dacă rulezi modele de embedding local cu Ollama, costul dublei embedări scade la timp de calcul.

Chunking conștient de document: Markdown, HTML și cod

Împărțirea conștientă de structură folosește propriile limite ale documentului (headere, elemente de listă, definiții de funcții) în loc de numărări de caractere. Un H2 din Markdown este o limită semantică plasată deliberat de un om; un splitter pe caractere o face praf.

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

Pentru cod, limitele sunt noduri AST. NodeParsers de la LlamaIndex livrează splittere conștiente de limbaj care rup la definițiile de funcții și clase. Detaliul critic: ține blocul de importuri și semnătura clasei care le conține atașate de fiecare chunk de funcție. Un corp de funcție fără importurile sale este zgomot care nu poate fi embedat, deci adaugă-le pe ambele la începutul fiecărui chunk, iar embedding-ul va capta ce face funcția și de ce depinde.

Specific pentru RAG pe cod: împărțire pe limite AST, importuri adăugate la început, 256-512 tokeni per funcție, zero suprapunere.

Dar chunking-ul late, ierarhic și agentic?

Acestea sunt strategiile avansate de chunking RAG din spatele zgomotului despre „RAG 2.0" și toate trei stau la o acoperire SERP de 1/10.

Late chunking

Late chunking, introdus de Günther și colaboratorii în „Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models" (arXiv 2409.04701, septembrie 2024), embedează întâi tot documentul cu un model pe context lung, apoi grupează embedding-urile la nivel de token în vectori de chunk, astfel încât fiecare chunk poartă context din tot documentul, iar „costă 40 $/lună" știe la ce se referă „costă". Rezumatul pretinde regăsire superioară pe mai multe sarcini, dar nu publică nicio cifră de titlu pe care am putut-o verifica. Articolul Weaviate explică mecanica și se oprește și el înainte de o comparație controlată. Starea dovezilor: promițător, necuantificat.

Chunking ierarhic (părinte-copil)

Indexează chunk-uri mici (256 tokeni) pentru regăsire; returnează părintele (1.024 tokeni) generatorului. Retriever-ul găsește acul; generatorul primește carul cu fân din jur. Menții două niveluri de index și o mapare părinte-copil. Niciun benchmark public nu izolează efectul.

Chunking bazat pe LLM / agentic

LLMSemanticChunker din studiul Chroma folosește GPT-4o pentru a decide punctele de împărțire per document: 91,7% recall (cel mai mare) și 3,9% precizie (cea mai mică). Plătești un apel LLM per document la momentul indexării (aproximativ 100 $ pentru un corpus de 10.000 de documente) și trimiți generatorului mai mult zgomot. Păstrează-l pentru corpusuri cu adevărat neregulate: dosare juridice, PDF-uri scanate fără headere extrasibile.

Ce dimensiune de chunk se potrivește modelului tău de embedding?

Numărul maxim de tokeni la intrare al modelului tău de embedding este un plafon de trunchiere, nu o recomandare. Un model care acceptă 8.192 tokeni nu embedează mai bine la 8.192 decât la 512. Calitatea se degradează prin diluare cu mult înainte de plafon: modelul face o medie a semnificației pe mai mulți tokeni, iar vectorul plutește spre centrul de greutate al corpusului. Coloana de recomandări de mai jos este interpretarea Techsy, nu ghidajul vânzătorilor.

Surse: ghidul OpenAI embeddings, documentația Cohere embed, documentația Voyage embeddings, fișa modelului BGE.

Tiparul: modelele cu un plafon dur de 512 tokeni (Cohere v3, BGE) cer chunk-uri mult sub 512, pentru că trunchierea este silențioasă. Dă-i unuia 600 de tokeni și ultimii 88 dispar din embedding fără nicio eroare în jurnal. Modelele cu plafoane mari (OpenAI, Voyage, Cohere v4) tolerează chunk-uri mai mari, dar nu le răsplătesc. Lungimea maximă de intrare a unui model este o limită de trunchiere, nu o recomandare.

Asociază asta cu clasamentul nostru al celor mai bune modele de embedding pentru RAG, cu ce măsoară de fapt un scor MTEB și cu Voyage, OpenAI și Cohere embeddings puse față în față, înainte să te decizi la un model.

Cum faci chunking pe documente în alte limbi decât engleza?

Tokenizer-ele nu sunt neutre față de limbă. Petrov și colaboratorii au arătat în „Language Model Tokenizers Introduce Unfairness Between Languages" (arXiv 2305.15425, 2023) că același text tradus între limbi poate diferi ca lungime tokenizată cu până la 15x. Chiar și modelele la nivel de caracter și de octet arată o diferență de peste 4x pentru unele perechi de limbi. Un chunk de 512 tokeni ține mult mai puțin sens în turcă, arabă sau japoneză decât în engleză.

Iată aceeași propoziție tokenizată cu codificarea cl100k_base din tiktoken (tokenizer-ul 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

Numărătoare generată cu tiktoken cl100k_base, 30 iulie 2026.

Ghidaj practic: la o dimensiune fixă de 512 tokeni, chunk-urile tale în turcă și japoneză țin aproximativ 37% din sensul pe care îl țin chunk-urile în engleză, iar chunk-urile în arabă țin aproximativ 26%. Fă chunking după numărul de caractere sau de propoziții per limbă sau crește bugetul de tokeni proporțional (aproximativ 1.400 pentru turcă, 2.000 pentru arabă). Limbile CJK nu au granițe de cuvânt pe spații, deci splittere-le pe caractere se comportă diferit. Morfologia arabei înghesuie mai mulți marcatori gramaticali în tokeni singuri, umflând și mai mult numărătoarea.

Un arbore de decizie pentru alegerea strategiei de chunking

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

Trei rețete rapide. Chatbot pe documente: MarkdownHeaderTextSplitter la 512 tokeni, zero suprapunere, calea titlului în metadata. Asistent de căutare în cod: împărțire pe limite AST la 256-512 tokeni per funcție, importuri adăugate la început. Corpus enterprise mixt: direcționează după tipul documentului la ingestie și stochează în baza de date vectorială în care ții chunk-urile cu metadata de tip, pentru reglaj per tip mai târziu. Această direcționare per document este întregul chunking adaptiv pentru aplicații RAG.

Instrumente: LangChain vs LlamaIndex vs Chonkie

Nu vindem niciunul dintre acestea; primele trei pagini clasate pentru acest cuvânt cheie sunt bloguri ale vânzătorilor, cu CTA-uri de produs.

Surse: documentația LangChain, LlamaIndex NodeParsers, documentația Chonkie.

Toate trei implementează aceleași algoritmi de bază, deci alege pe baza a ce folosește deja pipeline-ul tău. Pentru stack-ul mai larg de instrumente RAG, dincolo de splittere, și Qdrant, Chroma și pgvector comparate pentru stocare, vezi ghidurile noastre de cluster.

Cum abordează Techsy chunking-ul

Pe build-urile RAG pentru clienți, echipa Techsy începe cu 512 tokeni și 10% suprapunere și nu atinge splitter-ul până nu am construit un set de evaluare cu 20-50 de întrebări din tichetele reale de suport ale clientului. Setul de evaluare vine primul; apoi schimbăm câte o variabilă pe rând: dimensiune, suprapunere, strategie. Nicio schimbare de splitter fără un număr înainte-și-după pe aceleași întrebări. Obține o consultație gratuită pentru o a doua pereche de ochi pe pipeline-ul tău de regăsire.

Despre autor

Mert Batur este Co-Fondator al Techsy.io, unde echipa livrează agenți AI, sisteme de automatizare și pipeline-uri de voce/SDR pentru clienți B2B. El scrie despre stack-ul de instrumente LLM pe care echipa Techsy îl folosește efectiv în producție, inclusiv despre lucrarea de RAG și regăsire din spatele build-urilor de baze de cunoștințe pentru clienți. Conectează-te pe LinkedIn.

Întrebări frecvente

Ce este chunking-ul în RAG?

Chunking-ul este pasul de preprocesare care împarte documentele în segmente mai mici înainte de embedding, astfel încât retriever-ul să poată potrivi interogările cu pasaje focalizate, nu cu fișiere întregi. Punctele de împărțire determină ce poate și ce nu poate găsi sistemul tău la momentul interogării.

Care este cea mai bună strategie de chunking pentru RAG?

Pentru majoritatea sistemelor de producție pe documente generale, chunking-ul recursive character la 512 tokeni cu 10% suprapunere este cea mai puternică variantă implicită. În studiul Chroma cu 472 de interogări (iulie 2024), a obținut 88,5% recall, la 3,2 puncte de cea mai scumpă metodă bazată pe LLM, fără niciun cost suplimentar.

Care este dimensiunea optimă a chunk-ului pentru RAG?

Începe cu 512 tokeni. Coboară la 256 dacă modelul tău de embedding are un plafon de 512 tokeni la intrare (Cohere v3, BGE) sau dacă interogările tale așteaptă răspunsuri de o singură propoziție. Urcă la 1.024 doar dacă setul tău de evaluare arată răspunsuri pe mai multe paragrafe care sunt fragmentate. Măsoară întotdeauna pe propriile întrebări.

Câtă suprapunere de chunk ar trebui să folosesc?

10-20% din dimensiunea chunk-ului (50-100 tokeni la 512). Suprapunerea împiedică propozițiile de la graniță să rămână izolate: un fapt împărțit între două chunk-uri apare complet în cel puțin unul. Peste 20%, re-embedezi prea mult din corpus pentru câștiguri descrescătoare. Majoritatea echipelor se opresc la 10% și nu se mai uită înapoi.

Chunking-ul semantic este mai bun decât cel pe dimensiune fixă?

Marginal, și cu dublul costului de embedding. Benchmark-ul Chroma din iulie 2024 a arătat chunker-ul semantic pe cluster la 89,0% recall și 6,7% precizie, față de 88,5% recall și 7,0% precizie pentru recursive la aceeași dimensiune de tokeni, cu cel mai bun rezultat de precizie al său, 8,0%, venind dintr-o setare diferită de regăsire. Merită pentru corpusuri cu subiecte diverse; greu de justificat pentru seturi de documente omogene.

Dimensiunea chunk-ului depinde de modelul de embedding?

Da. Modelele cu un plafon de intrare de 512 tokeni (BGE, Cohere v3) cer chunk-uri mult sub 512, pentru că trunchierea este silențioasă. Modelele cu plafoane de 8.192+ tolerează chunk-uri mai mari, dar nu le răsplătesc; calitatea embedding-ului se degradează prin diluare înainte de plafon. Vezi tabelul de asocieri de mai sus pentru punctele de pornire per model.

Cum fac chunking pe cod pentru un sistem RAG?

Împarte pe limite AST (definiții de funcții și clase) mai degrabă decât pe numărări de tokeni. Ține fiecare chunk la 256-512 tokeni per funcție, adaugă la început blocul de importuri al fișierului și semnătura clasei care le conține și folosește zero suprapunere, din moment ce funcțiile sunt unități autosuficiente. CodeSplitter de la LlamaIndex și splittere-le conștiente de limbaj de la LangChain fac ambele asta.

Ce este late chunking?

Late chunking embedează întâi tot documentul cu un model pe context lung, apoi grupează embedding-urile la nivel de token în vectori de chunk. Fiecare embedding de chunk poartă context din tot documentul, rezolvând problema „la ce se referă «costă»?". Introdus de Günther și colaboratorii (arXiv 2409.04701, septembrie 2024). Niciun benchmark public comparativ nu cuantifică încă câștigul.

Cum fac chunking pe documente în alte limbi decât engleza?

Numărătoarea tokenilor nu este neutră față de limbă. Aceeași propoziție a luat de 2,7x mai mulți tokeni în turcă și japoneză decât în engleză și de 3,9x în arabă (tiktoken cl100k_base). Un buget fix de 512 tokeni dă silențios mai puțin sens chunk-urilor în alte limbi decât engleza. Fă chunking după numărul de caractere sau de propoziții per limbă sau crește bugetul proporțional.

Cum știu dacă chunking-ul meu chiar funcționează?

Construiește un set de evaluare cu 20-50 de întrebări din interogările reale ale utilizatorilor înainte să atingi splitter-ul. Scor hit@5 și MRR pe chunk-urile tale curente. Schimbă o variabilă (dimensiune, suprapunere, strategie), rulează din nou, compară. Fără un set de evaluare, reglezi din simțire. Douăzeci de întrebări sunt suficiente pentru început.

Concluzia

• Începe cu chunking recursive character la 512 tokeni, 10% suprapunere. Varianta implicită corectă pentru text simplu.
• De-a lungul celor patru familii de splittere pe care le-a măsurat cineva, cele 472 de interogări ale Chroma mută recall-ul cu aproximativ 5 puncte și precizia de câteva ori mai mult. Reglează pentru precizie și cost mai întâi.
• Potrivește dimensiunea chunk-ului la plafonul de intrare al modelului tău de embedding. Un model cu plafon de 512 tokeni cere chunk-uri sub 512.
• Îmbogățește chunk-urile cu context (căderea ratei de eșec de la 5,7% la 3,7% a Anthropic) înainte să reglezi din nou splitter-ul.
• Construiește setul de evaluare primul. Fiecare decizie de splitter fără un număr înainte-și-după este o presupunere.

Pentru întregul pipeline din jurul alegerii tale de chunking, vezi construiește o aplicație RAG de la cap la coadă. Încă te decizi între regăsire și fine-tuning? RAG sau fine-tuning detaliază când câștigă fiecare.