Vad är RAG? Så använder företag sina egna data i en språkmodell

En språkmodell kan formulera ett övertygande svar utan att ha tillgång till den information som gäller i just er verksamhet. RAG, från engelskans retrieval-augmented generation, är ett sätt att minska det gapet. Tekniken låter en lösning söka efter relevanta uppgifter i godkända datakällor och använda dem som underlag när svaret skapas.

Det gör det möjligt att bygga exempelvis en intern kunskapschatt som svarar utifrån policyer, handböcker, rapporter eller produktdokumentation. Men RAG är inte en garanti för att varje svar blir korrekt. Resultatet beror på hur informationen har strukturerats, vilken åtkomst användaren har, hur sökningen fungerar och hur lösningen testas.

Vad är RAG?

RAG kombinerar två funktioner: informationshämtning och textgenerering. När användaren ställer en fråga söker systemet först efter relevant innehåll i en eller flera anslutna källor. De mest relevanta textavsnitten skickas sedan, tillsammans med frågan, till en språkmodell. Modellen formulerar ett svar med källmaterialet som kontext.

Begreppet etablerades i forskning om hur språkmodeller kan kombineras med ett externt, sökbart minne. En viktig poäng är att kunskap då inte bara behöver finnas lagrad i modellens parametrar. Den kan också hämtas från en källa som organisationen själv kan uppdatera och kontrollera.[1]

I praktiska företagslösningar omfattar RAG ofta fler lager än själva sökningen: dokumentbearbetning, identitet, behörighetsfiltrering, loggning, källvisning och uppföljning.

Så fungerar RAG steg för steg

1. Källor ansluts

Lösningen kopplas till godkända datakällor, till exempel SharePoint, ett dokumentarkiv, ett intranät eller en databas. Varje källa behöver en ägare och tydliga regler för vilka användare som får se innehållet.

2. Innehållet bearbetas

Dokument behöver kunna läsas av systemet. Text extraheras, delas vanligen upp i mindre avsnitt och kompletteras med metadata, exempelvis dokumenttyp, datum, avdelning och behörighetsinformation. Dåligt inskannade filer, dubbletter och motstridiga versioner försämrar resultatet.

3. Texten indexeras

Textavsnitten omvandlas ofta till numeriska representationer, så kallade embeddings. De lagras i ett sökindex där innehåll med liknande betydelse kan hittas även om frågan inte använder exakt samma ord som källan.

4. Frågan kontrolleras

När en användare ställer en fråga identifieras användaren och dennes åtkomst. Sökningen ska begränsas till information som användaren faktiskt har rätt att se. En gemensam chatt får inte bli en genväg förbi organisationens behörighetsmodell.

5. Relevanta avsnitt hämtas

Systemet väljer de avsnitt som bedöms vara mest relevanta. Här kan semantisk sökning kombineras med nyckelord, filter, omrankning och regler för aktualitet. Om fel avsnitt hämtas får modellen ett dåligt underlag, även om själva språkmodellen är stark.

6. Modellen formulerar ett svar

Frågan och de hämtade avsnitten skickas till vald språkmodell. Instruktionerna kan kräva att modellen håller sig till källorna, redovisar osäkerhet och avstår när underlaget inte räcker.

7. Källorna visas och resultatet följs upp

Användaren bör kunna se vilka dokument eller avsnitt som stöder svaret. Loggar och användarfeedback gör det möjligt att upptäcka återkommande fel och förbättra index, instruktioner och testfall.

RAG gör inte modellen ofelbar. Det gör svaren lättare att grunda, kontrollera och uppdatera.

RAG jämfört med att träna eller finjustera en modell

RAG och finjustering löser olika problem. RAG används främst för att ge modellen tillgång till aktuell eller verksamhetsspecifik kunskap vid svarstillfället. När en policy ändras kan källan uppdateras och indexeras om utan att modellen tränas om.

Finjustering påverkar i stället modellens beteende eller förmåga inom en viss uppgift. Det kan vara relevant för exempelvis klassificering, ton, format eller ett återkommande beslutsmönster. Finjustering är sällan det bästa sättet att lagra löpande uppdaterad fakta.

I vissa lösningar kombineras metoderna. En modell kan vara anpassad för uppgiften och samtidigt använda RAG för att hämta aktuell information. Valet ska utgå från problemet, datan och kraven – inte från vilken metod som låter mest avancerad.

Vilka problem kan RAG lösa?

RAG passar när rätt svar finns i ett avgränsat informationsunderlag men är svårt eller tidskrävande att hitta. Vanliga användningsområden är:

• stöd till medarbetare som söker i policyer, rutiner och handböcker

• teknisk support baserad på manualer och produktdokumentation

