POC’erne så nemme ud: vektordatabase, embeddings, lidt promptlim. Så kom produktion og agenter – og skramlerne fulgte med. Nye tal fra VB Pulse for Q1 2026 peger på, at virksomheder gør det fornuftige: de bygger retrieval om. Ikke flere lag for lagets skyld. Fundamentet først.
Bevægelsen er markant: intentionen om at adoptere hybrid retrieval er gået fra 10,3 procent til 33,3 procent på et kvartal. Samtidig falder budgetintentionen til klassisk “relevans-test”, mens optimering af retrieval rykker frem. Og vektor‑DB‑feltet? Flere kendte navne taber adoptionsandel, mens provider‑native retrieval og custom stacks tager imod trafikken. Det ser vi også i vores projekter i Danmark – de samme driftssmerter, de samme valg.
Hvad VB Pulse faktisk fandt
VB Pulse kørte tre månedlige målinger i januar, februar og marts blandt virksomheder med 100+ ansatte. Hver bølge havde 45–58 kvalificerede respondenter. Det er et smalt panel, og data skal ifølge VentureBeat behandles som “directional”, altså retningsgivende – ikke endelig sandhed. Alligevel er signalet konsistent på tværs af månederne.
Ud over hybrid‑springet viser målingerne, at 22 procent af de kvalificerede respondenter rapporterer ingen produktionelle RAG‑systemer. Evaluering og relevans‑test som budgetfokus falder fra 32,8 procent i januar til 15,6 procent i marts. I samme periode vokser retrieval‑optimering fra 19,0 til 28,9 procent. Ifølge VB Pulse mister standalone vektor‑databaser som Weaviate, Milvus, Pinecone og Qdrant andel, mens custom stacks og provider‑native retrieval tager imod andelen. Der er huller i rapporteringen her: vi får ikke at vide, om det primært er små eller store kunder, der flytter sig, og absolut brug er ikke dokumenteret.

Hvad betyder hybrid retrieval i praksis
Hybrid retrieval kombinerer tre greb:
- Dense embeddings for semantisk nærhed
- Sparse søgning (keywords, BM25) for præcise match og “must have‑termer”
- Reranking, der genvurderer kandidaterne i kontekstDet øger kompleksitet og ofte latenstid en smule. Til gengæld stiger recall og styrbarhed – især hvor adgangsstyring og sikkerhed er i spil. For mange enterprise‑teams er det den pragmatiske vej for agentiske workloads: mindre pynt, mere robusthed.
Hvorfor det skete nu
Mange RAG‑opsætninger blev født som dokument‑søgning med semantisk tvist. Det rækker til FAQ‑bots og wiki‑opsummeringer. Når agenter derimod skal handle, krydse systemer og respektere autorisationer, vælter det: relevansen bliver ustabil, adgangsstyring ender som krykker, og driften spredes over for mange komponenter.
Steven Dickens, vice president hos HyperFRAME Research, formulerede det i marts i forbindelse med Oracles agentiske data‑stack: “Data teams are exhausted by fragmentation fatigue. Managing a separate vector store, graph database and relational system just to power one agent is a DevOps nightmare.” Vi genkender billedet: Jira‑boards med syv forskellige “indexer services” og dobbelt ingestion for samme kilde – særtilfælde, der kunne være løst med bedre basisstruktur.

Danske erfaringer fra maskinrummet
Vi har været med i flere retrieval‑rebuilds de seneste seks måneder. Den kedelige del virker bedst. Når metadata bliver normaliseret. Når duplikater fjernes. Når chunking binder afsnit til deres overskrifter i stedet for at skære midt i en sætning. I et projekt stod vi i et printerrum og gennemgik PDF‑konverteringer med bogmærker fra 2014. Efter en uges oprydning steg hit‑raten synligt, og behovet for endnu et lag reranking blev udskudt.
I et andet dansk forløb fjernede vi antageligvis 18 procent dubletter fra et kontrakt‑arkiv og ryddede op i tre modstridende “department”-felter. Den øvelse halverede antallet af irrelevante top‑3‑træf. Og ved at maskere gamle PII‑felter i bilag forsvandt en hel kategori af sikkerhedsalarmer. Det er ikke teori – det er drift.

