Har du bygget et klassisk RAG-system, kender du dets styrker: Det henter relevante chunks, LLM’en genererer forankrede svar, ydeevnen er rimelig, og omkostningerne er forudsigelige. Til de fleste spørgsmål i en vidensbase er det tilstrækkeligt.
Men nogle spørgsmål bryder klassisk RAG. Flertrinsspørgsmål (“Hvilke af vores kunder bruger funktion X og har forladt os de sidste 6 måneder?”). Relationsrige spørgsmål (“Hvordan er vores pris sammenlignet med konkurrenterne A, B og C?”). Syntesespørgsmål (“Opsummér alt, vi ved om denne kundes rejse”). Klassisk chunk-baseret søgning sammensætter chunks dårligt; LLM’en ender med at mangle kontekst, der er spredt mange steder.
Tilgangene “ud over chunks” — Graph RAG, agentisk RAG og RAG med lang kontekst — overskrider hver især disse begrænsninger på forskellige måder. Denne artikel gennemgår varianterne, hvornår hver af dem er det rette værktøj, hvordan de fungerer i produktion, og hvilke afvejninger der betyder noget.
Begrænsninger ved chunk-baseret RAG
For at forstå, hvad varianterne løser, skal vi først se på begrænsningerne:
Begrænsning 1: Ingen relationsstruktur. Chunks er uafhængige enheder. Det forhold, at chunk A handler om kunde X’s konto, mens chunk B handler om en klage fra samme kunde, går tabt — de er blot to chunks i et vektorrum, som hentes (eller ikke hentes) uafhængigt.
Begrænsning 2: Intet flertrinsræsonnement. “Kunder, der bruger funktion X og har klaget over Y” kræver, at oplysninger fra to forskellige kilder kombineres med mængdelogik. Det gør chunk-baseret søgning ikke.
Begrænsning 3: Begrænset syntese. “Opsummér relationen til denne kunde over tid” kræver, at mange chunks samles til en sammenhængende fortælling. Chunks præsenteres som fragmenter; LLM’en skal skabe syntesen fra bunden hver gang.
Begrænsning 4: En stiv, fast pipeline. Klassisk RAG gør altid det samme: Opret embedding af spørgsmål → hent K → generér. Komplekse spørgsmål, der kræver iterativ søgning eller ræsonnement i flere trin, passer ikke til denne pipeline.
Begrænsning 5: Udvandet kontekst. De øverste 5 chunks kan omfatte resultater, der matcher spørgsmålet sprogligt, men ikke emnemæssigt. LLM’en tvinges til at gennemgå dem, og kvaliteten lider.
De varianter, vi gennemgår, adresserer hver især dele af disse begrænsninger.
Graph RAG
Idéen er at repræsentere data som en vidensgraf. Entiteter (personer, produkter, dokumenter, hændelser) er noder, og relationer er kanter. Forespørgsler gennemløber grafen i stedet for — eller som supplement til — vektorsøgning.
Hvornår Graph RAG hjælper
Relationstunge domæner. Kunde-konto-aftalings-interaktionsstrukturer. Org-hierarkier. Produkttaxonomier. Citationsnetværk. Alt, hvor forhold mellem entiteter er lige så vigtige som entiteterne selv.
Flertrinsræsonnement. “Hvem leder det team, der købte produkt X i Q3?” kræver flere hop: produkt → aftale → team → leder. Graph RAG håndterer det naturligt.
Aggregering. “Hvor mange kunder i segment Y har integreret med system Z?” kræver mængdeoperationer over entiteter. SQL på en vidensgraf slår tekstsøgning.
Kildehenvisninger og forklaringer. Grafrelationer er eksplicitte og kan revideres. LLM’en kan citere “John leder Team Acme [kant: leder]” frem for “Jeg tror, John leder Team Acme ud fra konteksten.”
Sådan fungerer Graph RAG i praksis
Den typiske pipeline:
1. Ekstraktion. Byg grafen fra din data. To almindelige tilgange:
- Strukturerede kilder (databaser, strukturerede API’er): importér direkte. Kunder, produkter og transaktioner er allerede i tabeller.
- Ustrukturerede kilder (dokumenter, transskriptioner, e-mails): Brug en LLM til at udtrække entiteter og relationer. “Udtræk personer, organisationer og relationerne mellem dem fra denne transskription.”
Output: noder (med typer og egenskaber) og kanter (med typer og egenskaber).
2. Lager. En grafdatabase — Neo4j, Memgraph eller tilpasset Postgres med kanttabeller. Valget afhænger af forespørgselsmønstre og skala.
3. Udvid med embeddings. Hver node får også en tekstrepræsentation og en embedding. Det muliggør en hybrid: Gennemløb grafen OG udfør semantisk søgning.
4. Forespørgsler på søgetidspunktet. Tre almindelige mønstre:
- Ren grafforespørgsel. LLM’en (eller routinglogik) genererer en grafforespørgsel (Cypher, SQL). Kør den. Returnér resultaterne til LLM’en.
- Embedding først, grafudvidelse bagefter. Find relevante entiteter via embeddings. Udvid derefter til deres nabolag og relaterede entiteter.
- Hybrid. Kombinér vektorsøgning + grafgennemløb i én pipeline.
5. Format til LLM’en. Grafresultater formateres som struktureret tekst, som LLM’en kan bruge: entiteter med egenskaber og eksplicitte relationer.
Et konkret eksempel
En SaaS-virksomhed med kundedata. Entiteter: kunder, kontrakter, produkter, supportsager, interaktioner og medarbejdere.
Klassisk RAG-tilgang: Opdel kundedokumenter i chunks, opret embeddings, og søg. Relationsstrukturen går tabt.
Graph RAG-tilgang:
- Noder: kunde, kontrakt, produkt, ticket, interaktion, medarbejder.
- Kanter: kunde→har→kontrakt, kunde→abonnerer_på→produkt, kunde→indleveret→ticket, ticket→tildelt→medarbejder, kontrakt→solgt_af→medarbejder.
Spørgsmål: “Hvilke kunder i SaaS-segmentet har mere end 3 supportsager i Q1 og skal forny deres aftale i Q2?”
Det er naturligt en grafforespørgsel:
MATCH (c:Customer)-[:HAS]->(contract:Contract)
WHERE contract.tier = "SaaS"
AND contract.renewal_date BETWEEN "2026-04-01" AND "2026-06-30"
MATCH (c)-[:SUBMITTED]->(t:Ticket)
WHERE t.created BETWEEN "2026-01-01" AND "2026-03-31"
WITH c, count(t) as ticket_count
WHERE ticket_count > 3
RETURN c, ticket_count
LLM’en genererer denne forespørgsel (eller vælger blandt skabeloner). Kør den. Formatér resultaterne. Generér svaret.
Klassisk RAG kan ikke nemt besvare spørgsmålet. Graph RAG løser det elegant.
Kompromiser
Fordele:
- Behandler relationelle spørgsmål naturligt.
- Eksplicit struktur, der kan revideres.
- Kan kombineres med embeddings.
Ulemper:
- Opbygning af grafen kræver reelt ingeniørarbejde. Udtrækning fra ustrukturerede kilder er især vanskelig.
- Skemadesign betyder noget; dårlige skemaer begrænser dig.
- Vedligeholdelse: Når data udvikler sig, skal grafen udvikle sig med dem.
- Mindre modne værktøjer end til vektorsøgning.
Hvornår skal du vælge den?
Vælg Graph RAG, når relationer er centrale i dit domæne. Vælg det ikke blot, fordi det lyder avanceret; i mange dokumentbaserede domæner er klassisk RAG enklere og lige så godt.
Microsofts GraphRAG og beslægtet arbejde
Microsofts open source-projekt GraphRAG (2024) gjorde en bestemt tilgang populær:
- Udtræk entiteter og relationer fra dokumenter (LLM-baseret).
- Kluster entiteter i fællesskaber.
- Generér opsummeringer pr. fællesskab på flere hierarkiske niveauer.
- På forespørgselstidspunktet: Hent relevante fællesskabsopsummeringer, og brug dem som kontekst.
Det fungerer godt til “globale” spørgsmål, der spænder over et korpus (f.eks. “Hvilke hovedtemaer findes i denne kundes klagehistorik?”), frem for konkrete opslag.
Varianter inkluderer LightRAG, Graphiti og andre — hver med bestemte arkitektoniske valg.
Agentisk RAG
Idéen er at erstatte en fast søg-og-generér-pipeline med en LLM-agent, der beslutter, hvad der skal findes, hvornår og hvordan søgningen skal forbedres. Agenten kan stille opfølgende søgeforespørgsler, gennemgå resultaterne, vurdere dem som utilstrækkelige og prøve andre vinkler.
Hvornår agentisk RAG hjælper
Komplekse spørgsmål, der kræver iteration. “Hjælp mig med at forstå, hvorfor vores kundeafgang steg i Q1” kræver flere vinkler (segment, periode, funktioner, konkurrenter). En agent kan undersøge dem iterativt.
Spørgsmål, hvor én søgning ikke er nok. Hvis svaret kræver oplysninger fra flere forskellige søgninger, håndterer en agent det naturligt.
Spørgsmål med betinget logik. “Hvis X er sandt ud fra søgning 1, så søg efter Y; ellers søg efter Z.” Agenten håndterer forgrening; det gør faste pipelines ikke.
Uklare spørgsmål. Agenten kan bede brugeren (eller dataene) om en afklaring.
Sådan fungerer agentisk RAG
Pipeline:
User query
↓
Agent reasons about what it needs
↓
Agent calls retrieval tools (one or many)
↓
Agent reads results
↓
Agent decides: enough info? Or another retrieval?
↓
Loop until done
↓
Generate final answer
Implementeringen involverer:
Søgning som værktøjer. Gør søgefunktioner tilgængelige for agenten: search_documents(query), lookup_by_id(id), aggregate(field, filter). Agenten kalder dem efter behov.
Hukommelse. Agenten husker på tværs af kald, hvad den har fundet, og undgår at hente det samme indhold igen.
Beslutningstagning. Agenten vurderer eksplicit, om den har tilstrækkelige oplysninger. “Kender jeg svaret på brugerens spørgsmål? Hvis ikke, hvad skal jeg finde mere om?”
Afslutning. Agenten skal vide, hvornår den skal stoppe. Et maksimalt antal trin. Et sikkerhedsniveau. En betingelse om, at spørgsmålet er besvaret.
Et konkret eksempel
Spørgsmål: “Hvad var de tre mest almindelige kundeanmeldelser i Q1, med eksempler?”
Klassisk RAG-tilgang: Hent nogle chunks med kundefeedback, og håb, at de dækker emnet.
Agentic RAG tilgang:
Agent: I need to find Q1 customer concerns. Let me start by searching for customer complaints in that period.
> Tool: search_documents(query="customer complaints Q1 2026", filter={date_range: "Q1 2026"})
Agent: I got 25 results. Let me see what topics they cover.
> [reads results]
Agent: I see three main themes: pricing, slow support, and missing integrations. Let me get specific examples for each.
> Tool: search_documents(query="customer pricing complaints", filter={...})
> Tool: search_documents(query="customer support speed complaints", filter={...})
> Tool: search_documents(query="customer integration missing complaints", filter={...})
Agent: Now I have 3-5 specific examples per theme. Let me compile the answer.
Flere søgninger, der forbedres iterativt. Agenten beslutter strukturen ud fra det fundne.
Kompromiser
Fordele:
- Behandler komplekse, flertrins spørgsmål.
- Tilpasser sig spørgsmålets kompleksitet (enkle spørgsmål udløser ikke lange agentkørsler).
- Kan afklare uklarheder ved at spørge.
Ulemper:
- Højere latenstid (flere søgninger).
- Højere omkostninger (flere LLM-opkald).
- Agentens pålidelighed betyder noget; dårlige agenter løkker eller opgiver.
- Sværere at evaluere (mere variable udførelsesforløb).
- Svært at kontrollere (agenten kan gøre usædvanlige ting).
Hvornår skal du vælge den?
Vælg agentisk RAG, når spørgsmålenes kompleksitet varierer meget. Enkle spørgsmål kan bruge hurtige forløb; komplekse spørgsmål får agentisk behandling. Til ensartede, enkle spørgsmål er meromkostningen ikke umagen værd.
Mønstre i agentisk RAG
Nogle almindelige mønstre:
Mønster 1: ReAct (Tænk + Handling). Agenten tænker eksplicit, så handler (henter), så observerer, så tænker igen. Loop indtil færdig.
Mønster 2: Planlæg og udfør. Agenten opretter først en plan med flere trin (hvad der skal findes og i hvilken rækkefølge) og udfører derefter planen med eventuelle justeringer.
Mønster 3: Selvkritik. Efter søgningen vurderer agenten, om oplysningerne er tilstrækkelige. Hvis ikke, forbedrer den forespørgslen og søger igen.
Mønster 4: Værktøjsrig agent. Agenten har mange søgeværktøjer (fuldtekstsøgning, SQL-forespørgsler, grafforespørgsler, API-kald) og vælger mellem dem.
Forskellige mønstre passer til forskellige brugssituationer. En værktøjsrig agent fungerer med heterogene datakilder; ReAct fungerer til undersøgende spørgsmål; planlæg-og-udfør fungerer, når strukturen i et komplekst spørgsmål kan planlægges på forhånd.
RAG med lang kontekst
Idéen: Hvorfor overhovedet hente chunks med kontekstvinduer på 1M tokens (Gemini, GPT-5)? Læg blot hele korpusset i konteksten.
Hvornår RAG med lang kontekst hjælper
Små korpora. Et korpus på 100K-token passer nemt i et vindue på 1M-token. Der kræves ingen søgeinfrastruktur.
Forståelse af hele dokumenter. “Opsummér hele dette 500-side dokument.” En model med lang kontekst håndterer det direkte.
Spørgsmål på tværs af små dokumentsæt. “Sammenlign disse 10 kontrakter.” Det er lettere at lægge dem alle i konteksten end at søge præcist.
Prototyper. Lang kontekst er den enkleste vej til et fungerende system. Byg prototypen med lang kontekst; optimér senere med søgning, hvis det bliver nødvendigt.
Sådan fungerer RAG med lang kontekst
Pipeline’en er triviel:
[corpus, possibly 100K-1M tokens]
↓
+ [user query]
↓
LLM call
↓
[answer]
Intet vektorlager. Ingen chunking. Ingen reranking.
I praksis kan du stadig foretage en grov søgning, så korpusset passer i konteksten (fra et korpus på 5M token kan du f.eks. hente en del på 500K-token). Søgningen er dog grovkornet — LLM’en udfører det finkornede arbejde med at “finde de relevante dele”.
Problemet med “kontekstforfald”
I 2025-2026 er realiteten: Modeller med lang kontekst udnytter ikke altid den lange kontekst godt.
Empirisk:
- Kvaliteten er højest med ca. 5-50K tokens i konteksten — den bagvedliggende struktur for positionel opmærksomhed er dokumenteret i Liu et al.’s “Lost in the Middle” og efterfølgende evalueringer af lang kontekst.
- Kvaliteten falder mærkbart ved 100K+ tokens.
- Ved 500K+ tokens overses eller misbruges vigtige oplysninger ofte.
Modeller kan teknisk håndtere lang kontekst, men “nål i en høstak”-benchmarks overvurderer deres praktiske ydeevne. Virkelige anvendelser med lang kontekst lider.
Det betyder, at RAG med lang kontekst fungerer pålideligt for korpora op til ca. 50K tokens. Over det niveau forringes kvaliteten sammenlignet med god søgning.
Kompromiser
Fordele:
- Enkleste mulige arkitektur.
- Ingen søgepipeline at vedligeholde.
- Bedst til opgaver, der kræver forståelse af hele korpusset.
Ulemper:
- Kvalitetsforringelse ved store kontekststørrelser.
- Høj omkostning per spørgsmål (du betaler for hele konteksten hver gang).
- Høj latens (stor kontekst = langsommere svar).
- Skalerer ikke ud over korpora, der kan rummes pålideligt.
Hvornår skal du vælge den?
Små korpora (under 50K tokens). Enkeltstående analyser. Prototyper. IKKE generelle søgescenarier i store vidensbaser.
Hybrid: Søgning + lang kontekst
Et almindeligt mønster er at hente en større kontekst (50-200K tokens relevant indhold), end klassisk RAG ville gøre, men mindre end hele korpusset. LLM’en får nok kontekst til at håndtere spørgsmålet uden kontekstforfald.
Implementering: Hent top-50 chunks (i stedet for top-5), medtag dem alle, og lad LLM’en sortere i dem.
Dette fungerer godt, når:
- Spørgsmål kræver bred kontekst.
- Modeller håndterer mellemstore kontekster godt (50-200K).
- Omkostningen er acceptabel.
Et godt kompromis i 2026 er at søge bredt (50-100 chunks), medtage dem alle og lade LLM’en bruge de relevante dele. Du bytter højere omkostning for enkelhed og kvalitet.
Vælg den rigtige variant
En beslutningsramme:
Brug klassisk chunk-baseret RAG, når:
- Dokumenter er den primære datatype.
- Spørgsmålene er overvejende opslag.
- Volumen og omkostninger betyder noget (billigst pr. forespørgsel).
- Du har brug for forudsigelig latens.
Brug Graph RAG, når:
- Data har en rig relationsstruktur mellem entiteter.
- Spørgsmål omfatter flertrinsræsonnement, mængdeoperationer og aggregering.
- Du kan investere i grafbygning og vedligeholdelse.
Brug agentisk RAG, når:
- Spørgsmålets kompleksitet varierer meget.
- Nogle spørgsmål kræver iterativ undersøgelse.
- Du er villig til at betale højere latens/omkostning for svære spørgsmål.
- Du har observabilitet til at fejlfinde agentkørsler.
Brug RAG med lang kontekst, når:
- Korpus er lille (under 50K tokens).
- Du vil have den enkleste arkitektur.
- Enkeltanalyser eller prototyper.
Kombiner, når:
- De fleste virkelige systemer gør det.
- Klassisk + Graph RAG til relationelle spørgsmål.
- Klassisk + agentisk RAG til komplekse spørgsmål.
- Klassisk med bredere søgning (mellemstor kontekst) til grænsetilfælde.
Det modne svar i 2026 er “alt ovenstående, anvendt pr. forespørgsel”. En router bestemmer ud fra spørgsmålets egenskaber, hvilken variant der skal bruges.
Produktionssærligheder
Nogle observationer fra virkelige implementeringer:
Kompleksiteten vokser. Hver variant tilføjer kompleksitet. Et system, der bruger alle fire, er en betydelig ingeniørudfordring. Begynd med klassisk RAG, og tilføj kun varianter, når du rammer klare begrænsninger.
Evaluering er sværere. Med flere søgeforløb skal evalueringen dække dem alle. Testsættet bør indeholde spørgsmål, der afprøver hvert forløb.
Omkostninger varierer meget. Graph RAG kan være billig (én databaseforespørgsel). RAG med lang kontekst er dyr. Agentisk RAG varierer (enkle = billige, komplekse = dyre). Overvåg omkostningerne pr. forespørgsel.
Latenstiden varierer tilsvarende. Et agentisk RAG-svar på 30-sekund er acceptabelt i nogle brugssituationer, men ikke i andre. Vælg variant efter UX-konteksten.
Vedligeholdelsesbyrden. Grafskemaer driver, agentprompts skal justeres, og embeddingmodeller opdateres. Hver variant har sin egen vedligeholdelsesomkostning. Planlæg derefter.
Reglen 80/20. Klassisk RAG håndterer 80% af spørgsmålene tilstrækkeligt. De svære 20% håndteres af varianterne ud over chunks, fordi klassisk RAG løser dem dårligt. Erstat ikke; udvid.
En kombineret arkitektur
En praktisk arkitektur, der bruger flere varianter:
Query
↓
Router (classify the query)
├→ "Lookup" → Classic RAG (cheap, fast)
├→ "Relational" → Graph RAG
├→ "Complex / open-ended" → Agentic RAG
└→ "Whole-corpus / small corpus" → Long-context
Each variant produces an answer.
Observability tracks which path was used.
Eval suites cover all paths.
Det er mere komplekst end en enkelt variant, men håndterer hele spektret af spørgsmål godt. For modne systemer med forskellige spørgsmålstyper er det ofte den endelige arkitektur.
En praktisk udbygning
Hvis du starter fra et fungerende klassisk RAG og vil udvide:
Tilføj lang kontekst først. Det kræver mindst ingeniørarbejde, er nyttigt til bestemte spørgsmålstyper og giver ofte hurtige resultater.
Tilføj agentisk RAG til komplekse spørgsmål. Identificér de spørgsmål, som klassisk RAG har svært ved. Byg en agent, der håndterer dem, og send dem betinget til den.
Tilføj Graph RAG sidst. Det kræver mest ingeniørarbejde og er kun umagen værd ved tydelige relationelle spørgsmålsmønstre.
Denne rækkefølge svarer typisk til investeringsafkastet. Lang kontekst: lav indsats, reel værdi. Agentisk RAG: mellemstor indsats, udfylder reelle huller. Graph RAG: høj indsats, specifikke brugssituationer.
Forbedr, ikke erstatt
Klassisk chunk-baseret RAG er arbejdshesten, men har begrænsninger. Varianterne “ud over chunks” — Graph RAG, agentisk RAG og RAG med lang kontekst — åbner hver især nye muligheder.
Vejen frem er ikke at erstatte klassisk RAG, men at udvide det. Modne systemer bruger flere varianter og sender hver forespørgsel til den variant, der håndterer den bedst.
Investeringen er betydelig — hver variant kræver reelt ingeniørarbejde. Men for systemer, hvor klassisk RAG når et plateau, er gevinsten reel. Et system, der kun håndterer opslag godt, er langt mindre nyttigt end et, der også håndterer relationelle, komplekse spørgsmål og spørgsmål om hele korpusset.
Kortlæg dine spørgsmål. Identificér dem, som klassisk RAG ikke håndterer godt. Vælg den rette variant. Byg udvidelsen. Iterér.
Sådan udvikler RAG-systemer sig fra at være nyttige til enkelte spørgsmål til at være reelt kompetente på tværs af hele spektret af virkelige forespørgsler.
