Ich habe paperless-ai getestet

paperless-ngx
1

Ich habe es endlich mal geschafft und die letzten Tage paperless-ai getestet. Zusammen mit oolama könnte ich wirklich brauchbare Resultate erzielen. Es wurden neue Dokumententypen erstellt die wirklich Sinn machen. Auch würde die Erkennung des Inhaltes verbessert sowie ein vernünftiger Betreff gewählt.

Ich habe für ~1300 Dokumente einen halben Tag gebraucht, aber auch nur weil ich ausschließlich 100 Dokumente auf einmal verarbeiten ließ. Und das alle 30 Minuten.

Grüße

2

Kannst du bitte noch ein paar Worte zu deinem Setup verlieren. Läuft das Ganze ausschließlich auf einem NAS oder wie hast du Oolama eingebunden?

3

Das ganze läuft auf einem Hetzer rootServer, dort wurden Kubernetes Node VMs installiert und dann wurde das Oolama und Paperless Setup als Container im Kubernetes Cluster ausgerollt.

1 „Gefällt mir“
4

Welches llm hast du denn verwendet? Ich habe auf meinem Proxmox auch einen LXC mit Ollama und bin noch am schauen was man damit so alles machen kann…

5

Ich probiere da immer noch rum. Habe zu erst kleine Modelle getestet, Mistral zum Beispiel. Da war das Ergebnis OK, aber nicht gut genug für meinen Anwendungsfall.

Zurzeit teste ich etwas größere Modelle, sieht man auch gleich an der Installationsgröße.

Gerade teste ich llama3.2

6

Kannst du Mal drinnen promt Sharen?

7

???

Was genau meinst Du?

8

Wie laut dein paperless-ai promt weicher für den Kontext für die Verarbeitung der Dokumente benutzt wird:

Settings-promt description

9

Wenn du deinen prompt schreibst wie deine letzten beiden Beiträge wird dir AI wenig helfen können.

