DeepBI: ein LLM-gesteuerter Datenanalyst mit Docker-Installation und festen Datenbankgrenzen

Welches Problem DeepBI adressiert und für wen es gedacht ist

Die Ausgangslage ist bekannt: Wer eine Frage an seine Daten hat, schreibt entweder SQL oder bittet jemanden darum. DeepBI setzt an dieser Stelle an und beschreibt sich selbst als AI-native Datenanalyseplattform, die große Sprachmodelle nutzt, um Daten zu erkunden, abzufragen, zu visualisieren und zu teilen. Der Anspruch ist nicht, eine neue Datenbank zu sein, sondern eine Schicht über vorhandenen Quellen. Das README nennt als Zielgruppe Nutzer, die über Dialoge zu Datenergebnissen und Analysen kommen wollen, ohne selbst Abfragen zu formulieren. Praktisch richtet sich das an Fachabteilungen mit wiederkehrenden Auswertungsfragen und an kleine Data-Teams, die keine eigene BI-Plattform betreiben wollen. Die Liste der unterstützten Quellen im README umfasst MySQL, PostgreSQL, Doris, StarRocks, MongoDB sowie den Import von CSV- und Excel-Dateien. Wer ausschließlich im Warehouse eines anderen Anbieters arbeitet, findet dort keinen Eintrag. Das ist keine Lücke im Marketing, sondern eine harte Grenze der aktuellen Version.

Dialog, persistente Query, Dashboard: die drei Ebenen im Datenfluss

Die Mechanik lässt sich aus den Feature-Beschreibungen ableiten. Ebene eins ist der Dialog: Nutzer stellen eine Frage in natürlicher Sprache, das System erzeugt daraus eine Abfrage gegen die verbundene Quelle und liefert Ergebnisse zurück. Ebene zwei ist die persistente Query. Das README formuliert es als Generierung dauerhafter Abfragen und Visualisierungen über Dialoge. Der Unterschied zur ersten Ebene ist wichtig: Eine einmal erzeugte Abfrage bleibt erhalten und muss nicht bei jeder Frage neu formuliert werden. Ebene drei ist das Dashboard, in dem persistente Visualisierungen zusammengestellt werden. Der Datenfluss verläuft also von der natürlichen Sprache über eine generierte Abfrage in eine gespeicherte Definition und von dort in eine Anzeige. Was das README nicht beschreibt, ist der Zwischenschritt: ob die generierte Abfrage vor der Ausführung sichtbar und editierbar ist, ob es eine Vorschau gibt, ob Fehlschläge automatisch korrigiert werden. Genau dieser Punkt entscheidet in der Praxis darüber, ob man dem System vertraut. Ohne Einsicht in die erzeugte Abfrage bleibt die Antwort eine Black Box, und bei aggregierten Kennzahlen ist das ein Problem.

Installation über Docker, Ubuntu oder Windows-Exe

Der schnellste Weg führt über Docker. Laut README wird das Repository per git clone https://github.com/DeepInsight-AI/DeepBI.git geholt, danach wechselt man mit cd DeepBI in das Verzeichnis und führt ./Install.sh aus. Die Standardports sind 8338 und 8339, der Webzugang läuft über http://ip:8338. Für den laufenden Betrieb nennt das README drei Befehle: docker-compose start, docker-compose stop und docker-compose ps. Treten PermissionError- oder Permission-denied-Meldungen auf, soll man den Befehlen sudo voranstellen. Auf Ubuntu erfolgt die Installation direkt im System und setzt Redis, PostgreSQL in Version 16 und Python 3.8.17 voraus. Redis muss über die Kommandozeile unter 127.0.0.1 passwortfrei erreichbar sein. Gestartet wird mit . ubuntu_install.sh, wobei das README ausdrücklich betont, dass der Punkt vor dem Skriptnamen nötig ist, weil darüber die Python-Umgebung aktiviert wird. Für Windows gibt es window_install_exe_EN.zip in der Release-Liste, entpacken und die .exe doppelklicken, getestet laut README unter Win10 und Win11. Die Mindestanforderung an den Server liegt bei 1 Kern und 2 GB Speicher, empfohlen werden 2 Kerne und 4 GB.

