PrivateGPT: private Dokumente über eine OpenAI-kompatible Schnittstelle abfragen

PrivateGPT ist die Anwendungsschicht

PrivateGPT wird im README als Möglichkeit beschrieben, mit privaten Daten zu arbeiten, während die Anwendung an einen OpenAI-kompatiblen Inferenzserver angeschlossen wird. Die zentrale Grenze lautet ausdrücklich: PrivateGPT führt Modelle nicht selbst aus. Es erwartet einen bereits laufenden Dienst. Damit richtet sich die Architektur an Nutzer, die Modellbetrieb und Dokumentanwendung getrennt kontrollieren wollen. Die Bezeichnung privat ist folglich kein automatisch belegter Datenschutzstatus; Netzwerk, Speicher, Logs und der gewählte Modellserver bleiben Teil der eigenen Umgebung.

Der Quickstart beginnt beim Modellserver

Als Voraussetzung nennt die Quickstart-Dokumentation einen laufenden OpenAI-kompatiblen LLM-Server. Ollama wird als einfachster Startpunkt genannt. Auf macOS verweist das README auf den Homebrew-Weg mit `brew tap zylon-ai/tap` und `brew install private-gpt`. Dieser Befehl installiert die Anwendung, startet aber nach der dokumentierten Architektur nicht das Modell. Für einen ersten Versuch muss deshalb zuerst feststehen, unter welcher Adresse der Server erreichbar ist und welche Modelle er anbietet. Die Versions- und Systemkompatibilität ist im konkreten Setup zu prüfen.

OPENAIAPIBASE ist der entscheidende Anschluss

Die Verbindung zum Inferenzdienst wird über OPENAIAPIBASE beschrieben. Ein kompatibler Dienst funktioniert laut README, wenn er `/v1/chat/completions` und `/v1/models` implementiert. Das ist ein konkreter Prüfpunkt für jede Alternative zu Ollama. In einer isolierten Testumgebung sollte die konfigurierte Basisadresse aufgelöst, die Modellliste über `/v1/models` abgerufen und eine kurze Anfrage an `/v1/chat/completions` mit einem Testdokument ausgeführt werden. Erst wenn Antworten, Modellwahl und Fehlerfälle passen, lässt sich die PrivateGPT-Konfiguration sinnvoll beurteilen.

UI für Demo, API für das Produkt

PrivateGPT liefert laut README eine eingebaute Workbench unter `/ui`, die für Tests und Demos gedacht ist. Die API wird als das eigentliche Produkt bezeichnet. Diese Unterscheidung ist für die Auswahl wichtig: Eine gut erreichbare Oberfläche beweist nicht, dass die API in eine eigene Anwendung passt. Das README nennt interne Piloten, Videos und schnelle lokale Nutzung als passende UI-Szenarien, erwartet für dauerhafte Anwendungen aber eigene Entwicklung auf der API. Routing, Authentifizierung und Mehrbenutzerbetrieb sind aus dem Material nicht ausreichend beschrieben.

Datenbanken, MCP und eigene Werkzeuge

Als Konfigurationsbereiche nennt das Projekt Datenbanken, MCP-Connectoren, Skills und benutzerdefinierte Tools. Der README-Text liefert dafür keine vollständige Konfigurationsmatrix. Diese Begriffe sollten daher nicht als fertig eingerichtete Integrationen verstanden werden. Für einen Test ist ein einzelnes, unkritisches Dokument geeigneter als ein vollständiger Datenbestand. Beobachtet werden sollten Import, Suche, Antwortbezug und die tatsächlich angesprochenen Dienste. Besonders bei MCP und eigenen Tools müssen Berechtigungen und ausgehende Verbindungen zum eigenen Sicherheitsmodell passen; konkrete Defaults sind im Material nicht belegt.

Apache-2.0 und Betriebsrealität

Die Repository-Metadaten weisen Apache-2.0, den Branch main, 57407 Sterne, 7604 Forks und zwei offene Issues aus. Das sind Signale für Verbreitung und Aktivität, keine Garantie für Modellqualität oder Datenschutz. Apache-2.0 erlaubt die Nutzung und Änderung unter den dort geltenden Bedingungen; Lizenz- und NOTICE-Pflichten gehören in die eigene Distribution. Entscheidend bleibt der laufende Inferenzserver. Wer Daten nicht an einen externen Anbieter senden darf, muss OPENAIAPIBASE, Modellprozess, Speicher und Logs im eigenen Netz nachvollziehen. Das README belegt diese Kontrolle nicht automatisch. Auch der Begriff private sollte nicht mit einer vollständigen Ende-zu-Ende-Garantie verwechselt werden. Die Anwendung kann nur so abgeschottet sein wie der Server, auf den sie zeigt. Vor einem Teamtest gehört deshalb ein Netzplan dazu: Wo liegt das Modell, welche Adresse wird in OPENAIAPIBASE eingetragen, und welche Komponenten dürfen Dokumentinhalte sehen? Mit einem absichtlich unkritischen Dokument lassen sich außerdem Quellenbezug, Antwortqualität und Löschverhalten getrennt beobachten. Die `/ui`-Workbench ist dafür ein praktischer Einstieg, darf aber nicht stillschweigend als fertige Mehrbenutzerplattform gelten. Wer eine eigene Oberfläche baut, sollte die API-Verträge und die im README genannten Endpunkte als Integrationsgrenze behandeln. Nicht dokumentierte Funktionen, Authentifizierung oder Speicherfristen bleiben offene Punkte und müssen vor einer dauerhaften Einführung geklärt werden.

Ein kontrollierter Dokumenttest

Für PrivateGPT sollte der erste Durchlauf mit einem unkritischen Dokument und einem eindeutig bekannten Inhalt beginnen. Nach dem Import sind die Antwort, der Quellenbezug und die Reaktion auf eine nicht vorhandene Information getrennt zu prüfen. Dabei gehören die konfigurierte OPENAIAPIBASE und die Antworten von `/v1/models` in das Testprotokoll. So lässt sich unterscheiden, ob ein Fehler aus dem Modellserver, der Dokumentverarbeitung oder der API-Anwendung stammt. Der README-Text beschreibt diese Auswertung nicht als fertigen Prozess; sie bleibt eine konkrete Aufgabe für die eigene Einführung.

Redaktionelles Fazit

PrivateGPT passt zu Teams, die eine dokumentenbezogene Anwendung auf einer selbst kontrollierten OpenAI-kompatiblen Modell-API aufbauen wollen. Es ist keine eigenständige Modell-Laufzeit: Der README-Text verlangt einen laufenden Inferenzserver und nennt Ollama als einfachen Einstieg. Vor der Einführung sollten ein Testdokument, die tatsächliche OPENAIAPIBASE, die Endpunkte /v1/chat/completions und /v1/models sowie die Trennung zwischen /ui-Demo und produktiver API geprüft werden.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes