Paperless OCR verbessern: best practise?

paperless-ngx
9

Hallo Alexander,

vielen Dank für dein Feedback! Es freut mich riesig, dass der Workflow dich inspiriert. Hier sind die Antworten auf deine Fragen:

  • Zu den drei Modellen: Ja, ich setze sie mittlerweile ganz gezielt für unterschiedliche Aufgaben ein (V3.2 „No-Swap Policy“).

    • Das Vision-Modell (qwen2.5vl:7b) läuft auf der GPU und ist die „Speerspitze“ für OCR und Bildanalyse. Es läuft im PRE-Skript und ist das “menschliche Auge” für die Generierung der JSON-Metadaten.

    • Ein kleineres, flinkeres Text-Modell (qwen2.5:3b) übernimmt zur selben Zeit auf der CPU Aufgaben im POST-Skript wie Zusammenfassungen, falls die GPU gerade mit dem nächsten Scan beschäftigt ist.

    • Das Embedding-Modell kümmert sich rein um die Vektorisierung für die Duplikaterkennung. Diese Trennung ist kein Kompromiss für schwache Systeme, sondern eine Strategie, um den Grafikspeicher (VRAM) stabil zu halten und Modell-Wechsel (Swapping) zu vermeiden, was früher oft zu Abstürzen führte.

  • PDF-Reparatur (Ghostscript): Absolut, das ist ein Kernbestandteil! Ich nutze dafür den DocumentOptimizer in Verbindung mit ocrmypdf. Bevor ein Dokument an Paperless geht, wird es – falls nötig – „geputzt“. Dabei werden defekte Header repariert, schiefe Seiten begradigt (Deskew) und das Ganze in ein sauberes, archivtaugliches PDF/A umgewandelt. Das löst genau das Problem der „consume errors“ bei älteren oder schlecht codierten Scans.

  • Eigener Chatbot vs. paperless-ai: Es ist eine “Eigenentwicklung” unter Open WebUI. Ich nutze zwar Paperless-ngx als Basis, aber die KI-Logik (Watchdog, RAG-Chat, Metadaten-Extraktion) habe ich in eigenen Python-Skripten (Werkzeug Open WebUI) programmiert. Das gibt mir die volle Kontrolle darüber, wie die Dokumente verarbeitet werden und wie die KI auf die Datenbank zugreift (RAG = Retrieval-Augmented Generation).

  • Sync-Tokens & JWT Seed: Hier geht es vor allem um die Beständigkeit. Wir haben einen festen JWT-Seed (WEBUI_SECRET_KEY) in der Konfiguration verankert. Ohne diesen „festen Anker“ würde die Open WebUI bei jedem Update einen neuen Sicherheitsschlüssel würfeln. Das Ergebnis: Deine Session-Tokens wären ungültig, du müsstest dich ständig neu einloggen und der Bot würde den Zusammenhang zum bisherigen Chat verlieren. Der „Sicherung“-Aspekt sorgt also dafür, dass der Zugang und das „Gedächtnis“ des Bots über Container-Updates hinweg stabil bleiben.

Ich hoffe, das bringt etwas Licht ins Dunkel! Wenn du weitere Details zum Code oder zum Setup brauchst, meld dich einfach.

Beste Grüße, Heiko

und noch die fehlende Antwort auf die Frage ob das Setup auf getrennten Systemen lauffähig ist:

Das ist natürlich problemlos möglich. Die Skripte würden in diesem Fall auf deinem PC laufen und sich die benötigten Daten direkt von deinem NUC/Synology abrufen.

Ich hatte eine ähnliche Konstellation zuvor mit einer Synology im Einsatz. Da die leistungsschwächeren Systeme jedoch oft mit der ressourcenintensiven Erstellung der OCR-Archivdateien überfordert sind, habe ich die Verarbeitung mittlerweile komplett auf meinen leistungsstärkeren Rechner ausgelagert. Mein nächster Schritt wird sein, dieses Hauptsystem mit meiner Synology zu synchronisieren (z. B. durch eine gemeinsame Datenbanknutzung).

Mein Vorschlag für deinen Workflow:

  • Vorverarbeitung auf dem PC: Belasse den Input-Ordner auf dem PC, damit dieser die anspruchsvolle Verarbeitung durch das Vision-Modell (LLM) übernehmen kann.

  • Übergabe an Paperless-ngx: Sobald das Dokument auf diese Weise „veredelt“ wurde, wird es im nächsten Schritt einfach an den Consume-Ordner von Paperless-ngx weitergereicht.

Die Skripte sind prinzipiell so flexibel aufgebaut, dass du die URL deiner Paperless-ngx-Instanz ganz bequem in den jeweiligen Config-Dateien anpassen kannst.

Hier ist mein Vorschlag für die optimale Verteilung der Skripte in deiner Dual-System-Architektur. Diese Aufteilung nutzt die enorme Leistung deines PCs für die KI-Arbeit und hält den NUC/Server frei für die Verwaltung und Archivierung.

:desktop_computer: RECHNER 1: Dein Haupt-PC (The „Muscle“)

meine Hardware: Intel Core Ultra, RTX 5060 Ti (16GB VRAM)

Hier laufen alle Skripte, die direkte Rechenpower benötigen:

  • ollama-gpu (Container): Das Herzstück für das Vision-Modell (qwen2.5vl). Hier findet das eigentliche „Sehen“ der Dokumente statt.

  • ollama-cpu (Container): Erledigt die Text-Zusammenfassungen und das Tagging parallel zur GPU.

  • ai_watchdog.py: Dieser läuft auf dem PC und überwacht deinen lokalen Input-Ordner. Er jagt die PDFs durch die lokale GPU, veredelt sie und schiebt sie erst nach der Analyse auf den NUC (in den Consume-Ordner).

  • ollama-monitor (Optional): Falls du die Auslastung deiner RTX 5060 Ti im Blick behalten willst.

