Manche PDFs sind keine Textdokumente. Sie sehen nur so aus. In Wirklichkeit sind sie gestaltete Wissensseiten: Tabellen, Diagramme, Produktbilder, technische Zeichnungen, Legenden, Fußnoten, Screenshots und erklärende Textblöcke. Wer solche Dokumente nur mit pdf2text oder einfachen PDF-to-Markdown-Werkzeugen verarbeitet, bekommt oft Text. Aber nicht unbedingt Wissen. Für KI, Suche und Vector Stores ist das zu wenig. Bei komplexen technischen PDFs ist es häufig besser, die Seiten als Bilder zu erfassen, mit einem Vision-Modell auszuwerten und daraus strukturierte JSON- oder Markdown-Elemente zu erzeugen.

Komplexe PDFs enthalten Bedeutung nicht nur im Text, sondern im Layout. Wer nur Zeichen extrahiert, verliert oft den Zusammenhang. Wer Seiten visuell strukturiert erfasst, kann daraus nutzbares Unternehmenswissen machen.

Das Problem: PDFs sehen geordnet aus

Für Menschen ist eine technische PDF-Seite oft schnell verständlich. Man sieht eine Überschrift, darunter ein Produktbild, daneben eine Tabelle, unten eine Maßzeichnung und rechts einen Hinweis. Die räumliche Anordnung erklärt, was zusammengehört.

Für eine einfache Textextraktion ist das schwierig.

Sie liest Zeichen aus. Aber sie versteht nicht zuverlässig, dass eine Fußnote nur zu einer bestimmten Tabellenspalte gehört. Sie erkennt nicht sicher, dass ein Diagramm den Absatz daneben erklärt. Sie weiß nicht, ob eine Zahl zur Variante A oder zur Variante B gehört. Und sie ignoriert oft Bilder, Zeichnungen oder Kurven vollständig.

Das Ergebnis ist dann kein leeres Dokument. Das wäre leicht zu erkennen. Das Ergebnis ist schlimmer: Es ist ein halb brauchbarer Textbrei.

Ein Vector Store, der mit solchem Material gefüllt wird, sieht beschäftigt aus. Er hat Chunks, Tokens und Treffer. Nur fehlt oft der fachliche Zusammenhang.

Warum der PNG-Weg praktisch stark ist

Der Weg über gerenderte Seiten ändert die Aufgabe.

Das PDF wird nicht nur als Textquelle behandelt, sondern als visuelle Informationseinheit. Jede Seite wird in ein Bild umgewandelt. Ein Vision-Modell sieht dann Text, Tabellen, Bilder, Diagramme, Legenden, Pfeile, Abstände und Überschriften gemeinsam.

Das Ziel ist nicht, aus dem Bild wieder Fließtext zu machen. Das Ziel ist eine strukturierte Erfassung:

• Textblöcke
• Tabellen als Markdown
• Diagramme als Beschreibung und Datentabelle
• Bilder und Zeichnungen als fachliche Beschreibung
• Warnhinweise
• Fußnoten
• Quellenangaben
• Seiten- und Bereichsbezug

Damit entsteht nicht nur extrahierter Text. Es entstehen adressierbare Wissenselemente.

Ein einfacher Textexport erzeugt vielleicht:

Technische Daten Lichtstrom Leistung CRI IP20 Montage Abstand Wand 24W 3100lm >90

Eine strukturierte Vision-Erfassung kann daraus machen:

{
  "document": "produktdatenblatt.pdf",
  "page": 7,
  "element_type": "table",
  "title": "Technische Daten",
  "content_markdown": "| Leistung | Lichtstrom | CRI | Schutzart |\n|---:|---:|---:|---|\n| 24 W | 3100 lm | >90 | IP20 |",
  "notes": [
    "Die Werte beziehen sich auf die auf Seite 7 dargestellte Produktvariante."
  ],
  "source_region": "Seite 7, Tabelle rechts unten"
}

Das ist ein anderer Qualitätslevel. Die Information ist lesbar, prüfbar und später gezielt verwendbar.

Die Seite davor und danach mitgeben

Ein wichtiger Praxispunkt: Eine einzelne Seite reicht oft nicht.

