Strategii de chunking pentru RAG: cum împarți documentele

RAG-ul tău e doar atât de bun cât sunt bucățile pe care le regăsește. Înainte ca modelul să formuleze un răspuns, sistemul caută în baza ta de cunoștințe și scoate câteva fragmente de text — iar felul în care ai tăiat documentele în acele fragmente decide, mai mult decât aproape orice alt parametru, dacă răspunsul iese corect sau halucinat. Asta e chunking-ul: procesul prin care spargi documentele în bucăți suficient de mici cât să încapă în context și suficient de coerente cât să rămână utile la căutare.

În articolul despre de ce eșuează RAG în producție ai văzut că majoritatea problemelor nu vin din model, ci din retrieval. Chunking-ul greșit e una dintre cauzele cele mai frecvente și, din fericire, una dintre cele mai ieftine de reparat — nu cere reantrenare, nu cere alt model, doar o decizie mai bună la indexare. Mai jos găsești cele patru strategii de bază, numerele care contează la dimensiune și overlap, și cum alegi în funcție de tipul de documente pe care le ai.

Ce înseamnă chunking și de ce decide calitatea retrieval-ului

Un sistem RAG nu trimite modelului întreaga ta documentație. Ar fi imposibil: nu ar încăpea în fereastra de context și ar costa enorm la fiecare întrebare. În schimb, la indexare, documentele sunt tăiate în bucăți, fiecare bucată e transformată într-un vector (embedding) și stocată. La interogare, întrebarea utilizatorului devine și ea un vector, iar sistemul aduce bucățile cu vectorul cel mai apropiat.

Aici e capcana: bucata e și unitatea de regăsire, și unitatea de context. Dacă o tai prea mare, vectorul ei amestecă mai multe idei și se potrivește slab cu orice întrebare punctuală — precizia scade. Dacă o tai prea mic, fiecare bucată e curată, dar pierde firul: o frază rămâne fără subiectul din propoziția anterioară, o cifră rămâne fără anul la care se referă. Iar dacă tai exact prin mijlocul unei idei, niciuna dintre cele două bucăți rezultate nu mai conține răspunsul complet. Toată arta chunking-ului e să găsești granițele care păstrează ideile întregi.

Cele patru strategii de bază

Există zeci de variații, dar aproape toate pornesc de la patru abordări. Le poți vedea una lângă alta mai jos, apoi le iei pe rând.

Fixed-size: tai la fiecare N tokeni

Cea mai simplă metodă: stabilești o lungime fixă — să zicem 300 de tokeni — și tai documentul la fiecare 300, cu un mic overlap între bucăți. E exact abordarea din lucrarea care a introdus termenul RAG (Lewis et al., 2020), unde corpusul era împărțit în pasaje disjuncte de aproximativ 100 de cuvinte.

Avantajul e că e rapidă, previzibilă și nu costă nimic la calcul. Dezavantajul e că nu are nicio idee despre conținut: taie cu plăcere prin mijlocul unei propoziții, al unei celule de tabel sau al unei funcții. Rămâne însă alegerea corectă pentru text fără structură clară — loguri, transcrieri de apeluri, fluxuri de chat — unde nu există oricum granițe naturale de respectat.

Recursive: respectă structura textului

Strategia implicită pragmatică pentru proză. Un splitter recursiv (cel mai cunoscut e RecursiveCharacterTextSplitter) încearcă să taie întâi pe granițe mari — paragrafe — și coboară la propoziții, apoi la cuvinte, doar dacă bucata e încă prea mare. Rezultatul: rămâi cu paragrafe întregi cât timp încap în limita ta, și abia când un paragraf e enorm îl spargi mai fin.

E un compromis bun pentru majoritatea documentelor text și ar trebui să fie punctul tău de plecare. Limita lui: cunoaște structura sintactică (unde se termină un paragraf), nu cea semantică (unde se schimbă subiectul). Două paragrafe care vorbesc despre același lucru pot ajunge în bucăți separate, iar o schimbare bruscă de temă în mijlocul unui paragraf trece neobservată.

