ai-chatbot-framework: Dialogregeln im Dashboard statt im Code

Welches Problem die Dashboard-Variante löst

Die meisten Chatbot-Projekte scheitern nicht an der Modellwahl, sondern an der Pflege. Jede neue Absicht, jede Variante einer Formulierung, jede geänderte Rückfrage landet als Codeänderung im Repository, wird reviewt, getestet und ausgerollt. Das ist bei einem Bot, dessen Inhalte Fachabteilungen verantworten, ein struktureller Konflikt. ai-chatbot-framework setzt genau dort an: Dialogabläufe, Intents und Antworten sollen laut README ohne Programmieraufwand im Admin-Dashboard entstehen. Die Zielgruppe sind damit weniger Machine-Learning-Teams als Betreiber, die einen mehrstufigen Dialog selbst konfigurieren wollen und Python nur als Betriebsvoraussetzung akzeptieren. Der Preis für diese Trennung ist, dass die Logik in MongoDB liegt und nicht im Git-Verlauf. Wer Änderungen an Dialogen nachvollziehen will, braucht dafür eine eigene Strategie.

FastAPI, Motor, Spacy und ein LLM als Ausweichpfad

Der Stack ist im README vollständig benannt: Python mit FastAPI und Pydantic für den Dienst, MongoDB über den asynchronen Treiber Motor als Speicher, React und Next.js für die Oberfläche. Die Spracherkennung ruht auf zwei Schienen. Für trainierte Fälle kommen scikit-learn, TensorFlow und Keras sowie Spacy-Wortvektoren und python-crfsuite für die Entitätenerkennung zum Einsatz. Für Fälle ohne Trainingsdaten nennt das README Zero-Shot-NLU über Large Language Models, womit sich Intents auch ohne Beispielsätze zuordnen lassen. Die Topics des Repositories verweisen zusätzlich auf OpenAI, DeepSeek, LangChain und Tool-Calling, was den zweiten Pfad konkretisiert: Das Modell entscheidet, wann eine API-Anfrage ausgeführt wird. Persistent Memory und Kontextverwaltung sind als eigene Funktion gelistet, ohne dass das README beschreibt, wie der Kontext zwischen Turns gespeichert oder begrenzt wird. Genau diese Grenze ist in der Praxis die interessantere Frage, und sie bleibt hier offen.

Was das Repository an Struktur erkennen lässt

Die Projektbeschreibung nennt TypeScript als primäre Sprache, während das README das System als in Python gebaut beschreibt. Beides ist vereinbar: Backend in Python, Frontend in TypeScript. Für die Bewertung ist das relevant, weil ein Beitrag zum Backend eine andere Umgebung erfordert als einer zur Oberfläche. Entsprechend existieren zwei getrennte CI-Workflows, evaluate-backend.yml und evaluate-frontend.yml, die laut README-Badges den Build-Status getrennt ausweisen. Das Repository führt die Themen hacktoberfest und help-wanted, ist also auf externe Beiträge ausgelegt. Ein Homepage-Feld fehlt, die Dokumentation liegt im Repository unter docs/README.md. Wer sich orientieren will, ist auf dieses Verzeichnis und die Screenshots angewiesen, nicht auf eine gehostete Doku-Seite.

Installation: Docker, MongoDB, dann das Dashboard

Das README verweist für den Einstieg auf docs/README.md und gibt selbst keine Befehlsfolge an. Als Betriebswege sind Docker, docker-compose, Kubernetes und Helm im Tech-Stack genannt, was die übliche Reihenfolge nahelegt: Umgebung über die Compose-Datei starten, MongoDB als Datenhaltung mitliefern, Frontend und Backend getrennt hochfahren. Konkrete Variablennamen für Modellschlüssel oder Datenbankverbindung lassen sich aus dem vorliegenden Material nicht belegen. Wer das Projekt ausprobiert, muss diese Werte der Dokumentation im docs-Verzeichnis entnehmen; ich habe sie nicht verifiziert. Dasselbe gilt für die Anbindung an einen Kanal: Das README nennt einen Web-Kanal über REST API und Chat-Snippet, während Facebook Messenger gelistet ist und Slack sowie WhatsApp über Twilio ausdrücklich als kommend markiert sind. Wer heute einen WhatsApp-Bot plant, plant gegen eine Ankündigung.

