Paperless OCR verbessern: best practise?

Hallo Leute,

Mein paperless läuft seit kurzem und mit papernext als App zum scannen per Handy bin ich sehr zufrieden. Der scan ist zwar nicht überragend und macht kaum Bild Bearbeitung (zB Faltung aus Briefen entfernen), aber der automatische Upload ist unschlagbar.

Jetzt ist es leider so, dass das OCR in paperless wirklich schlecht anspringt bei mir. Das Wort “Grundsteuerbescheid” wurde komplett nicht erkannt von paperless, obwohl auf dem Brief und im PDF deutlich zu erkennen. Neu einlesen in paperless hat nix geändert.

Paperless OCR Mode ist auf redo

Languages hab ich auf deu

language auch deu

Woran kann ich jetzt noch drehen, ohne einen komplizierten workflow mit KI oder dritt Tools? Oder gibt es keinen anderen Weg? Habt ihr eine simple Anleitung für mich, wie ich das machen könnte (nicht weil ich keinen Plan hab, sondern wegen Zeitmangel)?

Leider kann ich mir keinen separaten Scanner oä anschaffen. Handy ist Muss. Alternative zu papernext wäre ok, hab aber nach langer recherche nichts vergleichbares gefunden. Hab sogar mit syncthing experimentiert und hatte auch da keine gute Handy App gefunden, mit der das ginge, ohne permanent Werbung zu kriegen oder ins blaue 20€ für die Handy app zu zahlen.

Freue mich auf eure Rückmeldung!

Vermutlich wird sich in den kommenden Monaten viel tun, wenn wir in die Lage versetzt werden, unsere eigene KI auf die Dokumente loszulassen. Nach dem, was ich bisher gelesen habe, wird sie “Grundsteuerbescheid” sehr sicher erkennen können.

Pfiffikus,
der sehr aufmerksam beobachtet, wie diese Technologie aus den Kinderschuhen heraus wächst

Und außer warten gibt’s keine gute Möglichkeit? :cry: Schade, das Projekt ist so groß und gut gepflegt, viele Features. Hätte gedacht, dass es da eine einfache Lösung gibt, aber dann muss ich wohl warten :face_with_peeking_eye:

Hallo ! :waving_hand:

Ich möchte dir mein Setup vorstellen, mit dem ich
Paperless-ngx um eine vollständig lokale KI-Pipeline erweitert
habe. Keine Cloud, keine API-Kosten – alles läuft auf dem eigenen Server.

:bullseye: Was macht das System?

Kurz gesagt: Jedes Dokument, das ich einscanne oder importiere, wird automatisch von einer Vision-KI (Qwen2.5-VL via Ollama) analysiert.

Das Ergebnis:

  • Automatische
    Titel-Vergabe
    (z.B. „Rechnung Telekom Januar 2025“)

  • Korrespondent,
    Tags und Dokumenttyp
    werden erkannt und gesetzt

  • Hochwertige
    OCR
    direkt aus dem Bild (kein Tesseract-Salat bei Mehrspaltlern!)

  • Duplikaterkennung per
    Vektor-Ähnlichkeit (ChromaDB) + Binärvergleich

  • Optimiertes
    Archiv-PDF
    mit sauberem OCR-Layer

:building_construction: Architektur

Das System besteht aus zwei Stufen, die
vollständig in Docker laufen:

Stufe 1: AI Watchdog (Vor dem Import)

Ein eigener Container überwacht den scan_input-Ordner.
Sobald eine Datei auftaucht:

  1. Binärer Duplikat-Check (MD5 gegen Paperless-DB)

  2. PDF → Bilder konvertieren und optimieren (Schärfung, Kontrast)

  3. Vision-AI analysiert jede Seite (OCR + Layout-Erhaltung)

  4. Sidecar-JSON mit allen Ergebnissen wird erstellt

  5. Original wird unverändert(!) in den consume-Ordner verschoben

(Das Kopieren in den Consume-Ordner bleibt folgenlos)

Stufe 2: Post-Consume Script (Nach dem Import)

Paperless importiert das Dokument und triggert mein
Post-Consume-Script:

  1. Sidecar einlesen → Metadaten anwenden (Titel, Tags, Korrespondent, Datum)

  2. Content überschreiben mit dem besseren AI-OCR-Text

  3. Vektor-Duplikaterkennung via ChromaDB

  4. ChromaDB-Indexierung für semantische Suche

  5. Archiv-PDF optimieren

  6. Tag „paperless-ai“ setzen → Fertig! :white_check_mark:

