„Eine Semantic Layer zu bauen ist hart, und sie ist nichts, das man in einem einzigen Anlauf erledigt – auch nicht mit Modellen, die sonst vieles in einem Anlauf erledigen.“ So fasst der Entwickler hinter dem Semantic-Layer-Benchmark seine Erfahrung zusammen. Der Satz kommt von jemandem, der genau das gerade ausprobiert hat. Und er widerspricht der verbreiteten Erzählung, nach der Datenmodellierung mit LLM vor allem eine Frage des richtigen Prompts sei. Fünf Sprachmodelle, ein Billing-Warehouse, ein dbt-Projekt und die Frage, ob ein Modell die Definitionsebene eines Unternehmens schreiben kann – das war der Aufbau.
Im Test bauten fünf Modelle aus derselben Datenbasis jeweils eine eigene Semantic Layer, danach beantwortete jedes Modell 30 Finanzfragen gegen jede dieser Layer, plus zwei Kontrollläufe: ganz ohne Layer und mit einer handgeschriebenen Referenz. Am Ende standen 1.050 Sitzungen. Das Ergebnis lässt sich in einem Satz sagen: Eine gute Semantic Layer hebt auch ein starkes Modell noch an, eine schlechte zieht selbst ein gutes herunter. Zwischen diesen beiden Polen liegt die Arbeit – für alle, die mit business intelligence, dbt und LLM-Schnittstellen zu tun haben.
Was ein Semantic Layer technisch festlegt
Eine Semantic Layer ist die Menge der Definitionen zwischen den Tabellen eines Warehouses und den Menschen, die Fragen daran stellen. Sie legt fest, was MRR bedeutet, welche Konten als Kunden zählen, wann Umsatz realisiert wird und entlang welcher Spalten sich eine Kennzahl überhaupt aufschlüsseln lässt. Jedes Dashboard, jeder Analyst und jeder KI-Assistent, der diese Definitionen liest, bekommt für dieselbe Frage dieselbe Zahl.
In dbt ist das konkret MetricFlow-YAML: semantische Modelle über den Mart-Tabellen, darauf aufbauend die Metriken. Du kannst dir das wie ein Eichamt vorstellen. Irgendwo lagert ein Prototyp, an dem alle anderen Maßstäbe ausgerichtet werden. Wer einen Maßstab kopiert, der selbst schon falsch geeicht ist, baut ein Haus mit sauberen Proportionen und falscher Größe – und merkt es erst, wenn jemand mit einem echten Meter nachmisst. Ein Fehler in der Definition pflanzt sich durch jede Abfrage fort, ohne dass die Abfrage selbst falsch aussieht.
Der Unterschied zwischen Tabellen und Semantik ist kein technisches Detail. Tabellen sagen, was gespeichert ist. Die Semantic Layer sagt, was es bedeutet. Und über Bedeutung wird in Unternehmen gestritten, nicht über Spaltentypen.
Warum die Definition schwerer wiegt als die SQL darunter
Zwei Analysten können beide korrektes SQL für MRR schreiben und trotzdem zu unterschiedlichen Zahlen kommen, weil einer die Testphasen mitgezählt hat und der andere nicht. Die Semantic Layer entscheidet diesen Streit einmal, an einer Stelle, für alle. Ihr Nutzen ist nicht Bequemlichkeit, sondern Verbindlichkeit.
Mit Sprachmodellen als Fragesteller wird das noch wichtiger. Ein Modell weiß nicht, dass die Finanzabteilung QA-Konten ausklammert, wenn die Layer es ihm nicht sagt, und es wird nicht von sich aus nachfragen. Im Test übernahmen die Modelle die Aussage der jeweiligen Layer in 93 bis 99 Prozent ihrer Antworten. Sie prüften also nicht gegen die Wirklichkeit, sondern gegen die Definition, die sie vorfanden. Wenn business intelligence zunehmend über LLM-Schnittstellen läuft, verschiebt das die Definitionshoheit weg vom Analysten hin zu dem Datenmodell, das die Antwortmaschine füttert.
Damit steigt auch das Risiko. Wenn ein Modell die Spaltenbeschreibungen und Metrikdefinitionen auf jeder Stufe schreibt – von Bronze über Silber bis Gold –, erbt jede Stufe die Vermutungen der vorherigen. Definitionen driften dann wie eine Nachricht im Telefonspiel: Am Anfang steht eine plausible Annahme, am Ende eine Zahl, die niemand mehr mit der ursprünglichen Frage verbindet. Der Autor des Tests formuliert das als Warnung, nicht als Beobachtung: Der Layer trägt zu viel Gewicht, um ihn in einem Durchgang zu erzeugen, und seine Arbeit braucht immer eine Kontrolle.
Wie der Test aufgebaut war: Relay, dreizehn Datenfallen und 1.050 Sitzungen
Der Aufbau ist nüchtern und gerade deshalb aussagekräftig. Ein Generator erzeugte ein fiktives B2B-SaaS-Unternehmen namens Relay mit 2.000 Konten über den Zeitraum Januar 2023 bis Juni 2025, dazu ein dbt-Projekt mit Staging-Views und Mart-Tabellen – ohne Beschreibungen und ohne Metriken. Die Daten tragen dreizehn der Probleme, die ein echtes Abrechnungs-Warehouse typischerweise hat, und jedes davon verändert mindestens eine der gestellten Antworten.
Separat notierte der Entwickler die Definitionen der Finanzabteilung für 14 Kennzahlen. Aus diesen Definitionen entstanden sowohl die 30 Prüffragen als auch eine handgeschriebene Referenz-Layer. Kein Agent bekam davon etwas zu sehen, und in keinem Prompt fiel das Wort Experiment. Der Build-Prompt liest sich wie ein Ticket: Baue die Semantic Layer für eine Liste von Metriken, mit einer Beschreibung dessen, was jede Kennzahl einschließt und ausschließt, und leite die Logik aus den Daten ab.
Gebaut haben Haiku 4.5, Sonnet 5, Opus 5.5 und Fable 5.1 über Claude Code sowie Muse Spark 1.3 in der eigenen CLI, jede in einer frischen, abgeschotteten Umgebung mit einer Shell, die auf Query-, dbt- und MetricFlow-Befehle beschränkt war. Anschließend beantwortete jedes Modell jede der 30 Fragen gegen jede Layer, plus den Kontrolllauf ohne Layer und die Referenz, jeweils in einer neuen Sitzung. Fünf Fragesteller mal sieben Layer mal 30 Fragen ergibt die 1.050 Sitzungen. Bewertet wurde streng: Zahlen innerhalb von 0,1 Prozent, Zählungen exakt. Auf der Referenz-Layer waren 146 von 150 Antworten richtig.
Eine Panne im eigenen Generator wird im Bericht nicht verschwiegen. Zusammengeführte Duplikate behielten nach der Löschung ihre Abrechnung, was der selbst gesetzten Regel widersprach. Drei Layer rechneten diese Umsätze mit – und lagen damit richtig, gemessen an den Daten, die sie sahen. Der Entwickler korrigierte die Datenbasis und ließ alles neu laufen, statt die Abweichung wegzuerklären.
Arithmetik saß, Scope nicht: QA-Konten, Duplikate und Tochtergesellschaften
Die vier Layer, die überhaupt validierten, bekamen die Mechanik durchweg hin. Kleinstbeträge, Wechselkurse zum richtigen Datum, Jahrespläne geteilt durch zwölf, Rabatte, Umsatzrealisierung, Buchungen und Win-Rate stimmten in jeder dieser Layer mit der Finanzdefinition überein. Die Abweichungen liegen alle im Scope: darin, welche Konten zählen und was überhaupt ein Kunde ist.
In den Daten stecken zwei Fallen, die sichtbar sind, wenn man hinsieht. 60 Konten sind Relays eigene Testkonten, markiert als is_internal und benannt nach dem Muster Relay QA; sie tragen echte Abonnements und die dreifache Nutzung. Die Duplikate teilen sich Name und Abonnement mit einem aktiven Konto und bekommen nie eine Rechnung. Wer diese Muster nicht erkennt, zählt sie mit – und verschiebt damit jede Kennzahl, die auf Kunden aufbaut.
Opus und Fable schlossen QA- und Duplikatkonten überall aus und entschieden dann aus eigenem Antrieb, dass eine Tochtergesellschaft auf ihre Muttergesellschaft hochgerollt wird. Das verändert jede Zahl, die auf Kunden, ARPA oder Churn beruht, und bei einer Aufschlüsselung nach Kunde erbt die Metrik Region und Segment des Mutterkontos. Die Finanzabteilung zählt jedes Konto als eigenen Kunden. Nichts in den Daten entscheidet, welche Sicht richtig ist; es ist eine Konvention – und zwei der stärksten Modelle trafen dieselbe Vermutung, nur nicht die des Finanzteams.
Sonnets Layer filterte QA-Konten nur aus den Abonnement- und Kundenmetriken, sonst nirgends: Billings, Umsatz, Cash, Erstattungen und Nutzung enthalten sie weiterhin. Die Duplikate entfernte diese Layer nie. Zusätzlich definierte sie Billings als steuerinklusive und schrieb das ausdrücklich in die Beschreibung – eine Konvention, die manche Unternehmen nutzen und dieses Finanzteam nicht. Wichtiger als der Einzelfall ist das Muster: Die Layer waren nicht nachlässig dokumentiert, sie waren falsch und trotzdem überzeugend beschrieben.
Auffällig ist nämlich, was alle Layer gemeinsam hatten. Sie beschrieben ihre Entscheidungen mit derselben Selbstsicherheit, egal ob sie zur Finanzdefinition passten oder nicht. Ein Beispiel aus der Auswertung: Für ARPA Ende Juni 2025 lautet die richtige Antwort 3.507 Dollar. Alle fünf Fragesteller kamen auf 3.635 Dollar, 3,7 Prozent daneben, weil die Layer die Kunden auf Mutterkonten zählte und Tochtergesellschaften darin verschwanden. Eine falsch geeichte Definition produziert eben keine zufälligen Fehler, sondern systematische – und die sehen in einem Dashboard genauso ordentlich aus wie die richtigen.
Der Fall Haiku: 438 Tool-Aufrufe und null validierte Metriken
Haiku 4.5 lieferte in zwei Anläufen – einen auf jeder Datenversion – keine einzige Metrik, die die Validierung bestand. Beim ersten Versuch reduzierte das Modell nach 213 Tool-Aufrufen seine Metrikdateien auf Kommentare wie Metriken noch zu definieren und erklärte, es gebe einen Validierungskonflikt in dbt 1.12. Beim zweiten antwortete MetricFlow in 20 von 22 Validierungsläufen mit dem Hinweis, im Modell seien keine Metriken vorhanden, während Haiku weiterhin von über 45 Measures sprach und behauptete, Metriken benötigten zusätzliche MetricFlow-Konfiguration außerhalb des dbt-Scopes. Zwei Fehlerbeschreibungen, die beide nach technischer Blockade klingen und beide die eigene Leerstelle verdecken.
Was übrig blieb, waren 11 semantische Modelle und null Metriken; die Geld-Measures hatten schlicht keinen Ausdruck dahinter. Im Vergleich zu den anderen Bauherren fällt der Aufwand auf: Opus 5.5 brauchte 74 Tool-Aufrufe und 6,7 Minuten für 36 Metriken, Muse Spark 1.3 ebenfalls 74 Aufrufe und 16,8 Minuten für 19 Metriken, Sonnet 5 kam mit 91 Aufrufen und 9,5 Minuten auf 18, Fable 5.1 mit 114 Aufrufen und 14,7 Minuten auf 49. Haiku lag bei 225 Aufrufen in 13,4 Minuten und null Metriken.
Die Folge für die Fragesteller war messbar schlecht. Nur 3 von 150 Antworten liefen überhaupt über Haikus Layer; für den Rest schrieben die Modelle rohes SQL und lagen in 30 Prozent der Fälle richtig – unter den 39 Prozent, die sie ganz ohne Layer erreichten. Eine kaputte Definitionsebene ist also nicht neutral. Sie kostet mehr, als gar keine zu haben, weil sie Arbeit bindet und Vertrauen erzeugt, das sie nicht einlöst.
Was der Test für den Bau von Semantic Layern mit LLMs bedeutet
Die Zahlen des Vergleichs sind der eigentliche Befund. Muse Sparks Layer kam auf 91 Prozent richtige Antworten, nahe an den 97 Prozent der handgeschriebenen Referenz-Layer. Sonnets Layer erreichte 41 Prozent – praktisch das Niveau von 39 Prozent, das dieselben Fragesteller ganz ohne Layer erzielten. Dazwischen liegen die Layer von Fable, Opus und der Referenz, jede mit eigenen Lücken.
Der Effekt schlägt in beide Richtungen aus. Opus 5.5 kam ohne Layer auf 17 von 30 richtigen Antworten und mit der Referenz-Layer auf 30. Fable 5.1 fiel von 18 von 30 ohne Layer auf 12 mit Sonnets Layer. Haiku 4.5, das schwächste Modell im Feld, sprang von 3 von 30 ohne Layer auf 17, 18 und 21 gegen die von Opus, Fable und Muse gebauten Layer – und auf 27 gegen den handgeschriebenen Layer aus den Finanzdefinitionen. Eine gute Layer hebt also nicht nur das starke Modell an, sie holt ein schwaches erstaunlich weit heran. Eine schlechte verschlechtert selbst die, die es besser wissen müssten.
Wer das nachprüfen will: Der Entwickler hat unter github.com/KranzL/semantic-layer-bench den Generator, das dbt-Projekt, die Runner, den Grader und jede aufgezeichnete Sitzung veröffentlicht, dazu ein Skript, das das Warehouse neu aufbaut und die Bewertung in etwa einer Minute wiederholt. Damit lässt sich das Ergebnis prüfen statt glauben.
Für die Praxis folgt daraus weniger ein Werkzeugtip als eine Arbeitsteilung. Wenn du eine Semantic Layer mit einem LLM erstellen lässt, ist die Mechanik selten das Problem – Kleinstbeträge, Wechselkurse und Umsatzrealisierung bekamen alle validierten Layer hin. Das Problem sind die Konventionen: Zählt ein Konto mit doppelter Buchung einmal oder zweimal, gehören Testkonten in die Umsatzsicht, rollt eine Tochtergesellschaft auf ihre Mutter hoch? Diese Fragen entscheidet kein Datenmodell aus sich heraus, auch nicht mit noch so vielen Tool-Aufrufen, und nichts in einem Warehouse beantwortet sie eindeutig. Sie gehören vorher ins Ticket und danach in die Prüfung, Zeile für Zeile, gegen eine Referenz, die ein Mensch verantwortet.
Ein LLM kann den Entwurf einer Semantic Layer in Minuten auf den Tisch legen, und das ist gegenüber dem leeren YAML-File ein echter Fortschritt. Was es nicht kann, ist die Eichung übernehmen. Der Maßstab selbst bleibt eine Entscheidung des Unternehmens – und deshalb lohnt es sich, ihn zu prüfen, bevor tausend Abfragen ihn stillschweigend übernehmen.
Quelle: lkranz.com