Semantic: tai unde se schimbă sensul

Aici lași embedding-urile să decidă granițele. Calculezi un vector pentru fiecare propoziție, apoi grupezi propozițiile consecutive câtă vreme rămân similare semantic; când similaritatea scade brusc, pui o graniță. În teorie e ideal: fiecare bucată e o unitate de sens coerentă.

În practică, lucrurile sunt mai nuanțate. Întâi, e scump: un document de 10.000 de cuvinte cere 200–300 de embedding-uri suplimentare doar ca să-i găsești granițele. Apoi, granițele sunt instabile — recalculezi cu altă versiune de model de embedding și obții alte tăieturi, ceea ce complică reindexarea. Și, surprinzător, nu câștigă mereu: mai multe evaluări recente (Qu et al., 2025, și lucrări prezentate la NAACL 2025) au găsit că un simplu fixed-size de ~200 de cuvinte egalează sau bate chunking-ul semantic pe seturi de întrebări reale, iar experimentele publicate de Chroma arată că diferența dintre strategii poate fi de până la 9 puncte procentuale în orice direcție, în funcție de corpus. Există și implementări mai inteligente bazate pe LLM care raportează recall ridicat (în jur de 0,92 față de ~0,85–0,89 pentru recursive), dar cu un cost de calcul pe măsură. Pe scurt: tratează semantic chunking-ul ca pe o optimizare pe care o testezi, nu ca pe un default.

Document-aware: respectă structura existentă

Dacă documentele tale au deja o structură — titluri Markdown, secțiuni HTML, articole de contract, blocuri de cod — folosește-o. Un splitter care respectă structura (de exemplu MarkdownHeaderTextSplitter) taie pe titluri și subtitluri, nu rupe niciodată un bloc de cod sau un tabel în două, și păstrează contextul ierarhic (sub ce capitol se afla bucata).

E adesea cel mai mare câștig la cel mai mic preț: nu costă embedding-uri în plus ca semantic, dar elimină exact tăieturile care strică totul — codul rupt la jumătate, tabelul fără antet, clauza fără numărul ei. Singura condiție e ca documentele să aibă o structură de respectat. Pentru un PDF scanat fără marcaje, nu ai de unde.

Chunk size și overlap: numerele care contează

Dincolo de strategie, ai două butoane numerice: cât de mari sunt bucățile și cât se suprapun.

Pentru dimensiune, zona practică în care lucrează majoritatea sistemelor e 200–500 de tokeni per bucată. Sub această zonă, bucățile devin fragmente fără context; peste ea, începi să plătești de două ori. Plătești în precizie, fiindcă un vector care acoperă 1.500 de tokeni amestecă prea multe idei ca să se potrivească exact cu o întrebare. Și plătești în bani: dacă aduci 8 bucăți a câte 1.500 de tokeni, ai pus 12.000 de tokeni în prompt la fiecare întrebare, iar acel cost de inferență domină factura. Regula bună e să potrivești dimensiunea cu tipul de întrebare — întrebări factuale scurte preferă bucăți mici și precise; întrebări analitice, care cer să legi mai multe idei, preferă bucăți mai mari.

Pentru overlap, un suprapus de 10–20% între bucăți vecine e suficient. Rostul lui e să prindă faptele care cad fix pe graniță: o frază a cărei jumătate ar fi rămas într-o bucată și cealaltă jumătate în următoarea. Mai mult overlap nu strică precizia, dar îți umflă inutil numărul de bucăți și costul de stocare.

Mai e un plafon tehnic de care trebuie să ții cont: modelele de embedding au o limită dură de intrare. Familia OpenAI text-embedding-3 acceptă maximum 8.191 de tokeni per intrare, iar tot ce trece peste e trunchiat tăcut — nu primești o eroare, primești un vector calculat doar pe primii 8.191 de tokeni. Dacă o bucată depășește limita din greșeală, jumătatea ei pur și simplu nu e indexată, și nu afli până nu căutarea dă greș.

Cum alegi în funcție de tipul documentului