Der Alpha-Status ist keine Formalie

Die drei jüngsten Releases heißen v1.0.0-alpha.8, alpha.9 und alpha.10 und liegen laut Repository-Angaben innerhalb weniger Tage im Februar 2025. Solche Abstände deuten auf schnelle Iteration, nicht auf eingefrorene Schnittstellen. Für Betreiber heißt das: Datenstrukturen in MongoDB können sich zwischen zwei Versionen ändern, und ein Upgrade ist kein Selbstläufer. Die Knowledge-Base-Funktion mit RAG ist im README als in Entwicklung gekennzeichnet. Wer einen Bot auf Dokumenten aufbauen will, sollte sie nicht einplanen. Ein zweiter Punkt betrifft die Wartung: Das Projekt ist nicht archiviert und wird weiterentwickelt, aber es gibt kein Homepage-Feld und keine externe Dokumentationsseite. Die Pflege des eigenen Bots hängt damit an der Pflege des Frameworks, und die ist an ein einzelnes Repository gebunden.

Wann Rasa oder ein reiner LLM-Agent die bessere Wahl ist

Der offensichtliche Vergleich ist Rasa, das ebenfalls selbst gehostet wird und Intent-Erkennung mit trainierten Modellen kombiniert. Der Unterschied liegt in der Herkunft der Wahrheit. Rasa hält Dialogregeln in YAML-Dateien, die im Repository versioniert, reviewt und in Pipelines getestet werden. ai-chatbot-framework hält sie im Dashboard und damit in der Datenbank. Wer Auditierbarkeit, Code-Review für Dialogänderungen oder reproduzierbare Deployments braucht, ist mit dem dateibasierten Ansatz besser bedient; wer Fachbereiche ohne Git-Zugang einbinden will, mit dem Dashboard. Die zweite Alternative ist ein Agent, der ausschließlich über Tool-Calling und ein LLM arbeitet, ohne trainiertes NLU. Solche Systeme kommen ohne Beispielsätze aus, sind aber schlechter darin, einen festen Ablauf zuverlässig einzuhalten. ai-chatbot-framework versucht beides zu verbinden, was erklärbar macht, warum der Stack so breit ist: scikit-learn, TensorFlow, Spacy und python-crfsuite auf der einen, LLM-Zero-Shot auf der anderen Seite.

Lizenz und Betriebskosten

Das Projekt steht unter der MIT-Lizenz. Das erlaubt kommerzielle Nutzung und Änderungen, verlangt aber, dass der Lizenztext und der Urheberrechtshinweis in Kopien oder wesentlichen Teilen erhalten bleiben. Wer das Framework als Bestandteil eines eigenen Produkts ausliefert, muss diesen Hinweis mitführen. Das ist keine Rechtsberatung, sondern der Inhalt der Lizenzkennung. Die eigentlichen Betriebskosten liegen woanders: MongoDB muss laufen und gesichert werden, das Backend braucht Python-Abhängigkeiten aus dem ML-Umfeld, und die Zero-Shot-NLU verursacht Aufrufe bei einem Modellanbieter, deren Umfang das README nicht beziffert. Wer die Kosten planen will, muss die Aufrufe pro Dialogschritt selbst messen. Ein Kostenmodell gibt es im Repository nicht.

Redaktionelles Fazit

Wer einen internen Bot mit mehrstufigen Dialogen braucht und Python sowie MongoDB betreiben kann, findet hier eine nachvollziehbare Basis. Wer Produktionsreife, stabile Schnittstellen oder Support sucht, sollte warten: Die letzten Releases tragen Alpha-Nummern, und die RAG-Funktion ist laut README noch in Entwicklung. Vor dem Einsatz zu prüfen sind die tatsächlich verfügbaren Kanal-Integrationen, denn Slack und WhatsApp sind im README ausdrücklich als kommend markiert, sowie der Zustand der Mongo-Schemata zwischen zwei Alpha-Versionen.

Offizielle Quellen

1. alfredfrancis/ai-chatbot-framework on GitHub
2. Issues
3. License: MIT
4. README
5. Releases