Vad är RAG? Så fungerar Retrieval-Augmented Generation i praktiken

RAG, som står för Retrieval-Augmented Generation, uppstod som ett svar på ett väldigt konkret problem: stora språkmodeller är bra på att formulera text, men de bär inte säkert runt på all den fakta du behöver i en verklig verksamhet. De kan sakna information, de kan vara inaktuella, och de kan hallucinera.

Det klassiska syftet med RAG var därför tvådelat. Dels att minska hallucinationer genom att grunda svaret i faktiska dokument, dels att ge modellen tillgång till information som aldrig fanns i träningsdatan, till exempel interna manualer, avtal, produktblad, supportärenden eller teknisk dokumentation.

Idag har moderna LLM och språkmodeller och AI-agenter fler sätt att hämta information. De kan söka på webben, öppna filer, läsa terminalutdata, köra kod och navigera i system. Men RAG har fortfarande en tydlig fördel när uppgiften är att hitta relevant information i ett känt kunskapsunderlag snabbt, billigt och reproducerbart. Det är fortfarande ett av de mest praktiska retrievalmönstren som finns.

RAG i en mening

RAG är ett arkitekturlager runt språkmodellen. I stället för att hoppas att modellen redan "kan" svaret hämtar systemet först relevant information ur ett externt kunskapsunderlag, och skickar sedan den informationen tillsammans med frågan till modellen.

Hur fungerar RAG i praktiken?

I genomgången nedan utgår vi från textbaserad RAG, alltså den vanligaste och pedagogiskt tydligaste formen. Det är också den variant de flesta menar när de talar om RAG i dokument, kunskapsbanker och interna system. Senare återkommer vi till hur samma grundidé även kan användas multimodalt.

Om man zoomar ut består RAG i praktiken av två faser.

Först förbereder man materialet så att det blir sökbart. Dokumenten läses in, görs om till text, delas upp i mindre delar och omvandlas till numeriska representationer som går att jämföra matematiskt.

Sedan, när en användare ställer en fråga, gör systemet samma sak med frågan. Frågan omvandlas till en numerisk representation, systemet letar upp de mest relevanta textstyckena, och språkmodellen får sedan svara utifrån just det underlaget.

Det betyder att RAG inte är ett enda modellsteg, utan en hel pipeline där flera led måste fungera bra samtidigt. Om dokumentinläsningen är svag blir retrieval svag. Om chunkingen är dålig blir träffarna sämre. Om embeddingmodellen inte fångar betydelse väl spelar det mindre roll hur stark språkmodellen är i slutet. Det är därför RAG i praktiken är mer systemdesign än promptning.

Först byggs ett sökbart kunskapsunderlag

Dokumenten blir läsbar text

RAG börjar i dokumenten.

PDF:er, Word-filer, HTML, e-post, databasutdrag, bilder och ibland ljud eller video måste först omvandlas till ett format som systemet kan arbeta med. I enklare fall räcker det att extrahera rå text. I mer realistiska miljöer behöver man också fånga struktur, till exempel rubriker, tabeller, sidnummer, sektioner, käll-ID:n och ibland OCR om dokumenten är skannade.

Det här steget underskattas ofta, eftersom det är lätt att tänka att retrieval och språkmodell är det som "är AI" och därför det som spelar störst roll. I verkligheten är kvaliteten på inläsningen ofta avgörande. Om parsern tappar rubriker, tabellstruktur eller styckesgränser blir resten av RAG-pipelinen sämre, oavsett hur bra embeddingmodell eller språkmodell du väljer senare.

Det märks särskilt i material som inte är skrivet som ren löptext. Manualer, policydokument, avtal, supportärenden och tekniska specifikationer är ofta fulla av tabeller, punktlistor, fotnoter och bilagor. Om allt det plattas till på fel sätt får du fortfarande "text", men inte längre en särskilt bra representation av vad dokumentet faktiskt säger.

Texten delas upp i chunkar

När dokumenten väl finns som text delar man normalt upp dem i mindre bitar, så kallade chunks. Orsaken är enkel: retrieval fungerar bättre på mindre, fokuserade textstycken än på hela dokument, och det är också mycket billigare att skicka ett fåtal relevanta chunkar till modellen än att skicka allt.