:light_bulb: Das Besondere:
Fail-Safe + Retry

Falls die AI-Analyse im Watchdog scheitert (z.B.
verschlüsseltes PDF, Timeout):

  • Das Dokument wird trotzdem importiert (Fail-Safe)

  • Das Post-Consume-Script erkennt die fehlenden Daten und startet automatisch
    einen zweiten Versuch
    im Container

  • Das funktioniert sogar für DOCX und Bilder: Hier wird das von
    Paperless erstellte Archiv-PDF für die Vision-Analyse genutzt

:spouting_whale: Docker-Setup (Komplettes Re-Build eines Paperless-ngx)

Das Ganze läuft mit folgenden Containern:

Container Aufgabe

webserver - Paperless-ngx (Custom Build mit Python-Deps)

ai-worker - Watchdog (überwacht scan_input)

chromadb - Vektordatenbank für Duplikaterkennung

ai-chat - Ollama mit Open-WebUI (Dokumente per Chat durchsuchen)

broker - Redis

db - PostgreSQL

gotenberg - Office-Konvertierung

tika - Textextraktion

Ollama läuft bei mir direkt auf dem Host
(GPU-Zugriff). Kann aber auch als Container integriert werden.

:wrench: Verwendetes Modell

  • Qwen2.5-VL:7b via Ollama

  • Läuft bei mir auf Intel Core i7 Ultra, 32 GB-DDR5, Nividia RTX 5060 (16GB VRAM)

  • Verarbeitung: ~30-60 Sekunden pro Seite (je nach Komplexität)

  • Auch auf CPU möglich, dann natürlich langsamer

:hammer_and_wrench: Besondere Features

  • Zombie-Erkennung: Binärer Duplikat-Check prüft, ob die Datei physisch existiert. „Geister“
    in der DB werden ignoriert.

  • ChromaDB Cleanup: Wartungsskript zum Entfernen verwaister Vektoren (maintenance_cleanup_vectors.py).

  • Kein Datenverlust: Originale werden NIEMALS verändert. Alles passiert
    auf Kopien/im Archiv-Layer.

  • Deutsche Optimierung: Prompts und Metadaten-Extraktion sind auf deutsche
    Dokumente optimiert.

:red_question_mark: FAQ

Q: Brauche ich eine GPU? A: Empfohlen, aber
nicht zwingend. Qwen2.5-VL:7b läuft auch auf CPU, dann dauert es nur deutlich
länger.

Q: Funktioniert das auch mit nicht-deutschen Dokumenten?

A: Ja, die Prompts sind auf Deutsch, aber das Modell versteht auch Englisch/andere
Sprachen problemlos.

Credits: Ein großer Teil der Implementierung
wurde mit Unterstützung von Antigravity AI (Google DeepMind)
entwickelt. :robot:

2 „Gefällt mir“

Moin Heiko,

kann man Dein Setup ausprobieren?

LG Jürgen

Hallo Jürgen,

prinzipiell kann ich das Setup bereitstellen. Da ich aber den kompletten Paperless-NGX Container verbogen habe muss ich erst einmal ein Installationsskript inkl. Zip-Datei verfassen. mal sehen ob ich es am Wochenende schaffe.

Grüße Heiko

1 „Gefällt mir“

Paperless-ngx meets local AI: Ein komplett autonomer Workflow (Das große V2 Update)

Hallo zusammen! Ich möchte heute meinen Workflow teilen, mit dem ich meine Paperless-ngx Instanz um ein komplett lokales, autonomes KI-Backend (auf Basis von Ollama) erweitert habe. Das Setup ist in den letzten Tagen durch wertvolles Feedback massiv gewachsen und hat nun den Status „Rock Solid“ erreicht: Echte asynchrone Parallelverarbeitung, absolute Absturzsicherheit und unantastbare PDF/A-Originaldokumente.

Das Ziel: Keine externen Cloud-Abhängigkeiten (Datenschutz!), maximale Hardware-Effizienz und perfekte Erkennungsrate (selbst bei schlechten Handy-Fotos oder zerkratzten Ausweiskopien).


:desktop_computer: Hardware & Systemvoraussetzungen

