Datenbank per Chat abfragen: ERP-, CRM- und SQL-Daten in normaler Sprache mit lokalem LLM

Das ERP in normaler Sprache fragen

Eine Datenbank mit KI abfragen heißt: Sie tippen eine fachliche Frage in ein Chatfenster und erhalten die Antwort aus Ihren eigenen Daten. Ein Sprachmodell übersetzt die Frage in SQL, die Abfragesprache von Datenbanken (daher „Text-to-SQL“), die Datenbank führt sie aus, und die Antwort kommt als Tabelle oder Diagramm zusammen mit der Abfrage zurück. Lokal betrieben, läuft das Modell auf einer Workstation oder einem Server in Ihrem Unternehmen, sodass Fragen, Tabellenstruktur und Ergebnisse nie an einen Cloud-Dienst gehen. Für ein Controlling- oder Vertriebsteam ist eine NVIDIA RTX PRO 5000 Blackwell mit 48 oder 72 GB der praktische Einstieg.

Dieser Artikel richtet sich an Geschäftsführung, Controlling und Vertriebsleitung, die Antworten aus ERP oder CRM möchten, ohne auf einen Bericht zu warten, und an die IT-Kollegin, die das Ganze anbindet. Typische Fragen sind „welche Kunden haben in diesem Quartal weniger bestellt als im Vorjahresquartal“, „offene Aufträge über einem bestimmten Wert je Außendienstler“ oder „durchschnittliche Tage vom Angebot bis zum Auftrag je Produktlinie“. Jede braucht einige korrekt verknüpfte Tabellen und einen Filter, der so zählt wie Ihr Unternehmen.

Dieser Artikel zeigt, was ein Unternehmen für den Start braucht: die Werkzeuge, die fachlichen Definitionen, die Zugriffsregeln und eine Workstation. Die Modellwahl für ein BI-Team mit großen Data Warehouses, die Schema-Auswahl und Server mit mehreren Karten behandelt unser Leitfaden zu Text-to-SQL on-premise. Die Suche in Dokumenten ist eine andere Aufgabe, beschrieben in unserem Leitfaden zu RAG auf Firmendaten: Eine Dokumentsuche findet eine Textstelle, Text-to-SQL berechnet eine Zahl, und ein falscher Filter liefert eine selbstsichere, falsche Zahl.

Wie oft die Antwort stimmt

Öffentliche Benchmarks zeichnen ein nüchternes Bild. BIRD, ein Benchmark mit 95 Datenbanken, wertet eine Antwort als richtig, wenn das Ergebnis der erzeugten Abfrage dem einer Referenzabfrage entspricht. Am 30. Oktober 2026 liegt die menschliche Leistung auf dem Testset bei 92,96 Prozent. Das beste Einzelmodell, Googles Gemini-SQL2, erreicht 80,04 und ist ohne Link zu Gewichten gelistet; das beste mit einem Link zu Gewichten auf Hugging Face, Kwai-AutoSQL-32B, erreicht 74,12. Der beste Eintrag der Hauptrangliste, die vollständige Systeme bewertet, steht bei 83,40 (Eintrag vom 22. Oktober 2026).

Mit dem besten Modell mit offenen Gewichten auf der Rangliste ist im öffentlichen Test also etwa jede vierte Antwort falsch, und Firmendatenbanken sind unordentlicher als BIRD. Drei Gewohnheiten machen das Werkzeug trotzdem brauchbar. Zeigen Sie zu jeder Antwort das SQL, damit jemand, der die Daten kennt, eine falsche Verknüpfung erkennt. Führen Sie eine Sammlung geprüfter Fragen mit ihren richtigen Abfragen, die das Werkzeug als Beispiele nutzt. Und kennzeichnen Sie Antworten aus einer geprüften Abfrage anders als neue. Spider 2.0, ein schwererer Benchmark mit Unternehmensdatenbanken, die oft mehr als 1.000 Spalten haben, zeigt noch etwas: In seinem Snowflake-Teil erreichte gpt-oss-120b in einem Agenten-Framework 65,45 und in einem anderen 13,10, wie unser Text-to-SQL-Leitfaden festhält. Das System um das Modell herum zählt also so viel wie das Modell.

Offene Tools für den Datenbank-Chat im Oktober 2026

