Snilld

Fra vektorstore til knowledge engine — hvorfor agenter kræver mere end RAG

Pinecone lancerer Nexus og KnowQL, mens VentureBeats Pulse-data viser et hop i hybrid retrieval-intent til 33,3 procent og fald for rene vektordatabaser. Signalværdien er klar: RAG, som vi kender det, rammer loftet for agentiske systemer. Det får praktiske konsekvenser for arkitektur, drift og revision i virksomheder.

5. maj 2026 Peter Munkholm

Lad os være ærlige. RAG var en genial genvej, så længe en person sad for enden af tråden og kunne oversætte svarene. Nu presser agentiske workflows sig på, og tallene peger samme vej som mavefornemmelsen længe har gjort. VentureBeats Pulse-data for Q1 2026 viser, at hybrid retrieval-intent er tredoblet til 33,3 procent, mens stand‑alone vektordatabaser taber fodfæste. Samtidig lancerer Pinecone Nexus og KnowQL og kalder det ikke en smartere søgning, men et egentligt knowledge‑lag for agenter. Det ligner ikke et produktstunt, men en arkitekturændring.

Vores påstand er enkel: RAG‑æraen var skrevet til mennesker, ikke til agenter. Agenter har brug for vedvarende, opgave‑specifik viden, sessionel state og deterministiske spor. Ikke endnu et sæt dokumenter ved inferenstid. Det skifter ikke bare værktøjer. Det ændrer, hvordan teams designer systemer, måler omkostninger og fører tilsyn.

Hvor vi står

RAG kører én forespørgsel, ét svar. En person i loopet kan tolke, rette og spørge igen. Agenter arbejder anderledes. De får opgaver, ikke spørgsmål. De skal samle kontekst fra flere kilder, holde styr på, hvad de allerede har set, løse konflikter mellem kilder og planlægge næste skridt uden at spørge brugeren hver gang. VentureBeat opsummerer nøgternt, at RAG‑til‑vektordatabase‑pipelines ikke dækker agentiske behov længere.

Det lyder teoretisk, men vi har set det i praksis. I en POC hos en industrikunde brugte agenten over 70 procent af compute på at genfinde og genfortolke de samme få kilder i hver session. Det matcher Pinecones egen vurdering af, at op mod 85 procent ryger på re‑discovery. Vores tal svinger med domænet, men mønsteret er det samme: latens stiger, tokenforbrug løber løbsk, og reproducerbarheden skrider.

Nærbillede af kanten på et kompileret knowledge-artifact med farvede faner og et lille metal-token ved siden af, fokus på tekstur, ingen læsbar tekst.

Hvad Pinecone skubber ud

Nexus iscenesættes som en knowledge engine. Ikke en hurtigere retriever. Kernen er en context compiler, der omsætter rå virksomhedsdata til vedvarende, opgave‑specifikke knowledge artifacts før agenten spørger. Og en komponerbar retriever, der serverer artefakter med felt‑citeringer og deterministisk konfliktløsning. Sammen med det kommer KnowQL, en deklarativ forespørgselssyntaks, hvor agenter kan angive output‑form, krav til sikkerhed (confidence) og latensbudgetter.

Hvis det holder, adresserer det tre hårde problemer: 1) Re‑discovery flyttes fra inferenstid til en kompileringsfase med genbrug, 2) sporbarhed via felt‑citater gør revision realistisk, og 3) deterministisk konfliktløsning gør svar mere konsistente fra kørsel til kørsel. Pinecone åbner Nexus i early access nu, men meget af det kræver feltprøver, ikke slides.

Benchmarks med forbehold

Pinecone peger i et internt benchmark på, at en finansanalyse gik fra 2,8 millioner tokens til cirka 4.000. 98 procent reduktion. Det er voldsomt. Men det er ikke valideret i kunders produktion. Vi anerkender logikken – flytning af arbejde fra inferenstid til kompilation giver færre tokens – men datasæt, prompt‑stil, encoder‑valg og metrikvalg kan flytte kurverne markant.

Banner

Vores erfaring: I to kundecases med semantiske snapshots og sessionel hukommelse så vi stabil reduktion i tokens pr. opgave og mere ensartet latens, men prisen var mere kompleks drift og længere release‑cyklus, fordi artefakter skulle versionsstyres. Potentiale ja. Gratis nej.

Markedet drejer

