Chunking, reranking og hybridsøgning: Få RAG til faktisk at virke

De fleste RAG-implementeringer fungerer dårligt. Modellen er ikke problemet — Claude og GPT-5 besvarer gerne spørgsmål på grundlag af hentede dokumenter. Det er retrieval-delen, der svigter. Du stiller et spørgsmål, systemet returnerer de forkerte tekstudsnit, og modellen leverer et selvsikkert svar baseret på de forkerte oplysninger.

Denne artikel er en praktisk guide til de tre tiltag, der forbedrer dårlig retrieval: chunking-strategi, reranking og hybridsøgning. Når de fungerer rigtigt, forsvinder de fleste klager om, at »RAG ikke virker til vores anvendelsestilfælde«.

Vi springer den dybe matematik over og fokuserer på, hvad du konkret skal gøre.

Hvorfor retrieval fejler

En almindelig RAG-pipeline:

1. Opdel dokumenter i chunks.
2. Opret en embedding for hver chunk.
3. Når et spørgsmål kommer ind, oprettes en embedding for det, hvorefter de mest lignende chunks findes ved hjælp af cosinuslighed.
4. Send disse chunks til LLM’en.

Hvert trin kan fejle:

Dårlig chunking skaber chunks, der er for korte til at være nyttige eller for lange til at være sammenhængende. De kan også bryde midt i en logisk idé, så ingen af halvdelene fungerer godt ved retrieval.

Naiv lighedssøgning finder chunks, der deler ordforråd med forespørgslen, men ikke reelt er relevante. Forespørgslen »hvordan opsiger jeg mit abonnement?« kan hente enhver chunk, der nævner »abonnement«, herunder uvedkommende markedsføringstekst.

Ingen reranking betyder, at LLM’en ser præcis det, lighedssøgningen returnerer. Den chunk, der ligner forespørgslen mest, er ikke altid den mest relevante.

Ren semantisk søgning overser vigtige eksakte søgeordsmatch. En forespørgsel efter »fejlkode 503« kan overse en chunk med den præcise tekst »fejlkode 503«, fordi forespørgslens semantiske vektor ikke matcher chunkens overordnede emne.

De tre løsninger — bedre chunking, reranking og hybridsøgning — håndterer hver sin af disse mangler.

Løsning 1: Bedre chunking

Chunking er den enkeltbeslutning, der har størst betydning i din RAG-pipeline, og den, de fleste først overvejer, når resultaterne er blevet dårlige.

Standardløsningen i de fleste no-code-værktøjer er at opdele efter et fast antal tokens, f.eks. 500 tokens med et overlap på 50 tokens. Det fungerer nogenlunde, men fejler ofte.

Her er bedre strategier:

Semantisk chunking

Opdel dokumenter ved semantiske grænser — steder, hvor emnet skifter — frem for ved vilkårlige tokenantal. De fleste moderne frameworks, herunder LangChain og LlamaIndex, har semantiske chunkere, som registrerer emneskift og opdeler teksten dér.

Fordelen er, at hver chunk indeholder en hel idé. Modellen får sammenhængende kontekst i stedet for halve argumenter.

Strukturbevidst chunking

Brug dokumentets naturlige struktur, hvis den findes, f.eks. Markdown-overskrifter, HTML-sektioner, PDF-kapitler eller funktionsgrænser i kode. Opdel efter sektion, ikke efter tokenantal.

Til Markdown:

• Hver H2-sektion er en chunk, hvor H1-konteksten sættes foran.
• Lange H2-sektioner opdeles yderligere, og H2-overskriften gentages som kontekst.

Til kode:

• Hver funktion eller klasse er en chunk.
• Chunken indeholder filstien og eventuelle imports.

Det fungerer markant bedre end blind chunking med fast størrelse for enhver form for struktureret indhold.

Hierarkisk chunking

Et mønster fra nyere RAG-forskning er at oprette chunks på flere niveauer:

• Små chunks (200-500 tokens) til præcis retrieval.
• Mellemstore chunks (1000-2000 tokens) til kontekst.
• Dokumentresuméer (50-100 tokens) til overordnet matchning.

Ved retrieval matcher du mod de små chunks, men returnerer den omgivende mellemstore chunk. LLM’en får både præcis relevans og tilstrækkelig kontekst til at forstå indholdet.

Valg af chunkstørrelse

Her er en grov tommelfingerregel efter indholdstype:

