💬 NLP

Spider 2.0-AIFunc: Extending Real-World Text-to-SQL to AI-Native SQL Workflows

Dieses Papier stellt Spider 2.0-AIFunc vor, einen neuen Benchmark mit 465 verifizierten Instanzen über 125 reale Datenbanken hinweg, der darauf ausgelegt ist, die Fähigkeit großer Sprachmodelle zur Generierung von KI-nativen SQL-Abfragen auf der Snowflake-Plattform zu bewerten, wobei aufgezeigt wird, dass während führende proprietäre Modelle eine Genauigkeit von 67–70 % erreichen, aktuelle Agent-Frameworks, die für traditionelle Text-zu-SQL-Aufgaben optimiert sind, nicht effektiv auf dieses aufkommende Szenario übertragbar sind.

Ursprüngliche Autoren: Tianyang Liu, Canwen Xu, Fangyu Lei, Nikki Lijing Kuang, Jixuan Chen, Tao Yu, Julian McAuley, Zhewei Yao, Yuxiong He

Veröffentlicht 2026-07-08

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Tianyang Liu, Canwen Xu, Fangyu Lei, Nikki Lijing Kuang, Jixuan Chen, Tao Yu, Julian McAuley, Zhewei Yao, Yuxiong He

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie hätten eine riesige, hochtechnologische Bibliothek (eine Cloud-Datenbank), in der Menschen alles Mögliche speichern, von Kundenbewertungen bis hin zu Verkaufsdatensätzen. Jahrelang erforderte das Abfragen dieser Bibliothek eine sehr strikte, roboterhafte Sprache namens SQL. Es war, als würde man in einem Restaurant ein komplexes Gericht bestellen, indem man ausschließlich in einem Code aus Zahlen und Symbolen spricht.

Vor kurzem haben die Besitzer der Bibliothek (wie etwa Snowflake) eine neue Funktion hinzugefügt: AI-Funktionen. Denken Sie an diese als „intelligente Assistenten“, die direkt in das Bestellsystem eingebaut sind. Jetzt können Sie, anstatt nur nach „allen roten Äpfeln“ zu fragen, das System bitten: „Lies die Bewertungen dieser Äpfel und sag mir, ob die Leute glücklich oder wütend sind“, oder „Finde Bewertungen, die dieser einen Bewertung ähnlich sind“. Dies verwandelt die Datenbank in ein AI-natives System, bei dem Sie Standard-Datenbefehle mit intelligentem, sprachbasiertem Denken in einem einzigen Satz kombinieren können.

Das Problem: Die alte Karte funktioniert nicht mehr

Die Forscher stellten fest, dass diese neuen „intelligenten Assistenten“ zwar leistungsstark sind, die Tests, die zur Ausbildung und Überprüfung von Computergehirnen (KI-Modellen) verwendet werden, jedoch veraltet sind. Die alten Tests prüften nur, ob der Computer die strikte, roboterhafte Sprache sprechen konnte. Sie prüften nicht, ob der Computer diese neuen „intelligenten Assistenten“ auch nutzen kann. Es war, als würde man einen Fahrer nur auf einer geraden, leeren Straße testen, während die reale Welt nun durch Verkehr, Fußgänger und Baustellen geprägt ist.

Die Lösung: Spider 2.0-AIFunc

Um dies zu beheben, entwickelte das Team einen neuen, härteren Fahrtest namens Spider 2.0-AIFunc.

Die Transformation: Sie nahmen 513 bestehende „Fahrtests“ (Fragen zu Daten) und schrieben diese um. Sie zwangen die Fragen dazu, die neuen „intelligenten Assistenten“ zu benötigen.
- Alte Frage: „Zeige mir alle negativen Bewertungen.“ (Erfordert, dass ein Mensch sie zuerst liest).
- Neue Frage: „Zeige mir alle Bewertungen, bei denen der KI-Assistent sagt, dass die Stimmung negativ ist.“ (Die KI erledigt das Lesen innerhalb der Datenbank).
Die Baucrew: Sie setzten ein Team von KI-Agenten (digitalen Arbeitern) ein, um diese Fragen umzuschreiben. Diese Agenten fungierten als Editoren und Mechaniker:
- Sie prüften, ob die Anweisungen klar waren (z. B. „Was genau meinst du mit ‚negativ‘?“).
- Sie stellten sicher, dass der „intelligente Assistent“ über alle richtigen Werkzeuge (Parameter) verfügte, um die Aufgabe zu erledigen.
- Sie ließen die Tests immer wieder durchlaufen, um sicherzustellen, dass die Antworten stabil sind und sich nicht ändern, nur weil der KI-Assistent einen schlechten Tag hat.
Die Abschlussprüfung: Das Ergebnis ist ein Benchmark aus 465 verifizierten Fragen über 125 verschiedene Datenbanken hinweg. Er deckt sechs Arten von Aufgaben für „intelligente Assistenten“ ab, wie etwa das Sortieren von Bewertungen nach Emotionen, das Finden ähnlicher Texte oder das Extrahieren spezifischer Details aus einem Absatz.

Die Ergebnisse: Wer hat den Test bestanden?

Die Forscher ließen 10 verschiedene KI-Modelle (die „Fahrer“) diese neue Prüfung absolvieren, um zu sehen, wie gut sie diese komplexen, KI-gestützten Abfragen schreiben können.

Die Top-Fahrer (Proprietäre Modelle): Die großen, geschlossenen Modelle (wie Claude Opus und Gemini) schnitten am besten ab. Sie beantworteten etwa 67 % bis 70 % der Antworten korrekt. Sie waren gut darin, herauszufinden, welchen „intelligenten Assistenten“ sie nutzen und wie sie die richtige Frage an ihn stellen müssen.
Die Open-Source-Fahrer: Die besten Open-Source-Modelle (wie Kimi K2.5) erreichten etwa 58 %. Sie waren ordentlich, machten aber mehr Fehler.
Die Lücke: Der Hauptgrund, warum die Open-Source-Modelle Schwierigkeiten hatten, war nicht, dass sie den grundlegenden Code nicht schreiben konnten. Sie stolperten über die „intelligenten“ Teile:
- Missverständnis der Regeln: Wahl der falschen Tabelle oder Spalte.
- Schlechte Anweisungen: Vergessen, dem KI-Assistenten genau zu sagen, wonach er suchen soll (z. B. nicht alle möglichen Kategorien für eine Klassifizierungsaufgabe aufzulisten).
- Logikfehler: Vertauschen der Reihenfolge der Operationen (z. B. die Daten erst zu filtern, nachdem man den KI-Assistenten gefragt hat, anstatt davor).

Die überraschende Entdeckung: Weniger ist mehr

Die Forscher testeten auch, ob die Verwendung komplexer „Agent-Frameworks“ (aufwendige Toolkits, die der KI helfen, ihre Schritte zu planen) half.

Das Ergebnis: Überraschenderweise halfen die komplexesten Toolkits nicht viel. Tatsächlich funktionierte ein minimales Setup – nur ein einfaches Werkzeug, um in die Datenbank zu schauen, und ein Werkzeug, um die Abfrage auszuführen – genauso gut oder sogar besser als die schicken Frameworks.
Die Metapher: Es ist, als würde man einem Meisterkoch ein winziges, einfaches Messer gegenüber einem massiven, komplizierten Schweizer Taschenmesser geben. Für diese spezielle Art des Kochens (AI-Native SQL) brauchte der Meisterkoch keine zusätzlichen Gadgets; er musste nur wissen, wie man das Messer benutzt. Die komplexen Frameworks, die für klassische Datentasks entwickelt wurden, standen im Weg oder brachten keinen Mehrwert.

Zusammenfassung

Dieses Paper führt einen neuen, realistischen Test für KI-Modelle ein, der prüft, ob sie moderne „KI-gestützte“ Datenbankfunktionen nutzen können. Es stellte fest, dass die besten KI-Modelle zwar bereits gut darin werden, aber dennoch eine Lücke zwischen den Top-Modellen und den Open-Source-Modellen besteht. Der Schlüssel zum Erfolg liegt nicht in der Verwendung komplexerer Planungswerkzeuge, sondern darin, die grundlegenden Anweisungen und Parameter für die KI-Funktionen exakt richtig zu setzen.

Technisches Resümee: Spider 2.0-AIFunc

Problemstellung

Große Cloud-Datenplattformen (z. B. Snowflake, BigQuery, Databricks) haben damit begonnen, LLM-Fähigkeiten als native SQL-Funktionen bereitzustellen. Diese „KI-nativen“ Funktionen ermöglichen es Analysten, semantische Operationen – wie Klassifizierung, Sentiment-Analyse, Ähnlichkeitssuche und Informationsextraktion – direkt innerhalb standardmäßiger SQL-Abfragen durchzuführen. Bestehende Text-to-SQL-Benchmarks (z. B. Spider 1.0, Spider 2.0, BIRD) bewerten jedoch nur konventionelles SQL über strukturierte Daten. Sie liefern kein Signal hinsichtlich der Fähigkeit eines Modells, KI-natives SQL zu generieren, was nicht nur die Konstruktion von Standard-SQL, sondern auch die korrekte Auswahl, Parametrisierung und Integration von KI-Funktionsaufrufen erfordert.