Pulse‑målingen fra VentureBeat er mere end støj. Intent til hybrid retrieval er nu 33,3 procent, og det er den hurtigst voksende strategi i datasættet. Samtidig rapporteres fald i adoption for hver enkeltstående vektordatabase. Man kan diskutere stikprøvens størrelse og definitionen af hybrid, men retningen er konsistent med, hvad arkitekter efterspørger: kombinationer af semantisk søgning, symbolske regler, metadatafiltre og ofte en kompileret mellemrepræsentation.

Med andre ord: markedet leder efter et videnslag, ikke bare en lagerhylde af embeddings. Vi hører det i udbud, i spørgsmål om citater på feltniveau og i ønsket om determinisme i revisionstunge miljøer.

Opdelt billede: til venstre rod med løse udskrifter og post-its, til højre ordnede artefakt‑patroner på hylde; kontrast mellem gammel RAG-rod og kompileret knowledge-lag.

Hvad det ændrer i arkitekturen

Første konsekvens er memory. Ikke kun en lang kontekstbuffer, men hybrid memory med kort‑ og langtid, hvor semantiske snapshots kan genbruges på tværs af sessioner. Det reducerer re‑discovery og gør latens forudsigelig. Men man skal have styr på invalidation og versionsstyring – ellers bliver “memory” bare gammelt rod.

Anden konsekvens er stateful metadata. Når artefakter bærer information om kilde, gyldighed, anvendelsesdomæne og tillidsniveau, kan orkestratoren træffe mere deterministiske valg. Det hjælper agenter, der skal skifte gear mellem læsning, planlægning og handling. (Simple regler som “brug kun artefakter fra ledger‑kilder til finansielle summeringer” eliminerer hele klasser af fejl.)

Drift og compliance bliver lettere – og sværere

Persistent artifacts med felt‑citater lyder som revisionens drøm. Man kan endelig besvare spørgsmålet: Hvilket felt skabte den her konklusion, og hvad skete der, hvis to kilder var uenige. Deterministisk konfliktløsning gør det muligt at gentage en opgave og få samme svar – eller i det mindste en log over, hvorfor svaret afveg.

Men SRE‑virkeligheden ændrer sig. Der opstår nye KPI’er: artefakt‑freshness, compile‑latens, fejl i compiler‑pipelines, andel af svar der kræver fallback til rå retrieval, og reproducerbarhed på tværs af versioner. Ops‑teamet får en ny rollback‑mekanisme: rulle snapshots tilbage. Vi har måttet lave uventede vagtordninger omkring snapshot‑publicering, fordi et fejlet compile‑run ændrede adfærd i hele agent‑flowet, uden at nogen havde rørt prompten.

Implementeringsvalg og tradeoffs

Der er ikke én rigtig vej. Kompilering koster tid og penge. Mere determinisme kan koste friskhed. En tung compiler kan æde det latensbudget, man lige vandt. Vores råd er at træffe fire bevidste valg: 1) Hvor går grænsen mellem compiled artifacts og on‑the‑fly retrieval, 2) hvor ofte re‑kompileres hvilke domæner, 3) hvad tæller som autoritativ kilde, og 4) hvor meget konfliktløsning lægges i regler kontra i modellen.

Prisstrukturer skifter også. Man flytter forbrug fra tokens ved inferens til lagring, kompileringscompute og metadatahåndtering. Nogle vil spare netto, andre ikke. Det afhænger af opgavernes gentagelsesgrad. En finansopsummering, der rammer de samme 12 tabeller hver mandag, vinder stort. En ad‑hoc udforskning? Måske mindre.

Opdelt billede: til venstre rod med løse udskrifter og post-its, til højre ordnede artefakt‑patroner på hylde; kontrast mellem gammel RAG-rod og kompileret knowledge-lag.

Sikkerhed og validitet

Når man kompilerer viden, kan man også kompilere fejl. En dårlig mapning af source‑of‑truth kan lægge et pænt deterministisk slør over en forkert sandhed. Forældede snapshots er en anden klassiker. Og konfliktløsning kan blive for hård og filtrere legitime outliers væk, som egentlig burde råbe alarm.

Banner

Derfor skal pipelines have evalueringspunkter. Ikke bare model‑eval, men compile‑eval: semantisk diff af artefakter mellem versioner, referencechecks mod autoritative kilder og testopgaver, der sikrer reproducerbarhed før udrulning. Guardrails bør inkludere datakilder, tidshorisonter og en gråzone for “ukendt” i stedet for hallucineret sikkerhed.

Andre bevægelser i samme retning

