💻 computer science

Rose-SQL: Role-State Evolution Guided Structured Reasoning for Multi-Turn Text-to-SQL

Rose-SQL ist ein trainingsfreies Framework, das kleine Large Reasoning Models mit einer neuartigen Role-State-Repräsentation nutzt, um strukturiertes Schlussfolgern zu steuern und konversationelle Abhängigkeiten in Multi-Turn-Text-to-SQL-Aufgaben präzise aufzulösen, wobei es sowohl In-Context-Learning-Baselines als auch state-of-the-art feinabgestimmte Modelle auf Standard-Benchmarks übertrifft.

Ursprüngliche Autoren: Le Zhou, Feng Yao, Fengcai Qiao, Bo Xu, Fangyuan Wang, Boyan Xu

Veröffentlicht 2026-05-06

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Le Zhou, Feng Yao, Fengcai Qiao, Bo Xu, Fangyuan Wang, Boyan Xu

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 versuchen, einem sehr klugen, aber leicht unerfahrenen Assistenten beizubringen, wie man eine Datenbank nach Informationen fragt. Die Datenbank ist wie eine riesige Bibliothek mit Millionen von Büchern (Tabellen) und spezifischen Ablagesystemen (Schemata). Ihr Ziel ist es, ein natürliches Gespräch in einen präzisen Befehl (SQL) zu übersetzen, den die Bibliothek verstehen kann.

Die Arbeit stellt Rose-SQL vor, eine neue Methode, um diesen „kleinen" KI-Assistenten zu helfen, die Aufgabe zu erledigen, ohne zur Schule gehen zu müssen (Feinabstimmung) oder sich auf teure, riesige KI-Modelle zu verlassen.

So funktioniert Rose-SQL, aufgeschlüsselt in einfache Konzepte und Analogien:

1. Das Problem: Das „in der Übersetzung verlorene" Gespräch

Im echten Leben sind Gespräche nicht nur einmalige Fragen. Sie fragen: „Wer hat das Spiel gewonnen?" und fragen dann nach: „Wie war ihr Ergebnis?" Die KI muss sich an die erste Frage erinnern, um die zweite zu beantworten.

Das Problem: Kleine KI-Modelle geraten oft in Verwirrung. Sie könnten den Kontext vergessen, die Regeln durcheinanderbringen oder Teile der Antwort halluzinieren (erfinden), weil sie versuchen, den endgültigen Befehl direkt aus dem Gespräch zu erraten.
Der alte Weg: Forscher versuchten normalerweise entweder, massive, teure KI-Modelle einzusetzen (wie einen Super-Genie, der alles weiß) oder die kleinen Modelle dazu zu zwingen, Tausende von Beispielen auswendig zu lernen (Feinabstimmung), was langsam und kostspielig ist.

2. Die Lösung: Der „Bauplan" (Rollen-Zustand)

Rose-SQL führt einen cleveren Mittelsmann namens Rollen-Zustand ein.

Die Analogie: Stellen Sie sich vor, Sie sind ein Architekt. Anstatt das Bauteam zu bitten, „ein Haus zu bauen" (was vage ist), zeichnen Sie zuerst einen Bauplan.
Wie es funktioniert: Bevor die KI den endgültigen SQL-Code schreibt, füllt sie zunächst eine einfache Checkliste (den Rollen-Zustand) aus. Diese Checkliste fragt: „Müssen wir Spalten auswählen? Müssen wir Tabellen verbinden? Müssen wir nach einer Bedingung filtern?"
Der Vorteil: Dies verwandelt ein komplexes, chaotisches Gespräch in eine strukturierte, 10-Schritte-Checkliste. Es zwingt die KI, innezuhalten und über die Struktur der Antwort nachzudenken, bevor sie den eigentlichen Code schreibt. Es ist wie das Überprüfen Ihrer Packliste, bevor Sie den Koffer zuknöpfen.

3. Die Strategie: „Aus der Vergangenheit lernen" (Evolutionäre Trajektorien)

Gespräche ändern sich. Manchmal fügen Sie einen neuen Filter hinzu; manchmal entfernen Sie eine Bedingung. Rose-SQL rät nicht einfach; es sucht nach Mustern in der Entwicklung des Gesprächs.

Die Analogie: Denken Sie daran wie an einen Detektiv, der einen Fallordner durchsucht. Wenn die aktuelle Frage einer früheren in den Trainingsdaten ähnelt, prüft die KI: „Wie haben wir das gelöst?"
Der „Isomorphie-Check": Das System vergleicht den „Bauplan" der aktuellen Frage mit dem „Bauplan" vergangener Fragen. Wenn die strukturellen Änderungen übereinstimmen (z. B. „Im letzten Schritt haben wir einen Filter hinzugefügt"), nutzt es diesen früheren Erfolg als Leitfaden.
Das Ergebnis: Es filtert das „Rauschen" (irrelevante Teile des Chats) heraus und behält nur die logischen Schritte, die tatsächlich wichtig sind. Es ist wie ein GPS, das sagt: „Wir sind letztes Mal links abgebogen, um Staus zu vermeiden; machen wir es wieder so", anstatt einfach zufällig zu fahren.

4. Der Prozess: Ein Dreischritt-Tanz

Rose-SQL führt die KI durch drei spezifische Phasen:

Abhängigkeitsanalyse: Die KI fragt: „Braucht diese neue Frage wirklich die alten Fragen, um Sinn zu ergeben, oder ist es ein neues Thema?" Sie trennt nützliche Geschichte von Gesprächsgeplänkel.
Suche nach evolutionären Trajektorien: Sie findet eine „Zwillings"-Konversation aus ihren Trainingsdaten, die sich auf die gleiche Weise entwickelt hat, und prüft, ob der strukturelle Bauplan übereinstimmt.
Erweiterte hierarchische Schlussfolgerung: Schließlich kombiniert sie den Bauplan, die Geschichte und die Datenbankregeln, um den SQL-Code zu schreiben. Sie baut die Antwort Schritt für Schritt auf: Zuerst der Plan (Bauplan), dann der Code.

5. Die Ergebnisse: Kleine Modelle, große Erfolge

Die Arbeit testete dies an Standard-Benchmarks (SParC und CoSQL).

Die Überraschung: Sie verwendeten kleine KI-Modelle (4 bis 14 Milliarden Parameter), die nicht neu trainiert oder feinabgestimmt wurden.
Das Ergebnis: Durch die Verwendung dieser „Bauplan- und Mustererkennung"-Methode schnitten diese kleinen Modelle besser ab als viel größere, feinabgestimmte Modelle.
Die Erkenntnis: Man braucht nicht immer ein größeres Gehirn; man braucht nur eine bessere Art, seine Gedanken zu organisieren. Rose-SQL gibt kleinen Modellen eine strukturierte Denkweise, die es ihnen ermöglicht, über ihre Gewichtsklasse hinaus zu performen.

Zusammenfassung

Rose-SQL ist wie das Geben einer strukturierten Checkliste und eines Referenzhandbuchs früher erfolgreicher Projekte an einen Junior-Mitarbeiter, bevor er eine komplexe Aufgabe beginnt. Anstatt die endgültige Antwort zu erraten, plant er zuerst die Struktur, prüft, ob sein Plan mit der Lösung ähnlicher Probleme in der Vergangenheit übereinstimmt, und führt sie dann aus. Dies ermöglicht es kleinen, effizienten KI-Modellen, komplexe, mehrstufige Gespräche mit hoher Genauigkeit zu bewältigen, ohne teures Training zu benötigen.

Technische Zusammenfassung: Rose-SQL

Problemstellung

Multi-Turn Text-to-SQL ist eine grundlegende semantische Parsing-Aufgabe, bei der Modelle natürliche Sprachdialoge in ausführbare SQL-Abfragen über ein Datenbankschema übersetzen müssen. Während Large Reasoning Models (LRMs), die mit Long Chain-of-Thought (CoT) trainiert wurden, vielversprechende Ergebnisse in der Code-Generierung und mathematischen Schlussfolgerung zeigen, bleibt ihre Anwendung auf Multi-Turn Text-to-SQL noch wenig erforscht. Bestehende Ansätze stehen vor einer Dichotomie:

In-Context Learning (ICL) mit großen proprietären Modellen: Methoden wie ACT-SQL und CoE-SQL verlassen sich auf teure APIs (z. B. GPT-3.5) und sind empfindlich gegenüber der Qualität von Prompts, wobei sie häufig Schwierigkeiten mit verrauschtem oder mehrdeutigem historischem Kontext haben.
Feinabgestimmte kleine Modelle: Ansätze wie Track-SQL und RASAT nutzen aufgabenspezifisches Fine-Tuning und spezialisierte Architekturen (z. B. Graphstrukturen), um Kontext zu verarbeiten. Diese Methoden sind jedoch trainingintensiv, teuer in der Anpassung und erfordern oft zusätzliche Module für Schema-Linking oder Intent-Tracking.

Die Kernherausforderung besteht darin, kleine, Open-Source-LRMs in die Lage zu versetzen, effektive Multi-Turn-Schlussfolgerungen ausschließlich durch In-Context Learning durchzuführen. Diese Modelle verfügen häufig nicht über die induktiven Verzerrungen, um sich entwickelnde Dialogkontexte zu bewältigen, was zu Fehlinterpretationen von Kontextabhängigkeiten und zum Scheitern bei der Erfassung zusammengesetzter Abfragebedeutungen führt.

Methodik: Rose-SQL

Rose-SQL ist ein trainingfreies Framework, das entwickelt wurde, um kleine LRMs für kontextabhängiges Parsing ohne aufgabenspezifisches Fine-Tuning anzupassen. Es nutzt In-Context Learning durch einen strukturierten, dreiphasigen Schlussfolgerungsprozess, der sich auf eine neuartige Zwischenrepräsentation namens Role-State konzentriert.

1. Role-State: Ein struktureller Bauplan

Um die Lücke zwischen Schema-Linking und SQL-Generierung zu schließen, führt Rose-SQL Role-State ein, eine feingranulare Darstellung, die semantische Absicht von syntaktischer Ausführung entkoppelt.

Definition: Role-State ist ein 10-dimensionaler binärer Indikatorvektor ( $v \in \{0, 1\}^{10}$ ), der natürliche Spracheinheiten explizit auf funktionale SQL-Rollen abbildet: select, join, condition, group, order, union, except, intersect, in und not in.
Funktion: Er dient als struktureller Bauplan und ermöglicht dem Modell, die strukturelle Konsistenz über Dialogwechsel hinweg durch Isomorphieprüfungen zu verifizieren. Diese digitalisierte Form bietet eine berechenbare Grundlage für den Vergleich historischer Übergänge mit der aktuellen Interaktion.

2. Dreiphasiger Schlussfolgerungsrahmen

Rose-SQL arbeitet durch drei synergistische Phasen, um Dialogdynamiken zu verwalten:

Phase 1: Gain Dependency Analysis (GDA)
Diese Phase quantifiziert den kontextuellen Einfluss historischer Äußerungen, um substanzielle Informationsgewinne von konversationellem Rauschen zu unterscheiden.
- Fragen werden unter Verwendung des M-Schemas umformuliert, um die Kontextabhängigkeit zu reduzieren.
- Dependency Strength ( $S_i$ ): Gemessen durch normalisierte Perplexitätsreduktion, um zu bestimmen, wie sehr ein historischer Wechsel der aktuellen Frage hilft.
- Dependency Distance ( $D_i$ ): Weist Gewichte basierend auf der zeitlichen Nähe zu.
- Der finale Gain Dependency Score (GDS) filtert Kandidaten für strukturelle Analogie.
Phase 2: Evolutionary Trajectory Searching
Diese Phase identifiziert historische Interaktionsmuster, die sowohl semantisch relevant als auch strukturell analog zum aktuellen Dialog sind.
- Das System ruft Kandidaten-Trainingsdialoge mit kompatiblen Schemaskalen und Abhängigkeitsprofilen ab.
- Es lokalisiert den semantisch ähnlichsten historischen Wechsel und seine stärkste Abhängigkeit.
- Isomorphie-Check: Ein Kandidatenübergang wird nur beibehalten, wenn die digitalisierte Role-State des historischen Ankers isomorph zu der des aktuellen kontextuellen Ankers ist. Dies stellt sicher, dass die abgerufene Trajektorie eine logisch gültige Referenz für die aktuelle SQL-Zusammensetzung darstellt.
Phase 3: Augmented Hierarchical Reasoning
Das Modell wird angeleitet, SQL durch einen stabilisierten Deduktionsprozess zu generieren, anstatt eine direkte Generierung durchzuführen.
- Eingaben: Der Prompt enthält die Aufgabenanweisung, das Datenbankschema, die aktuelle Frage, Contextual Anchors (Fokus auf relevante Historie), Verified Evolutionary Trajectories (Bereitstellung struktureller Anleitung) und Role Knowledge Injection (atomare Exemplare von SQL-Rollen).
- Prozess: Das Modell leitet zunächst den intermediären strukturellen Plan und Role-State ab und generiert dann die finale ausführbare SQL. Dieser hierarchische Ansatz verringert die strukturelle Lücke zwischen semantischem Verständnis und SQL-Realisierung.

Hauptbeiträge

Rose-SQL-Framework: Ein trainingfreies Paradigma, das den Role-State-Mechanismus nutzt, um semantische Abbildung von syntaktischer Generierung zu entkoppeln und ein strukturiertes intermediäres Ziel für kleine LRMs bereitzustellen.
Evolutionary Guidance Strategy: Ein neuartiger Ansatz, der Gain Dependency Analysis mit strukturellen Isomorphieprüfungen integriert. Dies mindert kontextuelles Rauschen, indem die logische Konsistenz der Dialogentwicklung zur Inferenz der möglichen SQL-Zusammensetzung verifiziert wird.
Augmented Hierarchical Reasoning: Ein Paradigma, das den Deduktionsprozess durch verifizierte Trajektorien und kontextuelle Anker stabilisiert und State-of-the-Art-Leistung ohne Fine-Tuning erreicht.

Experimentelle Ergebnisse

Experimente wurden auf den Benchmarks SParC und CoSQL mit der Qwen3-Serie (4B, 8B, 14B Parameter) und zusätzlichen Backbones (DeepSeek-R1-Distill-Llama-8B, gpt-oss-20b) durchgeführt.

Leistungssteigerungen: Rose-SQL übertrifft In-Context-Learning-Baselines signifikant. Innerhalb der Qwen3-Serie erreicht das 4B-Modell mit Rose-SQL eine Leistung, die mit der 8B-Baseline gleichzieht. Die 8B- und 14B-Modelle übertreffen auf beiden Benchmarks erheblich state-of-the-art feinabgestimmte Modelle (z. B. Track-SQL).
- Auf SParC (Dev) erreicht Rose-SQL (8B) 78,72% Interaction Match (IM) und 62,56% Execution Accuracy (EX) und übertrifft damit das feinabgestimmte Track-SQL (IM: 75,39%, EX: 57,81%).
Robustheit: Das Framework zeigt konsistente Gewinne über verschiedene Modellskalen und Schlussfolgerungs-Backbones hinweg, was darauf hindeutet, dass die strukturelle Anleitung übertragbar ist und nicht von einer spezifischen Modellfamilie abhängt.
Ablationsstudien:
- Role-State: Führt ein strukturelles intermediäres Ziel ein und verbessert signifikant metrikbasierte Ergebnisse (EX, TS).
- Role Knowledge Injection: Verbessert die Exact-Match (EM)-Scores durch Bereitstellung atomarer rollenspezifischer Priors.
- Evolutionary Trajectories & Contextual Anchors: Entscheidend für die Modellierung der Dialogentwicklung und das Filtern historischen Rauschens, was die konsistenz über mehrere Turns hinweg verbessert.
- Trajectory Quantity: Optimale Leistung wird mit einer kontrollierten Anzahl von Trajektorien erreicht (N=2 für SParC, N=1 für CoSQL); zu viele führen zu Mehrdeutigkeiten.

Bedeutung und Behauptungen

Die Arbeit behauptet, dass Rose-SQL die strukturelle Fehlausrichtung und das kontextuelle Rauschen, die Multi-Turn Text-to-SQL-Aufgaben inhärent sind, ohne die Kosten eines Fine-Tunings adressiert. Durch die Einführung von Role-State als expliziten strukturellen Raum ermöglicht das Framework kleinen Schlussfolgerungsmodellen, über verifizierbare strukturelle Übergänge zu reasoning, anstatt sich ausschließlich auf rohe konversationelle Historie zu verlassen.

Die Autoren behaupten, dass Rose-SQL einen stabileren Weg von der mehrstufigen natürlichen Sprachabsicht zur Generierung ausführbarer SQL bietet. Die Ergebnisse deuten darauf hin, dass die Wirksamkeit des Frameworks auf seinem strukturellen Leitmechanismus beruht und nicht auf bloßer Modellskalierung, was es kleinen Open-Source-Modellen ermöglicht, mit größeren, feinabgestimmten oder proprietären Modellen zu konkurrieren oder diese zu übertreffen.

Limitationen: Die Autoren erkennen drei Einschränkungen an: (1) Strukturelle Retrieval-Spärlichkeit für seltene Dialogmuster; (2) Role-State-Ausdrucksfähigkeit, die möglicherweise komplexe Open-Domain-SQL-Strukturen nicht vollständig abdeckt; und (3) Inferenz-Overhead aufgrund der durch abgerufene Trajektorien erhöhten Prompt-Länge. Zukünftige Arbeiten zielen darauf ab, die spärliche Suche zu adressieren und die Schlussfolgerungseffizienz zu verbessern.