Paperless-ngx mit lokaler KI: Ollama und RAG auf Proxmox sinnvoll einsetzen

Paperless-ngx wird besonders interessant, wenn die Dokumente das eigene Netzwerk nicht verlassen müssen. In meinem Proxmox-Homelab laufen Paperless und Ollama deshalb getrennt: Paperless verwaltet Dokumente, OCR und Metadaten; ein eigener GPU-fähiger Ollama-LXC übernimmt lokale Sprachmodelle und Embeddings.

Das Ziel ist nicht, einer KI blind die komplette Ablage zu überlassen. Sinnvoller ist ein kontrolliertes System: semantische Suche und Vorschläge ja, automatische Massenänderungen erst nach einer überprüften Testphase.

Die Architektur

• ein eigener LXC für Paperless-ngx,
• ein separater LXC für Ollama und die GPU-Durchreichung,
• Kommunikation ausschließlich im internen Netz,
• keine Cloud-API für Dokumentinhalte,
• getrennte Sicherung von Dokumenten, Datenbank und KI-Index.

Die Trennung hat zwei Vorteile: Paperless bleibt auch dann stabil, wenn ein Modell viel RAM oder GPU-Leistung benötigt. Gleichzeitig kann Ollama unabhängig aktualisiert oder mit einem anderen Modell getestet werden.

Native Installation statt unnötiger Schichten

Schritt 1: Paperless-LXC anlegen

Ein reproduzierbarer Einstieg ist das aktuelle Paperless-ngx-Community-Script. Auf dem Proxmox-Host dessen Quelltext und Optionen vorab prüfen und dann ausführen. Scripts aus dem Netz laufen hier mit Host-Rechten – nur von einer Quelle starten, der du vertraust:

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/paperless-ngx.sh)"
pct list
pct status <PAPERLESS-CTID>

Im Installationsdialog eine freie Gast-ID, ausreichend Datenträger für Originale und Archiv, internes Netzwerk und Backup-Storage wählen. Die angezeigte URL nur im privaten Netz beziehungsweise per VPN öffnen. Admin-Kennwort ändern und erst mit einem einzelnen Test-PDF kontrollieren, ob OCR, Import und Suche funktionieren. Das Script kann sich ändern; im Zweifel gelten seine aktuelle Dokumentation und Installationsausgabe.

Schritt 2: Ollama getrennt installieren

Für Ollama einen separaten Debian-LXC oder eine VM vorbereiten. GPU-Passthrough ist hardware- und hostabhängig; zuerst einen CPU-Test durchführen. Innerhalb des Ollama-Gasts nach der offiziellen Linux-Anleitung installieren und den lokalen Dienst prüfen:

curl -fsSL https://ollama.com/install.sh | sh
systemctl status ollama --no-pager
ollama pull gemma3:4b
ollama run gemma3:4b "Fasse diesen Testsatz auf Deutsch zusammen."
curl -fsS http://127.0.0.1:11434/api/tags

Für den Zugriff aus dem Paperless-Gast braucht Ollama einen Listener auf der privaten Gast-IP und eine Firewall-Freigabe ausschließlich für diesen Gast. Nicht Port 11434 öffentlich ins Internet öffnen. Die konkrete RAG-Erweiterung und deren Konfigurationsoberfläche sind nicht Teil von Paperless-ngx selbst; Modell-URL, Embedding-Modell und Chunk-Größe nach deren eigener Versionsdokumentation eintragen.

Paperless läuft bei mir nativ unter /opt/paperless und wird über systemd verwaltet. Bei einer Funktionsprüfung kontrolliere ich nicht nur die Weboberfläche, sondern die beteiligten Dienste:

systemctl status paperless-webserver
systemctl status paperless-consumer
systemctl status paperless-task-queue
systemctl status paperless-scheduler

Gerade bei KI-Erweiterungen ist wichtig, welche Konfiguration tatsächlich aktiv ist. Werte aus der Benutzeroberfläche oder Datenbank können Umgebungsvariablen überschreiben. Deshalb zählt am Ende nicht die Konfigurationsdatei allein, sondern der effektive Laufzeitzustand.

Sprachmodell und Embeddings sind zwei verschiedene Aufgaben

Ein Sprachmodell fasst Inhalte zusammen oder erzeugt Vorschläge. Ein Embedding-Modell wandelt Textabschnitte in Vektoren um, damit semantisch ähnliche Inhalte gefunden werden können. Das schnellste Chatmodell ist daher nicht automatisch das beste Suchmodell.

In meinem deutschen Dokumentbestand hat sich folgende Kombination bewährt:

• gemma3:4b als kompaktes lokales Sprachmodell,
• multilingual-e5-small für mehrsprachige Embeddings,
• eine Chunk-Größe von 512 Tokens passend zum Embedding-Modell.

