24 June 2026 · 9 min
Vektorsökning hämtar det som liknar. För flerstegs relationsfrågor räcker det inte.
Retrieval-augmenterad generering har blivit standardsättet att förankra en språkmodell i egen data, och för de flesta team betyder det en sak: embedda allt till vektorer, lagra dem i en vektordatabas och hämta de närmaste träffarna för varje fråga. För en stor klass problem fungerar detta anmärkningsvärt väl. Men det finns en andra klass där det tyst misslyckas, och misslyckandet är lätt att missa eftersom systemet fortfarande ger självsäkra, rimliga svar — bara ofullständiga eller fel.
Den avgörande skillnaden är inte vilken teknik som är nyare eller mer sofistikerad. Det är formen på din data och formen på frågorna. Får du den diagnosen rätt blir valet mellan rent vektorsök och en grafbaserad ansats uppenbart.
Vektorsök svarar på likhetsfrågor. Du har mycket text, någon frågar, och svaret ligger i en passage — eller några få — som är semantiskt nära frågan. Produktdokumentation, kunskapsbaser, supportarkiv, forskningsbibliotek: en nästan perfekt match. Faktumet sitter i en chunk, chunken liknar frågan, och hämtningen hittar det.
För denna klass är vektorsök snabbt, billigt och svårslaget. Att lägga grafmaskineri ovanpå vore överingenjörskonst — komplexitet utan vinst. Om dina frågor besvaras av den mest relevanta passagen behöver du inget mer avancerat, och vi säger det istället för att sälja ett större system.
Problemet börjar när svaret inte ligger i någon enskild passage utan i relationerna mellan passager. Tänk på: vilka leverantörer påverkas av en förordning som ändrar en annan förordning som styr en komponent använd i en produktlinje ägd av ett visst dotterbolag? Ingen enskild chunk innehåller det. Det måste sättas samman genom att följa länkar från ett faktum till nästa.
Vektorsök kan inte följa länkar. Det hämtar passager som liknar frågan, men likhet är inte förbindelse. De enskilda hoppen kan var och en vara textmässigt olika frågan, så de rätta passagerna dyker aldrig upp. Modellen svarar då från det den hämtade — flytande, självsäkert, fel. Just detta läge överraskar team, eftersom inget kastar ett fel.
En kunskapsgraf lagrar fakta som explicita entiteter och relationer: denna förordning ändrar den, denna komponent hör till den produkten, denna produkt till det dotterbolaget. GraphRAG kombinerar denna struktur med hämtning. Istället för att bara hitta liknande text kan den traversera grafen — ändringslänken, sedan komponentlänken, sedan ägarlänken — och bygga ett svar från en kedja kopplade fakta.
Detta låser upp multi-hopp-frågor som platt hämtning inte kan röra. Det ger en andra fördel som betyder enormt i reglerade miljöer: spårbarhet. Eftersom svaret byggdes genom att gå en explicit väg genom grafen kan du visa den vägen. Svaret kommer med resonemanget fäst, som granskare kan verifiera.
Grafer är inte gratis. Att bygga en betyder att extrahera entiteter och relationer från datan — ett modelleringsarbete vektorsök hoppar helt över. Du måste avgöra vad entiteterna är, vilka relationer som kopplar dem, och hålla strukturen aktuell. För text där svaren verkligen ligger i enskilda passager är detta ren overhead utan avkastning.
Just därför kommer diagnosen först. Att gripa efter en graf för att den låter kraftfullare är ett vanligt och dyrt misstag. Grafen förtjänar sin kostnad bara när dina frågor verkligen kräver att följa förbindelser; annars är den komplexitet du underhåller för alltid utan vinst.
I praktiken är de starkaste systemen sällan rena. De flesta äkta korpusar innehåller båda slags frågor: många som en relevant passage besvarar, och några som kräver att koppla fakta. Rätt arkitektur använder vektorsök för semantisk återkallning och ett graflager för de relationella multi-hopp-fallen, och dirigerar varje fråga till mekanismen som passar.
Att designa den delningen väl — vad som modelleras som graf, vad som blir platt text, och hur de två kombineras vid fråga — är där merparten av ingenjörsomdömet ligger. Rätt gjort betalar du för grafkomplexitet bara där den betalar tillbaka.
Du kan oftast diagnostisera fallet från frågorna ensamma. Skriv ner de tio svåraste frågorna dina användare faktiskt ställer. Om var och en besvaras av den enda mest relevanta passagen behöver du vektorsök och inget mer. Om några bara kan besvaras genom att kombinera flera fakta som inte är textmässigt lika har du multi-hopp-frågor, och ett graflager förtjänar sin plats.
Vi startar varje hämtningsprojekt med precis denna övning, på dina äkta frågor och data, innan någon kod skrivs. Tekniken följer diagnosen, aldrig tvärtom — och diagnosen är nästan alltid tydligare än marknadsföringen kring båda ansatserna.
Boka ett 30-minuters samtal. Vi säger ärligt om vi kan hjälpa.
Boka samtal