Der Chunker hätte vor drei Jahren einen eigenen Artikel verdient
Jeder Retrieval-Artikel, den wir geschrieben haben, nennt Chunking den größten Hebel und wendet sich dann etwas Interessanterem zu. Das beschreibt fair, wie die Branche damit umgeht — und es ist die Komponente, in der unsere gemessenen Gewinne am größten waren.
Warum er vernachlässigt wird
Weil er langweilig ist und weil er gelöst aussieht. Jedes Framework liefert einen Splitter mit Größe und Überlappung, beides konfigurierbar, und die Voreinstellungen erzeugen etwas, das für eine Vorführung gut genug funktioniert.
Danach justiert das Projekt den Reranker, denn dort liegen die interessanten Entscheidungen. Unsere Messungen sagen, die Reihenfolge sollte umgekehrt sein: In sechs Projekten, in denen wir beides gemessen haben, brachten Chunking-Änderungen mehr Verbesserung als sämtliche Reranker-Änderungen zusammen.
Was wir tun
Struktur vor Größe. Wir schneiden an den eigenen Grenzen des Dokuments — Überschriften, Abschnitte, Listenpunkte — und wenden eine Größenbegrenzung nur innerhalb davon an. Ein Chunk, der mitten im Satz endet, weil eine Zeichenzahl auslief, ist ein Chunk, der zur falschen Frage abgerufen wird.
Ein Gedanke je Chunk, Überschriften in den Text übernommen, damit eine Passage sagt, worum es geht, und Tabellen werden nie geteilt. Die letzte Regel klingt eng und verhindert eine ganze Klasse der Fehler, die wir beim Schreiben über Seiten als Bilder beschrieben haben.
Wohin die Forschung zeigt
Koutsiaris veröffentlichte 2026 eine Arbeit zu Chunking, das sich am vorhergesagten Informationsbedarf ausrichtet und ein Dokument danach segmentiert, was jemand voraussichtlich davon will, statt nach seiner Länge.
Das ist das Prinzip, bei dem wir gelandet waren, ohne es auszusprechen. Unsere Struktur-zuerst-Regel wirkt, weil Dokumentstruktur meist mit Informationsbedarf korreliert: Eine Autorin hat dort eine Überschrift gesetzt, weil ein Leser genau danach sucht. Wo die Struktur schlecht ist, bricht die Korrelation, und unser Chunker schneidet schlecht ab.
| Regel | Warum |
|---|---|
| An Struktur schneiden, dann Größe begrenzen | Eine Grenze bedeutet einem Leser etwas |
| Überschriften in den Chunk-Text übernehmen | Eine Passage soll sagen, worum es geht |
| Tabellen und Listen nie teilen | Die Beziehung ist der Inhalt |
| Überlappung nur über echte Grenzen | Nutzlose Doppelung kostet Index |
Das Erste, was wir falsch gemacht haben
Große Überlappung, jahrelang, weil sie die sichere Voreinstellung ist und eine sichere Voreinstellung niemand überprüft. Als wir endlich gemessen haben, entfernte ihre Verringerung in einem Bestand fast ein Fünftel der Vektoren ohne messbare Qualitätsänderung.
Überlappung existiert, damit eine Antwort nicht über eine Grenze zerrissen wird. Wo die Grenzen strukturell sind, passiert das selten — die Überlappung kauft dann eine Versicherung gegen einen Fehler, den die Struktur schon verhindert hat. Wir nutzen sie heute nur, wo ein Abschnitt tatsächlich über einen Seitenumbruch weiterläuft.
Das Zweite, was wir falsch gemacht haben
Eine einzige Chunk-Größe für einen gemischten Bestand. Eine Spezifikationstabelle, eine Prozedur und eine Seite Fließtext haben verschiedene natürliche Größen, und eine Einstellung bedient den Mittelwert einer Verteilung, die keinen sinnvollen Mittelwert hat.
Die Chunk-Größe ist heute eine Eigenschaft des Dokumenttyps statt der Pipeline. Das ist mehr Konfiguration, es verlangte eine Klassifikation eingehender Dokumente, und es brachte die zweitgrößte gemessene Einzelverbesserung nach dem Wechsel zum strukturbasierten Schneiden.
Wie wir ihn justieren
Gegen das Referenzset, eine Änderung nach der anderen, je drei Läufe. Chunking-Änderungen verlangen eine vollständige Neuindexierung, die Schleife ist also langsam — und genau diese Langsamkeit ist der Grund, warum Leute stattdessen den Reranker justieren, der schnell ist und weniger zählt.
Wir planen zu Projektbeginn zwei Tage für Chunking-Arbeit ein und behandeln sie als erste Optimierung statt als letzte. In jedem Projekt, in dem wir das getan haben, zählten die späteren Optimierungen weniger als erwartet — die richtige Reihenfolge, um das festzustellen.
Die Einstellung, die niemand kopieren sollte
Unsere. Die Zahlen, die für einen Bestand technischer Handbücher auf Deutsch mit vielen Tabellen funktionieren, sind nicht die Zahlen für eine Wissensbasis kurzer englischer Artikel — und eine Chunk-Größe als Empfehlung zu veröffentlichen ist der Weg, auf dem aus einer Voreinstellung eine Branchengewohnheit wird.
Übertragbar ist die Reihenfolge: Struktur zuerst, Größe innerhalb der Struktur, je Dokumenttyp, gemessen auf dem eigenen Referenzset. Die Zahlen, die dabei herauskommen, gehören Ihnen und interessieren sonst niemanden.
Was wir nicht behaupten
Wir behaupten nicht, Struktur zuerst gewinne immer. Bei Dokumenten ohne verlässliche Struktur, gescanntem Material oder schlecht konvertierten Dateien fällt es auf größenbasiertes Schneiden zurück, und wir haben nichts Besseres anzubieten, als zuerst die Konvertierung zu reparieren.
Wir behaupten auch nicht, Chunking sei für alle der größte Hebel. Es ist der größte, den wir gemessen haben, auf unseren Beständen, die dokumentlastig und strukturreich sind. Bei einem Bestand kurzer Datensätze entschiede sich die Qualität überwiegend anderswo.