> 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/solving-nl2sql.md).
# NL2SQL lösen
## Feinabgestimmte Modelle vs. Frontier-Modelle
Eine zentrale Entscheidung ist, ob das Large Language Model, das zur Generierung von SQL-Abfragen verwendet wird, ein allgemeines größeres proprietäres Modell sein sollte, das mit Schema-Informationen gepromptet wird, oder ein kleineres Modell, das speziell auf Abfragen für das Ziel-Schema feinabgestimmt wurde.
Wir haben dies getestet, und unsere Benchmarks zeigen, dass ein kleineres feinabgestimmtes Modell bei domänenspezifischer SQL-Generierung gleich gut abschneidet oder sogar deutlich größere allgemeine Modelle übertrifft:
Details zur Evaluation
* 70 Stichproben, die sich vom Trainingsdatensatz unterscheiden (\~350 Stichproben)
* Jede Stichprobe kategorisiert nach Abfragekomplexität und Domäne (welche Art von Daten abgerufen wurde)
* Verwendete Metrik: Semantische Abfrageähnlichkeit der generierten Abfrage mit der handgefertigten Ground-Truth-Abfrage (dies wird berechnet, indem die Ausführungspläne beider Datenbankabfragen im Detail verglichen werden)
* Das feinabgestimmte Modell erhält: die Benutzeranfrage
* Die größeren LLMs erhalten: die Benutzeranfrage + semantisch angereicherte Schema-Beschreibung (z. B. mit Erklärungen von Datenbankkonzepten) + Few-Shot-Beispiele von NL-Abfrage -> SQL-Zuordnungen aus dem Trainingsdatensatz
Insgesamt scheint unser feinabgestimmtes Modell `bpro-suites-nl2sql-3B` ähnlich abzuschneiden wie größere Open-Weight-Modelle wie DeepSeek oder Qwen und größere proprietäre Modelle wie die Nicht-Reasoning-Modelle der GPT-5-Familie.
Bei Evaluierungsanfragen, die komplexere SQL-Abfragen erfordern (z. B. mehrere Joins, CTEs, Subqueries), zahlt sich das feinabgestimmte Modell zunehmend aus, da seine generierten Abfragen viel stärker mit dem Ziel-Schema übereinstimmen:
Konsistenz ist in Unternehmensumgebungen entscheidend!\
Ein vielseitiges Modell sollte in der Lage sein, alle Arten unterschiedlicher Datentasks zu bewältigen, ohne dass die Genauigkeit zu stark variiert.
{% hint style="info" %}
Mit 3 Milliarden Parametern ist unser Modell ungefähr 300-mal kleiner als die größeren LLMs, mit denen es hier verglichen wird.
{% endhint %}
Dieser Umstand wird dadurch weiter verdeutlicht, dass die Evaluationsergebnisse nach Daten-Domäne aufgeschlüsselt werden.\
Während größere Modelle bei einfacheren Anfragen rund um **Asset-Konfiguration** und aktuelle Daten gut generalisieren können, tun sie sich schwer damit, auf komplexere historische Aggregationen (**Trend**) zu generalisieren, da dabei auch die Asset-Hierarchie berücksichtigt werden muss, um zuerst die relevanten Assets in der Abfrage und anschließend deren Zeitreihendaten abzurufen:
{% hint style="info" %}
Reasoning-Modelle der GPT-5- oder Claude-Opus-Familie wurden mit geringem Reasoning-Aufwand evaluiert. Da niedrige Latenz eine zentrale Anforderung war.
{% endhint %}
## Kontext-Engineering
Das Finetuning auf schema-spezifischen NL->SQL-Paaren lehrt ein Modell die Struktur der Datenbank (Tabellen, Spalten, Joins, effiziente Abfragemuster), domänenspezifische Konventionen (z. B. wie Attribute, Subtypen und Einheiten organisiert sind) und wie gängige natürliche Sprachformulierungen auf SQL-Konstrukte abgebildet werden, die für die jeweilige Datenbank optimiert sind.\
\
Es lehrt jedoch nicht:
* Welche konkreten Assets in einem bestimmten Projekt existieren
* Was ein Nutzer in seinem spezifischen Kontext mit „dem Gebäude“ meint
* Ob ein bestimmter Asset-Typ tatsächlich Daten für eine angefragte Kennzahl hat
* Wie Mehrdeutigkeiten aufgelöst werden, wenn mehrere gültige Interpretationen existieren
Deshalb ist ein Modell, das Abfragen für ein bestimmtes Schema sehr gut generieren kann, nur ein Teil einer benutzerorientierten Lösung, die es ermöglicht, mit der Datenbank in natürlicher Sprache zu kommunizieren.
### Semantische Schicht
Eine semantische Schicht wird oft als Abstraktionsschicht zwischen dem Benutzer und der Datenbank beschrieben, die es erleichtert, Abfragen zu formulieren und die semantische Bedeutung der Daten zu verstehen.\
Hier stellt sie einen Ansatz dar, die Lücke zu überbrücken, die sich nicht allein durch das Feinabstimmen eines LLMs lösen lässt.
Die Art und Weise, wie Nutzer ihre Daten und deren Struktur über eine Benutzeroberfläche verstehen, unterscheidet sich oft stark davon, wie diese Daten letztlich in einer Datenbank gespeichert sind. Je größer dieser Unterschied ist, desto schwieriger wird es, eine auf Annahmen über die eine Struktur basierende Anfrage mit der Realität der anderen zu verbinden.
[Ontologien](/collection/german/akademie/introduction-to-ontologies.md) sind ein leistungsstarkes Werkzeug, um semantische Strukturen zu beschreiben und zu verstehen. Sie ermöglichen es uns, Beziehungen zwischen Konzepten und ihren Eigenschaften zu definieren. Im Kontext von BuildingPro Suites bedeutet dies, zu beschreiben, wie Portfolios strukturiert sind und wie sie strukturiert werden können. Im Zentrum dieses Modells stehen Assets, die verschiedene Formen annehmen können, etwa Sensoren, Standorte, Gebäude oder bestimmte Bereiche. [Wie BPro Suites Ontologien abdeckt](/collection/german/akademie/introduction-to-ontologies/how-eliona-covers-ontologies.md) beschreibt daher, wie diese Assets modelliert werden können und wie sie zueinander in Beziehung stehen.
In diesem Kontext wird die semantische Schicht verwendet, um natürliche Sprachanfragen mit den in dieser Ontologie definierten Konzepten und Strukturen zu verknüpfen. Ihr Zweck ist es, die SQL-Generierung so präzise wie möglich dynamisch zu kontextualisieren und damit effektiv zu verbinden, wonach ein Benutzer in natürlicher Sprache fragt, mit der tatsächlichen Existenz der zugrunde liegenden Daten.
Die semantische Schicht hilft dem LLM, besser zu verstehen, was der Nutzer abrufen möchte, und reduziert so Mehrdeutigkeiten bei der Abfragegenerierung. Zum Beispiel kann sie klären, welche Assets ein Nutzer abfragen möchte, bevor die SQL-Generierung stattfindet. Außerdem hilft sie Nutzern zu verstehen, wie ihre Anfrage vom System interpretiert wird und wie sie sie verfeinern können, um bessere Ergebnisse zu erzielen.
Beispiel, wie eine solche Semantic-Layer-Architektur für NL2SQL aussehen könnte
**Beispielablauf:**
1. Die natürliche Sprachabfrage mit Konzepten und Strukturen innerhalb der Ontologie verknüpfen
2. Beziehungen zwischen diesen Konzepten extrahieren (z. B. befindet sich in)
3. Vordefinierte Regeln für Konzepte und ihre Beziehungen verwenden, um sie auf tatsächliche Dateninstanzen abzubilden.
4. Die SQL-Generierung basierend auf den identifizierten Konzepten und ihren entsprechenden Datenbankinstanzen kontextualisieren.
Die Kernidee ist, dass die semantische Schicht als Brücke zwischen der natürlichen Sprachabfrage und der Datenbank dient, indem sie die in der Ontologie definierten Konzepte und Beziehungen nutzt. Anstatt eine natürliche Sprachanfrage direkt in SQL zu übersetzen, versucht das System zunächst, die Anfrage auf Konzepte abzubilden, die Nutzer bereits kennen und verstehen, weil sie in der Benutzeroberfläche sichtbar sind.
Mehrdeutigkeiten, arguably die größte Herausforderung bei der natürlichen Sprachabfrage, können daher gelöst werden, indem Benutzeranfragen direkt mit tatsächlichen Datenentitäten verknüpft werden. Im Kontext von BuildingPro Suites wären dies meist Assets und Asset-Typen.
## Wichtige Erkenntnisse
* LLMs sind oft nur so leistungsfähig wie der Kontext, den sie erhalten.
* LLMs sind selten allein die vollständige Lösung und benötigen typischerweise umgebende Systeme, die sie bei der Lösung komplexerer Aufgaben leiten und unterstützen.
* Kleine Modelle, die auf eine bestimmte Aufgabe ausgerichtet sind, können viel größere, leistungsfähigere Modelle übertreffen
* Finetuning kann sehr gut funktionieren, um die Leistung auf ein bestimmtes Datenbankschema zu optimieren, aber es erfordert Datensatz-Updates und erneutes Training, sobald erhebliche Schemaänderungen auftreten.
* Da generierte SQL-Abfragen letztlich die Absicht des Nutzers widerspiegeln sollten, ist es sinnvoll, den Nutzer in den Prozess einzubeziehen und die Interpretation auf Konzepte zu stützen, die der Nutzer am besten versteht
---
# 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/solving-nl2sql.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.
