Bygga ett produktionsklart text-till-SQL-system: Uppnå 88.15 % på Spider 1.0

Att bygga ett produktionsklart text-till-SQL-system kräver mycket mer än att generera SQL med en stor språkmodell. Företagsapplikationer kräver noggrann schemaförståelse, kontexthämtning, validering och felkorrigering för att producera tillförlitliga resultat på tidigare osedda databaser.

I den här studien jämför vi vår Data Agent med Spider 1.0 och uppnår en exekveringsnoggrannhet på 88.15 % med hjälp av Gemma 4 26B -modellen. Istället för att enbart fokusera på benchmarkresultat delar den här artikeln de arkitekturbeslut, tekniska lärdomar och benchmarkinginsikter som ligger bakom dessa resultat.

Stora språkmodeller har förbättrat SQL-generering avsevärt, men att bygga ett produktionsklart Text-to-SQL-system kräver mycket mer än att översätta naturligt språk till SQL. Företagsapplikationer måste förstå komplexa databasscheman, hämta rätt kontext, validera genererade frågor och producera tillförlitliga resultat på databaser som de aldrig sett förut.

För att utvärdera dessa funktioner jämförde vi vår Data Agent med Spider 1.0, det mest använda Text-to-SQL-riktmärket. Med hjälp av Gemma 4 26B -modellen uppnådde vårt system 88.15 % exekveringsnoggrannhet , vilket visar att arkitektur och kontexthantering är lika viktiga som modellval.

Att välja rätt riktmärke är lika viktigt som att välja rätt modell. Medan nyare datamängder som Spider 2.0 och BIRD introducerar mer komplexa företagsscenarier, är Spider 1.0 fortfarande det mest använda riktmärket för att utvärdera Text-to-SQL-system och jämföra resultat från olika litteraturkällor.

För vår första utvärdering valde vi Spider 1.0 eftersom den ger en standardiserad och väletablerad baslinje. Den låter oss mäta hur effektivt vår Data Agent förstår tidigare osedda databasscheman och genererar korrekt SQL under realistiska förhållanden.

Figur 2 sammanfattar hur Spider 1.0 står sig i jämförelse med andra vanligt förekommande Text-to-SQL-riktmärken.

Att uppnå hög text-till-SQL-noggrannhet handlar inte bara om att använda en större språkmodell. Under hela vår benchmarkingprocess fann vi att arkitektur och kontexthantering hade större inverkan på prestandan än enbart modellval.

Vår dataagent är utformad som en flerstegspipeline som gradvis begränsar problemet innan LLM:en ombeds att generera SQL. Istället för att exponera hela databasschemat för modellen hämtar systemet först endast relevant schema och kontextuell information, genererar sedan en SQL-fråga, validerar resultatet och korrigerar automatiskt vanliga fel innan körning.

Som illustreras i figur 3 består arkitekturen av tre huvudsteg:

• Informationsinhämtning – Användarens fråga analyseras för att identifiera relevanta databasobjekt, och endast nödvändig schemainformation hämtas från metadatalagret.
• Självraffinerande medel – Språkmodellen genererar SQL, validerar frågan mot det hämtade schemat och förfinar den automatiskt när valideringen misslyckas.
• Utförande och svar – När SQL-frågan har validerats körs den mot måldatabasen och resultaten returneras som strukturerade data eller ett naturligt språksvar.

Denna produktionsorienterade arkitektur är inspirerad av idéer som introducerats i DIN-SQL och DAIL-SQL , samtidigt som den är anpassad för företagsmiljöer där tillförlitlighet, förklarbarhet och robusthet är lika viktiga som noggrannhet i riktmärken.

Att välja rätt språkmodell var en viktig del av vår benchmarkingprocess. Istället för att utvärdera en enda modell experimenterade vi med ett brett utbud av LLM:er med öppen källkod, inklusive Llama 3.1, Qwen 2.5, DeepSeek, SQLCoder, CodeGemma, Mistral, GPT-OSS och Gemma 4.

För att säkerställa en rättvis jämförelse utvärderade vi varje modell med hjälp av Execution Accuracy (EA) , standardmåttet för Text-to-SQL-benchmarking. Till skillnad från syntaxbaserade mätvärden mäter Execution Accuracy om den genererade SQL-frågan returnerar samma resultat som referensfrågan, vilket gör den till en bättre indikator på verklig prestanda.

Vår benchmarkingresa illustreras i figur 4. Vi började med att experimentera på en lokal arbetsstation utrustad med ett RTX 4060 (8 GB VRAM) , där mindre modeller gjorde det möjligt för oss att iterera snabbt och validera vår pipeline. Efter att ha etablerat en stabil baslinje med en delmängd av 233 Spider 1.0-frågor, gick vi över till moln-GPU:er för att utvärdera större modeller på hela benchmarket med 2 147 frågor . Denna etappvisa metod gjorde det möjligt för oss att optimera arkitekturen effektivt innan vi investerade i storskaliga benchmarkkörningar.

