Fachbegriffe
Begriffe, Synonyme und zulässige Interpretationen werden explizit, damit Nutzerfragen nicht direkt am technischen Schema hängen.
Deep Dive · Semantic Layer
Ein Semantic Layer übersetzt Fachsprache in kontrollierte Daten-, Metrik- und Aktionslogik. Er macht Begriffe sichtbar und entscheidet, welcher Kontext für eine Frage erlaubt, relevant und ausführbar ist.
Kuratierter erster Schnitt · Stand Mai 2026
Nutzer fragen in Fachsprache, Daten liegen aber in Tabellen, Graphen, APIs, Dokumenten und Tools. Der Semantic Layer übersetzt dazwischen: Er erkennt, welche Begriffe gemeint sind, welche Metriken gelten, welche Quellen genutzt werden dürfen und welche Aktionen überhaupt erlaubt sind.
Der praktische Wert entsteht, wenn diese Bedeutung beschrieben und ausführbar wird. Ein Semantic Layer kann aus einer Fachfrage eine kontrollierte SQL-Abfrage, einen Graphpfad, einen API-Aufruf oder ein kleines Kontextpaket für einen Agenten machen.
Ein Semantic Layer ist kein einzelnes Datenformat. Er ist ein gepflegtes Set aus Begriffen, Regeln und Mappings, das Fachlogik für Systeme nutzbar macht.
Begriffe, Synonyme und zulässige Interpretationen werden explizit, damit Nutzerfragen nicht direkt am technischen Schema hängen.
Kunden, Verträge, Produkte, Tickets oder Services werden als fachliche Objekte mit Bezug zu Tabellen und Feldern beschrieben.
Kennzahlen bekommen Definitionen, Filterlogik, Berechnungsregeln und Gültigkeitsbereiche.
Erlaubte Joins, Graphpfade oder API-Verknüpfungen legen fest, wie Objekte fachlich zusammenhängen dürfen.
Der Layer entscheidet mit, welche Daten, Metriken oder Aktionen für eine Rolle sichtbar und erlaubt sind.
Erlaubte, mehrdeutige und verbotene Fragen machen die Bedeutungsschicht dokumentiert und testbar.
Die Pipeline zeigt den Weg vom Begriffslexikon zur operativen Bedeutungsschicht. Der Layer entscheidet, was ein Wort bedeutet und wie daraus ein erlaubter Zugriff wird.
Nutzerfrage aufnehmen und Fachbegriffe, Zeitraum, Rolle und gewünschte Antwortform erkennen.
Begriffe auf definierte Entitäten, Metriken, Synonyme und Datenquellen abbilden.
Erlaubte Relationen, Joins, Graphpfade oder Tool-Aufrufe auswählen.
Rollen, Berechtigungen, Constraints und verbotene Interpretationen anwenden.
Eine Query, einen Tool-Aufruf oder ein kontrolliertes Kontextpaket erzeugen.
Antwort mit Definitionen, Quellen und angewendeten Regeln zurückgeben.
Fachfragen wirken oft einfach. Ihre Bedeutung hängt aber an Definitionen, Datenquellen, Zeitlogik und Berechtigungen.
Wie hoch war unser Umsatz mit aktiven Enterprise-Kunden im letzten Quartal?
Technische Mappings
Semantische Prüfung
Net Revenue ohne Steuern, nach Stornos, mit Buchungsdatum als Reporting-Grundlage.
Kunde mit laufendem Vertrag und mindestens einer produktiven Nutzung in den letzten 90 Tagen.
Segment aus CRM, aber nur wenn der Accountstatus nicht archiviert ist.
Geschlossenes Kalenderquartal in der Reporting-Zeitzone Europe/Berlin.
Der Semantic Layer verhindert, dass das Modell Umsatz, Rechnungsbetrag, Pipeline-Wert oder Bruttoumsatz vermischt.
Der Semantic Layer ist am stärksten, wenn er Bedeutung für Suche, Graphen, Metriken und Agenten nutzbar macht.
beschreibt Begriffe, Klassen und Beziehungen als Bedeutungssystem.
speichert Instanzen, Beziehungen und Fakten als abfragbaren Graph.
nutzt Graphkontext im Retrieval, wenn Antworten aus Beziehungen entstehen.
liefert semantisch ähnliche Textstellen, aber kennt Fachdefinitionen nicht automatisch.
Agenten brauchen kleinen, berechtigten, fachlich korrekten und handlungsfähigen Kontext.
Ein erster Semantic Layer kann sehr klein starten. Entscheidend ist, dass Definition, Quelle, Rolle und verbotene Interpretationen zusammen gepflegt werden.
metric: net_revenue
label: Umsatz
definition: Net Revenue ohne Steuern, nach Stornos
allowed_roles:
- finance
- management
source:
table: finance.revenue_fact
field: net_revenue_eur
filters:
booking_status: posted
forbidden_interpretations:
- pipeline_value
- gross_invoice_amountEin Semantic Layer ist für Text-to-SQL und Agenten nützlich. Bei Agenten entscheidet er auch, ob eine fachliche Aktion erlaubt ist oder als Vorschlag vorbereitet werden darf.
Bitte aktualisiere den Renewal-Status für Kunde Nordstern auf gefährdet.
Renewal-Status ist ein CRM-Feld mit erlaubten Werten: offen, stabil, gefährdet, verloren.
Der Agent darf Status lesen; Schreiben ist nur für Customer Success Manager erlaubt.
Bei fehlendem Schreibrecht erzeugt der Agent einen Änderungsvorschlag und lässt das CRM unverändert.
Semantic-Layer-Arbeit scheitert selten an der Idee. Häufig scheitert sie daran, dass Bedeutung nicht gepflegt, getestet oder in die Ausführung eingebunden wird.
Begriffe stehen in einem Wiki, sind aber nicht in Retrieval, Query-Erzeugung oder Tool-Aufrufe eingebunden.
Der Layer versucht die gesamte Organisation abzubilden und wird dadurch schwer pflegbar.
Fachdefinitionen ändern sich, technische Mappings bleiben alt oder umgekehrt.
Rechte, Rollen und verbotene Aktionen werden erst ergänzt, wenn der Agent schon produktiv genutzt wird.
Das Begriffssystem wird gepflegt, aber die operative Übersetzung in Abfragen, Metriken und Aktionen fehlt.
Der beste Start ist ein dünner, testbarer Schnitt mit echten Fragen und messbarem Nutzen.
5 bis 10 kritische Business-Fragen sammeln, bei denen falsche Begriffe echte Folgen hätten.
Die wichtigsten Entitäten, Metriken, Synonyme, Quellen und Rollen dazu notieren.
Erlaubte und nicht erlaubte Interpretationen als Testfälle formulieren.
Ein kleines YAML- oder JSON-Modell bauen, das Fragen auf Mappings und Regeln abbildet.
Gegen direkte SQL-, RAG- oder Agent-Antworten messen: Wird die Antwort korrekter, enger und erklärbarer?
Starte mit Definitionen, Metriken und Synonymen. Das reduziert falsche Antworten bei scheinbar einfachen Business-Fragen.
Mache Vorbedingungen, Rollen und erlaubte Parameter explizit. Der Layer wird dann zur Leitplanke für Ausführung.
Kapsle Tabellen, Graphen und APIs hinter fachlichen Objekten. Das Modell bekommt weniger Schema-Rauschen und mehr Bedeutung.
Nächste Schritte