Startseite
» Domänen
»
So automatisieren Sie die PDF-Datenextraktion mit lokalen KI-Modellen ohne Cloud-API
So automatisieren Sie die PDF-Datenextraktion mit lokalen KI-Modellen ohne Cloud-API
Der zuverlässigste lokale Workflow zur PDF-Extraktion ist in der Regel eine Pipeline und kein einzelner KI-Prompt: Stellen Sie zunächst vertrauenswürdigen Text und Layout aus dem PDF wieder her, bitten Sie dann ein lokales Modell, diesen Inhalt in ein strenges Schema abzubilden, und validieren Sie abschließend die Felder, bevor Sie sie speichern. Das direkte Senden jeder PDF-Seite an ein Vision-Modell kann funktionieren, ist aber oft langsamer, hardwareintensiver und schwerer zu prüfen als die Verwendung von nativem PDF-Text oder OCR, wenn diese ausreichen.
Diese Unterscheidung ist wichtig, wenn Ihr Ziel „keine Cloud-API“ ist. Sie können weiterhin eine lokale API auf Ihrem eigenen Rechner verwenden – zum Beispiel Ollamas HTTP-Endpunkt auf localhost –, ohne Dokumentinhalte an einen gehosteten Dienst zu senden. Ollama gibt an, dass Prompts und Antworten nicht an Ollama zurückgesendet werden, wenn Modelle lokal ausgeführt werden, und bietet einen rein lokalen Modus, der Cloud-Funktionen deaktiviert. Docling deaktiviert ebenfalls standardmäßig Remote-Dienste, obwohl Modelldateien während der Einrichtung möglicherweise noch heruntergeladen werden müssen, es sei denn, Sie laden sie für die Offline-Nutzung vorab herunter.
Der richtige Stack hängt vom PDF ab. Geborene digitale Rechnungen mit auswählbarem Text erfordern einen anderen Ansatz als gescannte Belege, komplexe Finanztabellen oder bildlastige Formulare. Dieser Leitfaden vergleicht diese Optionen und gibt ein vierstufiges Automatisierungsmuster vor, das Sie an Rechnungen, Verträge, Bestellungen, Antragsformulare, Berichte und andere wiederkehrende Dokumente anpassen können.
Schnelle Empfehlung: Wählen Sie die Pipeline nach Dokumenttyp
PDF-Typ
Praktische lokale Pipeline
Hauptvorteil
Hauptnachteil
Geborenes digitales PDF mit sauberem, auswählbarem Text
PyMuPDF → lokales Text-LLM → JSON-Validierung
Schnell und relativ hardwarearm
Die einfache Extraktion kann Lesereihenfolge oder Tabellenbeziehungen verlieren
Gescanntes PDF mit einfachen Seiten
OCRmyPDF/Tesseract → PyMuPDF → lokales Text-LLM
Wandelt Seitenbilder vor der KI-Extraktion in durchsuchbaren Text um
OCR-Fehler werden zu Modell-Eingabefehlern
Gemischtes PDF mit Text, Scans und Tabellen
Docling oder OCRmyPDF im Skip-/Redo-Modus → lokales LLM
Bessere Kontrolle über gemischte Inhalte und Dokumentstruktur
Mehr Abhängigkeiten und Verarbeitungszeit
Layoutlastige Formulare, Tabellen, Diagramme oder visuell bedeutungsvolle Seiten
Docling lokale Pipeline oder lokales Vision-Modell → strukturierte Ausgabe
Erhält mehr visuellen/Layout-Kontext
Erfordert in der Regel mehr Rechenleistung und stärkere Validierung
Es gibt keinen universellen Gewinner. Wenn Ihre Dokumente vorhersehbar sind und eingebetteten Text enthalten, kann ein Parser plus ein kleines lokales Sprachmodell ein viel größeres Vision-Workflow in Bezug auf Kosten, Geschwindigkeit und Reproduzierbarkeit übertreffen. Wenn die Position des Textes Teil der Bedeutung ist – zum Beispiel eine Tabelle mit zusammengeführten Zellen oder ein Formular, bei dem Beschriftungen und Werte räumlich gepaart sind –, wird eine layoutbewusste Verarbeitung wertvoller.
Schritt 1: Klassifizieren Sie das PDF, bevor Sie OCR oder KI wählen
Beginnen Sie damit, festzustellen, ob das Dokument bereits nutzbaren Text enthält. Geboren digital bedeutet, dass das PDF aus Software generiert wurde und normalerweise Textobjekte enthält, die ausgewählt und kopiert werden können. Ein gescanntes PDF kann nur Seitenbilder enthalten, sodass ein normaler Textparser wenig oder nichts zurückgibt.
Die offizielle Dokumentation von PyMuPDF zeigt die direkte Textextraktion mit page.get_text(). Ein minimaler lokaler Test sieht so aus:
import pymupdf
def extract_native_text(pdf_path: str) -> str:
pages = []
with pymupdf.open(pdf_path) as doc:
for page in doc:
pages.append(page.get_text())
return "\f".join(pages)
text = extract_native_text("invoice.pdf")
print(text[:1000])
Siehe die offiziellen PyMuPDF-Grundlagen. PyMuPDF warnt auch, dass einfacher PDF-Text möglicherweise nicht in natürlicher Lesereihenfolge erscheint und unerwartete Zeilenumbrüche enthalten kann. Das ist eine Einschränkung des Parsers, nicht unbedingt ein KI-Problem.
Beste Eignung: Rechnungen, Kontoauszüge, Berichte und Formulare, bei denen Text-Kopieren/Einfügen bereits funktioniert und die Felder leicht aus benachbarten Beschriftungen identifiziert werden können.
Achtung: Eine Seite kann eine winzige Textebene plus ein großes gescanntes Bild enthalten. Einfach zu prüfen, ob „irgendwelcher Text existiert“, ist daher kein perfekter Scan-Detektor. Für die Produktionsautomatisierung sollten Sie repräsentative Dokumente prüfen, anstatt sich auf einen universellen Zeichenzähl-Schwellenwert zu verlassen.
Aktion: Nehmen Sie 20–50 repräsentative PDFs und klassifizieren Sie sie in Gruppen wie geboren digital, gescannt, gemischt und layoutlastig. Ihre Pipeline sollte nach Dokumentverhalten routen, nicht nur nach Dateiendung.
KI-generierte Illustration der PDF-Eingabestufe. Es ist ein konzeptionelles Workflow-Bild, kein Screenshot einer bestimmten PDF-Anwendung oder ein Benchmark-Ergebnis.
Schritt 2: Extrahieren Sie Text lokal – oder nutzen Sie OCR nur, wenn Sie es brauchen
Option A: PyMuPDF für saubere digitale PDFs
Wenn die Textebene zuverlässig ist, ist die direkte Extraktion normalerweise der einfachste Weg. Sie vermeidet OCR-Latenz und verhindert, dass OCR-Zeichenfehler in Text eingeführt werden, der bereits korrekt kodiert war. Für lange Dokumente können Sie Seitentrennzeichen beibehalten und Seitengruppen oder logische Abschnitte verarbeiten, anstatt das gesamte Dokument auf einmal an das Modell zu übergeben.
Trade-off: Einfacher Text ist billig und schnell, aber Tabellen, mehrspaltige Seiten, Kopfzeilen, Fußzeilen und Lesereihenfolge erfordern möglicherweise zusätzliche Behandlung. Wenn diese Beziehungen für die Zielfelder wichtig sind, wechseln Sie zu einer layoutbewussten Darstellung, anstatt Prompt-Anweisungen auf schlechten Quelltext zu häufen.
Option B: OCRmyPDF plus Tesseract für gescannte Seiten
Tesseract ist eine Open-Source-OCR-Engine. Das aktuelle Benutzerhandbuch dokumentiert die 5.x-Serie und die Unterstützung für viele Sprachen über separate trainierte Datendateien. OCRmyPDF verpackt OCR um PDF-spezifische Verarbeitung, sodass gescannte Seiten eine durchsuchbare Textebene erhalten können.
Für ein gemischtes Dokument, bei dem einige Seiten bereits Text enthalten, unterstützen aktuelle OCRmyPDF-Versionen einen skip-Modus:
ocrmypdf --mode skip input.pdf searchable.pdf
Die offizielle OCRmyPDF-Erweiterungsdokumentation erklärt, dass --mode skip Seiten mit vorhandenem Text unberührt lässt und die Seiten OCR-verarbeitet, die es benötigen. Dieselbe Dokumentation beschreibt redo zum Ersetzen erkannten vorherigen OCRs und force zum Rasterisieren und OCR-Verarbeiten aller Inhalte. Verwenden Sie force mit Vorsicht, da das Rasterisieren Vektorvorteile verwerfen und interaktive Inhalte flach machen kann.
Für die Tesseract-Installation, Sprachen und das Verhalten der Befehlszeile verwenden Sie das offizielle Tesseract-Benutzerhandbuch. Die OCR-Sprache ist wichtig: Wenn Ihre Rechnungen beispielsweise Englisch und Deutsch enthalten, installieren und konfigurieren Sie die entsprechenden Sprachdaten, anstatt anzunehmen, dass das Standard-Englisch-Modell beide gleich gut verarbeitet.
Option C: Docling, wenn Struktur wichtig ist
Docling ist für die Dokumentkonvertierung mit Layout-, Tabellen-, OCR- und lokalen Vision-Sprachverarbeitungsoptionen konzipiert. Die Projektdokumentation listet erweitertes PDF-Verständnis, Tabellenstruktur, OCR und verlustfreie JSON/Markdown-artige Ausgaben auf, wobei die lokale Ausführung für sensible und luftgesperrte Workflows vorgesehen ist.
Eine grundlegende Python-Konvertierung kann so klein sein wie:
Siehe den offiziellen Docling-Schnellstart. Docling unterstützt auch lokale VLM-Pipelines und mehrere OCR-Backends. Die erweiterten Optionen erklären, dass Aufrufe von Remote-Diensten eine explizite Opt-in-Erklärung erfordern, während Modellartefakte für die Offline-Nutzung vorab geladen werden können.
Beste Eignung: Komplexe Tabellen, Überschriften, mehrspaltige Berichte, gemischte Scans oder Fälle, in denen Sie eine wiederverwendbare Dokumentdarstellung anstelle eines einfachen Text-Dumps wünschen.
Trade-off: Die Pipeline ist schwerer als ein einfacher PDF-Parser. Verwenden Sie sie, weil die zusätzliche Struktur Ihre Extraktionsgenauigkeit verbessert – nicht nur, weil sie mehr Komponenten hat.
Aktion: Wählen Sie die leichteste Extraktionsmethode, die die Informationen bewahrt, die Ihr Zielschema benötigt. Führen Sie kein OCR für sauberen eingebetteten Text durch und werfen Sie das Layout nicht weg, wenn das Layout die Bedeutung bestimmt.
KI-generierte Illustration der Wahl von OCR für Scans und direkter Extraktion für geborene digitale PDFs. Sie stellt das Entscheidungskonzept dar, nicht die Oberfläche einer echten OCR-Anwendung.
Schritt 3: Bilden Sie den wiederhergestellten Inhalt mit einem lokalen Modell auf ein strenges Schema ab
Sobald Sie vertrauenswürdigen Quellinhalt haben, nutzen Sie das lokale Modell für das, was es gut kann: semantische Abbildung. Anstatt zu fragen: „Extrahieren Sie alles aus dieser Rechnung“, definieren Sie die Felder, die Sie tatsächlich benötigen.
Beispiel:
from pydantic import BaseModel
from typing import Optional
class LineItem(BaseModel):
description: str
quantity: Optional[float]
unit_price: Optional[float]
amount: Optional[float]
class Invoice(BaseModel):
invoice_number: Optional[str]
invoice_date: Optional[str]
vendor_name: Optional[str]
currency: Optional[str]
subtotal: Optional[float]
tax: Optional[float]
total: Optional[float]
items: list[LineItem]
Die aktuelle Dokumentation zu strukturierten Ausgaben von Ollama unterstützt das Übergeben eines JSON-Schemas über das Feld format und die Validierung der Antwort mit Pydantic. Ein lokaler Aufruf kann so aussehen:
from ollama import chat
schema = Invoice.model_json_schema()
prompt = f"""
Extrahieren Sie die Rechnung in das angegebene Schema.
Regeln:
- Verwenden Sie nur Informationen, die im Quelltext vorhanden sind.
- Verwenden Sie null, wenn ein Feld nicht gefunden wird.
- Inferieren Sie keine fehlenden Rechnungsnummern, Daten, Steuern oder Summen.
- Bewahren Sie Positionsposten einzeln auf.
QUELLE:
{text}
"""
response = chat(
model="gpt-oss",
messages=[{"role": "user", "content": prompt}],
format=schema,
options={"temperature": 0},
)
invoice = Invoice.model_validate_json(response.message.content)
Dies folgt dem Muster in Ollamas offizieller Dokumentation zu strukturierten Ausgaben, die wiederverwendbare Schemata und eine niedrige Temperatur wie Null für deterministischere strukturierte Vervollständigungen empfiehlt.
Der oben genannte Modellname ist ein Beispiel aus Ollamas eigener Dokumentation zu strukturierten Ausgaben, keine Behauptung, dass es das beste Modell für jeden Extraktionsjob ist. Ein kleineres Modell kann für repetitive Rechnungen mit klaren Beschriftungen ausreichend sein; ein stärkeres Modell kann bei mehrdeutigen Verträgen oder inkonsistenten Layouts helfen, erfordert aber im Allgemeinen mehr Speicher und Verarbeitungszeit.
Textmodell oder Vision-Modell?
Verwenden Sie ein Textmodell, wenn die Parser-/OCR-Ausgabe bereits die Feldbeziehungen bewahrt, die Sie benötigen. Verwenden Sie ein visionfähiges lokales Modell, wenn die visuelle Position wesentlich ist oder die Textkonvertierung konsistent Struktur verliert. Ollamas offizielle Vision-Dokumentation unterstützt Bildeingaben für lokale Vision-Modelle, und die Funktion für strukturierte Ausgaben kann mit visionfähigen Modellen kombiniert werden.
Allerdings ändert das Rendern jeder Seite als Bild den Trade-off:
Es müssen mehr Pixel verarbeitet werden;
Seiten mit hoher Auflösung verbrauchen mehr Rechenleistung und Speicher;
Das Stapeln von Seiten wird für lange PDFs wichtig;
Visuelle Modelle können immer noch ein Feld erfinden oder eine Zahl falsch lesen;
Sie benötigen eine Möglichkeit, extrahierte Werte auf eine Seite oder Quellregion zurückzuverfolgen.
Aktion: Beginnen Sie mit Parser-/OCR-Text plus einem schema-begrenzten lokalen LLM. Eskalieren Sie nur die schwierigen Seitentypen auf ein lokales VLM, anstatt die Vision-Kosten für jede Seite zu zahlen.
KI-generierte Illustration der lokalen Modellstufe. Sie stellt keinen echten Ollama-Bildschirm dar und impliziert nicht, dass ein lokales Modell jedes Feld ohne Validierung extrahieren kann.
Schritt 4: Validieren Sie, bevor Sie JSON, CSV, Excel oder eine Datenbank schreiben
Schema-valides JSON ist nicht automatisch faktisch korrekt. Ein Modell kann gültige Felder mit falschen Werten erzeugen. Die letzte Stufe sollte daher nach Möglichkeit deterministische Prüfungen verwenden.
Für eine Rechnung sind nützliche Prüfungen:
Erforderliche Identifikationsfelder: Rechnungsnummer oder Lieferantenname müssen vorhanden sein, wenn Ihr Workflow sie benötigt.
Datumsanalyse: Parsen Sie Daten mit einer festen Richtlinie, anstatt mehrdeutigen Strings wie 03/04/26 zu vertrauen.
Arithmetik: Vergleichen Sie die Summe der Positionsbeträge mit der Dokumentenzwischensumme innerhalb einer definierten Toleranz.
Summen: Überprüfen Sie, ob Zwischensumme plus Steuern und andere Gebühren mit der Gesamtsumme konsistent ist.
Währung: Nehmen Sie nicht USD an, nur weil das Dokument auf Englisch ist.
Herkunft: Speichern Sie den Quell-Dateinamen, die Seitennummer, den Extraktionszeitstempel und optional einen Hash des ursprünglichen PDFs.
Prüfqueue: Leiten Sie fehlende, widersprüchliche oder Fälle mit geringer Konfidenz zur menschlichen Überprüfung weiter, anstatt Werte stillschweigend aufzufüllen.
Eine grundlegende Batch-Struktur kann Extraktion und Validierung trennen:
from pathlib import Path
import json
for pdf_path in Path("inbox").glob("*.pdf"):
source_text = extract_native_text(str(pdf_path))
# Wenn Text unbrauchbar ist, führen Sie hier Ihren OCR- oder Docling-Zweig aus.
record = extract_with_local_model(source_text)
errors = validate_record(record)
if errors:
save_for_review(pdf_path, record, errors)
else:
output = Path("processed") / f"{pdf_path.stem}.json"
output.write_text(
json.dumps(record, ensure_ascii=False, indent=2),
encoding="utf-8"
)
Die Hilfsfunktionen sind bewusst anwendungsspezifisch gehalten, da sich Validierungsregeln zwischen Rechnungen, Verträgen, Steuerformularen, Laborberichten und Bestellungen dramatisch unterscheiden. Ein universeller Validator würde falsches Vertrauen erzeugen.
Wenn Sie CSV oder Excel benötigen, flachen Sie nur die Felder ab, die tatsächlich in Zeilen und Spalten gehören. Für Dokumente mit wiederholten Positionsposten ist es oft sauberer, eine dokumentbezogene Tabelle und eine zweite Positionspostentabelle zu erstellen, die über eine Dokument-ID verknüpft sind, anstatt jedes Feld in eine breite Tabellenzeile zu zwingen.
Aktion: Definieren Sie Validierungsregeln, bevor Sie Tausende von Dateien verarbeiten. Testen Sie gegen einen beschrifteten Stichprobensatz und protokollieren Sie die Feldgenauigkeit, nicht nur „Dokumente erfolgreich verarbeitet“.
KI-generierte Illustration lokaler Exportziele wie Excel, CSV und JSON. Es ist ein konzeptioneller Endpunkt, kein Beweis dafür, dass jedes PDF ohne Überprüfung konvertiert werden kann.
Eine praktische vollständig lokale Architektur
Für viele kleine und mittlere Automatisierungsaufgaben ist diese Aufgabenteilung leichter zu warten als ein All-in-One-Modell:
Dieses Design ermöglicht es Ihnen, Komponenten unabhängig auszutauschen. Wenn die OCR-Qualität schwach ist, verbessern Sie die OCR-Ebene, ohne das LLM neu zu trainieren. Wenn das lokale Modell zu langsam ist, verwenden Sie ein kleineres, ohne den PDF-Parser zu ändern. Wenn die Rechnungen eines bestimmten Anbieters eine spezielle Tabellenbehandlung benötigen, leiten Sie nur diese Dateien über Docling oder einen Vision-Zweig.
Ollama vs. llama.cpp vs. Docling VLM: Welches lokale Runtime sollten Sie wählen?
Option
Verwenden Sie es, wenn
Stärke
Nachteil
Ollama
Sie möchten die einfachste lokale Modell-API und schema-begrenzte Ausgabe
Einfache localhost-API, strukturiertes JSON, Vision-Unterstützung für kompatible Modelle
Die Abstraktion bietet weniger Low-Level-Runtime-Kontrolle als eine reine Inferenz-Engine
llama.cpp
Sie möchten direkte GGUF-Kontrolle, Befehlszeilenbereitstellung oder einen leichten lokalen Server
Lokaler CLI/Server und Grammatik-/JSON-Schema-begrenzte Generierung
Mehr Modell-/Runtime-Details liegen in Ihrer Verantwortung
Docling VLM
Ihre Hauptherausforderung ist die Dokumentlayout-Konvertierung, nicht die allgemeine Chat-artige Extraktion
Dokumentfokussierte lokale VLM-Pipeline mit Markdown/HTML/DocTags-artigen Ausgaben
Am besten als Dokumentkonvertierungskomponente gedacht, nicht als Ersatz für jeden Geschäftsregel-Extraktionsschritt
Das offizielle llama.cpp-Repository dokumentiert einen lokalen llama-server und grammatikbegrenzte Generierung; aktueller Servercode akzeptiert auch JSON-Schema-Beschränkungen. Doclings Vision-Modelle-Dokumentation listet lokale VLM-Optionen für die Dokumentkonvertierung auf.
Wählen Sie eine Runtime nicht nur basierend auf einer Modell-Bestenliste. Für die PDF-Extraktion sind die praktischen Maße die Feldgenauigkeit, der Durchsatz pro Dokument, die Speichernutzung auf Ihrem Rechner, die Fehlerrate bei Ihren Layouts, die Startkomplexität und wie leicht Sie falsche Ergebnisse inspizieren können.
Wie Sie die Pipeline wirklich lokal halten
„Keine Cloud-API“ sollte eine Bereitstellungseigenschaft sein, die Sie überprüfen können, nicht nur ein Marketing-Label.
Ollama
Ollamas offizielle FAQ besagt, dass lokale Prompts und Antworten nicht an Ollama zurückgesendet werden. Es dokumentiert auch eine Cloud-Deaktivierungseinstellung:
OLLAMA_NO_CLOUD=1
oder die entsprechende disable_ollama_cloud-Servereinstellung. Ollamas lokale API läuft auf http://localhost:11434 und erfordert laut seiner Authentifizierungsdokumentation keine Authentifizierung für den lokalen Zugriff.
Denken Sie daran, dass ein Dienst, der an localhost gebunden ist, sich von einem unterscheidet, der Ihrem LAN ausgesetzt ist. Wenn Sie seine Bindungsadresse ändern oder hinter einen anderen Server stellen, sind Sie für die Zugriffskontrolle verantwortlich.
Docling
Docling hält die Nutzung von Remote-Diensten standardmäßig deaktiviert. Die Dokumentation unterscheidet auch zwischen Verarbeitungsschutz und Modellbeschaffung: Modelle können bei der ersten Verwendung abgerufen werden, es sei denn, Sie laden sie vorab herunter. Für ein luftgesperrtes System verwenden Sie docling-tools models download auf einem verbundenen Staging-Rechner oder stellen Sie genehmigte Modellartefakte anderweitig vorab bereit, und weisen Sie dann die Offline-Umgebung auf dieses lokale Artefaktverzeichnis hin.
Aktion: Blockieren Sie vor der Verarbeitung sensibler Dokumente den ausgehenden Netzwerkzugriff auf Betriebssystem- oder Netzwerkebene und führen Sie einen Test durch, während Sie die Verbindungen überwachen. Anwendungseinstellungen sind nützlich, aber Netzwerksteuerungen geben Ihnen eine unabhängige Verifizierungsebene.
Was lokale KI nicht löst
Das lokale Ausführen verbessert die Datenkontrolloptionen, macht die Extraktion aber nicht automatisch korrekt, konform oder sicher. Lokale Dateien können weiterhin über Debug-Logs, temporäre Verzeichnisse, Backups, freigegebene Ordner, zu großzügige Dienste oder kopierte Exporte durchsickern. Ein lokales Modell kann auch Werte genau wie ein gehostetes Modell halluzinieren.
Verwenden Sie das Modell nicht als einzigen Verifizierer für hochwirksame Felder wie Bankkontonummern, Zahlungsanweisungen, Vertragsdaten, medizinische Werte oder regulatorische Kennungen. Für diese vergleichen Sie mit dem Quelltext, wenden Sie deterministische Validierung an und verlangen Sie eine menschliche Überprüfung, wenn die Konfidenz unzureichend ist.
Wie Sie testen, bevor Sie einen ganzen Ordner automatisieren
Erstellen Sie einen kleinen beschrifteten Evaluierungssatz, der die Fälle enthält, die Sie tatsächlich erhalten:
sauberes digitales PDF;
Scan mit niedriger Auflösung;
gedrehte oder verzerrte Seite;
mehrseitige Rechnung;
Tabelle über mehrere Seiten;
fehlende optionale Felder;
unterschiedliche Datums- und Zahlenformate;
mindestens ein absichtlich schwieriges Dokument.
Vergleichen Sie für jedes Zielfeld den extrahierten Wert mit dem Ground Truth. Messen Sie die exakte Übereinstimmung für Kennungen, numerische Toleranz für Beträge und die Zeilengenauigkeit für Positionsposten. Protokollieren Sie auch die Verarbeitungszeit und den Prozentsatz der Dokumente, die zur manuellen Überprüfung gesendet wurden.
Wenn ein einfacherer PyMuPDF-plus-LLM-Pfad Ihre erforderliche Genauigkeit erreicht, behalten Sie ihn bei. Wenn Scans der Hauptfehler sind, verbessern Sie OCR. Wenn Tabellenbeziehungen das Problem sind, testen Sie Docling. Wenn visuell positionierte Felder weiterhin schwierig sind, leiten Sie diese Teilmenge über ein lokales Vision-Modell. Diese gestufte Eskalation gibt Ihnen in der Regel bessere Kontrolle über Geschwindigkeit und Hardware-Nutzung als die Anwendung des schwersten Modells auf jede Seite.
Fazit
Ein gutes lokales PDF-Extraktionssystem trennt Dokumentlesen von semantischer Extraktion. Verwenden Sie PyMuPDF, wenn das PDF bereits guten Text enthält; OCRmyPDF/Tesseract, wenn die Seite gescannt ist; Docling, wenn Struktur und Tabellen wichtig sind; und ein lokales Ollama- oder llama.cpp-Modell, wenn Sie eine flexible Abbildung in ein Geschäftsschema benötigen. Verwenden Sie lokale Vision nur dort, wo das visuelle Layout Informationen hinzufügt, die die Textpipeline nicht zuverlässig bewahren kann.
Die letzte Anforderung ist die Validierung. JSON-Schema kann die Form einer Modellantwort begrenzen, aber es kann nicht beweisen, dass der Betrag, das Datum, der Name oder die Kontonummer mit der Quelle übereinstimmt. Wenn Sie die Pipeline so gestalten, dass unsichere Dokumente sichtbar und überprüfbar sind, können Sie einen großen Teil der PDF-Datenextraktion automatisieren, ohne die Dokumente an eine Cloud-API zu übergeben – und ohne so zu tun, als würde lokale KI die Notwendigkeit einer Qualitätskontrolle beseitigen.