Lad os være ærlige. Vektor‑RAG har båret os langt, og det er stadig den hurtigste vej, når nogen siger “kan vi ikke bare lægge dokumenterne ind”. Men den flade top‑k søgning knækker for tit i komplekse enterprise‑spørgsmål. Som VentureBeat skriver, er RAG blevet de facto standard til at grounde LLM’er i private data, men relationer går tabt i processen, og så begynder problemerne i produktion.
Nyheden er praktisk: referencearkitekturen i VentureBeat lægger en grafdatabase ind mellem ingestion og retrieval, så relationer ikke forsvinder i embedding‑trinnet. Konsekvensen for produktionsteams er klar. Pipelines skal udtrække entiteter og kanter ved ingestion, storage går fra kun vektor‑DB til også en graf, og retrieval bliver hybrid med både vektor‑scan og traversal. Det kræver nye tests, mere overvågning og lidt tålmodighed. Og ja, det betaler sig, når data er tæt vævet.
Hvorfor standard‑RAG halter i struktur‑tunge domæner
Den gængse RAG‑opsætning er veldokumenteret hos VentureBeat: chunk dokumenter, embed, læg i en vektor‑database, og hent top‑k via cosine‑similaritet. Det virker fint til semantisk søgning i ustruktureret tekst, især ved ét hop til “nærmeste svar”. Problemet er, at embedding‑rummet flader struktur ud – hierarki, ejerskab og afhængigheder bliver svagere signaler end ren semantik (samme kilde samt vores interne brief).
I enterprise‑domæner bærer relationerne sandheden. Supply chain, finansiel compliance og svindelopsporing er netværk, ikke monologer. Når top‑k returnerer gode men isolerede bidder, mangler modellen ledetråden mellem dem. Fejlene viser sig som hallucinationer eller “ved ikke” – selv om data i princippet ligger derinde et sted (VentureBeat + vores brief).
Hvad går galt i praksis
Spørg til en forsinkelse i et underkomponent: påvirker det leverancen til Kunde Y i Q3? VentureBeat bruger netop den type multi‑hop supply‑chain eksempel. Standard RAG kan finde noten om forsinkelsen og måske også kontrakten, men ikke forbindelsen imellem dem. Multi‑hop er akilleshælen, og vores erfaring matcher – selv med rerankere og metadata. Embeddings fanger lighed; den eksplicitte topologi forsvinder ofte.
Vi havde en POC i en logistikkredit‑kontekst hos en nordisk virksomhed. Datasættet var afgrænset til realistiske forretningsspørgsmål med kontrakter, bilag og leverandørrelationer, og der var en stram SLA på svartid i sekunder. Top‑k scorede højt i simple FAQ‑tests. Men når spørgsmålet krævede et hop via leverandørforhold og et hop mere via fakturaer, styrtdykkede præcisionen. Vi fik pæne sætninger tilbage – bare ikke de rigtige. Det er en kvalitativ observation med den nævnte kontekst, ikke en kvantitativ måling.
Referencearkitekturen for graf‑forstærket RAG
VentureBeat beskriver et tre‑lags mønster, der lukker hullet mellem semantik og struktur. Først ingestion: udtræk entiteter og relationer, og link dem til eksisterende poster. Brug NER, LLM‑baserede ekstraktører eller regler – domænet bestemmer værktøjet. Pointen er at lægge struktur på ved indløb, ikke at gætte den bagefter.
Næste lag er storage: en grafdatabase som Neo4j eller JanusGraph holder noder og kanter, mens vektor‑embeddings gemmes som egenskaber på relevante noder (fx et RiskEvent). Så kan tekststykker og strukturerede systemer leve i én model. Man kører stadig en vektor‑DB til hurtig semantisk adgang, men grafen holder topologien intakt.
Retrieval bliver hybrid: først et vektor‑scan for at finde indgangsnoder semantisk. Derefter traversal i grafen for at samle konteksten langs relationer, der betyder noget for svaret. Output til LLM’en er ikke bare brødkrummer fra top‑k, men en lille beviskæde, der binder delene sammen. Alt det er i tråd med VentureBeats referencearkitektur.
Hvad ændrer sig for ingeniørerne
Arbejdet flytter opstrøms. Intelligent chunking betyder at klippe ved naturlige grænser og lægge ID’er og ankre ind, så linking bliver stabil. Entitetslinking ved ingestion er en disciplin for sig: normalisering af navne, fuzzy matching og disambiguering mod masterdata. Vi har lært, at en lille, klar regelkanon og et auditspor sparer mange timer senere.
Opdateringsmønstret deles typisk i batch og streaming. Batch til reindeksering, schema‑ændringer og historiske data. Streaming til nye risikohændelser, bilag, tickets. Konsistens er et bevidst valg: stærk konsistens i kritiske relationer (ejerskab, roller) og eventual consistency i svagere kanter (relaterede nyheder). Det lyder tungt. Det gør blot det implicitte eksplicit – og mindre skrøbeligt.
Drift, overvågning og governance
Når grafen flytter ind, skal monitoreringen med. Vi anbefaler CI/CD for både data og modeller, så ingestion‑regler, ekstraktionsmodeller og schema kan releases kontrolleret. Evaluering af retrieval‑kvalitet skal køre løbende, ikke kun ved versionsskift. Små eval‑jobs, der måler multi‑hop præcision og kildernes dækning, er nok til at opdage drift.
Governance skal være konkret, ikke kun pæne ord. Praktiske mønstre vi bruger i projekter: redaktion/pseudonymisering ved udtræk, kryptering ved hvile for linking‑nøgler, og adgangskontrol på node‑ og/eller edge‑niveau. Få audit‑logs på plads – hvem så hvad og hvorfor – med fast review‑cadence. Test for utilsigtet PII‑sammenkædning ved at køre syntetiske navne gennem pipeline og sikre, at de ikke linkes til rigtige personer. Og husk fallback‑regler: hvis traversal er for langsom eller svarsporet er tomt, så vend tilbage til en sikker top‑k + reranker‑vej og fortæl brugeren det i systemets egen forklaring. Alle disse råd understøttes i vores faglige brief.
Ydelse og omkostninger uden pynt
En graf‑layer koster på latency, storage og drift. Caches hjælper: cache indgangsnoder for hyppige forespørgsler, og gem små subgrafer for standardruter. Vi har set simple LRU‑caches halvere traversal‑tiden i en support‑case, fordi de samme ruter gik igen. Det er en erfaringsbaseret observation, ikke et generelt løfte.
På den længere bane er forskning i lang kontekst interessant, men ikke en tryllestav for graf‑latency. MarkTechPost rapporterer, at Nous Researchs Lighthouse Attention giver cirka 1,40–1,69× hurtigere prætræning ved lange kontekster end en cuDNN‑understøttet baseline, med sammenlignelig eller lavere trænings‑loss. Det er en sekundær kilde, og metoden er træningsfokuseret research – ikke en produktionsløsning til traversal i morgen.
Tre migrationsstier alt efter appetit
Minimal ændring: bliv på vektor‑RAG, gør metadata klogere, brug en reranker og indfør skarpere evaluering. Forudsætter at spørgsmålene mest er ét‑hop, og at domænet er “tekstligt” mere end strukturelt. Risiko lav, indsats lav til moderat. God første sprint, især hvis SLA på latency er stram og budgettet endnu strammere.
Hybrid læsning: behold primær vektorsøgning, men synkroniser en read‑only graf fra kildesystemer, så I kan lave simple traversals uden at ændre skrivevejen. Kræver rimelig datakvalitet og en letvægts‑ETL. Risiko medium, indsats moderat. Effekten kan mærkes på multi‑hop spørgsmål uden at forstyrre eksisterende applikationer.
Fuld graph‑RAG: udtræk entiteter og kanter ved ingestion og kør live‑traversals i produktion. Forudsætter moden data‑governance, tydelige schemaer og en driftbar grafdatabase. Risiko højere, indsats stor. Til gengæld får man præcise svar i domæner med komplekst ejerskab og dybe afhængigheder.
En enkel TCO og latency skitse
Brug den her skitse til at kvalificere valget pr. sti:
- Minimal: lav ny infrastruktur. Omkostninger samler sig om bedre metadata, eval og eventuel reranker. Latency påvirkes minimalt. Skaler godt, men begrænset gevinst på multi‑hop.
- Hybrid: ny graf‑instans i read‑only, let ETL. Omkostninger i drift/backups samt synkronisering. Latency stiger for queries der kræver traversal; caches kan dæmpe det.
- Fuldt graf‑RAG: fuldt ingestion‑trin, live traversal, schema‑styring. Højere løbende driftsomkostning. Latency afhænger af traversal‑dybde og cache‑hit‑rate; kræver aktiv tuning.
Eksempler fra virkeligheden den uperfekte
Kundesupport, der skal samle svaret fra manual, garanti og to Jira‑sager. Med grafen som lim går systemet fra “ligner dette afsnit” til “denne specifikke enhed, i den her version, har den her kendte fejl”. Supply chain risk: en nyhedsartikel om oversvømmelse bindes til den rigtige leverandør og videre til fabrikkerne, der mangler underdelen i næste uge. Compliance‑forespørgsel: hvem må godkende, hvem gjorde det, og hvor blev undtagelsen journalført.
Vores anekdote fra foråret: en POC med et afgrænset datasæt af kontrakter, bilag og leverandøroversigter så flot ud på dashboardet. Men spørgsmålet “hvilke ordrer er i risiko pga. leverandørens seneste aflysning” gav for brede svar. En enkel graf, der linkede ordrer, leverandører og hændelser, ændrede billedet på få dage. Kvalitativt resultat, men klart i praksis: de rigtige ordrer kom frem først.
Hvad kan I gøre i næste sprint
Start småt, men målbart. Læg eval‑sæt op, der tester to‑ og tre‑hop scenarier, og mål både præcision og svartid. Log retrieval‑stien: hvilke noder og relationer blev brugt til svaret, og var de autoriserede. Og skær igennem: kan I ikke forklare linking‑reglerne, stoler brugerne heller ikke på svaret.
- Prioritet 1 – Eval baseline: definér 10–20 repræsentative multi‑hop queries, acceptance: stabil nøjagtighed over en fastsat tærskel i to uger.
- Prioritet 2 – Metadata og logging: indfør dokument‑ID, forfatter, tidsstempel, system‑of‑record og adgangsetiketter, acceptance: alle svar har sporbar kilde og retrieval‑sti.
- Prioritet 3 – Pilotgraf: byg en lille graf for ét område (produkt → komponent → hændelse) og kør hybrid retrieval på udvalgte queries, acceptance: målbar gevinst på multi‑hop uden uacceptabel latency.
- Prioritet 4 – Fallback: sæt regler for SLA og scoretærskel, acceptance: dokumenterede scenarier hvor systemet vælger ren vektor + reranker og markerer lav struktur‑sikkerhed.
Hvornår skal man lade være
Hvis jeres brugssager er rene FAQ’er, eller hvor dokumenterne i praksis svarer på ét hop, er graf‑laget sandsynligvis overkill. Jo færre krydsreferencer og jo mindre behov for at binde ustruktureret og struktureret data sammen, jo mindre gevinst. Pas også på at gå all‑in på fuld graph‑RAG uden disciplin i datakilderne – det bliver hurtigt en flot graf oven på mudder. Og der er åbne spørgsmål: bedste konsistensmønstre på tværs af ERP og graf, og praktisk PII‑håndtering i automatiske ekstraktioner kræver stadig omhu og flere produktionserfaringer.
VentureBeat og vores brief er på linje om årsagen til skiftet og de grundlæggende mønstre. Der er en lille forskel i vægtningen: VentureBeat lægger vægt på grafens strukturelle determinisme, mens vi også fremhæver mitigeringer i ren vektor‑verden som rerankere og hybrid lexical+dense. Det er ikke uenighed – mere prioritering: start med de billige forbedringer og byg graf, når spørgsmålene kræver relationer.
Praktiske noter til rollerne
For arkitekter: planlæg ingestion som et særskilt trin med entitets‑ og relationsudtræk. Beslut hvor embeddings bor i grafen, og hvordan de opdateres ved nye events. Vælg grafteknologi efter skala og konsistenskrav – ikke mode. Neo4j, JanusGraph eller noget I allerede har – vigtigst er, at I kan drifte det.
For drift og DevOps: overvåg retrieval‑kvalitet, graf‑traversal‑latency og fejl i linking. Tag backups af grafen som både snapshot og change‑log, og lav konsistenskontroller mod system‑of‑records. Når traversal fejler, skal fallback være robust og gennemsigtig. Små dashboards med top‑queries og deres ruter afslører mange problemer hurtigt.
Kort note om Snilld
Vi hjælper teams med at gå fra ren vektor‑RAG til en pragmatisk hybrid – fra arkitektur og POC til drift og evaluering – uden at vælte organisationen. Kort sagt: bygge, måle, lære.
Tre nøgler til beslutning
- Kræver jeres vigtigste spørgsmål to eller flere relationelle hop, så planlæg et graf‑lag nu – start lille, men start.
- Er latency stram og domænet enkelt, så bliv på vektor‑RAG og investér i metadata, reranking og eval – mål, ikke gæt.
- Gør ingestion klogere: entiteter, relationer, adgangsetiketter. Kvaliteten afgøres her – ikke i prompten. Man opdager først forskellen, når man sidder med det i hænderne.
