Ein Semantic Layer, damit KI Ihre Finanzkennzahlen spricht

Ein Semantic Layer ist ein Governance-gestützter Katalog, der zwischen Ihren Rohtabellen und allem sitzt, was diese abfragt, und für jede Kennzahl und Dimension genau eine kanonische Definition vorhält. Wenn ein Dashboard, ein Notebook oder ein KI-Agent nach dem Nettoumsatz fragt, wird jede Anfrage in dieselbe Query aufgelöst, mit denselben Filtern und derselben Währungsbehandlung darunter. Die Definition lebt an einer einzigen Stelle, statt von jedem, der gerade fragt, neu hergeleitet zu werden.

Das Problem, das er löst, ist von langweiliger Alltäglichkeit. Finance fragt das Data Warehouse nach dem Umsatz und bekommt eine Zahl. Jemand zieht denselben Zeitraum aus dem Abrechnungssystem und bekommt eine andere. Beide sind vertretbar, denn jede kodiert eine leicht abweichende Regel für Gutschriften, Erstattungen, abgegrenzte Beträge und den genauen Zeitpunkt der Umsatzrealisierung. Multiplizieren Sie das mit jeder Kennzahl, die ein Unternehmen ausweist, und Sie erhalten einen permanenten, schwelenden Streit darüber, wessen Zahl die richtige ist. Setzen Sie einen KI-Agenten in diese Umgebung, und der Streit wird schneller, nicht beigelegt. Das Modell generiert bereitwillig einen selbstbewussten Satz, der genau die Umsatzzahl enthält, die es zufällig abgefragt hat.

Warum KI das Kennzahlenproblem dringlich macht

Jahrelang lebte die Branche mit der Definitionsdrift, weil ein Mensch zwischen Query und Entscheidung saß. Ein Analyst, der sah, dass der Umsatz 8 % zu niedrig zurückkam, wusste zu prüfen, ob Erstattungen saldiert wurden, und korrigierte die Query stillschweigend. Dieser Mensch ist ein Filter, er ist teuer, und er skaliert nicht auf Hunderte spontaner Fragen pro Tag.

Wenn Sie ein Sprachmodell SQL gegen physische Tabellen schreiben lassen, entfernen Sie den Filter und behalten die Mehrdeutigkeit. Das Modell hat keine Ahnung, dass amount_usd in der Tabelle invoices bereits ohne Steuer ausgewiesen ist, während die Tabelle orders sie enthält. Es sieht zwei plausible Spalten und wählt eine. Es steckt keine böse Absicht dahinter und kein offensichtlicher Fehler, den man abfangen könnte. Die Ausgabe ist grammatikalisch korrekt, sauber formatiert und um genau den Betrag der Steuerposition falsch.

• Ein Modell, das nach Churn gefragt wird, rät den Nenner: Logos, Seats oder Dollar, und ob Downgrades mitgezählt werden.
• Ein Modell, das nach der Bruttomarge gefragt wird, rät, welche Kostenblöcke oberhalb der Linie stehen.
• Ein Modell, das nach dem Umsatz gefragt wird, rät die Realisierungsregel, das Währungsdatum und ob Konsolidierungsbuchungen (Intercompany-Eliminierungen) greifen.

Jede einzelne Schätzung ist für sich genommen vernünftig und in der Summe nicht prüfbar. Der Semantic Layer beseitigt das Raten. Das Modell schreibt nicht mehr SELECT SUM(amount); es fordert die Kennzahl namens net_revenue für eine Zeitgranularität und eine Menge von Dimensionen an, und der Layer kompiliert diese Anfrage in die eine Query, die Ihr Finance-Team freigegeben hat.

Was tatsächlich im Layer liegt

Ein nützlicher Semantic Layer ist mehr als ein Wörterbuch von Spalten-Aliassen. Er hält die Bestandteile einer Kennzahl fest, die man üblicherweise implizit lässt und über die man sich später uneinig wird.

