DocsGPT: Private RAG-Plattform mit Agent Builder und lokalen Modellen
Private AI platform for agents, assistants and enterprise search. Built-in Agent Builder, Deep research, Document analysis, Multi-model support, and API connectivity for agents.
Auf einen Blick
- Was ist das?
- DocsGPT verbindet Dokumentenanalyse, Agenten und Suche in einer selbst hostbaren Flask-Anwendung. Der Setup-Skript-Ansatz senkt die Einstiegshürde, die Lizenz bleibt MIT, aber der Betrieb verlangt Docker und eigene Modellentscheidungen.
- Für wen ist es gedacht?
- DocsGPT passt zu Teams, die Dokumentenanalyse und Agenten selbst hosten wollen und Docker sowie einen Modell-Provider mitbringen. Wer nur einen Chat über eine Handvoll PDFs braucht, fährt mit einem schlanken RAG-Skript oder einem Managed Service günstiger.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem DocsGPT löst und für wen
Die meisten RAG-Demos enden als Jupyter-Notebook, das genau eine PDF-Sammlung kennt. DocsGPT setzt eine Ebene höher an: Es bündelt Dokumentenaufnahme, Vektorsuche, Chat-Oberfläche, Agenten und API-Zugänge in einer Anwendung, die sich selbst hosten lässt. Der Anspruch laut README ist Privatsphäre und Kontrolle über die Daten, deshalb die Betonung auf lokal laufenden Modellen über Ollama oder llama_cpp neben den Cloud-Anbietern OpenAI, Google und Anthropic.
Die Zielgruppe lässt sich aus den Roadmap-Einträgen ablesen: SharePoint- und Confluence-Konnektoren, OIDC/SSO mit SCIM, Rollen und Teams, Admin-Dashboard. Das sind Funktionen für Organisationen mit bestehender Identitätsverwaltung, nicht für Einzelentwickler. Wer einen internen Assistenten über Handbücher, Wikis und Meeting-Aufzeichnungen bauen will und die Datenhoheit behalten muss, ist der adressierte Fall. Wer dagegen nur eine einzelne Wissensdatenbank durchsuchbar machen möchte, trägt hier mehr Betriebslast als nötig.
Was der Aufnahme-Pfad tatsächlich umfasst
Die Formatliste im README ist ungewöhnlich breit: PDF, DOCX, CSV, XLSX, EPUB, MD, RST, HTML, MDX, JSON, PPTX, dazu Bilder sowie Audio in MP3, WAV, M4A, OGG und WebM. Für Audio beschreibt das README einen zweistufigen Ablauf: Aufnahme im Chat, Transkription im Backend, danach Aufnahme des Transkripts als durchsuchbares Wissen. Das ist der Punkt, an dem sich DocsGPT von reinen PDF-Chattools unterscheidet. Besprechungsmitschnitte und Sprachnotizen landen im selben Index wie Handbücher.
Als Quellen jenseits von Dateien nennt das README URLs, Sitemaps, Reddit, GitHub und Web-Crawler. Wer diese Konnektoren produktiv nutzt, sollte den Aktualisierungszyklus selbst definieren, denn das Material beschreibt die Ingestion, nicht einen Abgleich in festen Intervallen. Genau dort entsteht in der Praxis der Aufwand: Ein einmalig gefüllter Index veraltet, und die Verantwortung dafür liegt beim Betreiber.
Architektur: Flask-Backend, Vite-Frontend, Docker Compose
Die Projektstruktur nennt drei Teile. Der Ordner docsgpt enthält die Flask-Anwendung als Python-Paket. Der Ordner Frontend beherbergt die Weboberfläche auf Basis von Vite und React. Unter Extensions liegen Integrationen und Widgets, im README genannt sind Chatwoot und ein React-Widget. Das README verweist zusätzlich auf ein Architekturbild, ohne dessen Inhalt im Text zu erläutern. Details zu Vektorstore, Embedding-Modell oder Chunking-Strategie lassen sich aus dem vorliegenden Material nicht ableiten.
Der Datenfluss, den das README beschreibt, ist geradlinig: Dokumente oder Web-Quellen werden aufgenommen, im Backend verarbeitet und über die Oberfläche mit Quellenangaben beantwortet. Die Antworten sollen mit Zitaten belegbar sein, was für Prüfpfade in regulierten Umgebungen relevant ist. Die Roadmap nennt eine Postgres-Migration für Nutzerdaten und OpenTelemetry für Observability, beides mit Datum April 2026. Ob eure Version diese Punkte bereits enthält, lässt sich nur im Changelog der jeweiligen Release prüfen.
Inbetriebnahme über setup.sh und setup.ps1
Der Einstieg ist als Skript geführt, nicht als Sammlung manueller Befehle. Nach dem Klonen des Repositories startet man unter macOS und Linux mit ./setup.sh, unter Windows mit PowerShell -ExecutionPolicy Bypass -File .\setup.ps1. Das Skript führt durch fünf Optionen: öffentliche API, lokaler Betrieb, Anbindung einer lokalen Inferenz-Engine, ein Cloud-API-Anbieter oder ein lokal gebautes Docker-Image. Laut README schreibt das Skript die .env-Datei und übernimmt Downloads und Installationen passend zur Auswahl.
Danach ist die Oberfläche unter http://localhost:5173/ erreichbar. Zum Beenden dient docker compose -f deployment/docker-compose.yaml down. Wer den Dienst hinter einem Reverse Proxy oder in Kubernetes betreiben will, findet im README nur den Hinweis auf Kubernetes-Unterstützung, keine Manifeste. Die .env-Datei ist der zentrale Konfigurationspunkt, aber das README listet die Schlüssel nicht auf. Diese Liste muss man der Dokumentation unter docs.docsgpt.cloud entnehmen, bevor man eine Variante wählt, denn die Modellwahl bestimmt später, welche Daten das Haus verlassen.
Grenzen: Betriebslast, Modellabhängigkeit, unklare Details
Die ehrlichste Einschränkung steht implizit im Setup: DocsGPT ist eine Mehrkomponenten-Anwendung mit Docker Compose, Flask-Backend, Vite-Frontend und Datenhaltung. Das ist kein Werkzeug, das man an einem Nachmittag produktiv stellt. Wer keinen Container-Betrieb und keine Modellinfrastruktur verantwortet, unterschätzt den Aufwand.
Der zweite Punkt ist die Modellabhängigkeit. Zwar unterstützt das Projekt lokale Modelle, doch die Qualität der Antworten hängt vollständig vom gewählten Modell ab. Das README verspricht "accurate, hallucination-free responses with source citations". Zitate helfen bei der Prüfung, beseitigen aber keine Fehler im Retrieval. Wenn die Suche den falschen Abschnitt liefert, ist das Zitat korrekt und die Antwort trotzdem falsch. Diese Trennung zwischen Belegbarkeit und Korrektheit wird in der Projektbeschreibung nicht thematisiert.
Drittens die Materiallücke: Es gibt keinen Hinweis auf Ressourcenbedarf, Indexgrößen oder Grenzen bei der Anzahl der Dokumente. Für Kapazitätsplanung ist das unzureichend. Wer tausende Dokumente erwartet, sollte vorher selbst messen statt sich auf Zusagen zu verlassen.
Alternative: LlamaIndex oder Haystack statt Vollplattform
Wer nur Retrieval braucht, nicht die komplette Oberfläche, ist mit einem Framework wie LlamaIndex oder Haystack besser bedient. Der Unterschied liegt im Ansatz: DocsGPT liefert eine fertige Anwendung mit UI, Agenten, Konnektoren und Rollenkonzept. LlamaIndex liefert Bausteine, aus denen man die Pipeline selbst zusammensetzt, inklusive eigener Entscheidungen zu Chunking, Embeddings und Vektorstore.
Das ist keine Frage von besser oder schlechter, sondern von Verantwortungsverteilung. DocsGPT nimmt euch die Oberfläche und die Ingestion ab, gibt aber die Kontrolle über diese Schichten nur soweit das Projekt sie öffnet. Ein eigenes Skript auf Basis von LlamaIndex ist mehr Arbeit am Anfang und mehr Freiheit danach. Für ein Team, das eine interne Anwendung mit Anmeldung, Teams und Audit-Pfad braucht, ist der fertige Stack die günstigere Wahl. Für ein Forschungsteam, das die Retrieval-Qualität systematisch variieren will, ist er ein Umweg.
Wartung, Upgrades und Lizenz
Die Release-Kadenz ist eng: 0.17.3 im Juni 2026, 0.18.0 im selben Monat, 0.19.0 im August 2026. Allein das bedeutet, dass Upgrades regelmäßig anstehen und man einen Weg braucht, sie zu testen. Die Roadmap listet abgeschlossene Punkte mit Datum, was die Planung erleichtert, aber auch zeigt, wie schnell sich Datenmodell und Konfiguration bewegen. Die Postgres-Migration für Nutzerdaten und die Analytics-Überarbeitung mit Zuordnung pro Agent sind Beispiele für Änderungen, die bestehende Installationen betreffen können.
Die Lizenz ist MIT. Das erlaubt kommerzielle Nutzung, Änderung und Weitergabe, solange Lizenz- und Urheberrechtshinweis erhalten bleiben. Es besteht keine Pflicht, eigene Änderungen offenzulegen. Das ist für Unternehmen mit internen Anpassungen günstig. Die Lizenzangabe im Repository ist die Quelle, die zählt; dies ist keine Rechtsberatung, und wer DocsGPT in ein Produkt einbettet, sollte die Lizenzbedingungen selbst prüfen.
Ein Kostenpunkt bleibt unabhängig von der Lizenz: Der Betrieb verursacht Rechenzeit, und die Modellwahl entscheidet, ob diese im eigenen Haus oder beim Anbieter anfällt. Genau diese Entscheidung trifft man im setup.sh, und sie ist später nur mit Aufwand zu revidieren.
Redaktionelles Fazit
DocsGPT passt zu Teams, die Dokumentenanalyse und Agenten selbst hosten wollen und Docker sowie einen Modell-Provider mitbringen. Wer nur einen Chat über eine Handvoll PDFs braucht, fährt mit einem schlanken RAG-Skript oder einem Managed Service günstiger. Vor dem Produktivgang zu prüfen: ob die gewählte Deployment-Variante im setup.sh zu eurer Modellstrategie passt, ob Postgres als Datastore für Nutzerdaten aktiv ist und welche der Roadmap-Punkte wie OIDC/SSO und RBAC in eurer Version tatsächlich enthalten sind.
Community-Notizen