Methodik

Die Autoren führen Spider 2.0-AIFunc ein, einen Benchmark, der darauf ausgelegt ist, Text-to-SQL-Fähigkeiten im Kontext von KI-nativen Workflows zu evaluieren. Die Konstruktions- und Evaluierungsmethodik umfasst drei Kernkomponenten:

1. Benchmark-Konstruktion via Agent-Pipeline

Der Benchmark leitet sich aus 513 Instanzen des Spider2-Snow Datensatzes ab (einem Enterprise-Level-Subset von Spider 2.0, gehostet auf Snowflake). Die Autoren nutzen eine wiederverwendbare, agentenbasierte Pipeline (unter Verwendung von Claude Opus 4.5), um diese traditionellen Aufgaben in KI-native Versionen zu transformieren:

Transformation: Agenten schreiben das Ziel-SQL um, um Snowflake Cortex AI-Funktionen einzubinden, und verfeinern gleichzeitig die natürlichen Sprachinstruktionen, um die beabsichtigte KI-Nutzung explizit zu machen.
Ambiguitätsreduktion: Für Aufgaben mit mehreren gültigen Gold-SQLs werden die Instruktionen dahingehend verfeinert, die exakte KI-Funktion und Parameter zu spezifizieren (z. B. vollständige Klassenlabel-Sets für die Klassifizierung), um eine einzige korrekte Antwort zu gewährleisten.
Zweistufiger Prozess:
- Hauptrunde: Agenten wählen KI-Funktionen frei, was zu einer Verteilung führt, die von AI_CLASSIFY, AI_FILTER und AI_SIMILARITY dominiert wird.
- Diversitätsrunde: Agenten werden angewiesen, unterrepräsentierte Funktionen (AI_SENTIMENT, AI_EXTRACT, AI_AGG) zu priorisieren, um eine breite Abdeckung der sechs unterstützten KI-Funktionstypen sicherzustellen.

2. Determinationsverifizierung

Eine kritische Herausforderung bei der Evaluierung von KI-Funktionen ist die Ausführungsdeterminismus, da LLM-Outputs selbst bei Zero-Temperature geringfügige Inkonsistenzen aufweisen können. Um dies zu adressieren:

Multi-Pass-Verifizierung: Jede Kandidateninstanz durchläuft vier Ausführungspässe (insgesamt $\ge$ 35 Ausführungen). Ein Verifizierungs-Agent repariert Instanzen mit inkonsistenten Ergebnissen, indem er das SQL, die Instruktionen oder die Evaluierungskonfigurationen anpasst.
Temporale Stabilität: Überlebende Instanzen durchlaufen eine abschließende Stabilitätsprüfung, die 30 Ausführungen über drei zeitlich getrennte Zeitfenster umfasst. Instanzen, die über diese Fenster hinweg inkonsistente Ergebnisse liefern, werden verworfen.
Finaler Datensatz: Der Prozess liefert 465 verifizierte Instanzen über 125 reale Datenbanken.

3. Evaluierungsprotokoll

Metrik: Ausführungsgenauigkeit (Execution Accuracy, EX). Im Gegensatz zu traditionellen Benchmarks, bei denen Gold-Ergebnisse vorberechnet und statisch sind, erfordert Spider 2.0-AIFunc, dass sowohl das Gold-SQL ( $S_n$ ) als auch das prädizierte SQL ( $\hat{S}_n$ ) innerhalb desselben Zeitfensters ausgeführt werden, um sicherzustellen, dass sie gegen denselben zugrunde liegenden Modellzustand evaluiert werden.
Vergleichslogik: Die Ergebnisse werden mittels Spalten-Teilmengen-Matching verglichen (Gold-Spalten müssen in den prädizierten Ergebnissen erscheinen; prädizierte Spalten dürfen zusätzliche enthalten).
Frameworks: Modelle werden mit dem Spider-Agent Framework evaluiert, das über einen minimalen Tool-Satz verfügt (Bash für Schema-Exploration, SQL-Ausführung und Aufgabenbeendigung). Das Setup enthält Referenzdokumentationen für Snowflake Cortex AI-Funktionen.

Zentrale Beiträge