• Das Measure und seine Aggregation. Nicht nur „Umsatz”, sondern der exakte Ausdruck, die Granularität, auf der er gültig ist, und ob er summiert, mittelt oder ein Distinct Count erfordert.
• Join-Pfade und Entity Resolution. Wie ein Kunde in der Abrechnung auf einen Kunden im CRM und auf eine Einheit im Hauptbuch abgebildet wird, damit eine nach Kunde geschnittene Kennzahl überall denselben Kunden meint.
• Zeitsemantik. Welches Datum die Kennzahl steuert (Booking, Rechnung, Realisierung, Cash) und wie sie Point-in-time Correctness behandelt, damit eine restated Vorperiode nicht stillschweigend die ausgewiesene Zahl des letzten Quartals umschreibt.
• In die Definition eingebackene Filter. Testkonten ausgeschlossen, Intercompany eliminiert, eine bestimmte Menge von Status, die als aktiv zählen. Das sind die Regeln, die es nie in einen Dashboard-Titel schaffen und die meiste Drift verursachen.
• Währungs- und Einheitenbehandlung. Die Quelle des Umrechnungskurses und das Datum, an dem er angewendet wird, damit ein EUR-Vertrag, der in USD ausgewiesen wird, nicht um einen Monat FX-Bewegung danebenliegt.
• Lineage und Ownership. Welche physischen Tabellen die Kennzahl speisen, wem die Definition gehört und wann sie zuletzt geändert wurde. Das ist es, was aus einer KI-generierten Zahl etwas mit einem Prüfpfad dahinter macht.

Der letzte Punkt wiegt im Finanzbereich schwerer als fast irgendwo sonst. Wenn eine Zahl in einem Board-Deck oder einer regulatorischen Meldung landet, muss jemand sie bis zur Quelle zurückverfolgen können. Eine im Semantic Layer definierte Kennzahl trägt diese Lineage konstruktionsbedingt in sich. Eine Kennzahl, die ein Modell aus rohem SQL rekonstruiert hat, trägt nichts als das Selbstvertrauen des Modells.

Governance ist der schwierige Teil, nicht die Query-Engine

Die Technik, benannte Kennzahlen in SQL zu kompilieren, ist gut ausgetreten. Mehrere Open-Source- und kommerzielle Engines leisten das. Die Arbeit, die darüber entscheidet, ob der Layer gelingt, ist organisatorisch, und genau dort investieren die meisten Projekte zu wenig.

Jemand muss jede Definition besitzen, und Änderungen müssen den Review durchlaufen, so wie Code es tut. Ein Pull Request, der ändert, wie Churn berechnet wird, sollte sichtbar, diskutiert und versioniert sein, denn er verändert jede nachgelagerte Zahl in dem Moment, in dem er gemergt wird. Wir behandeln Kennzahlendefinitionen als Code: Sie liegen im Repository, sie haben Tests, und ein vorgeschlagener Change läuft gegen eine Menge bekannter Zeiträume, um vor jeder Freigabe genau zu zeigen, wie sich die ausgewiesenen Zahlen verschieben.

Dieses Test-Harness lohnt sich früh aufzubauen. Halten Sie für jede Kennzahl eine kleine Menge von Zeiträumen mit einem handverifizierten Erwartungswert vor, so wie Sie ein Eval-Set für ein Modell vorhalten würden. Wenn jemand die Definition bearbeitet, berechnet das Harness diese Zeiträume neu und markiert jeden, der sich verändert hat. Die meisten Änderungen sollten nichts verschieben; diejenigen, die es tun, sind die, bei denen ein Mensch abzeichnen muss. So fangen Sie das gut gemeinte Refactoring ab, das stillschweigend einen Kostenblock über die Margenlinie verschoben hat.

Die Reconciliation gehört an dieselbe Stelle. Die Umsatzkennzahl des Semantic Layer sollte planmäßig mit dem Hauptbuch abgeglichen werden (tie-out), und eine Abweichung sollte einen Alert auslösen, statt bis zum Quartalsende zu warten, um aufzutauchen. Sobald dieser Abgleich automatisiert ist, hört der Layer auf, eine Bequemlichkeit für Analysten zu sein, und wird zu dem, worauf Sie einen Agenten ansetzen können, ohne die Luft anzuhalten. Das Modell fragt eine Kennzahl an, bekommt eine Zahl, die bereits mit den Büchern abgestimmt ist, und zitiert eine Definition, die eine Person besitzt. Das ist der Unterschied zwischen KI, die eine plausible Zahl entwirft, und KI, die Sie einem Wirtschaftsprüfer vorlegen können.