Analysieren Sie den Aktenordner, nicht nur die PDFs: Die relationalen Tabellen, die RAG auf einer Akte benötigt

Hintergrund

In der technischen Praxis der Unternehmensdokumentenintelligenz wird Retrieval-Augmented Generation häufig auf eine einzige Pipeline reduziert: PDFs in Abschnitte zerschneiden, Vektorsuche ausführen und die Fragmente einem großen Sprachmodell übergeben. Dieser Ablauf bewährt sich bei Blogartikeln, technischen Handbüchern und internen Wikis, versagt jedoch, sobald Dokumente um diskrete Fälle organisiert sind. Akten im Rechtsbereich, Versicherungsansprüche und Kreditanträge teilen eine Struktur, die durch bloßes Zerschneiden nicht erfasst werden kann.

Eine kürzliche Analyse auf Towards Data Science greift diesen Fehler direkt auf. Kernaussage ist, dass die Einheit, die es zu analysieren gilt, nicht das PDF, sondern der gesamte Aktenordner ist, und dass die zwei wertvollsten Fragen, für die man entwickeln sollte, überhaupt keine Retrieval-Fragen sind. Es handelt sich um relationale Tabellenprobleme. Diese Einordnung ist deshalb so bedeutsam, weil sie eine Abweichung am architektonischen Ausgangspunkt aufdeckt, die die meisten unternehmerischen Dokumentensysteme teilen.

Der Wert einer Akte liegt nicht in der Semantik einer einzelnen Seite, sondern im Beziehungsnetzwerk, das sich über mehrere Dokumente, Seiten und Zeitlinien erstreckt. Ein Kreditantrag gewinnt seine Bedeutung dadurch, dass Einkommensbescheinigung, Bankauszüge, ein Schufa-Auszug und das Antragsformular miteinander abgeglichen, reconciliert und zurückverfolgt werden können. Der Betrag auf einer einzelnen Bescheinigung ist diesen dokumentübergreifenden Verknüpfungen untergeordnet. Alles das in eine Vektordatenbank zu zwingen, komprimiert ein Beziehungsnetz in verstreuten Sand.

Tiefenanalyse

Die Vektorsuche beantwortet Fragen der semantischen Ähnlichkeit. Sie beherrscht es, zu identifizieren, welcher Textabschnitt einer gegebenen Frage am nächsten steht, kann aber nicht prüfen, ob der Betrag im Dokument A mit dem im Dokument B übereinstimmt, ob die Unterzeichner eines Vertrags alle erforderlichen Klauseln abdecken oder in welche Stufe eines Genehmigungsablaufs ein Zeitstempel fällt. Diese Fragen admittieren keine Ähnlichkeitszahl. Sie liefern wahr oder falsch, Ja oder Nein, übereinstimmend oder nicht. Solche Antworten gehören zum Bereich relationaler Datenbanken, die von Fremdschlüsseln, Constraints, Aggregation und Join-Operationen gelenkt werden, nicht von der Kosinusdistanz im Einbindungsraum. Der Unterschied ist strukturell, nicht bloß eine Frage des Retrieval-Tunings. Der Vorschlag des Autors lautet, dass das Indizierungssystem bereits wissen sollte, zu welchem Falltyp eine Akte gehört, bevor irgendeine Akte geöffnet wird, und den von diesem Typ verlangten Inhalt vorab auflisten soll. Dies erfordert Fachwissen: welche Dokumente eine Scheidungsakte erfordert, welche Qualifikationen ein Baubiet braucht, welche Belege ein Versicherungsanspruch verlangt. Die durch den Falltyp getriebene strukturierte Extraktion steht in direktem Gegensatz zur Volltextzerschneidung gefolgt von passivem Retrieval. Ersteres kodiert Geschäftsregeln als Schema, bevor die Extraktion beginnt; zweiteres ebnert alles gleich und verlässt sich darauf, dass das Modell die Bedeutung während des Retrievals zusammenfügt.

Der zweite Ansatz ist im Rechtskontext besonders gefährlich. Sobald eine kritische Beziehung beim Zerschneiden durchtrennt wurde, kann das Modell nur aus zerbrochenen semantischen Fragmenten schließen, und Fehler treten mit hohem Vertrauen auf. Kommerziell gesehen landen die Einsatzmöglichkeiten in Genauigkeit und Verantwortlichkeit. Recht, Finanzwesen und Medizin tolerieren fast keine Dokumentenverarbeitungsfehler; ein einziges falsch platziertes Feld kann einen Kredit ablehnen, einen Anspruch falsch einschätzen oder eine Vertragsklausel übersehen. Wenn ein Fehler aus semantischer Drift der Vektorsuche stammt, ist die Verantwortlichkeit diffus und schwer zurückzuverfolgen. Stammt er aus einer fehlenden relationalen Struktur, ist sie klar und durch Architektur korrigierbar.

Branchenwirkung

Dieser Unterschied formt um, wohin Ressourcen fließen. Führende Unternehmen verlagern Investitionen vom besseren Zerschneidungsstrategien hin zu rigoroserem Falltyp-Schema-Design. Die Wettbewerbslandschaft spaltet sich entsprechend. Eine Gruppe von Anbietern konkurriert weiter um Einbindungsmodelle und Ranking. Eine andere beginnt, strukturierte Extraktionsmaschinen aufzubauen, die für vertikale Falltypen konzipiert sind, die in spezialisierten Umfeldern oft stärkere Mauern mit sich bringen.

Für Käufer verändert dies die Fragen, die sie stellen sollten. Die Auswahl einer Dokumentenintelligenzlösung ist keine Frage mehr davon, wie hoch die Retrieval-Genauigkeit ist. Die schärfere Frage lautet, ob das System vor dem Lesen irgendeiner Datei benennen kann, welche Materialien, Felder und Beziehungen ein gegebener Fall verlangt.

Ausblick

Drei Signale sind Aufmerksamkeit wert. Erstens, ob Schemata, die durch den Falltyp getrieben werden, automatisch erzeugt werden können, sodass Systeme aus historischen Akten die gemeinsame Tabellenstruktur eines Falltyps ableiten, anstatt sich jedes Mal auf manuelle Definition zu verlassen. Zweitens, wie relationale Strukturen und Vektorsuche innerhalb eines Systems zusammenarbeiten können, sodass strukturierte Anfragen die wichtigsten Dokumente lokalisieren, während semantisches Retrieval Details auffüllt, sich ergänzend statt ersetzend. Drittens, ob diese Tabellen zu einem universellen Fall-Datenmodell institutionalienübergreifend standardisiert werden können, das echte Dateninteroperabilität zwischen verschiedenen Kanzleien, Versicherern und Banken ermöglicht.

Falls sich diese Richtungen voranbringen, wird die Dokumentenintelligenz über das bloße Lesen von PDFs hinausgehen und tatsächlich Fälle erledigen. Dieser Übergang könnte gut die Wasserscheide sein, die Vorführungen der Branche von Produktionssystemen trennt.