Spider 2.0-AIFunc Benchmark: Der erste Benchmark speziell für KI-natives Text-to-SQL, der 465 verifizierte Instanzen, 125 Datenbanken und sechs Arten von KI-Funktionen (Klassifizierung, Filtern, Sentiment, Ähnlichkeit, Extraktion, Aggregation) abdeckt.
Agentenbasierte Konstruktions-Pipeline: Eine neuartige, automatisierte Pipeline, die bestehende Enterprise Text-to-SQL-Aufgaben in KI-native Versionen transformiert und gleichzeitig Instruktionen verfeinert sowie die Ausführungsdeterminismus verifiziert.
Empirische Analyse von KI-nativem SQL: Eine umfassende Evaluierung von 10 State-of-the-Art-Modellen (5 proprietär, 5 Open-Source) und 3 Agent-Frameworks, die spezifische Fehlermodi und die Grenzen traditioneller Text-to-SQL-Strategien in diesem neuen Setting aufzeigt.

Ergebnisse

Die Evaluierung von 10 Modellen auf Spider 2.0-AIFunc liefert die folgenden Erkenntnisse:

Proprietäre vs. Open-Source-Lücke: Proprietäre Modelle übertreffen Open-Source-Modelle signifikant.
- Top-Proprietär: Claude Opus 4.6 (70,3 %), Claude Sonnet 4.6 (69,0 %) und Gemini 3.1 Pro (67,1 %).
- Top-Open-Source: Kimi K2.5 (58,1 %).
- Die Lücke wird primtär durch Fehler in der Prädikatsspezifikation, dem Schema-Grounding und der KI-Funktions-Parametrisierung getrieben.
Ausführungserfolg: Die meisten Modelle erreichen hohe „Exec.“-Raten (90–99 %), was darauf hindeutet, dass sie syntaktisch korrektes KI-natives SQL generieren können, das ohne Fehler läuft. Die Performance-Lücke liegt in der semantischen Korrektheit.
Übertragbarkeit von Agent-Frameworks: Agent-Frameworks, die für traditionelle Text-to-SQL-Herausforderungen entwickelt wurden (z. B. Schema-Retrieval, Tabellenauswahl), übertragen sich nicht effektiv auf KI-natives SQL.
- Komplexe Frameworks (AutoLink, ReFoRCE, DSR-SQL) erreichten das Niveau, konnten aber das minimale Spider-Agent-Setup nicht übertreffen, wenn sie dasselbe Backbone-Modell (Claude Sonnet 4.6) verwendeten.
- Dies deutet darauf hin, dass Strategien für das traditionelle SQL-Scaffolding weniger kritisch sind als die Fähigkeit, präzise semantische Entscheidungen bezüglich der Nutzung von KI-Funktionen zu treffen (z. B. korrekte Parametrisierung, Filterreihenfolge).
Interaktionsverhalten: Open-Source-Modelle benötigen signifikant mehr Interaktionsrunden (19–30 vs. 10–12 bei proprietären Modellen) und mehr SQL-Ausführungsversuche, um ein korrektes Ergebnis zu erreichen, wobei sie oft Probleme beim korrekten Beenden (Termination) haben.

Bedeutung und Behauptungen

Das Paper behauptet, dass Spider 2.0-AIFunc eine notwendige Evolution in der Text-to-SQL-Evaluierung darstellt, die sich von der rein strukturierten Datenmanipulation hin zu KI-nativen Workflows entwickelt, die semantische Operationen direkt in SQL integrieren.

Die Autoren betonen:

Aktuelle Benchmarks sind unzureichend: Bestehende Benchmarks erfassen nicht die Komplexität der Integration von LLM-Fähigkeiten in Enterprise-Datenpipelines.
Determinismus ist entscheidend: Das Verifizierungsprotokoll hebt hervor, dass die Benchmarking von KI-Funktionen aufgrund der inhärenten Nicht-Deterministik von LLM-Outputs, selbst in kontrollierten Umgebungen, rigorose Stabilitätsprüfungen erfordert.
Strategiewechsel: Das Scheitern komplexer Agent-Frameworks, die Leistung minimaler Setups zu übertreffen, legt nahe, dass der primäre Flaschenhals bei KI-nativem SQL nicht das Schema-Retrieval oder die Dekomposition ist, sondern die präzise Spezifikation und Parametrisierung von KI-Funktionen. Mit fortschreitender Verbesserung der Modelle nimmt der Wert aufwendiger Scaffolds für traditionelle SQL-Komponenten im Vergleich zur Notwendigkeit einer präzisen semantischen Funktionsaufrufs ab.

Die Arbeit dient als grundlegender Schritt zur Evaluierung und Verbesserung von Modellen, die in der Lage sind, „KI-native“ Datenanalyse-Workflows aufzubauen – eine Fähigkeit, die von Enterprise-Datenplattformen zunehmend gefordert wird.