Nu există o strategie câștigătoare universală; există strategia potrivită pentru ce ai pe disc. Iată cum mapezi tipul de conținut pe abordare:

• Cod: tăiere care respectă structura, pe funcție sau clasă, niciodată în mijlocul unui bloc. O funcție ruptă în două e inutilă la regăsire. Dacă construiești un asistent peste propriul codebase — vezi cum arată asta în RAG cu Next.js și Vercel AI SDK — păstrarea blocurilor întregi e ne-negociabilă.
• Contracte și documente juridice: tăiere pe clauză sau pe articol. Granițele legale sunt deja definite în document; respectă-le și fiecare bucată rămâne o unitate care are sens singură.
• Documentație tehnică (Markdown, HTML): tăiere pe titluri. Structura există deja și e exact harta de care ai nevoie; un splitter pe headere face aproape toată munca.
• Loguri și transcrieri: fixed-size pe tokeni. Nu au structură de respectat, așa că simplitatea câștigă.
• Bază de cunoștințe mixtă: pornește cu recursive ca linie de bază, măsoară, apoi testează semantic doar pe segmentele unde recursive dă rezultate slabe.

Meta-regula care le leagă pe toate: începe simplu, adaugă structură, complică doar pe bază de măsurători. Pornește de la recursive, adaugă conștientizarea structurii acolo unde documentele o au, și ajunge la semantic sau la tehnicile avansate de mai jos doar după ce ai numere care arată că merită. Iar ca să ai numere, măsoară retrieval-ul cu metrici ca recall@k, MRR sau faithfulness — nu te baza pe impresia că „pare mai bine”.

Dincolo de cele patru: contextual retrieval și late chunking

Toate strategiile de mai sus au un punct slab comun: în clipa în care tai o bucată din document, bucata își uită originea. O propoziție de tipul „cei peste 3,85 milioane de locuitori o fac cel mai populat oraș din UE” e perfect clară în context, dar ca bucată izolată nu mai spune despre care oraș e vorba — așa că la o căutare după „Berlin” nu se potrivește. Două tehnici recente atacă exact această pierdere de context.

Contextual retrieval, propus de Anthropic în septembrie 2024, adaugă în fața fiecărei bucăți un scurt context generat de un model — 50–100 de tokeni care explică de unde vine bucata („Fragment dintr-un raport Acme pe T2 2023, despre…”) — înainte de a o transforma în embedding. Cifrele raportate sunt notabile: doar embedding-urile contextuale reduc rata de eșec la regăsire (procentul de întrebări pentru care bucata corectă nu apare în top 20) cu 35%, de la 5,7% la 3,7%. Combinate cu o căutare hibridă pe bază de BM25 contextual, reducerea ajunge la 49%; adăugând și un pas de reranking, la 67% — adică o rată de eșec de 1,9%. Costul generării contextelor e ținut sub control prin prompt caching.

Late chunking, descris de echipa Jina AI (Günther et al., 2024), inversează ordinea. În loc să tai întâi și să faci embedding pe fiecare bucată separat, treci întreg documentul printr-un model de embedding cu context lung (jina-embeddings acceptă până la 8.192 de tokeni), obții embedding-uri la nivel de token care au „văzut” tot documentul, și abia apoi aplici granițele și faci media (pooling) per bucată. Fiecare bucată rezultată poartă în vectorul ei contextul întregului document, așa că exemplul cu orașul se rezolvă de la sine: vectorul fragmentului „știe” că e vorba despre Berlin chiar dacă numele nu apare în el.

Niciuna nu e gratuită — contextual retrieval cere apeluri suplimentare la un model la indexare, late chunking cere un model cu context lung — dar ambele atacă un punct de eșec pe care simpla alegere a dimensiunii nu îl rezolvă. Căutarea hibridă și reranking-ul menționate aici sunt un subiect în sine, tratat separat.

Cât te costă alegerea