Det finns flera sätt att göra detta på. Vissa system chunkar efter rubriker och semantiska sektioner. Vissa använder rekursiva strategier. Vissa använder fasta fönster. Men i praktiken är tokenbaserad chunking fortfarande ett vanligt standardval, eftersom både tokenizer, embeddings och kontextfönster ändå arbetar i tokens.

Det viktiga är att chunkarna blir tillräckligt små för att vara precisa, men inte så små att de tappar sitt sammanhang. Om du delar all text för hårt kan du få stycken som var för sig ser irrelevanta ut, trots att de tillsammans bär den information du faktiskt behöver. Om du gör chunkarna för stora får du i stället sämre precision, högre kostnad och större risk att språkmodellen får med för mycket brus i varje anrop.

Man använder därför ofta också overlap, alltså att två intilliggande chunkar delar ett visst antal tokens. Det minskar risken att viktig information kapas mitt i en mening, mitt i en tabellrad eller precis mellan två stycken som hör ihop. Samtidigt kostar för mycket overlap både lagring och retrievalkvalitet, eftersom du skapar fler nästan identiska chunkar som konkurrerar med varandra.

I Chromas utvärdering av chunking såg man också att chunkingstrategin faktiskt påverkar retrievalkvaliteten påtagligt, och att det inte finns en enda strategi som vinner för alla typer av material. Det är värt att understryka, eftersom många beskriver chunking som ett enkelt förberedelsesteg. I praktiken är det ett av de ställen där ett RAG-system ofta vinner eller förlorar i kvalitet.

Varje chunk blir en embedding

När textstyckena är skapade skickas de till en embeddingmodell. Den gör inte ett färdigt svar. Den omvandlar varje chunk till en numerisk representation, en vektor, som fångar den semantiska innebörden.

En embedding kan se ut som en lång lista flyttal, till exempel:

[0.018, -0.442, 0.731, 0.094, -0.118, 0.507, -0.221, 0.063, ...]

I verkligheten är den mycket längre än så. Många moderna embeddingmodeller arbetar med hundratals eller tusentals dimensioner, ofta exempelvis 768, 1024, 1536, 3072 eller 4096, beroende på modell. Poängen är inte att människor ska tolka varje tal. Poängen är att texter med liknande betydelse hamnar nära varandra i ett högdimensionellt rum.

Det här är också skälet till att embeddingmodellen är ett viktigt arkitekturval i RAG. En svag embeddingmodell kan ge dålig retrieval även om språkmodellen efteråt är mycket stark. Om modellen är dålig på svenska, på juridiskt språk, på teknisk terminologi eller på multimodalt innehåll, då börjar hela retrievalkedjan redan med en sämre representation av materialet.

Det är också värt att förstå att embeddingmodellen och språkmodellen inte måste vara samma typ av modell. I många system är de olika komponenter med helt olika roller. Embeddingmodellen används för att ordna materialet i ett sökbart semantiskt rum. Språkmodellen används senare för att läsa den hämtade kontexten och formulera ett svar.

Vektorerna lagras i ett sökbart index

När embeddings är skapade måste de lagras på ett sätt som gör dem snabba att söka i. Det är här vektordatabaser och andra vektorindex kommer in.

Där lagras inte bara själva vektorn, utan ofta också metadata som dokument-ID, sektion, källa, sidnummer, språk och ibland länkar tillbaka till den ursprungliga chunken. Det är viktigt, eftersom retrieval i slutänden inte bara handlar om att hitta en vektor som ligger nära en annan vektor. Systemet måste också kunna gå tillbaka till det faktiska textstycket och ofta till dess källa.

Under huven används ofta någon form av approximate nearest neighbor-indexering, till exempel HNSW eller liknande strukturer, eftersom exakt jämförelse mot varje vektor blir dyr när mängden data växer. För användaren märks det sällan, men för systemdesignen är det avgörande. Utan ett bra index blir retrieval antingen för långsamt eller för dyrt när materialet blir stort.

Sedan används underlaget när någon ställer en fråga

Frågan blir också en embedding

När användaren ställer en fråga omvandlas även frågan till en embedding. Nu finns både dokumentens chunkar och användarens fråga representerade i samma matematiska rum.