Viele technische Dokumente erklären Inhalte über Seitengrenzen hinweg. Eine Produktvariante wird auf Seite 14 eingeführt, die Tabelle folgt auf Seite 15. Ein Codebeispiel beginnt unten auf einer Seite und endet oben auf der nächsten. Eine Grafik wird erst im Folgeabsatz erklärt. Ein Warnhinweis bezieht sich auf den vorherigen Abschnitt.

Deshalb ist es in der Praxis oft sinnvoll, dem Vision-Modell drei Seiten zu geben:

• vorherige Seite als Kontext
• aktuelle Seite als Extraktionsziel
• nächste Seite als Kontext

Die aktuelle Seite wird strukturiert erfasst. Die Nachbarseiten helfen nur beim Verstehen.

Das ist besonders wichtig bei Entwicklerdokumentation. Programmcode bricht gerne an Seitenkanten. Wenn nur die aktuelle Seite betrachtet wird, fehlt der Anfang oder das Ende. Dann wird aus einem Codebeispiel ein Rätsel mit Semikolons.

Wichtig ist die saubere Trennung: Das Ergebnis muss klar markieren, welche Inhalte tatsächlich von der aktuellen Seite stammen und welche nur zur Einordnung verwendet wurden. Sonst wandert Wissen auf die falsche Seite.

Was in das JSON gehört

Ein gutes JSON-Schema ist entscheidend. Ohne Schema produziert das Modell schöne Beschreibungen, aber keine verlässliche Datenbasis.

Ein sinnvolles Element kann so aussehen:

{
  "document_id": "manual_2026_01",
  "page": 42,
  "context_pages": [41, 43],
  "section_title": "Montageabstände",
  "elements": [
    {
      "type": "text_block",
      "title": "Hinweis zur Wandmontage",
      "content_markdown": "Bei Wandmontage ist ein Mindestabstand von 50 cm einzuhalten.",
      "source_region": "Seite 42, oberer Textblock"
    },
    {
      "type": "figure",
      "title": "Montageskizze",
      "description": "Die Skizze zeigt den Abstand zwischen Leuchte und Wand sowie die empfohlene Ausrichtung.",
      "source_region": "Seite 42, mittlere Abbildung"
    },
    {
      "type": "table",
      "title": "Empfohlene Abstände",
      "content_markdown": "| Anwendung | Mindestabstand |\n|---|---:|\n| Wandmontage | 50 cm |\n| Deckenmontage | 30 cm |",
      "source_region": "Seite 42, Tabelle unten"
    }
  ],
  "warnings": [
    "Die Werte sollten gegen das Originaldokument geprüft werden, wenn sie für Planung oder Bestellung verwendet werden."
  ]
}

Das Ziel ist nicht maximale Eleganz. Das Ziel ist Nachvollziehbarkeit.

Jedes Element braucht einen Typ, einen Inhalt, eine Quelle und im Idealfall eine Position. Sonst kann man später nicht prüfen, ob die KI richtig erfasst hat.

Tabellen, Diagramme und Bilder getrennt behandeln

Bei visuellen PDFs ist es wichtig, nicht alles in einen Textblock zu werfen.

Tabellen sollten als Tabellen gespeichert werden. Markdown reicht oft aus. Bei wichtigen Daten kann zusätzlich eine strukturierte JSON-Tabelle sinnvoll sein.

Diagramme sollten vorsichtig verarbeitet werden. Ein Vision-Modell kann Achsen, Trends und Beschriftungen erkennen. Es sollte aber keine präzisen Messwerte erfinden. Wenn Werte nicht klar ablesbar sind, muss das Ergebnis das sagen.

Bilder und technische Zeichnungen sollten beschrieben werden. Nicht poetisch, sondern fachlich: Was ist zu sehen? Welche Bauteile, Maße, Anschlüsse, Abstände oder Varianten werden dargestellt? Gibt es Beschriftungen? Gibt es Bezug zu einer Tabelle?

Der Satz „Das Bild zeigt ein Produkt“ ist fast wertlos.
Der Satz „Die Zeichnung zeigt die Einbausituation mit Mindestabstand zur Wand und markiert zwei Befestigungspunkte“ ist nutzbar.

Vom PDF zum Vector Store

Der Vector Store sollte nicht mit rohen Seitenbeschreibungen gefüllt werden. Besser sind fachliche Chunks.

Ein Chunk kann eine Tabelle sein. Oder eine Abbildung mit Erklärung. Oder ein Abschnitt mit Warnhinweis. Oder ein zusammenhängendes Codebeispiel.

