Zum Inhalt springen
GraphRAG Compass
  • Grundlagen
  • Architekturen
  • Praxis
  • Business Cases
  • Lernpfad
  • Simulation
  • Landkarte
GraphRAG Compass

Öffentlicher Field Guide für GraphRAG, Knowledge Graphs, AI-Architekturen und bessere Entscheidungen in komplexen Wissenssystemen.

Erkunden

  • Grundlagen
  • Architekturen
  • Praxis
  • Business Cases
  • Simulation
  • Landkarte

Lernen

  • Lernpfad
  • Mini-Use-Case
  • GraphRAG Poster
  • Glossar

Über

  • About
  • LinkedIn

Discovery

  • llms.txt
  • llms-full.txt
  • sitemap.xml

Rechtliches

  • Impressum
  • Datenschutz

© 2026 Meierhoff Systems · GraphRAG Compass

Orientierung für Entscheidungen in Wissenssystemen

Zurück zum Architekturmuster

Architektur-Detail · Datenzugriff

Semantic Layer für Text-to-SQL

Ein Schema-Graph modelliert nur die fachlich relevanten Tabellen, Felder, Begriffe und Beziehungen — der LLM bekommt den kontextrelevanten Subgraph statt des vollständigen Schemas. 20–30 % weniger Tokens, messbar bessere Join-Qualität und explizite Domänenlogik statt implizitem Tabellenwissen.

Praxisnah
Aufwand: mittel
Datenreife: hoch
Team-Reife: mittel

Kuratierte Architekturentscheidung auf Basis der lokalen Compass-Daten

Relevant wenn

Wenn Text-to-SQL über komplexe Schemas fehlerhaft ist und das vollständige Schema den LLM-Kontext überlädt.

Quellenlage

Compass-Komposition aus realen Semantic-Layer- und Text-to-SQL-Mustern. Es gibt Primärquellen zu Semantic Layer, SQL Agents und Zugriffskontrolle, aber nicht genau diesen Compass-Namen als Standardarchitektur.

Welches Problem löst das Muster?

LLM erzeugt fehlerhafte SQL-Abfragen, weil das Datenbankschema zu groß, zu technisch oder zu unverständlich ist.

Systemkarte

Wie der Architekturfluss aussieht

Die Motion Map verdichtet das Muster auf seine wichtigsten Stationen: Eingabe, Daten- oder Graphschicht, Retrieval, Kontrolle und Antwort. Sie ist bewusst kleiner als die Referenzarchitektur darunter und soll zuerst die Leserichtung und die Systemgrenzen sichtbar machen.

Motion Map

Semantic Text-to-SQL

Fachfrage
Semantik
Schema
Policy
SQL
Antwort

Der relevante Bedeutungsausschnitt kommt in den Prompt.

Architekturblick

Was du bauen, betreiben und messen musst

Diese Seite ist eine Entscheidungshilfe für den Stack. Der Blick liegt auf Datenfluss, Failure Modes, Evaluation, Tooling und dem nächsten sinnvollen Migrationsschritt.

Stack-Schnitt

Business GlossarSchema GraphMetric StorePolicy LayerSQL GeneratorValidatorQuery Log

Runtime-Datenfluss

Fachbegriffe werden auf Metriken, Tabellen, Joins und Regeln gemappt. Erst dann erzeugt das LLM SQL gegen einen begrenzten Schema-Ausschnitt, der validiert und protokolliert wird.

Migrationspfad

Mit wenigen Fachfragen und Metriken starten, dann Schema-Subgraph, Policies, Validierung und versionierte Metrikdefinitionen ergänzen.

Failure Modes

  • Falsche Joins liefern plausible, aber falsche Kennzahlen.
  • Mehrdeutige Begriffe werden nicht geklärt.
  • Rollen und Zeilenrechte greifen erst nach der Antwort.

Evaluation

  • SQL gegen erwartete Query-Muster prüfen.
  • Kennzahlen mit bekannten Reports abgleichen.
  • Ablehnungen und Rückfragen als Qualitätsmerkmal zählen.

Tooling & Betrieb

  • dbt Semantic Layer
  • Cube
  • MetricFlow
  • SQL Parser
  • Policy Engine
  • Warehouse Logs

Referenzarchitektur

Wie Semantic Layer für Text-to-SQL funktioniert

Diese Architektur übersetzt nicht einfach Sprache in SQL. Sie baut eine kontrollierte Bedeutungsschicht zwischen Fachfrage und Datenbankschema. Das Modell bekommt nur den relevanten Schema-Ausschnitt, fachliche Definitionen und erlaubte Operationen. Dadurch wird Text-to-SQL weniger ein Prompt-Trick und mehr eine governancefähige Abfragearchitektur.

  1. 01

    Fachfrage aufnehmen

    Nutzer fragen in Fachsprache: Umsatz, aktive Kunden, offene Risiken oder Marge. Diese Begriffe sind selten identisch mit Tabellen- und Spaltennamen.

  2. 02

    Begriffe auflösen

    Der Semantic Layer klärt, welche Metrik, Definition, Zeitebene, Datenquelle und Berechnungsregel gemeint ist.

  3. 03

    Schema-Subgraph wählen

    Statt das gesamte Datenbankschema in den Prompt zu geben, wird nur der relevante Ausschnitt aus Tabellen, Feldern, Joins und Regeln bereitgestellt.

  4. 04

    SQL erzeugen

    Das LLM generiert SQL gegen einen begrenzten, fachlich erklärten Kontext. Dadurch sinkt die Wahrscheinlichkeit falscher Joins und falscher Kennzahlen.

  5. 05

    Validieren und begrenzen

    Policies prüfen Tabellenzugriff, Aggregationen, Zeilenlimits, gefährliche Operationen und Rollen. Fehler werden vor der Ausführung abgefangen.

  6. 06

    Antwort erklären

    Die Antwort sollte Ergebnis, Kennzahl, Quelle, Filter, Zeitraum und SQL-Logik nachvollziehbar machen.