Im direkten deutschen Vergleich war das kleine E5-Modell ungefähr zehnmal schneller als die zuvor getestete Alternative. Das ist für einen regelmäßig aktualisierten Index oft wertvoller als ein minimal besseres Ergebnis bei einzelnen Dokumenten.

Warum die Chunk-Größe wichtig ist

Dokumente werden für die semantische Suche in Abschnitte zerlegt. Sind die Abschnitte größer als das Kontextfenster des Embedding-Modells, gehen Inhalte verloren oder werden abgeschnitten. Sind sie zu klein, fehlt Zusammenhang und die Zahl der Vektoren wächst unnötig.

Beim Wechsel von Embedding-Modell oder Chunk-Größe muss der Index vollständig neu aufgebaut werden. Ein bloßes inkrementelles Update mischt sonst alte und neue Vektoren.

document_llmindex rebuild --no-progress-bar -v 2
document_llmindex update

Danach prüfe ich nicht nur, ob der Befehl erfolgreich endet, sondern auch Datenbankintegrität, erwartete Dimension des Vektors, Dokumentanzahl und einen anschließenden inkrementellen Lauf.

Semantische Suche ist keine automatische Ablage

Das ist der wichtigste Punkt: Ein neu aufgebauter RAG-Index ändert nicht automatisch Titel, Tags, Korrespondenten, Dokumenttypen, Ablagepfade oder Datumsfelder. Er macht Inhalte auffindbar und ermöglicht Vorschläge.

Für eine spätere Automatisierung verwende ich deshalb einen vorsichtigen Ablauf:

1. 50 bis 100 repräsentative Dokumente nur lesend analysieren,
2. Vorschläge gegen vorhandene Metadaten vergleichen,
3. nur fehlende Felder ergänzen,
4. bestehende Angaben niemals automatisch überschreiben,
5. Datumsfelder zunächst vollständig ausnehmen,
6. Fehlerquote dokumentieren, bevor der Umfang wächst.

So bleibt die KI ein Assistent und wird nicht unbemerkt zum Datenbereiniger.

Performance und Speicher

Embeddings brauchen weniger Rechenleistung als große Chatmodelle, erzeugen aber einen wachsenden Index. Im Betrieb beobachte ich daher drei Dinge:

• Antwortzeit des Ollama-Endpunkts,
• Größe und Integrität der Indexdatenbank,
• freien Speicher im Paperless- und Ollama-Gast.

Modell-Cache, alte Indizes und temporäre Downloads können überraschend viel Platz belegen. Gelöscht wird nur, was eindeutig regenerierbar ist. Danach kann ein fstrim im Gast freigegebenen Speicher an den Proxmox-Thin-Pool zurückmelden.

Backups ohne falsches Sicherheitsgefühl

Paperless bringt einen Exporter mit. Dessen Aufruf hängt von Installationsart und Dienstbenutzer ab. Bei einer nativen Installation zuerst den vorhandenen Installationspfad und Benutzer prüfen; danach beispielsweise:

pct enter <PAPERLESS-CTID>
systemctl status paperless-webserver --no-pager
find /opt/paperless -maxdepth 4 -name manage.py -print

Im gefundenen Projektverzeichnis und mit dem Dienstbenutzer lässt sich der Exporter typischerweise so aufrufen:

sudo -u paperless python3 manage.py document_exporter /PFAD/ZUM/EXPORT

Python-Umgebung, Projektpfad und Dienstbenutzer sind installationsabhängig; bei einer virtuellen Umgebung deren Python verwenden. Das Exportziel muss dem Paperless-Benutzer gehören und genug freien Speicher bieten. Anschließend die Exportdateien auf ein getrenntes Backup-Ziel kopieren und einen Import in einer isolierten Testinstanz prüfen. Die Paperless-Dokumentation beschreibt Export und Import versionsbezogen.

Der KI-Index ist regenerierbar; die Originaldokumente und Metadaten sind es nicht. Deshalb priorisiere ich im Backup:

1. Originale und Archivdateien,
2. Paperless-Datenbank,
3. Konfiguration und Schlüssel,
4. erst danach Modell- und Indexdaten.

Ein Proxmox-Backup des kompletten Gasts ergänzt diese anwendungsnahe Sicherung. Wie immer gilt: Ein Restore in einem isolierten Testgast ist aussagekräftiger als ein grünes Häkchen im Jobprotokoll.

Fazit

Paperless-ngx und Ollama sind eine starke Kombination für private Dokumente. Der größte Gewinn entsteht nicht durch möglichst große Modelle, sondern durch eine passende Arbeitsteilung: stabiles Paperless, separates Ollama, schnelles mehrsprachiges Embedding und vorsichtige Metadatenregeln. So bleibt die Dokumentablage nachvollziehbar – und die Daten bleiben zu Hause.

Weiterlesen: meine Proxmox-Backup-Strategie · offizielle Paperless-ngx-Dokumentation · Ollama auf GitHub