RAG vs. LLM: Teknisk gjennomgang (definisjoner, forskjeller, bruksområder)

LLM-er genererer svar ved hjelp av parametere som er lært fra mønstre i treningsdataene deres. Fordi disse parameterne kanskje ikke gjenspeiler nyere eller fullstendig informasjon, supplerer RAG, som står for retrieval-augmented generation, prosessen ved å legge til data fra eksterne kilder i LLM-ens inndatakontekst. Et KI-verktøy henter informasjon utenfra for å berike LLM-ens genererings prosess.

I virkeligheten er valget ditt ikke mellom RAG eller en LLM. Det er mellom en hybridtilnærming og en som bare bruker en LLM.

RAG er nødvendig når en LLM trenger tilgang til bedriftsdokumentasjon, databaser eller raskt skiftende informasjon. En LLM-only-tilnærming er egnet for enkelte administrative oppgaver, databehandling og innholdsproduksjon der all inndata kan leveres av brukeren.

RAG vs. LLM: Hva er de viktigste forskjellene?

• RAG og LLM-er er komplementære systemer. Du kan bruke en KI-modell uten RAG (der den utelukkende baserer seg på sine eksisterende parametere), men du kan ikke bruke et RAG-system uten en modell.
• RAG ble introdusert for å løse tre nøkkelproblemer med LLM-er: utdatert informasjon, hallusinerte svar og mangel på verifisering mot tredjepartskilder.
• RAG gjør KI langt mer effektiv i reelle forretningssituasjoner fordi det kobler LLM-er med verifisert intern dokumentasjon, databaser og API-endepunkter.
• De viktigste bruksområdene for RAG inkluderer kundestøtte-chatboter, spørsmål basert på hurtigskiftende data (som bransjenyheter) og spesialiserte fagområder, som medisin og jus, der presisjon og faktasjekk av kilder er viktig.
• Det finnes tre hovedtyper av RAG: enkel RAG, modulær RAG og avansert RAG. Enkel RAG kan best forstås som enkel informasjonsinnhenting, mens modulær og avansert RAG legger til ekstra funksjonalitet som omskriving av søk og optimalisering av tekstbiter.

Hva er en stor språkmodell (LLM)?

En LLM, eller stor språkmodell, er et system som genererer innhold ved hjelp av finjusterte parametere. Disse parameterne bestemmer sannsynlighetene som tilordnes alle tokenene i en LLM-vokabular, og viser hvilket token som mest sannsynlig kommer som det neste i en gitt sekvens.

For å forstå bedre hvordan RAG fungerer (og skiller seg fra) LLM-er, er det nyttig å se på hvordan generativ KI fungerer på et grunnleggende nivå:

1. Tokenisering: En brukers prompt deles opp i tokens, som kan være ord, deler av ord eller enkelttegn.
2. Innebygging: Tokens konverteres til embeddings, numeriske representasjoner (tallstrenger) kalt vektorer, som det nevrale nettverket, som inkluderer en dekoder, kan behandle.
3. Dekoding: Lagene i dekoderen (som utgjør en stor del av LLM-ens nevrale nettverk) manipulerer disse vektorene ved hjelp av en prosess som kalles oppmerksomhet for å fange opp mening. Denne prosessen bestemmer hvor sterkt hvert token skal være relatert til andre tokens i sekvensen.
4. Scoring: Modellen tilordner en kompatibilitetssannsynlighet til hvert token i sitt eksisterende vokabular og velger et sannsynlig neste token for sekvensen.

Det viktige poenget er at en LLM bare kan produsere output basert på sine eksisterende parametere og tokenene i kontekstvinduet. Under trening blir en LLM bedt om å fullføre deler av ufullstendig tekst milliarder av ganger, og parameterne justeres til den tilordner sannsynligheter til tokens (og dermed fullfører teksten) pålitelig.

Se for deg for eksempel at du spør en KI-modell: «Hva sier selskapets refusjonspolicy for 2026?» LLM-en kan bare forutsi de neste tokenene basert på sine eksisterende parametere, som ikke har blitt finjustert ved hjelp av støttedokumentasjonen din. Hvis du stiller dette spørsmålet uten noen ekstra kontekst, vil den rett og slett ikke kunne svare på en meningsfull måte, eller den vil hallusinere et feil svar.

Hva er retrieval-augmented generation (RAG)?

RAG (retrieval-augmented generation) er prosessen der informasjon fra eksterne systemer inkluderes i en LLM-prompt.

Den underliggende LLM-prosessen, som innebærer innebygging og probabilistisk tokenmatching, forblir den samme. RAG introduserer et innledende trinn der brukerprompten utvides med ekstra data.

Her er en oversikt over hvordan RAG fungerer:

