Stell dir vor, du bist Vertriebsleiter. Du willst wissen: „Welche unserer Top-10-Kunden haben dieses Quartal weniger bestellt als im Vorjahr?” Heute tippst du ein Ticket an die IT, wartest zwei Tage, bekommst eine Excel-Datei — und merkst, dass die Frage leicht anders verstanden wurde.
Das ist kein Randproblem. Das ist der Alltag in den meisten mittelständischen Unternehmen, die ein ERP-System betreiben. Die Daten sind da. Der Zugang fehlt.
Genau das versuche ich gerade zu lösen: unsere ERP-Daten mit einer selbst gehosteten KI zu verbinden, so dass Business-Teams Fragen in normaler Sprache stellen und präzise Antworten bekommen — ohne Entwickler-Vermittlung. Was dabei auffällt: Der offensichtliche Ansatz funktioniert nicht so gut wie erwartet. Und der richtige Ansatz ist einen Gedanken tiefer.
Das Text-to-SQL-Versprechen — und wo es bricht
Text-to-SQL ist die naheliegende Idee: Der Nutzer stellt eine Frage in natürlicher Sprache, ein LLM übersetzt sie in SQL, die Datenbank gibt eine Antwort zurück. In Demos sieht das beeindruckend aus. Frontier-Modelle wie Claude 4, GPT-5 oder Gemini 2.5 Pro erreichen auf dem Spider-Benchmark über 85 % Genauigkeit — eine Zahl, die Vertrauen weckt.
Das Problem: Spider ist ein Lehr-Datensatz. 5 bis 10 Tabellen, klar benannte Spalten, saubere Beziehungen. Dein ERP sieht anders aus.
Spider 2.0 wurde mit echten Enterprise-Schemas aus Snowflake- und BigQuery-Deployments gebaut — hunderte Spalten pro Tabelle, Spalten wie usr_trx_fl und tmp_stage_agg, domänenspezifische Abkürzungen, die nur jemand mit fünf Jahren Firmenerfahrung entschlüsseln kann. Das Ergebnis: Die Genauigkeit der besten Modelle bricht auf unter 25 % ein. Die implizite Business-Logik, die in echten Produktivsystemen steckt, ist für kein Modell aus dem Schema allein lesbar.
Ohne Semantic Layer liegen reale Enterprise-Deployments laut aktuellen Untersuchungen bei 10–31 % Genauigkeit auf echten Produktiv-Daten.
Das eigentliche Problem: SQL das lügt
Das Tückische an Text-to-SQL-Fehlern ist nicht, dass Queries abstürzen. Es ist, dass sie erfolgreich laufen und trotzdem falsche Zahlen zurückgeben.
Drei klassische Muster aus der Praxis:
Fan-out-Fehler: Ein LLM fragt „Gesamtumsatz pro Kunde” und schreibt einen JOIN zwischen customers, orders und order_items. Korrekte Syntax — aber weil orders bereits mehrere Zeilen pro Kunde hat und order_items nochmal mehrere Zeilen pro Bestellung, explodiert das Ergebnis. Ein Kunde mit 10 Bestellungen à 5 Artikel bekommt statt des richtigen Umsatzes den 5-fachen Wert zurück. Kein Fehler, kein Warning, falsche Zahl im Dashboard.
Begriffsambiguität: „Umsatz” bedeutet für den Vertrieb gebuchte Aufträge, für die Finanzbuchhaltung anerkannte Erlöse und für Marketing das Bruttobestellvolumen. Das LLM wählt eine Interpretation — und niemand weiß welche, bis Zahlen sich widersprechen.
Versteckte Business-Logik: Ein Logistikunternehmen meldete über sein BI-Tool 98 % pünktliche Lieferungen. Die neue KI, die direkt auf Rohspalten zugreift, kam auf 92 %. Der Unterschied: Das BI-Tool schließt „vom Kunden akzeptierte Verzögerungen” aus. Diese Logik existiert im Code des Reporting-Tools — nicht in der Datenbank. Das LLM weiß das nicht.
Was ein Semantic Layer ist
Ein Semantic Layer ist eine explizite Definitionsschicht zwischen deiner Datenbank und dem LLM. Statt dem Modell zu sagen „hier ist das Schema, bau mir SQL”, definierst du Geschäftsbegriffe ein einziges Mal in Code:
# Beispiel: dbt MetricFlow Semantic Model
metrics:
- name: monthly_revenue
label: Monatlicher Umsatz
description: >
Anerkannte Erlöse aus abgeschlossenen Aufträgen,
exkl. Stornierungen und Gutschriften.
type: simple
type_params:
measure: net_revenue_usd
filter: |
{{ Dimension('order__status') }} = 'recognized'Ab jetzt bedeutet monthly_revenue für jeden, der das System befragt, exakt dasselbe. Das LLM muss nicht mehr raten, welche Tabelle, welches Feld, welches Filter. Es wählt nur noch: welche Metrik, welcher Zeitraum, welche Dimension — und der Semantic Layer generiert das SQL deterministisch.
Das ist der Kern des Unterschieds: probabilistische SQL-Generierung vs. deterministische Query-Ausführung.
Der direkte Vergleich — gleiche Frage, zwei Ansätze
Frage des Buchhalters: „Wie hoch waren unsere Außenstände über 60 Tage Ende letzten Monats?”
Plain Text-to-SQL
Das LLM bekommt das Schema: ar_transactions, customers, invoices, payments. Es produziert:
SELECT c.customer_name, SUM(i.amount - COALESCE(p.paid_amount, 0)) AS outstanding
FROM invoices i
JOIN customers c ON i.customer_id = c.id
LEFT JOIN payments p ON i.invoice_id = p.invoice_id
WHERE i.due_date < CURRENT_DATE - INTERVAL '60 days'
GROUP BY c.customer_nameLäuft durch. Gibt Zahlen zurück. Aber: Es fehlt der Filter auf invoice_status = 'open'. Bezahlte Rechnungen mit Datum über 60 Tage sind noch drin. Das Ergebnis ist zu hoch — und niemand merkt es, weil die Zahl plausibel wirkt.
Mit Semantic Layer
Das Modell ist definiert:
overdue_receivables_60d= offene Rechnungssumme, Fälligkeit > 60 Tage, exkl. bezahlte und stornierte- Dimension:
customer,region,account_manager
Das LLM fragt: get_metric("overdue_receivables_60d", time_grain="month", dimensions=["customer"]). Der Semantic Layer kompiliert daraus immer dasselbe, korrekte SQL — unabhängig davon, wie die Frage formuliert war.
Die Zahlen aus dem aktuellen Benchmark
dbt Labs hat im April 2026 ihren Benchmark zwischen Text-to-SQL und Semantic Layer wiederholt — diesmal mit den neuesten Modellen:
| Modell | Methode | Genauigkeit |
|---|---|---|
| Claude Sonnet 4.6 | Text-to-SQL | 90,0 % |
| Claude Sonnet 4.6 | Semantic Layer | 98,2 % |
| GPT-5.3 Codex | Text-to-SQL | 84,1 % |
| GPT-5.3 Codex | Semantic Layer | 100,0 % |
Auf rohen, unnormalisierten Tabellen (wie sie in echten Systemen vorkommen) lagen Text-to-SQL-Systeme 2023 noch bei 32,7 % Gesamtgenauigkeit. Mit einem ordentlich modellierten Semantic Layer: 72,7 % bis 100 % — je nach Fragetyp.
Die wichtigste Erkenntnis aus dem Benchmark ist aber nicht die Zahl selbst:
Wenn der Semantic Layer eine Frage nicht beantworten kann, sagt er es. Text-to-SQL gibt dir eine falsche Antwort, die wie eine richtige aussieht.
Das ist der Unterschied zwischen einem Fehler, den du siehst, und einem, den du erst im Board-Meeting bemerkst.
Konkrete ERP-Anwendungsfälle
Das ERP-System ist der Ort, wo solche Fragen am häufigsten gestellt werden. Und es ist das klassische Beispiel für ein System mit hunderten Tabellen, internen Abkürzungen und Business-Logik, die nirgendwo dokumentiert ist.
Buchhaltung:
- „Welche Kunden haben offene Posten über 30 Tage, die wir noch nicht gemahnt haben?”
- „Wie entwickelt sich unser Cash-Flow in den nächsten vier Wochen?”
Einkauf / Lager:
- „Welche Artikel liegen unter dem Meldebestand und haben einen aktiven Lieferanten?”
- „Was kostet uns der Lagerbestand der Artikel, die in den letzten 90 Tagen nicht bewegt wurden?”
Vertrieb:
- „Top 10 Kunden nach Deckungsbeitrag dieses Quartal, sortiert nach Veränderung zum Vorjahr”
- „Welche Kunden haben seit 90 Tagen keine Bestellung gemacht, waren aber vorher regelmäßig aktiv?”
Produktion:
- „Welche Fertigungsaufträge der nächsten zwei Wochen sind gefährdet wegen Materialunterdeckung?”
Alle diese Fragen spannen mehrere ERP-Module auf. Kein Modul gibt allein eine Antwort. Und ohne Semantic Layer muss das LLM die Joins, Filter und Definitionen jedes Mal neu erfinden — mit entsprechend variablen Ergebnissen.
Die Tooling-Landschaft 2026
Der Markt hat sich in zwei Lager aufgeteilt:
Headless (plattformagnostisch):
- dbt MetricFlow — Code-first, YAML-basiert, generiert SQL zur Laufzeit und schiebt es gegen jedes Warehouse. Open Standard, Teil von OSI (Open Semantic Interchange).
- Cube.dev — Semantic Layer plus MCP-Server, damit AI-Agents Metriken direkt als Tools aufrufen können (
get_metric()statt SQL-Generierung). Besonders gut für multi-tool Setups. - Wren AI — Open-Source, einsteigerfreundlich, mit eigenem Metadata Definition Language (MDL). Gut für Teams, die schnell starten wollen.
Platform-native:
- Snowflake Cortex / Databricks Unity Catalog — YAML-basierte Metric Views direkt im Warehouse. Weniger Lock-in als früher, gut wenn ihr ohnehin in einem dieser Ökosysteme lebt.
- Microsoft Fabric / Power BI Semantic Link — Stark für Microsoft-zentrierte Stacks. November 2025 kam ein öffentlicher Preview des Power BI Modeling MCP Servers.
Mein Ansatz: Erst die Tier-0-Metriken
Was ich gerade aufbaue: Eine selbst gehostete KI-Instanz, die über einen Semantic Layer auf unsere ERP-Daten zugreift. Kein SaaS, keine Daten in fremden Clouds, volle Kontrolle.
Was ich dabei gelernt habe: Nicht mit allen 500 Tabellen anfangen. Das überfordert sowohl die Modellierung als auch die LLMs beim Routing.
Stattdessen: 10 bis 20 „Tier-0-Metriken” definieren — die KPIs, die täglich nachgefragt werden. Umsatz, offene Posten, Lagerreichweite, Lieferquote. Diese sauber in YAML definieren, testen, validieren. Dann schrittweise erweitern.
Text-to-SQL bleibt dabei als Fallback: Für Ad-hoc-Fragen, die noch nicht im Semantic Layer modelliert sind, lässt man das LLM SQL generieren — aber mit dem Wissen, dass es probabilistisch arbeitet und validiert werden sollte. Für alles was in Reports, Dashboards oder regelmäßigen Abfragen landet: Semantic Layer.
Die dbt-Empfehlung deckt sich mit meiner Erfahrung:
Text-to-SQL für Exploration und Prototyping. Semantic Layer für alles, was im Board-Meeting, bei Auditoren oder in wöchentlichen Berichten landet.
Fazit
Die Frage ist nicht mehr, ob Business-Teams natürliche Sprache für Datenabfragen nutzen werden. Das wird passieren. Die Frage ist, ob die Antworten vertrauenswürdig sind.
Plain Text-to-SQL ist ein starker Einstieg — aber in Production ein Risiko. Nicht weil LLMs schlecht sind. Sondern weil Business-Logik nicht in Tabellennamen steckt. Sie steckt in den Köpfen von Leuten, die das System seit Jahren kennen. Ein Semantic Layer macht diese implizite Logik explizit, versionierbar und für jede KI nutzbar — egal ob du nächstes Jahr das Modell wechselst.
Wenn du an einem ähnlichen Setup arbeitest — ERP-Daten zugänglich machen, AI sinnvoll einsetzen, Kontrolle über die Infrastruktur behalten — sprich mich gerne an. Ich teile gerne, was funktioniert und was nicht.