Die stille Wende: von „das Modell fragen» zu „Agenten über den Daten orchestrieren»
Während 2024 und eines großen Teils von 2025 drehte sich die Diskussion über Sprachmodelle in der Datenanalyse um den Chat: eine CSV-Datei einfügen, ein Diagramm anfordern, eine Tabelle erhalten. Dieses Muster erschöpft sich. Was die jüngsten Entwicklungen dominiert, ist etwas anderes: Modelle, die nicht mit Text antworten, sondern Code ausführen, Kataloge abfragen, Annahmen validieren und prüfbare Ergebnisse zurückgeben.
Der praktische Unterschied ist enorm. Ein Chat, der eine CSV-Datei „interpretiert», halluziniert Zeilen und Durchschnittswerte mit beunruhigender Leichtigkeit. Ein Agent, der SQL oder Python gegen ein echtes Data Warehouse ausführt, kann keine Zahl erfinden, ohne dass die Datenbank-Engine protestiert. Das ist die Achse des Wandels: Das Modell ist nicht mehr der Analyst, sondern wird zum Planer, der Abfragen schreibt und Ergebnisse verifiziert.
Ausgereiftes Text-to-SQL: wo es funktioniert und wo es weiterhin scheitert
Die Generierung von SQL-Abfragen aus natürlicher Sprache ist die am weitesten verbreitete Anwendung und zugleich die in Demos am meisten überschätzte. Laut offizieller Dokumentation der wichtigsten Anbieter analytischer Datenbanken haben sich die öffentlichen Text-to-SQL-Benchmarks stetig verbessert, doch diese Zahlen werden auf sauberen Schemata mit selbsterklärenden Spaltennamen und ohne semantische Mehrdeutigkeit erzielt.
In einem echten Data Warehouse ändert sich die Sache. Ein Fall, der sich wiederholt: Die Tabelle heißt fact_ventas_v3, es existiert eine fact_ventas_v2, die nicht mehr aktualisiert wird, aber noch lebt, und es gibt eine Spalte importe, die in den Zeilen vor einer bestimmten Migration tatsächlich in Cent angegeben ist. Kein Modell errät das. Gelöst wird es durch einen Datenkatalog mit Beschreibungen, Linienverfolgung und dokumentierten Geschäftsregeln.
Was tatsächlich funktioniert
- Explorationsabfragen über eine abgegrenzte Domäne (eine Abteilung, eine geschlossene Menge von Tabellen).
- Übersetzung häufiger Fragen in parametrisierte Abfragen, die zuvor von einem Menschen geprüft wurden.
- Generierung von SQL-Entwürfen, die ein Analyst in Sekunden korrigiert, statt sie von Grund auf zu schreiben.
Was nicht funktioniert (und was man zugeben sollte)
- Fragen, die nicht schriftlich festgehaltene Geschäftsdefinitionen erfordern („aktive Kunden» kann fünf verschiedene Dinge bedeuten).
- Schemata mit Hunderten von Tabellen ohne Beschreibungen: Die Fehlerquote schießt in die Höhe.
- Berechnungen, bei denen ein falsch gewählter JOIN Zeilen verdoppelt und niemand es bemerkt, bis der Bericht die Geschäftsleitung erreicht.
Agenten mit Code-Ausführung: das Muster, das sich durchsetzt
Der Ansatz, der am stärksten gewachsen ist, besteht darin, dem Modell einen isolierten Code-Interpreter zu geben. Das Modell schreibt pandas, DuckDB oder R, führt es aus, liest die Ausgabe und iteriert, wenn ein Fehler auftritt. Das hat einen entscheidenden Vorteil für die Analyse: Das Ergebnis ist reproduzierbar. Man kann das Skript speichern, versionieren und im nächsten Monat erneut ausführen.
Hier gibt es ein Detail, das man nur durch den täglichen Einsatz dieser Werkzeuge lernt: Die meisten Fehler stammen nicht aus dem statistischen Denken, sondern aus dem Umgang mit Typen und Nullwerten. Datumsangaben in gemischten Formaten, Kategorien mit Leerzeichen am Ende, Beträge mit Dezimalkomma aus einem alten Export. Ein leistungsfähiges Modell schreibt ein tadelloses groupby und gruppiert dann falsch, weil „Madrid» und „Madrid » zwei verschiedene Werte sind. Die Lösung ist kein besseres Modell: Es ist eine vorgelagerte Bereinigungsschicht und explizite Validierungen.
Integration in den Stack: MCP und semantische Kataloge
Die architektonisch relevanteste Neuerung der letzten Monate ist die Standardisierung von Konnektoren. Das offene Protokoll, das gefördert wird, um Assistenten mit Datenquellen zu verbinden (bekannt als MCP), ermöglicht es, dass ein und dasselbe Modell ein Data Warehouse, ein CRM und eine Tabellenkalkulation abfragt, ohne dass jede Integration eine maßgeschneiderte Entwicklung ist.
Das hat eine Konsequenz, die Organisationen allmählich akzeptieren: Der Wert liegt nicht mehr im Modell, er liegt in der semantischen Schicht. Metriken einmal zu definieren (Nettoumsatz, Churn, Marge) und sie als Werkzeuge bereitzustellen, die das Modell aufrufen kann, ist das, was einen eindrucksvollen Piloten von einem System trennt, das den dritten Monat überlebt.
Ein Muster, das in Teams auftaucht, die die Testphase bereits hinter sich haben: weniger lange Prompts, mehr registrierte Funktionen mit präzisem Namen und präziser Beschreibung. Das Modell wählt zwischen zehn gut dokumentierten Werkzeugen, statt SQL über fünfzig Tabellen zu improvisieren.
Evaluierung: das Problem, das fast niemand gut löst
Zu messen, ob ein LLM gut analysiert, ist schwieriger, als es zum Laufen zu bringen. Öffentliche Benchmarks spiegeln nicht die eigenen Daten wider. Die Praxis, die sich unter reifen Teams durchsetzt, ist der Aufbau eines Satzes von Fragen mit manuell verifizierter Antwort über das eigene Data Warehouse und dessen Ausführung bei jedem Modell- oder Prompt-Wechsel.
Ohne diesen Evaluierungssatz ist jede Migration zu einem neuen Modell ein Blindflug. Und hier gibt es eine Nuance, die man im Hinterkopf behalten sollte: Eine Verbesserung bei einem generischen Benchmark garantiert keine Verbesserung in der eigenen Domäne. Wir haben Modelle gesehen, deren Leistung bei Aggregationsaufgaben mit Datumshierarchien sinkt, weil sie ihren Denkstil ändern, nicht weil sie schlechter sind.
Kosten und Latenz: der Faktor, der die Architektur entscheidet
Eine interaktive Analyse toleriert zwei Sekunden Wartezeit; ein geplanter Bericht, der jede Nacht über Tausende von Zeilen läuft, toleriert nicht die Kosten eines großen Modells pro Abfrage. Daher der Trend zu hybriden Architekturen:
- Kleine Modelle oder deterministische Regeln für häufige und gut typisierte Fragen.
- Große Modelle nur für offene Exploration und Fehlerbehebung.
- Ergebnis-Caching für wiederholte Abfragen, die in der Praxis die Mehrheit ausmachen.
Die Ausgaben für Tokens werden zu einer echten operativen Kostenposition, wenn das System täglich von zwanzig Personen genutzt wird. Ohne dies zu berücksichtigen zu entwerfen, ist der schnelle Weg dazu, dass das Projekt abgesagt wird.
Governance und Datenschutz: das Gespräch, das zu spät kommt, aber kommt
Kundendaten an einen externen Anbieter zu senden, erfordert die Prüfung von Verträgen, Aufbewahrung und Datenresidenz. Die Optionen für private Bereitstellung und Modelle, die auf eigener Infrastruktur ausgeführt werden, sind ausgereift genug, um in regulierten Branchen gangbar zu sein, allerdings mit einem Wartungsaufwand, den viele Unternehmen unterschätzen.
Ein häufiger Fehler: anzunehmen, dass „der Anbieter trainiert nicht mit meinen Daten» das Problem löst. Es löst es nicht, wenn die Daten das eigene Perimeter verlassen. Die eigentliche Entscheidung ist architektonisch, nicht vertraglich.
Worauf in den kommenden Monaten zu achten ist
- Ergebnisverifizierung: Mechanismen, die die Ausgabe des Modells mit einer Wahrheitsquelle abgleichen, bevor sie angezeigt wird.
- Automatische Linienverfolgung: zu wissen, aus welcher Tabelle und welcher Transformation jede vom System präsentierte Zahl stammt.
- Hybride Schnittstellen: Der Chat verschwindet nicht, aber er koexistiert mit Dashboards, bei denen das LLM nur die Erklärung des Diagramms verfasst.
- Kontinuierliche Evaluierung: eigene Suiten, die bei jeder Modellaktualisierung ausgeführt werden.
Die ehrliche Schlussfolgerung ist, dass LLMs bereits klaren Mehrwert bei Exploration, Datendokumentation und assistierter Generierung von Abfragen bieten und weiterhin fragil bei jeder Aufgabe bleiben, bei der eine falsche Zahl Konsequenzen hat. Mit dieser Asymmetrie im Hinterkopf zu entwerfen, die Daten und die Validierung ins Zentrum und das Modell an die Peripherie zu stellen, ist heute der Unterschied zwischen einem Experiment und einem System im Produktivbetrieb.