Konsekvenser for platformvalg
VB Pulse peger på to vindere: provider‑native retrieval og custom stacks. Den første giver fart, lav integrationsfriktion og ofte pæn compliance‑historik. Den anden giver kontrol, mulighed for at tune pipeline‑leddene og bedre multicloud‑forhandling. Taberne er ikke nødvendigvis dårlige produkter; det ligner snarere en bevægelse fra “for mange komponenter” mod “færre, men bedre forbundet”.
Tradeoffs, vi ofte ser:
- Kontrol vs. kompleksitet: Custom giver knobs – hver knap kræver opsyn
- Omkostning vs. latenstid: Provider‑native kan være billig pr. forespørgsel, men dyr ved volumen; self‑hosted kan betale sig ved rigtig lastprofil, men kræver SRE‑timer
- Compliance og dataresidency: Nogle vælger provider‑native for at lande ISO‑pakker og datalokalitet hurtigt; andre går custom for end‑to‑end‑audit
Sådan omprioriterer teams nu
Flere går fra “model shopping” og løsrevne relevansmålinger til retrieval‑SLO’er og testdata, der ligner virkeligheden – ikke kun syntetiske spørgsmål, men de drilske sager fra helpdesk og juristerne.
Forslag til et retrieval‑rebuild i en dansk virksomhed på 500–1000 ansatte:
- Uge 1–3 Audit og cleanup: Kildeliste, ingestion‑kort, deduplikering, metadata‑normalisering, canonicalization, chunking‑regler, maskering af PII og adgangsmærker
- Uge 4–6 Lille hybrid‑pilot: Sparse + dense + rerank i ét kritisk flow (kundesupport, kontraktopslag) med SLO’er for recall og latenstid
- Uge 7–12 Skalering og observability: Automatisk regressionssuite, permission‑leak‑tests, cost‑per‑query‑overvågning, alerting og driftshandoverRoller der skal med: data engineers, MLOps, sikkerhed, produktansvarlige – og en driftsansvarlig, der må sige nej. Uden et nej ender I tilbage i fragmentering.
Metrikker der betyder noget
Når vi måler på retrieval, bruger vi typisk:
- nDCG og recall@k på et sæt realistiske forespørgsler
- Rerank‑latenstid og total p95‑latenstid
- Cost per query og cache‑hit‑rate
- Permission‑leakage‑tests på tværs af roller og datasiloerI agentiske workloads bør recall og adgangskontrol komme før marginale præcisionsgevinster. Vi har set for mange hændelser, hvor en agent gjorde “det rigtige” på et forkert dokument. Det er værre end intet svar.

Hvorfor ikke bare købe et nyt lag
Fristelsen er at lægge endnu et rerank‑ eller reasoning‑lag ovenpå. Det kan hjælpe. Uden datahygiejne bliver det et plaster. I to danske cases var gevinsten fra metadata‑rens + chunking‑justering større end fra en dyr reranker. Og driftsteamet fik færre alarmer. Vi så færre incidents efter at have konsolideret fra tre datalagre til to i en kundes stack. Mindre sync‑ballade, færre natlige pagerduty‑vågninger. Det er en observation – ikke en universel sandhed – men den peger på, hvor støjen ofte kommer fra.
Risici og begrænsninger i tallene
VB Pulse arbejder med 45–58 respondenter pr. måned. Det er lille. Det er globalt og muligvis US‑skævt. VentureBeat skriver selv, at resultaterne er retningsgivende. Der mangler segmentering på branche og region, og vi ved ikke, om faldet for vektor‑DB’er primært kommer fra små eller store kunder. Der findes stadig få uafhængige benchmarks, der kvantificerer gevinster fra “index hygiene” i agentiske miljøer. Vores cases er illustrative – ikke ekstern dokumentation.

