RAG-chunking til AI-chatbots: Opdel indhold med mening

En website-chatbot kan kun svare pålideligt, hvis den finder det rette indhold på det rette tidspunkt. Det er præcis her, RAG-chunking gør forskellen: Lange sider, manualer og hjælpetekster opdeles i mindre enheder, som en søgekomponent målrettet kan hente. For store blokke indeholder meget irrelevant støj. For små blokke mister konteksten. En god opdeling følger derfor ikke blindt et tal, men i stedet indholdets struktur, betydning og fremtidige anvendelse.

Denne guide er henvendt til website-, support- og content-teams. Den forklarer, hvordan du opdeler indhold semantisk, bevarer metadata, reducerer duplikering og tester med realistiske søgespørgsmål, om den valgte strategi virker. Tilgangen er uafhængig af leverandør og kan overføres til både klassisk vektorsøgning og hybride retrieval-metoder.

Hvorfor RAG-chunking præger svarkvaliteten

Ved Retrieval-Augmented Generation søger systemet først efter relevante vidensbyggeklodser og sender dem derefter videre til sprogmodellen. Chunk-grænserne bestemmer dermed, hvad der overhovedet kan findes sammen og bruges som kontekst. Hvis en prisbetingelse adskilles fra sin undtagelse, kan en formelt korrekt søgning stadig levere et ufuldstændigt grundlag. Indeholder en chunk derimod en hel produktside med navigation, varianter og sidefod, konkurrerer den afgørende passage med en masse støj.

Chunking påvirker flere kvalitetsdimensioner på samme tid:

• Findbarhed: Passer det søgte udsagn klart ind i en kompakt enhed?
• Sammenhæng: Bliver overskrift, forklaring, begrænsning og eksempel sammen?
• Præcision: Indeholder søgeresultatet mindst muligt emnefremmed fyld?
• Gennemskuelighed: Kan uddraget henføres til en gyldig kilde, sprog og version?

Microsoft beskriver faste, variable og semantiske metoder og fremhæver, at overskrifter samt andre layoutsignaler kan udnyttes til meningsfulde grænser. AWS skelner ligeledes mellem faste, hierarkiske og semantiske strategier. Den fælles praktiske erfaring: Den tekniske opdeling bør følge den indholdsmæssige struktur, hvor end denne findes pålideligt.

Start med semantiske sektioner frem for vilkårlige snit

Et godt udgangspunkt er den eksisterende sidestruktur. H2- og H3-overskrifter, afsnit, lister, FAQ-spørgsmål, tabeller og klart afgrænsede bemærkninger bærer allerede på betydning. En sektion om returfrister bør ikke ende midt i en sætning eller mellem regel og undtagelse. Et FAQ-spørgsmål hører sammen med sit svar i den samme chunk. Ved en vejledning bør handlingstrin, forudsætning og advarsel så vidt muligt blive sammen.

En praktisk grænselogik

1. Opdel først ved dokument-, side- og hovedoverskrifter.
2. Kontrollér, om en sektion behandler præcis ét forståeligt hovedemne.
3. Opdel kun sektioner, der er for store til retrieval eller modelkontekst.
4. Sammenføj meget korte fragmenter med en passende nabosektion.
5. Mærk hver del med overskrift og strukturstikort som kontekst.

Ved ren HTML eller Markdown er denne metode nem at automatisere. Ustrukturerede PDF'er, uensartede eksporter og scannede dokumenter kræver ofte en forudgående layout- eller tekstgenkendelse. Kontrollér i den forbindelse især tabeller, spalter, sidehoveder og sideskift: Det, der visuelt står ved siden af hinanden, kan ende i en forkert rækkefølge under udlæsningen.

Behandl chunk-størrelse som en testværdi, ikke som et dogme