Det gör att systemet kan jämföra frågan med det indexerade materialet på samma sätt som det redan jämför olika chunkar med varandra. Det är just detta som gör att RAG inte fastnar i ren nyckelordslogik. En fråga behöver inte använda exakt samma ord som dokumentet gör, så länge embeddingmodellen fångar att betydelsen är nära.

Det här är också skälet till att RAG kan fungera bra i verkliga verksamheter där språkbruket varierar. En användare kan skriva "hur gör man semesteransökan" medan dokumentet talar om "ledighetsansökan i HR-systemet". Om embeddingmodellen gör sitt jobb väl finns ändå en god chans att de hamnar nära varandra semantiskt.

De mest relevanta styckena hämtas

Nu kommer själva retrievalsteget. Systemet letar upp de chunkar vars vektorer ligger närmast frågans vektor.

Detta görs ofta med cosine similarity eller dot product. Idén är densamma i båda fallen: systemet mäter vilka vektorer som liknar frågevektorn mest i ett högdimensionellt rum. Sedan hämtas normalt de k närmaste träffarna, till exempel topp 3, 5 eller 10.

Efter det används metadata för att hämta tillbaka själva textstyckena, inte bara vektorerna. Det är dessa textstycken som sedan skickas vidare till språkmodellen. I många praktiska system lägger man också till ett extra steg här, där träffarna omordnas eller filtreras ytterligare innan de skickas vidare. Men kärnan är densamma: först semantisk retrieval, sedan faktisk text tillbaka in i modellen.

Semantisk retrieval handlar inte om exakta nyckelord, utan om närhet i ett vektorrum där liknande betydelser placeras nära varandra.

Det är viktigt att förstå att retrieval inte "förstår" i mänsklig mening. Det väljer de chunkar som verkar mest semantiskt lika frågan. Det gör det ofta mycket kraftfullt, men också begränsat. Systemet är bra på att hitta det mest relevanta, men inte automatiskt på att avgöra om frågan egentligen kräver hela fördelningen av relevanta träffar, en bred jämförelse eller en exakt uppräkning.

Först nu genererar språkmodellen ett svar

När retrievalsteget är klart byggs prompten till språkmodellen. Den består ofta av användarens fråga, instruktioner om hur svaret ska formuleras, och de hämtade chunkarna som kontext. Först här kommer själva genereringen in.

Det är därför RAG inte är samma sak som modellträning. Du ändrar inte språkmodellens vikter. Du ändrar vilket underlag modellen får se i det aktuella anropet. Om du vill förstå den skillnaden djupare är nästa naturliga steg våra sidor om LLM, tokenizer och kontextfönstret.

Detta är en av RAG:s stora styrkor. Om dokumenten ändras behöver du i många fall inte träna om modellen. Du behöver i stället uppdatera det sökbara underlaget. Det gör RAG särskilt attraktivt i miljöer där information förändras ofta, men där man ändå vill kunna bygga AI-system ovanpå den.

När räcker promptning, när behövs RAG och när blir finetuning relevant?

Det är lätt att blanda ihop de här tre sakerna, eftersom de alla används för att få bättre resultat ur en språkmodell. Men de löser i grunden olika problem.

Promptning

Promptning handlar om hur du formulerar instruktionen till modellen. Du kan ofta komma långt med bättre struktur, tydligare rollinstruktioner, bättre exempel och tydligare krav på format eller ton. Det är nästan alltid det första man bör förbättra, eftersom det är snabbt, billigt och inte kräver något extra system runt modellen.

Men promptning ger inte modellen ny kunskap. Den kan hjälpa modellen att använda det den redan har bättre, men den kan inte i sig ge modellen tillgång till ett nytt avtal, en uppdaterad prislista eller en intern manual som aldrig fanns i träningsdatan.

RAG

RAG blir relevant när problemet inte främst är hur du instruerar modellen, utan vilket underlag modellen faktiskt får se. Det är alltså rätt verktyg när svaret behöver bygga på extern, uppdaterbar eller företagsintern information. I stället för att försöka skriva in all kunskap i prompten, eller hoppas att modellen redan kan den, hämtar systemet fram rätt material i samma stund som frågan ställs.

Det gör RAG särskilt starkt när kunskapen ändras över tid, när materialet är för stort för att ligga direkt i prompten och när du vill kunna koppla svaret till faktiska källor.

Finetuning