Mehrere offene Projekte versprechen genau das. Ihr Stand hat sich 2026 verändert, prüfen Sie ihn also, bevor Sie darauf aufbauen.

GitHub-Repositorys und README-Dateien von Vanna, WrenAI, DB-GPT und LangChain, Release-Seite von DB-GPT, LangChains Tutorial „Build a SQL agent“ und die Seite zu ChatOllama, alle gelesen am 30. Oktober 2026.

Vanna nennt sich „Chat with your SQL database“ und wurde als Vanna 2.0 mit nutzerbezogenen Agenten und einer fertigen Chat-Komponente neu geschrieben. Sein Repository wurde „archived by the owner on Mar 29, 2026“ und „is now read-only“, es erhält also keine Korrekturen mehr. Für neue Projekte installieren wir es nicht.

WrenAI beschreibt sich als „GenBI (Generative BI) for AI agents, an open-source, governed text-to-SQL through an open context layer“. Kern-Engine, SDK und Skills stehen unter Apache 2.0; Sicherheit auf Zeilen- und Spaltenebene mit Benutzerverwaltung, die GenBI-Oberfläche, Dashboards und Einbettung sind als kommerziell aufgeführt. Die README nennt Coding-Agenten als Nutzer des offenen Teils und keinen lokalen Modellanbieter. Seine Modellierungssprache dient unten als Beispiel für eine semantische Schicht.

DB-GPT steht unter MIT und nennt sich „open-source agentic AI data assistant“. Es nimmt Fragen in natürlicher Sprache entgegen, schreibt das SQL und erzeugt Diagramme, Dashboards und Berichte. Die README nennt lokale GPU-Modelle über vLLM und llama.cpp sowie OpenAI-kompatible Modellserver und öffnet eine Weboberfläche auf Port 5670. Zu Benutzerkonten oder Berechtigungen sagt sie nichts; der Zugang gehört deshalb davor, über die Firmenanmeldung oder einen authentifizierenden Proxy, wie unser Leitfaden zur privaten ChatGPT-Alternative es für Chat-Oberflächen beschreibt.

Der SQL-Agent von LangChain ist ein Tutorial mit Bausteinen für Entwickler; eine fertige App zum Installieren gibt es nicht. Der Agent listet die Tabellen auf, liest die Struktur der relevanten, schreibt eine Abfrage, lässt das Modell sie prüfen, führt sie aus, korrigiert sie nach einem Fehler und antwortet. Sein Systemprompt sagt „DO NOT make any DML statements (INSERT, UPDATE, DELETE, DROP etc.)“, und eine HumanInTheLoopMiddleware kann vor jeder Abfrage anhalten, bis ein Mensch sie freigibt. Die Beispiele des Tutorials nutzen Cloud-Modelle; die Integration ChatOllama von LangChain unterstützt Tool Calling mit einem lokalen Modell.

Sie können die RTX PRO Workstation allein bestellen, die Einrichtung von Modell, DB-GPT und Lesezugriff auf die Datenbank allein oder beides zusammen: die Workstation mit allem fertig installiert und eingerichtet; schreiben Sie uns, wir schlagen Ihnen die beste Lösung für Ihre Aufgaben und Ihr Budget vor.

Eine semantische Schicht mit Ihren Fachbegriffen

Das Modell sieht Tabellen- und Spaltennamen, und selbst klare Namen verraten ihm nicht, was Ihr Unternehmen unter „Umsatz“ versteht, welche Auftragsstatus als storniert gelten oder welches Datum über das Quartal entscheidet. Eine semantische Schicht ist eine schriftliche Beschreibung der Daten in Fachbegriffen, die zwischen Datenbank und Modell liegt: was jede Tabelle bedeutet, welche Verknüpfungen freigegeben sind, wie jede Kennzahl berechnet wird.

Die Kontextschicht von WrenAI zeigt, was eine solche Schicht enthält: Ihre Modeling Definition Language beschreibt Modelle, Spalten, Beziehungen, Views, Cubes und Kennzahlen, und zwei einfache Dateien, instructions.md und queries.yml, halten Aufzählungswerte, Einheiten, freigegebene Verknüpfungen und Definitionen. Dieselbe Idee funktioniert ohne WrenAI. Die IT legt einige Datenbank-Views an, gespeicherte Abfragen, die wie Tabellen aussehen, mit lesbaren Namen für die wichtigen Fragen, etwa Umsatz je Kunde und Monat oder offene Aufträge mit Außendienstler. Sie schreibt einen Satz je Spalte und ergänzt die geprüften Beispielfragen. Das Modell fragt dann nur diese Views ab; die rohen ERP-Tabellen bleiben außer Reichweite.