Der findes ingen universel ideel chunk-størrelse. Microsoft nævner 512 tokens med 25 procent overlapning som et muligt startpunkt for bestemte scenarier, men påpeger, at den optimale indstilling afhænger af indhold og model. AWS dokumenterer ligeledes konfigurerbare størrelser og overlapninger. Sådanne værdier er nyttige udgangshypoteser – ikke et kvalitetsbevis.

Korte FAQ-svar fungerer ofte som selvstændige enheder. Detaljerede fremgangsmåder kræver mere kontekst. Juridiske eller kontraktlige tekster bør ikke rive regel, anvendelsesområde og undtagelse fra hinanden. Produktsammenligninger kan derimod give mening række- eller sektionsvis, hvis spalteoverskrifter og produktreference følger med.

Sådan genkender du for store eller for små chunks

For stor er en chunk typisk, hvis flere søgeintentioner er blandet sammen i den, den relevante sætning forsvinder mellem navigation og sekundær information, eller mange søgeresultater returnerer den samme omfangsrige blok. For lille er den, hvis pronominer mister deres reference, overskrifter mangler, betingelser adskilles fra udsagn, eller der kræves adskillige fragmenter for at forstå et enkelt spørgsmål.

Sammenlign derfor mindst to eller tre varianter med det samme sæt af spørgsmål. Ændr kun én parameter ad gangen, såsom målstørrelse eller grænselogik. På den måde bliver det tydeligt, hvad der reelt forbedrer søgekvalitet og svardokumentation.

Overlapning beskytter konteksten – og skaber samtidig duplikater

En lille overlapning kan forhindre, at en afgørende sætning går tabt direkte ved en chunk-grænse. Den er især hjælpsom, når en teknisk opdeling efter længde er uundgåelig. For megen overlapning har dog bivirkninger: Næsten identiske resultater optager adskillige pladser i resultaterne, øger kontekstomfanget og kan dominere et udsagn kunstigt.

Brug derfor overlapning målrettet. Ved strukturbaserede sektioner er det ofte nok at medtage overskrift, overordnet sti og en kort overgang. Ved længere brødtekster kan en lille del af det foregående afsnit give mening. Mål derefter, om forskellige relevante kilder forbliver blandt de øverste resultater, eller om de fortrænges af dubletter.

Metadata gør en chunk driftssikker

Ren tekst er sjældent nok til en produktiv vidensbase. Hver chunk bør bevare sin oprindelse og sit gyldighedsområde. AWS beskriver metadata som grundlag for filtrering ved forespørgsler. I en website-vidensbase er især følgende felter nyttige:

• kanonisk kilde-URL og sidetitel,
• overskrifternes sti på siden,
• sprog eller locale,
• indholdstype som FAQ, vejledning, retningslinje eller produktdetalje,
• udgivelses- henholdsvis ændringsdato,
• produkt, region eller målgruppe, såfremt det er fagligt relevant,
• adgangs- og godkendelsesstatus ved ikke-offentligt indhold.

Dermed kan man for eksempel vælge kun at søge i aktuelt godkendt supportindhold. Kilden kan desuden linkes i svaret og målrettet genbehandles ved en senere opdatering. Hvordan du systematisk sikrer aktualitet, viser guiden KI-Chatbot-Wissensbasis aktuell halten.

Fjern boilerplate og dubletter før indeksering

Navigation, cookie-meddelelser, gentagne kontaktblokke og globale sidefødder hører ikke hjemme i hver eneste chunk. Ellers opstår der hundredvis af næsten identiske poster, som kan fortrænge det egentlige indhold. Fjern tilbagevendende sideelementer før opdelingen, og normaliser unødvendige mellemrum, dekorative tegn og tekniske fragmenter.

Faglige dubletter kræver også opmærksomhed. Hvis den samme returregel er formuleret forskelligt på hjælp-, produkt- og forsendelsessider, bør der fastlægges en ansvarlig primærkilde. Forældede kopier fjernes, omdirigeres eller nedprioriteres entydigt. En chunking-proces kan ikke forvandle modstridende kilder til pålidelig viden.