Mein System läuft auf Windows 11 Pro mit WSL2 (Ubuntu 24.04). Die Hardware-Basis bildet ein Intel Core i7 Ultra mit 32 GB DDR5-RAM und einer Nvidia RTX 5060 Ti (16 GB VRAM). Die 16 GB VRAM der Grafikkarte sind der absolute Sweet-Spot, um die Qwen-Modelle mitsamt der Embedding-Datenbank performant im Grafikspeicher zu halten.


:hammer_and_wrench: Architektur & Setup (Hybrid-LLM Ansatz)

Das Setup läuft vollständig via docker-compose. Das Herzstück ist ein selbst geschriebener, radikal entkoppelter ai_watchdog Container (Python). Um Hardware-Ressourcen zu schonen und gleichzeitig extrem schnell zu sein, setzt das System auf einen Hybrid-Zweiklang bei den lokalen LLMs (gesteuert von Ollama):

  • Das schwere Vision-Modell (qwen2.5vl:7b): Hat „Augen“, liest Bilder, ignoriert Hologramme auf Ausweisen und extrahiert komplexe Metadaten aus dem Layout.

  • Das leichte Text-Modell (qwen2.5:3b): Ist rasend schnell, braucht kaum VRAM und liest gigantische Textblöcke fehlerfrei (ideal für Zusammenfassungen).

  • Das Embedding-Modell (nomic-embed-text): Für die blitzschnelle semantische Vektorsuche (Speicherung in ChromaDB).


:counterclockwise_arrows_button: Der Workflow (Schritt für Schritt)

1. Asynchrone Jobs & Die Warteschlange (Producer/Consumer)

Früher blockierte die OCR den Paperless-Eingang. Das ist Geschichte!

  • Der Scanner (Producer): Wenn neue PDFs im scan_input Ordner landen, zieht ein flinker Frontend-Thread sie in Bruchteilen einer Sekunde in einen versteckten ai_staging Zwischenordner. Dort zerlegt die CPU sie hocheffizient in flüchtige Base64-Strings (direkt im RAM).

  • Die GPU (Consumer): Ein asynchroner Hintergrund-Thread nimmt sich diese Bilder aus einer Queue, sobald die Grafikkarte frei ist. Das schwere Vision-Modell rattert die Liste entspannt ab.

  • Live-Zähler: In den Docker-Logs steht live: „GPU beginnt mit OCR für: Rechnung.pdf | Noch 19 Dokument(e) in der Warteschlange.“ Paperless kann währenddessen ungestört weiterarbeiten.

2. Absturzsicherheit & „Ghost-Busting“ (Recovery)

Was passiert, wenn der Docker-Container mitten im großen KI-Scan abstürzt?

  • Beim Neustart scannt das System den verborgenen ai_staging Ordner und reiht abgebrochene Jobs automatisch wieder in die Warteschlange ein.

  • Geister-Schutz: Um fiese Duplikat-Fehler in Paperless zu vermeiden, prüft das Skript live über die Paperless-API den Datei-Hash (SHA-256). Liegt das defekte PDF in Wirklichkeit längst sicher im Archiv, löscht das Skript die „Dateileiche“ im Staging-Ordner stillschweigend.

3. Archiv-Integrität & „Hands-off“ bei Originalen

Viele externe KI-Skripte wandeln Bilder brutal in Graustufen um und überschreiben das bunte, gut strukturierte originale PDF physisch auf der Festplatte. Meine Philosophie:

  • Wir belassen das Original (mit allen Farben, Wasserzeichen und Vektoren) absolut unangetastet.

  • In meinem Setup greift die KI auf der Festplatte nichts destruktiv an. Bilder werden nur flüchtig als JSON im RAM analysiert.

  • Paperless verarbeitet das Original nativ zu sauberen PDF/A Dateien. Die KI hängt ihre erkannten Tags, Daten und den extrahierten Text einfach transparent über die API an (ai_post_consume.py).

4. Smart Duplicate Detection (Vektor-Ähnlichkeit)

Das Post-Consume Skript berechnet beim Einlesen ein semantisches Text-Embedding des neuen Dokuments und gleicht es über ChromaDB mit dem Archiv ab.

  • Bei z.B. >92% Ähnlichkeit (z.B. derselbe Telekom-Vertrag in zwei minimal verschiedenen PDF-Formaten) wird nicht blind gelöscht.

  • Das Skript vergibt intelligent das Tag „Duplikat“ und hinterlegt eine Notiz ans Dokument mit einem direkten Klick-Link zum Vergleich mit dem Ursprungsdokument. (Die Reihenfolge in den Skripten ist dabei entscheidend!).

