Vinster:
- Utvärdera numeriskt chunkstorlek, överlappning och semantiska chunking-avvägningar
- Att välja lämplig chunking-strategi för olika dokumenttyper (PDF, tabell, kod, chattlogg)
- Förstärk hämtningskvaliteten och filtreringen genom att lägga till metadata till varje bit
Detta är det mest förbisedda men mest avgörande steget i RAG: hur du bryter ner dokumentet. Detta kallas chunking. Även om du ger samma dokument till samma modell, på grund av dålig chunking returnerar hämtningen fel bit och modellen kommer aldrig att ge ett bra svar. I den här enheten tar vi upp fragmenteringsstrategier, hur man anpassar dem efter dokumenttyp och hur man lägger till meningsfull metadata till varje fragment.
Varför strimlar vi?
Det finns tre skäl. Först konverterar inbäddningsmodeller text upp till en viss längd till en meningsfull vektor; Om ett helt kapitel på 40 sidor är inpackat i en enda vektor, blir betydelsen "suddig". För det andra vill vi ge modellen endast den del som behövs som sammanhang; att lämna över hela dokumentet är dyrt och distraherande. För det tredje, för att hämtning ska vara exakt måste sökenheten vara liten och fokuserad.
Så chunk är den minsta enheten för hämtning. Den ska inte vara för stor eller för liten – precis lagom.
Klumpstorlek och överlappsbalans
Det finns två huvudinställningar: bitstorlek (hur många tokens/ord kommer att finnas i en bit) och överlappning (delen som delas av angränsande bitar).
Mycket små bitar (t.ex. 100 tokens): fokuserad men frånkopplad från sammanhanget. Han säger "i 14 dagar", men vad 14 dagar är lämnas i föregående mening. Mycket stora bitar (t.ex. 2000 tokens): bevarar sammanhang men många trådar blandas in; inbäddning blir rörigt och irrelevanta ämnen samlas.
Överlappning löser gränsproblemet. Om en mening faller exakt på gränsen mellan två delar delas den i två utan att överlappa varandra och dess betydelse går förlorad. Överlappning av 50-100 tokens säkerställer att informationen som faller inom gränsen förblir intakt i minst en del.
Klumpstorlek
Fördel
Nackdel
lämpligt innehåll
Liten (100-250 tokens)
Hög känslighet, fokuserad
Sammanhanget kan bryta
FAQ, korta artiklar, definitioner
Medium (300–600 tokens)
Balans; de flesta scenarier
—
Rutiner, policytexter
Stora (800-1500 tokens)
Kontextintegritet
suddig inbäddning
Berättande, långa förklaringar
Tips: Om du inte vet var du ska börja, börja med 400-500 token chunk och 50-80 token överlappning; mät och justera sedan med dina egna data. Den "rätta" storleken är inte universell, det beror på sammanhanget.
Chunking Strategier
Fast storlek: Beskär texten var N-symbol. Det är enkelt och snabbt, men kan avbryta mitten av meningen.
Separatorbaserad (rekursiv/separator): Delar efter stycke och sedan meningsgränser; Det bevarar bättre betydelsens integritet. De flesta produktionssystem börjar med detta.
Semantisk chunking: Den tittar på meningarnas inbäddningar och delar upp dem där ämnesändringen sker. Det är den högsta kvaliteten men dyraste metoden; Med stora volymer ökar transaktionskostnaderna.
Strukturmedveten: Använder dokumentstruktur som rubriker, avsnitt, tabeller. Att till exempel dela upp ett Markdown-dokument efter rubriker säkerställer att varje del har sin egen rubrik.
Anpassning efter dokumenttyp
Alla dokument är inte likadana. Strategin varierar beroende på typ:
- PDF/policytext: Bokmärkesbaserad, medelstor. Rensa upprepningar på sidan upp/botten (sidhuvud/sidfot).
- Tabeller: Ta inte linjen ur sitt sammanhang; behåll varje rad med rubrikinformation ("Artikel: X, Pris: Y, Lager: Z"). Att konvertera råtabellen till vanlig text är ofta viktigt.
- Kod: Uppdelad efter funktion/klassgränser; Klipp inte en funktion ur vägen.
- Chatt/biljettinspelning: Dela upp efter meddelande eller konversationsrunda; Behåll kunskap om vem som sa vad.
# parentesbaserade chunking (konceptuella) chunks = bol( text, target_size=450, # token overlap=70, # token parentes=["\n\n", "\n", ". ", " "] # stycket först, ordet sist)
Lägg till metadata till varje spår
Chunking är inte bara "dela"; är att berika varje del. Varje tagg du fäster på banan är guld värd för framtida filtrering och källhänvisning.
# Enriched chunk (konceptuell){ "text": "Årlig betald ledighet är 14 dagar med 1-5 års tjänstgöring...", "metadata": { "source": "ik_el_kitabi_v7.pdf", "section": "5.2 Annual Leave", "page": 23, "date": "6", "IK:privacy", "2025:privacy" "internt" }}
En annan kraftfull teknik är att lägga till en kontextuell rubrik: skriv titeln på kapitlet som det tillhör i början av varje del. Således är även ett osammanhängande stycke som "I 14 dagar" både bättre inbäddat och mer meningsfullt som "Annual Leave - 14 days."
Svag chunking / Stark chunking
Svag (blind hardcut, inga metadata):
Trunkera text var 1000:e tecken. Behåll bara texten.# Resultat: tabeller delas på mitten, "14 dagar" förblir utan kontext,# det är inte känt vilket dokument det kom ifrån, inget filter kan göras.
Kraftfull (strukturmedveten + rubrik + metadata):
Dela upp dokumentet efter rubriker; lägg till avsnittsrubrik till varje del; bifoga källa, sida, datum och sekretessmetadata; konvertera tabellrader till vanlig text med sina rubriker.# Resultat: fokuserad, kontextuell, filtrerbar, källbar.
Tre minifodral
Fall 1 — Målningskatastrof. Ett finansteam delade upp den 200 sidor långa prislistan med blind hard cutting; Tabellraderna delades upp slumpmässigt. "Vad är priset på produkt X?" Modellen läste fel rad och gav fel pris (9 av 12 fall har fel). När jag konverterade tabellraderna till vanlig text i formatet "Produkt: … | Pris: … | Enhet: …” minskade felet till 0 av 12.
Fall 2 — Extremt stor bit. I en wiki är varje sida gjord av en enda bit (vissa säger 3 000 tokens). Inbäddningen är suddig eftersom det finns "ledighet", "övertid" och "lön" på en sida; Arbetstidssektionen kom också in i fråga om ledighetsfrågan. När sidorna delades upp i medelstorlek efter titel ökade recall@5 från 64 % till 91 %.
Fall 3 — Avkortad mening utan överlappning. 250 token fast snitt för ett juridiskt team, ingen överlappning. En kritisk definition föll precis på gränsen mellan två delar och delade i två; Varken det ena eller det andra innehåller det fullständiga svaret. När 60 tokens överlappning lades till förblev samma definition intakt i ett stycke och det korrekta svaret returnerades.
Vanliga misstag
- Blind fast snitt: Delar meningar och tabeller på mitten; mening går förlorad.
- Lämnar överlappningen vid noll: Information som faller på gränsen delas upp och går förlorad.
- Lägger inte till metadata: Filtrering och källvisning blir omöjliga.
- Lämna tabeller råa: Modellen kan inte lösa tabellstrukturen; Konvertera rader till vanlig text.
- Att införa en strategi: PDF, kod och tabell delas inte upp med samma metod; Anpassa sig till genren.
Varning: Ställ inte in Chunking en gång och glöm det. Mät om hämtningskvaliteten när nya dokumenttyper anländer (biljetter från ett nytt system, skannade PDF-filer). Dålig indata betyder dåligt svar ("skräp in, skräp ut").
Sammanfattningsvis
- Chunk är den minsta enheten för hämtning; Varken för stor eller för liten – den ska balanseras efter innehållet.
- Bitstorlek indikerar balans mellan fokus och kontext; Överlappning hanterar gränsförlust.
- Bracket-baserad och strukturmedveten chunking är utgångspunkten för de flesta generationssystem; semantisk chunking är bra kvalitet men dyrt.
- Typer som tabell, manus och chatt kräver sina egna strategier; Konvertera tabeller till vanlig text.
- Lägg till metadata för källa/datum/kapitel/sekretess och avsnittstitel till varje spår; Detta är grunden för filtrering och citering.
Applikationsuppgift
Dela en del av dokumentet du väljer på tre olika sätt: (1) små bitar med 200 tokens, (2) medelstora bitar med 500 tokens (70 tokens överlappning), (3) enstaka stora bitar. Ställ samma 3 frågor för varje strategi, markera manuellt vilken del du ska ta in och skriv ner resonemanget för vilken strategi som fungerar bäst för det dokumentet. Lägg sedan till minst fyra metadatafält och en "kapiteltitel" till varje spår. Om dokumentet innehåller en tabell, konvertera en tabellrad till vanlig text i formatet "fält:värde".
checklista
- [ ] Jag kan säga att chunk är den minsta enheten för hämtning och storlek är fokus-kontextbalansen.
- [ ] Jag vet varför överlappning förhindrar gränsförlust.
- [ ] Jag kan skilja mellan parentesbaserad, semantisk och strukturmedveten chunking.
- [ ] Jag kan anpassa strategin för tabell, kod och chatt.
- [ ] Jag förstärker hämtningen genom att lägga till metadata och kapitelrubrik till varje spår.