Simba: Kundenservice-RAG mit eingebauter Evaluation

Welches Problem Simba adressiert

Viele Chatbot-Baukästen liefern eine Antwort, aber keine Messgröße dafür, ob diese Antwort brauchbar war. Simba setzt genau dort an: Das Repository beschreibt sich als Kundenservice-Assistent, der von Anfang an um Evaluation und Anpassung herum entworfen wurde. Die Zielgruppe sind laut README Teams, die die volle Kontrolle über ihren KI-Stack behalten wollen, statt sich an einen Anbieter zu binden. Konkret richtet sich das Projekt an Entwickler, die eine eigene Wissensbasis einbringen, Embedding-Modelle und LLMs austauschen und die Qualität des Retrievals mit Zahlen statt mit Bauchgefühl beurteilen möchten. Die Themenliste des Repositories (customer-service, evals, knowledge-base, llm, rag) bestätigt diesen Zuschnitt. Wer lediglich einen fertigen Support-Bot mieten will, findet hier keinen fertigen Dienst, sondern eine Baustelle, die betrieben werden muss.

Der Datenfluss durch die Architektur

Das README zeigt ein Diagramm mit vier Stationen. Das npm-Paket simba-chat-widget läuft auf der eigenen Website und spricht mit der Simba-API, die als FastAPI-Anwendung beschrieben wird. Diese API greift auf einen Vector Store zu, im Diagramm mit Qdrant oder FAISS benannt. Für die Antwortgenerierung ruft die API ein LLM auf, wahlweise OpenAI oder ein lokales Modell. Der Ingestion-Pfad verläuft getrennt: Celery nimmt die Dokumentenverarbeitung entgegen und nutzt Redis als Task Queue. Das ist eine klassische Aufteilung, bei der die schwere Arbeit asynchron läuft und der Chat-Endpunkt nicht auf das Parsen großer PDFs warten muss. Bemerkenswert ist, dass die Dokumentation den Celery-Pfad nur im Diagramm und in der Komponententabelle erwähnt, aber keine Konfigurationsschlüssel für Broker oder Ergebnis-Backend nennt. Wer den Stack ohne Docker betreibt, muss diese Werte selbst herleiten.

Installation über Docker oder pip

Der schnellste Weg laut README führt über Docker. Nach dem Klonen des Repositories wird eine .env-Datei mit OPENAI_API_KEY angelegt, danach folgt entweder DEVICE=cpu make build && make up oder DEVICE=cuda make build && make up für NVIDIA-Hardware. Das Dashboard ist anschließend unter http://localhost:3000 erreichbar. Ohne Docker installiert man das Python-Paket mit pip install simba-core und startet die beiden Prozesse getrennt über simba server und simba front. Für die Website-Einbindung kommt npm install simba-chat-widget hinzu, gefolgt von einer React-Komponente, die apiUrl und theme als Props erhält. Wer Claude Code verwendet, kann die Einrichtung laut README mit /setup --all abkürzen, wobei auch die Varianten --backend, --frontend und --services dokumentiert sind. Auffällig: Die Anleitung nennt nur OPENAI_API_KEY als Umgebungsvariable. Für die im Diagramm gezeigten Komponenten Redis, Celery und einen austauschbaren Vector Store sind keine Beispielwerte angegeben, sodass der Docker-Weg faktisch der einzige vollständig beschriebene Pfad ist.

Evaluation als Teil der Pipeline

Der Kern des Projekts ist das Bewertungsframework. Das README nennt drei Gruppen von Metriken: Retrieval-Metriken wie Precision, Recall und Relevanzwerte, Generierungsmetriken wie Faithfulness, Antwortrelevanz und Latenz, sowie Konversationsanalysen zu Nutzerzufriedenheit und Lösungsraten. Diese Einteilung orientiert sich an gängigen RAG-Bewertungsschemata, was für Vergleichbarkeit spricht. Die Dokumentation bleibt allerdings bei der Aufzählung stehen. Es fehlen Angaben dazu, wie ein Evaluationslauf gestartet wird, ob ein Testdatensatz im Repository mitgeliefert wird, welche Bibliothek die Metriken berechnet und ob die Ergebnisse in der Datenbank oder nur im Dashboard landen. Genau diese Lücke ist relevant, denn ein Bewertungsframework ohne dokumentierten Ausführungspfad lässt sich in der Praxis schwer in eine CI-Pipeline einhängen. Wer Simba wegen der Evals evaluiert, sollte deshalb zuerst prüfen, ob der zugrunde liegende Code die Metriken tatsächlich implementiert oder ob die Liste im README eher eine Zielbeschreibung ist.

Grenzen und Fälle, in denen Simba das falsche Werkzeug ist

