Enhver AI-assistent, der skal svare præcist på baggrund af en virksomheds egne data, hviler på det samme fundament: en vektordatabase, der kan finde det rigtige stykke indhold, hurtigt, uanset hvor meget data der ligger bag.
Det lyder som en detalje. I praksis er det ofte det, der tager længst tid at få rigtigt: skalering, indeksering, isolation mellem kunder, og en pris, der ikke løber løbsk, når datamængden vokser. De fleste teams ender med at bruge mere tid på den del end på selve produktet.
Hvad problemet egentlig er
Bygger man selv sin vektorsøgning, sidder man typisk med tre valg på samme tid: hvilken database, hvordan den skal driftes, og hvordan den skal skaleres, når data eller trafik vokser. Ingen af de valg er interessante for kunden, der bare vil have et hurtigt og korrekt svar.
Det er præcis det lag, vi har bygget en managed løsning til: en hostet vektordatabase, klar til produktion fra dag ét.
Sådan ser det ud i praksis: ScrapeGoat
Et konkret eksempel er ScrapeGoat, et værktøj der bygger AI-chatbots ud fra virksomheders egne hjemmesider. Man peger værktøjet på en hjemmeside, og det bliver til en chat, der kan svare på det, siden faktisk indeholder.
Det stiller et helt konkret krav: når en besøgende stiller et spørgsmål, skal chatten finde det rigtige afsnit på hjemmesiden, ud af måske tusindvis af sider, på et øjeblik. En almindelig database er god til at slå noget op, hvor man kender det præcise navn eller de rigtige nøgleord på forhånd. Men gæsten spørger sjældent med de samme ord, som står på siden ("må jeg have min hund med" i stedet for "kæledyrspolitik"). Derfor kræver det en vektordatabase, der finder det rigtige indhold ud fra betydning, ikke bogstaver.
Trin 1: Hjemmesiden bliver til søgbare data
Når en ny kundes hjemmeside tilføjes, bliver hver side læst, delt op og lagret som vektorer i vores managed vektordatabase. Det sker automatisk, uden at nogen manuelt skal sætte en database op eller planlægge kapacitet på forhånd.
Det eneste, kunden selv skal gøre, er at indsætte et lille JavaScript-snippet på deres hjemmeside. Herfra kører resten af sig selv: indholdet bliver løbende scannet, delt op og lagt ind i databasen, og chatten opdateres automatisk, når siden ændrer sig, uden noget manuelt setup, ingen separat integration og ingen ventetid på et udviklerteam.
Fra hjemmeside til søgbar viden, automatisk og løbende opdateret.
Trin 2: Et spørgsmål bliver til et svar
En besøgende skriver et spørgsmål i chatten. Spørgsmålet bliver selv lavet om til en vektor, matchet mod det rigtige indhold i databasen, og rangeret, så det mest relevante svar kommer først.
Trin 3: Det vokser uden at gå i stå
Efterhånden som ScrapeGoat får flere kunder og flere sider bliver indekseret, vokser antallet af vektorer markant. Fordi det er bygget på en managed vektordatabase, kræver det ikke, at nogen manuelt skalerer databasen op, den er bygget til at vokse med.
Flere kunder og flere indekserede sider betyder flere vektorer. Databasen skalerer med, uden at nogen skal skrue op manuelt.
Resultatet
ScrapeGoat kan bruge sin tid på at gøre selve chatoplevelsen bedre, i stedet for at drifte og skalere en database ved siden af. Vektorsøgningen er hurtig og stabil, uanset om det er ti eller ti tusind sider, der ligger bag.
Hvad man vælger imellem
Løsningen findes i flere niveauer, fra en gratis mulighed til at komme i gang, over en delt løsning til tidlige workloads, til dedikeret infrastruktur i forskellige størrelser for dem, der har brug for mere isolation eller kapacitet. Man starter typisk småt og flytter op i takt med, at behovet vokser, uden at skulle skifte database undervejs.
Kun ét stykke af et større puslespil
Vores managed vektordatabase er en selvstændig ydelse, man kan tilkøbe alene. Men den passer også naturligt ind i en større pipeline: fra ingest, over embedding og retrieval, til rerank, samlet som en RAG-pakke, hvor selve database-laget håndteres af den samme løsning.
Selve generering af svar (inferensen) holder vi bevidst uden for pakken. I vælger selv, hvilken model der skal generere svaret, og betaler for det separat og efter forbrug, så man ikke låses til én bestemt model, bare fordi man har valgt vores database eller RAG-lag.
På gensyn i næste del, hvor vi dykker ned i selve RAG-workflowet: ingest, embedding, retrieval og rerank, og hvordan det hele spiller sammen i praksis. Delen efter det handler om MCP-servere.
Er det relevant for jer?
Bygger I noget, der læner sig op ad semantisk søgning eller RAG, og bruger I mere tid på infrastrukturen end på selve produktet?
Det er langt fra det eneste sted, vi kan hjælpe. Ud over vores managed vektordatabase og RAG-pakken rådgiver vi også om, hvordan I sammensætter jeres AI-arkitektur fra bunden: hvilke modeller der giver mening til hvilke opgaver, hvordan data skal struktureres og sikres undervejs, og hvordan det hele driftes i praksis. Selve inferensen, altså den del der genererer svarene, kan vi også stå for som en selvstændig, forbrugsbaseret ydelse, hvor I frit vælger model.
Skriv til os, og lad os tage en snak om, hvor I kunne starte.