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

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

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