# Design-Entscheidung: PDF-Extraktion **Datum:** 2026-06-14 **Kontext:** Sparfuchs SpaFu02 – Prospekt-Verarbeitung auf LXC 106 ## Gewählt: PyMuPDF (`fitz`) als primäres Erkennungssystem (Priority 1) **Benchmark-Quelle:** https://github.com/py-pdf/benchmarks | Library | Geschwindigkeit | Textqualität | |---|---|---| | PyMuPDF | 0.1s/PDF | 96% | | pdfplumber | 9.5s/PDF | 75% | ### Eigener Messwert (LXC 106, 40 MB newsletter.pdf, 27 Seiten) | Library | Ergebnis | |---|---| | pdfplumber | 21s/Seite, ~1 GB RAM → LXC überfordert, Prozess abgebrochen | | PyMuPDF | ~14s gesamt (alle 27 Seiten), stabiler RAM-Verbrauch | ## ErkennungsSystem-Prioritäten | Priorität | System | Beschreibung | |---|---|---| | 1 | `pymupdf` | Schnell, speicherarm, 96% Qualität — Standard | | 2 | `pdfplumber` | Tabellenerkennung, aber langsam — Fallback | | 3 | `claude_api` | Vision für Bild-PDFs ohne Text-Layer | | 4 | `mistral_ocr` | KI-basierte Dokumentenextraktion | | 5 | `google_dai` | Google Cloud Document AI | | 6 | `azure_di` | Azure AI Document Intelligence | | 7 | `nutrient_ocr` | Nutrient OCR (ehem. PSPDFKit) | | 8 | `docupipe` | Cloud-Dokumentenverarbeitung | ## Hinweise - PyMuPDF hat ab v1.23 `page.find_tables()` — wird in `process_pdf()` mit try/except für ältere Versionen abgesichert - Benchmark testet native PDFs, nicht gescannte Dokumente mit OCR - Bei reinen Bild-PDFs (kein Text-Layer) → `claude_api` als nächste Stufe