Unstructured-Review: Dokumente für RAG parsen

Unstructured ist die Dokument-Parsing-Schicht, mit der die meisten Retrieval-Pipelines beginnen: eine Apache-2.0-Python-Bibliothek, die PDFs, Word-Dateien, HTML, Bilder und Tabellen in typisierte Elemente verwandelt, Titel, Tabellen, Listen und Fließtext, dazu eine gehostete Plattform, die Konnektoren, Änderungserkennung und die Strategien ergänzt, die die Bibliothek nicht mitliefert. Die Bibliothek ist für fast jeden der richtige Einstieg; die Plattform lohnt sich nur dann zu bezahlen, wenn Tabellen oder gescannte Archive darüber entscheiden, ob die Pipeline überhaupt funktioniert.

Die Schicht steht vorn im Stack, vor Chunking, Embedding und Retrieval, und konkurriert mit LlamaParse, Docling, Reducto, Azure Document Intelligence und den Parsing-Endpunkten der großen Cloud-Anbieter. Ihr Vorteil ist nicht, dass sie jeden Benchmark gewinnt, die eigenen veröffentlichten Zahlen sagen für das Open-Source-Bauhaus das Gegenteil, sondern dass der Kern lokal unter einer freien Lizenz läuft: Diese Schicht schreibt weder eine Vektordatenbank, noch einen Chunker noch einen Hosting-Ort vor.

Was es ist

Installation mit pip install "unstructured[all-docs]", dann partition() auf eine Datei aufrufen und man erhält eine Liste von Element-Objekten mit Typ, Text und Metadaten wie Seitenzahl und Bounding-Box. Das Argument strategy wählt die Pipeline: auto, fast, hi_res und ocr_only in der Bibliothek, vlm kommt von der Plattform und schickt Seiten durch ein Vision-Modell. Darum herum liegt eine Kette, partition, chunk, enrich, embed und load, die die Plattform als Job ausführt und die Bibliothek als normale Funktionen.

• Lizenz und Eigentümer: Apache-2.0 für die Bibliothek; die Plattform ist ein kommerzielles Produkt von Unstructured mit Gratis-Tarif, Pay-as-you-go und individuellem Tarif.
• Abdeckung: die Preisliste nennt über 45 unterstützte Dateitypen und über 40 Konnektoren, verteilt auf mehr als 20 Quellen und mehr als 20 Ziele.
• Ausgabe: typisierte Elemente wie Title, NarrativeText, Table, ListItem und Image, mit Seitenzahlen, Koordinaten und Element-Metadaten statt einer Textwand.
• Strategien: auto, fast, hi_res und ocr_only lokal, dazu vlm und die Anreicherungsschritte auf der Plattform.
• Chunking: nach Titel, nach Seite, nach Zeichenzahl und nach Ähnlichkeit, kontextuelles Chunking gibt es als Plattform-Funktion.
• Benchmarks: Unstructured veröffentlicht Ergebnisse über 1.000+ Unternehmensseiten gegen Reducto, LlamaParse, Docling, Snowflake, Databricks und NVIDIA.
• Telemetrie: die Bibliothek meldet anonyme Nutzungsdaten, solange DO_NOT_TRACK oder SCARF_NO_ANALYTICS nicht gesetzt ist.

Wie es funktioniert

Ein Lauf liest die Datei, rendert die Seiten, wenn die Strategie Pixel braucht, und klassifiziert dann Bereiche in Elemente. fast nimmt den eingebetteten Text und beschriftet ihn; hi_res läuft Layout-Erkennung und OCR über das Seitenbild, deshalb langsamer, deshalb mit installiertem Modell-Stack, und deshalb die Strategie, die noch Tabellen liefert, die sich lohnen; ocr_only ist die Rückfallebene, wenn eine Seite überhaupt keinen Textlayer hat. Danach fasst das Chunking Elemente unter einem Zeichenbudget zusammen und versucht dabei, eine Überschrift nicht von ihrem Absatz zu trennen.

Das Ergebnis steht und fällt mit der Elementgrenze. Eine Tabelle, die als HTML mit intakter Kopfzeile herauskommt, wird zu einem nützlichen Knoten; dieselbe Tabelle als Fließtext gelesen wird zu mehreren Chunks, von denen jeder die Hälfte einer Zahl enthält. Das ist das ganze Argument für diese Schicht, und zugleich der ganze Grund, das Parser-Ergebnis zu lesen, bevor man das Embedding-Modell wechselt.

