Chunking-Strategien für produktives RAG: Feste Größen, semantische Ansätze und Eltern-Kind-Strukturen.

Nehmen wir an, ein Schadensbearbeiter bei einer Versicherung fragt einen internen Assistenten: Welche Freigabe ist für einen Schadensanspruch wegen Wasserschäden in Höhe von 40.000 Euro erforderlich, und was muss überprüft werden, bevor er ausgezahlt werden kann? Der Assistent stützt sich auf das aktuelle Schadensbearbeitungshandbuch. Die Dateien wurden ordnungsgemäß eingelesen, das OCR funktionierte, die Vorausverarbeitung entfernte Störungen, das Embedding-Modell fand das richtige Handbuch und der Reranker platzierte es ganz oben.

Die Antwort kommt dennoch nur unvollständig zurück.

Ein erfahrener Schadensadjuster wäre nicht überrascht. Die Regel ist nicht in einem einzigen Absatz enthalten. Ein Erzählausdruck besagt, dass Ansprüche mit Verdacht auf vorherige Schäden eine unabhängige Inspektion vor der Zahlung erfordern. Darunter befindet sich eine Autorisierungstabelle. Auf der nächsten Seite gibt es ein Flussdiagramm, das zeigt, dass auch die Betrugsprüfung und die Überprüfung des Eigentumsrechts zuerst abgeschlossen werden müssen. Das Dokumentensystem fügt den Identifikator des Handbuchs, seine Version sowie die Region hinzu, auf die es anwendbar ist.

Für den Bearbeiter handelt es sich dabei nicht um vier getrennte Fakten. Es handelt sich um eine einzige Geschäftsregel, die in vier verschiedenen Formaten dargestellt wird: Der Absatz legt die Bedingung fest, die Tabelle nennt diejenigen, die zustimmen können, das Diagramm gibt die Reihenfolge der Überprüfungen an und die Metadaten angeben, welche Version gültig ist.

Ein Standard-Splitter mit Einstellung auf 500 Tokens kann den Absatz in einen Block, die obere Hälfte der Tabelle in einen zweiten, die entsprechende Tabelleinzeile in einen dritten und den aus dem Diagramm extrahierten Text in einen vierten Block legen. Jeder Block ist gültig. Jeder Embedding-Aufruf ist erfolgreich. Das Dashboard bleibt grün. Dennoch wurde das Wissen grundlegend umgeordnet. Bei der Abfrage muss das System den Behauptungstyp mit dem Betragsbereich verknüpfen, diesen auf einen Genehmiger zuordnen, die Inspektionsanforderungen finden und die Überprüfungen wiederherstellen – alles aus Fragmenten, die allein nicht lesbar sind. Das Sprachmodell erhält Teile und liefert eine unvollständige Antwort.

Deshalb führt das Debuggen von RAG in die Irre. Teams wechseln Embedding-Modelle, erhöhen den top-k-Wert, kaufen ein leistungsstärkeres Reranking-Modul oder schreiben den Prompt um. Manchmal hilft das. Häufig kompensiert es jedoch nur die durch die Segmentierung verursachten Schäden. Eine schlechte RAG-Qualität ist oft ein Chunking-Problem, das sich als LLM ausgibt.

Die meisten Diskussionen zum Chunking reduzieren sich auf eine einzige Zahl: 256 Token, 512 oder 1.000, zusammen mit dem Ausmaß der Überlappung. Das sind berechtigte Implementierungsfragen, doch die architektonische Frage ist eine andere:

Was muss zusammenbleiben, damit es auch dann noch dasselbe bedeutet, wenn es einzeln abgerufen wird?

Im Folgenden werden von den einfachsten Strategien über die Techniken aus den Jahren 2024 und 2025 bis hin zu einem Produktionsdesign erläutert, das mit unstrukturierten Unternehmensdokumenten umgehen kann. Dabei werden die Stellen aufgezeigt, an denen sich die jeweiligen Ansätze lohnen, und am Ende wird ein solches Design vorgestellt.

Welche Rolle spielt das Chunking im Prozessfluss?

Das Chunking ist kein isolierter Schritt bei der Textverarbeitung. Es bildet die Grenze zwischen dem Verständnis sauberer Dokumente und der Erstellung suchbarer Kenntnisse. Alles im Vorfeld bestimmt, was geteilt werden kann, und alles danach hängt davon ab, ob die Teile genügend Bedeutung, Struktur und Herkunft beibehalten, um korrekt gefunden zu werden.

Stellen Sie sich den vollständigen Pfad vor. Quellen wie PDFs, Tabellen, Bilder, JSON, Datenbanken, APIs und Code werden aufgenommen, analysiert, gereinigt und normalisiert. Erst danach entscheidet eine Chunking-Schicht, wie jede Inhaltsart zu einer Abrufeinheit wird. Für narrative Inhalte kann eine strukturelle oder semantische Aufteilung verwendet werden. Dichte Regelwerke eignen sich möglicherweise für Darstellungen auf Propositionsebene. Tabellen benötigen Grenzen, die ihrem Schema entsprechen. JSON sollte Geschäftsobjekten folgen. Bilder benötigen visuelle Beschreibungen, die auf das Original verweisen.

Deshalb wählt ein Produktionsystem selten eine einzige Chunk-Größe für alles. Ein Corpus kann Darstellungen auf Dokument-, Abschnitts-, Paragrafen-, Propositions- und Token-Ebene gleichzeitig enthalten. Eltern-Kind-Abrufpaare verwenden kleine Chunks für Präzision sowie größere Eltern-Chunks für Kontext, während spätes Chunking, kontextbasiertes Abrufen und RAPTOR Informationen rekonstruieren, die bei einer früheren Aufteilung sonst weggeworfen würden.