5. Content Summary & RAG Chatbot

  • Zusammenfassung: Die KI liest große Textblöcke und wirft gigantisch schnell eine 3-Satz-Zusammenfassung (Kernaussagen, Fristen, Beträge) als Notiz ans Dokument an.

  • Chatbot (Open WebUI): Die vollständige Anbindung der Paperless-DB an Open WebUI, um mit eigenen Dokumenten privat zu chatten („Welche Versicherungen habe ich letztes Jahr gekündigt?“). Dank eines fixierten WEBUI_SECRET_KEY in der docker-compose.yaml verfallen die Sync-Tokens auch bei Docker-Updates nie wieder!

6. Spezielle Härtefälle: Ausweiskopien

Ausweise und Pässe haben extrem komplexe Sicherheits-Hintergrundmuster, an denen klassische OCRs (und auch Vision-KIs oft) völlig scheitern und „halluzinieren“ (z.B. indem sie nur noch einzelne Ziffern wie eine „9“ ausgeben). Durch rigoroses Prompt-Engineering in der Yaml-Config ist das Vision-Modell nun darauf gedrillt, diese störenden Hologramme chirurgisch auszublenden und sich rein auf Namen, Geburtsdatum und die Behörden-MRZ-Zahlenreihen am unteren Rand zu konzentrieren.

7. Performance Limit: Große Dokumente (> 10 Seiten)

Ein extrem wichtiges Detail zum Schluss: Um die Pipeline vor einem VRAM-Infarkt durch 50-seitige Handbücher zu bewahren, überprüft der Watchdog im initialen, asynchronen Durchlauf strikt nur die ersten 10 Seiten jedes neuen PDFs.

Für alles darüber hinaus gibt es ein beiliegendes Batch-Skript (z.B. process_by_tag.py): Wenn ihr in Paperless feststellt, dass ein Dokument sehr lang ist und ihr zwingendalleSeiten durch die KI jagen wollt, vergebt ihr dem Dokument manuell das Tag"KI-NOCHMAL". Ein abendlicher Cronjob (oder manueller Aufruf) greift dann all diese markierten Mega-Dokumente auf und veredelt sie in aller Ruhe über Nacht komplett!

8. Das Paperless AI Control Panel (Web-Dashboard)

Ganz neu hinzugekommen in diesem Export-Paket ist ein leichtgewichtiges Browser-Dashboard (ähnlich wie Portainer, nur spezifisch für diesen KI-Workflow). Unter Port 8050 erreicht ihr ab sofort ein edles Dark-Mode-Interface, um die Container nicht mehr übers Terminal steuern zu müssen:

  • Live Logs: Verfolgt in Echtzeit, was der Watchdog treibt und wie viele Dokumente in der Warteschlange hängen.

  • Skripte triggern: Führt Batch-Verarbeitungen (process_by_tag.py) oder ChromaDB-Aufräumaktionen mit einem simplen Mausklick aus.

  • Duplikate-Verwaltung: Eine clevere Liste aller erkannten Archiv-Duplikate ermöglicht euch per Knopfdruck („Vergleichen“) den sofortigen Side-by-Side-Ansichtssprung in Paperless-ngx.

  • Datensicherheit (Backup & Restore): Ein Button für ein inkonsistenzfreies Komplett-Backup (stoppt kurz alle Services, zieht alle Vektoren, DBs und PDFs in ein .tar.gz Archiv und startet wieder). Ein weiterer Button erlaubt die sofortige Wiederherstellung aus bestehenden Archiven oder direkt per Datei-Upload vom lokalen PC bei komplett frischen Systemen!


:bullseye: Mein Fazit

Durch das radikal entkoppelte Producer/Consumer-Skripting rennt die Pipeline nun auch bei wilden Bulk-Uploads von extrem anspruchsvollen Formaten geschmeidig und logisch nachvollziehbar im Hintergrund durch.

Sollte jemand von euch auf ähnliche Probleme stoßen (zerstörte Archive nach KI-Durchlauf, VRAM-Kollapse, gestrandete Dateileichen in Staging-Ordnern oder scheiternde Ausweiskopien), hoffe ich, dass dieser Workflow als gute Blaupause dient.

Vielleicht gibt das dem ein oder anderen neue Inspiration für eigene Bastelprojekte!


