Embeddings og vektordatabaser: Derfor er de nøglen til præcis RAG (forklaret enkelt)

Når RAG virker virkelig godt, føles det næsten enkelt: Man stiller et spørgsmål, og systemet svarer præcist med relevant viden fra egne dokumenter. Når RAG virker dårligt, skyldes det ofte ikke selve sprogmodellen, men det der sker lige før svaret bliver skrevet.

Her kommer embeddings og vektordatabaser ind. De udgør den del af løsningen, som afgør, om modellen får de rigtige tekststykker serveret, eller om den må gætte sig frem.

Hvad embeddings betyder i en RAG-løsning

Et embedding er en måde at oversætte tekst til tal på. Ikke som simpel optælling af ord, men som en matematisk repræsentation af mening. Et ord, en sætning eller et dokument bliver gjort til en vektor, altså en lang række tal, der placerer teksten i et flerdimensionelt rum.

Pointen er stærk og meget praktisk: Tekster med beslægtet betydning placeres tæt på hinanden. To formuleringer kan derfor ligge nær hinanden, selv om de ikke bruger de samme ord. Det er netop det, der gør embeddings værdifulde i RAG.

Hvis en bruger spørger: “Hvordan reducerer man bias i AI-modeller?”, kan en god embedding-model også finde tekststykker om “fairness”, “skævhed i træningsdata” og “ansvarlig modeludvikling”, selv om ordet “bias” måske ikke står i dokumentet.

Det er her, klassisk nøgleordssøgning ofte kommer til kort.

Efter den første intuition giver det mening at se på, hvad embeddings faktisk hjælper med:

• Synonymer og variationer i sprog
• Forskellige formuleringer af samme spørgsmål
• Kontekst omkring tvetydige ord
• Match mellem spørgsmål og relevante afsnit, ikke kun titler

Der findes mange typer embedding-modeller. Tidlige modeller gav ét fast vektorudtryk pr. ord. Nyere modeller arbejder med kontekst, så betydningen af et ord afhænger af resten af sætningen. Det gør en stor forskel i praksis, fordi ord sjældent står alene. “Bank” kan være økonomi eller flodbred. En moderne model kan ofte skelne mellem de to betydninger ud fra sammenhængen.

Hvad en vektordatabase gør i praksis

Når tekst er omsat til embeddings, skal de gemmes et sted, hvor man kan søge hurtigt og præcist. Det er præcis formålet med en vektordatabase. Den lagrer vektorer og finder de nærmeste naboer til en ny forespørgsel.

En traditionel database er god til eksakte opslag. En søgemotor er stærk til nøgleord og filtre. En vektordatabase er bygget til lighedssøgning i højdimensionelle data. Det betyder, at den kan besvare spørgsmålet: “Hvilke tekststykker ligner mest denne forespørgsel i betydning?”

Det er en anden opgave end almindelig SQL.

For at gøre søgningen hurtig bruger vektordatabaser særlige indeksstrukturer. Ved små datamængder kan man sammenligne mod alle vektorer. Ved store datamængder bruger man ofte ANN-søgning, approximate nearest neighbors, hvor systemet finder de mest sandsynlige bedste match meget hurtigt. Metoder som HNSW er blevet populære, fordi de giver en stærk balance mellem hastighed og kvalitet.

Tabellen her viser forskellen mellem tre datatyper, som ofte blandes sammen:

I praksis arbejder mange moderne løsninger med en kombination. Metadata, adgangsregler og filtre ligger ofte side om side med selve vektorsøgningen. Det gør løsningen både præcis og styrbar.

Sådan arbejder embeddings, vektordatabase og RAG sammen

RAG står for Retrieval-Augmented Generation. Det betyder, at en sprogmodel ikke kun svarer ud fra sin træning, men også får hentet relevant ekstern viden ind i prompten, før svaret genereres.

Flowet er mere jordnært, end det lyder. Først opdeles dokumenter i mindre bidder, ofte kaldet chunks. Hver chunk bliver omdannet til et embedding og lagret i en vektordatabase sammen med metadata, kilde og id. Når brugeren stiller et spørgsmål, bliver spørgsmålet også embeddet. Derefter finder databasen de nærmeste tekststykker.

Til sidst sendes spørgsmålet og de fundne tekststykker videre til sprogmodellen, som skriver svaret med afsæt i den fundne kontekst.

En typisk RAG-proces ser sådan ud:

1. Dokumenter renses og opdeles i passende tekststykker
2. Hvert tekststykke omdannes til et embedding
3. Vektorer og metadata gemmes i en vektordatabase
4. Brugerens spørgsmål embeddes ved søgning
5. De mest relevante tekststykker hentes tilbage
6. Sprogmodellen svarer med udgangspunkt i de hentede kilder

Når denne kæde er stærk, stiger præcisionen markant. Når kæden er svag, opstår de klassiske problemer: irrelevante resultater, halvkorrekte svar og svar, der lyder overbevisende uden at være godt funderet.

Hvor præcisionen vindes eller tabes i RAG

Mange taler om valg af model, men i virkeligheden bliver meget af kvaliteten afgjort i dataarbejdet. Chunking er et godt eksempel. Hvis tekststykkerne er for korte, mister systemet kontekst. Hvis de er for lange, bliver søgeresultaterne ofte mudrede og mindre præcise.

