> 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/why-nl2sql-is-hard.md). # Warum NL2SQL schwierig ist Trotz erheblicher Forschungsfortschritte bleibt NL2SQL in der Praxis ein herausforderndes Problem. Die Schwierigkeit nimmt deutlich zu, wenn man von akademischen Benchmarks (die typischerweise saubere, kleine Schemata mit eindeutigen Fragen verwenden) zu produktiven Datenbanken aus der realen Welt wechselt. Was Nutzer in der Benutzeroberfläche einer Anwendung sehen, im Gegensatz dazu, wie die Anwendung intern in der Datenbank aussieht, sind oft zwei Paar Schuhe.\ Je unterschiedlicher diese beiden Paar Schuhe sind, desto schwieriger ist es, eine Anfrage, die auf den Annahmen einer Struktur basiert, mit der anderen zusammenzuführen.
### **Schemaskomplexität** Datenbanken aus der Praxis haben Dutzende von Tabellen mit nicht offensichtlichen Namenskonventionen, impliziten Beziehungen und domänenspezifischer Semantik. Spaltennamen können abgekürzt, mehrfach verwendet oder nur im Kontext sinnvoll sein. Fremdschlüsselbeziehungen können implizit statt deklariert sein. Domänenspezifische Erweiterungen (z. B. TimescaleDB-Hyperfunktionen für Zeitreihendaten) fügen Syntax hinzu, auf die Allzweckmodelle im Training nur selten treffen. ### Mehrdeutigkeit Nutzerfragen sind von Natur aus mehrdeutig. "Zeig mir den Energieverbrauch" könnte sich auf aktuelle Messwerte, historische Aggregationen oder einen Vergleich über Standorte hinweg beziehen. Es spezifiziert nicht, welche Anlagen Energie messen, welche Einheit verwendet werden soll oder welchen Zeitraum man berücksichtigen sollte. Diese Mehrdeutigkeit aufzulösen erfordert Fachwissen, das über das Datenbankschema hinausgeht. ### **Korrektheit vs. Plausibilität** Eine generierte Abfrage kann syntaktisch gültiges SQL sein und dennoch falsche Daten zurückgeben. Sie könnte den falschen Schlüssel für den Join verwenden, eine falsche Aggregation anwenden, die falsche Tabelle abfragen oder einen notwendigen Filter auslassen. Der gefährlichste Fehlerfall ist eine Abfrage, die erfolgreich ausgeführt wird und plausibel aussehende, aber falsche Ergebnisse liefert. Das zu erkennen erfordert zu verstehen, wie das richtige Ergebnis aussehen sollte – und genau das weiß der Nutzer nicht (sonst würde er nicht fragen). ### **Schwierigkeit der Bewertung** Die Messung der NL2SQL-Qualität ist nicht trivial. Eine generierte Abfrage, die sich syntaktisch von einer Referenzabfrage unterscheidet, kann dennoch semantisch korrekt sein (z. B. andere Join-Reihenfolge, äquivalente Unterabfrage statt CTE). Umgekehrt können zwei Abfragen, die auf einem kleinen Testdatensatz dasselbe Ergebnis liefern, auf Produktivdaten auseinanderlaufen. ## Die Herausforderung flexibler Datenmodelle Standard-NL2SQL-Benchmarks (also Spider, BIRD) gehen von einem festen, bekannten Schema aus.\ Das Modell lernt, SQL für einen bestimmten Satz von Tabellen und Spalten zu erzeugen. Viele Plattformen aus der realen Welt, insbesondere in IoT- und Smart-Building-Domänen, haben in diesem Sinne kein einziges festes Schema. Sie haben ein **relationales Schema** (die Datenbanktabellen selbst) plus ein **projektspezifisches Datenmodell** definiert durch den Inhalt dieser Tabellen. Assets, ihre Typen, ihre Attribute, ihre hierarchischen Beziehungen und ihre Telemetriestrukturen werden alle pro Mandant und dessen Portfolio konfiguriert. Das bedeutet, dass ein NL2SQL-System zwei Ebenen verstehen muss: 1. **Das relationale Schema**: welche Tabellen existieren, ihre Spalten, Datentypen, Join-Beziehungen und eventuelle Datenbankerweiterungen (z. B. JSON-Felder, spezielle Funktionalität). 2. **Das Datenmodell auf Instanzebene**: welche Asset-Typen konfiguriert sind, welche Attribute sie definieren, wie Assets hierarchisch organisiert sind und welche Telemetriedaten tatsächlich verfügbar sind. All das variiert zwischen Projekten. Ein Modell, das das relationale Schema perfekt gelernt hat, kann dennoch scheitern, wenn es nicht weiß, dass "energy usage" einem Attribut namens "energy" auf Assets vom Typ "EMeter" mit dem Untertyp "input" entspricht – Informationen, die in den Daten liegen, nicht in der Schemadefinition. ### Zwei Arten von Mehrdeutigkeit Diese zweischichtige Struktur führt zu zwei unterschiedlichen Arten von Mehrdeutigkeit: #### **Abfrage-Mehrdeutigkeit** Die Frage des Nutzers selbst ist unzureichend spezifiziert: * "Zeig mir Daten für das Gebäude" – welches Gebäude? Welche Daten? * "Gibt es Anomalien?" – was gilt als Anomalie? Welche Assets? Welcher Zeitraum? #### **Daten-Mehrdeutigkeit** Die Datenbank enthält mehrere gültige Interpretationen: * Mehrere Gebäude mit demselben Namen an unterschiedlichen Standorten * Mehrere Asset-Typen, die dieselbe physikalische Größe messen können (z. B. können sowohl ein dedizierter Temperatursensor als auch ein Raumregler Temperatur erfassen) * Hierarchische Beziehungen, bei denen der "richtige" Geltungsbereich vom Kontext abhängt (z. B. Energiezähler, die drei Ebenen unter dem vom Nutzer genannten Gebäude liegen) Die Mehrdeutigkeit der Anfrage aufzulösen erfordert das Verständnis der Absicht des Nutzers. Die Mehrdeutigkeit der Daten aufzulösen erfordert das Verständnis des Datenmodells des Projekts. Ein reines NL2SQL-Modell kann, egal wie gut es trainiert ist, nur das erste Problem lösen, wenn ihm das zweite als Kontext gegeben wurde. --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.buildings.ability.abb/collection/german/akademie/building-intelligence-ai-and-machine-learning-in-buildingpro-suites/agents/nl2sql/why-nl2sql-is-hard.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.