← KI & Unternehmensdaten

Semantische Schicht

Die semantische Schicht: Bedeutung, die nicht im Prompt steht.

Eine Datenbank speichert Werte, keine Bedeutung. Dass eine Rechnung erst ab einem bestimmten Status als offen gilt und dass eine Tabelle Historie statt Gegenwart enthält, steht nirgends im Schema – es steht im Sourcecode und in den Köpfen. Die semantische Schicht ist der Ort, an dem dieses Wissen aufgeschrieben wird.

Beschrieben statt trainiertPrüfbar durch Ihre FachbereicheBleibt Ihr Eigentum
Bestehende Systeme
Sourcecode
Datenbank
Semantische Schicht
Fachbegriffe · Beziehungen · Bedeutungen · Regeln
MCP-Server · Chat-Oberfläche
„Welche Kunden …?“

Das Problem

Ein Schema sagt, wie Daten liegen. Nicht, was sie bedeuten.

Eine Spalte heißt „status“ und enthält Zahlen von 1 bis 7. Welche davon eine offene Rechnung bezeichnet, ergibt sich nicht aus dem Datenmodell, sondern aus einer Fallunterscheidung irgendwo im Programmcode. Eine Tabelle heißt wie ein Geschäftsobjekt, enthält aber jede Änderung daran als eigene Zeile. Zwei Tabellen gehören fachlich zusammen, ohne dass ein Fremdschlüssel das festhält.

Ein Sprachmodell, das nur das Schema sieht, muss diese Dinge erraten. Es rät oft plausibel – und genau das ist gefährlich, weil eine plausibel falsche Zahl nicht als falsch auffällt.

Im Referenztest ergab eine technisch völlig plausible Auswertung 92.232 Datensätze. Fachlich korrekt waren es 15.305.

Der Unterschied entstand allein dadurch, dass der betroffene Datenbereich nicht den aktuellen Zustand eines Vorgangs enthielt, sondern dessen vollständige Änderungshistorie. Beide Zahlen sehen ohne Kenntnis dieser Regel richtig aus. Ein Faktor 6 fällt in einem Bericht niemandem auf, der die Größenordnung nicht ohnehin kennt.

Abgrenzung

Kontext im Prompt oder Wissen im Modell.

Beides gibt einem Sprachmodell Informationen über Ihre Daten. Der Unterschied liegt darin, was danach davon übrig bleibt.

Schemainformationen im Prompt
Semantische Schicht
Gilt für diese eine Unterhaltung
Gilt für jede Frage, auch in einem Jahr
Wächst mit jeder Regel, bis der Kontext knapp wird
Wird abgefragt, wenn sie gebraucht wird
Fehlt eine Regel, entsteht stillschweigend eine Antwort
Fehlt eine Regel, wird die Lücke benannt
Wer die Regeln kennt, muss sie jedes Mal mitgeben
Die Regel ist einmal beschrieben und dann hinterlegt
Nicht prüfbar: Der Kontext verschwindet mit dem Chat
Prüfbar: Ein Fachbereich kann die Definition lesen
Korrektur wirkt für den nächsten Satz
Korrektur wirkt für jede gleichartige Frage danach

Inhalt

Was in der semantischen Schicht beschrieben ist.

Kein Datenbestand, sondern eine Beschreibung: Fachbegriffe und die Regeln, nach denen sie aus Ihren Daten ermittelt werden.

  • Fachbegriffe

    „Kunde“, „Auftrag“, „offene Rechnung“ – jeweils mit der Definition, die in Ihrem Haus gilt, und mit der Angabe, aus welchen Tabellen und Spalten der Begriff entsteht.

  • Beziehungen

    Welche Geschäftsobjekte fachlich zusammengehören und über welchen Weg. Das schließt Beziehungen ein, die im Schema nicht als Fremdschlüssel hinterlegt sind, sondern nur im Code aufgelöst werden.

  • Geschäftsregeln

    Bedingungen, die eine Auswertung erfüllen muss, damit sie fachlich richtig ist: Statuswerte, Ausschlüsse, Historisierung, Mandanten- oder Werksabgrenzung, Storno- und Testdatensätze.

  • Kennzahlen

    Wie eine Summe, ein Bestand oder eine Quote in Ihrem Haus gerechnet wird – einschließlich der Frage, was dabei nicht mitzählt. Zwei Abteilungen mit unterschiedlichen Definitionen sind hier ein Modellierungsfall, kein Streitfall.

  • Zeitbezüge

    Welches Datum gemeint ist, wenn jemand „dieses Jahr“ sagt: Erfassung, Auftragseingang, Rechnung, Zahlung oder Buchung. Bei historisierten Daten zusätzlich, auf welchen Stichtag sich ein Zustand bezieht.

  • Sichtbarkeit

    Welche Begriffe und Datenbereiche eine Rolle abfragen darf. Die Angabe liegt im Modell und wirkt vor der Auswertung – was eine Rolle nicht sehen darf, wird nicht abgefragt und nicht erst beim Anzeigen ausgeblendet.