Håndtér specialtilfælde bevidst

FAQ-indhold

Gem spørgsmål og svar sammen. Suppler med det overordnede emneområde ved meget korte svar. Varianter af det samme spørgsmål kan være nyttige til søgningen, men bør ikke indekseres som flerdobbelt svartekst.

Tabeller og lister

En tabelrække uden kolonneoverskrifter er for det meste uforståelig. Gentag eller referer derfor de relevante overskrifter i chunken. Ved lange lister bør hver del bevare listetitlen og den fælles introduktion. Kontrollér efter ekstraktionen, om værdierne stadig er knyttet til det korrekte kendetegn.

Flersprogede sider

Adskil indhold efter locale, og gem sproget som metadata. En forespørgsel på ét sprog bør ikke tilfældigt modtage en forældet sektion på et andet sprog, blot fordi lignende begreber optræder. Fælles oversættelses- eller sideidentifikatorer hjælper med at forbinde varianter uden at blande dem sammen i den samme tekstblok.

Udfør retrieval-tests før svartesten

Vurdér først, om søgningen leverer den rette passage. Først bagefter vurderer du sprogmodellens formulering. Et lille Golden Set bestående af reelle brugerspørgsmål bør indeholde entydige spørgsmål, synonymer, flerdelte henvendelser, grænsetilfælde og spørgsmål uden dokumenteret svar. For hvert spørgsmål definerer du på forhånd, hvilken kilde eller hvilken sektion der forventes.

Kontrollér mindst:

• om den forventede sektion dukker op blandt de første resultater,
• om irrelevante eller dobbelte resultater fortrænger vigtige kilder,
• om alle nødvendige betingelser og undtagelser står i den leverede kontekst,
• om kilden og dens aktualitetsstatus forbliver gennemskuelig,
• om systemet sikkert lader være med at opfinde et svar ved manglende viden.

Artiklen KI-Chatbot-Antwortqualität mit Golden Set und RAG-Tests messen beskriver den rette testproces. For synlig dokumentation supplerer guiden Chatbot-Antworten mit Quellen belegen perspektivet på linkkontrol og usikkerhed.

Tjekliste til implementeringen

1. Kortlæg indhold: Registrer sidetyper, sprog, formater og ansvarlige kilder.
2. Kontrollér ekstraktion: Tjek overskrifter, tabeller og læserækkefølge på repræsentative eksempler.
3. Definer grænser: Foretræk semantiske sektioner, og brug kun faste størrelser som fallback-logik.
4. Bevar kontekst: Medtag sidetitel, overskriftssti og nødvendige overgange.
5. Planlæg metadata: Gem URL, locale, aktualitet, indholdstype og godkendelse struktureret.
6. Fjern dubletter: Rens boilerplate og modstridende kopier før indeksering.
7. Test varianter: Sammenlign størrelser og overlapning med det samme Golden Set.
8. Overvåg driften: Evaluer regelmæssigt manglende søgeresultater, forældede kilder og brugerfeedback.

Konklusion: Gode chunks er forståelige vidensenheder

RAG-chunking er ikke en engangsindstilling i teknikken, men indholdsarkitektur til maskinel retrieval. Gode chunks besvarer et klart afgrænset delønske, bevarer deres nødvendige kontekst og kan henføres til en gyldig kilde. Overskrifter, metadata og kontrolleret overlapning er i den forbindelse lige så vigtige som den rene længde.

Start med nogle få repræsentative indholdstyper, mål retrieval før svarstil, og dokumenter enhver ændring. Hvis du bagefter ønsker at opbygge en website-chatbot på en struktureret vidensbase, finder du den rette start på ChatReact-Funktionsübersicht.

Kilder

• Microsoft Learn: Chunk large documents for vector search solutions in Azure AI Search
• Microsoft Learn: Chunk and vectorize by document layout
• AWS Bedrock: How content chunking works for knowledge bases
• AWS Bedrock: Include metadata in a data source