• dokumentanalys med sammanfattningar och källhänvisningar

• stöd i reglerade verksamheter där ursprunget till uppgifter måste gå att följa

• kundservice där svar ska grundas i aktuella villkor och godkänt innehåll

• research i rapportarkiv eller andra stora, kontrollerade kunskapsmängder

Tekniken är mindre lämplig om uppgiften framför allt kräver strukturerade beräkningar, deterministiska regler eller realtidsdata som bör hämtas direkt via ett API. Då kan RAG vara en del av lösningen, men inte nödvändigtvis kärnan.

Vad avgör kvaliteten på svaren?

Kvaliteten avgörs inte av en enda komponent. Minst fem delar behöver fungera tillsammans.

Källornas kvalitet

Föråldrade, motsägelsefulla eller otydliga dokument ger ett osäkert underlag. Informationsägarskap och versionshantering är därför lika viktiga som modellvalet.

Dokumentbearbetningen

Rubriker, tabeller, bilagor och metadata måste hanteras på ett sätt som bevarar sammanhanget. Om text delas upp på fel ställe kan centrala villkor separeras från sina undantag.

Sökningen

Lösningen behöver hitta rätt text för olika typer av frågor. Det bör testas separat från kvaliteten i det slutliga svaret.

Instruktionerna till modellen

Modellen måste veta när den ska använda källor, hur den ska ange osäkerhet och när den ska avstå. Prompten är dock inte ett tillräckligt säkerhetsskydd i sig.

Utvärderingen

Ett antal imponerande demosvar säger lite om hur lösningen fungerar över tid. Ett representativt testbibliotek behöver innehålla enkla frågor, tvetydiga frågor, behörighetsfall, otillräckligt underlag och frågor som lösningen ska vägra besvara.

NIST rekommenderar att generativa system hanteras genom hela livscykeln med dokumenterad riskbedömning, mätning och uppföljning.[2]

Behörigheter, källhänvisningar och spårbarhet

En företagslösning behöver skilja mellan rätten att använda plattformen, rätten att använda en viss funktion och rätten att hämta innehåll från en viss källa. Om två medarbetare ställer samma fråga kan deras källunderlag därför behöva vara olika.

Källhänvisningar gör det möjligt för användaren att kontrollera svaret, men de behöver också testas. En hänvisning kan vara relevant utan att faktiskt stödja hela påståendet. För känsliga eller verksamhetskritiska uppgifter bör lösningen utformas så att mänsklig kontroll är en del av arbetsflödet.

Loggning behövs för att kunna följa användning, felsöka och utreda incidenter. Samtidigt kan loggar innehålla personuppgifter eller känslig information. Vad som loggas, vem som får läsa loggarna och hur länge de sparas måste därför vara ett medvetet beslut.

När räcker inte RAG?

RAG kan inte kompensera för att organisationen saknar tillförlitliga källor. Tekniken löser inte heller alla risker med generativ text. Modellen kan missförstå ett korrekt avsnitt, blanda ihop flera källor eller formulera en alltför säker slutsats.

För uppgifter med mycket låg feltolerans kan ett mer styrt flöde krävas: fasta regler, strukturerad datavalidering, obligatoriskt mänskligt godkännande eller att modellen endast får extrahera information i stället för att dra egna slutsatser.

OWASP lyfter bland annat risker kopplade till manipulerade instruktioner, känslig informationsspridning och osäker hantering av modellens utdata.[3]

Så kommer ni igång

Innan ni väljer modell eller plattform behöver ni avgränsa vad lösningen ska kunna svara på och vilka källor som får användas.

• Utse en verksamhetsägare för problemet och en ägare för varje datakälla.

• Inventera dokumentformat, kvalitet, dubbletter och uppdateringsfrekvens.

• Klassificera informationen och definiera behörigheter.

• Bestäm hur källor och osäkerhet ska visas för användaren.

• Skapa representativa testfrågor och förväntade svar eller avslag.

• Sätt acceptanskriterier för sökning, svar, säkerhet och svarstid.

• Planera hur innehåll, tester och modeller ska förvaltas efter lansering.

En bra första pilot använder ett begränsat informationsområde och en tydlig användargrupp. Då går det att mäta om lösningen verkligen minskar söktid, förbättrar kvalitet eller gör ett arbetsflöde enklare – utan att öppna hela organisationens informationslandskap på en gång.

Källor

1. Lewis, P. m.fl., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020:
   https://arxiv.org/abs/2005.11401

2. NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, publicerad 2024 (webbsidan uppdaterad 2026):
   https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

3. OWASP, Top 10 for Large Language Model Applications / GenAI:
   https://genai.owasp.org/