Vestea bună: embedding-ul în sine e ieftin. text-embedding-3-small de la OpenAI costă 0,02 USD la fiecare milion de tokeni de intrare (0,01 USD în regim batch) și produce vectori de 1.536 de dimensiuni; varianta large costă 0,13 USD pe milion, cu 3.072 de dimensiuni; vechiul ada-002 rămâne la 0,10 USD pe milion. Toate sunt facturate doar la intrare și au aceeași limită de 8.191 de tokeni. În cifre concrete: un corpus de 100.000 de documente se indexează pentru sub 3 USD pe model-ul small — embedding-ul nu e linia care îți sparge bugetul.

Costul real al deciziei de chunking e în altă parte. Primul e reindexarea: dacă schimbi strategia sau modelul de embedding, trebuie să recalculezi vectorii pentru tot corpusul, nu doar pentru documentele noi. Al doilea sunt multiplicatorii: semantic chunking adaugă embedding-uri pentru găsirea granițelor, contextual retrieval adaugă apeluri la un LLM pentru fiecare bucată — fiecare strat mărește costul de indexare. Al treilea, și cel mai ușor de uitat, e costul din aval: dimensiunea bucății stabilește câți tokeni intră în fiecare prompt, iar acela e costul pe care îl plătești la fiecare întrebare, nu o singură dată la indexare. Pentru o estimare completă a tuturor componentelor, vezi cât costă un sistem RAG.

Întrebări frecvente

Care e cea mai bună strategie de chunking? Nu există una universală. Pentru majoritatea documentelor text, recursive e cel mai bun punct de plecare; dacă documentele au structură (titluri, cod, clauze), tăierea care respectă structura aduce cel mai mare câștig cu cel mai mic efort. Semantic și tehnicile avansate merită testate, dar abia după ce ai măsurat că variantele simple nu-ți ajung.

Ce dimensiune de chunk ar trebui să folosesc? Pornește din zona 200–500 de tokeni cu 10–20% overlap și ajustează după tipul de întrebări. Întrebări factuale scurte funcționează mai bine cu bucăți mici; întrebări analitice, care cer legarea mai multor idei, cu bucăți mai mari. Tratează valorile ca punct de plecare pe care îl calibrezi prin măsurare, nu ca pe o constantă.

De ce am nevoie de overlap între bucăți? Ca să nu pierzi faptele care cad fix pe graniță dintre două bucăți. Un overlap de 10–20% face ca o frază tăiată la mijloc să apară întreagă în cel puțin una dintre bucăți. Mai mult de atât doar îți crește numărul de bucăți și costul, fără câștig de precizie.

Chunking-ul semantic merită complexitatea? Uneori, dar nu presupune că da. Evaluări recente au găsit că fixed-size simplu îl egalează sau îl bate pe multe seturi de date reale, iar costul suplimentar de embedding și instabilitatea granițelor la schimbarea modelului sunt reale. Testează-l comparativ pe corpusul tău înainte să-l adopți.

Ce se întâmplă dacă o bucată depășește limita modelului de embedding? E trunchiată tăcut. Modelele OpenAI text-embedding-3 acceptă maximum 8.191 de tokeni; tot ce trece peste e ignorat fără nicio eroare, iar vectorul rezultat reprezintă doar începutul bucății. Asigură-te că dimensiunea maximă de chunk rămâne confortabil sub plafon.

Cum știu dacă chunking-ul meu e bun? Măsoară retrieval-ul, nu doar răspunsul final. Metrici ca recall@k (apare bucata corectă în primele k rezultate?), MRR și faithfulness îți spun dacă problema e la regăsire sau în altă parte. Fără măsurare, optimizezi pe ghicite.

Pasul următor

Chunking-ul e prima pârghie pe care o reglezi când retrieval-ul dă rezultate slabe, fiindcă e ieftin de schimbat și are impact direct. Dar e o singură piesă dintr-un sistem care trebuie evaluat și securizat ca întreg. Pentru restul pieselor — de la evaluarea riguroasă a calității până la securitatea datelor — explorează seria RAG în producție, sau vezi cum arată o implementare completă în pagina de servicii AI și RAG.