Strategji chunking për RAG që përmirësojnë vërtet përgjigjet

Kur një sistem RAG jep një përgjigje të gabuar ose të paqartë, zakonisht fajësohet modeli dhe kërkohet një më i madh. Nëntë herë në dhjetë problemi është më herët: teksti i duhur nuk u gjet kurrë, sepse ishte ndarë keq. Strategjitë e chunking-ut për RAG vendosin çfarë lejohet të shohë modeli.

Këto janë qasjet që përdor kur ndërtoj sisteme RAG për klientë, afërsisht me radhën që i provoj.

Pse chunking-u ka më shumë rëndësi se modeli

Kërkimi punon mbi copa (chunks), jo mbi dokumente. Çdo copë kthehet në një embedding, dhe kërkimi kthen copat që janë më afër pyetjes. Nga kjo dalin dy mënyra dështimi:

• Copa shumë të mëdha — një embedding duhet të përfaqësojë pesë ide të ndryshme, ndaj nuk përputhet fort me asnjërën. Përgjigjja humbet në zhurmë.
• Copa shumë të vogla — gjendet fjalia që përputhet me pyetjen, por fjalia që e shpjegon është në copën tjetër dhe nuk vjen kurrë.

Çdo strategji chunking-u është një mënyrë për të lundruar mes këtyre dyjave.

Strategjia 1: copa me madhësi fikse dhe mbivendosje

Ndaj çdo N token, duke përsëritur disa token të fundit të çdo cope në fillim të tjetrës. Është standardi në shumicën e tutorialeve sepse është i thjeshtë dhe punon me çdo tekst.

Pika ime e nisjes është rreth 400–600 token me 10–15% mbivendosje. Është bazë, jo zgjidhje: ndarja fikse e pret me qejf një tabelë në mes ose e ndan titullin nga paragrafi që prezanton. Përdore për tekst pa strukturë — transkripte, email-e, faqe të skrapuara — dhe për të pasur diçka që punon ditën e parë.

Strategjia 2: chunking sipas strukturës

Shumica e dokumenteve të biznesit të tregojnë vetë ku janë kufijtë: tituj, seksione, pika liste, rreshta tabelash, pyetje FAQ. Ndarja sipas kësaj strukture jep copa ku secila mban një ide të plotë.

• Markdown dhe HTML — ndaj te h2/h3 dhe mbaj rrugën e titujve (“Kthimet › Porositë ndërkombëtare”) në çdo copë.
• Manuale dhe kontrata PDF — ndaj sipas neneve dhe seksioneve të numëruara, jo sipas faqeve.
• FAQ dhe baza njohurish — një pyetje me përgjigjen e saj për copë, kurrë të ndara.
• Tabelat — mbaj rreshtin e titujve me çdo grup rreshtash, ose ktheje çdo rresht në fjali.

Nëse një seksion është ende shumë i gjatë, bie te ndarja fikse vetëm brenda atij seksioni. Ky hibrid është ai që lëshoj më shpesh.

Strategjia 3: chunking semantik

Chunking-u semantik bën embedding për çdo fjali dhe nis një copë të re aty ku ndryshon kuptimi — ku bie ngjashmëria mes fjalive fqinje. Ndihmon te tekste të gjata e pak të strukturuara, si intervista ose raporte që kalojnë nga një temë te tjetra.

Kushton më shumë për indeksim dhe debugohet më vështirë, ndaj e përdor vetëm kur ndarja sipas strukturës dështon qartë. Rrallë është gjëja e parë për t’u provuar.

Strategjia 4: copa të vogla për kërkim, copa të mëdha për përgjigje

Kjo është ajo që rregullon më shumë probleme reale. Indekson copa të vogla e të sakta — një paragraf ose disa fjali — sepse përputhen fort me pyetjet. Por kur gjendet njëra, modelit i jep seksionin prind.

Merr kërkim të saktë dhe kontekst të mjaftueshëm për një përgjigje të mirë. Implementimi është i thjeshtë: ruaj një parent_id në çdo copë të vogël dhe zëvendësoje me prindin para se të ndërtosh prompt-in, duke hequr dublikatat kur disa copa ndajnë të njëjtin prind.

Metadata është pjesë e copës

Një copë pa kontekst është një paragraf që pluskon në hapësirë. Për çdo copë ruaj:

• Titullin e dokumentit dhe rrugën e titujve, të shtuara në fillim të tekstit para embedding-ut
• URL-në ose skedarin burim, për citime
• ID-në e tenant-it ose përdoruesit, për lejet
• Gjuhën, datën dhe llojin e dokumentit, për filtrim

Filtrimi me metadata para kërkimit vektorial — “vetëm dokumentet e këtij klienti, vetëm versioni aktual i politikës” — shpesh bën më shumë për cilësinë e përgjigjeve se çdo ndryshim te madhësia e copës. Është edhe mënyra si i mban të dhënat e një klienti jashtë përgjigjeve të një tjetri, siç e shpjegoj te RAG brenda një aplikacioni Laravel.

Strategji chunking-u për RAG: vlerat e mia fillestare

1. Nis me ndarje sipas strukturës, me ndarje fikse për seksionet e gjata.
2. Synoni 300–600 token për copë, 10–15% mbivendosje.
3. Shto titullin dhe rrugën e titujve në çdo copë para embedding-ut.
4. Shto kërkimin prind-fëmijë sapo përgjigjet duken “pothuajse të sakta, por pa kontekst”.
5. Filtro sipas tenant-it, gjuhës dhe versionit para kërkimit.

Mat para se të rregullosh

Mos e ndrysho madhësinë e copës me ndjesi. Ndërto një grup të vogël pyetjesh reale me pasazhin që duhet t’i përgjigjet secilës, dhe kontrollo nëse ai pasazh del te rezultatet e para. Ndrysho një gjë, riprovo, krahaso. Procesin e shpjegoj te si të vlerësosh një sistem RAG. Për një hyrje më teknike te konceptet bazë, udhëzuesi i Pinecone për chunking është një referencë e mirë.

Nëse asistenti yt vazhdon të përgjigjet nga faqja e gabuar e dokumentacionit, më dërgo disa shembuj — zgjidhja zakonisht është te chunking-u, dhe zakonisht vjen më shpejt nga ç’pret.