Erste Schritte

Das Quickstart der Bibliothek ist ein einziger Funktionsaufruf. Das Snippet unten parst ein PDF mit der High-Resolution-Strategie, behält die Tabellenstruktur, chunkt nach Titel und schreibt das Ergebnis als JSON.

from unstructured.partition.auto import partition
from unstructured.chunking.title import chunk_by_title
from unstructured.staging.base import elements_to_json

# strategy: auto, fast, hi_res or ocr_only; hi_res is the one that keeps table structure
elements = partition(
    filename="report.pdf",
    strategy="hi_res",
    infer_table_structure=True,
)
chunks = chunk_by_title(elements, max_characters=1_200, combine_under=300)

elements_to_json(chunks, filename="report.elements.json")
print(len(elements), "elements,", len(chunks), "chunks")

Für alles jenseits eines lokalen Experiments ist die Plattform der gepflegte Weg: derselbe Partition-Schritt hinter einer API oder einem geplanten Job, Konnektoren zu S3, SharePoint, Google Drive und weiteren, Änderungserkennung, damit nur neue oder geänderte Dateien verarbeitet werden, sowie die Strategie vlm. Die Bibliothek bleibt der Ort, an dem der eigentliche Parsing-Code lebt, und die Dokumentation ist darum herum geschrieben.

Performance und Kosten

Die Plattform rechnet Seiten ab: 10.000 gratis zum Start, danach 0,015 Dollar pro Seite, ein gescanntes Archive mit 400 Seiten kostet also sechs Dollar Parsing, bevor jemand eine Frage gestellt hat. Die Bibliothek rechnet in CPU und Wandzeit ab: fast ist nahezu I/O-gebunden, hi_res führt pro Seite ein Layout-Modell und OCR aus, und vlm verlagert die Rechnung von Rechenzeit auf Modell-Tokens.

Die Zahlen stammen aus dem eigenen Benchmark von Unstructured über 1.000+ Unternehmensseiten, gescannte Rechnungen, verschachtelte Tabellen und Handschrift, und ein Anbieter-Vergleich ist Marketing, deshalb ist das brauchbare Signal die Lücke innerhalb eines einzigen Produkts: 0,426 gegen 0,820 Tabellenzellen-Inhalt zwischen dem Open-Source-Bauhaus und der besten Plattform-Pipeline, und 0,715 gegen 0,880 bei der bereinigten Textgenauigkeit. Element Alignment, ob ein Bereich als Überschrift, Tabelle oder Absatz beschriftet wurde, ist der Wert, bei dem alle Werkzeuge dieser Tabelle zwischen 0,53 und 0,61 zusammenliegen, und das ist die ehrliche Schwierigkeit dieser Schicht.

• Einmal parsen und das Element-JSON behalten: dasselbe Korpus beim Chunking-Experiment neu zu partitionieren, ist der häufigste Weg, auf dem diese Schicht Geld verbrennt.
• Die Strategie pro Dokumenttyp wählen und nicht pro Korpus: fast für digitalen Text, hi_res für Scans und alles mit Tabellen.
• Seiten zählen und nicht Dateien, denn ein Preis pro Seite macht aus einer 400-Seiten-PDF den Kostenfaktor, nicht die Zahl der Dokumente.

Nichts davon ist speziell für diesen Anbieter, jeder Parser tauscht Recall gegen Rechenzeit. Speziell ist allein, dass die Zahlen überhaupt veröffentlicht werden, in einer Tabelle mit Namen der Wettbewerber, und das ist mehr, als der Rest der Branche offenlegt.

Preise

Zwei Produkte, ein Name. Die Bibliothek ist Apache-2.0 und gratis: installieren, auf der eigenen Maschine laufen lassen, kein Konto und keine Seitenzahl. Die Plattform ist dasselbe Parsing, verpackt in verwaltete Jobs, Konnektoren und Compliance, abgerechnet pro Seite.

