Warum Chunking entscheidet, was Retrieval überhaupt finden kann
Ein Retriever kann keine Passage zurückgeben, die es als Chunk nicht gibt. Das ist das ganze Argument. Alles, was nach dem Chunking kommt — Embedding-Modell, Reranker, Prompt, das Modell selbst — wählt nur noch aus einer Speisekarte aus, die das Chunking geschrieben hat. Und steht der eine Satz, der die Frage beantwortet, in einem Chunk, dessen übrige 700 Token von etwas anderem handeln, ist der Vektor dieses Chunks ein Mittelwert aus beiden Themen. Mittelwerte liegen in der Nähe von allem und nah an nichts.
Deshalb vorab die ehrliche Antwort, noch vor jeder Systematik: Bei den meisten Unternehmenskorpora gewinnt die Strategie, die der Struktur folgt, die das Dokument ohnehin schon hat — und die die Chunk-Größe in Ruhe lässt. Die aufwendigen Verfahren, zu denen Teams greifen, gleichen meist einen Parser aus, der genau diese Struktur zerstört hat, bevor der Chunker sie je zu sehen bekam. Chunking-Debatten sind häufiger Parsing-Probleme in Verkleidung als echte Chunking-Probleme.
Chunking verdient außerdem mehr Sorgfalt als ein gewöhnlicher Parameter, weil die Entscheidung klebt. Verschieben Sie die Grenzen, ist jeder Vektor im Index ungültig: Sie embedden den kompletten Korpus neu und wiederholen Ihre Auswertung. Bei ein paar tausend Dokumenten ist das ein Nachmittag. Beim Handbucharchiv eines Maschinenbauers ist es ein Batch-Fenster und eine Rechnung.
Drei Chunking-Strategien, sortiert
Feste Größe, semantisch, strukturbasiert: Um diese drei dreht sich die Diskussion. Sie sind nicht gleichwertig, und die mittlere bekommt weit mehr Aufmerksamkeit, als sie verdient.
Feste Chunk-Größe: die Messlatte, die Sie schlagen müssen
Alle N Token schneiden, etwas Overlap dazu, fertig. Der RecursiveCharacterTextSplitter von LangChain ist die verbreitete Variante: Er trennt zuerst an Absätzen, dann an Zeilen, dann an Sätzen, zuletzt an Zeichen. Das ist deterministisch, schnell, kostenlos und mühelos zu debuggen — „warum liegt dieser Chunk hier?“ hat immer eine lesbare Antwort. Für Korpora ohne Struktur ist das kein Kompromiss, sondern die richtige Wahl: Gesprächsmitschriften, Chat-Verläufe, Forenthreads, OCR aus handschriftlichen Werkstattnotizen. Sein Fehlermodus ist wenigstens laut: Er trennt eine nummerierte Klausel von ihrer Nummer und zerschneidet eine Arbeitsanweisung zwischen Schritt 4 und Schritt 5.
Semantisches Chunking: womit ich nicht anfangen würde
Jeden Satz embedden, den Abstand zum nächsten messen, dort schneiden, wo der Abstand springt. Im Prinzip findet das Themengrenzen, die die Formatierung nie markiert hat. In der Praxis, bei den Korpora, die mir tatsächlich begegnen, entdeckt es überwiegend Absatzgrenzen wieder — die das Dokument längst mitliefert, als schlichtes Zeichen im Text, zum Nulltarif. Und es lässt sich das Wiederentdecken bezahlen: ein Embedding-Aufruf pro Satz beim Ingest, über ein Archiv aus 900-Seiten-Handbüchern, ist eine echte Rechnung und ein echtes Batch-Fenster.
Schwerer wiegt, dass es auf die unangenehme Art nicht deterministisch ist. Ihre Grenzen werden zu einer Funktion des Embedding-Modells — ein Modellwechsel formt also still den ganzen Index um. Und wenn Sie eine schlechte Antwort auseinandernehmen wollen, ist „warum beginnt dieser Chunk hier?“ nicht mehr beantwortbar. Für den Fall, zu dem es passt, würde ich es nicht ausschließen: lange, unstrukturierte Fließtexte, in denen Themen ohne Formatierungshinweis driften, etwa Interviewnotizen. Als Standard würde ich es nicht setzen — und nie, bevor es ein Testset gibt, das seinen Aufwand belegt.
Strukturbasiertes Splitting: das Skelett nutzen, das jemand schon gebaut hat
Dokumente, die für ein Unternehmen zählen, sind fast nie eine flache Textwand. Ein Liefervertrag hat nummerierte Paragrafen. Eine Wartungsanleitung hat Kapitel, Abschnitte und nummerierte Abläufe. Die Versicherungsbedingungen eines regionalen Versicherers haben eine Klauselstruktur, an der Juristen lange gesessen haben. Die semantische Segmentierung ist also längst erledigt — von Hand, mit Überschriften, und im Dokument hinterlegt. Wer an diesen Grenzen schneidet, erbt diese Arbeit: ein Markdown-Heading-Splitter, ein Durchlauf über die HTML-Überschriften, die Gliederung einer DOCX.
Genau deshalb liegt die eigentliche Arbeit davor. Strukturbasiertes Chunking ist nur möglich, wenn der Parser die Struktur erhalten hat. Wandeln Sie also in ein strukturiertes Zwischenformat — Markdown oder HTML — mit einem Werkzeug, das dafür gebaut ist: Docling, Unstructured oder Azure Document Intelligence, statt ein PDF nach Plaintext zu kippen und die Gliederung im ersten Schritt zu verlieren. Wer seine PDFs plattmacht, braucht anschließend semantisches Chunking, um zu rekonstruieren, was er selbst weggeworfen hat. Dieselbe unglamouröse Vorarbeit wie beim Vorbereiten der Daten für KI — und sie zahlt sich auf dieselbe Weise aus.
Die brauchbare Einordnung: Strukturbasiertes Chunking ist Chunking mit fester Größe, nur dass die Grenzen vom Autor stammen statt von einer Modulo-Rechnung. Die beiden sind keine Gegner. Sie schneiden an der Struktur — und wo ein Abschnitt danach immer noch über Ihre Obergrenze läuft, schneiden Sie genau diesen Abschnitt nach Länge.
Hören Sie auf, eine Chunk-Größe zu wählen
Die Größendebatte — 300 Token oder 1.000? — unterstellt, dass eine Zahl zwei Aufgaben erfüllen muss, die in entgegengesetzte Richtungen ziehen. Retrieval will klein: Ein Embedding ist ein einzelner Vektor fester Länge, je mehr eigenständige Gedanken Sie in einen Chunk pressen, desto unschärfer wird er. Die Generierung will groß: Das Modell braucht die Definition zwei Absätze weiter oben und die Ausnahme im Satz darunter, sonst antwortet es überzeugt auf halber Faktenlage.
Sie müssen sich nicht entscheiden, denn der Chunk, den Sie finden, muss nicht der Chunk sein, den Sie übergeben. Indexieren Sie die kleine Einheit, merken Sie sich einen Verweis auf ihren übergeordneten Abschnitt, und weiten Sie den Treffer bei einem Match auf diesen Elternabschnitt aus. LlamaIndex liefert das als Auto-Merging-Retrieval, LangChain als ParentDocumentRetriever — und es sind rund vierzig Zeilen, wenn Ihnen der eigene Code lieber ist als die Abhängigkeit.
Der Preis dafür gehört benannt: Fünf kleine Treffer können sich zu drei Elternabschnitten und ziemlich vielen Token ausweiten — Sie deduplizieren also die Eltern und deckeln das Kontextbudget. Dafür verschwindet der Parameter, um den alle streiten — und es ist die einzelne Änderung, die ein mittelmäßiges RAG-System, das auf meinem Tisch landet, am verlässlichsten besser macht.
Overlap, Tabellen und die Zeile, die einen Chunk rettet
Overlap gilt als Standardeinstellung — 10 bis 20 Prozent, warum nicht. Tatsächlich ist er ein Pflaster für Grenzen, denen Sie nicht trauen. Er kostet Indexgröße, und er kostet Plätze in den Top-k: Derselbe Satz auf Rang eins und Rang zwei bedeutet, dass ein einziger Gedanke zwei von fünf Sitzen im Kontext belegt. Folgen die Grenzen der Struktur des Autors, darf der Overlap gegen null gehen. Wo ich ihn behalte: ein, zwei Sätze Nachlauf, und zwar nur dort, wo ein langer Abschnitt ohnehin nach Länge geschnitten werden musste.
Tabellen sind das schärfere Problem, und ihr Versagen ist leise. Zerschneiden Sie eine Tabelle, landet die Kopfzeile im einen Chunk und die Zahlen im nächsten — „4,5“ und „18“ kommen dann ohne jeden Hinweis an, dass es sich um ein Anzugsmoment in Nm und eine Schraubenanzahl handelt. Für einen Zulieferer oder Maschinenbauer ist das kein Randfall: Der Fließtext ist die Verpackung, die Tabellen sind das Produkt. Drei Regeln, die sich halten: eine Tabelle nie über Chunks hinweg trennen; ist sie wirklich zu groß, die Kopfzeile in jedes Teilstück wiederholen; und dem Chunk, den Sie embedden, eine einzeilige Klartext-Zusammenfassung des Tabelleninhalts mitgeben — denn keine Frage sieht je aus wie eine Zahlenzeile, und genau diese Zusammenfassung ist es, worauf die Anfrage trifft.
Und dann die Zeile Code mit dem höchsten Ertrag in fast jeder Chunking-Pipeline: Stellen Sie den Überschriftenpfad dem Chunk-Text voran. Ein Chunk, in dem „Die Frist beträgt vier Wochen“ steht, ist unbrauchbar — welche Frist? Mit dem Präfix „Liefervertrag > §7 Gewährleistung > 7.2 Mängelrüge“ ist er auffindbar und zitierfähig. Entscheidend ist, wohin er gehört: in den Text, den Sie embedden, nicht nur in ein Metadatenfeld daneben. Das Embedding-Modell sieht den Text und sonst nichts. Strukturierte Metadaten verdienen sich getrennt davon: Quelle, Version, Datum, Seitenzahl, Zugriffsbereich — als Vorfilter vor der Vektorsuche und als Grundlage für Quellenangaben. Der Zugriffsbereich ist das, was einen Chunk aus der Antwort für jemanden heraushält, der das Dokument nicht sehen darf. Diese Seite der Pipeline behandelt RAG-Pipelines erklärt im Detail.
Wie Sie testen, welche Strategie an Ihren Dokumenten funktioniert
Alles bisher Gesagte ist eine Vermutung, kein Urteil. Ihre Dokumente haben eine Stimme — nur ist die Art, wie die meisten Teams sie abgeben lassen, wertlos: Man liest ein paar Antworten und findet sie gut. Damit vermengen Sie Chunking mit Retrieval, Ranking, Prompt und Modell: fünf Verdächtige, ein Indiz.
Isolieren Sie es stattdessen. Bauen Sie ein kleines Gold-Set: 30 bis 50 echte Fragen — und, das ist der Teil, auf den es ankommt, markieren Sie zu jeder die Passage, die die Antwort tatsächlich enthält. Dann messen Sie eine einzige Zahl: Wie oft liegt die antworttragende Passage in den Top-k, die der Retriever liefert? Recall@k fragt den Generator nichts, und genau deshalb ist es die Kennzahl, die Chunking isoliert. Ein Fehltreffer hier ist endgültig: Was nie auftaucht, holt kein Prompt und kein Modell zurück. Lassen Sie Ihre Kandidaten gegen dasselbe Gold-Set laufen, und aus der Diskussion wird eine Entscheidung.
Zwei Dinge machen das schwerer, als es klingt. Die Fragen müssen von Menschen kommen, die das System nicht gebaut haben — aus Support-Tickets, dem Suchlog, den Mails im Service. Fragen, die sich das Projektteam ausdenkt, sind systematisch zu wohlgeformt und übernehmen still das Vokabular der Dokumente. Und das Markieren der Antwortpassagen braucht jemanden, der die Unterlagen kennt: einen Nachmittag einer Fachkraft, nicht eines Entwicklers. Das ist der günstigste Nachmittag im ganzen Projekt und der, den fast alle auslassen — viele Teams verbringen drei Wochen mit dem Feintuning von Splittern und null Tage mit den fünfzig Fragen, die ihnen gesagt hätten, welcher Splitter bleiben soll.
Wo Tippel ins Spiel kommt
Chunking steht selten auf einem Projektplan. Es taucht später auf, als „der Assistent übersieht ständig Dinge, von denen wir wissen, dass sie drinstehen“ — und dann heißt die Korrektur: den Korpus neu indexieren und einräumen, dass nie jemand das Retrieval für sich allein gemessen hat. In der richtigen Reihenfolge ist das günstig, in der falschen ein Neubau.
Wenn Sie ein RAG-System haben, das fast gut genug ist, oder Dokumente, die schwieriger sein könnten, als sie aussehen, ist der KI-Readiness-Check ein zeitlich begrenzter Weg, das an Ihren echten Dateien zu klären: was der Parser rettet, welche Strategie auf einem Gold-Set aus Ihren Fragen gewinnt, und ob die ehrliche Antwort „bauen“ oder „noch nicht“ lautet. Festpreis, bei Beauftragung angerechnet. Wenn Sie es lieber erst besprechen, nehmen Sie Kontakt auf.