Dieser Schritt entscheidet mehr als die Wahl des Modells. Ein Controller, der zwanzig Definitionen und dreißig geprüfte Fragen aufschreibt, gibt dem Werkzeug, was eine erfahrene Kollegin weiß. Fachliche Definitionen ändern sich auch; halten Sie die Schicht in Git, damit jede Änderung datiert und prüfbar ist.

Nur Lesezugriff auf ERP- und CRM-Daten

Das Datenbankkonto, mit dem das Werkzeug arbeitet, ist die entscheidende Sicherheitsgrenze. Die Dokumentation von LangChain sagt es deutlich: „Make sure that your database connection permissions are always scoped as narrowly as possible for your agent's needs.“ Die Anweisung, keine Daten zu ändern, ist ein Satz in einem Prompt; durchgesetzt wird sie nur von den Datenbankrechten.

1. Eine Kopie abfragen, nicht das Live-System. Nutzen Sie ein Reporting-Replikat oder das Data Warehouse, damit eine schwere Abfrage die Auftragserfassung nicht bremst. Fragen Sie Ihren ERP-Anbieter, ob direkter Lesezugriff auf seine Datenbank nach Ihrem Wartungsvertrag erlaubt ist.
2. Einen Benutzer nur mit Leserechten anlegen. Er erhält SELECT-Rechte auf die Views der semantischen Schicht und sonst nichts. In PostgreSQL ist default_transaction_read_only nur eine Voreinstellung, die eine Sitzung ändern kann, die Rechte entscheiden also; statement_timeout stoppt ausufernde Abfragen und wird für dieses Konto gesetzt, wie unser Text-to-SQL-Leitfaden erklärt.
3. Zeilenregeln beibehalten. Dürfen Außendienstler nur ihre eigenen Kunden sehen, gehört diese Regel in die Datenbank, und die Datenbank muss wissen, wer fragt: Ein gemeinsames Konto sieht alles, was seine Rolle sehen darf. Geben Sie jedem Team eine eigene Rolle nur mit Leserechten und eine eigene Verbindung im Werkzeug. Legen Sie die Views in PostgreSQL mit security_invoker = true an, denn standardmäßig wendet eine View die Zeilenregeln ihres Eigentümers an und nicht die der fragenden Person.
4. Jede Abfrage prüfen und protokollieren. Lassen Sie je Frage genau eine SELECT-Anweisung zu, ergänzen Sie ein Zeilenlimit und protokollieren Sie Frage, SQL und Nutzer.

Kundennotizen und Freitextfelder können Anweisungen enthalten, die im Kontext des Modells landen, ein Risiko, das unser Leitfaden zu Prompt Injection und LLM-Sicherheit beschreibt. Personen­bezogene Daten im CRM unterliegen auch auf eigener Hardware der DSGVO; was der Eigenbetrieb regelt und was Ihre Pflicht bleibt, steht in unserem Leitfaden zu lokaler KI und DSGVO, die Details bestätigt Ihr Datenschutz­beauftragter.

Welches lokale Modell das SQL schreibt

Zwei Arten von Modellen kommen zum Einsatz. Auf SQL feinabgestimmte Modelle wie Kwai-AutoSQL-32B (Gewichte unter Apache 2.0) oder Snowflakes Arctic-Text2SQL-R1-7B (Apache 2.0, laut Karte 68,5 auf dem BIRD-Testset) machen aus einer Frage und den Tabellendefinitionen eine Abfrage. Agenten wie DB-GPT oder der SQL-Agent von LangChain brauchen ein allgemeines Modell, das Werkzeuge aufruft: gpt-oss-20b oder gpt-oss-120b (Apache 2.0) oder Qwen3.8-27B (Apache 2.0, August 2026), dessen Karte keinen SQL-Benchmark nennt. Keine veröffentlichte Zahl vergleicht diese allgemeinen Modelle auf Ihrer Art von Schema; den Ausschlag gibt ein Test mit Ihren eigenen Fragen.