In der Schicht liegen Beschreibungen, keine Geschäftsdaten. Sie ist damit auch keine Kopie Ihres Datenbestands.

Entstehung

Woher das Wissen kommt – und wer es verantwortet.

Der Aufwand liegt nicht im Protokoll und nicht in der Oberfläche, sondern hier. Von Hand dauert dieser Schritt Wochen; das ist der übliche Grund, warum solche Vorhaben abgebrochen werden, bevor sie etwas zeigen. Deshalb wird er KI-gestützt gemacht – mit einem klar davon getrennten zweiten Schritt.

  • Quellen: Datenmodell und Sourcecode

    Das Datenmodell liefert Strukturen und Beziehungen, der Sourcecode die Bedeutung: Statuswerte, Berechnungen, Sonderfälle. Beides zusammen ergibt einen ersten Entwurf des Modells.

  • Was daraus entsteht, ist ein Vorschlag

    Erkannte Begriffe, vermutete Beziehungen, abgeleitete Regeln – ausdrücklich als Entwurf. Was maschinell erschlossen wird, kann unvollständig oder fachlich falsch benannt sein; nichts davon gilt, bevor es bestätigt ist.

  • Ihre Fachbereiche entscheiden

    Geprüft wird im Klartext, nicht in SQL: Falsches wird korrigiert, Fehlendes ergänzt, Uneindeutiges entschieden. Das ist der Schritt, der Zeit auf Ihrer Seite kostet – und der sich nicht delegieren lässt.

  • Der Maßstab sind Fragen, deren Antwort Sie kennen

    Referenzfragen mit bekanntem Ergebnis zeigen, wo eine Regel noch fehlt oder falsch beschrieben ist. Ohne solche Fragen fehlt der Maßstab, an dem sich die Qualität überhaupt prüfen lässt.

Wie die Erschließung im Einzelnen arbeitet, gehört in ein technisches Gespräch und nicht auf eine öffentliche Seite. Für die Beurteilung des Ansatzes zählt, woher das Wissen stammt, wer es bestätigt und woran es gemessen wird.

Transparenz

Für die Erschließung verlässt Sourcecode in Ausschnitten das Haus.

„KI-gestützt“ heißt konkret: Code- und Strukturausschnitte werden an ein Sprachmodell übermittelt, das heute bei einem externen Anbieter läuft. Produktivdaten aus Ihrer Datenbank werden dafür nicht benötigt.

Welcher Anbieter, welche Vertragslage und welche Bereiche Ihres Repositorys einbezogen werden – und welche ausdrücklich nicht –, wird schriftlich festgelegt, bevor gelesen wird. Wenn Ihr Sourcecode selbst das Schutzgut ist, gehört diese Klärung an den Anfang und nicht ans Ende.

Was dabei übertragen wird

Pflege

Das Modell wächst. Trainiert wird nichts.

Ein Modell ist am Anfang nie vollständig. Entscheidend ist deshalb, was passiert, wenn eine Frage auf einen Begriff trifft, der noch nicht beschrieben ist.

Statt eine Antwort zu erzeugen, die niemand prüfen kann, wird die Lücke benannt: Welcher Begriff fehlt, in welchem Zusammenhang er gebraucht wurde, welche Beschreibung nötig wäre. Aus der unbeantwortbaren Frage wird ein Pflegeauftrag mit klarem Inhalt.

Wird der Begriff einmal beschrieben, gilt er dauerhaft – für diese Frage und für jede gleichartige danach.

Wichtig für die Einordnung: Hier lernt kein Modell. Es werden keine Gewichte angepasst und keine Ihrer Daten in ein Training gegeben. Es wird etwas aufgeschrieben, das vorher nicht aufgeschrieben war – nachlesbar, korrigierbar und jederzeit wieder änderbar.

Frage
Prüfung gegen semantisches Modell
Lücke erkannt
Begriff oder Regel fehlt im Modell
Ausgabe als Pflegeauftrag
Begriff wird fachlich beschrieben
Frage ist beantwortbar
↑ dauerhaft – auch für jede gleichartige Frage danach

Einordnung

Verhältnis zu Begriffen, die ähnlich klingen.

Der Begriff „semantische Schicht“ ist nicht neu. Er wird nur an unterschiedlichen Stellen für Unterschiedliches verwendet.

Semantic Layer im BI-Werkzeug
Beschreibt Kennzahlen und Dimensionen für Auswertungen, die vorher feststehen, und setzt in der Regel auf einem aufbereiteten Modell auf. Der Zweck hier ist ein anderer: eine offene Frage auf ein gewachsenes Produktivschema abbilden, ohne es vorher umzubauen.
Data Catalog
Dokumentiert, welche Datenbestände es gibt und wer sie verantwortet. Das ist Auffindbarkeit. Hier geht es darum, dass eine Auswertung fachlich richtig gerechnet wird.
Vektorindex / RAG
Sucht in Texten nach Ähnlichkeit und eignet sich für Dokumente. Für die Frage, welcher Kunde wie viele Aufträge hatte, ist Ähnlichkeit das falsche Werkzeug – gebraucht wird eine exakte Auswertung.
Feintuning
Passt ein Sprachmodell an. Das Wissen läge danach in Modellgewichten: nicht einsehbar, nicht gezielt korrigierbar und bei jeder Regeländerung erneut fällig. Eine beschriebene Regel ist an dieser Stelle das robustere Mittel.

Belastbarkeit

Was das Modell bisher tatsächlich getragen hat.

Das semantische Modell ist der Teil, der über die Qualität der Antworten entscheidet – und damit der Teil, der geprüft gehört. Für den aktuellen Stand liegen Zahlen aus einem Referenzsystem und aus drei unabhängigen Fremdsystemen vor.

Dort steht auch, welche Fälle nicht wie erwartet ausgingen und woran das lag.

Testergebnisse ansehen

Häufige Fragen

Fehlt Ihnen eine Frage? Ausführliche Antworten zu Betrieb und Datenzugriff stehen auf der Sicherheitsseite.

Ist das nicht dasselbe wie ein Semantic Layer im BI-Tool?

Die Idee ist verwandt, der Einsatzpunkt ist ein anderer. Ein BI-Semantic-Layer beschreibt Kennzahlen und Dimensionen für Auswertungen, deren Form vorher bekannt ist, und setzt meist auf einem bereits aufbereiteten Modell auf.

Hier ist die Ausgangslage ein gewachsenes Produktivschema, und die Frage steht vorher nicht fest. Das Modell muss deshalb nicht nur Kennzahlen kennen, sondern auch Beziehungen erschließen, die im Schema fehlen, und Sonderfälle wie Historisierung tragen. Wenn Sie bereits einen Semantic Layer betreiben, ist das kein Widerspruch – die dort gepflegten Definitionen sind eine gute Vorlage.

Was passiert mit dem Modell, wenn sich unser Datenmodell ändert?

Änderungen an Tabellen und Spalten treffen das Modell an den Stellen, die diese Tabellen verwenden. Weil im Modell steht, aus welchen Feldern ein Begriff entsteht, lässt sich benennen, welche Begriffe von einer Änderung betroffen sind.

Betrifft eine Änderung einen beschriebenen Begriff, ist die Beschreibung nachzuziehen. Das ist Pflegeaufwand und wird hier auch so genannt – ein Modell, das sich selbst aktuell hält, gibt es nicht.

Wem gehört das semantische Modell?

Das Modell beschreibt Ihre Fachlichkeit und bleibt Ihr Eigentum. Es liegt in Ihrer Umgebung und ist in lesbarer Form exportierbar.

Das ist bewusst so gebaut: Der Inhalt dieser Schicht ist genau das Wissen über Ihr System, das heute verstreut in Sourcecode und Köpfen liegt. Es an einen Anbieter zu binden, würde das Problem nur verlagern.

Wie groß wird so ein Modell bei einem gewachsenen System?

Das hängt davon ab, wie viel Fachlichkeit tatsächlich abgefragt werden soll. Ein vollständiges Schema hat schnell mehrere hundert Attribute, aber nur ein Teil davon wird für Auswertungen gebraucht.

In der Praxis ist es deshalb sinnvoll, mit den Bereichen zu beginnen, zu denen es echte Fragen gibt, und das Modell entlang der tatsächlich gestellten Fragen wachsen zu lassen. Ein Modell, das erst nach Monaten fertig ist, hat bis dahin nichts gezeigt.

Verwandte Themen

Angrenzende Fragen, jeweils auf einer eigenen Seite beantwortet.

Der ehrlichste Test ist eine Frage, deren richtige Antwort Sie schon kennen.