Finetuning blir relevant när problemet ligger djupare än både promptning och retrieval. Det handlar inte främst om att ge modellen mer fakta i stunden, utan om att förändra modellens beteende mer varaktigt. Det kan till exempel handla om att modellen ska följa ett visst format mycket konsekvent, lära sig en särskild tonalitet eller bli bättre på en smal uppgift där vanlig promptning inte räcker.

Finetuning är däremot normalt inte det naturliga förstavalet om målet bara är att modellen ska kunna läsa ny eller ofta uppdaterad information. Där är RAG oftast betydligt mer naturligt, eftersom du då uppdaterar kunskapsunderlaget i stället för själva modellen.

I praktiken arbetar många bra system med alla tre nivåerna samtidigt. Först gör man promptningen tydlig, sedan lägger man till RAG om modellen behöver extern kunskap, och först därefter överväger man finetuning om beteendet fortfarande inte blir tillräckligt stabilt eller specialiserat. Vill du gå djupare i den delen kan du läsa vidare om finetuning.

RAG fungerar inte bara på text

Många förknippar RAG med textdokument, och det är fortfarande den vanligaste formen. Men själva mönstret är bredare än så.

Om du har embeddingmodeller som kan placera flera modaliteter i samma semantiska rum blir det möjligt att göra retrieval över mer än text. Google beskrev detta tydligt när de lanserade Gemini Embedding 2, en modell som kan arbeta multimodalt. Idén är att text, bild, ljud och video kan representeras i ett gemensamt vektorrum så att en fråga kan hitta det mest semantiskt relevanta innehållet, oavsett modalitet.

Det betyder att en fråga i text i princip kan hämta ett textstycke som beskriver ett fel, en bild på rätt komponent, ett videoklipp där momentet demonstreras eller ett ljudklipp från support, så länge allt detta är inbäddat i samma typ av semantiskt rum. Det gör RAG intressant långt utanför ren dokumentchatt, särskilt i miljöer där kunskap faktiskt är spridd över flera medietyper.

Varför RAG fortfarande har en tydlig edge

När människor pratar om moderna agentsystem blandas ofta flera retrievalsätt ihop. En agent kan söka på webben, köra terminalkommandon, öppna filer eller fråga ett API. Allt det är användbart. Men RAG har fortfarande flera starka egenskaper.

Det går snabbt att söka i stora mängder redan indexerad information. Retrieval blir mer reproducerbart än fri surf eller fri verktygsnavigation. Det fungerar väl för privata dokument och interna kunskapsbaser. Och det går att knyta träffarna till källor, metadata och ibland citat på ett sätt som ofta är svårare i öppnare agentflöden.

Det är därför RAG ofta blir det retrievallager som andra system byggs ovanpå, även när agenten i övrigt är mer avancerad. En agent kan vara duktig på att planera, men den behöver fortfarande ofta ett robust sätt att hitta rätt information i rätt mängd. Där fyller RAG fortfarande en väldigt tydlig funktion.

Styrkor och svagheter

Den största styrkan med RAG är att det är mycket bra på att hitta en specifik nål i en stor höstack. Om rätt information finns i materialet, och om chunking samt embeddings är rimliga, är chansen god att retrieval hittar de mest relevanta styckena även när exakt formulering skiljer sig från frågan.

Det gör tekniken särskilt stark när relevant information faktiskt finns koncentrerad i några få tydliga textstycken. Det kan handla om policydokument, instruktioner, tekniska svar, supportsammanfattningar eller intern kunskap som någon snabbt behöver få åtkomst till utan att bläddra manuellt genom stora mängder material.

Men RAG har också tydliga svagheter, och de blir viktiga att förstå så fort frågorna blir mer komplexa.

När RAG ofta blir svagare

RAG är mindre starkt när frågan kräver att systemet inte bara hittar de mest lika chunkarna, utan förstår relationer eller summerar många snarlika informationspunkter samtidigt.

Tänk dig en lång maskinmanual med tjugo maskiner där varje maskin har en sektion om oljebyte. Om du frågar "Vilka skillnader finns mellan hur man byter olja på maskinerna?" eller "Hur många maskiner kräver oljebyte var 500:e timme?" räcker det inte alltid att hämta de tre eller fem närmaste chunkarna. Top k-retrieval tenderar att ge dig de mest semantiskt lika träffarna, inte nödvändigtvis hela mängden relevanta träffar.