Die harten Abhängigkeiten: PostgreSQL 16, Redis ohne Passwort, Python 3.8

Die Ubuntu-Variante ist der aufschlussreichste Teil des README, weil sie die Betriebsanforderungen offenlegt. PostgreSQL 16 wird in dieser Version verlangt, nicht irgendeine 14 oder 15. Wer bereits eine ältere Instanz betreibt, muss entweder parallel installieren oder migrieren. Redis soll passwortfrei über 127.0.0.1 erreichbar sein, was auf einem Einzelhost funktioniert, in einem geteilten Netz aber eine bewusste Entscheidung erfordert. Python 3.8.17 ist eine Festlegung auf eine Nebenversion, nicht auf den 3.8-Zweig allgemein. Das README empfiehlt ausdrücklich virtuelle Umgebungen wie pyenv oder conda. Diese drei Vorgaben zusammen bedeuten: DeepBI lässt sich nicht nebenbei in eine bestehende Anwendung hineininstallieren. Es ist ein eigener Dienst mit eigener Laufzeitumgebung. Das ist ein legitimer Entwurf für eine Plattform, die Dashboards und persistente Abfragen verwaltet, aber es schließt die Nutzung als Bibliothek aus. Wer nur eine Funktion zur Übersetzung von natürlicher Sprache in SQL braucht, trägt hier erheblich mehr Betriebsaufwand als nötig.

Was das README offen lässt: LLM-Anbindung, Rechte, Berichte

An mehreren Stellen ist die Dokumentation dünn. Das README nennt keine Konfigurationsdatei, keine Umgebungsvariablen und keinen Schlüssel für den LLM-Anbieter, obwohl die Topics gpt und gpt-4 aufführen. Wie das Modell ausgewählt oder ein API-Schlüssel hinterlegt wird, geht aus dem vorliegenden Material nicht hervor. Ebenso fehlt jede Aussage zu Benutzerverwaltung, Rollen oder Zugriffsrechten auf Datenquellen. Bei einem Werkzeug, das beliebige Abfragen gegen Produktionsdatenbanken erzeugt, ist das der wichtigste offene Punkt. Wer DeepBI auf eine Datenbank mit echten Kundendaten richtet, sollte vorher klären, mit welchen Rechten das System arbeitet und ob es sinnvoll ist, ein eigenes Read-only-Konto anzulegen. Das README hilft dabei nicht. Auch die automatischen Analyseberichte stehen nur als angekündigtes Feature in der Liste, mit dem Zusatz to be developed. Man sollte sie bei der Bewertung nicht mitzählen. Die Feature-Liste mischt also Ausgeliefertes und Geplantes, was den Vergleich mit Alternativen erschwert.

Wann DeepBI das falsche Werkzeug ist

DeepBI passt nicht, wenn die Anforderung deterministisch ist. Ein festes monatliches Reporting mit bekannten Kennzahlen gehört in eine versionierte SQL-Datei oder ein dbt-Modell, nicht in einen Dialog mit einem Sprachmodell. Der Grund ist nicht Geschwindigkeit, sondern Reproduzierbarkeit: Eine generierte Abfrage kann sich zwischen zwei Läufen unterscheiden, eine feste Abfrage nicht. DeepBI passt ebenfalls nicht, wenn Daten das Haus nicht verlassen dürfen, ohne dass geklärt ist, welches Modell wo läuft. Da das README zur LLM-Anbindung schweigt, lässt sich nicht sagen, ob ein lokales Modell unterstützt wird oder ob ein externer Anbieter vorausgesetzt ist. Ein dritter Fall: Wer bereits ein Warehouse mit semantischer Schicht betreibt, in der Kennzahlen zentral definiert sind, baut mit DeepBI eine zweite, dialogbasierte Definitionsquelle daneben. Zwei Quellen für dieselbe Kennzahl sind ein Rezept für abweichende Zahlen. Und schließlich ist DeepBI kein Ersatz für Datenqualitätsprüfung. Wenn die zugrunde liegende Tabelle Duplikate enthält, liefert das Sprachmodell eine flüssig formulierte Antwort auf Basis fehlerhafter Daten.