Aufwand
mittel

Implementierungs-, Integrations- und Betriebsaufwand.

Datenreife
hoch

Qualität, Struktur und Zugänglichkeit der Daten vor dem Pilot.

Team-Reife
mittel

Erfahrung mit RAG, Graphdenken, Infrastruktur und Evaluation.

Nicht ideal wenn

Schema und Fachdomäne häufig wechseln oder kaum fachliche Governance existiert.

Trade-offs

Schema-Graph muss manuell gepflegt werden und mit der echten Datenbank synchron bleiben. Nur wirksam wenn die Domäne klar abgrenzbar ist — breite, dynamisch wachsende Schemas sind schwer vollständig zu modellieren.

Bausteine

Was der Semantic Layer enthalten muss

Der Semantic Layer ist hier kein hübscher Name für Dokumentation. Er ist der kontrollierte Kontext, der entscheidet, welche Bedeutung, Tabellen, Joins, Metriken und Regeln für eine Frage gelten.

Business Glossar

Definiert Fachbegriffe wie Umsatz, Kunde, aktiver Vertrag oder Risiko. Ohne Glossar bleibt Text-to-SQL eine Übersetzung technischer Tabellen.

Schema-Graph

Modelliert Tabellen, Spalten, Beziehungen, Joins, Kardinalitäten und relevante Datenprodukte als abfragbaren Kontext.

Metrikdefinitionen

Kennzahlen brauchen Formel, Filter, Zeitraum, Aggregationslogik und Verantwortlichkeit. Sonst produziert das Modell plausible, aber falsche Zahlen.

Policy Layer

Regelt, wer welche Daten sehen darf, welche Operationen erlaubt sind und wann eine Abfrage abgelehnt oder eskaliert wird.

Qualitätshebel

Wo Text-to-SQL gefährlich wird

Text-to-SQL wirkt schnell beeindruckend, bis falsche Kennzahlen, falsche Joins oder unerlaubte Daten in Antworten landen. Der Semantic Layer soll genau diese Fehlerklassen sichtbar und prüfbar machen.

Join-Fehler messen

Bewerte, ob SQL syntaktisch läuft und ob Joins fachlich korrekt sind, ohne Zeilen zu vervielfachen oder Daten zu verlieren.

Kennzahlen versionieren

Wenn sich Metrikdefinitionen ändern, muss nachvollziehbar bleiben, welche Antwort mit welcher Definition erzeugt wurde.

Fallback statt Fantasie

Wenn ein Begriff mehrdeutig ist, soll das System nachfragen oder ablehnen, statt eine willkürliche Tabelle zu wählen.

SQL sichtbar machen

Für analytische Nutzung sollte die generierte Logik prüfbar sein: verwendete Tabellen, Filter, Zeitraum und Annahmen gehören in die Antwort.

Stack-Komponenten

Neo4j / GraphwiseSchema-GraphLangChainSQL-Datenbank

Ausbaustufen

Vom Glossar zur operativen Bedeutungsschicht

Ein Semantic Layer kann klein starten. Entscheidend ist, dass er Begriffsdefinitionen, Abfragen, Rechte, Metriken und Verantwortlichkeiten gemeinsam kontrolliert.

  1. Stufe 1

    Starte mit 20 echten Fachfragen, Begriffen, Tabellen und erwarteten SQL-Mustern.

  2. Stufe 2

    Baue einen kleinen Graphen aus Tabellen, Spalten, Beziehungen, Metriken und erlaubten Joins.

  3. Stufe 3

    Führe SQL nur nach Validierung, Rollenprüfung und Limitierung aus. Speichere Frage, SQL und Ergebnis für Evaluation.

  4. Stufe 4

    Erweitere auf Metrik-Governance, Datenprodukte, Ownership, Versionierung und Agentenaktionen.

Konkrete Beispiele

In welchem Kontext das Muster typischerweise Sinn ergibt und welchen Beitrag es dort leistet.

Fachliche BI-Fragen

Nutzer fragen nach Umsatz oder aktiven Kunden, kennen aber das Datenbankschema nicht.

Der Semantic Layer begrenzt und übersetzt die Abfrage auf fachlich erlaubte Konzepte.

Governance für Kennzahlen

Metriken haben je Team unterschiedliche Definitionen.

Gemeinsame Regeln reduzieren widersprüchliche SQL-Generierung.

Einsteigerbeispiel: Umsatzfrage

Ein Fachnutzer fragt: Wie hoch war der wiederkehrende Umsatz im letzten Quartal? In der Datenbank heißen die Tabellen aber subscriptions, invoices und account_events.

Der Semantic Layer erklärt dem System, welche Tabellen, Joins, Filter und Kennzahlendefinitionen für diese Frage erlaubt und fachlich korrekt sind.

Nächste Umsetzungsschritte

  1. 1

    Kritische SQL-Fragen sammeln

  2. 2

    Fachbegriffe auf Tabellen mappen

  3. 3

    Join-Fehler vor/nach Semantic Layer messen

Verwandte Konzepte, Tools und Plattformen

Semantic LayerKnowledge GraphsNeo4jGraphwise
Vorheriges ThemaNeo4j GraphRAG StackNächstes ThemaAgent Memory Stack