RAG vs. LLM: Teknisk gennemgang (definitioner, forskelle, brugsscenarier)

LLM'er genererer svar ved hjælp af parametre, der er lært ud fra mønstre i træningsdataene. Fordi disse parametre muligvis ikke afspejler nylig eller fuldstændig information, supplerer RAG, som står for retrieval-augmented generation, processen ved at tilføje data fra eksterne kilder til LLM'ens inputkontekst. Et AI-værktøj henter ekstern information for at augmentere LLM'ens genereringsproces.

I virkeligheden er valget ikke mellem RAG eller en LLM. Det er mellem en hybridtilgang og en, der kun bruger en LLM.

RAG er nødvendig, når en LLM har brug for adgang til virksomhedsdokumentation, databaser eller hurtigt skiftende information. En LLM-only-tilgang er velegnet til visse administrative, databehandlings- og indholdsoprettelsesopgaver, hvor alle input kan leveres af brugeren.

RAG vs. LLM: Hvad er de vigtigste forskelle?

• RAG og LLM'er er komplementære systemer. Du kan bruge en AI-model uden RAG (hvor den udelukkende bygger på sine eksisterende parametre), men du kan ikke bruge et RAG-system uden en model.
• RAG blev introduceret for at overvinde tre centrale problemer med LLM'er: forældet information, hallucinerede svar og manglende verifikation over for tredjepartskilder.
• RAG gør AI meget mere effektiv i virkelige forretningssituationer, fordi den forbinder LLM'er med verificeret intern dokumentation, databaser og API-endpoints.
• De vigtigste RAG-brugsscenarier omfatter kundesupportchatbots, forespørgsler baseret på hurtigt skiftende data (som branchenyheder) og specialiserede områder som medicin og jura, hvor nøjagtighed og faktatjek af kilder er vigtigt.
• Der er tre hovedtyper af RAG: naiv RAG, modulær RAG og avanceret RAG. Naiv RAG forstås bedst som ligetil informationssøgning, mens modulær og avanceret RAG tilføjer ekstra funktionalitet som forespørgselsomskrivning og chunk-optimering.

Hvad er en stor sprogmodel (LLM)?

En LLM, eller stor sprogmodel, er et system, der genererer indhold ved hjælp af finjusterede parametre. Disse parametre bestemmer sandsynlighederne, der tildeles alle tokens i en LLM-vokabular, og angiver, hvilket token der med størst sandsynlighed kommer som det næste i en given sekvens.

For bedre at forstå, hvordan RAG fungerer (og adskiller sig fra) LLM'er, er det nyttigt at se på, hvordan generativ AI fungerer på et grundlæggende niveau:

1. Tokenisering: En brugers prompt deles op i tokens, som kan være ord, dele af ord eller enkelte tegn.
2. Indlejring: Tokens konverteres til embeddings, numeriske repræsentationer (talstrenge) kaldet vektorer, som det neurale netværk, der omfatter en decoder, kan behandle.
3. Dekodning: Lagene i decoder'en (som udgør en stor del af LLM'ens neurale netværk) manipulerer disse vektorer ved hjælp af en proces kaldet attention til at indfange betydning. Denne proces afgør, hvor stærkt hvert token skal relateres til andre tokens i sekvensen.
4. Scoring: Modellen tildeler hver token i sit eksisterende ordforråd en kompatibilitetssandsynlighed og vælger en sandsynlig næste token til sekvensen.

Det vigtige er, at en LLM kun kan producere output baseret på sine eksisterende parametre og tokens i sit kontekstvindue. Under træningen bliver en LLM bedt om at fuldføre dele af ufuldstændig tekst milliarder af gange, og dens parametre justeres, indtil den pålideligt tildeler tokens sandsynligheder (og dermed fuldfører teksten).

Forestil dig for eksempel, at du stiller en AI-model spørgsmålet: “What does our company’s 2026 refund policy say?” LLM'en kan kun forudsige de næste tokens baseret på sine eksisterende parametre, som ikke er finjusteret ved hjælp af din supportdokumentation. Hvis du stiller den dette spørgsmål uden yderligere kontekst, vil den simpelthen ikke være i stand til at svare meningsfuldt eller vil hallucinere et forkert svar.

Hvad er retrieval-augmented generation (RAG)?

RAG (retrieval-augmented generation) er den proces, hvorved information fra eksterne systemer inkluderes i en LLM-prompt.

Den underliggende LLM-proces, som involverer indlejring og probabilistisk tokenmatchning, forbliver den samme. RAG introducerer et indledende trin, hvor brugerens prompt udvides med yderligere data.

Her er en oversigt over, hvordan RAG fungerer:

