Automatische Zuweisung von Korrespondent, Tag, Dokumentenart funktioniert nicht (mehr)

paperless-ngx
1

Hallo Forum,

Ich habe vorgestern paperless-ngx v2.19.6 auf meiner Synology mit Docker installiert. Hat alles prima funktioniert. 2 Test-PDFs manuell über das Web-UI hochgeladen …ok. Prima, Text gut erkannt.

Dann: ein paar Tags, Korrespondenten und Dokumententypen angelegt…. alle mit der Regel “enthält alle Wörter”.

Die 2 Dokumente, die bisher importiert waren, habe ich dann mit “Aktion - Erneut verarbeiten” nochmal verarbeiten lassen - und dann wurden auch die Tags, Korrespondenten und Dokumententypen angezeigt.

(Und ich meine, bei einem dritten Dokument hat er bei nachträglich angezeigtem Tag bei Anzeige des Dokuments sogar ein “Vorschlag: xxx” unter dem Tag-Feld angezeigt - ohne daß man nochmal neu verarbeiten muß)

So, alles gut so. Ich lege dann mehr Klassifikations-Stammdaten an (19 Tags, 19 Korrespondenten, 4 Dokumententypen) …. importiere noch 5 weitere Test-PDFs … alles prima. Alles zugewiesen.

Dann lösche dann die Testdokumente aus paperless (inkl. Papierkorb) … und lade manuell 600 PDFs übers UI hoch.

Während dem Hochladen ist mir schon aufgefallen: hm… da werden gar keine Tags, Korrespondenten, … zugewiesen… hm …. vielleicht macht er das erst am Ende, wenn die Queue alle Dokumente importiert / interpretiert hat?

Nein, hat er nicht gemacht. Keinerlei Zuweisungen nachdem alles importiert war.

Mal runter- und wieder hochgefahren … danach mal ein Dokument, bei dem in “Inhalt” ganze klar die 2 oder 3 Worte aus der Korrepsondenten-Definition vorhanden waren, mit “Aktion - Erneut verarbeiten” behandelt…. nichts. Keine Zuweisung.

In vielen anderen Dokumenten ist übrigens unter “Inhalt” klar erkennbar, daß die geforderten Worte erkannt wurden.

Und: bei diesem 600 PDF-Dateien waren auch die von den ersten Gehversuchen dabei - die er am Anfang ohne Probleme getagt hat!

Dann in Portainer auf die Konsole des PaperlessNGX-Containers … und als root ausgeführt:
document_retagger -c

Läuft ca. 1-2 Minuten …. und der Fortschrittsbalken zählt meine Dokumentenanzahl durch. Keine sonstigen Protokollausgaben. Danach: Nichts. Dokumente nach wie vor ohne Korrespondent. Das gleiche mit Option -T für “Tags” probiert … ebenfalls keine Zuweisungen.

Dann ein weiterer Test mit zusätzlicher Angabe der ‘–use-first” option…. keine Lösung des Problems.

Dann das hier:

document_retagger -c -f

”-f” ist die “Overwrite” Option.

Aha, jetzt tut sich was…. im Konsolenfenster sehe ich dieses Mal nicht nur einen Fortschrittsbalken, der meine 600 Dokumente zählt …. sondern ich bekomme alle meine 600 Dokumente aufgelistet mit mit der Meldung: ”Assigning correspondent None to ”

Ein vorher manuell im paperless-UI gesetzter Korrespondent war danach auch wieder gelöscht (im paperless log sehe ich “Updating index for document 467” - das ist genau dieses eine Dokument) - aber es wurden keine aus meinen Definitionen zugewiesen.

Es steht jetzt also fest:

  • OCR erkennt den Text sauber
  • In Inhalt stehen genau die Begriffe, die ich in der Tag-/Korrespondent-Definition mit Komma (ohne Leerstellen) eingegeben habe (inkl. gesetzter Option, Groß-/Kleinschreibung zu ignorieren)
  • Das System kann durchaus Dokumente updaten - daran liegt es nicht.

Was anscheinend nicht geht: Den Text aus der Tag-/Korrespondent-Definition im “Inhalt” des Dokuments”finden” und das Tag setzen.

Beispiel für eine Korrespondenten-Definion : "Alle Wörter: landshut,84003”. Im erkannten Inhalt des Dokuments stehen sowohl “Landshut” als auch die PLZ 84003.

