TLDR;
Integrering av eksterne kunnskapsbaser med store språkmodeller (LLM-er) gjennom Retrieval-Augmented Generation (RAG) har vist seg å være en effektiv måte å øke presisjon og kontekstforståelse i genererte svar. I artikkelen “Graph RAG vs SQL RAG: Evaluating RAGs on graph and SQL databases” (Reinhard Sellmair, 1. november 2025) ble denne tilnærmingen testet empirisk ved å sammenligne ytelsen til LLM-er som GPT-3.5, GPT-4 og GPT-5 på én og samme datakilde lagret i to ulike databaseparadigmer: SQL og grafdatabaser.
Formål og metode
Sellmair lagret et omfattende Formel 1-resultatsett (1950–2024) i både en SQL-database og en grafdatabase for å undersøke hvordan ulike RAG-arkitekturer håndterer strukturerte og relasjonelle data. Datasettene inkluderte resultater fra kvalifisering, sprintløp, hovedløp, samt rundetider og pit-stopp, i tillegg til sammenlagtstillingen for førere og konstruktører etter hvert løp.
Ved hjelp av LangChain og ChatOpenAI ble det bygget to RAG-kjeder — én for SQL og én for grafdatabasen. Modellen fikk generere spørringer basert på brukerens spørsmål, hente relevante data og deretter formulere et svar. Alle modellene brukte det samme system-promptet og de samme spørsmålene for å sikre rettferdig sammenligning.
Datastruktur og forskjeller
SQL-databasen besto av 14 tabeller knyttet sammen gjennom primær- og fremmednøkler, med Races som sentral tabell koblet til blant annet Drivers, Constructors og Results. Dette ga et tradisjonelt relasjonelt oppsett med høy struktur og presisjon.
Grafdatabasen representerte de samme dataene med kun seks noder og relasjoner mellom dem. Et Car-node fungerte som bindeledd mellom fører, konstruktør og løp, slik at endringer i lag-tilhørighet over tid kunne modelleres direkte i grafen. Resultater og mesterskapsposisjoner ble lagret som relasjonstyper (:RACED og :STOOD_AFTER).
Evaluering av LLM-ytelse
Spørsmålene ble delt inn i tre vanskelighetsnivåer: enkle (én tabell/node), middels (flere koblinger) og komplekse (flere ledd eller underspørringer). I tillegg ble det inkludert spørsmål som ikke kunne besvares ut fra databasen, for å teste modellens evne til å erkjenne kunnskapsgrenser.
Resultatene viste klare forskjeller mellom modellene:
- GPT-3.5-turbo: presterte svakt og ga flere feil svar, spesielt på grafspørringer.
- GPT-4: ga generelt riktige SQL-svar, men slet med enkelte mer komplekse grafspørringer.
- GPT-5: leverte nesten perfekte resultater i begge databasetyper, med kun ett feil svar per system.
Interessant nok viste GPT-5 identisk totalscore på både SQL- og grafdatabasen (18 av 20 poeng), mens enklere modeller klarte seg bedre på SQL-data enn grafdata. Dette antyder at nyere modeller håndterer relasjonelle mønstre og kontekstuell strukturering langt bedre enn tidligere generasjoner.
Feilkilder og observasjoner
To feil ble fremhevet i evalueringen: I SQL-systemet svarte GPT-5 “Lewis Hamilton” som den mestvinnende verdensmesteren, men overså at Michael Schumacher hadde samme antall titler. I graf-systemet svarte modellen feil på spørsmålet om hvem som vant Formel 2-mesterskapet i 2017 — data som ikke finnes i databasen — noe som illustrerer utfordringen med å balansere mellom intern kunnskap og ekstern datakontekst.
Sellmair påpeker at en måte å redusere slike feil på er å spesifisere tydelig i promptet at modellen kun skal bruke data fra den tilkoblede databasen som kunnskapsgrunnlag.
Konklusjon
Studien viser at database-valget ikke gir store forskjeller i nøyaktighet for moderne LLM-er som GPT-5. Valget bør derfor styres av hvordan dataene naturlig er strukturert, heller enn forventning om ytelsesforskjell. SQL-databaser passer best for veldefinerte, tabulære data, mens grafdatabaser egner seg når relasjonene mellom entiteter står sentralt.
Sellmairs eksperiment understreker hvor langt RAG-metodikken har kommet — dagens LLM-er kan integrere strukturerte data på presist og kontekstuelt vis uten avansert prompt-tilpasning. Hele analysen, med kode og resultattabeller, er tilgjengelig i originalartikkelen “Graph RAG vs SQL RAG” av Reinhard Sellmair (2025).