Google Research annoncerede 12. juni, at Gemini‑SQL2 rammer 80,04% execution accuracy på BIRD Single‑Model leaderboard. En pæn stigning over forgængeren ifølge Googles egen graf, og signalet er klart: tekst‑til‑SQL er på vej fra demo til noget, man kan bygge ind i dataarbejdet. Stort, ja — men med forbehold.
Nyheden kom via en X‑post fra Google Research, suppleret af MarkTechPost, der samler tal og kontekst. Der er ikke tale om en ny foundation‑model, men en kapabilitet oven på Gemini 3.1 Pro. Det vigtige er derfor ikke branding, men hvad 80,04% EX på BIRD betyder i praksis for BI‑teams, datafolk og beslutningstagere — og hvor hullet stadig er til menneskelig performance.
Hvad Google sagde — og hvad kilden viser
Google beskriver Gemini‑SQL2 som tekst‑til‑SQL oven på Gemini 3.1 Pro, ikke et selvstændigt modelrelease. MarkTechPost gengiver scoren 80,04% execution accuracy på BIRD Single‑Model og viser, at Googles graf placerer Gemini‑SQL2 over Gemini‑SQL. Kun 80,04% er angivet eksplicit; resten aflæses omtrentligt fra grafen og bør tages med et gran skepsis. X‑posten nævner også integrationsmål som BigQuery Studio, AlloyDB AI og Cloud SQL Studio, men uden bekræftet udrulningsplan.
Når kilden er en graf i et socialt opslag, er alt under toppunktet usikkert på decimalerne. MarkTechPost gør opmærksom på det — og det er fair. Konklusionen, man roligt kan stå på, er dog enkel: Gemini‑SQL2 ligger over forgængeren og over flere navngivne konkurrenter i Single‑Model sporet på BIRD.
Hvad BIRD måler — teknisk men klart
BIRD evaluerer execution accuracy (EX): den genererede SQL skal køre mod databasen og returnere samme resultatsæt som en gold query. Ikke bare ligne god SQL. Det skiller BIRD fra ældre benchmarks, hvor syntaks og struktur fyldte for meget. Her testes, om svaret er rigtigt, når man trykker kør.
Datasetbeskrivelsen, som MarkTechPost gengiver, er ikke lille: 12.751 spørgsmål‑SQL‑par, 95 databaser, 37 domæner, cirka 33,4 GB. Der er bevidst “dirty values” og behov for ekstern viden i flere opgaver, hvilket gør opgaven mere realistisk og mindre skolebogsagtig. Derfor føles få procentpoint som store spring i praksis. EX er binær: kørte den, og kom de rigtige rækker ud.
Hvor meget bedre er Gemini‑SQL2 reelt?
Googles graf antyder, at tidligere Gemini‑SQL lå omkring 77,2%. Google Cloud rapporterede 76,13% i november 2025 for Single‑Model track ifølge MarkTechPost. Med 80,04% er der et løft på cirka 2,8 til 3,9 procentpoint over forrige niveau, afhængigt af reference. Ikke et kvantespring, men i EX‑termer et reelt skridt.
Menneskelig benchmark på BIRD angives til 92,96%. Det efterlader et hul på 12,92 procentpoint til Gemini‑SQL2. Ædrueligt — og netop pointen: stærkt fremskridt, ja, men ikke et niveau til ukritisk kørsel af kritiske queries.
Hvad Single‑Model tracken betyder for tolkning
Single Trained Model Track begrænser forbehandling, retrieval og agentiske ensembles. Målet er at måle den “rå” tekst‑til‑SQL‑evne. Det gør sammenligninger renere for, hvad en enkelt model kan alene. Til gengæld siger det mindre om, hvad man kan bygge i et produkt med værn, heuristik og retrievers ovenpå.
En høj Single‑Model‑score er en stærk indikator for basiskvalitet, men ikke en garanti for produktionsadfærd i miljøer med datasikkerhed, latenskrav og skæve skemaer. Leaderboardet er bundlinje — ikke hele historien.
Praktiske konsekvenser for organisationer
Hvis 80% EX lyder som “næsten i mål”, er det ikke helt forkert — for de rigtige opgaver. Mange standardforespørgsler i rapportering kan nu auto‑udledes med høj sandsynlighed for korrekt resultat. Men én ud af fem rammer ved siden af, og tallet gælder et benchmark, ikke din egen datasump af aliaser, skæve datoformater og gamle visninger. Vær nøgtern.
Fire områder ændrer sig i praksis: 1) Selvbetjening i BI: flere brugere kan stille spørgsmål og få kørende SQL hurtigere, hvilket aflaster dataholdet. 2) Valideringslag og fallback: drift kræver godkendelse, regressionstests og sikre rollemønstre. 3) Governance: logning af prompts, genereret SQL og resultater samt revisionsspor. 4) Roller og kompetencer: prompt‑design, schema‑kontrakter og enkle data‑sanity‑checks bliver hverdag.
Sådan bygges de fire spor uden at drukne
Start selvbetjening i BI som read‑only. Begynd med dimensionelle spørgsmål og aggregeringer, hvor konsekvensen ved fejl er lav. Gør det tydeligt, når et svar er modelgenereret, og vis SQL’en åbent — det hæver kvaliteten, fordi fejl bliver synlige og retbare.
Validering og fallback er en pipeline, ikke et punkt. Minimum: en automatisk testsuite med kendte spørgsmål og gold‑resultater, manuel godkendelse for nye skemadele, samt sanity‑checks som rækkeantal, null‑andele og range‑kontroller. Når noget fejler, rulles der tilbage til en kendt god variant. Ikke fancy — bare sikkert.
Integrationer og usikkerheder
Google peger mod BigQuery Studio, AlloyDB AI og Cloud SQL Studio som naturlige hjem for kapabiliteten. Det giver mening, men der er ikke annonceret produktudrulning eller dato. Det er sandsynlig retning, ikke bekræftet plan.
De åbne spørgsmål er praktiske: latens per query, adgang til skema og metadata i runtime, hvordan credentials og row‑level security respekteres, og hvad prisstrukturen bliver, når generation og kørsel skaleres. Uden svar på de punkter er ROI svær at regne på. Proof‑of‑concepts bliver derfor nødvendige.
Hvor er faldgruberne — når 80% ikke er nok
Der findes domæner, hvor 80% EX ikke er acceptabelt: finansrapportering, regulatoriske forespørgsler, automatiserede ændringer af data (UPDATE og DELETE). Det bør ikke overlades til en model uden menneskelig godkendelse. Her er fejl for dyre, for synlige og ofte irreversible.
Et konservativt setup er effektivt: tillad kun SELECT i første fase, kræv menneskelig godkendelse for queries mod følsomme tabeller eller med høj omkostning, og kør alt nyt mod testsæt før produktion. Supplér med whitelist af funktioner, tvungen kvalificering af tabelnavne og begrænset brug af komplekse subqueries i første iteration. Kedelig drift slår smarte fejl.
Dialog med konkurrentlandskabet
Googles graf viser Gemini‑SQL2 foran forgængeren og en række navngivne konkurrenter, inklusiv specialiserede 32B SQL‑modeller. Et par frontier‑modeller ligger lavere. Mønsteret er ikke overraskende: specialiserede modeller kan være stærke på text‑to‑SQL, men en stor generalist med målrettet kapabilitet tager nu føringen på Single‑Model‑sporet.
Det betyder ikke, at nichemodeller er ude. I miljøer med sær skemalogik, produkt‑specifikke funktioner eller sproglige krav kan en finetunet 32B‑model stadig være det rigtige. Samtidig vejer økosystem, værktøjer og enterprise‑integrationer ofte tungere end et par procentpoint på et leaderboard. Man vælger sjældent kun efter én søjle i et skema.
Anbefalinger til CIO’er og BI‑teams
Tre første skridt virker igen og igen: 1) Et fokuseret proof‑of‑concept på fem til ti forretningsspørgsmål, der rammer både simple og moderate mønstre i jeres data. 2) Et valideringsworkflow med gold‑spørgsmål, auto‑tests og manuel godkendelse for alt nyt. 3) Mål EX internt over tid — ikke kun end‑to‑end, men pr. domæne og pr. skemahotspot.
Byg en lille prompt‑pakke, der standardiserer stil, alias‑regler og sikkerhedsrammer, og versionsstyr både prompts og tests. Estimér ROI nøgternt: sparede timer på SQL‑udkast minus tid på review og tests, plus cloudomkostninger og eventuelle fejlomkostninger. Hvis tallet er grønt i read‑only, kan man rulle stille videre.
Hvilke fakta mangler stadig
Nogle kerneoplysninger mangler for at vurdere modenheden præcist: direkte permalink og fuld tekst til Google Researchs X‑post (inkl. tidsstempel og evt. rettelser), et officielt snapshot af BIRD‑leaderboardet på annonceringsdagen for at undgå aflæsningsstøj, samt detaljer om prompting, kontekstvindue og evt. retrieval i praksis, selvom tracket begrænser det i målingen.
Derudover savnes hårde tal for latens og pris pr. query i BigQuery‑ og AlloyDB‑scenarier, samt uafhængige reproduktioner på tredjepartsdatasæt — især i domæner med beskidte værdier og behov for ekstern grounding. Indtil da bør implementeringer planlægges som kontrollerede forløb, ikke big‑bang‑udrulninger. Bedre kedeligt sikkert end smart og dyrt.
Bundlinjen
Det afgøres i hænderne. Tegn små linjer i sandet, prøv det på egne skemaer, og mål fejl og forbedringer over uger — ikke dage. Forskellen mærkes først, når man trykker kør.
