Skip to content

ADR-0065: Dokument-Extraktion — pdf-oxide für Text, lokales Vision-Modell für Scans

  • Status: proposed (pdf-oxide-Textextraktion umgesetzt; Vision-Modell und LLM-Klassifikation für P14b vorgeschlagen)
  • Datum: 2026-10-08
  • Phase: Dokumente (P14a / P14b)
  • Lastenheft: DMS-01, DMS-02, DMS-04
  • Bezug: ADR-0005, ADR-0061, ADR-0063

Kontext

Die Dokumentenverwaltung (ADR-0063) braucht Text aus eingehenden Dateien: für die Volltextsuche und, ab P14b, für einen Vorschlag zu Typ, Projekt und Feldern. ADR-0005 hat OCR und Parser für Rohinput ausgeschlossen, weil die Lizenzregel für Python-Abhängigkeiten PyMuPDF (AGPL-Konflikt mit der kommerziellen Lizenz) und Tesseract-Stacks im Image verbietet; pdf-oxide wurde dort als spätere Option notiert. ADR-0061 verlangt, dass KI lokal läuft (Ollama) und der Mensch entscheidet.

Entscheidung

  1. Textebene (umgesetzt, P14a). PDFs liest pdf-oxide (MIT/Apache-2.0) seitenweise. Seiten mit weniger als 25 Zeichen gelten als Scan und werden mit needs_ocr markiert. Klartext, CSV, XML (GAEB), JSON und E-Mail werden direkt dekodiert; Bilder werden als skipped markiert. Ergebnisse stehen append-only in document_extractions.
  2. Scans und Fotos (vorgeschlagen, P14b). Ein lokales Ollama-Vision-Modell liest Seiten mit needs_ocr und Bilder. Kein Tesseract, kein PyMuPDF, kein externer OCR-Dienst.
  3. Klassifikation (vorgeschlagen, P14b). Ein lokales LLM schlägt Typ, Projekt, Bauabschnitt, Felder und Beteiligte samt Konfidenz vor (suggestion, confidence am Dokument). Unterhalb min_confidence (Standard 0,75) bleibt das Feld leer. Der Vorschlag legt nie selbst ab; „Bestätigen & ablegen“ bleibt ein Mensch (DMS-02).
  4. Austauschbarer Provider. Modellaufruf hinter demselben Provider-Protokoll wie die Assistant-Pipeline (ADR-0061). Es verlassen keine Dokumentinhalte den Server.
  5. Zustand. extraction_state am Dokument; der Beat-Sweep holt unfertige Extraktionen nach (Technik).

Begründung

pdf-oxide deckt digital erzeugte PDFs (Behördenbescheide, Pläne, Verträge) ab, ist permissiv lizenziert und braucht kein Systempaket im Image. Scans und Fotos sind im Baualltag häufig; ein lokales Vision-Modell vermeidet sowohl die gesperrten OCR-Stacks als auch eine Datenweitergabe an Dritte. Die Trennung in Text- und Vorschlagsebene hält P14a lauffähig, ohne ein Modell vorauszusetzen.

Messung (Phase 0, 2026-10-09)

Korpus: 30 synthetische Text-PDFs (eine Seite, je ein Dokument pro Katalogtyp, 29 von 31 Typen; Dateiname = Ground Truth, nicht im Prompt). Ollama 0.12.3 im Dev-Stack, nur CPU (12 Kerne, keine GPU), temperature 0, num_ctx 8192, JSON-Schema mit enum der Typcodes, Prompt mit dem vollständigen Katalog (Label + Synonyme).