1. Vidensforberedelse: En videnskilde forberedes. Det kan være et sæt dokumenter, en vektordatabase, en knowledge graph eller et live index (f.eks. til AI-søgning).
2. Promptering: En bruger indtaster en prompt, såsom: “Should I go for a walk in London today?”
3. Hentning: Den eksterne informationskilde forespørges af AI-værktøjets retriever. Den kan indlejre prompten, omdanne den til en vektor og derefter forespørge en vektordatabase. Alternativt kan den bruge en anden metode, såsom et API-kald, søgeordsmatchning eller traversal af en knowledge graph.
4. Indsættelse: Disse oplysninger føjes til brugerens oprindelige prompt. I eksemplet med spørgsmålet om at gå en tur i London kan dette omfatte vejrinformation i London og den aktuelle tilgængelighed af populære gå-ruter.
5. Svargenerering: LLM'en genererer et svar på sædvanlig vis ved hjælp af den udvidede prompt.

Bag kulisserne tilføjes den hentede tekst til inputkonteksten, tokeniseres og indlejres. Modellen behandler derefter denne ekstra kontekst gennem sin decoder, hvilket ændrer sandsynlighederne for outputtokens.

Overordnet set kan RAG opdeles i tre undertyper. Naiv RAG følger den grundlæggende RAG-proces, hvor information hentes og føres ind i prompten. Avanceret RAG tilføjer ekstra funktioner som forespørgselsomskrivning og flere forespørgselsgennemløb. Modulær RAG refererer til en type arkitektur, hvor forskellige avancerede funktioner kan behandles som komponenter og kombineres efter behov.

RAG vs. LLM: Oversigt over brugsscenarier

RAG giver brugerne adgang til opdaterede data. Det resulterer i LLM-output, der har mindre risiko for hallucinationer og informationshuller. Hvis du har brug for at se kilderne til den information, der bruges i et output, er RAG også afgørende, da uunderbyggede LLM-svar ikke kommer med kildehenvisninger.

Udvid

RAG-brugsscenarier

• Forespørgsler om tidsfølsomme oplysninger: Enhver forespørgsel efter information, der hurtigt bliver forældet, hvilket kan være noget så enkelt som en vejrudsigt eller så komplekst som en detaljeret analyse af en nyhedshistorie under udvikling, skal baseres på validerede tredjepartskilder.
• Virksomhedsdokumentation: Interne eller kundevendte AI-chatbots, hvor brugerne stiller spørgsmål relateret til virksomhedens eller produktets dokumentation, bør have RAG aktiveret, især hvis dokumentationen ofte opdateres.
• Kundesupport: Kundechatbots har brug for adgang til aktuel, detaljeret supportdokumentation for at kunne give præcise svar.
• Specialiserede områder (medicin, jura, finans osv.): LLM'er, der ikke er trænet på domænespecifikke korpora (især mainstream-modeller), har typisk svært ved nuancerne i specialiserede prompts.

LLM-brugsscenarier

• Administrative opgaver: LLM'er kan udføre grundlæggende opgaver med minimal latenstid. RAG er unødvendig til grundlæggende skrive- og adminopgaver, såsom stavekontrol eller opsummering, hvor ekstern information ikke er påkrævet.
• Kreative opgaver: Nogle kreative opgaver, som at generere en kort historie eller et billede, kræver kun de oplysninger, der gives i den oprindelige prompt.
• Ræsonnerings- og databaserede opgaver: Hvis du arbejder med et stort datasæt, har en LLM ikke brug for adgang til ekstern information for at anvende ræsonnerings- og analysefunktioner.
• Generel kodning: Selv om en kodningsarbejdsproces kan kræve adgang til en privat kodebase eller dokumentation, er LLM'er meget dygtige til at udføre generelle kodningsopgaver, som at rette fejl og oprette funktioner, uden hjælp fra eksterne kilder.

RAG vs. LLM med lang kontekst, agentisk AI og grounding

Der er tre relaterede begreber, som er relevante for forskellen mellem RAG og LLM'er. Disse er LLM'er med lang kontekst, agentisk AI og grounding.

LLM'er med lang kontekst kan nogle gange bruges i stedet for RAG-aktiverede systemer, mens agentisk AI og grounding er synonyme med dem eller arbejder sammen med dem.

LLM'er med lang kontekst

Det er modeller med store kontekstvinduer, hvor nogle bredt tilgængelige kommercielle modeller understøtter op til en million tokens.

Hvis relevant materiale kan være i en models kontekstvindue og er tilgængeligt i et tekstformat, er der nogle fordele ved at bruge en LLM-only-tilgang. Det kan reducere risikoen for hentningsfejl, give mere omfattende kontekst og eliminere behovet for omfattende opsætning af RAG-arkitektur.

Agentisk AI

En agent er et system, der trækker på flere værktøjer, herunder RAG-funktioner, for at udføre komplekse opgaver. RAG er én komponent i agentisk AI, og en agent vil ofte bruge forskellige typer hentningsmetoder (f.eks. websøgning vs. vektorsøgning) afhængigt af indholdet i en prompt.

Grounding

Grounding henviser til den bredere proces med at bruge evidens eller data til at forbedre nøjagtigheden af en LLM's svar. RAG er én form for grounding, men at tilføje et teknisk dokument til et kontekstvindue ville også tælle som grounding.

RAG vs. LLM: Eksempler fra den virkelige verden

