RAG bortom textsegment: graf-RAG, agentbaserad RAG och RAG med lång kontext

Om du har byggt ett klassiskt system för hämtningsförstärkt generering (RAG) känner du till dess styrkor: det hämtar relevanta textsegment, LLM-modellen genererar välgrundade svar, prestandan är rimlig och kostnaderna förutsägbara. För de flesta frågor till en kunskapsbas räcker detta.

Men vissa frågor knäcker klassisk RAG. Flerstegsfrågor (”Vilka av våra kunder använder funktion X och har lämnat oss de senaste 6 månaderna?”). Relationstunga frågor (”Hur står sig vår prissättning jämfört med konkurrenterna A, B och C?”). Syntesfrågor (”Sammanfatta allt vi vet om den här kundens resa”). Klassisk textsegmentsbaserad hämtning kombinerar inte textsegment väl; LLM-modellen missar till slut kontext som är utspridd på många platser.

Metoderna ”bortom textsegment” – graf-RAG, agentbaserad RAG och RAG med lång kontext – angriper dessa begränsningar på olika sätt. Den här artikeln beskriver vad de är, när respektive metod är rätt verktyg, hur de faktiskt fungerar i produktion och vilka avvägningar som spelar roll.

Begränsningarna hos textsegmentsbaserad RAG

För att förstå vad vi åtgärdar måste vi förstå begränsningarna:

Begränsning 1: Ingen relationsstruktur. Textsegment är oberoende enheter. Att textsegment A handlar om kund X:s konto och textsegment B om ett klagomål från kund X går förlorat – de är bara två textsegment i ett vektorrum som hämtas (eller inte hämtas) oberoende av varandra.

Begränsning 2: Inga flerstegskopplingar. ”Kunder som använder funktion X och klagade på Y” kräver att information från två olika källor kombineras med mängdlogik. Textsegmentsbaserad hämtning gör inte detta.

Begränsning 3: Begränsad syntes. ”Sammanfatta relationen till det här kontot över tid” kräver att många textsegment sammanfogas till en sammanhängande berättelse. Textsegmenten presenteras som fragment; LLM-modellen måste göra syntesen från grunden varje gång.

Begränsning 4: Stel, fast pipeline. Klassisk RAG gör alltid: bädda in fråga → hämta K → generera. Komplexa frågor som kräver iterativ hämtning eller flerstegsresonemang passar inte i denna pipeline.

Begränsning 5: Utspädd kontext. De fem högst rankade textsegmenten kan innehålla sådana som matchar frågan men ligger utanför ämnet. LLM-modellen tvingas ta sig igenom dem och kvaliteten blir lidande.

Varianterna vi diskuterar hanterar olika delmängder av dessa problem.

Graf-RAG

Idén: representera dina data som en kunskapsgraf. Entiteter (personer, produkter, dokument, händelser) är noder och relationer är kanter. Frågor traverserar grafen i stället för (eller utöver) att göra vektorsökning.

När graf-RAG hjälper

Relationstunga domäner. Strukturer med kund–konto–affär–interaktion. Organisationshierarkier. Produkttaxonomier. Citeringsnätverk. Allt där kopplingarna mellan entiteter betyder lika mycket som entiteterna själva.

Flerstegsresonemang. ”Vem leder teamet som köpte produkt X under Q3?” kräver flera hopp: produkt → affär → team → chef. Graf-RAG hanterar detta naturligt.

Aggregering. ”Hur många kunder i segment Y har integrerat med system Z?” kräver mängdoperationer över entiteter. SQL mot en kunskapsgraf slår texthämtning.

Källhänvisningar och förklaringar. Grafrelationer är explicita och granskningsbara. LLM-modellen kan hänvisa till ”John leder Team Acme [kant: leder]” i stället för ”Jag tror att John leder Team Acme baserat på kontexten.”

Så fungerar graf-RAG i praktiken

Den typiska pipelinen:

1. Extrahering. Bygg grafen från dina data. Två vanliga metoder:

• Strukturerade källor (databaser, strukturerade API:er): importera direkt. Kunder, produkter och transaktioner finns redan i tabeller.
• Ostrukturerade källor (dokument, transkriptioner, e-post): använd en LLM för att extrahera entiteter och relationer. ”Extrahera personer, organisationer och relationerna mellan dem från den här transkriptionen.”

Resultatet: noder (med typer och egenskaper) och kanter (med typer och egenskaper).