Ich bin ratlos…. hat jemand eine Idee, was ich falsch mache oder was “defekt” sein könnte?

Viele Grüße,
Michael

2

Ich kann dir nur empfehlen die Tags und alles andere auf “Auto” zu stellen da sonst nicht trainiert wird.

Die Volltextsuche liefert manchmal seltsames da vielleicht nicht alles in der selben Zeile steht oder von einem Absatz gertennt usw.

Alles andere machst du vielleicht am besten über nen Workflow.

Gruß ausm Nachbarlandkreis :wink:

3

Hi,

ich wollte eigentlich nicht mit Training & KI arbeiten - sondern mit fest definierten Begriffen. Einfach weil ich wollte, daß es möglich “sicher” ist. Eine KI kann sich vielleicht mal irren, aber wenn im Dokument “Rentenbescheid” “und “Deutsche” und “Rentenversicheung” steht, dann passt das zu 100 %.

Aber davon abgesehen: warum hat es mit den ersten 5 Testdokumenten funktioniert…. und jetzt mit den 600 (bei denen genau diese 5 Testdokumente auch dabei sind) nicht mehr …… obwohl nach den ersten Tests keinerlei Änderungen an der Installation / Parametern oder an der Klassifikations-Definition vorgenommen wurden?

Für mich als Informatiker ist das …. ein nicht wünschenswertes Verhalten :wink:

Ich hätte dann gerne ein Erklärung - warum “verschluckt” sich die Volltextsuche bei 5 gespeicherten Dokumenten nicht, wenn ein sechstes importiert wird …. aber wenn ich 600 importiere (und das Sequentiell - nicht parallel) funktioniert es auf einmal nicht mehr? An Effekten wie “zu wenig Speicher", “Datenbank voll”, “Systemüberlast” sollte es da doch nicht liegen…

Gruß,

Michael
(leider nicht im Nachbarkreis wohnhaft, sondern weiter weg - vom Hauptzollamt Landshut war nur eines der Testdokumente… :wink: )

4

Nachtrag:

Im Log sieht man in den erfolgreichen Versuchen der ersten Tage solche Meldungen:

[2025-11-16 18:52:34,870] [DEBUG] [paperless.matching] Tag Commerzbank matched on document 2025-11-12 20251114_084210 because it contains this word: Commerzbank

Bei denn 600 Dokumenten keinerlei solche Meldungen…

5

Nachtrag 2:

Die Suche in den Dokumenten im paperless UI funktioniert - gebe ich da „landshut 84003“ ein, findet er genau das eine Deokument … der Volltext samt Index scheint also ok.

Nachtrag 3:

Hier noch das Log eines „Erneut verarbeiten“ Vorgangs:

[2025-11-17 23:05:01,833] [INFO] [paperless.tasks] No automatic matching items, not training

[2025-11-17 23:24:30,993] [INFO] [paperless.tasks] No automatic matching items, not training

[2025-11-17 23:25:21,732] [DEBUG] [paperless.classifier] Document classification model does not exist (yet), not performing automatic matching.

[2025-11-17 23:25:21,814] [INFO] [_granian.asgi.io] ASGI transport error: SendError { .. }

[2025-11-17 23:25:21,815] [INFO] [_granian.asgi.io] ASGI transport error: SendError { .. }

[2025-11-17 23:25:30,906] [INFO] [paperless.parsing.tesseract] pdftotext exited 0

[2025-11-17 23:25:32,952] [DEBUG] [paperless.parsing.tesseract] Calling OCRmyPDF with args: {‚input_file‘: PosixPath(‚/usr/src/paperless/media/documents/originals/2025/none/none/Hauptzollamt LH.pdf‘), ‚output_file‘: PosixPath(‚/tmp/paperless/paperless-_9s5xg3q/archive.pdf‘), ‚use_threads‘: True, ‚jobs‘: 4, ‚language‘: ‚deu+eng‘, ‚output_type‘: ‚pdfa‘, ‚progress_bar‘: False, ‚color_conversion_strategy‘: ‚RGB‘, ‚skip_text‘: True, ‚clean‘: True, ‚deskew‘: True, ‚rotate_pages‘: True, ‚rotate_pages_threshold‘: 6.0, ‚sidecar‘: PosixPath(‚/tmp/paperless/paperless-_9s5xg3q/sidecar.txt‘)}

