RAG i bedriften: bygg en intern kunnskapsassistent på 90 dager

Hva er RAG – og hvorfor passer det i norske virksomheter?

RAG (Retrieval-Augmented Generation) kombinerer to ting:

et søk som henter relevante utdrag fra dine egne dokumenter, og
en språkmodell som bruker disse utdragene som faktagrunnlag for svaret.

Resultatet er svar med høyere presisjon og kildevisning – uten å trene en egen modell. For norske virksomheter betyr dette raskere innsikt i policyer, prosedyrer, produktark og avtaler, med bedre styring på sikkerhet og personvern.

RAG vs. finjustering (fine-tuning)

RAG: bruker oppdaterte dokumenter som «kontekst». Fungerer straks dokumentene er indeksert. Lavere risiko for foreldet kunnskap.
Finjustering: lærer innhold inn i modellen. Bedre på stil/format og svært spesifikke oppgaver, men krever datasett, drift og styring.

Praktisk råd: Start med RAG for kunnskapsarbeid og beslutningsstøtte. Vurder finjustering først når du trenger konsistent stil/format på tvers av store volumer.

Kilde: Google Cloud – Architectural patterns for RAG

Use case i B2B: der RAG gir størst effekt først

Intern kunnskapsassistent (HR/IT/økonomi): Svar på interne retningslinjer, verktøy og rutiner med kildevisning.
Kundeservice kunnskapsbase: Svar forankret i produktark, policyer og driftsmeldinger. Agentassist med forslag til svar.
Dokumenthåndtering og kontrakt: Finn avvik mot maler, oppsummer endringer og vis sitater fra kildedokument.
Prosjekt- og teknisk dokumentasjon: Raskt oppslag i manualer, arkitektur- og API-dokumentasjon.
Compliance og kvalitetsstyring: Policyoppslag med sporbarhet, versjoner og lenker til originalkilde.

Effekten kommer når ansatte finner riktig svar raskt – og kan vise kilden i etterkant.

Kilder: NIST AI Risk Management Framework; Google Cloud – Architectural patterns for RAG

Arkitektur i praksis: fra dokument til svar med kilde

1) Datakilder og tilgang

Koble til SharePoint, Google Drive, Confluence, intranett, CRM/ITSM og leverandørportaler.
Bruk SSO/RBAC for å respektere eksisterende tilgangsnivåer.
Etabler synk-jobber (planlagt eller hendelsesdrevet) for å holde indekser oppdatert.

2) Indeksering og embeddings

Transformer dokumenter (PDF, DOCX, HTML) til tekst med struktur (tittel, seksjoner, metadata).
Del opp i «chunks» (avsnitt) og lag embeddings (numeriske vektorer) som muliggjør semantisk søk.
Lagre i en vektordatabase eller søketjeneste som støtter lignende-søk og filtrering (metadata som språk, dato, avdeling).

3) Retrieval og rangering

Ved spørsmål hentes 3–10 relevante utdrag (top-k) basert på semantisk likhet og metadatafiltre.
Reranking (valgfritt) kan forbedre rekkefølge basert på kontekst og brukerrolle.

4) Generering og kildevisning

Språkmodellen får spørsmålet + utdrag som kontekst og genererer svar.
Vis kildereferanser (lenke/filnavn + utdrag) i svaret. Det øker tillit og gjør kontroll enklere.

5) Sikkerhet og styring

Bruk policyer for maks kontekstmengde, PII‑maskering der relevant og logging for revisjon.
Skill mellom test og produksjon. Versjoner indekser og «prompts» for sporbarhet.

Kilde: Google Cloud – Architectural patterns for RAG

Sikkerhet og GDPR for RAG

Behandlingsgrunnlag og dataminimering

Avklar grunnlag (samtykke, avtale eller berettiget interesse) før du bruker personopplysninger i RAG.
Minimer data: indekser bare nødvendige kilder og vurder anonymisering/pseudonymisering.

Lagringssted, tilgang og overføringer

Prioriter EU/EØS-lagring. Bruk databehandleravtaler og egnede overføringsmekanismer ved behov.
Respekter tilgangsnivåer fra kildesystemene (SSO/RBAC) og loggfør oppslag.

Logging, sporbarhet og DPIA

Logg hva som er lest, av hvem og når. Oppbevar referanse til kildedokument og versjon.
Gjennomfør DPIA når personopplysninger behandles i nye eller vesentlig endrede prosesser.

Kilder: Datatilsynet – Virksomhetenes plikter; Regjeringen – Nasjonal strategi for kunstig intelligens; OpenAI Enterprise Privacy (eksempel på virksomhetskontroller)

Kvalitet og måling: slik evaluerer du RAG

Presisjon/Recall: Andel korrekte svar og hvor mye relevant innhold som hentes.
Kildeandel: Andel svar med tydelig kildevisning og riktig sitat.
Hallusinasjonsrate: Andel svar med påstander uten dekning i kildene.
Tidsbruk og adopsjon: Tid til svar, antall aktive brukere, oppslag per uke.
Tilbakemelding i flyt: Tommel opp/ned, «rapporter feil»-knapp med automatisk sak.