2. Lagring. En grafdatabas – Neo4j, Memgraph eller en anpassad Postgres-lösning med kanttabeller. Valet beror på frågemönster och skala.

3. Komplettera med inbäddningar. Varje nod får också en textrepresentation och en inbäddning. Det möjliggör en hybridmetod: traversera grafen OCH gör semantisk sökning.

4. Fråga vid hämtning. Tre vanliga mönster:

• Enbart graffråga. LLM-modellen (eller routningslogik) genererar en graffråga (Cypher, SQL). Kör den. Returnera resultaten till LLM-modellen.
• Inbäddning först, grafexpansion därefter. Hitta relevanta entiteter med inbäddningar. Expandera sedan till deras grannar och relaterade entiteter.
• Hybrid. Kombinera vektorsökning och graftraversering i en pipeline.

5. Formatera för LLM-modellen. Grafresultaten formateras som strukturerad text som modellen kan använda. Entiteter med sina egenskaper och explicita relationer.

Ett konkret exempel

Ett SaaS-företag med kunddata. Entiteter: kunder, avtal, produkter, supportärenden, interaktioner och medarbetare.

Klassisk RAG-metod: dela upp kunddokument i textsegment, bädda in och hämta. Relationsstrukturen går förlorad.

Graf-RAG-metod:

• Noder: kund, avtal, produkt, ärende, interaktion, medarbetare.
• Kanter: kund→has→avtal, kund→subscribed_to→produkt, kund→submitted→ärende, ärende→assigned_to→medarbetare, avtal→sold_by→medarbetare (kantnamnen är de som används i frågespråket nedan).

Fråga: ”Vilka kunder på SaaS-nivån hade fler än 3 supportärenden under Q1 och ska förnya under Q2?”

Detta är en naturlig graffråga:

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-modellen genererar frågan (eller väljer bland frågemallar). Kör den. Formatera resultaten. Generera svaret.

Klassisk RAG kan inte enkelt besvara detta. Graf-RAG gör det utan problem.

Avvägningar

Fördelar:

• Hanterar relationsfrågor naturligt.
• Explicit, granskningsbar struktur.
• Kan kombineras med inbäddningar.

Nackdelar:

• Att bygga grafen kräver ett reellt utvecklingsarbete. Extraheringen är ofullkomlig, särskilt för ostrukturerade källor.
• Schemadesignen spelar roll; dåliga scheman begränsar dig.
• Underhåll: när data utvecklas måste grafen utvecklas.
• Mindre mogna verktyg än för vektorsökning.

När du bör välja metoden:

Välj graf-RAG när relationer är centrala i din domän. Välj inte metoden bara för att den låter sofistikerad; för många dokumenttunga domäner är klassisk RAG enklare och lika bra.

Microsofts Graph RAG och relaterat arbete

Microsofts projekt GraphRAG med öppen källkod (2024) populariserade en specifik metod:

1. Extrahera entiteter och relationer från dokument (LLM-baserat).
2. Klustra entiteter i gemenskaper.
3. Generera sammanfattningar per gemenskap på flera hierarkiska nivåer.
4. Vid frågetillfället: hämta relevanta gemenskapssammanfattningar och använd dem som kontext.

Detta fungerar bra för ”globala” frågor som spänner över en korpus (exempelvis ”vilka är huvudtemana i den här kundens klagomålshistorik?”) snarare än specifika uppslagningar.

Varianter innefattar LightRAG, Graphiti och andra – var och en med specifika arkitekturval.

Agentbaserad RAG

Idén: använd en LLM-agent som avgör vad som ska hämtas, när och hur sökningen ska förfinas, i stället för en fast pipeline med hämtning följd av generering. Agenten kan göra uppföljande hämtningsfrågor, granska resultaten, avgöra att de inte räcker och prova andra infallsvinklar.

När agentbaserad RAG hjälper

Komplexa frågor som kräver iteration. ”Hjälp mig förstå varför kundbortfallet ökade under Q1” kräver undersökning ur många perspektiv (vilket segment, vilken tidsperiod, vilka funktioner, vilka konkurrenter). En agent kan utforska iterativt.

Frågor där en hämtning inte räcker. Om svaret kräver att information från flera separata hämtningar kombineras hanterar en agent detta naturligt.

Frågor med villkorslogik. ”Om X är sant enligt hämtning 1, slå då upp Y, annars Z.” Agenter hanterar förgreningar; fasta pipelines gör det inte.