Die Roadmap ist der ehrlichste Teil des README. Multi-Tenant-Unterstützung steht dort noch als offener Punkt, ebenso erweiterte Analytik, Webhook-Integrationen und eine Fine-Tuning-Pipeline. Für einen Anbieter, der mehrere Kundenmandanten mit getrennten Wissensbasen über eine Instanz bedienen will, ist das ein Ausschlusskriterium, solange die Isolation nicht implementiert ist. Auch die Anbindung an bestehende Ticketsysteme fehlt ohne Webhooks. Ein zweiter Punkt betrifft die Versionierung: Die letzten Releases v0.2.0 bis v0.4.0 liegen laut Repository im März 2025, während der letzte Push in den Main-Branch später datiert ist. Wer auf stabile Schnittstellen angewiesen ist, muss damit rechnen, dass sich Konfiguration und API zwischen Minor-Versionen bewegen. Drittens erfordert der Selbstbetrieb mindestens drei bewegliche Dienste (FastAPI, Celery, Redis) plus einen Vector Store. Teams ohne Erfahrung mit asynchronen Python-Workern unterschätzen diesen Aufwand regelmäßig.

Alternative: Flowise und LangServe im Vergleich

Wer den RAG-Stack lieber grafisch zusammenklickt, landet häufig bei Flowise. Der Unterschied liegt im Ansatz: Flowise modelliert die Pipeline als Knotengraphen in einer Weboberfläche, während Simba den Ablauf im Code hält und ein Bewertungsframework mitliefert. Flowise ist schneller für Prototypen, Simba ist besser nachvollziehbar, wenn Retrieval-Qualität über Wochen gemessen werden soll. Eine zweite Alternative ist LangServe, das eine LangChain-Kette als HTTP-Endpunkt bereitstellt. LangServe liefert jedoch kein Chat-Widget, kein Dashboard und keine vordefinierten Retrieval- und Generierungsmetriken. Der Preis für Simbas Rundumpaket ist die engere Kopplung: Wer nur einen einzelnen Endpunkt braucht, trägt bei Simba mehr Komponenten mit, als die Aufgabe verlangt. Umgekehrt spart Simba die Arbeit, ein eigenes Bewertungsschema und ein Widget von Hand zu bauen.

Wartung, Aktualisierung und Lizenz

Das Projekt steht unter Apache-2.0. Diese Lizenz erlaubt kommerzielle Nutzung, Modifikation und Weitergabe, verlangt aber, dass Lizenzhinweise und Änderungen an den Dateien kenntlich gemacht werden. Wer Simba als gehosteten Dienst anbietet, muss außerdem die Patentklausel und die Haftungsausschlüsse der Lizenz beachten. Das ist keine Rechtsberatung, sondern nur der Hinweis, dass Apache-2.0 im Gegensatz zu Copyleft-Lizenzen keine Veröffentlichung eigener Änderungen erzwingt. Beim Upgrade-Pfad ist Vorsicht angebracht: Zwischen v0.2.0 und v0.4.0 liegen nur wenige Tage, was auf schnelle Iteration hindeutet. Wer den Docker-Weg nutzt, sollte vor jedem Sprung auf eine neue Version die make-Ziele und die .env-Variablen gegen das dann aktuelle README prüfen, weil die Anleitung nur OPENAI_API_KEY dokumentiert. Ein Changelog ist in den bereitgestellten Informationen nicht enthalten, sodass sich Breaking Changes nicht vorab aus den Release Notes ableiten lassen.

Einordnung für die Adoption

Simba ist kein fertiges Produkt, sondern ein Gerüst mit klarer Meinung: RAG-Pipeline, Bewertung und Auslieferung an die Website sollen aus einer Hand kommen. Das ist dann sinnvoll, wenn ein Team ohnehin eine eigene Wissensbasis pflegt und den Stack selbst verantworten will. Die drei Fragen, die vor einem Einsatz zu klären sind, betreffen die tatsächliche Implementierung der Evaluationsmetriken, das Verhalten des Celery-Ingestion-Pfads unter realistischer Dokumentenlast und die Frage, ob die fehlende Multi-Tenant-Unterstützung den geplanten Betrieb ausschließt. Wer alle drei mit ja beantwortet, findet hier eine Apache-2.0-lizenzierte Basis, die weniger zusammenkleben muss als ein Baukasten ohne eingebaute Bewertung.

Redaktionelles Fazit

Simba passt zu Teams, die eine eigene Wissensbasis betreiben, den RAG-Stack selbst zusammenstellen wollen und bereit sind, die FastAPI-, Celery- und Redis-Komponenten zu verantworten. Wer einen reinen SaaS-Chatbot ohne Betriebsaufwand sucht, ist hier falsch, ebenso alle, die Multi-Tenant-Isolation oder Webhooks benötigen, denn beides steht in der Roadmap noch als offener Punkt. Vor dem Einsatz zu prüfen: ob die Evaluationsmetriken gegen die eigene Wissensbasis aussagekräftig sind, wie sich der Ingestion-Pfad über Celery und Redis unter der erwarteten Dokumentenmenge verhält und ob die Apache-2.0-Lizenz mit den eigenen Betriebsanforderungen zusammengeht.

Offizielle Quellen

1. GitHamza0206/simba on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases