> 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-ki-und-maschinelles-lernen-in-buildingpro-suites/agenten/nl2sql/warum-nl2sql-schwierig-ist.md). # Warum NL2SQL schwierig ist Trotz erheblicher Forschungsfortschritte bleibt NL2SQL in der Praxis ein herausforderndes Problem. Die Schwierigkeit nimmt erheblich zu, wenn man von akademischen Benchmarks (die typischerweise saubere, kleine Schemata mit unzweideutigen Fragen verwenden) zu produktiven Datenbanken in der realen Welt übergeht. Was Benutzer in der Benutzeroberfläche einer Anwendung sehen, im Gegensatz dazu, wie die Anwendung intern in der Datenbank aussieht, sind oft zwei Paar Schuhe.\ Je stärker sich diese beiden Paar Schuhe unterscheiden, desto schwieriger ist es, eine Anfrage zu konsolidieren, die auf den Annahmen einer Struktur basiert, mit der anderen.
### **Schema-Komplexität** Datenbanken aus der realen Welt haben Dutzende von Tabellen mit nicht offensichtlichen Namenskonventionen, impliziten Beziehungen und domänenspezifischer Semantik. Spaltennamen können abgekürzt, mehrfach belegt oder nur im Kontext aussagekräftig sein. Fremdschlüsselbeziehungen können implizit statt explizit definiert sein. Domänenspezifische Erweiterungen (z. B. TimescaleDB-Hyperfunktionen für Zeitreihendaten) fügen spezifische Syntax hinzu, auf die allgemeine Modelle im Training nur selten stoßen. ### Mehrdeutigkeit Benutzerfragen sind von Natur aus mehrdeutig. "Zeige mir den Energieverbrauch" könnte sich auf aktuelle Messwerte, historische Aggregationen oder einen Vergleich über Standorte hinweg beziehen. Es wird nicht angegeben, welche Anlagen Energie messen, welche Einheit zu verwenden ist oder welchen Zeitraum man berücksichtigen soll. Die Auflösung dieser Mehrdeutigkeit erfordert Domänenwissen, das über das Datenbankschema hinausgeht. ### **Korrektheit vs. Plausibilität** Eine generierte Abfrage kann syntaktisch gültiges SQL sein und trotzdem falsche Daten zurückgeben. Sie könnte über den falschen Schlüssel verknüpfen, eine falsche Aggregation anwenden, die falsche Tabelle abfragen oder einen erforderlichen Filter auslassen. Der gefährlichste Fehlermodus 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 Benutzer nicht (sonst würde er nicht fragen). ### **Bewertungsschwierigkeit** 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 vs. CTE). Umgekehrt können zwei Abfragen, die auf einem kleinen Testdatensatz dasselbe Ergebnis liefern, auf Produktionsdaten auseinanderlaufen. ## Die Herausforderung flexibler Datenmodelle Standard-NL2SQL-Benchmarks (d. h. Spider, BIRD) gehen von einem festen, bekannten Schema aus.\ Das Modell lernt, SQL für eine bestimmte Menge von Tabellen und Spalten zu erzeugen. Viele reale Plattformen, 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** das durch den Inhalt dieser Tabellen definiert ist. 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 dies variiert zwischen den 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 des Typs "EMeter" mit dem Subtyp "input" entspricht – Information, die in den Daten liegt, nicht in der Schemadefinition. ### Zwei Arten von Mehrdeutigkeit Diese zweischichtige Struktur führt zu zwei unterschiedlichen Arten von Mehrdeutigkeit: #### **Abfrage-Mehrdeutigkeit** Die Frage des Benutzers selbst ist unzureichend spezifiziert: * "Zeige mir Daten für das Gebäude" - welches Gebäude? Welche Daten? * "Gibt es Anomalien?" - was gilt als Anomalie? Welche Assets? Welcher Zeitraum? #### **Datenmehrdeutigkeit** 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 eine Raumsteuerung die Temperatur erfassen) * Hierarchische Beziehungen, bei denen der "richtige" Geltungsbereich vom Kontext abhängt (z. B. Energiezähler drei Ebenen unterhalb des Gebäudes, nach dem der Benutzer gefragt hat) Die Auflösung von Abfrage-Mehrdeutigkeit erfordert das Verständnis der Absicht des Benutzers. Die Auflösung von Datenmehrdeutigkeit erfordert das Verständnis des Datenmodells des Projekts. Ein reines NL2SQL-Modell kann, egal wie gut trainiert, nur das erste adressieren, 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 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-ki-und-maschinelles-lernen-in-buildingpro-suites/agenten/nl2sql/warum-nl2sql-schwierig-ist.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.