Lad os være ærlige. Mange RAG-projekter går i stå, når et spørgsmål kræver to-tre hop gennem kilder. AWS skriver det selv i deres indlæg: LLM’er kæmper med at samle viden på tværs af flere kilder, og klassisk RAG ser for ofte hvert dokument som en ø. HippoRAG prøver at løse det i retrieval-laget, så modellen får de rigtige brikker stillet op fra start.
Hvad HippoRAG er
Det er ikke en løs graf ved siden af vektorsøgning. Idéen er at erstatte iterative, prompt-styrede hop med et enkelt rangeret overblik over de mest relevante noder og kanter i grafen. Single-step multi-hop. Det skærer antallet af LLM-kald og øger sporbarheden, fordi kilderne følger med som noder og relationer i stedet for løse tekstuddrag.
Hvordan det adskiller sig fra standard RAG
I klassisk RAG bliver multi-hop ofte til flere runder: hent, generér del-svar, hent igen. Det falder fra hinanden, når relationer er skrøbelige. HippoRAG vender rækkefølgen: man opbygger først et lag af entiteter og relationer, så multi-hop bliver en grafforbindelse, ikke en prompt-koreografi.
Personalized PageRank er motoren. Spørgsmålet udleder seed-noder, PPR spreder vægt gennem netværket og returnerer en rangeret liste over noder og kanter, der tilsammen danner en mulig beviskæde. Ét retrieval-træk frem for en stak iterative kald. For dem, der arbejder med grafer, giver det mening: relationel struktur hjælper.
AWS-arkitekturen i praksis
AWS demonstrerer HippoRAG med fire byggeklodser. Amazon Bedrock håndterer LLM-opgaver, både udtræk af entiteter og triples samt selve besvarelsen. Amazon Neptune er grafdatabasen. Amazon Neptune Analytics kører de tunge grafalgoritmer, herunder Personalized PageRank. Og Amazon Titan Embeddings leverer vektorlaget til semantisk søgning, så den dimension ikke går tabt.
Valget peger på en AWS-først arkitektur: Bedrock samler modelkald, Neptune er managed graf, Analytics tager PPR’s beregningstunge del, og Titan passer ind i samme økosystem. For nogle er det en fordel, for andre en lock-in-bekymring. Men det er den opskrift, AWS viser her.
Datapipelinen og eksemplet med HotpotQA
Blogindlægget bruger HotpotQA som datakilde og viser forløbet trin for trin: rå JSON til Bedrock for triple- og entitetsudtræk, Neptune bulk-load CSV’er i S3 og import til Neptune. Der er konkret kode og klasseeksempler til import, batchning og en genkørbar pipeline, så man kan følge spor fra rå data til en navigerbar graf.
Kravene står også klart: triple-kvalitet og konsolidering af entitetsnavne er afgørende. Ellers ender man med dubletter, brudte kanter og en graf, der ikke kan bruges. Validering, normalisering og deduplikering er ikke svært at kode, men at holde det stabilt over tid, når kilderne ændrer sig, er der arbejdet ligger.
Hvad det betyder for implementering
I en enterprise-kontekst rækker en notebook ikke. Man skal have en Neptune-klynge, arbejdsgrafer i Neptune Analytics, Bedrock-adgang, S3-buckets og IAM-roller, der er strammet til. Latency tæller: PPR på store grafer koster. Caching, præberegning af hotspots og disciplin i valg af seed-noder gør en reel forskel, især hvis spørgsmålene har tydelige domæne-clustre, man kan genbruge.
Hold opsætningen nøgtern: beslut, hvilke dokumenttyper der bliver til hvilke entiteter og kanter, og frys schemaet tidligt. Justér siden. Det lyder kedeligt, men uden schema-disciplin drukner man hurtigt i nye noder med næsten samme navn.
Hvor begrænsningerne ligger
HippoRAG antager, at fakta og relationer kan modelleres robust som noder og kanter. Det gælder i mange domæner, men ikke alle. Ustruktureret eller tvetydig tekst kan tabe nuance i triple-form. Sporbarheden er kun så god som de kanter, man faktisk har udtrukket. Er ekstraktionen usikker, er forklaringen det også.
PPR kræver tuning. Damping, seed-vægte, stopkriterier og undergrafsvalg kan flytte rangeringen mærkbart, især i grafer med hubs. AWS viser værktøjerne, men ikke tallene. Der er ingen offentliggjorte benchmarks for latency, nøjagtighed eller omkostning mod en baseline i blogindlægget. Det må man måle selv, før man skalerer ud.
Hvornår klassisk RAG stadig rækker
Standard RAG er stærkt, når et spørgsmål besvares af ét dokument eller få nærliggende uddrag: FAQ’er, afsnit i en manual, simpel kundesupport. Her bliver et graflag overkill, der tilføjer latency og driftskompleksitet. Hvis data ændrer sig sjældent, eller domænet ikke har entiteter, der er lette at navngive og forbinde, er gevinsten lille. Vektorbaseret retrieval med veltrimmet prompt-design rækker længere her.
Med andre ord: vælg graf, når relationer bærer viden. Ellers, bevar enkelheden.
Konsekvenser for virksomheder
Oplagte cases er enterprise search med komplekse sammenhænge, videnassistenter for politikker, der opdateres løbende, og compliance-scenarier, hvor beviskæden bag et svar skal kunne dokumenteres. Også ved teknisk fejlsøgning på tværs af manualer, tickets og release notes. Fordelen er højere sandsynlighed for at samle de rigtige brikker og et tydeligere audit trail via præcise kildehenvisninger i grafen.
Organisatorisk kræver det data engineering- og graph-kompetencer. Nogen skal eje schemaet for entiteter og relationer og kunne sige nej til at smide alt i grafen. Derudover kræver det governance: inkrementelle opdateringer, sletninger, dataklassifikation og adgang på node-niveau. AWS berører IAM, men ikke hele governance-mønsteret. Det er afgørende i praksis.
Tekniske anbefalinger
Start småt: et afgrænset domæne og en kompakt, høj-kvalitets knowledge graph fra 1 til 3 kilder. Fastlæg målepunkter før kode: nøjagtighed på multi-hop, hop-coverage, latency per forespørgsel, antal LLM-kald per svar og om hvert svar kan spores til konkrete noder og dokumenter. Etabler en baseline med jeres nuværende RAG og mål forbedringen. Hvis den ikke er tydelig, er grafen næppe løsningen i det domæne.
Dokumentér driftsbeslutningerne tidligt: seed-strategier, PPR-parametre og fallback-logik til ren vektorsøgning. Ellers kan I ikke gentage succeserne, når de opstår. Eller fejlene, når de også gør det.
IAM, sikkerhed og drift
Blogindlægget nævner IAM-forudsætninger, men ikke et færdigt sikkerhedsdesign. I praksis ender man med rolleopdeling for ingestion kontra query, stramme S3-bucket policies, kryptering i transit og i ro for Neptune og S3 samt miljøadskillelse mellem test og produktion. Adgangskontrol på node- eller kant-niveau kommer ikke gratis. Spejl gerne dataklassifikation i grafschemaet, så følsomme relationer ikke lækker.
På driften er observability centralt: mål PPR-køretider, bulk-load-fejl, andel af forespørgsler der falder tilbage til vektor-RAG, og ryd løbende op i entitetsnavne. Overvåg grafinflation. En simpel disciplin hjælper: ingen nye entiteter uden kilde og type.
Konkurrence og kontekst
HippoRAG står ikke alene; der findes andre multi-hop- og graph-hybrider. AWS’ styrke er en sammenhængende, managed opskrift på deres platform. arXiv-præprintet giver den akademiske ramme, blogindlægget den praktiske opsætning. Modeludbuddet bevæger sig, men pointen består: hvor opgaver kræver relationel forståelse, bør retrieval-laget afspejle det.
Vigtigt: AWS viser en implementation, ikke en benchmark. Der mangler uafhængige målinger af skalerbarhed for PPR på meget store enterprise-grafer og af omkostningsprofiler under last. Indtil de data findes, bør HippoRAG ses som en stærk kandidat til udvalgte domæner, ikke en universalløsning.
Hvad man realistisk kan forvente de næste 6 til 12 måneder
HippoRAG kan løfte kvaliteten i domæner, der naturligt modelleres som entiteter og relationer, og hvor multi-hop er normen. Forvent færre LLM-kald per komplekst spørgsmål og bedre sporbarhed, og forvent arbejde med schema, pipelines og PPR-tuning samt en læringskurve for teams uden graf-erfaring. Det er indsatsen værd. Bare ikke trylleri.