1. Kunnskapsforberedelse: En kunnskapskilde forberedes. Dette kan være et sett med dokumenter, en vektordatabase, en kunnskapsgraf eller et levende indeksregister (for eksempel for KI-søk).
2. Prompting: En bruker skriver inn en prompt, for eksempel: «Bør jeg gå en tur i London i dag?»
3. Henting: Den eksterne informasjonskilden blir spurt av KI-verktøyets retriever. Den kan innebygge prompten, gjøre den om til en vektor og deretter spørre en vektordatabase. Alternativt kan den bruke en alternativ metode, som et API-kall, samsvar av nøkkelord eller traversering av kunnskapsgraf.
4. Innføring: Denne informasjonen legges til brukerens opprinnelige prompt. I eksemplet med spørsmålet om å gå tur i London kan dette inkludere værinformasjon i London og den aktuelle tilgjengeligheten av populære gå-ruter.
5. Generering av svar: LLM-en genererer et svar på vanlig måte ved hjelp av den utvidede prompten.

Bak kulissene blir den hentede teksten lagt til i inndatakontexten, tokenisert og innebygd. Modellen behandler deretter den ekstra konteksten gjennom dekoderen sin, noe som endrer sannsynlighetene for utgangstokenene.

Grovt sett kan RAG deles inn i tre undertyper. Enkel RAG følger den grunnleggende RAG-prosessen ved å hente informasjon og mate den inn i prompten. Avansert RAG legger til ekstra funksjoner som omskriving av søk og flere søkeomganger. Modulær RAG viser til en type arkitektur der ulike avanserte funksjoner kan behandles som komponenter og kombineres etter behov.

RAG vs. LLM: Oversikt over bruksområder

RAG gir brukerne tilgang til oppdaterte data. Dette fører til LLM-utdata som har mindre sannsynlighet for å inneholde hallusinasjoner og informasjonsmangler. Hvis du trenger å se kildene til informasjonen som brukes i et output, er RAG også avgjørende, siden LLM-svar uten forankring ikke kommer med kildeangivelser.

Forstørr

Bruksområder for RAG

• Forespørsler om tidskritisk informasjon: Alle spørsmål om informasjon som raskt blir utdatert, noe som kan være noe så enkelt som en værmelding eller så komplekst som en detaljert analyse av en nyhetssak under utvikling, må være basert på validerte tredjepartskilder.
• Bedriftsdokumentasjon: Interne eller kundevendte KI-chatboter der brukere stiller spørsmål knyttet til bedriftens eller produktets dokumentasjon, bør ha RAG aktivert, spesielt hvis dokumentasjonen ofte oppdateres.
• Kundestøtte: Kundechatteroboter trenger tilgang til oppdatert og detaljert støttedokumentasjon for å kunne gi presise svar.
• Spesialiserte fagområder (medisin, jus, finans osv.): LLM-er som ikke er trent på domene-spesifikke korpus (særlig mainstream-modeller) sliter vanligvis med nyansene i spesialiserte prompts.

Bruksområder for LLM

• Administrative oppgaver: LLM-er kan fullføre grunnleggende oppgaver med minimal forsinkelse. RAG er unødvendig for grunnleggende skrive- og adminoppgaver, som stavekontroll eller oppsummering, der ekstern informasjon ikke er nødvendig.
• Kreative oppgaver: Noen kreative oppgaver, som å generere en kort historie eller et bilde, trenger bare informasjonen som er oppgitt i den opprinnelige prompten.
• Resonnering og databaserte oppgaver: Analyse- og resonneringsarbeidsflyter som kun refererer til dataene som er gitt i en prompt, trenger ikke RAG-funksjoner.
• Generell koding: Selv om en kodingsarbeidsflyt kan kreve tilgang til en privat kodebase eller dokumentasjon, er LLM-er svært gode til å utføre generelle kodingsoppgaver, som å fikse feil og lage funksjoner, uten å måtte bruke eksterne kilder.

RAG vs. LLM med langkontekst-LLM, agentisk KI og forankring

Det finnes tre beslektede konsepter som er relevante for skillet mellom RAG og LLM-er. Dette er LLM-er med lang kontekst, agentisk KI og forankring.

LLM-er med lang kontekst kan noen ganger brukes i stedet for RAG-aktiverte systemer, mens agentisk KI og forankring er synonymer med eller fungerer sammen med dem.

LLM-er med lang kontekst

Dette er modeller med store kontekstvinduer, der noen allment tilgjengelige kommersielle modeller kjører med opptil én million tokens.

Hvis relevant materiale får plass i modellens kontekstvindu og er tilgjengelig i et tekstformat, finnes det noen fordeler ved å bruke en LLM-only-tilnærming. Det kan redusere risikoen for hente-feil, gi mer omfattende kontekst og eliminere behovet for omfattende oppsett av RAG-arkitektur.

Agentisk KI

En agent er et system som bruker flere verktøy, inkludert RAG-funksjoner, for å utføre komplekse oppgaver. RAG er én komponent i agentisk KI, og en agent vil ofte bruke ulike typer hente-metoder (f.eks. nettsøk vs. vektorsøk) avhengig av innholdet i en prompt.

Forankring

Forankring viser til den bredere prosessen med å bruke bevis eller data for å forbedre nøyaktigheten til, eller forankre, et LLM-svar. RAG er én form for forankring, men å legge til et teknisk dokument i et kontekstvindu vil også regnes som forankring.

RAG vs. LLM: Eksempler fra virkeligheten