Abgrenzung zu Text-to-SQL-Werkzeugen und zu klassischem BI

Die naheliegende Alternative ist ein Text-to-SQL-Werkzeug, das sich als Bibliothek in eine bestehende Python-Anwendung einbinden lässt, statt als eigener Dienst mit Web-Oberfläche zu laufen. Der Unterschied liegt nicht in der Modellqualität, sondern im Umfang: Solche Werkzeuge liefern in der Regel eine Funktion, die eine Frage und ein Schema entgegennimmt und eine Abfrage zurückgibt. Was danach damit passiert, bleibt dem Aufrufer überlassen. DeepBI geht den umgekehrten Weg und liefert die gesamte Anwendung mit: Dialog, gespeicherte Abfragen, Visualisierungen, Dashboards, Datenquellenverwaltung, Mehrsprachigkeit in Chinesisch und Englisch. Dafür bringt es die Laufzeitumgebung mit, die ein Bibliotheksansatz nicht braucht. Die zweite Alternative ist klassisches BI mit manuell gebauten Reports. Dessen Stärke ist die Nachvollziehbarkeit jeder Zahl, seine Schwäche der Aufwand für jede neue Frage. DeepBI zielt auf den Zwischenraum: Fragen, die zu häufig für manuelle Reports und zu unvorhersehbar für feste Dashboards sind. Wer diesen Zwischenraum nicht hat, braucht das Werkzeug nicht.

Wartung, Release-Stand und Lizenz

Das jüngste aufgeführte Release ist v2.0.4 vom 8. Oktober 2024, davor v2.0.3 im Juni und v2.0.2 im Juni 2024. Der letzte Push auf den Hauptzweig liegt laut Repository-Angabe im August 2026, das Projekt ist nicht archiviert. Zwischen Release und Push liegt also ein erheblicher Abstand, was bedeutet, dass der Hauptzweig weiter entwickelt wird, während die veröffentlichten Pakete älter sind. Wer die Windows-Exe oder ein Tag-Release nutzt, arbeitet auf einem anderen Stand als jemand, der den Hauptzweig klont. Das ist beim Nachvollziehen von Fehlern relevant. Die Lizenz ist MIT, was kommerzielle Nutzung und Änderung erlaubt, solange der Copyright-Hinweis und der Lizenztext erhalten bleiben. Das ist eine der permissivsten Optionen und senkt die Einstiegshürde. Zu beachten ist, dass die MIT-Lizenz nur den Code im Repository abdeckt. Etwaige Kosten für einen externen LLM-Anbieter, für Server oder für Support sind damit nicht abgegolten, und das README nennt dazu keine Angaben. Eine rechtliche Bewertung der Lizenz für den eigenen Fall ersetzt das nicht.

Redaktionelles Fazit

Wer bereits MySQL, PostgreSQL, Doris, StarRocks oder MongoDB betreibt und eine selbst gehostete Chat-Oberfläche für wiederkehrende Abfragen und Dashboards sucht, kann DeepBI unter MIT-Lizenz ohne Lizenzkosten evaluieren. Wer fertige, automatisch generierte Analyseberichte erwartet, sollte warten: Das README führt diesen Punkt selbst als in Entwicklung befindlich. Und wer eine schlanke Bibliothek sucht, die er in eine bestehende Python-Anwendung einbettet, ist hier falsch, weil DeepBI als vollständiger Dienst mit Redis und PostgreSQL-16-Abhängigkeit ausgeliefert wird. Vor dem ersten Produktiveinsatz zu prüfen sind der Stand des Release v2.0.4 vom 8. Oktober 2024, die Frage, welcher LLM-Anbieter konfiguriert wird, und ob die mitgelieferte docker-compose-Datei im eigenen Netz die Ports 8338 und 8339 wie vorgesehen bindet.

Offizielle Quellen

1. DeepInsight-AI/DeepBI on GitHub
2. License: MIT
3. Project website
4. README
5. Releases