Hvis du bruger et no-code-værktøj, der skjuler chunkingen, så udfør en test: Stil 10 spørgsmål, som du ved, at korpuset indeholder svar på. Hvis retrieval jævnligt ikke finder den rigtige chunk, er chunkingen problemet.

Et velfungerende mønster: »side eller sektion, derefter spørgsmålsbaseret«

Til de fleste personlige RAG-anvendelser fungerer dette mønster:

1. Opdel efter dokumentsektion, f.eks. Markdown H2 eller PDF-kapitel.
2. Opdel chunks over ~2000 tokens yderligere efter afsnit.
3. Sæt dokumentets titel og sektionsoverskrift foran hver chunk som kontekst.
4. Tilføj en kort beskrivelse af, hvilke typer spørgsmål den pågældende chunk besvarer. Den kan genereres automatisk af en hurtig LLM under indekseringen.

Tricket med den automatisk genererede beskrivelse af, »hvilke spørgsmål denne chunk besvarer«, bruges overraskende sjældent og er overraskende effektivt. Det virker, fordi brugerforespørgsler ofte formuleres som spørgsmål, og et match mod metadata i spørgeform er mere præcist end et match mod dokumentets rå tekst.

Løsning 2: Reranking

Efter den indledende retrieval, der typisk returnerer 20-50 chunks ud fra vektorlighed, bruger du en reranker til at sortere dem på ny efter deres faktiske relevans for forespørgslen.

Rerankeren er en separat model — som regel en mindre, specialiseret model — der modtager par bestående af forespørgsel og chunk og returnerer en relevansscore. Du anvender den på de øverste 20-50 resultater, sorterer dem efter den nye score og sender de øverste 3-5 til LLM’en.

Fordelen er markant bedre præcision. Vektorlighed er hurtig, men ikke særlig præcis; rerankere er langsommere, men langt mere præcise. Kombinationen giver hurtig retrieval med nøjagtig sortering.

Muligheder for reranking i 2026:

• Cohere Rerank — den etablerede API-baserede reranker. $2.00 pr. 1,000 søgninger (listepris, verificeret 2026-07-10).
• Voyage AI rerank-2 — en stærk kommerciel løsning, der ofte er bedre end Cohere på nicheområder.
• bge-reranker-v2-m3 — open source og kan køre lokalt eller på billig hosting.
• Jina Reranker — endnu en stærk open source-løsning.

I en typisk pipeline:

1. Vektorsøgning returnerer de øverste 50 chunks hurtigt og billigt.
2. Rerankeren scorer alle 50 i forhold til forespørgslen, hvilket er dyrere og langsommere.
3. De øverste 5 efter reranking-score sendes til LLM’en.

Den ekstra latenstid er i alt ~200-500ms. Kvalitetsforbedringen er ofte 20-40% på benchmarks for retrieval-præcision.

For no-code-værktøjer, der ikke har reranking som standard, f.eks. NotebookLM og de fleste grundlæggende n8n-løsninger, er dette den enkeltopgradering, der har størst effekt. n8n har en Cohere Rerank-node, og LangChain samt LlamaIndex har indbyggede integrationer til rerankere.

Løsning 3: Hybridsøgning

Vektorlighed finder semantiske match. Søgeordssøgning, f.eks. BM25, finder eksakte match. De to metoder overser forskellige ting.

Ved forespørgslen »hvordan retter jeg HTTP 503-fejl på vores gateway?«:

• Vektorsøgning finder chunks om HTTP-fejl, gatewayproblemer og fejlfinding.
• Søgeordssøgning finder chunks, der specifikt nævner »503« — og de kan indeholde selve svaret.

Hybridsøgning kører begge metoder og kombinerer resultaterne. Kombinationen bruger en metode kaldet Reciprocal Rank Fusion (RRF). Ud fra rangordningen fra hver metode skaber RRF en samlet rangordning, der tager højde for begge signaler.

Implementeringen er enkel i de fleste værktøjer:

• Kør vektorsøgning → få den rangerede liste A.
• Kør BM25/søgeordssøgning → få den rangerede liste B.
• Beregn hver chunks RRF-score = 1/(k + rank_in_A) + 1/(k + rank_in_B) (hvor k typisk er 60).
• Sortér efter den samlede score, og returnér de øverste resultater.

I 2026, understøtter følgende løsninger hybridsøgning direkte:

• Weaviate (vektorlager) — indbygget hybridsøgning.
• Qdrant — hybridsøgning via filtrering.
• Pinecone — hybridsøgning via sparse vektorer.
• Elastic/OpenSearch — kombineret søgeords- og vektorsøgning.
• De fleste n8n RAG-skabeloner — hybrid er standard i moderne skabeloner.

Fordelen er markant bedre recall ved forespørgsler med bestemte identifikatorer, koder, navne eller fagudtryk. Til teknisk indhold som kode, fejlkoder, produktnavne og henvisninger til regler er hybridsøgning reelt nødvendig.

Hvis dine forespørgsler ofte indeholder bestemte udtryk, der skal matche præcist, f.eks. tal, navne, koder eller eksakte formuleringer, skal du slå hybridsøgning til. Omkostningen er lav, og gevinsten er stor.

Sådan kombinerer du dem

Den mest avancerede RAG-pipeline i 2026:

Query
  ↓
Query rewriter (optional — clean up the query, expand abbreviations)
  ↓
Hybrid retrieval: vector + keyword search
  ↓
Top 30-50 results
  ↓
Reranker
  ↓
Top 5 by reranker score
  ↓
LLM with retrieved chunks + query
  ↓
Cited answer

Hvert trin er billigt i sig selv. Tilsammen giver de en retrieval-kvalitet, der er kvalitativt anderledes end »vektorlighed → top 5 → LLM«.

Her er nogle mindre almindelige, men effektive tilføjelser:

Udvidelse af forespørgslen. Omskriv brugerens forespørgsel til flere varianter, og søg efter hver af dem. Det opfanger forskellige formuleringer.

Retrieval i flere trin. Udfør flere retrieval-runder ved komplekse spørgsmål. Første runde identificerer underspørgsmål; anden runde henter svar på hvert underspørgsmål.

Samtalebaseret retrieval. Brug samtalehistorikken til at styre retrieval i en samtale med flere beskeder: »Brugeren spurgte tidligere om X, så prioritér indhold om X til dette spørgsmål«.

Kildefiltrering. Brug metadatafiltre til at afgrænse retrieval: »Søg kun i dokumenter med tagget ‘EU regulations’ og en dato efter 2023.«

Disse funktioner findes i stigende grad i no-code-RAG-værktøjer, men kontrollér altid, at de tre grundlæggende dele fungerer — god chunking, en reranker og hybridsøgning — før du går videre til de avancerede.

Sådan måler du RAG-kvalitet

Du kan ikke forbedre noget, du ikke måler. Her er nogle praktiske evalueringsstrategier:

Test med »gyldne spørgsmål«. Vælg 20 spørgsmål, som du kender de korrekte svar på. Kør dem gennem din RAG. Vurder, om de rigtige chunks blev hentet, og om modellen leverede det rigtige svar. Gør det hver måned.

Retrieval recall ved K. Identificér for hvert gyldent spørgsmål, hvilke chunks der indeholder svaret. Kontrollér derefter, om retrieval-systemet returnerede nogen af disse chunks blandt de øverste K (5, 10, 20). Mål andelen.

LLM-as-judge-evaluering. I en mere avanceret udgave lader du en stærk model (Claude Opus eller GPT-5) bedømme, om svaret er korrekt, kildehenvisningerne er præcise, og svaret er fuldstændigt og veldokumenteret. Kør evalueringen på et sæt repræsentative spørgsmål. Vi har en hel artikel om evals.

Brugeroplevet kvalitet. Til RAG for teams eller produktion kan du føje en tommel op/tommel ned-vurdering til hvert svar. Undersøg mønstrene i negative vurderinger. De samler sig omkring bestemte spørgsmålstyper — ret dem.

Den største fejl er helt at undlade måling. »Det føles okay« er ikke en måling. Uden målinger kan du ikke vide, om dine forbedringer virker.

Praktisk eksempel: forbedring af en RAG, der svigter

Forestil dig, at du har bygget en personlig RAG til din virksomheds interne dokumentation. Kvaliteten er middelmådig — omkring 60% af spørgsmålene får et nyttigt svar. Anvend følgende forbedringer i denne rækkefølge:

Kontrollér retrieval først. Undersøg, hvilke chunks der blev hentet til ti af svarene med dårlig kvalitet. Blev den rigtige chunk hentet? Hvis ja, ligger problemet i modellen eller prompten. Hvis nej, ligger problemet i retrieval.

Hvis retrieval er problemet:

1. Kontrollér chunkingen. Er dine chunks sammenhængende? Opdeler din chunker teksten midt i vigtige idéer? Skift til semantisk eller strukturbevidst chunking.

2. Tilføj en reranker. Hvis du bruger grundlæggende vektorsøgning og de 5 øverste resultater, skal du tilføje Cohere Rerank eller bge-reranker-v2-m3 mellem retrieval og LLM’en. Forbedringen er som regel synlig med det samme — mål den på dit eget evalueringssæt i stedet for at stole på en universel procentsats.

3. Tilføj hybridsøgning. Især hvis dine forespørgsler indeholder bestemte udtryk som produktnavne, fejlkoder eller fagudtryk.

4. Undersøg din indeksering. Er dine chunks mærket med metadata som dokumenttype, sektion eller dato? Brug metadatafiltre ved retrieval.

Hvis modellen er problemet, fordi de rigtige chunks hentes, men svaret er forkert:

1. Stram prompten. Instruér modellen tydeligt: »Svar kun ud fra den angivne kontekst. Hvis konteksten ikke dækker spørgsmålet, skal du sige det.«

2. Tilføj kildehenvisninger. Kræv, at modellen henviser til den konkrete chunk, den brugte. Det hjælper både med fejlfinding og med at reducere hallucinationer.

3. Brug en stærkere model. Hvis du bruger en lille, hurtig model, så prøv Claude Sonnet 4.5 eller GPT-5.

Efter to eller tre runder med denne form for undersøgelse og rettelse når de fleste RAG-implementeringer en andel på 85-90% nyttige svar. Det er den tærskel, hvor brugerne faktisk tager systemet til sig og stoler på det.

Almindelige fejl

Her er nogle konkrete problemer, som jævnligt rammer implementeringer:

Indeksering af forkert indhold. Markedsføringssider, forældede dokumenter og blogindhold af lav kvalitet. Modellen kan ikke skelne; alt i indekset behandles som autoritativt. Udvælg indholdet konsekvent og kritisk.

Indekset opdateres ikke, når dokumenterne ændres. En RAG med forældet indhold leverer selvsikkert forkerte svar. Genindeksér regelmæssigt, eller brug et system med automatisk synkronisering.

Evaluering ignoreres. De fleste RAG’er sættes i drift uden målinger og bliver derefter aldrig forbedret. Fasen, hvor løsningen »føles okay«, fortsætter for evigt. Indbyg evaluering fra første dag.

Retrieval behandles som en sort boks. »Det virker bare ikke« er ikke en diagnose. Åbn retrieval-processen, og undersøg, hvad den returnerer. Problemet bliver næsten altid tydeligt, når du ser resultaterne.

Overudvikling fra begyndelsen. Du behøver ikke starte med den mest avancerede pipeline. Begynd med NotebookLM eller grundlæggende vektorsøgning. Tilføj kun kompleksitet, når du har identificeret en konkret flaskehals.

Hvornår det har betydning

De tre løsninger — bedre chunking, reranking og hybridsøgning — har størst betydning, når:

• Korpuset er teknisk og indeholder specifik terminologi.
• Forespørgsler kræver eksakte match, f.eks. koder, navne eller ID’er.
• Brugerne prioriterer præcision, f.eks. inden for jura, compliance og kundesupport.
• Systemet bruges i stor skala, hvor en lille kvalitetsforbedring betyder meget, når det anvendes 10,000 gange om dagen.

De har mindre betydning, når:

• Korpuset er lille, dvs. under 100 dokumenter, og velorganiseret.
• Forespørgslerne er åbne, f.eks. »hvad er vores holdning til X?«.
• Brugerne er tolerante og vil gentage processen for at finde svaret.
• Anvendelsen er undersøgende frem for præcisionsorienteret.

For de fleste personlige RAG’er og RAG’er til små teams er skiftet fra grundlæggende vektorlighed til vektor plus reranker den opgradering, der giver størst effekt. Hybridsøgning er den næste tilføjelse. Chunking har betydning i enhver skala.

Konklusionen

Dårlig RAG skyldes næsten altid dårlig retrieval, og dårlig retrieval skyldes næsten altid tre ting: chunking, reranking og søgemetoden. Ret de tre, så forsvinder de fleste problemer med RAG-kvaliteten.

Du behøver ikke være søgeekspert for at anvende dem. Værktøjer som Weaviate, Pinecone, Qdrant, n8n-skabeloner og LangChain-integrationer har gjort teknikkerne tilgængelige. Flaskehalsen er nu primært at kende dem og anvende dem bevidst.

Hvis din RAG ikke fungerer, skal du ikke give modellen skylden. Se på de chunks, der returneres, ret retrieval-processen, og evaluér derefter igen.