Alligevel flugter tendensen med det, vi ser i drift: flere pauser RAG‑udrulninger for at få retrieval på skinner. En mindre gruppe træder helt et skridt tilbage fra RAG. Den pæne modenhedskurve holder ikke – virkeligheden gør.
EMEA‑presset og hvorfor økonomi styrer timingen
IDC peger på, at kun 9 procent af organisationer i EMEA har leveret kvantificerbare forretningsresultater fra de fleste AI‑projekter de seneste to år. Interessen fejler ikke noget; eksekvering og bestyrelsers krav om finansiel validering trykker bremsen. IDC anbefaler CIO‑audits for at få projekter videre. Den virkelighed mærker vi i Norden. Når retrieval‑leddet fejler, fejler ROI.
Netop et retrieval‑rebuild giver typisk hurtige, målbare gevinster – ikke fordi det er smart, men fordi lavthængende frugter i kildekvalitet og indeksering stadig hænger der.
Hvad man bør gøre først
Start her, før I går hybrid i hele huset:
- Inventarliste over kilder, skemaer, titles, beskrivelser og adgangsmærker
- Rens metadata, dedupliker, og peg en canonical kilde pr. dokumenttype
- Fastlæg chunking‑regler, der binder overskrifter og afsnit sammen, og gør citater referérbare
- Byg et realistisk eval‑sæt og sæt recall‑SLO’er per flow
- Først derefter: læg sparse + dense + rerank på i et afgrænset flowVores tekniske leads korte, ærlige to‑ugers plan fra et nyligt rebuild: Dag 1–2 kortlægning af kilder og ingestion‑veje, dag 3–5 metadata‑normalisering og dublet‑jagt, dag 6–7 chunking‑tests og citat‑anker, dag 8 maskering af PII og permission‑mærker, dag 9–10 baseline‑målinger med nDCG\/recall@k og p95‑latenstid. Banalt på papiret – i praksis forsvinder halvdelen af de mærkelige fejl her.
Hvornår giver provider‑native mening
Oftere end purister bryder sig om. Hvis latency‑krav, compliance eller driftsmodenhed peger mod én cloud, og jeres data allerede bor der, er provider‑native retrieval et fint valg – især hvis I kan leve med færre knobs. Vi har ikke set nogen fortryde færre komponenter, når teamet er lille. Omvendt: har I tværgående databehov, flere clouds og stærk SRE‑kapacitet, kan custom give de kontroller, I mangler.
Et par jordnære faldgruber
Tre ting overses ofte – og bider hårdt:
- Adgangsstyring på retrieval‑laget: Hvis sparse‑delen ser mere end dense‑delen, opstår læk i kanterne
- Eval‑sæt, der er for pæne: Brug support‑tickets – ikke kun syntetiske spørgsmål
- Driftsomkostninger: Reranking kan æde latency‑budgettet. Mål p95 – ikke bare gennemsnitI ét projekt var vi i tvivl, om hybrid gav nok gevinst til mer‑latenstiden. Svaret blev “ja” – men først efter at vi strammede cache og slog to ingestion‑jobs sammen, der ellers dobbelt‑indekserede lovsamlinger. Små ting, stor effekt.
Hvad vi ikke ved endnu
Langtidsprofilen for hybrid i produktion er underbelyst: omkostninger over 12 måneder, når datamængden fordobles; vedligehold ved hyppige embedding‑opdateringer; fejlprofiler i komplekse agentsystemer. Kilderne rækker ikke dertil endnu.
Hold derfor rebuilds stramt afgrænsede, mål hårdt, og lov ikke for meget på forhånd. RAG behøver ikke være alt eller intet – start i ét forretningskritisk flow.
Konklusion
Markedet vender sig mod fundamentet. VB Pulse viser en tredobling i hybrid‑intention, et fald i eval‑budgetter og en bevægelse væk fra nogle standalone vektor‑DB’er. Samtidig melder hver femte ingen produktionel RAG. Det er ikke et nederlag for teknikken – men et tegn på, at arkitekturen fra 2025 ikke bar agentisk skala.
Vores to‑punkts plan, kort og kontant: 1) Audit og cleanup af data og indeks. 2) Pilottest hybrid i ét kritisk flow med klare SLO’er – og først derefter brede ud. I et nyligt dansk projekt gjorde vi netop det på et kontraktflow. Der var støv på arkivskabene og en labelprinter, der peb i baggrunden. Efter tre uger var fejlene halveret, sagsbehandlerne stoppede med at sende screenshots af “tomme svar”, og driften fik deres aftener tilbage. Forskellen mærkes først, når man sidder med den i hænderne.