Vi utvärderade de slutliga modellerna på hela Spider 1.0-testuppdelningen innehållande 2 147 frågor. Som visas i tabell 1 uppnådde Gemma 4 26B den högsta poängen (88.15 %), följt av GPT-OSS 20B (86.63 %). Dessa resultat visar att moderna LLM:er med öppen källkod, i kombination med en effektiv hämtnings- och valideringspipeline, kan uppnå mycket konkurrenskraftig Text-to-SQL-prestanda. 

Jämförelseresultat är endast meningsfulla när de kan jämföras med tidigare publicerat arbete. För att bättre förstå betydelsen av våra resultat granskade vi både aktuella Text-to-SQL-studier och allmänt refererade referensartiklar.

Tabell 2: Noggrannhetsgraderna för modeller med sluten källkod som rapporterats i SQL-of-Thought-studien på en delmängd av Spider-datasetet; den visar, i jämförelse, att resultatet på 88.15 % som erhölls i detta arbete ligger över GPT-4o Mini (87 %) och på en nivå nära GPT-5 (89 %).

Nyligen genomförda studier som SQL-of-Thought [1] rapporterar att ledande modeller med sluten källkod – inklusive Claude Opus 3, GPT-5 och GPT-4o Mini – uppnår hög noggrannhet på Spider-benchmark-delmängder. Även om direkta jämförelser bör tolkas noggrant på grund av skillnader i utvärderingsinställningar, prompter och benchmark-delmängder, visar vår exekveringsnoggrannhet på 88.15 % att modeller med öppen källkod kan uppnå prestanda inom samma konkurrensområde.

Även om dessa resultat kommer från olika utvärderingsmiljöer och inte bör jämföras direkt, ger de användbar kontext för att förstå det nuvarande prestandalandskapet för Text-to-SQL-system. Vårt riktmärke visar att modeller med öppen källkod nu kan konkurrera med ledande alternativ med sluten källkod när de kombineras med en väl utformad arkitektur.

Vi jämförde också våra resultat med produktionsorienterade Text-to-SQL-ramverk som DIN-SQL [3] och DAIL-SQ L, vilka kombinerar stora språkmodeller med tekniker som schemalänkning, prompt engineering, självkonsistens och felkorrigering.

Tabell 3: Resultaten av exekveringsnoggrannheten för olika metoder på Spider 1.0 i studien "Text-to-SQL Empowered by Large Language Models: A Benchmark Evaluation" [2]; den visar effekten på noggrannheten inte bara av modellval utan även av tekniker som prompt engineering, schemalänkning och självkonsistens.

Våra resultat förstärker en slutsats som delas i den senaste litteraturen: hög prestanda för Text-to-SQL beror inte bara på språkmodellen utan även på den omgivande arkitekturen. Effektiv schemahämtning, kontexthantering, validering och självkorrigering är ofta lika viktiga som själva modellen.

Benchmarking handlar inte bara om att mäta noggrannhet – det handlar också om att förstå var och varför ett system misslyckas. Under vår utvärdering analyserade vi felaktiga förutsägelser och identifierade flera återkommande mönster som påverkade slutresultaten.

Vissa fel härrörde från själva riktmärket. I ett litet antal fall orsakade inkonsekvenser i referens-SQL-frågorna (guld) att logiskt korrekta förutsägelser markerades som felaktiga. Andra fall involverade tvetydiga frågor i naturligt språk eller oavgjorda scenarier, där flera SQL-frågor legitimt kunde producera lika giltiga svar.

Vi observerade också flera modellspecifika beteenden, inklusive onödiga typkonverteringar, inkonsekvent hantering av skiftlägeskänslighet och enstaka överkomplikationer av annars enkla SQL-frågor. Dessa resultat förstärkte vikten av att integrera validerings- och självkorrigeringsmekanismer i Data Agent-pipelinen.

Sammantaget visade vår analys att många återstående fel inte orsakades av begränsningar i själva språkmodellen, utan av oklarheter i riktmärket eller kantfallen vid SQL-generering. Detta tyder på att ytterligare förbättringar av hämtning, validering och kontexthantering skulle kunna driva systemet bortom tröskeln på 90 % exekveringsnoggrannhet .

Hög noggrannhet är bara en aspekt av ett produktionsklart Text-to-SQL-system. I företagsmiljöer är infrastrukturkostnader, datasekretess och distributionsflexibilitet lika viktiga faktorer.

En av de viktigaste fördelarna med vår metod är att den helt förlitar sig på språkmodeller med öppen källkod. Under hela utvecklingsprocessen kunde vi utföra de flesta experimenten lokalt med ett konsumentklassat RTX 4060 (8 GB VRAM) , vilket gjorde det möjligt för oss att iterera snabbt utan att ådra oss några API- eller tokenkostnader. Större benchmarkkörningar kördes sedan på dedikerade moln-GPU:er först efter att arkitekturen hade validerats.

Vi använde RunPod Secure Cloud för den fullständiga utvärderingen av Spider 1.0. Gemma 4 26B-benchmarktestet kördes på ett A100 PCIe 80 GB GPU, medan GPT-OSS 20B kördes på ett RTX 6000 48 GB GPU.

