Dela RAG-dokument rätt – 512 token slog smartare metoder

I RAG Chunking Benchmark gav fasta segment om 512 token högst sammanvägd poäng, 0,8775, mot 0,8686 för semantisk och 0,8647 för hybrid delning på 40 frågor från två engelska dokument om sammanlagt 502 sidor. Det gör fasta segment till en rimlig baslinje, men underlaget räcker inte för att utse en storlek som bäst för alla kunskapsbaser.

Välj delningsmetod efter vad användarna frågar och hur beläggen ligger i era dokument. Jämför en enkel fast delning med en variant som följer rubriker eller stycken, och mät både om rätt passage hämtas och om det färdiga svaret stöds av den. Håll resten av sök- och svarskedjan konstant under jämförelsen.

Vad resultatet för fasta segment mäter

Den sammanvägda poängen blandar mått för hämtat sammanhang och genererade svar. En variant kan därför hamna lägre totalt trots att den ger svar med starkare stöd i de hämtade texterna. För en assistent som besvarar frågor om villkor eller tekniska krav kan det måttet väga tyngre än en liten fördel i totalpoäng. Delmåtten visar vad en förbättring faktiskt betyder i tjänsten.

De testade källorna var Apples årsrapport och Michael Porters skannade bok Competitive Strategy. Frågorna spände över faktasökning, resonemang mellan textställen, tabellvärden och sammanfattning. Bredden i frågorna kompenserar inte för att dokumenttyperna var få: testet använde en embeddingmodell, samma antal hämtade segment per fråga och en engelskspråkig korpus. En svensk handbok, en uppsättning FAQ-svar eller avtal med täta hänvisningar kan kräva andra segmentgränser.

Även en korrekt totalsiffra kan missleda om den läses som en egenskap hos segmentstorleken ensam. Extraktion från PDF, embedding, sökning, vald mängd kontext och svarsmodell ingick i den testade kedjan. Resultatet gäller den kombinationen av data och inställningar; det isolerar inte hur samma segmentstorlek skulle prestera med en annan dokumenttolkning eller ett annat urval frågor.

Det andra benchmarkets mått gäller sökrankning

I rag-cpp:s benchmark för Pipeline::standard() fick strukturell fast delning nDCG@10 på 0,6809 mot 0,6703 för semantisk och 0,5887 för propositionsbaserad delning på SciFact; på NFCorpus var värdena 0,3261, 0,3233 och 0,2895 i samma ordning, samtidigt som propositionsvarianten skapade ett betydligt större index. Den enkla metoden kom först även här, men ”fixed” betecknar projektets strukturella standarddelning, inte en oberoende mätning av just 512 token.

Måttet belönar relevanta träffar som hamnar högt bland sökresultaten. Det bedömer alltså rankningen, medan det första testets totalpoäng även omfattar svarens kvalitet. Skillnaderna mellan de fasta och semantiska varianterna i detta söktest är dessutom små jämfört med avståndet till propositionsvarianten. Resultaten ger skäl att använda en enkel referens, men poängen kan inte jämföras direkt eller översättas till en förväntad förbättring av era svar.

Dokument och frågor avgör var gränsen ska gå

Delningen bestämmer den minsta enhet som sökningen kan hämta. Knowledge Studios dokumentation skiljer mellan fast delning för enkel text, rubrikstyrd delning för tydligt strukturerade dokument och en metod som följer kapitel och stycken. Den rekommenderar olika inställningar för FAQ, produktmanualer, längre rapporter och avtal. Det är råd utifrån dokumentens utformning, inte en garanti för ett visst sökresultat.

En FAQ-post har ofta ett kort, fristående svar som passar i ett litet segment. Ett avtalsvillkor kan däremot behöva sin rubrik och ett undantag i närheten för att inte misstolkas. I en tabell kan siffran vara värdelös utan radens etikett, kolumnens enhet eller en förklarande fotnot. Delningen behöver därför hålla ihop det underlag som frågan kräver, även när det ger segment av olika längd.

Frågetypen styr också hur mycket sammanhang som behövs. En fråga efter ett namn kan besvaras från en kort passage; en fråga om varför två regler skiljer sig kan kräva belägg från skilda avsnitt. Om många frågor kräver flera textställen hjälper det föga att ett enskilt segment är väl avgränsat om sökningen bara lämnar plats för ett fåtal träffar. Pröva därför segmentgränser tillsammans med det antal träffar och den kontextbudget som assistenten faktiskt använder.

Skilj fel i hämtningen från fel i svaret

Ragas mått för RAG omfattar context precision, context recall, response relevancy och faithfulness. De belyser olika led: om relevanta belägg rankas högt, om nödvändigt innehåll kommer med, om svaret träffar frågan och om påståendena stöds av hämtad text. Ett enda medelvärde kan dölja att en variant förbättrar rankningen men lämnar modellen med för lite sammanhang för ett välgrundat svar.

Märk i förväg ut de passager som behövs för varje testfråga. När de saknas bland träffarna är hämtningen problemet; när de finns där men svaret ändå tillför ett obelagt påstående ligger felet senare i kedjan. Den uppdelningen gör det möjligt att utvärdera stöd för påståenden i RAG-svar utan att blanda ihop det med sökprecision. Bedöm också om assistenten avstår när dokumenten saknar svar, eftersom ett övertygande men obelagt svar annars kan se relevant ut.

Ett reproducerbart minitest med egna dokument

Ta ett litet men medvetet urval ur den kunskapsbas som ska användas: de vanligaste dokumenttyperna och avsnitt där gränser mellan rubriker, tabeller och brödtext spelar roll. Skriv frågor som motsvarar verkliga ärenden och lägg till frågor där beläggen finns på flera ställen eller där svaret saknas. Ange önskat svar och dess källpassager innan varianterna körs, så att bedömningen inte anpassas efter den metod som råkar vinna.

1. Bygg jämförbara varianter. Pröva till exempel fasta segment om 256, 512 och 1024 token samt en variant som delar efter rubriker eller stycken. Behåll samma överlappning mellan de fasta varianterna först; jämför ändrad överlappning i ett eget test.
2. Lås övriga inställningar. Använd samma textextraktion, embeddingmodell, sökmetod, antal hämtade segment, eventuell omrankning, svarsprompt och genereringsmodell. Spara också kodversion och frågor, så att körningen går att upprepa.
3. Poängsätt hämtningen per fråga. Kontrollera om de märkta passagerna finns bland träffarna och var de rankas. Bedöm passageinnehåll snarare än segment-ID, eftersom varje metod skapar nya gränser och därmed andra ID:n.
4. Bedöm svaren separat. Markera om svaret täcker frågan, om varje sakpåstående stöds och om assistenten avstår när underlag saknas. Bryt ned utfallet på faktasökning, tabellfrågor och frågor som kräver flera avsnitt.
5. Räkna kostnaden. Notera hur många segment indexet innehåller, hur mycket text som skickas till svarsmodellen och hur lång tid sökningen tar. Ett marginellt kvalitetslyft kan vara svårt att motivera om det kräver betydligt större index eller mer kontext.

Välj utifrån de frågetyper som är viktigast för tjänsten, inte enbart den högsta totalpoängen. Om fasta segment fungerar för FAQ men rubrikstyrd delning ger säkrare belägg i manualer, kan kunskapsbasen få skilda regler för dessa dokumenttyper. Den inställningen går sedan att ompröva när dokumenten eller frågorna förändras.

Läs också:

• Mät hallucinationer i RAG – träffsäker hämtning räcker inte
• Bygg datarummet före rundan: två dokument stoppar ofta granskningen