For bedre å forstå hvordan RAG fungerer sammenlignet med LLM-bruk uten RAG, kan vi se på et enkelt, reelt eksempel ved hjelp av Perplexity og et hypotetisk virksomhetstilfelle der en vektordatabase konsulteres.

RAG vs. LLM med en enkel prompt

Her er outputen (begrenset til to setninger) når Perplexity får spørsmålet «Bør jeg gå en tur i London i dag?» med KI-nettsøk (en form for RAG) slått av:

Ja – hvis været er rimelig tørt og du har tid, kan en spasertur i London i dag være et forfriskende avbrekk. Velg en rute langs South Bank, Regent’s Canal eller gjennom Hyde Park, og ta med en lett vanntett jakke i tilfelle.

Sammenlign dette med prompten når LLM-en kan sjekke eksterne kilder:

Ja, det er en fin dag for en spasertur i London: Værmeldingen sier milde temperaturer rundt 19–21 °C, solgløtt og bare svært liten sjanse for regn. Med delvis skyet himmel og en lett bris er forholdene behagelige for å utforske parker eller ruter langs elven, som South Bank.

Det finnes likheter mellom de to, siden LLM-en bruker den samme underliggende prosessen for tokenrangering. Men det andre eksemplet inkluderer detaljert værinformasjon, noe som gjør det langt mer nyttig.

RAG vs. LLM med en virksomhetsvektordatabase

Se for deg at en bruker stiller følgende spørsmål til en chatbot i en bankapp: «Hvor kan jeg laste ned den nyeste kontoutskriften min?»

Banken som administrerer appen har opprettet en database som inneholder innebygginger av den oppdaterte produktdokumentasjonen sin og koblet den til chatbotens RAG-pipeline. Dokumentasjonen består av rundt 1 000 kildedokumenter, som er delt inn i mindre tekstbiter og har blitt konvertert til vektorer for henting.

Brukerens forespørsel sendes til en innebyggingsmodell, og applikasjonen sender den vektoren til databasen, som returnerer de relevante tekstbitene.

Innebyggingsmodellen ville motta en forespørsel som denne:

Innebyggingsmodellen returnerer følgende vektorinnebygging:

Vektordatabasen mottar da en forespørsel som følgende:

I dette (sterkt forenklede) eksemplet returnerer databasen de fem tekstbitene som er mest relevante for brukerens forespørsel, og disse sendes til applikasjonen og inkluderes i LLM-prompten.

Når du bør velge RAG vs. en LLM, og når du bør kombinere dem

LLM-er og RAG er komplementære systemer. Dermed er spørsmålet «Når bør jeg velge en LLM, og når RAG?» feil formulert. Du bør heller spørre: «Når er en LLM tilstrekkelig, og når er RAG optimal?»

Når du skal bruke en LLM uten RAG aktivert

• Den valgte KI-modellen har et stort kontekstvindu: Hvis det er enklere å legge all informasjonen eller dataene som trengs for et korrekt svar inn i prompten, for eksempel ved å laste opp et dokument, kan det redusere forsinkelse og forhindre hente-relaterte problemer.
• Resonnerings- og dataanalysearbeidsflyter: Analyse- og resonneringsarbeidsflyter som bare refererer til dataene som er gitt i en prompt, trenger ikke RAG-funksjoner.
• Kodegenerering: RAG er vanligvis ikke nødvendig for generelt kodingsarbeid, selv om det som regel brukes til prosjektspecifikke oppgaver, som å hente tidligere feilrettinger eller leverandør-API-er og dokumentasjon.

Når du skal bruke en LLM med RAG aktivert

• Du trenger tilgang til oppdatert informasjon: Hvis en KI-applikasjon trenger å få tilgang til eksterne kilder med oppdatert informasjon for å generere et presist svar, må du alltid sørge for at RAG-funksjoner er aktivert.
• Du jobber i et spesialisert fagområde: For domener som medisin, jus, utdanning og så videre, der presisjon, detaljer og kildekontroll er viktig, vil bruk uten RAG ofte være utilstrekkelig.
• Utdata bør referere til interne bedriftsfiler: Hvis du bruker KI, enten internt eller i en kundevendt app, til å generere innhold basert på interne bedriftsdokumenter, enten det er data, en merkevarepakke, dokumentasjon eller filer, gir RAG tilgang til denne informasjonen.

RAG og LLM-er er komplementære, utviklende teknologier

RAG markerte en stor innovasjon i KIs utvikling. Den løser tre store problemer: utdatert informasjon, begrenset modellminne og informasjonsmangler på grunn av mangel på relevant treningsdata, noe som ofte resulterte i hallusinasjoner. LLM-er har naturligvis ikke overvunnet dette helt, men forekomsten har blitt betydelig redusert med fremveksten av RAG.

RAG er ikke en statisk teknologi. Den forventes å bli bedre på en rekke områder, blant annet rerankering, forsinkelse under henting og tokenbruk, sikkerhetsforsvar mot farlige datakilder, integrering av hentede data fra flere kilder og mer. Etter hvert som LLM-er og agentisk KI fortsetter å utvikle seg, vil også RAG-systemene som støtter dem gjøre det.