[2025-11-17 23:25:39,249] [INFO] [ocrmypdf._pipelines.ocr] Start processing 2 pages concurrently

[2025-11-17 23:25:45,833] [INFO] [ocrmypdf._pipeline] page is facing ⇧, confidence 2.70 - no change

[2025-11-17 23:25:48,461] [INFO] [ocrmypdf._pipeline] page is facing ⇧, confidence 13.04 - rotation appears correct

[2025-11-17 23:26:30,183] [INFO] [ocrmypdf._pipelines.ocr] Postprocessing…

[2025-11-17 23:26:41,271] [INFO] [ocrmypdf._pipeline] Image optimization ratio: 1.50 savings: 33.5%

[2025-11-17 23:26:41,272] [INFO] [ocrmypdf._pipeline] Total file size ratio: 1.69 savings: 40.9%

[2025-11-17 23:26:41,342] [INFO] [ocrmypdf._pipelines._common] Output file is a PDF/A-2b (as expected)

[2025-11-17 23:26:43,419] [DEBUG] [paperless.parsing.tesseract] Using text from sidecar file

[2025-11-17 23:26:43,772] [DEBUG] [paperless.parsing] Execute: convert -density 300 -scale 500x5000> -alpha remove -strip -auto-orient -define pdf:use-cropbox=true /tmp/paperless/paperless-_9s5xg3q/archive.pdf[0] /tmp/paperless/paperless-_9s5xg3q/convert.webp

[2025-11-17 23:26:48,488] [INFO] [paperless.parsing] convert exited 0

[2025-11-17 23:26:49,901] [INFO] [paperless.tasks] Updating index for document 467 (9ba4e3a393c226685b5abb6b23f0abb5)

[2025-11-17 23:26:50,933] [DEBUG] [paperless.index] Index updated for document 467.

[2025-11-17 23:26:51,096] [DEBUG] [paperless.parsing.tesseract] Deleting directory /tmp/paperless/paperless-_9s5xg3q

6

Es nur ein lernender Algorithmus der wie ein Kind lernen muss das Kontonummer 12345678 nach dem xten mal auch tatsächlich das Haushaltskonto ist.
Guck dir einfach mal die OCR Daten im Bearbeitungs-Modus an, Bei mir gab es manchmal Absätze usw, wieso das nicht funktioniert.

Es kann auch sein das du mit Reg-Ex arbeiten musst, mir war das zu dumm da es für mich auch nicht funktioniert hat.

Guck dir die OCR Daten mal an, vielleicht liegt da der Hase begraben.

Ich habe alle Tags, Korrespondenten auf Auto bis auf ein zwei ausnahmen und habe mir z.B. für die Problemfälle Rechnungen, Kontoauszüge, Kreditkartenabrechnung und die Kontentrennung zwischen mir und dem Vater/Eltern über die Workflows realisiert.

Seitdem funktioniert es

7

Wie gesagt: die OCR funktioniert.

Ich kann in dem eingelesenen Dokument im Bereich Inhalt ganz klar und hintereinander ohne Absätze meine Suchbegriffe sehen:

Hauptzollamt Landshut, Postfach 15 95, 84003 Landshut

8B 42C1 DECO 11 9001 1E32
DV 07.25 0,95 Deutsche Post

Es wurde sogar die Frankierungszone (obwohl kleiner gedruckt) absolut richtig erkannt.

Eine Volltextsuche nach einem festen Begriff MUSS funktionieren - das ist die einfachste Suchmethode. Die war jahrelang da und hat funktioniert, bevor die KI Einzug hielt. Wenn ein einfaches Suchen in einem ASCII-Text nach “Landshut” und “84003”, die in einem ASCII-Text direkt hintereinander in einer Zeile stehen, nicht funktioniert - dann stimmt da was nicht.

Daß das Ergebnis des Einscannens oder das Erkennen von Buchstaben/Zahlen in der eingescannten Grafik im PDF (=OCR) nicht immer die gleichen Ergebnisse liefert, ist verständlich - aber eine Volltextsuche in einem ASCII-Text, in dem eindeutig die Suchbegriffe stehen (ohne daß sie mitten im Wort durch Absätze oder was anderes getrennt sind), sollte immer die gleichen Resultate liefern. Das klappt in Word, das klappt in Notepad, das klappt in vi.