Das Chunking endet auch nicht, sobald Vektoren vorhanden sind. Metadaten zu Chunks, Dokumentversionen, Eltern-Kind-Verbindungen, Zugriffskontrollen sowie Quellenreferenzen müssen der Indizierung, dem Abruf, der Neubewertung, dem Zusammenstellen des Kontexts und der Erstellung standhalten. Die Bewertung schließt den Kreislauf: Fehlende Abrufe, duplizierte Kontexte, falsche Zitate sowie sich ändernde Abfragemuster sollten in die Entscheidungen bezüglich des Chunkings einfließen. Das produktive Chunking dreht sich weniger darum, Dokumente zu zerlegen, sondern vielmehr darum, die Abrufeinheiten zu entwerfen, auf denen alles Weitere beruht.

Der zentrale Kompromiss

Nehmen wir einen kurzen Auszug aus einer Richtlinie:

High-risk corporate customers must complete Enhanced Due Diligence.

Facilities above EUR 10 million require Group Credit Committee approval.

Fully cash-collateralised facilities may follow the exception defined in Section 7.4.3.

Das Zusammenhalten aller Elemente bewahrt den Kontext, erzeugt aber einen breiten, unklaren Vektor. Ein aggressives Aufteilen führt zu präziseren Ergebnissen, doch die Genehmigungsregel kann sich von der Kundengruppe entfernen, auf die sie angewendet wird, und die Ausnahme kann schließlich von der Regel getrennt werden, die sie ändert.

Das ist die gesamte Spannung: Kleine Abschnitte verbessern die Präzision, große Abschnitte bewahren den Kontext – und Produktionsysteme benötigen ein bewusstes Gleichgewicht. Jede Aufteilungsmethode ist ein anderer Weg durch diesen Kompromiss, und keine beseitigt die Notwendigkeit, die Dokumente sowie die tatsächlichen Fragen der Nutzer zu kennen.

Einfache Baselines

Aufteilung mit fester Größe

Die Aufteilung mit fester Größe teilt den Text in Abschnitte einer festgelegten Länge auf, meist in Tokens, mit optionaler Überlappung. Sie ist einfach, deterministisch und kostengünstig.

Das Zählen von Tokens ist im Allgemeinen besser als das Zählen von Zeichen, da Embedding-Modelle Tokens wahrnehmen. Fünfhundert Zeichen auf Deutsch oder Chinesisch können weitaus weniger sinnvolle Einheiten enthalten als derselbe Zeichenzahl auf Englisch. Die Methode kodiert den Text in Tokens, durchläuft diese in festen Abständen und decodiert jedes Fenster. Durch die Überlappung beginnt jedes Fenster vor dem Ende des vorherigen.

• Gut geeignet für: einheitlichen Prosa-Text, Baseline-Benchmarks, Fälle, in denen operative Einfachheit am wichtigsten ist, sowie frühe Prototypen, die zunächst einen funktionsfähigen Ablauf benötigen.
• Fällt durch: Situationen, in denen die Bedeutung von der Struktur abhängt. Eine Bedingung kann bei Token 499 enden, während ihre Ausnahme bei Token 501 beginnt – dabei weiß die Grenze nichts über die Geschäftslogik.

Was die Überlappung bewirkt

Überlappung ist eine Absicherung gegen Fehler an den Grenzen. Ohne sie kann ein Satz in zwei Teile geteilt werden, wobei keiner der beiden Teile für sich allein sinnvoll ist. Mit Überlappung enthält jeder Teil etwas vom Nachbarteil, sodass beide weiterhin interpretierbar bleiben.

Der Preis dafür ist real: mehr Vektoren, höhere Kosten für die Erstellung von Embeddings, mehr Speicherbedarf sowie Ergebnislisten, die mit nahezu identischen Abschnitten überfüllt sind. Ein Wert von zwanzig Prozent ist eher eine Gewohnheit als ein Gesetz – betrachten Sie ihn daher als Parameter, den Sie mit den Suchmetriken vergleichen können.

Festgrößiges Aufteilen verdient seinen Platz nicht durch Optimierung, sondern dadurch, dass es eine stabile Grundlage bietet. Wenn eine aufwendigere Methode in Ihrem Korpus nicht messbar besser abschneidet, ist die zusätzliche Komplexität nicht gerechtfertigt.

Rekursives Aufteilen

Unternehmensdokumente enthalten bereits nützliche Grenzen in Überschriften, Abschnitten, Paragraphen, Sätzen und Listen. Bei der rekursiven Aufteilung werden diese zuerst genutzt, bevor auf willkürliche Trennpunkte zurückgegriffen wird. Der rekursive Zeichentrenner von LangChain versucht beispielsweise zunächst doppelte Zeilenumbrüche, die in der Regel Paragraphen kennzeichnen. Falls ein Teil immer noch zu groß ist, werden anschließend einfache Zeilenumbrüche, Satzzeichen, Leerzeichen und schließlich einzelne Zeichen ausprobiert. Die Größenbegrenzung ist die Obergrenze, die jeweils zum Einsatz eines Ersatzverfahrens führt.

Die Reihenfolge der Trenner ist wichtiger als die genaue Größenangabe. Für gut strukturierte Richtlinien, Verfahren, Handbücher und technische Dokumentation stellt dies oft eine geeignete Standardlösung dar.

Eine wichtige Hinweis zur Erstellung: Wenn die Hierarchie bereits durch Extraktion ermittelt wurde, sollte man sie nicht wegwerfen und stattdessen einen Splitter bitten, sie erneut zu finden. Ein Abschnitt mit der Nummer 7.4 unter einem Kapitel über Ausleihen gibt bereits an, welcher Text zusammengehört. Bewahren Sie diese Struktur in den Metadaten auf und nutzen Sie sie, um die Aufteilung zu steuern. Einfach ausgedrückt: Zerstören Sie die Struktur beim Aufteilen nicht und versuchen Sie anschließend nicht, sie bei der Wiedergabe neu aufzubauen.

Rekursive Aufteilung setzt voraus, dass die Struktur im Großen und Ganzen der Bedeutung folgt – was jedoch nicht immer der Fall ist. Ein Absatz kann drei unzusammenhängende Regeln enthalten, und fünf Absätze können einen einzigen Prozess beschreiben. Genau hier kommen bedeutungsbasierte Methoden ins Spiel.

