> For the complete documentation index, see [llms.txt](https://docs.buildings.ability.abb/collection/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.buildings.ability.abb/collection/german/akademie/building-intelligence-ai-and-machine-learning-in-buildingpro-suites/agents/nl2sql/agentic-nl2sql.md). # Agentisches NL2SQL Die beschriebenen Einschränkungen [zuvor](/collection/german/akademie/building-intelligence-ai-and-machine-learning-in-buildingpro-suites/agents/nl2sql/why-nl2sql-is-hard.md) 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 ](/collection/german/copilot-assistent/agent-modes/data-agent.md)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](/collection/german/akademie/building-intelligence-ai-and-machine-learning-in-buildingpro-suites/agents/nl2sql/why-nl2sql-is-hard.md#two-types-of-ambiguity) Erneut betrachtet Der [vorheriges Kapitel](/collection/german/akademie/building-intelligence-ai-and-machine-learning-in-buildingpro-suites/agents/nl2sql/why-nl2sql-is-hard.md) 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.buildings.ability.abb/collection/german/akademie/building-intelligence-ai-and-machine-learning-in-buildingpro-suites/agents/nl2sql/agentic-nl2sql.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.