:warning: Ein wichtiger Hinweis zum Schluss (Vibe Coding): ein großer Teil dieses Setup ist im Laufe vieler „Vibe Coding“-Sessions entstanden (viel Trial & Error, LLM-Pair-Programming und kreatives Ausprobieren). Ich übernehme daher keinerlei Garantie für die Lauffähigkeit auf anderen Systemen oder für die absolute Datensicherheit eurer Archive. Wer die Skripte übernimmt, tut dies auf eigenes Risiko – checkt eure Backups! :wink:

Davon abgesehen bin ich aber wahnsinnig gerne bereit, bei der Fehlerbehebung, der Anpassung an andere Systeme oder der initialen Implementierung dieser Lösung in eure Paperless-Instanzen zu helfen. Meldet euch einfach hier im Thread!

Hinweis: Aus Vorsicht teile ich das Installations-Skript samt der zugehörigen ZIP-Datei nicht direkt inflationär hier im Post, sondern schicke es bei ernsthaftem Interesse sehr gerne einfach per kurzer PN (Privater Nachricht) rüber.

Da schon erste Anfragen zum Thema Verteilung auf getrennte Systeme aufkamen:

https://forum.digitalisierung-mit-kopf.de/t/aw-ocr-verbesserung-mit-lokalem-llm/3228/2?u=heiko

1 „Gefällt mir“

Lieber Heiko,