Wichtig ist, dass jeder Chunk genug Kontext enthält:

## Montageabstände – Seite 42

Die Tabelle beschreibt empfohlene Mindestabstände für die Montage.

| Anwendung | Mindestabstand |
|---|---:|
| Wandmontage | 50 cm |
| Deckenmontage | 30 cm |

Die zugehörige Skizze zeigt die Ausrichtung der Leuchte und zwei Befestigungspunkte.

Quelle: produktdatenblatt.pdf, Seite 42

So kann die KI später sinnvoll antworten. Sie findet nicht nur Begriffe. Sie findet eine kleine, prüfbare Wissenseinheit.

Praxisbeispiel: Herstellerdokumentation

Eine Herstellerdokumentation enthält Produktvarianten, technische Tabellen, Maßzeichnungen und Montagehinweise.

Mit einfacher Textextraktion landen Begriffe wie „Leistung“, „Lichtstrom“, „Montage“, „Abstand“ und „Variante“ irgendwo im Text. Die Werte sind vorhanden, aber nicht zuverlässig verbunden.

Mit visueller Strukturerfassung sieht der Ablauf anders aus:

Die Seite wird gerendert. Das Vision-Modell erkennt die Produktvariante, liest die technische Tabelle, beschreibt die Maßzeichnung, übernimmt die Fußnote und speichert alles als getrennte Elemente. Danach entstehen Markdown-Chunks mit Quellenbezug.

Später fragt jemand: „Welche Mindestabstände gelten für diese Variante?“

Die KI kann dann nicht nur einen Wert finden. Sie kann sagen, aus welcher Tabelle, auf welcher Seite und für welche Variante der Wert stammt.

Das ist der Unterschied zwischen Suche und Wissen.

Fallstricke

Der PNG-/Vision-Weg ist stark, aber nicht magisch.

Er kostet mehr Rechenzeit. Er braucht ein gutes Schema. Er braucht Prüfregeln. Er braucht saubere Prompts. Und er braucht Stichproben, besonders bei technischen Werten.

Lange Tabellen können falsch gelesen werden. Kleine Fußnoten können übersehen werden. Diagrammwerte können zu genau wirken, obwohl sie nur grob geschätzt wurden. Mehrseitige Zusammenhänge können falsch zugeordnet werden.

Deshalb sollten Ergebnisse Warnfelder enthalten. Zum Beispiel:

• „Tabelle unsicher erkannt“
• „Diagramm qualitativ beschrieben, keine exakten Werte extrahiert“
• „Fußnote möglicherweise relevant“
• „Codeblock läuft auf Folgeseite weiter“
• „Zuordnung zur Produktvariante prüfen“

Das wirkt vorsichtig. Genau das ist der Punkt.

Ein System für Unternehmenswissen darf lieber sagen „prüfen“ als falsch sicher klingen.

Wann dieser Weg nicht nötig ist

Nicht jedes PDF braucht diese Pipeline.

Ein sauberer Vertrag, ein Word-basiertes Handbuch oder eine einfache Textdokumentation kann oft direkt extrahiert werden. Dort wäre der PNG-Weg ein Umweg.

Aber sobald Layout, Tabellen, Bilder, Diagramme oder technische Zeichnungen die Bedeutung tragen, wird reine Textextraktion schwach. Dann ist die visuelle Erfassung nicht Luxus, sondern Qualitätssicherung.

Fazit

Visuelle PDFs brauchen eine andere Erfassung als reine Textdokumente.

Wer komplexe technische PDFs nur mit pdf2text verarbeitet, bekommt häufig Zeichen ohne Zusammenhang. Für Volltextsuche mag das reichen. Für KI-nutzbares Unternehmenswissen reicht es oft nicht.

Der bessere Ansatz ist eine strukturierte Pipeline: PDF-Seiten rendern, Nachbarseiten als Kontext mitgeben, Vision-Modell analysieren lassen, Tabellen als Markdown speichern, Bilder und Diagramme fachlich beschreiben, Quellenbezug sichern und erst dann sinnvolle Chunks in den Vector Store schreiben.

Das Ziel ist nicht, PDFs schneller zu entleeren.

Das Ziel ist, aus gestalteten Seiten verlässliche Wissenselemente zu machen.