Tvetydiga frågor. Agenten kan be användaren (eller datakällan) om ett förtydligande.

Så fungerar agentbaserad RAG

Pipelinen:

Användarfråga
    ↓
Agenten resonerar om vad den behöver
    ↓
Agenten anropar hämtningsverktyg (ett eller flera)
    ↓
Agenten läser resultaten
    ↓
Agenten avgör: finns tillräcklig information? Eller behövs en ny hämtning?
    ↓
Upprepa tills uppgiften är klar
    ↓
Generera slutligt svar

Implementationen omfattar:

Hämtning som verktyg. Exponera hämtningsfunktioner för agenten: search_documents(query), lookup_by_id(id), aggregate(field, filter). Agenten anropar dem efter behov.

Minne. Agenten minns vad den har hämtat mellan anropen. Det förhindrar att samma innehåll hämtas igen.

Beslutsfattande. Agenten resonerar uttryckligen om huruvida den har tillräcklig information. ”Känner jag till svaret på användarens fråga? Om inte, vad behöver jag hämta mer?”

Avslut. Agenten måste veta när den ska sluta. En maximal stegbudget. Ett konfidensgränsvärde. Ett villkor för ”jag har svarat”.

Ett konkret exempel

Fråga: ”Vilka var de tre största kundproblemen under Q1, med exempel?”

Klassisk RAG-metod: hämta några textsegment med kundåterkoppling och hoppas att de täcker ämnet.

Agentbaserad RAG-metod:

Agent: Jag behöver hitta kundproblem från Q1. Jag börjar med att söka efter kundklagomål under den perioden.
> Verktyg: search_documents(query="kundklagomål Q1 2026", filter={date_range: "Q1 2026"})

Agent: Jag fick 25 resultat. Jag undersöker vilka ämnen de täcker.
> [läser resultat]

Agent: Jag ser tre huvudteman: prissättning, långsam support och saknade integrationer. Jag hämtar specifika exempel för vart och ett.
> Verktyg: search_documents(query="kundklagomål om prissättning", filter={...})
> Verktyg: search_documents(query="kundklagomål om långsam support", filter={...})
> Verktyg: search_documents(query="kundklagomål om saknade integrationer", filter={...})

Agent: Nu har jag 3–5 specifika exempel per tema. Jag sammanställer svaret.

Flera hämtningar som förfinas iterativt. Agenten bestämmer strukturen utifrån vad den hittar.

Avvägningar

Fördelar:

• Hanterar komplexa flerstegsfrågor.
• Anpassar sig efter frågans komplexitet (enkla frågor utlöser inte långa agentkörningar).
• Kan reda ut tvetydigheter genom att fråga.

Nackdelar:

• Högre latens (flera hämtningar).
• Högre kostnad (flera LLM-anrop).
• Agentens tillförlitlighet spelar roll; dåliga agenter fastnar i loopar eller ger upp.
• Svårare att utvärdera (mer varierade exekveringsvägar).
• Svårare att kontrollera (agenten kan göra oväntade saker).

När du bör välja metoden:

Välj agentbaserad RAG när frågornas komplexitet varierar kraftigt. Enkla frågor kan använda snabba vägar, medan komplexa frågor hanteras agentbaserat. För genomgående enkla frågor är merkostnaden inte motiverad.

Mönster inom agentbaserad RAG

Några vanliga mönster:

Mönster 1: ReAct (Reason + Act). Agenten resonerar uttryckligen, agerar sedan (hämtar), observerar och resonerar på nytt. Upprepas tills uppgiften är klar.

Mönster 2: Planera och exekvera. Agenten skapar först en flerstegsplan (vad som ska hämtas och i vilken ordning) och exekverar sedan planen, med eventuella justeringar.

Mönster 3: Självkritik. Efter hämtningen utvärderar agenten om den hämtade informationen räcker. Om inte, förfinar den frågan och hämtar på nytt.

Mönster 4: Verktygsrik agent. Agenten har många hämtningsverktyg (fulltextsökning, SQL-frågor, graffrågor, API-anrop) och väljer mellan dem.

Olika mönster passar olika användningsfall. Verktygsrika agenter passar heterogena datakällor, ReAct passar utforskande frågor och planera-och-exekvera passar när strukturen hos en komplex fråga kan planeras på förhand.

RAG med lång kontext

Idén: varför alls hämta textsegment när kontextfönstren omfattar 1M+ token (Gemini, GPT-5)? Lägg helt enkelt hela korpusen i kontexten.

