Agentisches NL2SQL

Die beschriebenen Einschränkungen zuvor begründen einen agentischen Ansatz für NL2SQL: Anstatt Natural-Language-zu-SQL als ein einstufiges Übersetzungsproblem zu behandeln, wird es in einen mehrstufigen Workflow zerlegt, in dem verschiedene Komponenten unterschiedliche Aspekte der Aufgabe bearbeiten.

Der Copilot Assistant Data Agent ist die produktive Umsetzung dieses Musters für die Daten von BuildingPro Suites.

Warum eine Subagent-Architektur

In einem agentischen NL2SQL-System wird der Schritt der SQL-Generierung in einen dedizierten Subagenten. Dieser Subagent erhält eine vollständig abgegrenzte, unmissverständliche Anfrage und generiert dafür SQL. Er übernimmt nicht:

• Zu interpretieren, was der Nutzer mit „dem Gebäude“ meinte

• Zu bestimmen, welche Asset-Typen „Energie“ messen

• Zu entscheiden, ob aktuelle oder historische Daten abgefragt werden sollen

• Sich von falschen Ergebnissen zu erholen oder um Klärung zu bitten

Diese Aufgaben gehören dem orchestrierenden Agenten , der spezialisierte Tools verwendet, um Konzepte gegen das aktuelle Datenmodell aufzulösen, bevor er an den SQL-Subagenten delegiert.

Diese Trennung hat mehrere Vorteile:

• Fokussiertes Training: Der SQL-Subagent kann ausschließlich auf die Qualität der SQL-Generierung für ein bekanntes Schema optimiert werden, ohne Gesprächsführung, Mehrdeutigkeit oder Fehlerbehandlung abdecken zu müssen.

• Zustandslose Ausführung: Der SQL-Subagent arbeitet zustandslos – er erhält eine Anfrage, generiert und führt eine Abfrage aus und gibt die Ergebnisse zurück. Kein Gesprächsverlauf, kein mehrstufiges Schlussfolgern.

• Unabhängige Weiterentwicklung: Das SQL-Modell kann neu trainiert oder ausgetauscht werden, ohne den Orchestrator zu ändern. Der Prompt des Orchestrators kann aktualisiert werden, ohne das SQL-Modell neu zu trainieren.

Konzeptauflösung als semantische Schicht

Die entscheidende Erkenntnis hinter agentischem NL2SQL ist, dass die Lücke zwischen der Frage eines Nutzers und einer korrekten SQL-Abfrage nicht in erster Linie eine Sprach-zu-SQL-Übersetzung Lücke ist. Es ist eine Konzeptauflösung Lücke.

Betrachten Sie die Frage: „Wie hoch ist der Energieverbrauch in Gebäude A?“

Um korrektes SQL zu erzeugen, muss das System wissen:

• Welche Datenbankentität „Gebäude A“ repräsentiert (z. B. das konkrete Asset, das es darstellt)

• Welche Asset-Typen unter Gebäude A Energiedaten erfassen (z. B. Zähler, Unterzähler)

• Welcher Attributname und welcher Typ im Schema zu „energy consumption“ passen (z. B. Attribut „energy“, attribute_type „energy“, subtype „input“)

• Ob sich „energy consumption“ auf aktuelle Daten (Heap-Tabelle) oder historische Daten (Trend-Tabelle) bezieht, was davon abhängt, ob der Nutzer nach „jetzt“ oder nach einem Zeitraum fragt

• In welcher Einheit die Daten gespeichert sind

Der orchestrierende Agent verwendet spezialisierte Auflösungstools zur Überbrückung dieser Lücke, bevor SQL generiert wird.

Zwei Arten von Mehrdeutigkeit Erneut betrachtet

Der vorheriges Kapitel führte Abfrage-Mehrdeutigkeit und Datenmehrdeutigkeit ein. Der agentische Ansatz behandelt sie in unterschiedlichen Phasen:

Abfrage-Mehrdeutigkeit wird vom orchestrierenden Agenten durch toolbasierte Konzeptauflösung und, wenn nötig, durch Rückfragen an den Nutzer aufgelöst. Es muss also nicht geraten werden.

Datenmehrdeutigkeit wird von den Auflösungstools sichtbar gemacht und durch Hierarchieprüfung, Prüfung der Datenverfügbarkeit und Präzisierung des Umfangs aufgelöst. Wenn nach der automatischen Auflösung mehrere gültige Interpretationen übrig bleiben, präsentiert der Agent konkrete Optionen mit Namen und Kennungen, damit der Nutzer präzise wählen kann.