Spørg en almindelig database, om kunden "må have sin hund med", og den finder ingenting, med mindre nogen tidligere har skrevet præcis de ord ned et sted. Spørg en AI-chatbot det samme, og den svarer korrekt, selv hvis virksomhedens hjemmeside kun nævner en "kæledyrspolitik". Forskellen ligger ikke i modellen, der genererer svaret. Den ligger i det lag, der finder den rigtige information, før modellen overhovedet kommer i spil: en vektordatabase.
Det er ikke en detalje. Det er fundamentet, enhver AI-løsning, der skal svare præcist på baggrund af en virksomheds egne data, hviler på.
Hvad en vektordatabase egentlig er
En vektordatabase gemmer ikke tekst, som en almindelig database gør. Den gemmer tekstens betydning, oversat til et langt tal-array, en vektor. Det sker ved hjælp af en embedding-model, der læser et stykke tekst og placerer det et bestemt sted i et flerdimensionelt rum, hvor tekst med lignende betydning ender tæt på hinanden, uanset hvilke ord der faktisk blev brugt.
"Må jeg have min hund med?" og "Hvad er jeres kæledyrspolitik?" bruger ingen af de samme ord. Men de betyder stort set det samme, og derfor lander de tæt på hinanden i det rum. Det er præcis den egenskab, der gør semantisk søgning muligt: man søger på mening, ikke på bogstaver.
Når en bruger stiller et spørgsmål, bliver spørgsmålet selv omdannet til en vektor på samme måde. Databasen finder derefter de vektorer i sin samling, der ligger tættest på, det man i praksis kalder nearest neighbor search, og returnerer det indhold, de vektorer repræsenterer. Det er de par millisekunder, hele oplevelsen står og falder på.
Hvorfor en almindelig database ikke kan det samme
En relationel database er fremragende til at slå noget op, når man kender det præcise navn, id eller nøgleord på forhånd. Den er bygget til eksakte match og strukturerede felter.
Problemet er, at rigtige mennesker ikke spørger med de ord, der faktisk står i dokumentationen. En kunde skriver "kan jeg få pengene tilbage", ikke "returpolitik, paragraf 3". En medarbejder søger "hvordan sletter jeg en bruger", ikke den præcise sidetitel i det interne wiki. Nøgleordssøgning kræver, at spørgeren allerede kender svarets sprog. Semantisk søgning kræver kun, at spørgeren kender sin egen hensigt.
Det er derfor, man ikke kan bygge en AI-assistent, der reelt forstår en virksomheds indhold, oven på en almindelig database alene. Man kan tilføje fritekstsøgning og fuzzy matching, men man lapper stadig på et system, der grundlæggende leder efter bogstaver, ikke betydning.
Sådan bruges det i praksis: RAG
Den mest almindelige måde, en vektordatabase bliver brugt i en AI-løsning, er som en del af et RAG-setup, retrieval-augmented generation. Ideen er enkel: i stedet for at bede en sprogmodel om at "vide" alt om en virksomhed på forhånd, giver man den den rigtige kontekst, lige når den skal bruge den.
I korte træk sker der fire ting: virksomhedens indhold bliver delt op i mindre stykker og omdannet til vektorer (ingest og embedding), et spørgsmål bliver matchet mod de vektorer for at finde de mest relevante stykker (retrieval), de bedste resultater bliver sorteret efter relevans (rerank), og til sidst bliver de sendt til en sprogmodel sammen med selve spørgsmålet, så modellen kan formulere et svar baseret på virksomhedens faktiske indhold i stedet for at gætte.
Vektordatabasen er det lag, der gør retrieval-delen mulig. Uden den er der intet at give modellen at arbejde med, og man er tilbage til en model, der svarer ud fra generel viden, ikke jeres data.
Sat op visuelt ser flowet sådan ud:
flowchart TD
A[Virksomhedens indhold] -->|Ingest og embedding| D[(Vektordatabase)]
E[Brugerens spørgsmål] -->|Embedding| F[Spørgsmåls-vektor]
F -->|Finder nærmeste match| D
D --> G[Mest relevante stykker]
G --> H[Rerank efter relevans]
H --> I[Sprogmodel]
E --> I
I --> J[Svar til brugeren]Den del, der faktisk tager tid
Det, der ser simpelt ud på papiret, bliver hurtigt komplekst i produktion. Hvor mange vektorer kan systemet håndtere, før søgningen bliver langsom? Hvordan holder man data fra forskellige kunder eller projekter isoleret fra hinanden? Hvad sker der med prisen, når datamængden går fra tusind til ti millioner stykker indhold? Og hvordan opdaterer man indekset løbende, uden at søgningen går ned, mens det sker?
Ingen af de spørgsmål er interessante for den, der bare vil have et hurtigt og korrekt svar. Men de er præcis det, de fleste teams ender med at bruge mest tid på, når de bygger deres første AI-produkt: ikke selve produktet, men infrastrukturen under det.
Hvor det bliver brugt
I praksis dukker vektordatabaser op, hver gang en AI-løsning skal kende noget specifikt, som modellen ikke selv har lært under træning: en AI-chatbot, der skal svare ud fra en virksomheds egen hjemmeside eller dokumentation. En intern søgemaskine, der finder den rigtige sag i tusindvis af tidligere sagsbehandlinger. Et supportværktøj, der finder det rigtige svar i en produktmanual på et øjeblik. Fælles for dem alle er, at svaret findes et sted i virksomhedens eget indhold, det handler bare om at finde det rigtige sted, hurtigt.
Vi har for nylig set et konkret eksempel på det i praksis hos en af vores kunder, hvor det bliver brugt til at gøre en hel virksomheds hjemmeside til en søgbar AI-chat, automatisk og uden manuel opsætning.
Det behøver ikke være jeres problem at løse
At bygge og drifte den infrastruktur selv betyder typisk tre beslutninger på samme tid: hvilken vektordatabase, hvordan den skal driftes, og hvordan den skal skaleres, når data eller trafik vokser. Det er præcis det lag, vi hos Liviate har bygget en managed løsning til: en hostet vektordatabase, klar til produktion fra dag ét, i flere niveauer efter behov, fra en gratis mulighed til at komme i gang, til dedikeret infrastruktur for dem, der har brug for mere isolation eller kapacitet.
Vil I vide, om det er relevant for jer? Skriv til os, og lad os tage en snak om, hvor I kunne starte.