Qwen3.8-27B denkt vor der Antwort nach; seine Karte setzt den höchsten Reasoning-Aufwand als Vorgabe und bietet daneben mittel und niedrig an; für SQL-Schritte verkürzt ein niedrigerer Aufwand die Wartezeit. Die Geschwindigkeit für eine Frage hängt von der Speicherbandbreite und den je Token gelesenen Bytes ab: Auf der RTX PRO 5000 (1.344 GB/s) liest das 27B-Modell in 8 Bit etwa 28 GB je Token, etwa 47 Token pro Sekunde sind also nach unserer Schätzung eine Obergrenze. Ein Agent, der in jedem von vier Schritten 500 Token schreibt, braucht damit mindestens etwa 43 Sekunden, ebenfalls nach unserer Schätzung.

Karten und Kapazität für Datenbankfragen

Wir rechnen mit unserer Regel für Nutzer je Karte: 90 Prozent des vom Treiber gemeldeten Speichers, abzüglich 3 GiB je Karte und der Modellgewichte, bleiben für die laufenden Fragen. Ein Token ist ein Wort oder ein Wortteil. Eine Frage mit Anweisungen, den ausgewählten Views, Beispielen und den Schritten des Agenten umfasst in diesem Beispiel etwa 10.000 Token, dieselbe Annahme wie in unserem Text-to-SQL-Leitfaden. Wir rechnen mit einem 16-Bit-Cache, wie Ollama ihn standardmäßig anlegt.

Unsere Schätzungen nach der Regel für Nutzer je Karte (nutzbarer Speicher 18,5, 40,0, 61,5 und 83,0 GiB); Gewichte aus Ollamas Tags (qwen3.8 q8_0 30 GB) und den Hugging-Face-Dateien von gpt-oss; 16-Bit-Cache je Token: 24 KiB für gpt-oss-20b, 64 KiB plus 0,14 GiB festem Zustand für Qwen3.8-27B, 36 KiB für gpt-oss-120b. Ein FP8-Cache, wie vLLM ihn bietet, lässt Platz für mehr Fragen. Keine Messungen.

Laufende Fragen sind keine Nutzer: Zehn Führungskräfte fragen selten in derselben Sekunde, jede Zahl reicht also für ein größeres Team. Die Einstiegskarte mit 24 GB passt für ein Team mit wenigen sauberen Views. Die RTX PRO 5000 mit 48 GB hält ein 27B-Modell in 8 Bit mit Platz für Schema und Beispiele; unsere Seite zur Workstation mit RTX PRO 5000 48 GB beschreibt den Rechner. Die Version mit 72 GB bedient mehrere Abteilungen, und eine RTX PRO 6000 Workstation Edition oder Max-Q betreibt gpt-oss-120b. Für ein BI-Team auf einem großen Data Warehouse ist ein Server mit RTX PRO 6000 Server Edition oder H200 NVL in unserem Text-to-SQL-Leitfaden berechnet.

Schicken Sie uns Datenbanktyp, Zahl der Tabellen und zehn Fragen, die Ihr Team stellt, und wir schlagen Karte und Einrichtung vor, die dazu passen.

Mit einem Pilotprojekt beginnen

Sammeln Sie 50 bis 100 echte Fragen der künftigen Nutzer, deren richtige Antwort jemand geprüft hat, der die Daten kennt. Legen Sie Views und Definitionen dafür an, lassen Sie die Fragen mit demselben Werkzeug durch jedes Kandidatenmodell laufen und zählen Sie richtige Ergebnisse, falsche Ergebnisse und Verweigerungen. Wiederholen Sie den Test nach jeder Änderung an Modell, Prompt oder Views; wie man einen solchen Testsatz pflegt, zeigt unser Leitfaden zur LLM-Evaluierung. Ein erstes Pilotprojekt in einem Fachbereich, etwa Vertrieb oder Einkauf, zeigt, ob die Antworten belastbar sind, bevor weitere Bereiche dazukommen. Wollen mehr Abteilungen mitmachen, beschreibt Von Ollama auf dem PC zum KI-Server für die Firma den Schritt von einer Workstation zu einem gemeinsamen Rechner.

FAQ