Pfad Modell Stichprobe Typ Datum Aktenzeichen Zeit je Dokument
Text (pdf-oxide) qwen2.5:7b-instruct 13 von 30 (5 der Reihe nach, 8 bewusst schwierig: Schriftverkehr, Protokoll, Bedenken/Mehrkosten/Nachtrag, Fertigmeldung, Foto) 12/13 13/13 13/13 65–280 s (ohne Last ca. 65–110 s)
Vision (Seite als PNG, 110 dpi, JPEG q45, Rauschen, Unschärfe, ±2,5° Drehung) qwen2.5vl:7b 2 von 30 (VRAO, Lieferschein) 2/2 1/2 (Format 04.06.2026 statt ISO) 2/2 313–380 s
  • pdf-oxide extrahiert alle 30 Text-PDFs in 0–4 ms je Seite.
  • Der einzige Typfehler: Nachtragsangebot (NTA) als Nachtragsvereinbarung (NTV) erkannt. Beide Typen liegen im Katalog nah beieinander; der Mensch bestätigt ohnehin.
  • Das Vision-Modell lieferte das Datum einmal im deutschen Format. Die Pipeline normalisiert deshalb Daten selbst (dd.mm.yyyy und ISO) und vertraut dem Modell nicht auf das Format.
  • Das Aktenzeichen steht im Modell-Ergebnis mit Schrägstrich (32-1234/2026); Dateinamen ersetzen ihn durch -. Der Vergleich normalisiert beides.

Grenzen der Messung. Der Korpus enthält keine echten Scans oder Handyfotos; die Vision-Zahlen stammen von künstlich verschlechterten Seitenbildern und sind nur ein Hinweis. pdf-oxides eingebaute OCR (extract_text_ocr) wurde nicht gemessen (fällt bei Text-PDFs auf die Textebene zurück, ein OCR-Modell liegt nicht im Image). Stichprobe klein, keine Aussage zur Trefferquote bei verrauschten echten Dokumenten.

Folgerungen.

  1. Ohne GPU ist KI-Vorschlag nur als Hintergrundjob tragbar (1–5 Minuten je Dokument; Vision ca. 6 Minuten je Seite). Der Prüfer sieht den Vorschlag erst, wenn er fertig ist; das Formular bleibt bis dahin leer und benutzbar. Für Vision-Scans ist eine GPU praktisch Voraussetzung.
  2. Der Katalog-Prompt dominiert die Zeit (Vorlauf der Eingabe auf CPU). Ein kleineres Modell oder ein zweistufiger Aufruf (erst Kategorie, dann Typ innerhalb der Kategorie) kürzt den Prompt; vor Phase 1b mit qwen2.5:3b und dem zweistufigen Ablauf gegenmessen.
  3. Modellwahl vorläufig (Vorschlag): qwen2.5:7b-instruct für Text, qwen2.5vl:7b für Vision, DPI 110. Endgültig erst nach Messung mit echten Dokumenten und GPU.

Verworfene Alternativen

Alternative Warum verworfen
PyMuPDF Lizenzregel (AGPL-Konflikt mit kommerzieller Lizenz)
Tesseract / OCRmyPDF Lizenzregel und Systempakete im Image; schwache Ergebnisse bei Baustellenfotos
Cloud-OCR / Cloud-LLM Widerspricht lokal-only (ADR-0061); zusätzlicher Auftragsverarbeiter
Automatisch ablegen ab hoher Konfidenz Widerspricht DMS-02 (Human in the loop)
Keine Extraktion, nur Metadaten-Suche Aktenzeichen, Auflagen und Fristen stehen im Dokumenttext

Folgen

  • ADR-0005 bleibt für Rohinput gültig; die Aussage „kein OCR“ gilt für den Rohinput-Pfad weiter, Dokumente nutzen pdf-oxide (und in P14b das Vision-Modell).
  • Neue Abhängigkeit pdf-oxide in backend/pyproject.toml (Lizenzprüfung nach der Python-Abhängigkeitsrichtlinie); Health-Zeile pdf_oxide.
  • Offen für P14b: endgültige Modellwahl (Messung mit echten Scans/Fotos und GPU), Prompt-/Schema-Versionierung, Trefferquote auf einem größeren Korpus vor dem Statuswechsel auf accepted.
  • Zusätzliche Worker-Last: Vision-Aufrufe laufen auf der Queue documents (Concurrency 1).