Vektordatabaser er rykket fra legetøj til livsnerve. MarkTechPost skriver det ligeud, og vi er enige efter at have stået med for mange natlige alarmer i produktion. I 2026 er de blevet den centrale genfindingsmotor i RAG, semantisk søgning og agent‑workflows, og et forkert valg sætter sig direkte i latenstid, driftsomkostninger og kvaliteten af svarene. Det er nyheden og hovedpointen. Og ja, det føles som en modenhedstest for hele AI‑feltet.
Hvorfor betyder det noget i Danmark nu? Fordi mange har flyttet fra demoer til rigtige brugere. Og så gør 300 millisekunders forskel ondt. Vi ser, at standardvalg fra 2024 ikke holder, når datamængderne fordobles og embeddings skifter dimension med nye modeller. Strukturelt er skiftet sket, som MarkTechPost beskriver, fordi LLM’er er gledet ind i enterprise‑software som standardfunktion. Når alt bliver promptet, bliver alt også hentet et sted fra. Det sted er vektordatabasen.
Ni systemer på tavlen og hvorfor rammen er brugbar
MarkTechPost’ gennemgang fra 10. maj dækker ni førende systemer og fokuserer på pris, skala og arkitektur‑tradeoffs. Vi har ikke brug for en rangliste her. Rammen er vigtigere. Hvilke arkitektvalg driver hukommelsesforbrug. Hvad sker der, når indekset ikke passer til dit opdateringsmønster. Og hvor rammer prisen først. Guidens konklusion er klar nok til at stå på egne ben, uden vendor‑slides, og peger på, at “hvilken database” ikke længere er et akademisk spørgsmål men et driftsspor.
Vi tager rammen og oversætter til dansk virkelighed. Ikke fordi vi vil være klogere end kilden, men fordi de små forskydninger i krav betyder alt, når man sidder med en kundevendt assistent der hakker. Den erkendelse kommer ofte efter første release. Lidt for sent.
Hvad vi har set i danske projekter
Case et. En større servicevirksomhed kørte managed hosting med RAM‑tunge indekser. Fint i test. I drift voksede embeddings til trecifrede millioner. Regningen voksede også. Vi flyttede dem til en hybrid opsætning og reducerede RAM‑forbruget markant. Besparelsen landede på 30–50 procent over flere måneder, målt på faktisk drift. Men hver gang embeddings‑dimensionen skiftede, krævede genindeksering et døgns nedetid i retrieval‑laget. Det var prisen. Den var ikke synlig i offerter, men meget synlig i vagtskemaet.
Case to. En anden kunde klarede sig glimrende i en offentlig benchmark. Flotte tal. I deres egne søgninger faldt recall cirka 20 procent, fordi domænesproget skubbede embedding‑fordelingen. Vi skulle have testet på virkelige queries fra start. Den fejl laver vi ikke igen. Og ja, jeg ærgrede mig. For det kunne måles med en simpel eval‑pipeline på egne data.
De tekniske tradeoffs der faktisk bider
Hukommelse mod præcision. RAM‑intensive grafindekser som HNSW leverer lav latenstid og høj recall ved høj QPS, men kræver meget hukommelse og varme datasæt. Disk‑orienterede strategier reducerer RAM‑tryk på bekostning af koldstart og i nogle tilfælde lidt lavere recall. Vælg efter adgangsmønster, ikke brochure. Hvis dine queries “hænger sammen” tidsmæssigt, kan cache‑effekter redde dagen. Hvis alt er spredt, skal du regne koldt på p99.
HNSW mod IVF og PQ. HNSW bygger en navigerbar graf og er ofte førstevalg ved lav latenstid. IVF bruger en coarse quantizer til at pege mod få “centers”, hvorefter søgningen snævres ind. PQ komprimerer vektorer i mindre kodebøger for at spare plads. PQ sænker hukommelse og lagring betydeligt men kan koste præcision, især hvis koden er for grov. Kombinerer du IVF og PQ, kan du få meget lav lagerpris pr. embedding men må betale i enten recall eller ekstra rerank‑trin med LLM. Intet er gratis.
Opdateringer, konsistens og hvor vinduet lukker
Upserts lyder trivielt. Det er de ikke. Nogle indekser accepterer hyppige inkrementelle opdateringer fint, andre kræver batch‑jobs for at holde grafen sund. Hvis dit domæne ændrer sig time for time, er batch‑genindeksering en tidsbombe. Vi prioriterer i praksis arkitekturer, der kan absorbere upserts uden at krakelere i 99.9‑percentilen. Konsistensmodellen betyder også noget. Eventual consistency kan være fint for vidensbaser, men skidt for compliance‑tunge processer hvor “sidste version” ikke må flimre i minutter.
Shards og replikering. Sharding kan give lineær skala på papiret, men tværshard‑forespørgsler koster netværkstid og samling af resultater. Replikering giver resilience og læseskala, men dobler også nogle omkostningskurver. Det er her leverandører typisk oversælger. “Lineær skalerbarhed” kræver at din query‑distribution, indeksparametre og netværk opfører sig eksemplarisk. Det gør de sjældent.
Pris og skala uden varm luft
Hvor løber pengene hen. Først lagring af embeddings. Som tommelfingerregel fylder en 1536‑dimensionel float32‑vektor cirka 6 KB, før metadata og indeks. Indeks og metadata kan fordoble eller tredoble tallet, afhængigt af metode. Dernæst RAM til indekser, især HNSW. Så indekseringsjobs ved bulk‑indtag, hvor compute og IO kan give spidser. Og netværkstrafik hvis jeres forespørgsler flyver mellem regioner eller mellem applikation og database.
TCO kræver en enkel men ærlig model. Regn med antal dokumenter, gennemsnitlige tokens pr. dokument, embedding‑dimension, forventet QPS og p95/p99‑mål. Læg pris på lagring, RAM, CPU/GPU til indeksering, egress, backup, replikering og evt. multi‑region. Glem ikke migrationsomkostninger når dimensioner ændres eller når I skifter indeks‑familie. Der ligger ofte en uforudset post her, som ikke står i prislisten.
Sådan evaluerer du på egne data
Start med et datasæt fra virkelige spørgsmål og svar, ikke syntetiske. Definér ground truth for mindst 200–500 queries, så recall@k og precision@k faktisk siger noget. Mål både gennemsnit og hale. En p99 på 1.2 sekunder kan være katastrofal, selvom gennemsnittet er 120 ms. Brug lasttests med to til tre belastningsniveauer, men mål procentiler konsistent over flere timer.
Byg en cost‑simulator. Estimér embeddings‑størrelse, indeks‑overhead og opdateringsfrekvens. Kør to scenarier for upserts og for batch‑rebuilds. Prissæt begge. Til sidst en migrations‑sjekliste. Kan du køre to retrieval‑lag parallelt i en periode. Har du fallback til en ældre embeddings‑version. Find ud af det før du står med en varm hotline.
Skjulte omkostninger og operationsfælder
Hosting‑overraskelser rammer ofte i managed miljøer, hvor “RAM” lyder som en enkelt måleenhed men dækker indeksdata, caches og runtime sammen. Budgetter går i rødt når indekser vokser hurtigere end forventet. Versionering er næste fælde. Nye embedding‑modeller ændrer dimension eller distribution, og pludselig passer det gamle indeks ikke længere. Uden versionering i pipelinen bliver rollback til en manøvre med svedige håndflader.
Overvågning og SLO’er. Vi ser stadig teams der kun kigger på gennemsnit. Læg alarmer på p95, p99 og p99.9 samt recall‑drift over tid. Og sikkerhed. VentureBeat beskrev for nylig eksponeringer i såkaldt shadow‑AI. Det er ikke vektordatabasens skyld i sig selv, men det er din opgave at sikre datalokation, kryptering i hvile og i transit, og adgangskontrol ned på indeksniveau. Embeddings kan være følsomme, også selv om de er talrækker.
Når det går galt i virkeligheden
Scenarie et. Kundevendt assistent svarer langsomt efter inkrementelle opdateringer. Årsag. Indekset tåler ikke hyppige upserts og degraderer. Løsning. Skift til en opdateringsvenlig struktur eller indfør micro‑batches med kompaktering i baggrunden. Midlertidigt. Begræns opdateringsraten eller øg replikering på læseknuder for at tage toppen af halen.
Scenarie to. Relevansen dykker efter en modelopdatering. Årsag. PQ‑parametre er for aggressive, eller embedding‑distributionen er ændret. Løsning. Retune PQ, øg antal probes i IVF, eller tilføj en billig rerank med mindre kontekstvindue. Og mål. Du opdager det ellers først, når supporten skriver “den svarer ved siden af igen”.
Hvor leverandører og konkurrenter oversælger eller undersælger
Lineær skala er en påstand, ikke en garanti. Spørg efter percentil‑latenser ved jeres forventede QPS og dokumentstørrelser. Black‑box latensgarantier uden workload‑definition er ikke noget løfte. Managed services lover ofte nul drift, men gemmer kompleksitet i pris og kontrol. Selvhosting lover frihed, men undervurderer operatørbyrden. Sandheden ligger derimellem. Vi har det bedst med klare SLO’er og synlige knapper, ikke mirakler.
Verificér påstande. Både MarkTechPost og vi efterlyser uafhængige benchmarks. Vendor‑grafer er fine til start, men bed om testdata eller reproducérbare scripts. Og vær stædig med sikkerhedsdetaljer. Datalokation, kryptering, RBAC, audit‑logs. Det er sjældent øverst i brochuren, men øverst i jeres risikolog.
Fra PoC til produktion uden ballade
Start med en 4‑ugers bane. Uge 1. Afgræns use case, mål, datasæt og SLO’er. Uge 2. Stand up to kandidater med ens konfiguration og kør recall og latenstest. Uge 3. Cost‑modellér opdateringer og skaler op til realistisk QPS. Uge 4. Træf valg, planlæg migration og definer rollback. Involver data‑platform, sikkerhed, applikation og drift fra dag ét. Det lyder banalt, men her taber projekter fart, hvis folk kobles på for sent.
Migrationsvinduet skal være reelt. Hvis en skiftende dimension kræver fuld genindeksering, så reserver et døgn og byg en midlertidig routing, der kan nedprioritere smalle features. Eller tag chancen og sæt en weekend af. Vi har prøvet begge. Den første gør mindre ondt. Den anden ender oftere i pizza og dårlige jokes søndag aften.
Operativ tjekliste du kan bruge i morgen
- Mål p50, p95, p99 og p99.9 for både søgning og skrivning. Log dem separat.
- Hold recall@k‑mål pr. use case og alarmer på driftsfald over fx 5 procent.
- Indfør versionsstyring for embeddings og skema før produktion. To samtidige versioner mindst.
- Planlæg backup og disaster recovery med realistiske RTO/RPO. Test en gendannelse, ikke bare dokumentér den.
- Forhandl SLA med cost‑caps eller autoscaling‑grænser. Ingen vil se en egress‑regning komme ud af det blå.
- Fastlæg datalokation og kryptering i hvile og i transit. Dokumentér RBAC og audit‑flows.
Hvad vi stadig ikke ved nok om
MarkTechPost nævner ni systemer, men vi mangler den fulde navneliste og sammenlignelige, uafhængige benchmarktal i det materiale vi har gennemgået. Vi mangler også opdaterede TCO‑eksempler ved fx 100 millioner embeddings i 1536 dimensioner, helst med både RAM‑tunge og disk‑orienterede indekser. Leverandørernes skala‑garantier bør suppleres med percentil‑latenser på standard workloads med klare parametre. Det er ikke tilgængeligt her.
Opdateringsmønstre er underbelyst. Hvad koster hyppige upserts reelt i hvert system, og hvordan ser kompakteringstider ud. Derudover vil vi gerne se bedre dokumentation for sikkerhed og compliance på tværs af leverandører. Datalokation, kryptering og RBAC bør stå tydeligere, og helst testet af tredjepart. Sidst men ikke mindst. Roadmaps for enterprise‑funktioner som multi‑region og konsistensgrader er sjældent konkrete.
Hvorfor det her ender i drift, ikke i slides
Det, der overraskede os mest i 2025–26, var hvor ofte problemerne ikke sad i modellen, men i retrieval‑laget. Latenstid i halen. Relevansdrift efter en ellers harmløs opdatering. Eller bare prisen der langsomt gled op. Når vi kigger tilbage på de projekter, der fløj, var fællesnævneren en jordnær eval‑plan på egne data og en vilje til at justere indeks og pipeline, selv når det kostede en weekend. Man opdager først forskellen, når man sidder med det i hænderne.
Bilag og kort teknisk note
HNSW er et grafbaseret indeks, hvor hver vektor forbindes i lagdelte grafer. Søgning hopper gennem grafen mod nære naboer, hvilket giver lav latenstid og høj recall når indekset passer i RAM. IVF opdeler rummet i klynger via en coarse quantizer, så søgning kun sker i et lille udsnit af klynger. Det reducerer arbejde per forespørgsel, men kræver tuning af hvor mange klynger der undersøges. PQ komprimerer hver vektor i delrum med små kodebøger, så lagring og RAM‑forbrug falder kraftigt, men afstanden bliver approksimeret.
I praksis betyder det her. HNSW er ofte hurtigst og mest præcis ved høj RAM‑budget og stabile datasæt. IVF passer når du kan acceptere lidt mindre præcision for stor skala og lavere latency pr. omkostningsenhed. PQ giver stærk pladsbesparelse, især i kombination med IVF, men du skal typisk tilføje reranking for at genvinde præcision. Vi går ikke ned i alle parametre her. Det er bedre at teste tre velvalgte konfigurationer grundigt end ti overfladisk.