For bedre at forstå, hvordan RAG fungerer sammenlignet med LLM-brug uden RAG, kan vi se på et enkelt eksempel fra den virkelige verden med Perplexity og et hypotetisk virksomhedsscenarie, hvor der forespørges i en vektordatabase.

RAG vs. LLM med en simpel prompt

Her er outputtet (begrænset til to sætninger), når Perplexity bliver spurgt: "Should I go for a walk in London today?” med AI-websøgning (en form for RAG) slået fra:

Ja—hvis vejret er rimeligt tørt, og du har tiden, kan en gåtur i London i dag være et forfriskende skift i omgivelserne. Vælg en rute langs South Bank, Regent’s Canal eller gennem Hyde Park, og tag en let vandtæt jakke med for en sikkerheds skyld.

Sammenlign dette med prompten, når LLM'en kan tjekke eksterne kilder:

Ja, det er en god dag til en gåtur i London: prognosen siger milde temperaturer omkring 19–21°C med solskin indimellem og kun meget lav risiko for regn. Med delvist skyet himmel og en let brise er forholdene behagelige til at udforske parker eller ruter langs floden som South Bank.

Der er ligheder mellem de to, da LLM'en bruger den samme underliggende token-scoringsproces. Den anden example indeholder dog detaljerede vejrinformationer, hvilket gør den langt mere nyttig.

RAG vs. LLM med en enterprise-vektordatabase

Forestil dig, at en bruger stiller følgende spørgsmål til en chatbot i en banking-app: “Where can I download my most recent statement?”

Banken, der administrerer appen, har oprettet en database, der indeholder embeddings af dens opdaterede produktoplysninger, og har forbundet den til chatbotens RAG-pipeline. Dokumentationen består af omkring 1.000 kildedokumenter, som er opdelt i mindre chunks og er blevet konverteret til vektorer til hentning.

Brugerens forespørgsel sendes til en embeddingsmodel, og applikationen sender den vektor til databasen, som returnerer de relevante chunks.

Embeddingsmodellen ville modtage en forespørgsel som denne:

Embeddingsmodellen returnerer følgende vektorindlejring:

Vektordatabasen modtager derefter en forespørgsel som den følgende:

I dette (meget forenklede) eksempel returnerer databasen de fem chunks, der er mest relevante for brugerens forespørgsel, og de sendes til applikationen og inkluderes i LLM-prompten.

Hvornår man skal vælge RAG vs. en LLM, og hvornår man skal kombinere

LLM'er og RAG er komplementære systemer. Derfor er spørgsmålet: “Hvornår skal jeg vælge en LLM, og hvornår RAG?” forkert stillet. I stedet bør du spørge: “Hvornår er en LLM tilstrækkelig, og hvornår er RAG optimal?”

Hvornår man skal bruge en LLM uden RAG aktiveret

• Din valgte AI-model har et stort kontekstvindue: Hvis det er lettere at inkludere alle oplysninger eller data, der er nødvendige for et præcist svar, i din prompt, f.eks. ved at uploade et dokument, kan det reducere latenstid og forebygge hentningsrelaterede problemer.
• Ræsonnerings- og dataanalysearbejdsprocesser: Analyse- og ræsonneringsarbejdsprocesser, der kun refererer til de data, der er angivet i en prompt, har ikke brug for RAG-funktioner.
• Kodegenerering: RAG er typisk ikke nødvendig til generelt kodningsarbejde, selvom det normalt bruges til projektspecifikke opgaver, såsom at hente tidligere rettelser eller leverandør-API'er og dokumentation.

Hvornår man skal bruge en LLM med RAG aktiveret

• Du har brug for adgang til opdaterede oplysninger: Hvis en AI-applikation har brug for adgang til eksterne kilder med opdaterede oplysninger for at generere et præcist svar, skal du altid sikre, at RAG-funktionaliteten er aktiveret.
• Du arbejder inden for et specialiseret område: For domæner som medicin, jura, uddannelse og så videre, hvor nøjagtighed, detaljer og kildecheck er vigtigt, vil LLM-only-brug ofte være utilstrækkelig.
• Output bør henvise til interne virksomheds-filer: Hvis du bruger AI, enten internt eller i en kundevendt app, til at generere indhold baseret på interne virksomheds-dokumenter, uanset om det er data, et brand kit, dokumentation eller filer, giver RAG adgang til den information.

RAG og LLM'er er komplementære, udviklende teknologier

RAG markerede en stor innovation i AI's udvikling. Det adresserer tre store problemer: forældet information, begrænset modelhukommelse og informationshuller som følge af mangel på relevant træningsdata, hvilket ofte resulterede i hallucinationer. LLM'er har naturligvis ikke overvundet disse fuldstændigt, men deres forekomst er reduceret betydeligt med fremkomsten af RAG.

RAG er ikke en statisk teknologi. Det forventes at blive forbedret på en række områder, herunder reranking, latenstid under hentning og tokenforbrug, sikkerhedsbeskyttelse mod farlige datakilder, integration af hentede data fra flere kilder og mere. I takt med at LLM'er og agentisk AI fortsætter med at udvikle sig, vil de RAG-systemer, der understøtter dem, også gøre det.