Satz- und Absatzeinheiten

Tools wie spaCy und NLTK bieten trainierte Satzdetektoren, die Probleme durch naive Trennung nach Punkten bei Abkürzungen, Dezimalzahlen, Überschriften und Ellipsen bewältigen. Die Aufteilung in Absätze ist einfacher und oft effektiv, da ein Absatz eine vom Autor absichtlich gewählte Gruppierung darstellt. Bei sauberen Dokumenten ist eine Trennung nach Absätzen sowie das Zusammenführen kurzer benachbarter Absätze bis zu einer Mindestgröße ein sinnvoller Kompromiss zwischen festen Größen und semantischen Ansätzen.

Der Nachteil liegt in der variablen Größenordnung der Abschnitte. Einige Absätze enthalten 50 Token, andere 800, was die Gruppierung erschwert, die Latenz bei der Embedding-Verarbeitung erhöht und eine Vorhersage der Indexgröße schwieriger macht. Ob die besseren Grenzen dies rechtfertigen, hängt vom Korpus ab.

Schiebende Fenster als Recall-Tool

Ein Schiebefenster ist eine Methode des Festgrößen-Chunkings, bei der Überschneidungen als Suchmechanismus genutzt werden und nicht nur zur Absicherung der Grenzen dienen. Der Grund dafür ist, dass ein Abfragesatz am besten mit dem Abschnitt übereinstimmt, der ihm direkt eine Antwort gibt. Wenn dieser Abschnitt sich über eine Grenze in einer Segmentierung erstreckt, kann weder das eine noch das andere Chunk eine gute Bewertung erzielen. Bei ausreichender Überschneidung erscheint jeder Abschnitt angemessener Länge in mindestens einem Chunk vollständig.

Mehr Überschneidung erhöht die Trefferquote, auf Kosten der Redundanz. Ab etwa 30 bis 40 Prozent füllen sich die top-k-Listen mit nahezu identischen Inhalten, die den Kontextbudget aufbrauchen, ohne neue Fakten hinzuzufügen; 10 bis 25 Prozent eignen sich für die meisten Korpora. Bewertet die Überschneidung, indem Sie neben der Recall@k-Wertung auch den Anteil an duplizierten Suchergebnissen messen, denn eine Erhöhung von Recall@5 bei gleichzeitiger Verdopplung der Duplikate verbessert die Antworten möglicherweise nicht.

begriffserkennende Strategien

semantisches Chunking

Semantisches Chunking ersetzt die Regel zur Token-Zählung durch eine Frage: Hat sich das Thema stark genug verändert, um eine neue Einheit zu beginnen? Stellen Sie sich einen Abschnitt vor, dessen erste beiden Sätze die Inspektionsanforderungen behandeln, dessen dritte sich auf Zahlungsgrenzen bezieht und dessen vierte Betrugsregeln erwähnt. Ein fester Trenner kann diese Übergänge nicht erkennen, während ein gut abgestimmtes semantisches Chunking-Tool dies kann.

Das übliche Vorgehen umfasst drei Schritte. Zuerst wird der Text mit einem sprachlichen Modell in Sätze unterteilt. Anschließend werden jeweils einzelne Sätze oder ein kleines Fenster aus benachbarten Sätzen mithilfe eines Sentence-Transformers verarbeitet. Danach wird die Kosinus-Distanz zwischen den benachbarten Embeddings berechnet, und an den Stellen, an denen diese Distanz einen definierten Prozentschwellenwert überschreitet – meist zwischen dem 85. und 95. Perzentil der Distanzen in diesem Dokument – wird eine Grenze gesetzt.

Diese Schwelle ist die entscheidende Einstellung. Ist sie zu aggressiv, zerfallen die damit verbundenen Ideen in winzige, bedeutungslose Teile. Ist sie zu nachsichtig, bleiben die unterschiedlichen Themen miteinander verbunden und führen dazu, dass der Störgeräuschpegel, den man beseitigen wollte, wieder auftritt.

Außerdem ist dies kostspieliger, denn vor dem Kenntnisstand der Grenzen muss eine vollständige Embedding-Berechnung durchgeführt werden. Bei kurzen, übersichtlichen Dokumenten lohnt sich der Aufwand kaum. Bei langen, inhomogen formatierten Texten kann das Erkennen echter Themenwechsel jedoch die Suchleistung deutlich verbessern. Eine ehrliche Einschränkung: Die Methode geht davon aus, dass Themen sich zwischen Sätzen allmählich und erkennbar ändern. In dichtem juristischen oder regulatorischem Prosa, in dem ein Satz drei Bedingungen und zwei Ausnahmen enthalten kann, erzeugen satzbezogene Distanzen störende Signale.

Eltern-Kind-Chunking

Dies gehört zu den am stärksten wirksamen Mustern in produktiven RAG-Systemen, denn es löst einen Konflikt, den ein herkömmlicher Einzel-Einheit-Ansatz ignoriert: Die beste Einheit für die Abfrage ist nicht unbedingt die beste Einheit für die Generierung.

Nehmen wir einen Abschnitt mit 2.000 Token, der Grenzen, Ausnahmen, Kontrollmechanismen und Eskalationsverfahren behandelt. Wenn dieser Abschnitt vollständig eingebettet wird, bleibt der Kontext erhalten, doch es entsteht ein vager Vektor. Wenn er in Teile à 200 Token aufgeteilt wird, verbessert sich die Abfragefähigkeit, doch das abgegleiche Fragment könnte das Fehlen dessen aufweisen, was das Modell zur guten Argumentation benötigt.

Durch Eltern-Kind-Strukturierung werden diese beiden Aufgaben getrennt. Ein Elternteil ist ein größerer, kohärenter Abschnitt – beispielsweise ein ganzer Satz, eine Vorgehensanweisung oder ein Unterkapitel. Die Kinder sind kleinere, fokussierte Fragmente, die daraus abgeleitet werden: einzelne Bedingungen, Schwellenwerte oder Ausnahmen. Nur die Kinder werden eingebettet und gesucht. Wenn ein Kind übereinstimmt, holt der zugehörige Elternteil-Identifikator den größeren Quelltext ab, und genau diesen liest das Modell tatsächlich.

LlamaIndex und LangChain bieten Versionen davon über hierarchische Knoten, die Suche von klein zu groß sowie die Suche nach Elterndokumenten. Jedes Kind speichert in den Metadaten eine Elter-ID, und nach der Suche werden die Treffer vor dem Zusammenstellen des Kontexts auf ihre Eltern erweitert.

In regulierten Umgebungen benötigen Identifikatoren eine echte Abstammungslinie. Eine lesbare ID, die Dokument, Version und Abschnitt kombiniert, ist sicherer als ein willkürlicher UUID – schließlich erzeugt ein Kind aus Version 7.2, das auf ein Elterndokument aus 7.1 verweist, einen scheinbar plausiblen, aber in der Praxis falschen Kontext. Dieses Muster funktioniert auch bei verschiedenen Modalitäten: Ein Kind kann eine serialisierte Tabellenzeile, eine visuelle Beschreibung eines Diagramms oder eine Aussage sein – alle teilen denselben Elterndokument, das einen logischen Abschnitt darstellt.

Aussage-Bucketting

Nehmen wir einen Satz wie diesen aus einer Kreditrichtlinie: Risikoreiche Unternehmen als Kreditnehmer benötigen eine verstärkte Sorgfaltspflicht sowie eine jährliche Überprüfung, und ein Ausschuss muss zustimmen, sobald ihre Exposition einen festgelegten Grenzwert überschreitet. Dies enthält drei klare Fakten. Ein Suchsystem, das angeben soll, wie oft solche Kunden überprüft werden, sollte nicht erst durch die Genehmigungskriterien gehen müssen, um eine Übereinstimmung zu finden.

Die Aufteilung in Propositionen zerlegt den Text in atomare, selbstständige Aussagen, von denen jede für sich abgerufen werden kann. Die Extraktion erfolgt in der Regel zum Zeitpunkt der Indizierung durch ein Sprachmodell mithilfe eines sorgfältig strukturierten Prompts, der alle Bedingungen, Schwellenwerte, Qualifikatoren und Ausnahmen beibehält, Pronomen dort auflöst, wo es der Text zulässt, und nichts ergänzt, was nicht ausdrücklich gesagt wird. Für den obigen Satz könnten drei Aussagen resultieren: Solche Kunden erfordern eine sorgfältige Prüfung, eine jährliche Überprüfung sowie bei Überschreiten des Exposur-Schwellenwerts die Genehmigung eines Ausschusses.

Jede Proposition erhält ihre eigene Embedding, wodurch der Vektorraum zu einem Raum atomarer Fakten statt von Abschnitten wird, was die Präzision bei spezifischen, faktenorientierten Fragen erhöht. Es gelten zwei Erstellungseinschränkungen:

• Die Proposition ist nicht die Quelle der Wahrheit. Es handelt sich dabei um eine durch ein Modell erzeugte Darstellung. In regulierten Arbeiten sollte man zunächst mit der Proposition vorgehen und anschließend zum autoritativen Text zurückkehren, um Grundlagen, Argumentationen und Quellenangaben zu finden. Die Proposition ist ein Indexeintrag und keine Behauptung.
• Die Kosten steigen stark an. Ein Dokument mit 10.000 Token kann Hunderte von Propositionen erzeugen, wofür jeweils eine Embedding-Aufruf erforderlich ist; dadurch wächst der Index schnell.

Ausgefallener Kontext wiederherstellen

Spätes Chunking

Beim herkömmlichen Chunking wird zunächst geteilt und jedes Teilstück für sich eingebettet. Beim späten Chunking, das Jina AI im Jahr 2024 einführte, wird dieser Ablauf teilweise umgekehrt.

Das späte Chunking führt zunächst das gesamte Dokument durch ein Modell für lange Kontexte, um kontextbezogene Repräsentationen auf Token-Ebene zu erhalten. Anschließend werden Grenzen für die Chunks festgelegt, wobei die Token-Vektoren, die sich innerhalb jedes Fensters befinden, zusammengefasst werden. Der Unterschied zu der einfachen Verwendung größerer Chunks besteht darin, dass die Abrufeinheit weiterhin klein bleibt. Der Abschnitt bleibt fokussiert, doch sein Vektor spiegelt den Kontext wider, in dem er erschienen ist. Pronomen, Abkürzungen, vorangehende Verweise sowie zuvor definierte Begriffe werden bereits im Embedding berücksichtigt und nicht dem Modell zur Erstellungzeit überlassen.

Die Infrastrukturkosten sind tatsächlich hoch. Man benötigt ein Modell für langkontextuelles Einbetten, das tokenbasierte Ausgaben liefert, zusätzliches Indexierungs-Speicher und sorgfältig gestalteten Pooling-Code. Es kann außerdem keine fehlerhafte Segmentierung beheben: Eine schlecht serialisierte Tabelle oder ein Diagramm, das im Vorausverarbeitungsschritt eingefügt wird, bleibt unerreichbar. Was es löst, ist der Kontextverlust beim Einbetten – nichts davor. Bei Korpora mit starken zwischen-satzlichen Abhängigkeiten, wie beispielsweise Vorschriften, Verträgen und Handbüchern, kann die Verbesserung der Einbettungsqualität erheblich sein.

Kontextbasierte Suche

Anthropics kontextbasierte Suchmethode, die 2024 veröffentlicht wurde, geht demselben Isolationsproblem auf andere Weise an. Sie ändert die Einbettungsarchitektur nicht, sondern bereichert den Suchtext jedes Abschnitts zum Zeitpunkt der Indexierung.

Eine isolierte Aussage, die eine Grenze angibt, kann nicht mit einer Anfrage übereinstimmen, in der Klassifizierung des Kunden, Zuständigkeitsbereich und Genehmigungsbehörde erwähnt werden, da diese Begriffe im umgebenden Dokument vorkommen. Deshalb wird vor der Indizierung für jeden Abschnitt eine kurze, dem Dokument spezifische Kontextangabe erstellt, die beispielsweise angibt, aus welchem Abschnitt welcher Policieveröffentlichung der Text stammt und was er definiert. Diese Angabe wird vorangestellt, und die Kombination wird eingebettet.

In der Bewertung von Anthropic verringerte die Kombination von kontextuellen Embeddings mit dem kontextbasierten BM25 die Anzahl der Fehlschläge bei der Top-20-Auswahl um 49 Prozent, und das Hinzufügen einer Neubewertung reduzierte diese Zahl um weitere 67 Prozent. Diese Zahlen stammen aus Anthropics eigenen Korpora und stellen keine Garantien dar. Die tatsächlichen Vorteile hängen von Ihren Dokumenten, Abfragen, dem Embedding-Modell sowie der Suchkonfiguration ab. Die Lehre daraus liegt nicht in den Zahlen selbst, sondern darin, dass das Hinzufügen von dokumentsspezifischem Kontext zu isolierten Textabschnitten erheblich helfen kann, insbesondere dann, wenn die wichtigen Bedeutungsinhalte außerhalb der Abschnittsgrenzen liegen.

Es hilft am meisten bei mehrdeutigen Fragmenten: verloren gegangenen Tabellenzellen, Bildunterschriften, Erwähnungen definerter Begriffe sowie Abschnitten, deren Geltungsbereich von einer übergeordneten Ebene stammt und die diese nicht mehr enthalten. Es eignet sich außerdem gut zur Kombination mit der Suche nach übergeordneten und untergeordneten Elementen. Es gilt eine Regel: Der erzeugte Kontext dient lediglich als Suchhilfe und nicht als Quellenangabe. Wenn jedem Abschnitt derselbe allgemeine Text zugeordnet wird, werden die Vektoren zu ähnlich, was die Suche beeinträchtigt. Eine gute Kontextualisierung fügt nur das hinzu, was ein Abschnitt benötigt, um ohne seine Nachbarn verstanden zu werden.

RAPTOR: mehrere Abstraktionsstufen

RAPTOR, abgekürzt für Recursive Abstractive Processing for Tree-Organized Retrieval, behebt ein Problem, das auch die einstufige Suchfunktion teilt: Fein granulierte Informationen beantworten präzise spezifische Faktenfragen gut, haben aber Schwierigkeiten mit Fragen, die eine Synthese aus verschiedenen Abschnitten erfordern. Vergleichen Sie dazu die Frage, wer eine bestimmte Behauptung genehmigt, mit der Anfrage nach dem gesamten Kontrollrahmen der Organisation für diesen Behauptungstyp. Bei der ersten Frage gibt es eine eindeutige, autoritative Antwort in einer Tabelle. Bei der zweiten Frage sind Beweise aus Überprüfungsregeln, delegierter Befugnis, Sicherheits- oder Wiederherstellungsrichtlinien, Überprüfungsverfahren sowie Eskalationswegen erforderlich – vermutlich aus verschiedenen Abschnitten und Dokumenten.

RAPTOR erstellt eine Hierarchie. Quelltextabschnitte bilden die unterste Schicht. Verwandte Abschnitte werden aufgrund ihrer inhaltlichen Ähnlichkeit gruppiert und ein Sprachmodell fasst jede Gruppe zusammen. Diese Zusammenfassungen werden erneut gruppiert und weiter zusammengefasst, bis schließlich einige hochrangige Zusammenfassungen das gesamte Dokument oder Korpus darstellen. Bei einer Abfrage kann eine spezifische Frage mit einem Einzelabschnitt übereinstimmen, während eine allgemeine Frage mit einer höherrangigen Zusammenfassung übereinstimmt – somit kann ein und dasselbe System beides ohne architektonische Änderungen verarbeiten.

Die größte Herausforderung bei der Erstellung ist die Herkunft der Informationen. Zusammenfassungen sind Interpretationen, und Interpretationen können Schwellenwerte, Randfälle sowie Ausnahmen verfälschen – genau die Details, die in regulierten Arbeitsabläufen am wichtigsten sind. Verwenden Sie übergeordnete Knoten, um die relevanten Teile des Korpus zu finden, und kehren Sie vor der Erstellung wieder zu den ursprünglichen Textpassagen zurück. Die Zusammenfassung hilft dabei, Beweise zu finden, während der ursprüngliche Text die Grundlage für die Schlussfolgerungen des Modells darstellt. RAPTOR lohnt sich bei langen Richtlinien, regulatorischen Rahmenwerken sowie umfangreichen Handbüchern, in denen Nutzer in einer einzigen Anwendung sowohl detaillierte als auch zusammenfassende Fragen stellen. Bei kurzen Sammlungen oder einheitlichen Abfragentypen lohnt sich die Komplexität in der Regel nicht.

Gestrukturierte und nicht-textuelle Inhalte

Tabellen: Struktur bedeutet Bedeutung

Gehen Sie zurück zur Autoritäts-Tabelle. Sie enthält explizite Beziehungen: Anspruchstyp „Wasserschaden“, Betragsbereich über 25.000 Euro, Genehmiger: Regionaler Anspruchmanager. Wenn man das in eine Abfolge von Wörtern umwandelt, verschwinden die Spaltenbeziehungen, die jedem Wert Bedeutung verleihen; daher benötigen Tabellen eine tabellenspezifische Verarbeitung.

Bei kleinen Tabellen ist es oft am besten, die Tabelle als Ganzes beizubehalten – insbesondere dann, wenn Abfragen Zeilen vergleichen oder den gesamten Bedingungsbereich benötigen. Schreiben Sie die Daten so auf, dass die Verbindungen von Spalte zu Zeile erhalten bleiben, beispielsweise indem Sie jede Zeile in Label-Wert-Paare umwandeln, die jeweils eine Spalte benennen. Bei großen Tabellen bilden Zeilen präzisere Abschnitte, doch jede Zeile muss ihre Überschriften enthalten, denn drei reine Werte ohne Beschriftung bedeuten für sich genommen nichts.

Hinter der Serialisierung verbirgt sich eine wichtigere Entscheidung. Wenn Benutzer deterministische Anfragen stellen, wie beispielsweise die Auflistung aller Genehmiger für Beträge über einer bestimmten Summe, kann die Vektorabfrage völlig ungeeignet sein. Tabellen, die über SQL oder DataFrames abgerufen werden, sind für präzise Filterabfragen jeder Embedding-Methode überlegen. Das Prinzip: Zerstören Sie keine explizite Struktur nur deshalb, weil alles wie Text aussehen soll.

JSON und strukturierte Datensätze

Dieselbe Logik gilt für JSON. Ein Datensatz mit den Feldern segment, rating, region, amount, approver sowie einem Review-Flag zeigt bereits, welche Felder zusammengehören; daher ignoriert ein Token-Splitter bei serialisiertem JSON dies. Kleine Datensätze sollten als Ganzes erhalten bleiben, wobei eine lesbare Abfrageformel jedes Feld zusammen mit seinem Label ausgibt. Bei großen Datenmengen sollten natürliche Geschäftsentitäten wie Kunden, Konten, Transaktionen, Überprüfungsereignisse oder Entscheidungen gefunden und um diese herum in Blöcke aufgeteilt werden.

Innerhalb eines Datensatzes sollten semantische Felder von filterbaren Feldern getrennt werden. Felder, die in Fragen in natürlicher Sprache vorkommen, gehören in den Embedding. Felder wie region, version, Geschäftseinheit und Gültigkeitsdatum eignen sich in der Regel besser als Metadatenfilter im Index als Teil des Vektors. Vorfiltern anhand von Metadaten ist schneller und genauer bei kategorischen Einschränkungen und sorgt dafür, dass der Embedding den Bedeutungsinhalt beibehält.

Code: Die Syntax ist die Grenze

Der Code stellt im anderen Bereich dasselbe Problem dar. Ein generischer Trenner, der eine Python-Datei bei Token 500 teilt, kann eine Funktion von ihrer Rückgabeanweisung oder eine Klasse von ihren Methoden trennen. Bei der Code-Suche sollten die Grenzen der Syntax folgen: Funktionen, Methoden, Klassen und Module. Pythons ast-Modul kann Quellcode in einen Baum strukturieren und jede Funktion, Asynchrone Funktion sowie Klasse als vollständige Einheit extrahieren, sodass die Abschnitte der Semantik der Sprache folgen anstatt durch Zeichenzählungen annähernd dargestellt zu werden. Für Repositorien in vielen Sprachen bietet tree-sitter eine einzige Parsing-Schnittstelle für Dutzende davon und kümmert sich um Randfälle, die reguläre Ausdrücke übersehen. Eltern-Kind-Beziehungen passen sich natürlich an: Man kann eine Methode präzise abrufen und anschließend, wenn das Modell einen breiteren Kontext benötigt, auf ihre Klasse oder Datei zugreifen.

Diagramme und Bilder

Betrachten Sie OCR-Text nicht als vollständige Darstellung eines visuellen Elements. Ein Flussdiagramm übermittelt Bedeutung durch Pfeile, Sequenzen, Verzweigungen, Gruppierungen und die räumliche Anordnung – all das kann von OCR nicht erfasst werden. Verwenden Sie ein modell, das visuelle Informationen verarbeiten kann, um eine Beschreibung zu erstellen, die angibt, was das Bild vermittelt, und nicht nur welche Wörter darauf zu sehen sind. Speichern Sie einen Verweis auf das Original. Die erzeugte Beschreibung ist der Indexeintrag, während das ursprüngliche Bild das ist, was das System als Beweis anzeigt. In regulierten Systemen sollte der Verweis auf das ursprüngliche visuelle Element verweisen und nicht auf seine Beschreibung.

Routing nach Inhaltstyp

Echte Dokumente sind vielfältig. Ein einzelnes Handbuch kann Erzählregeln, eine Autoritätsliste, ein Prozessdiagramm, JSON-Metadaten sowie eingebettete Verweise enthalten. Es gibt keinen sinnvollen Grund, für alle vier Arten denselben Trennprozess anzuwenden, da jede Art eine andere Bedeutungstransmission ermöglicht: Ein Absatz durch sprachliche Kontinuität, eine Tabelle durch die Schnittpunkte von Zeilen und Spalten, ein Diagramm durch Position, Richtung und Gruppierung sowie JSON durch explizite Schlüssel.

Die produktive Lösung ist ein Chunking-Router – ein Dispatcher, der den Inhaltstyp jedes extrahierten Blocks erkennt und ihn an die entsprechende Verarbeitungsstrategie sendet. Der Router muss nicht besonders intelligent sein; sein Wert liegt darin, dass die Routierung nach Inhaltstyp eine bewusste Designentscheidung ist und nicht das Ergebnis der Anwendung eines generischen Splitters. Im Fall des Claims-Manuals würde die Erzählung einer strukturellen oder semantischen Aufteilung zugeordnet, die Autoritätsliste einer tabellenorientierten Serialisierung, das Flussdiagramm einem Beschreibungsmodell und die Metadaten-JSON einer objektorientierten Trennung.

Jeder entstehende Chunk sollte dieselben Kernmetadaten enthalten, wie beispielsweise Dokument-ID, Version, Elternteil-ID, Abschnitt und Region. Diese gemeinsame Herkunft ermöglicht es späteren Schritten zu erkennen, dass eine Tabellenzeile, ein Absatz und eine Diagrammbeschreibung zusammenhängende Belege aus demselben Abschnitt sind.

Wenn größere Einheiten vorteilhaft sind