2 „Gefällt mir“
10 
`You are a personalized document analyzer. Your task is to analyze documents and extract relevant information.

Analyze the document content and extract the following information into a structured JSON object:

1. title: Create a concise, meaningful title for the document
2. correspondent: Identify the sender/institution but do not include addresses
3. tags: Select up to 4 relevant thematic tags
4. document_date: Extract the document date (format: YYYY-MM-DD)
5. document_type: Determine a precise type that classifies the document (e.g. Invoice, Contract, Employer, Information and so on)
6. language: Determine the document language (e.g. "de" or "en")
      
Important rules for the analysis:

For tags:
1. The content is likely in German
2. FIRST check the existing tags before suggesting new ones
3. Tags are basically created by understanding the text and extracting that into a short single word that explains its intend the best (either a direct match or an indirect one in German or English
4. Scan the content and come up with a document-type that matches its description the best
5. Scan the title and content with the given document-type in mind and find the matching tags from both
6. Compare them against the list of available tags, if you find similiar tags choose the ones from the available tags first.
7. Absolutely make sure that you never return more then 4 tags in total! Remove more tags by least logical order first.
8. Respond with the final, clean and filtered selected tags as a comma-separated list without any reasoning given.
9. The output language is the one used in the document! IMPORTANT!
/no_think

For the title:
1. The content is likely in german
2. The content was partly OCR-ed so it might contain errors. If the amount of garbled text is too high, try to identify the next logical intent behind it and use that as the basis for the title.
3. In the title, double-check grammatical and spelling errors and fix them especially taking German into consideration.
4. Ensure the title does not contain any illogical letters, spacings, or separators; correct these issues. 
5. The title should be logically derived from the content itself.
6. The title should not exceed 128 characters.
7. Ensure the title is in the Language of the document and never contains foreign (e.g., Chinese) characters.
8. The title should never be the exact content itself.
9. If the content is short, apply common sense to find a shorter but meaningful title.
10. The title should have at least 4-6 words if possible and make sense; it could describe the document type or specify year and month, etc. (but not after {{.Today}})
11. Apply a sanity check multiple times to ensure the title fits all conditions from 1 to 10.
12. Provide only the final title itself in your response.
13. The output language is the one used in the document! IMPORTANT!
/no_think

For the correspondent:
1. The content language is German.
2. Correspondents are likely found in address fields or titles/headers at the start of the document, for example besides the address and are likely 2-6 words long and should never contain line-breaks.
3. They are a natural or un-natural Person, like a GmbH, Ltd. or so forth. Match companies (non-natural) first.
4. If the OCR-ed content is scrambled, attempt to make sentences sensible by replacing words, but keep the first 256 characters intact. Provide an original and a possible description version.
5. Search both versions and come up with a document-type that makes the most sense.
6. Search both versions for common company names (e.g., GmbH, AG, Ltd.) or person names as potential correspondents and list them.
7. Check if the Document is a operating instruction, if yes, assign the Correspondent "_Bedienungsanleitungen" and go to the end of this List.
8. Match found correnspondents against existing ones (only >70% probability), replace them but don't change the order.
9. Blacklisted correspondents are: Michael Müller, Iris Zollinger
10. Remove any matches of the blacklisted correspondents from your list.
11. Ensure the correspondent is a natural or non-natural person/company; if not, use placeholder-text thats 256 words long.
12. Do not randomly select an existing correspondent, but clean the matched correspondent for duplicate-whitespaces and line-breaks. If a line-break was found remove everything after the first match.
13. If no matches: simply give a placeholder-text thats 256 words long.
14. Final response: just the identified correspondent or placeholder, no kind of reasoning given.
/no_think

For the document date:
1. The content is likely in German
2. Scan the content for the date
3. The date can be in any international format and might need to be converted.
4. The answer/output format should be strictly converted to: YYYY-MM-DD.
5. If you find just a year, use that and fill the month and day with 01-01.
6. If you find a year and month, use that and fill the day with 01.
7. If you find a year, month, and day, then use that.
8. If you find a different format than YYYY-MM-DD, convert it without telling me.
9. If you find no date, or the date cannot be converted against YYYY-MM-DD just give me todays date back.
10. Final response: just the identified date, no kind of reasoning given.
/no_think

For the language:
- Determine the document language
- Use language codes like "de" for German or "en" for English
- If the language is not clear, use "und" as a placeholder
/no_think
2 „Gefällt mir“
11

Hallo zusammen,

ich möchte heute mein aktuelles Setup zur Dokumenten-Digitalisierung teilen. Mein Ziel war es, die herkömmliche OCR-Qualität (Tesseract) massiv zu verbessern, ohne meine Dokumente in die Cloud (OpenAI & Co.) schicken zu müssen.
:laptop: Das Hardware-Setup
Die Basis bildet ein Linux-Subsystem (WSL) unter Windows 11 mit ordentlich Dampf für lokale KI-Modelle:
CPU: Intel i7 Ultra (sorgt für schnelles PDF-Rendering und Reparatur via Ghostscript)
RAM: 32 GB (wichtig für die Pufferung großer PDF-Bilder)
GPU: NVIDIA RTX 5060 Ti (Das Herzstück: Hier laufen die Vision-LLMs über Ollama)

Speicher: Anbindung an ein NAS über /volume1/

:rocket: Der Workflow: KI trifft auf klassisches OCR
Statt mich auf die Standard-OCR-Engine von Paperless-ngx zu verlassen, habe ich ein Python-Skript vorgeschaltet, das als „Veredelungs-Filter“ fungiert.

Was das Skript macht:
PDF-Reparatur: Nutzt Ghostscript und qpdf, um defekte Struktur-Header zu fixen oder Verschlüsselungen (Bearbeitungsschutz) zu entfernen.
KI-Vision-Analyse: Die ersten Seiten werden gerendert und an Ollama (Modell: deepseek-ocr:3b) gesendet. Die KI „liest“ das Bild und korrigiert Rechtschreibfehler sowie semantische OCR-Patzer in Echtzeit lokal auf der RTX 5060 Ti.
Hybrid-Injection: Der korrigierte KI-Text wird mittels ocrmypdf als unsichtbare, durchsuchbare Ebene wieder in das Original-Layout des PDFs eingebettet.
Archivierung: Das Original wird in einen „Fertig“-Ordner verschoben, das optimierte PDF landet im Consumer-Ordner für das Archiv.
:warning: Warum ich mich gegen Paperless-GPT / Paperless-AI in der Standardform entschieden habe
Bei meinen Tests bin ich auf zwei massive Probleme gestoßen, die viele Nutzer von Paperless-Erweiterungen kennen dürften:

  1. Das VRAM-Dilemma (Timeout & Speicher-Crash)
    Tools wie Paperless-GPT versuchen oft, die „großen“ Vision-Modelle (wie Llama 3.2 11B) direkt auf die Dokumente loszulassen. Auf einer Consumer-Karte wie meiner RTX 5060 Ti führt das fast zwangsläufig zum Super-GAU:
    Der Flaschenhals: Das Modell belegt bereits 8-9 GB VRAM. Wenn man dann ein hochauflösendes PDF-Bild (300-400 DPI) zur Analyse hineinlädt, läuft der Speicher über.
    Die Folge: Der Ollama-Server antwortet nicht mehr, Python wirft einen „Server disconnected“ Fehler und das gesamte Linux-System fängt an zu „swappen“ (einzufrieren).
    Meine Lösung: Ich erzwinge im Skript einen keep_alive=0 nach jeder Seite und nutze das spezialisierte deepseek-ocr:3b. Das ist klein genug, um neben dem PDF-Bild noch genügend Puffer im VRAM zu haben, wodurch Timeouts und Abstürze der Vergangenheit angehören.
  2. Das „Dirty OCR“-Problem bei Paperless-AI
    Viele KI-Tools für Paperless arbeiten rein textbasiert. Das heißt, sie nehmen das (oft fehlerhafte) Tesseract-OCR-Ergebnis und versuchen, daraus per KI Metadaten zu extrahieren.
    Das Problem: Wenn das Basis-OCR schlecht ist (z. B. „R€chnung“ statt „Rechnung“), halluziniert die KI bei der Datenextraktion oder findet Termine und Beträge gar nicht erst. Das Dokument selbst bleibt im Archiv zudem „kaputt“.
    Mein Ansatz: Mein Workflow setzt eine Stufe früher an. Ich korrigiere nicht nur die Metadaten, sondern ersetze die fehlerhafte Textebene im PDF selbst durch das KI-Ergebnis.
    Anstatt Tesseract-Fehler zu „reparieren“, wird das PDF-Bild direkt von der KI „gelesen“.
    Der korrigierte Text wird per ocrmypdf im Sandwich-Verfahren neu eingebettet.
    Ergebnis: Paperless-ngx bekommt ein technisch perfektes PDF, bei dem die Suche (STRG+F) und das automatische Tagging sofort funktionieren, weil das Basis-Material bereits veredelt wurde.

:chart_increasing: Meine Erfahrungen
Erkennungsrate: Ein Quantensprung. Besonders bei schlechten Scans oder komplexen deutschen Begriffen erkennt die KI Wörter im Kontext, an denen Tesseract scheitert.
Performance: Auf der RTX 5060 Ti läuft das 3b-Modell extrem flüssig. Durch das Entladen des Modells nach jeder Seite (keep_alive=0) bleibt das System auch bei großen Batches stabil.
Datenschutz: Das für mich wichtigste Argument. 100% der Verarbeitung findet im eigenen „Wohnzimmer“ statt.
:hammer_and_wrench: Tipp für Nachahmer
Wenn ihr eine 8GB oder 12GB Karte nutzt, nehmt kleinere Vision-Modelle wie deepseek-ocr:3b oder qwen2.5-vl. Die großen 11B-Modelle sprengen oft den VRAM (eigene Erfahrung), wenn man gleichzeitig hochauflösende PDF-Seiten rendert.

Beste Grüße,
Heiko