Ein neuer Standard für konsistentes Dokument-Parsing in KI-Agenten
Das Document Parsing Protocol 0.1 definiert 140 Regeln zur Konvertierung von Dokumenten in strukturierten Text und zielt darauf ab, die Mehrdeutigkeit für KI-Agenten zu reduzieren.
Automatisch aus dem englischen Original übersetzt.
Am 28. Oktober 2026 hat das Team hinter ParseBench den Arbeitsentwurf 0.1 des Document Parsing Protocol (DPP) veröffentlicht. Diese neue Spezifikation soll das Problem der Inkonsistenz lösen, wie KI-Agenten geparste Dokumente interpretieren, indem sie einen standardisierten Regelwerkssatz für die Konvertierung von Seiten in strukturierten Text bereitstellt.
Was passiert ist
Das Parsen von Dokumenten war lange Zeit eine Quelle der Reibung für Entwickler, die KI-Agenten erstellen. Wenn ein Parser eine PDF-Datei oder ein Bild in Text konvertiert, muss er zahlreiche Entscheidungen bezüglich Layout und Struktur treffen. Unterschiedliche Parser treffen oft unterschiedliche Entscheidungen, was zu Ausgaben führt, die alle korrekten Wörter enthalten, aber unterschiedliche Bedeutungen vermitteln. Da KI-Agenten vollständig auf dieser geparsten Eingabe basieren, werden strukturelle Fehler in der Parsing-Phase direkt in die Schlussfolgerungen und die endgültige Antwort des Agenten übernommen.
Um dies anzugehen, haben die Autoren DPP als gemeinsame Definition dafür eingeführt, wie eine korrekt geparste Seite aussehen sollte. Das Protokoll entstand aus den internen Richtlinien, die von Annotatoren verwendet wurden, um Daten für ParseBench zu kennzeichnen, einem Benchmark für das Dokument-Parsing. Entwurf 0.1 umfasst 140 spezifische Regeln, die Text, Tabellen, Formulare, Diagramme und Grafiken abdecken. Jede Regel wird von Beispiel-Seiten und dem erwarteten Output begleitet, was Entwicklern und Bewertenden eine klare Referenz bietet.
Die Veröffentlichung lädt die Community ein, das Protokoll zu testen und Feedback zu geben. Die Autoren haben den Entwurf online verfügbar gemacht und Tools bereitgestellt, um ihn gegen große Sprachmodelle wie Claude und ChatGPT zu testen. Sie ermutigen Nutzer dazu, Issues oder Pull Requests auf GitHub zu öffnen, wenn sie auf Dokumente stoßen, bei denen die Regeln versagen oder Konflikte verursachen, um den Standard durch offene Zusammenarbeit zu verfeinern.
Wie es funktioniert
Der Kernmechanismus von DPP besteht darin, mehrdeutige Markdown-Konvertierungen dort durch präzise strukturelle Darstellungen zu ersetzen, wo dies notwendig ist. Beispielsweise können Standard-Markdown-Tabellen keine Kopfzeilen darstellen, die sich über mehrere Spalten erstrecken. In einem Verkaufsbericht, in dem Jahre über mehrere Quartale hinweg dargestellt werden, könnte ein Markdown-Konverter die Kopfzeilen flach machen oder ganz entfernen, was dazu führt, dass ein KI-Agent Daten falsch zuordnet. DPP schreibt die Verwendung von HTML-Tabellen mit colspan-Attributen vor, um die exakte visuelle Hierarchie des Originaldokuments beizubehalten. Dies stellt sicher, dass ein Wert wie "4,1 %" explizit mit "Q2" unter der Kopfzeile "2024" verknüpft bleibt.
Über Tabellen hinaus definiert das Protokoll strenge Handhabungsregeln für andere komplexe Elemente. Leere Formularfelder werden als [blank] markiert, um sie von vergessenen Feldern zu unterscheiden, und Checkboxen werden als [x] oder [ ] dargestellt. Diagramme werden in Datentabellen mit den exakt gedruckten Werten konvertiert, während Skizzen nach Möglichkeit in Mermaid-Code übersetzt oder textuell beschrieben werden, wobei alle Beschriftungen erhalten bleiben. Das Protokoll legt außerdem fest, dass versteckter Text in PDFs ausgeschlossen werden sollte, während unlesbarer sichtbarer Text als [illegible] markiert wird. Optionale Positionsdaten ermöglichen es, jedes Element an seinen Ort auf der Quellseite zurückzuverfolgen.
Wichtige Details
- DPP 0.1 enthält 140 Regeln, die Text, Tabellen, Formulare, Diagramme und Skizzen abdecken.
- Das Protokoll verlangt HTML-Tabellen für komplexe Kopfzeilen, um das Überspannen von Spalten beizubehalten.
- Leere Formularfelder werden explizit als
[blank]markiert, um Mehrdeutigkeiten bei Datenverlust zu verhindern. - Diagramme werden in strukturierte Tabellen mit exakten numerischen Werten aus der Quelle konvertiert.
- Skizzen werden als Mermaid-Code oder beschreibender Text ausgegeben, wobei alle Beschriftungen erhalten bleiben.
- Der Entwurf steht für Community-Feedback über GitHub-Issues und Pull Requests offen.
Warum das wichtig ist
Für Ingenieure, die Retrieval-Augmented Generation (RAG)-Systeme oder Werkzeuge zur Dokumentenanalyse entwickeln, ist Konsistenz entscheidend. Ohne einen Standard können zwei Teams denselben Parser-Output unterschiedlich bewerten, was es schwierig macht, die Leistung zu vergleichen oder Fehler zu debuggen. DPP bietet eine gemeinsame Sprache zur Bewertung der Parser-Qualität. Indem genau definiert wird, wie strukturelle Elemente dargestellt werden sollten, reduziert es die kognitive Belastung für KI-Agenten und ermöglicht ihnen, sich auf das Schlussfolgern statt auf das Entziffern mehrdeutiger Formatierungen zu konzentrieren.
Diese Standardisierung wirkt sich auch darauf aus, wie Benchmarks erstellt werden. Zuvor mussten Benchmark-Ersteller private Entscheidungen darüber treffen, was als "korrekte" Analyse gilt. DPP macht diese Entscheidungen explizit und überprüfbar. Diese Transparenz hilft dem gesamten Ökosystem, sich auf zuverlässigere Verarbeitungspipelines für Dokumente zu bewegen. Da KI-Agenten komplexere Aufgaben übernehmen, die Finanzberichte, Rechtsverträge und technische Handbücher betreffen, wird die Treue des anfänglichen Parsing-Schritts zum primären Bestimmungsfaktor für die Systemgenauigkeit.
Was Sie tun können
- Besuchen Sie parseprotocol.com, um die Quellseiten zusammen mit ihren erwarteten DPP-Ausgaben anzusehen.
- Testen Sie das Protokoll, indem Sie ein Seitenbild über die bereitgestellten Skills bei Claude oder ChatGPT hochladen.
- Überprüfen Sie, ob bestimmte Werte, wie Zahlen in Klammern, im Output exakt beibehalten werden.
- Sehen Sie sich die Walkthrough-Beispiele an, um die Begründung hinter bestimmten Parsing-Entscheidungen zu verstehen.
- Identifizieren Sie Edge Cases in Ihren eigenen Dokumentensätzen, die möglicherweise nicht von den aktuellen 140 Regeln abgedeckt werden.
- Tragen Sie zum Standard bei, indem Sie GitHub-Issues mit Beispielen für Regelkonflikte oder -versagen öffnen.