Ein Großteil der oben beschriebenen Entwicklungen zielt auf eine höhere Granularität ab, was den falschen Eindruck erwecken kann, dass immer kleinere Einheiten besser seien. Forschungen zu LongRAG untersuchten die entgegengesetzte Richtung und prüften, ob weitaus größere Abrufeinheiten – in einigen Experimenten bis zu etwa 4.000 Tokens – bei komplexen, mehrstufigen Fragen eine bessere Leistung als feingranulare Abrufe erbringen könnten. Es zeigte sich jedoch nicht, dass große Datensätze universell überlegen sind; vielmehr sollte die Granularität des Abrufs der Granularität der Anfrage entsprechen.

Eine Frage dazu, wie oft ein Kontotyp überprüft werden muss, lässt sich mit einer Antwort im Umfang einer Aussage beantworten. Für die Anfrage nach dem vollständigen Steuerungskonzept eines Anspruchstyps sind Belege aus mehreren Bereichen erforderlich, und feingranulare Abrufe können das System dazu zwingen, aus vielen isolierten Fragmenten eine umfassende Antwort zusammenzusetzen – wodurch Fehler auftreten, selbst wenn jedes Fragment korrekt ist.

Auswahl und Messung

Wie man eine Strategie wählt

Keine Chunking-Strategie ist überall die beste. Die Wahl hängt von der Dokumentstruktur, den tatsächlichen Abfragen, dem Latenzbudget, der Toleranz gegenüber Indexierungskosten sowie vom Design der nachgelagerten Generierung ab. Der Typ der Abfrage ist genauso wichtig wie der Dokumenttyp. Derselbe Strategie-Set kann sowohl eng gefasste Abfragen bezüglich einer Mindestüberprüfungsfrequenz als auch umfassende Anfragen zur Erklärung eines gesamten Frameworks bedienen – letztere erfordern eine andere Granularität bei der Datenabrufung. Wenn Ihre Bewertungsdaten nur einen bestimmten Typ abdecken, könnte die beste Strategie im echten Betrieb schlechter abschneiden.

Ein grober Leitfaden:

• Einheitlicher Text, frühes Prototypenstadium: fester Größenordnung mit geringer Überlappung.
• Gut strukturierte Handbücher und Verfahren: rekursives oder auf der Struktur basierendes Aufteilen, wobei die Hierarchie in Metadaten gespeichert wird.
• Lange Erzählungen mit inkonsistentem Format: semantisches Chunking, sofern der zusätzliche Aufwand einen messbaren Vorteil bringt.

Fragen, die sowohl Präzision als auch Kontext erfordern: Elternteil-Kind-Beziehungen.

Dichte Regelbeschreibungen und eng gefasste Faktensuchen: Aussagen mit Beibehaltung des Elternteils.

Teile, die für sich genommen an Bedeutung verlieren: kontextbasierte Abrufmethode oder spätes Teilungsvorgehen.

Mischformen von Abfragen in langen Dokumenten: hierarchische Methoden wie RAPTOR.

Tabellen, JSON, Code und Diagramme: typspezifische Verarbeitung über einen Router.

Benchmark statt Raten

Ein kurzer Blick auf einige Teile und die Schlussfolgerung, sie seien vernünftig, hilft beim Debuggen, ist aber keine Bewertung. Die eigentliche Frage ist, ob eine Strategie dem Abrufsystem dabei hilft, die für die tatsächlich gesendeten Abfragen benötigten Beweise zu finden.

Erstellen Sie ein Bewertungsset, das verschiedene Anforderungen abdeckt: eine enge Frage, die auf einer einzigen Tabellenspur beruht, eine mehrfach belegte Frage, die einen Erzählausdruck sowie eine Prozessbeschreibung erfordert, eine bedingte Frage zu einer Ausnahme sowie eine Synthesefrage, die mehrere Abschnitte umfasst. Verknüpfen Sie jede Anfrage mit den IDs der Sucheinheiten, die gefunden werden sollen.

Suchmetriken reichen allein nicht aus. Erfassen Sie, wie groß der Index im Vergleich zu einem fest definierten Referenzwert ist, welche Einbettungskosten pro Dokument anfallen, die Latenzzeiten beim Indexieren und Suchen, die Anzahl der Kontext-Token pro Anfrage, den Doppelungsgrad, die Richtigkeit der Antworten sowie die Richtigkeit der Zitate. Drei zusätzliche Punkte bei Recall@5 sind von geringem Wert, wenn sich der Index vervierfacht und die Ergebnisse fast ausschließlich aus Kopien bestehen.

In einem typischen Policy-Korpus zeigt sich ein plausibles Muster: Die rekursive Aufteilung ist bei gleichen Indexkosten um einige Punkte besser als die feste Größenbestimmung, das semantische Chunking führt bei geringfügig höheren Kosten zu einem etwas besseren Ergebnis, die Eltern-Kind-Struktur steigert die Trefferquote weiter mit einem deutlichen Indexanstieg, und Propositionen zusammen mit ihren Eltern erzielen die höchste Trefferquote – allerdings zu weitaus höheren Kosten und Komplexitäten. Die kontextbasierte Suche kann diese Trefferquote bei geringerem Indexwachstum erreichen, was ihre Verwendung beim Indexieren rechtfertigen kann, während RAPTOR bei eng gefassten Fakten hinter der Eltern-Kind-Struktur zurückbleiben kann, bei der Synthese aber vorn liegt. Betrachten Sie dies als Veranschaulichung der Abwägungen und nicht als gemessenes Ergebnis. Der richtige Betriebspunkt hängt von den Anforderungen an die Genauigkeit, den Latenzlimits, dem Indexierungsbudget sowie davon ab, ob jeder Zusatz seine Komplexität rechtfertigt.

Optimieren Sie nicht nur die Suche

Nehmen wir an, eine starke Überschneidung verbessert den Recall@5, doch die fünf besten Ergebnisse enthalten nun vier nahezu identische Abschnitte aus derselben Klausel, wodurch ein anderer relevanter Teil außerhalb des Kontextbudgets bleibt. Eine Metrik hat sich verbessert, doch das System ist dadurch schlechter geworden. Bewertet den gesamten Prozess – von der Recherche über die Neubewertung und Zusammenstellung des Kontexts bis zur Erzeugung – und prüft in jeder Phase, ob die benötigten Belege erhalten geblieben sind, ob Duplikate nützlichen Speicherplatz verbrauchen, ob die Antwort korrekt und belegt ist sowie ob die Quellenangabe auf die richtige Quelle und Version verweist.

In regulierten Systemen ist die Richtigkeit der Quellenangaben keine Nebensache. Eine Antwort kann faktisch richtig sein, aber auf einer falschen Version einer Richtlinie beruhen. Das stellt weiterhin einen Konformitätsfehler dar und bleibt unsichtbar, es sei denn, die Herkunft der Quellenangabe wird explizit überprüft.

Eine Produktionsarchitektur

Die zentrale Veränderung in der Denkweise besteht darin, dass ein ausgereiftes Unternehmenspipeline-System kaum jemals nach einem universellen Zerlegungswerkzeug verlangt. Es benötigt eine Routing-Schicht, die jeden Inhaltsteil an eine geeignete Strategie weiterleitet, gemeinsame Metadaten zur Herkunft aller entstehenden Teile speichert und explizite Verweise auf die autoritative Quelle bereitstellt.

Für das Antragshandbuch ist eine plausible Struktur wie folgt: Erzählbereiche werden strukturell oder semantisch aufgeteilt; dichte Regelklauseln werden zu Prämissen mit beibehaltenem Elternelement; kleine Tabellen werden vollständig serialisiert; große Tabellen werden in zeilenbasierte Blöcke unter Berücksichtigung der Überschriften aufgeteilt; Diagramme erhalten Beschreibungen im Stil von Vision-Modellen; und JSON-Einträge werden durch Objekte voneinander getrennt. Jeder Block, unabhängig vom Typ, trägt dieselben Identifikatoren: Dokument-ID, Version, Elternelement-ID, Abschnitt, Region sowie einen Verweis auf das ursprüngliche Dokument. Diese gemeinsame Abstammung ist genauso wichtig wie die Blöcke selbst, da sie es ermöglicht, eine Tabellenzeile, eine Klausel und eine Prozessbeschreibung als Beweismittel aus einem Abschnitt einer Version miteinander zu verknüpfen.

Zurück zum Antrag auf Schadensersatz wegen Wasserschäden

Die Frage war nie, ob 500 oder 800 Token die richtige Größe sind. Die Quelle enthielt verschiedene Arten von Belegen. Der Absatz machte deutlich, dass eine unabhängige Prüfung erforderlich war. Die Tabelle zeigte an, wer die Betragsklasse genehmigt. Das Diagramm erläuterte die Kontrollen vor der Zahlung. Die Metadaten gaben an, welche Version und Region gelten.

Eine gut konstruierte Chunking-Schicht bewahrt jeden Teil in seiner ursprünglichen Struktur und dokumentiert, dass sie einen gemeinsamen Abschnitt teilen. Dadurch gibt es bei der Abrufung verschiedene Möglichkeiten: Fragen zur Genehmigung holen die Zeile aus der Tabelle, Fragen zur Prüfung holen den entsprechenden Satzteil, Prozessfragen holen die Beschreibung aus dem Diagramm, und komplexe Fragen ziehen mehrere verwandte Teile heran und erweitern sich auf ihren gemeinsamen Elternteil. Das ist der Unterschied zwischen dem Aufteilen von Texten und der Gestaltung von Abrufeinheiten.

Die Reihenfolge, die zählt, ist nicht fest vorgegeben – es geht zunächst um Semantik, dann um Aussagen, wobei die neueste Idee gewinnt. Vielmehr: Lernen Sie die Quelle kennen, lernen Sie die Abfragen kennen, behalten Sie die bestehende Struktur bei, wählen Sie die geeignete Granularität für die Suche, ergänzen Sie fehlenden Kontext, bewahren Sie die Herkunft bei, messen Sie Suchergebnisse und Antworten sowie fügen Sie Komplexität nur dort hinzu, wo sie wirklich notwendig ist.

Eine letzte Überprülliste vor dem Indexieren

Bevor die Datenblöcke in den Embedding-Prozess gelangen, sollten sie drei Eigenschaften erfüllen:

• Auffindbar. Ausreichend spezifisch, um die relevanten Abfragen abzubilden, aber nicht so allgemein, dass alles grob abgeglichen wird.
• Interpretierbar. Enthält genügend Kontext, um allein seine Bedeutung zu bewahren, oder verfügt über eine zuverlässige Methode, diesen Kontext durch eine Elternsuche wiederzuerlangen.

Aufspürbar. Verweis auf die autoritative Quelle: das genaue Dokument, die Version, der Abschnitt, die Seite, die Tabelle, das Bild oder das Datensatzelement, aus dem es entnommen wurde.

Fehlt eines dieser Elemente, überträgt die Chunking-Schicht ihre Probleme auf die Abrufverarbeitung, Neubewertung, Zusammenstellung des Kontexts und Erstellung der Ergebnisse. Ein Vector-Store indiziert gerne eine mangelhafte Einheit, eine Embedding-API gibt ohne Beschwerden einen Vektor zurück und ein Modell kann daraufhin eine zuverlässige Antwort erstellen – doch keines dieser Verfahren zeigt an, dass die Darstellung korrekt ist. Es ist am günstigsten, eine fehlerhafte Einheit vor ihrer Umwandlung in ein Embedding zu beheben.

Vor der Veröffentlichung sollten außerdem die Protokollierung, die Handhabung von Geheimnissen und Konfigurationen, deterministische IDs, die Versionierung von Modellen und Prompts, das Tracking der Chunk-Herkunft, Zugriffskontrollen, Bewertungssammlungen, das Lifecycle-Management des Indexes sowie die Überwachung der Qualität der Abrufe, der Latenz und der Kosten geplant werden.