:package: RECHNER 2: Dein NUC / Synology (The „Brain & Storage“)

Hardware: NUC oder NAS (Permanent online)

Hier laufen die Dienste, die immer erreichbar sein müssen und die Daten verwalten:

  • Paperless-ngx (Kern-System): Webserver, Datenbank und Broker.

  • ai_post_consume.py: Läuft als Docker-Hook auf dem Server. Wenn du mal am PC vorbei ein Dokument hochlädst, bemerkt dieses Skript das und fragt die KI-API deines PCs über das Netzwerk an.

  • chromadb (Vektor-Datenbank): Hier liegen die eingebetteten Texte für die Suche. Da der Server immer an ist, sind diese Daten dort am besten aufgehoben.

  • Web-Dashboard: Damit du von überall im Haus sehen kannst, wie weit deine KI-Verarbeitung gerade ist.

:counterclockwise_arrows_button: Der Workflow (Die Brücke)

  1. Input: Du scannst ein Dokument in einen Ordner auf deinem PC.

  2. Verarbeitung: Der ai_watchdog am PC erkennt es, nutzt die RTX 5060 Ti für OCR und Metadata.

  3. Transfer: Das fertige Dokument landet im consume-Ordner des NUC.

  4. Finalisierung: Paperless am NUC archiviert es. Das ai_post_consume am NUC macht den Dubletten-Check und füttert die Datenbank.

Dein Vorteil bei dieser Verteilung:

  • Ruhe am NUC: Der Server wird nicht heiß und bleibt flüssig bedienbar, da er keine schweren KI-Modelle berechnen muss.

  • Speed am PC: Dein PC kann mit voller Kraft (V3-Architektur) arbeiten, solange er an ist.

  • Flexibilität: Wenn dein PC mal aus ist, „parkt“ Paperless die Dokumente einfach und das Post-Skript am NUC holt die Analyse nach, sobald der PC wieder im Netz erscheint.

Das ist die Profi-Lösung für „Home-Datacenter“!

[Release] Paperless-AI High-End Vision Pipeline V3.4 – Asynchron, Ressourcenschonend & Retroaktiv

Hallo zusammen,

inspiriert von den tollen Ansätzen hier im Forum (besonders von @ab_news / olmOCRund @Stefan mit seinen Videokursen über Paperless-NGX oder künstliche Intelligenz), habe ich mein System in den letzten Wochen zur Version 3.4 weiterentwickelt. Mein Fokus lag dabei auf maximaler Stabilität für Systeme mit begrenztem VRAM (16GB) und höchster Ressourceneffizienz.

Ich freue mich, euch heute mein Repository vorstellen zu dürfen: :backhand_index_pointing_right: GitHub: paperless-ai-high-performance

Was macht diesen Workflow besonders?

Während viele Ansätze synchron arbeiten, nutzt diese Pipeline ein asynchrones Producer-Consumer-Design. Das bedeutet: Die CPU bereitet Dokumente vor (Zerlegung in Bilder), während die GPU parallel die KI-Analyse durchführt. Das eliminiert Leerlaufzeiten und ist extrem flink.

Flexibilität bei der Hardware-Verteilung: Das System ist so konzipiert, dass es flexibel aufgeteilt werden kann:

  • Paperless-ngx & Watchdog können ressourcensparend auf einem NAS (z.B. Synology) oder NUC laufen.

  • Der Ollama-Server (die KI-Power) kann auf einem dedizierten GPU-Server (Windows mit WSL2 oder Linux) ausgelagert werden. Die Kommunikation erfolgt effizient über das Netzwerk, sodass euer NAS nicht durch die KI-Last in die Knie geht.

Die Key-Features von V3.4:

  1. :rocket: Retroactive OCR: Mein persönliches Highlight. Ihr wollt alte Dokumente in Paperless neu durch die KI-Pipeline jagen? Einfach den Tag AI-OCR in der Web-UI vergeben. Das System erkennt das, lädt das Original herunter und aktualisiert Text & Metadaten (und Vektoren!) vollautomatisch.

  2. :zzz: Resource Saver: Der ollama-cpu Container (für Texte/Embeddings) schaltet sich bei Nichtbenutzung nach 5 Min. selbst ab und startet bei Bedarf automatisch neu. Das spart Strom und RAM.

  3. :shield: No-Swap Policy: Intelligentes Routing zwischen GPU und CPU verhindert VRAM-Abstürze durch Modellwechsel. Die Pipeline bleibt auch bei Dauerlast stabil.

  4. :magnifying_glass_tilted_left: Pre-Vision Duplicate Check: Bevor die GPU überhaupt „wach“ wird, prüft das System via schnellem Text-Extrakt und ChromaDB-Vektorvergleich, ob das Dokument bereits bekannt ist.

  5. :brain: Full Understanding: Es ist kein reines OCR. Die KI extrahiert aktiv Titel, Datum, Korrespondenten und Tags aus dem visuellen Kontext.

Installation & Setup

Das Repository ist „clean“ und für den produktiven Einsatz vorbereitet. Schaut euch einfach die

README.md und die ai_config.yaml.example an. Es ist so vorkonfiguriert, dass sensible Daten (Medien, Datenbanken) sicher ausgeschlossen bleiben.

Ich freue mich auf euer Feedback, eure Ideen und natürlich auch über GitHub-Sterne, wenn euch das Projekt hilft!

Beste Grüße, Heiko

1 „Gefällt mir“