Wir haben eine Milliarde Dokumente. Müssen wir jetzt alle noch mal lesen?

Warum wir Extraktion, Qualität und fachliche Interpretation voneinander trennen sollten.

Stell dir eine Bank mit einer Milliarde Dokumenten vor. Kreditverträge, Kontoauszüge, Zahlungsbelege, Sicherheitenbewertungen, Compliance-Unterlagen und Korrespondenz aus einer langen IT-Geschichte.

Das Kreditteam möchte Verträge mit AI analysieren. „Wir brauchen zuerst OCR.“ Compliance startet eine Dokumentenprüfung. „Wir brauchen zuerst OCR.“ Ein RAG-Team möchte Wissen auffindbar machen. Die Antwort kennst du inzwischen.

Drei Teams, dreimal derselbe Ausgangspunkt. Und im Zweifel dreimal die Kosten.

Irgendwann müssen wir entscheiden, ob wir eine Dokumentenplattform bauen – oder einen wirklich sehr teuren PDF-Lesekreis betreiben.

Die Bank und die Milliarde sind ein fiktives Skalierungsszenario, keine gemessenen Kundendaten.

Was passiert, wenn die Teams selbst extrahieren?

Jede Lösung baut ihre eigene Pipeline: PDF laden, Text erkennen, Tabellen rekonstruieren, Fehler behandeln, Ergebnisse speichern. Die Implementierungen sind nicht zwingend identisch. Ein Team liest Tabellen besser, das andere behandelt mehrsprachige Dokumente zuverlässiger.

Beim nächsten Modellwechsel entsteht derselbe Aufwand erneut. Und wenn die Ergebnisse voneinander abweichen, lässt sich schwer beantworten, welches Team welches Extrakt verwendet hat.

Das Kernproblem ist nicht, dass Extraktion teuer ist. Es ist die enge Kopplung der Extraktion an jeden einzelnen Use Case.

Ich würde die Verarbeitung deshalb bewusst in drei unabhängige Ebenen aufteilen: Originaldokument, unveränderliche Basisextraktion und daraus abgeleitete Sichten.

Ein Dokument kann mehrere gültige Extrakte besitzen

Im Dokumentenmanagementsystem besitzt ein Dokument eine stabile ID. Das Original bleibt erhalten. Eine Parser- oder OCR-Engine erzeugt daraus ein Markdown-Artefakt:

DOC-123
├── original.pdf
├── EXT-001.md  ← Engine A, Konfiguration 1
└── EXT-002.md  ← Engine B, Konfiguration 3

Beide Extrakte bleiben unverändert. Jede Version referenziert das konkrete Quelldokument, ihre Engine, die Konfiguration, ihren Erstellungszeitpunkt und einen Hash.

Warum nicht einfach die neueste Datei überschreiben? Weil „neu“ keine Qualitätsmetrik ist. Eine neue Engine kann Fließtext verbessern und gleichzeitig Tabellen schlechter rekonstruieren. Für manche Anwendungen ist EXT-001 weiterhin die bessere Wahl.

Wir benötigen also nicht nur Versionen, sondern eine nachvollziehbare Entscheidung darüber, welches Extrakt für welchen Zweck geeignet ist.

„Erfolgreich verarbeitet“ ist noch keine Qualität

Ein Kreditvertrag enthält eine Zinstabelle. Im Original steht 1,5 %, im Markdown stehen plötzlich 15 %. Die Pipeline hat keinen Fehler geworfen. Alle Seiten sind verarbeitet. Der Status lautet success.

Und fachlich ist das Ergebnis gefährlich falsch.

Daher würde ich Qualität aus mehreren unabhängigen Kriterien zusammensetzen:

Diese Kriterien sind nicht austauschbar. Ein Vertrag kann eine vollständige Seitenabdeckung haben und dennoch einen entscheidenden Tabellenwert falsch enthalten.

Und wir sollten uns nichts vormachen: Ohne Ground Truth kennen wir die echte Textgenauigkeit normalerweise nicht. OCR-Confidence, Strukturheuristiken und die Übereinstimmung verschiedener Engines helfen beim Einschätzen. Sie sind kein unabhängiger Wahrheitsbeweis.

Unternehmensweite Quality Levels – mit klaren Grenzen

Ich würde ein versioniertes Qualitätsmodell veröffentlichen, das verschiedene Anwendungen gemeinsam verstehen:

• L0: Technisch unbrauchbares Ergebnis.
• L1: Gültiges, lesbares Artefakt.
• L2: Vereinbarte Mindestabdeckung erreicht.
• L3: Zusätzliche Struktur- und Konsistenzprüfungen erfüllt.
• L4: Ausgewählte Qualitätsaussagen anhand unabhängiger Referenzdaten verifiziert.

Das ist eine mögliche Level-Systematik, kein Industriestandard. Die konkreten Kriterien und Schwellenwerte müssen wir mit Fachbereichen anhand repräsentativer Dokumente kalibrieren.

Vor allem darf aus einem L4 nicht die Behauptung werden, dass jedes einzelne Zeichen fehlerfrei ist. Ein Verifikationsgrad sagt nur etwas darüber aus, was und wie geprüft wurde.

Eine Anwendung für Volltextsuche könnte ein anderes Mindestprofil akzeptieren als eine automatische Zinsprüfung. Deshalb bleiben neben dem Level die einzelnen Metriken abrufbar.

Die Dokumentenplattform verwaltet Referenzen, nicht riesige Textdateien

Die große Markdown-Datei muss nicht in ein operatives MongoDB-Dokument kopiert werden. Das Dokumentenmanagementsystem kann Referenzen, Versionen und Qualitätsbewertungen verwalten; die Extrakte liegen beispielsweise in GCS.

{
  "document_id": "DOC-123",
  "base_extraction": {
    "preferred_id": "EXT-002",
    "versions": [
      {
        "id": "EXT-002",
        "artifact_uri": "gs://bank-extractions/DOC-123/EXT-002.md",
        "engine_version": "parser-b/3",
        "quality": {
          "assessments": [
            {
              "standard_version": "1.0",
              "level": "L3",
              "page_coverage": 1.0
            }
          ]
        }
      }
    ]
  }
}

Das ist ein vereinfachter Contract; in der Praxis gehören Quellhash, Zeitpunkte und weitere Provenance-Angaben dazu. Bei sehr langen Historien würde ich Versionen in eine eigene Collection auslagern. Sonst wird das Metadatenobjekt selbst zum Skalierungsproblem.

Drei Änderungen. Drei unterschiedliche Konsequenzen.

Zurück zu den Teams aus unserer Bank.

Fall 1: Compliance verschärft ihre Qualitätsanforderungen. Das vorhandene Markdown wird gegen einen neu versionierten Quality Standard bewertet. Reicht es aus, muss das PDF nicht erneut gelesen werden.

Fall 2: Das RAG-Team wechselt sein Embedding-Modell. Die Chunks und Vektoren müssen gegebenenfalls neu erstellt werden. Das vorhandene Markdown kann bleiben.

Fall 3: Das Kreditteam erkennt, dass Tilgungspläne unvollständig extrahiert wurden. Jetzt hat eine neue PDF-Extraktion einen konkreten Nutzen. Aber wir schicken nicht deshalb automatisch die gesamte Dokumentenpopulation durch die Pipeline. Wir wählen die betroffenen Dokumente aus und bewerten sie erneut.

In allen drei Fällen wird dieselbe Dokumentenidentität beibehalten. Nur die abgeleitete Repräsentation ändert sich.

Und wenn es wirklich eine Milliarde Dokumente sind?

Dann brauchen wir eine Entscheidung, was wann erneut verarbeitet werden muss.

Nicht jeder Use Case benötigt den höchsten Qualitätsgrad. Nicht jede neue Parser-Version verbessert alle Dokumente. Eine Plattform sollte zuerst wiederverwendbare Extrakte anbieten, ihre Qualität sichtbar machen und kontrollierte Nachverarbeitung erlauben.

Natürlich kostet auch diese Architektur Geld: Versionen brauchen Speicher, Quality Gates brauchen Rechenleistung, und Retention sowie Zugriffsrechte bleiben wichtig. Sie reduziert also nicht jeden Aufwand. Sie verhindert aber, dass jeder neue Consumer dieselbe Grundarbeit wiederholt.

Ein sinnvoller Start

Ich würde mit einem Dokumenttyp und zwei unabhängigen Consumer-Anforderungen beginnen. Ein gemeinsamer Base-Extraction-Service erzeugt unveränderliche Markdown-Artefakte; ein kleiner Quality Contract macht ihre Eignung sichtbar. Danach prüfen wir, wie häufig bestehende Extrakte tatsächlich wiederverwendet werden.

Extrahiere nicht neu, weil eine andere Anwendung fragt. Extrahiere neu, wenn die vorhandene Grundlage ihre Anforderungen nicht erfüllt.

Wie oft wird bei euch dasselbe Originaldokument in verschiedenen Anwendungen noch einmal gelesen?

Im nächsten Beitrag: Warum diese gemeinsame Dokumentbasis nicht automatisch eine gute RAG-Suche ergibt.