Etabler et lite testsett (spørsmål + fasit/kilder) og kjør jevnlige regresjonstester ved endringer i indeks eller prompt.

Kilde: NIST AI Risk Management Framework

Kost og drift: hva driver prisen – og hvordan styre den

Modellforbruk: tokens/kontekst per svar. Store dokumentutdrag øker kost.
Indeksdrift: lagring av vektorindekser, synk-jobber og prosessering av nye dokumenter.
Integrasjoner: API-kall mot kildesystemer og eventuelle mellomvarekomponenter.
Observabilitet: logging, dashbord og kvalitetsmåling.

Tiltak for kostkontroll:

Begrens kontekststørrelse og antall utdrag (top-k) uten å ofre kvalitet.
Cache svar på hyppige spørsmål (der det er uproblematisk).
Skill «eksperiment» og «produksjon» med egne budsjetttak og varsler.

Kilder: OpenAI Enterprise Privacy (kost/styringsprinsipper); NIST AI RMF

90-dagers plan: fra idé til pilot i produksjon

0–30 dager: behov, kilder og akseptkriterier

Velg 1–2 scenarioer (for eksempel HR‑policy og IT‑brukerstøtte).
Kartlegg kilder, eierskap og tilgang. Rydd duplikater og motstridende dokumenter.
Definer akseptkriterier: presisjon >85%, kildevisning i 100% av svar, maks hallusinasjonsrate.

For overordnet bakteppe om KI‑begreper og styring, les mer i vår hovedartikkel: les mer om dette i vår hovedartikkel.

31–60 dager: prototype og kvalitetstesting

Sett opp pipeline: ingest → chunking → embeddings → vektorsøk → generering med kildevisning.
Test med ekte brukere. Mål kvalitet mot testsett og juster chunk‑størrelse, top‑k og prompts.
Etabler logging, tilgangskontroll og enkel driftsrutine for indekser.

61–90 dager: pilot og beslutning

Rull ut til en avdeling. Mål KPIer ukentlig (kvalitet, bruk, tid spart).
Dokumenter gevinst og risiko. Beslutning: stoppe, forbedre eller skalere.

Kilder: NIST AI RMF; Datatilsynet – Virksomhetenes plikter

Vanlige feil – og hvordan unngå dem

Uklart kildegrunnlag: motstridende dokumenter gir motstridende svar. Rydd først.
Ingen kildevisning: reduserer tillit. Gjør referanser obligatoriske.
For stor kontekst: dyrt og uklart. Optimaliser chunk‑størrelse og top‑k.
Manglende tilgangsstyring: respekter RBAC/SSO fra kildesystemene.
Null måling: uten testsett og brukerfeedback vet du ikke om kvaliteten øker.

Sjekkliste før pilot

Godkjente datakilder, eierskap og versjonering
Ingest‑pipeline med chunking, embeddings og vektorsøk
Kildevisning på plass og testet
SSO/RBAC, logging og skille mellom test/produksjon
Testsett for kvalitet + dashbord for effekt
Budsjettgrenser og varsler for modellforbruk

Neste steg (CTA)

Book en prat – vi prioriterer riktig use case og setter opp en trygg RAG‑pilot.
Få gratis AI‑vurdering – rask sjekk av datagrunnlag, arkitektur og risiko.

FAQ

Hva er fordelene med RAG fremfor tradisjonelt søk?

RAG kombinerer semantisk søk med språkforståelse og gir et ferdig svar med sitater fra kildene. Det sparer tid og øker presisjon sammenlignet med tradisjonelle nøkkelord‑søk.

Trenger vi en vektordatabase?

Du trenger en lagring som støtter semantisk likhetssøk. Det kan være en dedikert vektordatabase eller en søketjeneste med vektor‑støtte.

Kan vi bygge RAG med eksisterende kontorverktøy?

Ja, mange plattformer støtter RAG‑funksjoner eller connectorer til dokumentkilder. Vurder likevel behov for egen indeks for kontroll, kvalitet og koststyring.

Hvordan sikrer vi norsk språk og terminologi?

Bruk norske kilder, tydelige eksempler og evalueringssett. Velg modeller som fungerer godt på norsk, og finjuster prompts for tone/termer.

Når bør vi finjustere modellen i stedet for RAG?

Finjustering passer når stil/format må være helt konsistent over store volumer. For kunnskapssøk og beslutningsstøtte er RAG vanligvis mer kost‑ og tids‑effektiv.

Hvilke data bør ikke indekseres?

Unngå svært sensitive data uten ekstra kontroller. Følg dataminimering, anonymisering der mulig og sikre tydelig tilgangsstyring og logging.

Hvordan beregner vi kostnaden?

Regn på indeksdrift (lagring + synk), modellforbruk per svar (tokens/kontekst) og integrasjonskost. Sett caps og varsler fra dag én.