Det betyder att vanlig RAG ofta är starkare på att hitta rätt sak än på att skapa en heltäckande sammanställning av många relaterade saker. Den är mycket bra på precis retrieval, men betydligt mindre självklar när frågan i grunden handlar om att räkna, jämföra brett eller förstå relationer mellan många datapunkter samtidigt.

Det är också här vanlig RAG ofta börjar ge vika för mer specialiserade mönster, till exempel Graph RAG när relationer är centrala, eller Agentic RAG när systemet måste bryta ned frågan i flera delproblem och söka iterativt.

Tre vanliga varianter av RAG

Standard RAG

Det här är den vanligaste formen. Frågan embedas, de närmaste chunkarna hämtas ur ett vektorindex, och de skickas sedan till språkmodellen som kontext. För många dokumenttunga användningsfall räcker det långt.

Det är också den variant som oftast avses när någon bara säger "RAG" utan att specificera mer. När människor talar om att "koppla AI till företagets dokument" är det ofta just standard RAG de menar.

Graph RAG

Graph RAG försöker lösa ett annat problem än vanlig likhetssökning. I stället för att bara fråga "vilka chunkar liknar min fråga mest?" försöker systemet explicit modellera relationer mellan entiteter, fakta och begrepp.

Det passar bättre när frågan handlar om samband, beroenden, nätverk eller relationer mellan flera informationspunkter. I sådana fall är semantisk närhet inte alltid nog. Det kan till exempel vara viktigare att förstå hur två saker hänger ihop än att hitta det textstycke som råkar ligga närmast frågans ordval.

Graph RAG blir relevant när informationen främst ligger i relationerna mellan saker, inte bara i enskilda textstycken.

Agentic RAG

Agentic RAG lägger till planering ovanpå retrieval. I stället för en enda retrievalsökning kan systemet bryta ner en komplex fråga i flera delfrågor, välja olika datakällor, göra följdsökningar och först därefter sammanställa svaret.

Det börjar då närma sig AI-agenter. Skillnaden är att retrieval fortfarande står i centrum, men att retrievalkedjan blivit mer dynamisk och flerledad. I stället för att fråga en gång och hämta en gång kan systemet resonera kring vilken källa som bör användas, vad som saknas och vilken nästa sökning borde vara.

Agentic RAG är användbart när en enda likhetssökning inte räcker, utan systemet måste välja källa och sökstrategi steg för steg.

Så hänger RAG ihop med resten av kunskapsklustret

RAG är sällan en isolerad teknik. Den hänger ihop med flera andra lager.

Den hänger ihop med LLM och språkmodeller, eftersom RAG i grunden är ett retrievallager runt modellen, inte en ersättning för modellen. Den hänger ihop med Tokenizer, eftersom chunking, tokenbudget och embeddingflöden i praktiken bygger på tokenisering. Den hänger ihop med Kontextfönstret, eftersom alla retrieved chunkar måste få plats i modellens arbetsyta. Och den hänger ihop med AI-agenter, eftersom agenter ofta använder RAG som ett av flera retrievalverktyg.

Om du vill se hur den här tekniken används praktiskt på företagsintern information är nästa naturliga steg också sidan om AI med er data.

Sammanfattning

RAG uppstod för att språkmodeller behövde ett sätt att arbeta med aktuell och extern information utan att tränas om varje gång datan förändras. Det är fortfarande kärnpoängen.

I praktiken bygger man först ett sökbart kunskapsunderlag genom att läsa in dokument, dela upp dem i chunkar, skapa embeddings och lagra dem i ett vektorindex. När frågan sedan kommer in gör systemet samma sak med frågan, hämtar de mest relevanta textstyckena och låter först därefter språkmodellen generera sitt svar.

Det är också därför RAG är så användbart. Det låter språkmodellen arbeta med rätt information vid rätt tillfälle, utan att modellens vikter behöver ändras. Samtidigt har tekniken tydliga begränsningar, särskilt när frågor kräver bred jämförelse, uppräkning eller förståelse för relationer över många datapunkter. Det är där mer avancerade varianter som Graph RAG och Agentic RAG blir relevanta.

Vill du bygga robusta system på dokument och intern kunskap är RAG fortfarande ett av de mest användbara mönstren att förstå ordentligt.