Liebe Alle,
das Thema “schlechte OCR Erkennung in paperless-ngx” beschäftig mich auch schon eine Weile und so habe auch ich zum Programmieren angefangen.
Ähnlich wie Heiko’s Workflow ist auch Meiner ein pre-processing. Ich habe ihn dann aber auch auf post-processing erweitert, damit man schon die vorhanden Dokumente nochmals OCR scannen kann.
Da ich mein paperless auf einer Synology NAS betreibe und alle KI-Aufgaben durch meine Spark erledigen lasse, gibt es hier zwangsläufig Unterschiede zu anderen Konfigurationen.
Eine Schritt für Schritt Anleitung zur Installation habe ich auf GitHub veröffentlicht:
Hier noch ein Kurzüberblick auf Deutsch, was die Konfiguration lösen soll:
Diese Konfiguration implementiert eine vollständig automatisierte End-to-End-Pipeline zur Dokumentenverarbeitung mit den folgenden Funktionen:
1. Automatische OCR bei neuen Scans
Legen Sie eine PDF-Datei im Scan-Eingabeordner ab, und das System übernimmt den Rest. Der AI-Watchdog erkennt die neue Datei, sendet jede Seite als Bild an das KI-Modell auf dem GPU-Server, empfängt den extrahierten Text und leitet das Dokument – zusammen mit einer JSON-Datei, die das OCR-Ergebnis enthält – an die paperless-ngx-Verarbeitungs-Pipeline weiter. Es sind keine manuellen Schritte erforderlich.
2. Korrespondenzzuweisung über Unterordner
Der Scan-Eingabeordner unterstützt einen Unterordner pro Person oder Einheit (z. B. /scaninput//). Jedes Dokument, das in einen Unterordner abgelegt wird, wird automatisch dem entsprechenden Korrespondenten in paperless-ngx zugewiesen. Wenn der Korrespondent noch nicht existiert, wird er automatisch über die API erstellt.
3. Nachträgliche OCR für vorhandene Dokumente
Dokumente, die sich bereits in paperless-ngx befinden – unabhängig davon, ob sie vor dieser Einrichtung importiert oder zuvor mit schlechten Tesseract-Ergebnissen verarbeitet wurden – können jederzeit mit AI OCR erneut verarbeitet werden. Fügen Sie einfach das Tag „OCR” zu einem Dokument in der paperless-ngx-Benutzeroberfläche hinzu. Ein Hintergrund-Thread überprüft alle 5 Minuten, ob Dokumente mit diesem Tag vorhanden sind, lädt die Original-PDF-Datei herunter, führt die KI-OCR durch, schreibt das Ergebnis über die API zurück und ersetzt das Tag durch „OCR-done“, um den Abschluss zu bestätigen. Für die sofortige Verarbeitung steht auch ein manueller Trigger zur Verfügung.
4. Reibungsloser Fallback, wenn der KI-Server offline ist
Wenn der Ollama-Server vorübergehend nicht erreichbar ist, wird die Pipeline nicht unterbrochen. Die PDF-Datei wird weiterhin in das Verzeichnis „paperless-ngx consume“ verschoben und als Fallback mit der integrierten Tesseract-OCR verarbeitet. Die Wiederholungslogik versucht mehrmals, Ollama zu erreichen, bevor sie aufgibt, sodass kurze Netzwerkunterbrechungen transparent behandelt werden.
5. Robuste Wiederholungslogik
Jeder Netzwerkaufruf an Ollama – Zustandsprüfung, Modell-Warmup und OCR-Anfragen pro Seite – ist in eine konfigurierbare Wiederholungsschleife eingebettet (Standard: 3 Versuche mit 10-sekündigen Pausen). Dadurch ist das System robust gegenüber vorübergehenden GPU-Lastspitzen, Verzögerungen beim Modellwechsel oder kurzen Verbindungsproblemen zwischen dem NAS und dem KI-Server.
6. Wartungsfreier Betrieb
Nach der Bereitstellung läuft das System vollständig autonom. Der ai-Watchdog startet automatisch mit Docker, der Retagger-Thread läuft im Hintergrund und alle Python-Skripte werden als Docker-Volume gemountet – das bedeutet, dass Konfigurationsänderungen nur einen Neustart des Containers erfordern, nicht aber eine vollständige Neuerstellung des Images.
So funktioniert es auf einen Blick
Die beiden Maschinen kommunizieren ausschließlich über das lokale Netzwerk über die Ollama-HTTP-API. Das NAS benötigt niemals direkten GPU-Zugriff – es sendet einfach Bilddaten an den KI-Server und erhält Text zurück. Durch diese klare Trennung kann der KI-Server aktualisiert, ausgetauscht oder vorübergehend offline genommen werden, ohne dass dies Auswirkungen auf das NAS oder paperless-ngx selbst hat.
Das Sidecar-JSON ist der zentrale Übergabemechanismus: Wenn der ai-watchdog die OCR für eine Datei abgeschlossen hat, schreibt er eine kleine JSON-Datei (gleicher Dateiname, Erweiterung .json) in ein gemeinsames Sidecar-Verzeichnis. Wenn paperless-ngx die PDF-Datei kurz darauf verarbeitet, liest das Skript post-consume.sh diesen Sidecar, extrahiert den OCR-Text und die entsprechenden Informationen und schreibt beides über die paperless-ngx-REST-API in einem einzigen PATCH-Aufruf in das Dokument. Der Sidecar wird anschließend gelöscht.
Grüße, Alexander
Dann hab ich auf der Synology den Rest des Wochendes versucht meine Ursprungskonfig wiederherzustellen. Hab draus hoffentlich gelernt und werde jetzt die Installationen via Portainer in Zukunft machen, dann sind die unterschiedlichen Konfigurationen besser und komfortabler von einander isoliert… 
