Konzeptkarte

Natural-Language-Abfragen über SAP-Daten — Text-to-SQL-Muster und Grenzen

Stand 8. November 2026

Was sind Natural-Language-Abfragen über SAP-Daten?

„Natural-Language-Abfrage“ verbirgt zwei strukturell unterschiedliche Techniken: das durch die semantische Schicht vermittelte NLQ (Just Ask, Joules Analytical Insights) antwortet nur über ein vormodelliertes, gesteuertes Vokabular, während Text-to-SQL ein LLM seine eigene Abfrage gegen katalogisierte Tabellen schreiben und ausführen lässt. Keines ist universell besser — der Tausch erfolgt zwischen Flexibilität und der Garantie, dass die Antwort eine bereits geprüfte Definition wiederverwendet.

Zwei Techniken unter einem Etikett

„Stellen Sie Ihren Daten eine Frage in einfachem Deutsch“ beschreibt zwei strukturell unterschiedliche Mechanismen, und sie in einem Angebot zu verwechseln, ist der Weg, wie eine Delivery-Schätzung schiefgeht. Der erste, durch die semantische Schicht vermitteltes NLQ, ist das, was SACs Just Ask und darüber Joules Analytical Insights tun: Die Frage wird mit einem vormodellierten analytischen Modell abgeglichen – Kennzahlen, Hierarchien, Bezeichnungen bereits definiert und geprüft – und die Antwort kann nie flexibler sein als dieses Modell. Der zweite, Text-to-SQL, lässt ein LLM Tabellen- und Spaltenmetadaten aus einem gesteuerten Katalog lesen und seine eigene Abfrage auf die Schnelle generieren, näher an dem, was Databricks Genie gegen Unity Catalog tut: Kein vorgefertigtes Modell schränkt die Frage ein, aber nichts Vorgefertigtes schützt auch die Antwort.

Warum es zählt

„Natural-Language-Abfrage“ ist keine einzelne Technik: durch die semantische Schicht vermitteltes NLQ und Text-to-SQL scheitern auf entgegengesetzte Weisen — eines scheitert sichtbar durch Schweigen, das andere unsichtbar durch Plausibilität — und ein Scoping ohne Benennung, welches gemeint ist, lässt das eigentliche Risiko unadressiert.
Zugriffskontroll-Governance (Katalogberechtigungen) und semantische Korrektheit (bedeutet die Abfrage, was das Geschäft bedeutet) sind unterschiedliche Garantien; Text-to-SQL kann die erste perfekt liefern und trotzdem bei der zweiten scheitern.
Die meisten Geschäftsanforderungen für „fragen Sie Ihre Daten alles“ erweisen sich bei genauerem Hinsehen als Anforderungen an vertrauenswürdige Antworten auf eine begrenzte Fragenmenge — der durch die semantische Schicht vermittelte Fall, nicht der offene Fall, den die Formulierung suggeriert.

Kernpunkte

Durch die semantische Schicht vermitteltes NLQ (Just Ask, Joules Analytical Insights): antwortet nur über ein vormodelliertes, geprüftes Vokabular; scheitert durch Schweigen oder eine nachvollziehbare Modelllücke.
Text-to-SQL (Genie-artiges Muster): Ein LLM liest Katalog-Metadaten und schreibt seine eigene Abfrage; scheitert durch Plausibilität — eine syntaktisch gültige, selbstsicher falsche Antwort.
Governance (wer was sehen darf) ruht in beiden Mustern auf dem Katalog und wird gut behandelt; semantische Korrektheit (bedeutet die Abfrage, was das Geschäft bedeutet) ist für Text-to-SQL strukturell schwerer.
Beide schließen sich innerhalb einer Architektur nicht gegenseitig aus — Routinefragen über semantisches NLQ, explorative Arbeitslasten über Text-to-SQL auf denselben Datenprodukten.
Ein Angebot, das nur „Natural-Language-Abfrage“ nennt, ohne das Muster zu spezifizieren, hat weder die Kompetenzen noch die Fehlermodi noch die Governance-Geschichte gescopet, die sich zwischen beiden unterscheiden.
Die meisten realen Geschäftsanforderungen zielen auf vertrauenswürdige Antworten für eine begrenzte Fragenmenge — der Fall der semantischen Schicht — auch wenn sie als „fragen Sie alles“ formuliert sind.

Begriffe auf dieser Seite

Durch die semantische Schicht vermitteltes NLQ: Natural-Language-Abfrage, die über ein vormodelliertes analytisches Modell mit gesteuerten Kennzahlen, Hierarchien und Bezeichnungen beantwortet wird.
Text-to-SQL: Ein Ansatz, bei dem ein LLM seine eigene Abfrage gegen katalogisierte Tabellen generiert und ausführt, ohne ein vorgefertigtes semantisches Modell.
Governance auf Katalogebene: Zugriffskontrolle, durchgesetzt vom Datenkatalog (z. B. Unity Catalog), unabhängig davon, welches Abfragemuster darüber verwendet wird.
Selbstsicher falsche Antwort: Eine syntaktisch oder flüssig korrekt wirkende Antwort, die semantisch falsch ist und kein sichtbares Fehlersignal gibt.
Trusted Asset (Genie): Eine vom Datenteam kuratierte, verifizierte Zuordnung von Frage zu SQL oder Kennzahl, die ein Text-to-SQL-System prüft, bevor es auf freie Abfragegenerierung zurückfällt.
GraphRAG: Retrieval, das explizite Graphbeziehungen (SPARQL/RDF) durchläuft statt Vektorähnlichkeit oder generiertes SQL — SAP HANA Clouds Knowledge Graph Engine implementiert dies für beziehungsförmige Fragen, die keines der beiden NLQ-Muster dieser Seite gut beantwortet.
Principal Propagation (MCP): Der Mechanismus, der die echte, angemeldete Identität eines MCP-Aufrufers bis zu einem SAP-ABAP-Nutzer trägt, sodass ein über eine per MCP bereitgestellte API gebauter Text-to-SQL-Agent die Zugriffskontrolle automatisch erbt.
Validierungsschicht: Eine Komponente, die speziell gebaut wird, um die generierten Abfragen eines Text-to-SQL-Systems gegen bekannt korrekte Muster zu prüfen, bevor der Antwort vertraut wird — das fehlende Stück, das reine Governance auf Katalogebene nicht liefert.

Quellen

Vollständige Karte im Consultant-Tarif — 19,90 €/Monat. Was die vollständige Karte ergänzt: den vollständigen Entscheidungsrahmen · den Vergleich SAP · Snowflake · Databricks · Fabric · die häufigen Fallstricke und ihre Behebung · die Kurzreferenz · die Architekturschemata · die Codeblöcke · die zitierfähigen Kennzahlen.

In der App öffnen →

Redaktion: Cédric Mary · Wie diese Seite entsteht

Offene SAP-Projekte

Aktuelle SAP-Analytics-Projekte und Stellen im DACH-Raum: SAP-Analytics-Projekte im DACH-Raum.