Gevinster:
- Evaluer numerisk chunk-størrelse, overlapning og semantiske chunking-afvejninger
- Valg af passende chunking-strategi for forskellige dokumenttyper (PDF, tabel, kode, chatlog)
- Styrk genfindingskvalitet og filtrering ved at tilføje metadata til hver chunk
Dette er det mest oversete, men mest afgørende trin i RAG: hvordan du opdeler dokumentet. Dette kaldes chunking. Selvom du giver det samme dokument til den samme model, returnerer søgningen det forkerte stykke på grund af dårlig chunking, og modellen vil aldrig give et godt svar. I denne enhed dækker vi fragmenteringsstrategier, hvordan man tilpasser dem efter dokumenttype, og hvordan man tilføjer meningsfulde metadata til hvert fragment.
Hvorfor makulerer vi?
Der er tre grunde. For det første konverterer indlejringsmodeller tekst op til en vis længde til en meningsfuld vektor; Hvis et helt kapitel på 40 sider er proppet ind i en enkelt vektor, bliver betydningen "sløret". For det andet ønsker vi kun at give modellen den del, der er nødvendig som kontekst; at udlevere hele dokumentet er dyrt og distraherende. For det tredje skal søgeenheden være lille og fokuseret for at være præcis.
Så chunk er den mindste genfindingsenhed. Den skal hverken være for stor eller for lille – lige tilpas.
Chunk Størrelse og Overlap Balance
Der er to hovedindstillinger: chunk-størrelse (hvor mange tokens/ord vil være i en chunk) og overlap (den del, der deles af tilstødende chunks).
Meget små bidder (f.eks. 100 tokens): fokuseret, men afbrudt fra kontekst. Han siger "i 14 dage", men hvad 14 dage er, står tilbage i forrige sætning. Meget store bidder (f.eks. 2000 tokens): bevarer konteksten, men mange tråde er blandet ind; indlejring bliver rodet, og irrelevante emner samles.
Overlap løser grænseproblemet. Hvis en sætning falder nøjagtigt på grænsen af to dele, deles den i to uden at overlappe hinanden, og dens betydning går tabt. Overlapning af 50-100 tokens sikrer, at informationen, der falder inden for grænsen, forbliver intakt i mindst én del.
Klump størrelse
Fordel
Ulempe
passende indhold
Lille (100-250 tokens)
Høj følsomhed, fokuseret
Konteksten kan bryde
FAQ, korte artikler, definitioner
Medium (300-600 tokens)
Balance; de fleste scenarier
—
Procedurer, politiske tekster
Stor (800-1500 tokens)
Kontekstintegritet
sløret indlejring
Fortælling, lange forklaringer
Tip: Hvis du ikke ved, hvor du skal starte, så start med 400-500 token chunk og 50-80 token overlap; mål og juster derefter med dine egne data. Den "rigtige" størrelse er ikke universel, det afhænger af konteksten.
Chunking strategier
Fast størrelse: Beskærer teksten for hver N tokens. Det er enkelt og hurtigt, men kan afbryde midt i sætningen.
Separator-baseret (rekursiv/separator): Inddeler efter afsnit og derefter sætningsgrænser; Det bevarer bedre betydningens integritet. De fleste produktionssystemer starter med dette.
Semantisk chunking: Den ser på sætningernes indlejringer og opdeler dem, hvor emneændringen finder sted. Det er den højeste kvalitet, men den dyreste metode; Med store mængder stiger transaktionsomkostningerne.
Strukturbevidst: Bruger dokumentstruktur såsom overskrifter, sektioner, tabeller. For eksempel sikrer opdeling af et Markdown-dokument efter overskrifter, at hver del har sin egen overskrift.
Tilpasning efter dokumenttype
Ikke alle dokumenter er ens. Strategi varierer efter type:
- PDF/politiktekst: Bogmærkebaseret, mellemstørrelse. Ryd top-/bund-gentagelser på siden (sidehoved/sidefod).
- Tabeller: Tag ikke linjen ud af kontekst; behold hver række med overskriftsoplysninger ("Vare: X, Pris: Y, Lager: Z"). Det er ofte vigtigt at konvertere råtabellen til almindelig tekst.
- Kode: Opdelt efter funktions-/klassegrænser; Skær ikke en funktion af vejen.
- Chat/billetoptagelse: Opdelt efter besked eller samtalerunde; Bevar viden om, hvem der sagde hvad.
# parentes-baserede chunking (konceptuelle) chunks = bol( text, target_size=450, # token overlap=70, # token brackets=["\n\n", "\n", ". ", " "] # afsnit først, ord sidst)
Tilføj metadata til hvert spor
Chunking er ikke bare "dele"; er at berige hvert stykke. Hvert tag, du knytter til sporet, er guld værd til fremtidig filtrering og kildeangivelse.
# Enriched chunk (conceptual){ "text": "Årlig betalt orlov er 14 dage med 1-5 års tjeneste...", "metadata": { "source": "ik_el_kitabi_v7.pdf", "section": "5.2 Årlig orlov", "page": 23, "date": "6", "IK:privatliv", "2025:privacy" "intern" }}
En anden kraftfuld teknik er at tilføje en kontekstuel overskrift: at skrive titlen på det kapitel, det tilhører, i begyndelsen af hvert stykke. Således er selv et usammenhængende stykke som "I 14 dage" både bedre indlejret og mere meningsfuldt som "Annual Leave - 14 days."
Svag chunking / stærk chunking
Svag (blind hardcut, ingen metadata):
Afkort tekst for hver 1000 tegn. Behold kun teksten.# Resultat: tabeller er delt på midten, "14 dage" forbliver uden kontekst,# det vides ikke hvilket dokument det kom fra, der kan ikke laves filter.
Kraftfuld (strukturbevidst + header + metadata):
Opdel dokumentet efter overskrifter; tilføje afsnitstitel til hver del;vedhæft kilde, side, dato og privatlivsmetadata; konverter tabelrækker til almindelig tekst med deres overskrifter.# Resultat: fokuseret, kontekstuel, filtrerbar, kildevenlig.
Tre mini etuier
Case 1 - Malerikatastrofe. Et økonomihold delte den 200 sider lange prisliste med blind hard cutting; tabelrækkerne blev opdelt tilfældigt. "Hvad er prisen på produkt X?" Modellen læste den forkerte linje og gav den forkerte pris (9 ud af 12 tilfælde er forkerte). Da jeg konverterede tabelrækkerne til almindelig tekst i formatet "Produkt: … | Pris: … | Enhed: …” faldt fejlen til 0 ud af 12.
Case 2 — Ekstremt stor del. I en wiki er hver side lavet af en enkelt del (nogle siger 3.000 tokens). Indlejringen er sløret, fordi der er "orlov", "overarbejde" og "løn" på én side; Arbejdstidsafsnittet kom også i spil vedrørende orlovsspørgsmålet. Da siderne blev opdelt i mellemstørrelse efter titel, steg recall@5 fra 64 % til 91 %.
Sag 3 — Afkortet sætning uden overlap. 250 tokens fast snit for et juridisk hold, ingen overlapning. En kritisk definition faldt lige på grænsen af to dele og delt i to; Hverken det ene eller det andet indeholder det fuldstændige svar. Når 60 tokens overlapning blev tilføjet, forblev den samme definition intakt i ét stykke, og det korrekte svar blev returneret.
Almindelige fejl
- Blind fast snit: Opdeler sætninger og tabeller på midten; mening går tabt.
- Lader overlapningen stå på nul: Information, der falder på grænsen, opdeles og går tabt.
- Ikke tilføje metadata: Filtrering og kildevisning bliver umuligt.
- Forlader tabeller rå: Modellen kan ikke løse tabelstrukturen; Konverter linjer til almindelig tekst.
- Indførelse af én strategi: PDF, kode og tabel er ikke opdelt efter samme metode; Tilpas til genren.
Forsigtig: Indstil ikke Chunking én gang og glem det. Genmål genfindingskvaliteten, efterhånden som nye dokumenttyper ankommer (billetter fra et nyt system, scannede PDF'er). Dårlige inputdata betyder dårligt svar ("skrald ind, skrald ud").
Sammenfattende
- Chunk er den mindste genfindingsenhed; Hverken for stor eller for lille – den skal afbalanceres efter indholdet.
- Chunk-størrelse angiver balance mellem fokus og kontekst; Overlap håndterer grænsetab.
- Bracket-baseret og strukturbevidst chunking er udgangspunktet for de fleste generationssystemer; semantisk chunking er god kvalitet, men dyrt.
- Typer som tabel, script og chat kræver deres egne strategier; Konverter tabeller til almindelig tekst.
- Tilføj kilde/dato/kapitel/privatlivsmetadata og afsnitstitel til hvert spor; Dette er grundlaget for filtrering og citering.
Ansøgningsopgave
Opdel en sektion af det dokument, du vælger, på tre forskellige måder: (1) små stykker af 200 tokens, (2) mellemstore stykker af 500 tokens (70 tokens overlap), (3) enkelte store stykker. Stil de samme 3 spørgsmål for hver strategi, marker manuelt, hvilken brik der skal medbringes, og skriv begrundelsen for, hvilken strategi der fungerer bedst for det pågældende dokument. Tilføj derefter mindst fire metadatafelter og en "kapiteltitel" til hvert spor. Hvis dokumentet indeholder en tabel, skal du konvertere en tabelrække til almindelig tekst i formatet "felt:værdi".
tjekliste
- [ ] Jeg kan se, at chunk er den mindste genfindingsenhed, og størrelse er fokus-kontekstbalancen.
- [ ] Jeg ved, hvorfor Overlap forhindrer grænsetab.
- [ ] Jeg kan skelne mellem parentes-baseret, semantisk og struktur-bevidst chunking.
- [ ] Jeg kan tilpasse strategien for tabel, kode og chat.
- [ ] Jeg styrker genfindingen ved at tilføje metadata og kapiteltitel til hvert spor.