Leider kann ich den Prozess des Tag Matchings nicht debuggen - vielleicht würde man da was erkennen können.

Und wie gesagt: es hat ja schon funktioniert. Bei mir letzte Woche und bei all den anderen, die paperless vor Einführung der KI genutzt haben. Wenn an deinem Auto die Fahrertür nicht mehr aufgeht, ist die Lösung ja auch nicht, fortan immer durch die Beifahrertür einzusteigen … :wink:

8

Hallo!

Das Komma stört mich. Die Suchbegriffe müssen durch Leerzeichen getrennt sein.

Gruß

Andreas

9

Bei der Suche in Dokumenten über die oberste Zeile im Web Interface: ja, da muß ein Leerzeichen zwischen die Suchbegriffe

Bei der Definition von mehreren Suchbegriffen für die automatische Zuweisung (ohne KI!) von Tags/Korrespondent/etc.: nein - siehe hier:

Und wie gesagt: es hat genau so wie beschrieben (Suchbegriff mit Komma) bereits schon so funktioniert!

Die Definition der Tags / Korrespondenten etc. wurden zwischen dem (erfolgreichen, inkl. automatischer Zuweisung ohne KI) Test mit wenigen Dokumenten und dem großen Import der 600 PDFs nicht verändert.

10

Was meinst du seit Einzug der KI ?

Die “KI” gibt es seit mehr als ein paar Jahren.

Vielleicht ist die Version buggy ?

Schon mal ne ältere Version versucht ?

Wenn’s mit der 2.8xx geht könntest du maximal auf GitHub nen Bug reporten.

Mit dem ASCII geb ich dir recht.

Bei meinen Dokumenten lags rein am Aufbau.

Aber nach langem Training hats funktioniert und wo nicht kam n Workflow.

Teils aufgrund des Dateinamen aber bei z.b. Vodafone bekommt man die Rechnung teilweise nur noch als kryptischen Dateinamen Angeboten.

Bei der Volltextsuche bekommst du aber auch Probleme wenn sich die Daten z.b. auf den Kontoauszügen befinden.

Dann musst du nicht auf der Beifahrerseite aussteigen sondern erst das Fahrerfenstern runter machen und von aussen öffnen :wink:

11

Mit “KI” meine ich: Es gab vermutlich einen Zeitpunkt, an dem paperless, die Variante “Auto” (selbstlernend) bei der Zuordnung von Tags etc. noch nicht konnte. Vorher gab es vermutlich nur die Variante "mit der Suche nach Wörtern oder mit regulären Ausdrücken. Und in dieser Zeit muss ja diese Wortsuche auch funktioniert haben…

Buggy … ja, kann sein. Aber wie gesagt: mit genau der gleichen Version hat es direkt nach der Installation von paperless prima funktioniert…

Vielleicht sicher ich mal heute Abend die aktuellen Container, installiere nochmal neu und mache nochmal einen Test … aber: wenn so etwas nicht gleich in der ersten Woche passiert, sondern nach X Monaten (wo man schon viele Dokumente im System hat) … dann will man ja auch den Fehler finden und beheben - und nicht neu installieren und nochmal alles neu einlesen…

12

Nachdem ich paperless komplett neu installiert habe, hat es im ersten Test wieder nicht funktioniert.

Dann tauschte ich das Komma in den Suchbegriffen testweise mal durch ein Leerzeichen aus - und siehe da: es funktioniert!

Ich habe dann die vorher gemachte Sicherung wieder zurück gespielt … alle Kommas in den Tags etc. entfernt und “document_retagger” laufen lassen. Danach war alles so wie es sein sollte: die Dokumente in denen die OCR die Suchworte erkannte, waren mit den dazugehörigen Attributen versehen.

Daß es vor ein paar Tagen im ersten Test mit einem Komma funktioniert hat, ist noch seltsam … ber evtl. liegt es daran, daß in manchen Dokumenten so etwas wie “Huber,Karl” steht und ich “Huber,Karl” als Suchworte eingetragen hatte. Auch hatte ich jetzt ein Dokument gesehen, in dem “Karl Huber, geboren am…” steht - evtl. war das auch ein Grund für einen Match.

Der Rat / die Lösung in dem von mir verlinkten Beitrag “Tags mit mehreren Dokumenteninhalten” scheint dann auch falsch gewesen zu sein….