Metadata er et andet område med stor effekt. Hvis hvert tekststykke også har oplysninger om emne, dato, sprog, dokumenttype eller fagområde, kan man filtrere søgeresultaterne, før de sendes til modellen. Det giver bedre svar og bedre styring.

Valget af embedding-model betyder også meget, især på dansk og nordiske sprog. En model, der er stærk på engelsk generelt, er ikke nødvendigvis det bedste valg til danske kursustekster, HR-politikker, juridiske vejledninger eller tekniske manualer. Sprog og domæne sætter tydelige spor i kvaliteten.

Her er nogle af de vigtigste designvalg i en RAG-løsning:

• Chunk-størrelse: påvirker balancen mellem kontekst og præcision
• Embedding-model: afgør hvor godt mening og fagtermer bliver fanget
• Afstandsmetrik: styrer hvordan lighed måles mellem vektorer
• Metadata-filtre: begrænser søgning til relevant indhold
• Re-ranking: sorterer topresultaterne endnu skarpere før generering

En moden løsning bruger ofte mere end ren vektorsøgning. Hybrid søgning kombinerer semantiske embeddings med klassiske nøgleord. Det er særligt nyttigt, når bestemte termer, produktnavne, lovhenvisninger eller kursuskoder skal matches præcist.

Embeddings og vektordatabaser i danske og nordiske data

For danske og nordiske organisationer er sproget ikke en detalje. Det er et kvalitetskriterium. Mange datasæt er blandede med dansk, svensk, norsk og engelsk. Det stiller krav til embedding-modellen, hvis den skal tolke mening på tværs af sprog og fagområder.

Det gælder også for praksisnære læringsmiljøer, hvor dokumenter kan spænde fra kursusbeskrivelser og undervisningsmaterialer til FAQ, policy-tekster og cases. Her bliver fordelen ved embeddings tydelig, fordi spørgsmål sjældent stilles med samme ordvalg som de tekster, svarene findes i.

En bruger kan spørge til “ansvarlig brug af generativ AI i HR”, mens indholdet ligger under overskrifter om “compliance”, “personaleudvikling”, “automatiseret screening” og “intern governance”. God semantisk søgning binder det sammen.

Det åbner for flere værdifulde anvendelser:

• Intern vidensøgning
• AI-assistenter til kursusindhold
• Support på tværs af dokumentarkiver
• Anbefaling af relevante læringsforløb

Typiske misforståelser om embeddings og vektordatabaser

En almindelig misforståelse er, at en vektordatabase i sig selv gør RAG intelligent. Det gør den ikke. Den gør RAG hurtig og i stand til at søge på mening, men kvaliteten afhænger stadig af datagrundlag, chunking, modelvalg og evaluering.

En anden misforståelse er, at flere dokumenter automatisk giver bedre svar. Hvis store mængder svagt struktureret indhold hældes direkte ind i en pipeline, får man ofte mere støj end værdi. RAG belønner kurateret indhold og klare kilder.

Og nej, embeddings fjerner ikke behovet for styring.

Det er også værd at holde fast i, at embeddings ikke er særlig forklarlige for mennesker. Man kan måle afstande og relevans, men man kan ikke bare kigge på en vektor og se, hvorfor et dokument blev valgt. Derfor er det klogt at kombinere vektorsøgning med gennemsigtige metadata, logning og evaluering af resultater.

Praktisk set bør man være opmærksom på følgende faldgruber:

• Svag chunking
• Uegnede sprogmodeller
• Manglende metadata
• Ingen evaluering af søgeresultater
• For stor tillid til første version

Sådan kommer man godt fra start med embeddings og RAG

Et stærkt udgangspunkt er at starte mindre, end man tror. Vælg ét klart domæne, ét dokumentarkiv og én tydelig brugssituation. Det kan være en intern chatbot til kursusmateriale, en FAQ-assistent eller semantisk søgning i vejledninger.

Første mål bør ikke være at bygge alt. Første mål bør være at måle kvalitet.

Det giver mening at definere et sæt realistiske spørgsmål, som systemet skal kunne besvare. Når de spørgsmål testes igen og igen gennem udviklingen, bliver det hurtigt tydeligt, om forbedringer faktisk virker. Den disciplin adskiller lovende prototyper fra driftssikre løsninger.

En god startplan kan se sådan ud:

1. Vælg et afgrænset indholdsområde
2. Rens data og lav meningsfulde chunks
3. Test en nordisk eller flersproglig embedding-model
4. Gem tekst, metadata og embeddings i en vektordatabase
5. Mål retrieval-kvalitet før der fokuseres på det genererede svar

Når retrieval-delen fungerer stabilt, bliver resten langt lettere. Sprogmodellen får bedre materiale at arbejde med, hallucinationer reduceres, og brugeroplevelsen løfter sig mærkbart. Det er grunden til, at embeddings og vektordatabaser ikke bare er tekniske detaljer, men selve fundamentet under præcis RAG.

For organisationer, der vil arbejde seriøst med AI i praksis, er det en stærk erkendelse. Den bedste RAG-løsning starter ikke med det flotteste svar, men med den mest præcise genfinding.