Infrastrukturkostnaderna sammanfattas i tabell 4.

Även om de största benchmarkkörningarna krävde molninfrastruktur, förblev den övergripande utvecklingsprocessen kostnadseffektiv tack vare lokala experiment och modeller med öppen källkod. Ännu viktigare är att den resulterande arkitekturen kan distribueras helt inom en organisations egen infrastruktur, vilket eliminerar beroendet av externa API:er samtidigt som det ger större kontroll över datasekretess, efterlevnad och driftskostnader.

Detta gör arkitekturen särskilt väl lämpad för organisationer som verkar i integritetskänsliga, reglerade eller avgränsade miljöer, där datasäkerhet och flexibilitet vid distribution är avgörande krav.

Riktmärken ger ett objektivt sätt att utvärdera AI-system, men de är inte det slutgiltiga målet. Ett högt riktmärkesresultat är bara värdefullt om det leder till tillförlitlig prestanda i verkliga tillämpningar.

Genom hela studien fann vi att det att bygga ett produktionsklart Text-to-SQL-system handlar om mycket mer än att bara generera SQL. Att förstå databasscheman, hämta rätt kontext, validera genererade frågor och förfina felaktiga utdata visade sig vara lika viktigt som själva språkmodellen.

Vår exekveringsnoggrannhet på 88.15 % i Spider 1.0 visar att modeller med öppen källkod, i kombination med en väl utformad arkitektur, kan leverera mycket konkurrenskraftig prestanda för Text-to-SQL-uppgifter på företag. Ännu viktigare är att det validerar designprinciperna bakom vår Data Agent , som byggdes för att fungera tillförlitligt på komplexa företagsdatabaser snarare än bara på benchmark-dataset.

Spider 1.0 representerar en viktig milstolpe, men det är bara början på vår resa. Våra nästa steg inkluderar att utvärdera Data Agent på Spider 2.0 , större företagsnivåer och, viktigast av allt, verkliga kundmiljöer där databasscheman är betydligt större och affärsfrågor är mycket mer komplexa.

Vår långsiktiga vision är inte bara att bygga en bättre SQL-generator. Vi strävar efter att bygga intelligenta dataagenter som gör det möjligt för organisationer att interagera med företagsdata lika naturligt som de kommunicerar med en kollega – och kombinerar hämtning, resonemang, validering och förklarbar AI i en pålitlig beslutsstödsplattform.

Benchmarking handlar inte bara om att mäta noggrannhet – det handlar om att förstå varför ett system lyckas eller misslyckas.

Under vår utvärdering identifierade vi flera återkommande felmönster. Vissa härrörde från oklarheter i själva riktmärket, inklusive inkonsekvenser i referens-SQL-frågor och underspecificerade ordningsvillkor. Andra återspeglade vanliga LLM-beteenden, såsom onödig typomvandling eller inkonsekvent hantering av skiftlägeskänsliga värden.

Dessa observationer förstärkte ett av de centrala resultaten i vårt arbete: arkitektur spelar lika stor roll som modellval. Hämtning, schemalänkning, validering och självkorrigering bidrog lika mycket till den slutliga prestandan som den underliggande språkmodellen.

Även om begränsningar i riktmärket oundvikligen påverkar slutresultatet, tyder vår analys på att ytterligare förbättringar av kontexthantering och validering skulle kunna driva systemet bortom 90 % exekveringsnoggrannhet.

Spider 1.0 gav en viktig baslinje för utvärdering av vår Data Agent, men den representerar bara det första steget mot produktionsklar företags-AI.

Vårt nästa fokus är att utvärdera arkitekturen mot mer utmanande riktmärken som Spider 2.0 och, ännu viktigare, mot verkliga företagsdatabaser där scheman är betydligt större, dokumentationen ofta ofullständig och affärsfrågor är mycket mer komplexa.

Vårt mål är inte bara att bygga ytterligare ett text-till-SQL-system. Vi bygger intelligenta dataagenter som kombinerar hämtning, resonemang, validering och förklaringsförmåga för att hjälpa organisationer att interagera med företagsdata på ett naturligt och tillförlitligt sätt.

Referensprojekt

[1] Saumya Chaturvedi, Aman Chadha, Laurent Bindschaedler arXiv. “SQL-of-Thought: Multiagentisk text-till-SQL med guidad felkorrigering.” arXiv. Juni 2026 https://arxiv.org/abs/2509.00581

[2] Dawei Gao, Haibin Wang, Yaliang Li, Xiuyu Sun, Yichen Qian, Bolin Ding, Jingren Zhou “Text-to-SQL Empowered by Large Language Models: A Benchmark Evaluation” arXiv. juni 2026

https://arxiv.org/pdf/2308.15363 

[3] Mohammadreza Pourreza, Davood Rafiei. “DIN-SQL: Dekomponerad kontextuell inlärning av text-till-SQL med självkorrigering” arXiv. Juni 2026

https://arxiv.org/pdf/2304.11015

Dilşen YILDAR HAVAYLAR, 

Sr. mjukvaruingenjör, magisterexamen.