Amazon SageMaker beskriver agent‑guidede workflows til at strømline modeltilpasning – fra brugssagsbeskrivelse til eval og deployment – hvor pre‑byggede agent‑skills producerer genbrugelige artefakter. Det er ikke det samme som Nexus, men retningen er fælles: mere deklarativ styring, flere artefakter, mindre improviseret inferens.

Pointen er ikke, at alle bygger det samme, men at bevægelsen peger mod orkestrerede, artefakt‑tunge pipelines. Agenter guides, snarere end at gætte sig gennem et dokumentbjerg hver gang.

Så hvad gør vi nu

Det er tid til at teste – rigtigt. Ikke skifte alt i produktion i morgen. Start med en opgave, der gentages ofte, har klare autoritative kilder, og hvor revision betyder noget. Mål fire ting: tokenforbrug pr. trin, latens pr. agent‑trin, reproducerbarhed (samme input, samme artefakt, samme svar), og andel af svar med fulde felt‑citater.

Vi har haft held med at bygge små compile‑pipelines ved siden af eksisterende RAG. Det lyder kedeligt, men tvilling‑kørsler med A/B‑målinger afslører hurtigt, om artefakterne bærer deres egen vægt. Og ja, I vil opdage, at kildekatalogisering er det hårdeste stykke arbejde. Vi har brugt timer på at blive enige om, hvad der var sandt om rabatlogik i én ERP‑installation. Lugten af kaffe i møderummet hænger stadig i næsen.

Konsekvenser for leverandører

Vector‑leverandører kan ikke nøjes med at være hurtige nøgler til embeddings. Markedet forventer videnlag: context compilers, felt‑citater, deterministiske beslutninger og en slags deklarativ kontrolflade til agenter. Forretningsmodellerne rykker fra query‑volumen til artefakt‑livscyklus – compile, opbevaring, invalidering, audit.

Det åbner for nye bundter: “compliance‑tier” med streng determinisme og “exploration‑tier” med mere friskhed. Og ja, vendor lock‑in spøger. Et KnowQL‑agtigt lag kan blive limen, der gør det svært at flytte. Kræv eksportbarhed og klare SLO’er for compile‑pipelines.

Huller vi stadig ser

Vi mangler tredjepartsvalidering af Pinecones 98 procent‑tal i produktion. Vi mangler skalerbarhedstal på tværs af meget store datasæt – milliarder af rækker – under agent‑workflows. Og vi savner detaljer om, hvordan kompilerings‑freshness styres uden at sprænge latensbudgetter ved hyppige re‑kompileringer.

Pulse‑datas “hybrid retrieval” kunne også bruge en teknisk definition, så vi ved, om vi taler om symbolsk+semantisk, multi‑indeks, knowledge‑artefakter oven på vektor – eller alt ovenstående. Det påvirker arkitekturvalg.

Vores vurdering

RAG er ikke dødt. Det er bare ikke nok alene for agentiske flows, der skal kunne revidere sig selv og gentage et resultat uden at allokere hele lønposen til tokens. Nexus og KnowQL peger i en rigtig retning. Vi sælger det ikke som mirakelkur. Brug det som værktøj i opgaver, hvor genbrug af kontekst giver mening og hvor determinisme er en fordel.

Start småt, mål hårdt, og lad compiled knowledge vinde sin plads. Forskellen bliver tydelig, når man sidder med det i hænderne – og når revisionen spørger, hvorfor svaret var som det var, tirsdag klokken 14.08.

Billeder og data

  • VentureBeat‑Pulse tidsserie, der viser hybrid retrieval‑intent gå til 33,3 procent og fald for stand‑alone vektordatabaser.
  • Arkitekturdiagram for compiled knowledge‑lag med context compiler, artifact store, composable retriever og KnowQL‑grænse.
  • Token‑reduktion scenarie: fra 2,8 mio. tokens til cirka 4.000 med markering af, hvor arbejdet flyttes fra inferenstid til kompilation.

Kilder

  • VentureBeat: The RAG era is ending for agentic AI — a new compilation‑stage knowledge layer is what comes next. Primær kilde til Pulse‑tal, Nexus/KnowQL‑detaljer og citater.
  • Snillds interne erfaringer: anonymiserede POC‑observationer om re‑discovery‑andel, snapshot‑drift og kildekatalogisering.
  • Amazon SageMaker AI‑blog: Agent‑guided workflows to accelerate model customization. Understøtter tendensen mod agent‑styrede artefakter og orkestrering.

    Gør brugeroplevelsen bedre.
    Hvilket firma arbejder du for?