RasaGPT — GitHub Analysis

RasaGPT is the first headless LLM chatbot platform built directly on top of Rasa NLU and the Langchain/LlamaIndex framework. It acts as an orchestrator that enables traditional conversational AI (Rasa) to work alongside modern Large Language Models (LLMs) and vector retrievers (pgvector).

RasaGPT is evaluated as production-grade.

• ✓High-throughput and low-latency thanks to the asynchronous performance of FastAPI, combined with PostgreSQL indexing of vector fields with pgvector.
• ✓Enables completely self-hosted deployments. Sensitive enterprise documents can be processed locally or within virtual private clouds without leaking raw text to third-party APIs.
• ✓High initial interest with over 2400 stars on GitHub, driven by developers eager to unify the standard Rasa conversational system with contemporary LLMs.
• ✓Highly templated config files, environment templates, and standard integration structures with Telegram and ngrok that minimize initial boilerplate.
• ✓Provides standard configuration guides, step-by-step setup checklists, and deep structural guides inside the repository README to ease the setup process.
• ✓Well-structured Python code utilizing typed schemas (SQLModel/Pydantic) and modular design patterns that clearly isolate the Rasa agent from vector ingestion pipelines.

• ✗No built-in visual admin dashboard for viewing conversation logs or tweaking prompts in real-time.
• ✗Missing native support for other chat platforms out-of-the-box (e.g., WhatsApp, Slack) beyond Telegram.
• ✗Lacks automated model-evaluation suites (RAGAS or TruLens style evaluation) to run automated accuracy checks on retrieved answers.
• ✗Dependency on Langchain and LlamaIndex, which undergo rapid API changes, occasionally leading to breaking code updates.
• ✗The repository relies on a carefully synchronized matrix of Rasa version and Python dependencies which can be brittle to update.
• ✗Lacks advanced migration guides for moving from older Rasa 2.x structures to newer Rasa 3.x setups.
• ✗No explicit documentation outlining production deployment configurations under Kubernetes or high-availability environments.
• ✗LLM response generation is bound by the model latency (OpenAI api latency or local model throughput), which can lead to long-tail response latencies for end users.
• ✗If public-facing webhooks lack strict validation signatures, third parties could craft custom JSON payloads mimicking Telegram events to flood or exploit LLM endpoints.
• ✗A mix of Node.js/TypeScript configuration files (like package.json, tsconfig.json) combined with Python src/ packages indicates some tooling fragmentation or monorepo remnants.