När RAG med lång kontext hjälper

Små korpusar. En korpus med 100K token ryms enkelt i ett kontextfönster med 1M token. Ingen hämtningsinfrastruktur behövs.

Förståelse av hela dokument. ”Sammanfatta hela detta dokument på 500 sidor.” En modell med lång kontext hanterar detta direkt.

Frågor över små dokumentuppsättningar. ”Jämför dessa 10 avtal.” Det är enklare att lägga in alla i kontexten än att göra en noggrant utformad hämtning.

Prototyper. Lång kontext är den enklaste vägen till ett fungerande system. Bygg prototypen med lång kontext och optimera senare med hämtning om det behövs.

Så fungerar RAG med lång kontext

Pipelinen är trivial:

[korpus, eventuellt 100K–1M token]
    ↓
+ [användarfråga]
    ↓
LLM-anrop
    ↓
[svar]

Ingen vektorlagring. Ingen uppdelning. Ingen omrankning.

I praktiken kan du ändå göra en lätt hämtning för att få plats med korpusen i kontexten (exempelvis hämta en delmängd med 500K token ur en korpus med 5M token). Hämtningen är dock grovkornig – LLM-modellen gör det finkorniga arbetet med att ”hitta de relevanta delarna”.

Problemet med ”kontextförfall”

En realitet 2025–2026: modeller med lång kontext använder i praktiken inte långa kontexter väl.

Empiriskt:

• Kvaliteten är högst med ungefär 5–50K token kontext (det positionsbaserade uppmärksamhetsmönstret bakom detta dokumenteras i Liu et al.:s ”Lost in the Middle” och senare utvärderingar av lång kontext).
• Kvaliteten sjunker märkbart vid 100K+ token.
• Vid 500K+ token missas eller feltolkas viktig information ofta.

Modeller kan tekniskt hantera långa kontexter, men jämförelser av typen ”nål i en höstack” överdriver deras prestanda. Verklig användning av lång kontext blir lidande.

Det innebär att RAG med lång kontext fungerar tillförlitligt för korpusar på upp till ~50K token. Därutöver ger metoden sämre resultat än välkonstruerad hämtning.

Avvägningar

Fördelar:

• Enklast möjliga arkitektur.
• Ingen hämtningspipeline att underhålla.
• Bäst för uppgifter som kräver förståelse av hela korpusen.

Nackdelar:

• Kvaliteten försämras vid stora kontextstorlekar.
• Hög kostnad per fråga (du betalar för hela kontexten varje gång).
• Hög latens (stor kontext ger långsammare svar).
• Skalar inte bortom korpusar som ryms på ett tillförlitligt sätt.

När du bör välja metoden:

Små korpusar (under 50K token). Engångsanalyser. Prototyper. INTE generell hämtning för stora kunskapsbaser.

Hybrid: hämtning + lång kontext

Ett vanligt mönster: hämta en större kontext (50–200K token relevant innehåll) än klassisk RAG skulle göra, men mindre än hela korpusen. LLM-modellen får tillräckligt med kontext för att hantera frågan väl utan kontextförfall.

Implementering: hämta de 50 högst rankade textsegmenten (i stället för 5), inkludera samtliga och låt LLM-modellen sålla.

Detta fungerar bra när:

• Frågorna kräver bred kontext.
• Modeller hanterar medellånga kontexter väl (50–200K).
• Kostnaden är acceptabel.

En optimal avvägning 2026: hämta brett (50–100 textsegment), inkludera allt och låt LLM-modellen använda de relevanta delarna. Kostnad byts mot enkelhet och kvalitet.

Välj rätt variant

Ett beslutsramverk:

Använd klassisk textsegmentsbaserad RAG när:

• Dokument är primärdata.
• Frågorna främst handlar om uppslagning.
• Volym och kostnad spelar roll (billigast per fråga).
• Du behöver förutsägbar latens.

Använd graf-RAG när:

• Data har en rik struktur av entiteter och relationer.
• Frågorna omfattar flerstegsresonemang, mängdoperationer och aggregering.
• Du kan investera i konstruktion och underhåll av grafen.

Använd agentbaserad RAG när:

• Frågornas komplexitet varierar kraftigt.
• Vissa frågor kräver iterativ utforskning.
• Du accepterar högre latens och kostnad för svåra frågor.
• Du har observerbarhet för felsökning av agentkörningar.

Använd RAG med lång kontext när:

• Korpusen är liten (under 50K token).
• Du vill ha enklast möjliga arkitektur.
• Det gäller engångsanalyser eller prototyper.

Kombinera när:

• De flesta verkliga system gör det.
• Klassisk + graf för relationsfrågor.
• Klassisk + agentbaserad för komplexa frågor.
• Klassisk med bredare hämtning (medellång kontext) för gränsfall.

Det mogna svaret 2026 är ”allt ovanstående, tillämpat per fråga”. En router avgör vilken variant som ska användas baserat på frågans egenskaper.

Realiteter i produktion

Några observationer från verkliga driftsättningar:

Komplexitet ackumuleras. Varje variant ökar komplexiteten. Ett system som använder alla fyra är ett betydande utvecklingsprojekt. Börja med klassisk RAG och lägg bara till varianter när du når tydliga begränsningar.

Utvärderingen blir svårare. Med flera hämtningsvägar måste utvärderingen omfatta dem alla. Testuppsättningen bör innehålla frågor som aktiverar varje väg.

Kostnaderna varierar kraftigt. Graf-RAG kan vara billigt (en databasfråga). RAG med lång kontext är dyrt. Agentbaserad RAG varierar (enkelt = billigt, komplext = dyrt). Spåra kostnaden per fråga.

Latensen varierar på motsvarande sätt. Ett 30 sekunder långt agentbaserat RAG-svar är acceptabelt för vissa användningsfall, men inte för andra. Välj variant efter användarupplevelsens sammanhang.

Underhållsbörda. Grafscheman förändras, agentprompter behöver finjusteras och inbäddningsmodeller uppdateras. Varje variant har sin egen underhållskostnad. Planera därefter.

80/20. Klassisk RAG hanterar 80 % av frågorna tillräckligt bra. Varianterna bortom textsegment hanterar de svåra 20 % där klassisk RAG fungerar dåligt. Ersätt inte; komplettera.

En kombinerad arkitektur

En praktisk arkitektur med flera varianter:

Fråga
  ↓
Router (klassificera frågan)
  ├→ "Uppslagning" → Klassisk RAG (billig, snabb)
  ├→ "Relation" → Graf-RAG
  ├→ "Komplex / öppen" → Agentbaserad RAG
  └→ "Hel korpus / liten korpus" → Lång kontext

Varje variant producerar ett svar.
Observerbarheten spårar vilken väg som användes.
Utvärderingssviter täcker alla vägar.

Detta är mer komplext än en enskild variant, men hanterar hela frågespannet väl. För mogna system med varierande frågetyper är detta den slutliga arkitekturen.

En praktisk utbyggnad

Om du utgår från en fungerande klassisk RAG-lösning och vill bygga ut den:

Lägg först till lång kontext. Lägst utvecklingskostnad. Användbart för specifika frågetyper. Ger ofta omedelbara vinster.

Lägg till agentbaserad RAG för komplexa frågor. Identifiera frågorna som klassisk RAG har svårt med. Bygg en agent som hanterar dem. Routa villkorligt till den.

Lägg till graf-RAG sist. Högst utvecklingskostnad. Endast värt det om du har tydliga relationsbaserade frågemönster.

Denna ordning motsvarar vanligtvis avkastningen. Lång kontext: låg kostnad, konkret värde. Agentbaserad: måttlig kostnad, åtgärdar verkliga luckor. Graf: hög kostnad, specifika användningsfall.

Komplettera, ersätt inte

Klassisk textsegmentsbaserad RAG är arbetshästen, men den har begränsningar. Varianterna ”bortom textsegment” – graf-RAG, agentbaserad RAG och RAG med lång kontext – möjliggör olika förmågor.

Vägen framåt är inte att ersätta klassisk RAG, utan att komplettera den. Mogna system använder flera varianter, routade på lämpligt sätt, där varje variant hanterar frågorna den är bra på.

Investeringen är betydande – varje variant kräver verkligt utvecklingsarbete. Men för system där klassisk RAG når en platå är förmågevinsterna reella. Ett system som bara hanterar ”uppslagningsfrågor” väl är mycket mindre användbart än ett som även hanterar relationsfrågor, komplexa frågor och frågor över hela korpusen.

Kartlägg dina frågor. Identifiera dem som klassisk RAG hanterar dåligt. Välj den variant som passar. Bygg kompletteringen. Iterera.

Det är så RAG-system utvecklas från användbara för vissa frågor till verkligt kapabla över mångfalden av verkliga frågor.