ein MEGA Workflow und eine tolle Umsetzung, die Du da geleistet hast!! Finde viele Dinge sehr inspirierend und gut durchdacht!
Bei einigen Beschreibungen des Workflows habe ich noch Fragen:

  • Du beschreibst die drei Modelle. Hast Du sie verschiedentlich in Deinem Workflow zum Einsatz gebracht (und falls ja, bei welcher Gelegenheit), oder stellst Du sie als Alternative für Leistungsschwächere Systeme vor?

  • In einem früheren Posting ( Neues Video: Hands-on: Texterkennung (OCR) durch lokale KI: Endlich Handschrift & Kassenbons erkennen? - #9 von Heiko ) hast Du eine Teil vorgestellt, den ich sehr interessant fand, aber nicht weiß, ob Du ihn hier umgesetzt hast, bzw. ich ihn richtig verstanden habe. Es geht um den Schritt “PDF-Reparatur (Ghostscript)”. War damals gemeint, dass Du das PDF auf Fehler checkst und gegebenenfalls reparieren kannst, bevor Du es dann später an paperless übergibst - es kommt ja immer wieder vor, dass ältere PDF nicht lesbar für paperless sind (z.B. die consume errors) und auf dem “Fehlgeschlagen” Haufen landen.

  • Hast Du einen eigenen Chatbot und ein Zusammenfassungstool programmiert, oder verwendest Du im Hintergrund paperless-ai?

  • Ich habe den Part und den Zusammenhang mit den Sync-Tokens noch nicht ganz verstanden. Was passiert wenn die Sync-Tokens verloren gehen und warum ist das für den privaten Chat relevant? Als Sicherung, damit ich den Bot nicht nochmal fragen muss?

Grüße, Alexander

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“

Lieber Heiko,

ich habe bei meiner Konfig immer wieder das Problem, dass das Modell qwen2.5vl:7b immer mal wieder “hängen” bleibt und dann Wörter/Buchstaben quasi fast endlos wiederholt, bis dann wieder Sinnvoller text kommt. (siehe Screenshot)

Hast Du das auch ab und zu? Gibt es dafür eine Erklärung, bzw. einen Patch, wie man das vermeiden kann?
Ich habe nie ein Muster erkennen können (wie z.B. immer dasselbe Schriftstück, oder schlechte Qualität) - das hat sich immer irgendwie zufällig verhalten und war aber schon immer an ein Modell gebunden. Habe ich das Modell gewechselt, war das natürlich nicht mehr gleich - dafür gab’s dann andere Probleme :grinning_face_with_smiling_eyes:

Grüße, Alexander

Hallo Alexander,

da ich dein System nur schätzen kann (siehe den anderen Foreneintrag mit NAS und KI-Server), vermute ich stark, dass es am Speicherplatz (VRAM/RAM) liegt.

Wenn du zu viel auf einmal möchtest, geraten lokale Systeme wie Ollama an ihre Grenzen. Wenn der Chatverlauf oder das hochgeladene Dokument zu lang wird und die maximale Token-Anzahl des Modells (z.B. 8.000 Tokens) überschreitet, „vergisst“ die KI plötzlich die anfängliche Anweisung. Sie weiß nicht mehr, worum es geht, verliert den Kontext und fängt an zu stammeln oder zu loopen. Da du von einer getrennten Verarbeitung zwischen NAS und KI gesprochen hast, kommt vielleicht noch „Swapping“ hinzu (wie oft bei Paperless-GPT zu beobachten, wenn OCR und Tag-Zuordnung gleichzeitig laufen). Das bedeutet, dein KI-Server ist noch mit der Anfrage zu Titel oder Tag beschäftigt und dein OCR-Skript will schon Bilder nachschieben.

Der Speicherbedarf: qwen2.5vl:7b bei 8000 Token

Ein Modell mit 7 Milliarden Parametern (7B) ist ordentlich groß. Wie viel Arbeitsspeicher (RAM) oder Grafikkartenspeicher (VRAM) es benötigt, hängt massiv von der sogenannten Quantisierung (Komprimierung) ab. Hinzu kommt der Speicher, den das Modell braucht, um sich deinen Chatverlauf und deine Eingaben zu merken – der sogenannte KV Cache (Kontextfenster).

Wenn wir von einem recht großen Kontext von 8000 Token ausgehen, sieht die Rechnung grob so aus:

  • Bei 8-Bit Quantisierung (geringe Komprimierung, hohe Qualität):

    • Modellgewichte: ca. 7 bis 8 GB

    • Kontextspeicher (8000 Token): ca. 1 bis 2 GB

    • Gesamtbedarf: ca. 8 bis 10 GB VRAM/RAM

  • Bei 4-Bit Quantisierung (Standard für lokale Nutzung, z.B. Q4_K_M):

    • Modellgewichte: ca. 4 bis 4,5 GB

    • Kontextspeicher (8000 Token): ca. 1 bis 1,5 GB

    • Gesamtbedarf: ca. 5 bis 6 GB VRAM/RAM

Was passiert, wenn das System ans Limit stößt?

Wenn du beispielsweise eine Grafikkarte mit 8 GB VRAM besitzt und das Modell in 8-Bit mit vollen 8000 Token ausreizt, sprengst du den verfügbaren Speicherhaushalt. Dann passieren meist zwei Dinge, die dein Fehlerbild exakt beschreiben:

  1. Auslagerung (Swapping): Die Software (wie Ollama, LM Studio etc.) merkt, dass der VRAM voll ist, und lagert die restlichen Daten in den normalen, aber massiv langsameren CPU-Arbeitsspeicher aus. Das Modell wird extrem langsam, was sich anfühlt, als würde es komplett „hängenbleiben“.

  2. Kontext-Abriss: Wenn der Speicher wirklich voll läuft oder das Limit falsch konfiguriert ist, wird das „Gedächtnis“ des Modells überschrieben oder abgeschnitten. Das Modell verliert mitten im Satz den Faden, vergisst den Anfang des Prompts und stürzt in eine sogenannte Repetition Loop. In diesem verwirrten Zustand ist die Ausgabe von „d“ gefolgt von „er“ statistisch gesehen plötzlich die einzige logische Fortsetzung für das Modell.

Wie du das Problem umgehen kannst

  • Quantisierung anpassen: Wenn du aktuell ein 8-Bit-Modell (oder gar unquantisiertes 16-Bit) nutzt, wechsle unbedingt auf eine 4-Bit-Version (z.B. q4_k_m). Das entlastet den Speicher enorm und lässt genug Luft für den Kontext.

  • „Bildauflösung herunter setzen 200 statt 400 DPI“ Vision-Modelle zerlegen Bilder in kleine Kacheln (Patches) und wandeln diese in Tokens um. Je höher die Auflösung (DPI) deines Scans aus Paperless-NGX, desto mehr Kacheln entstehen und desto gigantischer wird der Token-Verbrauch im Kontextfenster. Eine Reduzierung der DPI spart massiv VRAM, ohne dass die Texterkennung (OCR) zwingend schlechter wird.

  • Kontextgröße (Context Size) begrenzen: Wenn du keine riesigen Textdokumente analysierst, reduziere das Limit in deinen Einstellungen von 8000 auf beispielsweise 4000 Token.

  • Repetition Penalty (Wiederholungsstrafe) erhöhen: Setze diesen Wert in deinen Inferenz-Einstellungen leicht nach oben (z.B. auf 1.1 oder 1.15). Das zwingt das Modell aktiv dazu, solche „d er d er“-Schleifen mathematisch abzuwerten und den Fehler früher abzufangen.

  • RAM leeren: Nach getaner Arbeit das Modell manuell entladen (z.B. über ollama stop qwen2.5vl), um den alten „Müll“ aus dem Speicher zu werfen und Platz für den nächsten Durchlauf zu schaffen. (musste ich früher immer bei Paperless-GPT machen weil sich die KI jedes mal aufgehangen hat)

Ich hoffe ich habe dir erst einmal genügend Probleme zurückgegeben um dich das Wochenende zu beschäftigen :wink:.

PS: habe jetzt mein Ursprüngliches Setup auch auf NAS und PC verteilt, da ich die Stromkosten senken möchte.

Grüße Heiko

1 „Gefällt mir“

Mein Paperless-ngx Hybrid AI-Setup: NAS trifft auf GPU-Power (Ollama + Open WebUI + RAG)

Hallo zusammen,

ich wollte euch heute mal mein aktuelles Dokumenten-Setup vorstellen, an dem ich in den letzten Wochen intensiv gefeilt habe. Vielleicht ist es für den einen oder anderen eine Inspiration, der vor dem gleichen Problem steht wie ich: Ein NAS ist super für Storage, aber zu schwach für moderne KI-Anwendungen.

Hier ist mein „Best of Both Worlds“ Ansatz: Paperless-ngx Dual-Host Setup.

Review

System Workflow Concept

:building_construction: Die Architektur: NAS & PC Hand in Hand

Statt alles auf die Synology zu quetschen, habe ich die Last verteilt:

  • Synology NAS (DS224+): Beherbergt den Paperless-Webserver, die Datenbank und den Dateispeicher. Hier liegen die Dokumente sicher und im Raid.

  • Windows 11 PC (mit WSL2 & RTX 5060 Ti): Hier schlägt das Herz der KI. Dank der 16 GB VRAM laufen Ollama und ChromaDB flüssig im Hintergrund.

:counterclockwise_arrows_button: Der Workflow: Automatisierung pur

Mein Setup nutzt einen AI-Watchdog, der den scan_input Ordner überwacht. Sobald ein neues Dokument reinkommt, passiert Folgendes:

  1. High-Quality OCR: Falls das PDF kein OCR hat, schickt der PC es an die lokale KI für eine Textextraktion.

  2. Metadata Magic: Eine KI analysiert den Text und schlägt Titel, Datum, Korrespondent und Tags vor.

  3. Vektorbasiertes Duplicate-Checking: Bevor ein Dokument im NAS landet, prüft ChromaDB via Vektor-Similarity, ob ich das Dokument (oder ein sehr ähnliches) schon einmal hochgeladen habe. Falls ja, wird es markiert und aussortiert.

  4. RAG-Integration: Alle Dokumente werden automatisch in die Knowledge-Base von Open WebUI synchronisiert.

:counterclockwise_arrows_button: Der „Retro“-Turbo: Nachbearbeitung von Bestandsdaten

Ein besonders mächtiges Feature ist die gezielte Nachbearbeitung von Dokumenten, die bereits seit Jahren in Paperless liegen:

  • Der AI-OCR Trigger: Vergebe ich in Paperless den Tag AI-OCR (oder einen anderen konfigurierten Trigger), erkennt mein PC-Worker das innerhalb von Sekunden.

  • Batch-Processing: Die KI wird dann auf das Bestandsdokument losgelassen, führt ein hochqualitatives OCR durch, extrahiert fehlende Metadaten und fügt eine Zusammenfassung in die Notizen ein.

  • Auto-Cleanup: Nach erfolgreicher Bearbeitung entfernt das System den Trigger-Tag automatisch und hinterlegt eine Erfolgsnotiz. So lassen sich tausende Dokumente über Nacht „smart“ machen.

:robot: Chatten mit den Dokumenten

Das Highlight ist die Einbindung von Open WebUI. Ich kann meine gesamte Paperless-Bibliothek einfach „fragen“:

  • „Wann läuft meine KFZ-Versicherung ab?“

  • „Fasse mir die letzte Stromrechnung zusammen.“ Die KI greift direkt auf die synchronisierten PDFs zu und liefert Antworten basierend auf meinen echten Daten (RAG - Retrieval Augmented Generation).

:hammer_and_wrench: Custom Fixes & Stabilität

Um das Ganze alltagstauglich zu machen, mussten einige Hürden genommen werden:

  • JBIG2 Support: Custom Docker-Build für Open WebUI, um auch ältere/komprimierte PDFs lesen zu können.

  • PDF-Rescue-Patch: Ein eingebauter Monkey-Patch verhindert Abstürze bei fehlerhaften Bilddaten in PDFs.

  • Dashboard: Ein zentrales Dashboard zeigt den Status aller Container und erlaubt Backups auf Knopfdruck.


Hier ein kurzes Beispiel für den OCR-Layer (High-Quality OCR):

:warning: Wichtiger Fallstrick: Wer Ollama bisher als systemd-Dienst (systemctl) betrieben hat, sollte diesen vor dem Start der Docker-Container deaktivieren. Laufen beide parallel, teilen sie sich die GPU – die Instanzen blockieren sich gegenseitig im VRAM, was zu sporadischen Connection reset-Fehlern und GPU-Hangs führt. Nach systemctl disable --now ollama und Port-Anpassung in der Config (1143411436) läuft alles deutlich stabiler.

Paperless-ngx AI Control Center (Dual-System Control)

weiterhin möchte ich euch mein Dashboard für ein erweitertes Paperless-ngx AI Setup vorstellen. Das Besondere an diesem Setup ist die hybride Architektur:

  • Synology DS224+: Hostet die Paperless-Instanz, die PostgreSQL-Datenbank und das Medien-Archiv.

  • AI-Worker PC (WSL2): Übernimmt die rechenintensiven Aufgaben wie OCR-Backfill, Vektor-Generierung (Ollama/ChromaDB) und Dokumenten-Klassifizierung per LLM.

Da die Verwaltung über zwei Systeme (NAS und PC) schnell unübersichtlich wurde, habe ich ein zentrales Control Center entwickelt.

:desktop_computer: Das Dashboard auf einen Blick

Kernfunktionen:

  1. Dual-System Monitoring: Echtzeit-Statistiken über CPU- und RAM-Last beider Systeme. So sehe ich sofort, ob die KI-Workstation gerade unter Volllast arbeitet oder ob die Synology beim DB-Indexieren ins Schwitzen kommt.

  2. Intelligente Warteschlangen-Steuerung: Die Warteschlange wird präzise anhand der PDFs im Staging-Ordner (ai_staging) berechnet. Man sieht genau, wie viele Dokumente noch auf die KI-Verarbeitung warten, bevor sie in den Paperless-Eingang wandern.

  3. Management-Tools (Remote via SSH): Ich kann Paperless-Managementbefehle (wie sanity_checker, document_retagger oder document_exporter) direkt aus der Web-UI starten. Diese werden sicher per SSH innerhalb des Docker-Containers auf der Synology ausgeführt.

  4. Kombinierte Duplikat-Erkennung: Das System zählt sowohl „harte“ Dateiduplikate im Eingangsordner als auch inhaltliche Duplikate, die per KI-Vektor-Suche in der Datenbank identifiziert wurden.

:shield: Backup & Sicherheit

Ein kritischer Punkt war das Backup. Da die Daten verteilt liegen, reicht ein Backup des PCs nicht aus.

Zentrales Backup-Management

Das integrierte Backup-Skript erledigt nun folgendes mit einem Klick:

  • Erstellt einen PostgreSQL-Datenbank-Dump via SSH auf der Synology.

  • Sichert die Docker-Konfigurationen beider Systeme (PC & NAS).

  • Packt die KI-Vektordatenbank (ChromaDB) vom PC mit ein.

  • Speichert alles in einem zentralen, komprimierten Archiv auf der Workstation.

:hammer_and_wrench: Technische Details

  • Frontend: HTML5/CSS3 (Vanilla), JavaScript mit Echtzeit-Polling.

  • Backend: Flask (Python) mit Docker-SDK und SSH-Integration.

  • Kommunikation: Direkter CIFS/SMB3-Mount zwischen WSL2 und Synology für maximale Dateiperformance.

Das Projekt hat die Wartung meines Paperless-Systems massiv vereinfacht, da ich nicht mehr zwischen DSM-Oberfläche, Portainer und Terminal-Sessions hin- und herspringen muss.

Interesse am Setup? Ich habe das gesamte Setup (Docker-Konfigurationen, Python-Skripte für den Watchdog und Sync-Logik) modular aufgebaut. Falls Interesse besteht, kann ich die Repo-Struktur gerne auf GitHub zur Verfügung stellen, damit ihr euch das mühsame Kleben der Einzelteile spart.

Was nutzt ihr für KI-Workflows in eurem Paperless? Ich freue mich auf den Austausch!

Viele Grüße, Heiko