> 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/nl2sql-losen.md). # NL2SQL lösen ## Feinabgestimmte Modelle vs. Frontier-Modelle Eine wichtige Entscheidung ist, ob das Large Language Model, das zum Generieren von SQL-Abfragen verwendet wird, ein allgemeines größeres proprietäres Modell sein sollte, dem Schemainformationen vorgegeben werden, oder ein kleineres Modell, das speziell auf Abfragen für das Zielschema feinabgestimmt wurde. Wir haben dies getestet, und unsere Benchmarks zeigen, dass ein kleineres feinabgestimmtes Modell bei domänenspezifischer SQL-Generierung mit deutlich größeren Allzweckmodellen mithält oder sie sogar deutlich übertrifft:
Bewertungsdetails * 70 Proben, verschieden vom Trainingsdatensatz (\~350 Proben) * Jede Probe nach Abfragekomplexität und Domäne kategorisiert (welche Art von Daten abgerufen wurde) * Verwendete Metrik: semantische Ähnlichkeit der generierten Abfrage mit der handgefertigten Ground-Truth-Abfrage (Dies wird durch einen detaillierten Vergleich der Datenbank-Ausführungspläne beider Abfragen berechnet) * 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 es so, als ob unser feinabgestimmtes Modell `bpro-suites-nl2sql-3B` schneidet ähnlich ab 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 Bewertungsanfragen, die zur Erfüllung komplexere SQL-Abfragen erfordern (z. B. mehrere Joins, CTEs, Subqueries), zahlt sich das feinabgestimmte Modell aus, da seine generierten Abfragen viel besser auf das Zielschema abgestimmt sind:
{% 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 verstärkt, dass die Evaluationsergebnisse nach Datenbereich aufgeschlüsselt werden.\ Während größere Modelle sich gut auf einfachere Anfragen rund um Anlagenkonfiguration und aktuelle Daten verallgemeinern lassen, haben sie Schwierigkeiten, auf komplexere historische Aggregationen (Trend) zu generalisieren, da diese erfordern, auch die Anlagenhierarchie zu berücksichtigen, um zunächst die relevanten Anlagen in der Abfrage und anschließend deren Zeitreihendaten abzurufen:
{% hint style="info" %} Reasoning-Modelle der GPT-5- oder Claude-Opus-Familie wurden nicht evaluiert. Da geringe Latenz eine zentrale Anforderung war. {% endhint %} ## Kontext-Engineering Das Feinabstimmen auf schema-spezifische NL->SQL-Paare lehrt ein Modell die Struktur der Datenbank (Tabellen, Spalten, Joins, effiziente Abfragemuster), domänenspezifische Konventionen (z. B. wie Attribute, Untertypen und Einheiten organisiert sind) und wie häufige natürliche Sprachformulierungen auf SQL-Konstrukte abgebildet werden, die für die jeweilige Datenbank optimiert sind.\ \ Allerdings lehrt es nicht: * Welche spezifischen Assets es in einem gegebenen Projekt gibt * Was ein Benutzer mit "dem Gebäude" in seinem spezifischen Kontext meint * Ob ein bestimmter Asset-Typ tatsächlich Daten für eine angeforderte Metrik 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 erzeugen kann, nur ein Teil einer benutzerseitigen Lösung, die es ermöglicht, über natürliche Sprache mit der Datenbank zu kommunizieren.
### Semantische Schicht Eine semantische Schicht wird oft als Abstraktionsschicht zwischen Benutzer und Datenbank beschrieben, die es erleichtert, Abfragen zu formulieren und die semantische Bedeutung der Daten zu verstehen. \ Hier stellt sie einen Ansatz dar, um die Lücke zu überbrücken, die durch das Feinabstimmen eines LLM allein nicht geschlossen werden kann. Die Art und Weise, wie Benutzer ihre Daten und deren Struktur über eine Benutzeroberfläche verstehen, ist oft sehr unterschiedlich davon, wie diese Daten letztlich in einer Datenbank gespeichert sind. Je größer dieser Unterschied, desto schwieriger wird es, eine Anfrage, die auf Annahmen über eine Struktur basiert, mit der Realität der anderen zu verbinden. [Ontologien](/collection/german/akademie/introduction-to-ontologies.md) sind ein leistungsstarkes Werkzeug zum Beschreiben und Verstehen semantischer Strukturen. 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 Sprachabfragen mit den durch diese Ontologie definierten Konzepten und Strukturen zu verbinden. Ihr Zweck besteht darin, die SQL-Generierung so präzise wie möglich dynamisch zu kontextualisieren und damit effektiv das zu verknüpfen, worum ein Benutzer in natürlicher Sprache bittet, mit der tatsächlichen Form der zugrunde liegenden Daten. Die semantische Schicht hilft dem LLM, besser zu verstehen, was der Benutzer abrufen möchte, und reduziert so Mehrdeutigkeiten während der Abfragegenerierung. Zum Beispiel kann sie klären, nach welchen Assets ein Benutzer fragen möchte, bevor die SQL-Generierung stattfindet. Darüber hinaus hilft sie Benutzern 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 Semantische-Schicht-Architektur für NL2SQL aussehen könnte

**Beispielablauf:** 1. Verknüpfen Sie die natürliche Sprachabfrage mit Konzepten und Strukturen innerhalb der Ontologie 2. Extrahieren Sie Beziehungen zwischen diesen Konzepten (z. B. befindet sich in) 3. Verwenden Sie vordefinierte Regeln für Konzepte und deren Beziehungen, um sie auf tatsächliche Dateninstanzen abzubilden. 4. Kontextualisieren Sie die SQL-Generierung basierend auf den identifizierten Konzepten und ihren entsprechenden Datenbankinstanzen. Die Kernidee besteht darin, 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 Benutzer bereits kennen und verstehen, weil sie in der Benutzeroberfläche sichtbar sind. Mehrdeutigkeiten, wohl die größte Herausforderung bei Abfragen in natürlicher Sprache, können daher durch die direkte Verknüpfung von Benutzeranfragen mit tatsächlichen Datenentitäten aufgelöst werden. Im Kontext von BuildingPro Suites wären dies am häufigsten Assets und Asset-Typen. ## Zentrale Erkenntnisse * LLMs sind oft nur so leistungsfähig wie der Kontext, den sie erhalten. * LLMs sind selten die vollständige Lösung für sich allein und benötigen typischerweise umgebende Systeme, die sie beim Lösen komplexerer Aufgaben anleiten und unterstützen. * Kleine Modelle, die auf eine bestimmte Aufgabe ausgerichtet sind, können deutlich größere, leistungsfähigere Modelle übertreffen * Feinabstimmung kann sehr gut funktionieren, um die Leistung für ein bestimmtes Datenbankschema zu optimieren, aber sie erfordert Datensatzaktualisierungen und erneutes Trainieren, sobald größere Schemaänderungen auftreten. * Da generierte SQL-Abfragen letztlich die Absicht des Benutzers widerspiegeln sollten, ist es sinnvoll, den Benutzer in den Prozess einzubeziehen und die Interpretation auf Konzepte zu stützen, die der Benutzer 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 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/nl2sql-losen.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.