Einen Assistenten die Datenbank abfragen lassen
Die Vorführung ist unwiderstehlich: eine Frage auf Deutsch stellen, eine Zahl aus dem ERP bekommen. Die Fassung, die wir betreiben, sieht der Vorführung überhaupt nicht ähnlich, und der Unterschied liegt fast vollständig darin, was der Assistent sehen darf.
Die Abfrage, die korrekt war
Ein Nutzer fragte, wie viele Aufträge für einen Kunden offen sind. Das erzeugte SQL war gültig, lief schnell und lieferte elf. Die richtige Antwort war sieben, denn die gezählte Tabelle enthält stornierte Aufträge, und die betriebswirtschaftliche Bedeutung von offen schließt sie aus.
Nichts ist gescheitert. Die Abfrage war syntaktisch korrekt, inhaltlich naheliegend und lieferte eine Zahl, die genau wie eine Antwort aussah. Das ist der typische Fehler erzeugten SQLs und der Grund, warum die Vorführung in die Irre führt: In einer Vorführung sieht jemand zu, der das Schema kennt.
Warum das Schema das Problem ist
Ein produktives ERP-Schema kodiert Entscheidungen aus Jahrzehnten: Statusfelder, deren Bedeutung sich geändert hat, Tabellen aus Migrationen, Spalten, deren Namen beschreiben, was sie 2011 enthielten. Ein Modell, das dieses Schema liest, erschließt Bedeutung aus Namen — genau das, was die Namen nicht verlässlich tragen.
Shen und Kollegen veröffentlichten 2025 MageSQL, eine Arbeit zur Verbesserung von Text-zu-SQL über In-Context-Learning, und die Rahmung, die geblieben ist, lautet: Die Schwierigkeit konzentriert sich im Verstehen des Schemas, nicht im Erzeugen von Syntax. Die Syntax war zuerst gelöst und der Teil, an dem niemand Geld verlor.
Was wir freigeben
Keine Tabellen. Eine kleine Menge Sichten, geschrieben von jemandem, der die Domäne kennt, jede mit Namen und dokumentierter Definition: offene Aufträge, Lieferungen dieses Monats, überfällige Rechnungen. Die Sicht kodiert die fachliche Bedeutung einmal, in SQL, von einer Person geprüft — und der Assistent fragt nur diese ab.
Damit wird aus einem offenen Schemaproblem ein begrenztes. Der Assistent kann Sichten weiterhin kombinieren, filtern und aggregieren, und er kann nicht entscheiden, was offen bedeutet, denn diese Entscheidung ist in der Sichtdefinition gefallen — von jemandem, der dafür einsteht.
| Erlaubt | Nicht erlaubt |
|---|---|
| Auswahl aus kuratierten Sichten | Jeder Zugriff auf Basistabellen |
| Filtern, gruppieren, aggregieren | Verknüpfungen, die die Sicht nicht bietet |
| Ein Zeilenlimit, immer gesetzt | Unbegrenzte Ergebnismengen |
| Nur-Lese-Zugangsdaten | Jeder Schreibvorgang, ausnahmslos |
Was jede Antwort zeigt
Die Abfrage, vollständig, unter der Zahl. Nutzer lesen sie nicht, und die Leute, auf die es ankommt, tun es: Bestreitet ein Controller einen Wert, dreht sich das Gespräch um eine sichtbare SQL-Anweisung statt um die Frage, ob man dem Assistenten trauen kann.
Wir zeigen außerdem, welche Sichten genutzt wurden, und die Zeilenzahl vor der Aggregation. Letztere hat mehr Fehler gefangen als alles andere — denn eine Summe über drei Zeilen und eine über dreitausend sehen identisch aus, sobald sie eine einzelne Zahl sind.
Die Grenzen, die nicht technisch sind
Ein Zeilenlimit auf jeder Abfrage, von uns gesetzt und nicht vom Modell, und eine Zeitbegrenzung. Beides existiert, weil der Fehler, den wir am meisten vermeiden wollten, nicht eine falsche Antwort ist, sondern ein Assistent, der zum Monatsende eine Produktionsdatenbank unter Last setzt, weil jemand mit weitem Zeitraum gefragt hat.
Nur-Lese-Zugangsdaten, ausnahmslos, und auf einer Replik, wo es eine gibt. Das ist keine Aussage über das Urteilsvermögen des Modells. Es ist, dass ein System, in dem eine falsche Antwort peinlich und ein falscher Schreibvorgang ein Vorfall ist, das Zweite nicht können sollte.
Wie die Sichten entstehen
Von einem Fachexperten und einem Entwickler gemeinsam, aus den Fragen, die tatsächlich gestellt werden. Wir haben zwei Monate lang Fragen gesammelt, die an das Controlling gingen, sie gruppiert — und elf Sichten deckten rund achtzig Prozent ab.
Die verbleibenden zwanzig Prozent sind wirklich verschieden und gehen an einen Menschen. Das ist dieselbe Gestalt wie in jedem anderen System, das wir bauen: Die begrenzte Mehrheit wird automatisiert, der lange Schwanz wird weitergeleitet, und niemand tut so, als sei der Schwanz klein genug zum Ignorieren.
Was es nicht ersetzt
Das Berichtswesen. Wir wurden zweimal gefragt, ob das geplante Berichte ersetzen könne, und das sollte es nicht: Ein Bericht, der jeden Montag mit fester Definition läuft, ist verlässlicher als eine Frage, die jede Woche etwas anders gestellt wird — und billiger.
Der Assistent ist für die Fragen zwischen den Berichten, die sonst eine Mail ans Controlling wären. So gemessen sparte er rund sechs Stunden pro Woche an fremder Zeit — ein bescheidenes und echtes Ergebnis, keine Verwandlung.
Was wir nicht behaupten
Wir behaupten nicht, erzeugtes SQL über ein rohes Schema könne nicht funktionieren. Bei einem sauberen, gut benannten, dokumentierten Schema funktioniert es deutlich besser, als unsere Vorsicht nahelegt, und wir haben es gesehen. Unsere Kunden haben dieses Schema nicht — eine Aussage über produktive Systeme, nicht über das Verfahren.
Wir behaupten auch nicht, Sichten beseitigten falsche Antworten. Eine Sicht kann eine Definition kodieren, die das Geschäft inzwischen geändert hat, und dann ist der Assistent selbstsicher falsch — auf eine Weise, die nun unser Fehler ist und nicht der des Modells. Genau deshalb werden Sichten jährlich überprüft.