• Bibliothek: Apache-2.0, Installation von PyPI, unbegrenzte Seiten, eigene Hardware.
• Gratis: 10.000 Seiten zum Start, keine Karte nötig, alle Funktionen enthalten.
• Pay-as-you-go: 0,015 Dollar pro Seite nach den ersten 10.000 Seiten, alle Funktionen enthalten.
• Business: individueller Preis für eine dedizierte Instanz, VPC oder Bare-Metal, Mehrbenutzerkonten, rollenbasierte Zugriffskontrolle und die Compliance-Nachweise des Anbieters.

Wo es scheuert

Mit den Schwächen beginnen. Das Open-Source-Bauhaus ist der schwächere Parser, und die eigene Tabelle des Anbieters sagt das: 0,426 Tabellenzellen-Inhalt gegen 0,820 bei der besten Plattform-Pipeline, 0,119 erfundene Tokens gegen 0,051. Der Preis geht pro Seite, was geburtsschicke PDFs belohnt und Scans bestraft, und eine Seite ist eine schlechte Einheit, wenn die eine einen Absatz enthält und die nächste eine Tabelle mit 400 Zellen. Die Funktionen, weshalb sich die Plattform mieten lässt, VLM-Partitionierung, inkrementelle Änderungserkennung, über 40 gepflegte Konnektoren und die Compliance-Geschichte, sind genau das, was die Lizenz nicht enthält. Und das Ergebnis braucht weiterhin Stichproben: Leserichtung und Tabellenstruktur sind die beiden Felder, die ohne Fehler still scheitern.

Die eigentliche Frage ist, wer die Qualität bezahlt. Wenn das Korpus digitaler Text ist und Ausgabe reicht, kostet die Bibliothek mit strategy="fast" nichts pro Seite und ist für die Aufgabe die richtige Größe. Wenn Tabellen, Scans oder regulierte Daten darüber entscheiden, ob die Pipeline funktioniert, ist die Plattform oder ein Spezial-Parser der Kauf, und der einzige Test, der zählt, ist einhundert Seiten der eigenen Dokumente, bewertet an genau den Feldern, die man wirklich liest.

Fazit

Unstructured ist der sicherste Standard am Anfang einer Retrieval-Pipeline, weil er langweilig, lokal und messbar ist: eine Funktion, die typisierte Elemente zurückgibt, ein Benchmark, über den man streiten kann, und eine bezahlte Stufe, in die man wechseln kann, ohne die Ingestion umzuschreiben. Tatsächlich entschieden wird, wie viel Parsing-Qualität das Produkt braucht, und die eigenen Zahlen des Anbieters sagen, dass das gratis Bauhaus nicht das bezahlte ist.

1. Bibliothek nutzen, wenn bereits eine Pipeline existiert und typisierte Elemente statt Rohtext braucht; sie ist Apache-2.0, läuft lokal und lässt sich austauschen, ohne den Rest des Stacks anzufassen.
2. Plattform nutzen, wenn Seiten aus S3, SharePoint oder Confluence kommen und Konnektoren, Änderungserkennung und ein Audit-Trail gebraucht werden.
3. Nicht als Parser of Record für Finanztabellen akzeptieren, ohne die eigenen Dokumente zu bewerten; die Lücke zwischen Strategien in einem Produkt ist größer als die zwischen Anbietern.
4. Nicht wählen, wo ein schwerer lokaler Abhängigkeitsbaum unzulässig ist, denn unstructured[all-docs] zieht den OCR- und Layout-Stack mit, während Docling oder eine gehostete API viel leichter sind.
5. Von Anfang an in Seiten budgetieren; ein Preis pro Seite ist leicht modelliert und mit gescannten Archiven leicht überschritten.

Dokument-Parsing als gemessenen Schritt behandeln und nicht als Rohrleitung: die Strategie an einer Stichprobe der eigenen Seiten wählen, das Element-JSON behalten und den Parser erst wechseln, wenn sich die Tabellenzahlen bewegen.

Quellen

1. Unstructured-Dokumentation: Pipeline-Überblick
2. Unstructured-Dokumentation: Transform-Quickstart
3. Unstructured-Preise: freie Seiten, Preis pro Seite und Tarife
4. Unstructured-Benchmarks: 1.000+ Unternehmensseiten gegen andere Parser
5. Unstructured-Bibliothek auf GitHub
6. Unstructured Partition-Endpoint-Container