Strategien für chunking

#Warum Chunking genauso wichtig ist wie das Embedding-Modell

Chunking bezeichnet das Aufteilen eines Dokuments in Textabschnitte vor deren Indexierung: Jeder Abschnitt erhält einen Vektor, und bei der Suche wird ein Abschnitt gefunden und anschließend an das Sprachmodell übergeben, niemals das gesamte Dokument. Alles Weitere hängt von dieser Aufteilung ab. Wenn der Satz, der die Frage beantwortet, auf zwei Abschnitte verteilt wird, enthält keiner von beiden ihn vollständig, und die Suche findet ihn nicht; wenn ein Abschnitt drei Themen vermischt, ist sein Vektor ein unscharfer Mittelwert, der keiner Frage besonders ähnlich ist. Ein leistungsfähigeres Embedding kann eine fehlerhafte Aufteilung nicht beheben, da es nur das vektorisieren kann, was ihm übergeben wird.

Eine Studie von Chroma zur Bewertung von Aufteilungsstrategien zeigt: Heuristische Methoden wie der RecursiveCharacterTextSplitter liefern in der Praxis oft gute Ergebnisse, wenn sie richtig parametrisiert sind, und die Ergebnisse variieren deutlich je nach gewählter Größe und Überlappung. Dieser Leitfaden verspricht daher keinen allgemeingültigen, bezifferten Zugewinn: Verlässlich ist nur, die Ergebnisse anhand Ihrer eigenen Dokumente zu messen.

#Welche Chunk-Größe wählen

Es gibt keine universell passende Größe, aber es gibt Anhaltspunkte. In der Studie von Chroma übertrifft die rekursive Strategie die Aufteilung nach Tokens bei Größen von höchstens 400 Tokens ohne Überlappung; bei größeren Größen und bei Überlappung verhält sie sich anders. Die Standardkonfiguration des Dateisuchtools von OpenAI – 800 Tokens mit einer Überlappung von 400 Tokens – erzielt in diesem Test einen leicht unterdurchschnittlichen Recall und die niedrigsten Werte bei den anderen Metriken. Die folgenden Anhaltspunkte leiten sich daraus ab, ohne den Anspruch, für Ihr Korpus exakt zu sein.

#Tokens oder Zeichen: die Falle bei den Einheiten

Die Bibliotheken zählen nicht alle in derselben Einheit. Der SentenceSplitter von LlamaIndex gibt chunk_size und chunk_overlap in Tokens an, laut seiner Dokumentation mit den Standardwerten 1024 und 200. Andere Tools, darunter der RecursiveCharacterTextSplitter von LangChain, zählen standardmäßig in Zeichen; prüfen Sie den Parameter length_function Ihrer Version. Wenn Sie im einen oder im anderen Tool „500“ einstellen, unterscheiden sich die Chunk-Größen um etwa den Faktor vier. Zweite Einschränkung: Das Embedding-Modell hat eine eigene maximale Eingabelänge. Das Modell BGE-M3 unterstützt laut seinem Modellprofil Eingaben mit bis zu 8.192 Tokens; andere, ältere oder kleinere Embedding-Modelle akzeptieren deutlich weniger, und jenseits dieser Grenze wird das Ende der Textpassage ignoriert. Prüfen Sie die Grenze Ihres Modells, bevor Sie die Größe wählen, und zählen Sie mit dem Tokenizer des Modells statt nach Augenmaß.

#Überlappung: nützlich, aber nicht immer

Bei der Überlappung wird das Ende eines Chunks am Anfang des nächsten wiederholt, damit ein an der Grenze geteilter Satz zumindest in einem der beiden Chunks lesbar bleibt. Das hat seinen Preis: mehr Chunks, einen größeren Index und Duplikate in den Ergebnissen. Die Studie von Chroma stellt fest, dass eine geringere Überlappung den IoU-Score verbessert, eine Metrik, die redundante Informationen negativ bewertet. Überlappung ist sinnvoll, wenn Sie den Text in Abschnitte fester Größe aufteilen; sie ist weniger wichtig, wenn Sie bereits an Absatz- und Überschriftengrenzen aufteilen, da die Trennstellen dann an natürlichen Grenzen liegen.

0 Token

Ausreichend bei einer Aufteilung nach Absätzen oder nach der Dokumentstruktur; am sparsamsten.

10 bis 15 Prozent der Größe

Guter Kompromiss, wenn die Aufteilung nach Sätzen oder Zeichen erfolgt.

mehr als 25 %

Selten gerechtfertigt: Sehr viel Redundanz, fast identische Abschnitte in den Ergebnissen.

#Strategien zur Aufteilung in Textabschnitte, von der einfachsten bis zur aufwendigsten

#1. Nach fester Zeichenanzahl

Den Text nach jeweils N Zeichen oder Tokens aufteilen, ohne seinen Inhalt zu berücksichtigen. Der einfachste und zugleich destruktivste Ansatz: Er trennt mitten in Wörtern, Sätzen und Tabellen. Nur für Prototypen verwenden.

#2. Nach Absätzen oder Sätzen

An doppelten Zeilenumbrüchen oder Satzzeichen aufteilen, dann die Einheiten bis zur Zielgröße zusammenfassen. Eine deutliche Verbesserung ohne zusätzliche Kosten, da jeder Chunk an einer natürlichen Grenze beginnt und endet.

#3. Rekursiv

Zunächst wird versucht, an gröberen Trennstellen aufzuteilen (Absatz, Zeile, Satz, Leerzeichen); erst als letztes Mittel wird auf Zeichenebene aufgeteilt. Das ist das Standardverhalten der wichtigsten Frameworks und eine solide Grundlage: Die Studie von Chroma stellt fest, dass diese Art der Aufteilung bei geeigneten Einstellungen häufig gut funktioniert.

#4. Gemäß der Dokumentstruktur

Überschriften, Listen, Tabellen und Codeblöcke werden berücksichtigt. Der MarkdownNodeParser von LlamaIndex beispielsweise teilt den Text anhand der Überschriften auf und fügt jedem Knoten den Pfad der Überschriften hinzu, die zu ihm führen. Dadurch erhält die Textpassage einen Kontext, den ihr Text allein nicht bietet. Das ist die beste Wahl für technische Dokumentation, Wikis und exportierte HTML-Seiten.

#5. Semantik

Für jeden Satz wird ein Embedding berechnet. Anschließend wird dort getrennt, wo die Ähnlichkeit zwischen zwei benachbarten Sätzen stark abnimmt. In LlamaIndex nimmt der SemanticSplitterNodeParser einen buffer_size (Anzahl der gemeinsam verglichenen Sätze, standardmäßig 1) und einen breakpoint_percentile_threshold (standardmäßig 95; ein niedrigerer Wert erzeugt mehr Knoten) entgegen. Der Aufwand besteht in einer zusätzlichen Berechnung von Embeddings bei der Indexierung, und der Nutzen ist nicht belegt: Eine Studie vom Oktober 2024 zu drei Retrieval-Aufgaben kommt zu dem Schluss, dass die Rechenkosten der semantischen Segmentierung nicht durch durchgängige Leistungsgewinne gerechtfertigt sind. Testen Sie das Verfahren an Ihrem Korpus, bevor Sie es übernehmen.

#6. Hierarchisch (Eltern- und Kindknoten)

Für eine präzise Suche werden kleine Chunks indexiert; für den Kontext erhält das Modell den größeren übergeordneten Block. Der HierarchicalNodeParser von LlamaIndex erzeugt solche Hierarchien, laut seiner Dokumentation beispielsweise mit drei Ebenen von 2048, 512 und 128 Token. Das ist die Lösung für lange Passagen: weder ausschließlich kleine noch ausschließlich große Chunks.

#Implementierungen mit LlamaIndex

from llama_index.core.node_parser import SentenceSplitter

splitter = SentenceSplitter(chunk_size=400, chunk_overlap=40)  # en tokens
nodes = splitter.get_nodes_from_documents(docs)

from llama_index.core.node_parser import MarkdownNodeParser

parser = MarkdownNodeParser()
nodes = parser.get_nodes_from_documents(docs)
# le chemin des titres est stocké dans les métadonnées de chaque nœud

from llama_index.core.node_parser import HierarchicalNodeParser, get_leaf_nodes

parser = HierarchicalNodeParser.from_defaults(chunk_sizes=[2048, 512, 128])
nodes = parser.get_nodes_from_documents(docs)
leaves = get_leaf_nodes(nodes)  # ce sont les feuilles qu'on vectorise

from llama_index.core.node_parser import SemanticSplitterNodeParser
from llama_index.embeddings.huggingface import HuggingFaceEmbedding

embed = HuggingFaceEmbedding(model_name="BAAI/bge-m3")
splitter = SemanticSplitterNodeParser(embed_model=embed, buffer_size=1, breakpoint_percentile_threshold=95)
nodes = splitter.get_nodes_from_documents(docs)

#Jedem Chunk wieder Kontext geben

Eine aus ihrem Dokument herausgerissene Passage verliert ihren Kontext: „Die Frist beträgt 30 Tage“ sagt nicht, worum es geht. Drei einfache Vorgehensweisen schaffen Abhilfe. Jedem Chunk den Dokumenttitel und den Abschnittspfad voranstellen; diese Informationen als Metadaten speichern, um nach Datum, Quelle oder Dokumenttyp filtern zu können; und bei Passagen, die mit einem Pronomen oder einem Verweis beginnen („diese Klausel“), die übergeordnete Ebene der hierarchischen Aufteilung in Betracht ziehen. Oft genügt eine einzige Kontextzeile vor dem Text, und sie kostet deutlich weniger als ein Modellwechsel.

#Das Chunking vorab bewerten, bevor es festgelegt wird

1. 01
   30 bis 50 echte Fragen formulieren

   Fragen, die Ihre Nutzer stellen würden, jeweils mit der erwarteten Quellpassage; formulieren Sie sie, bevor Sie sich die Ergebnisse ansehen.
2. 02
   Mit zwei oder drei Konfigurationen indexieren

   Zum Beispiel 250, 400 und 700 Tokens mit einem Overlap von 0 und 10 %. Halten Sie die anderen Parameter konstant.
3. 03
   Den Recall in den ersten 5 Ergebnissen messen

   Ist für jede Frage die erwartete Passage unter den ersten 5 Ergebnissen enthalten? Der Prozentsatz ergibt den Recall@5.
4. 04
   Auch Präzision und Redundanz betrachten

   Ein identischer Rückschluss mit variierterer Ausgabe ist eine bessere Einstellung. Zählen Sie die Doppelte in der Top-5.
5. 05
   Die Fehlschläge einzeln durchgehen

   Öffnen Sie für jede falsch beantwortete Frage den Chunk, der die Antwort hätte liefern sollen: Ist er abgeschnitten, zu groß oder der Textauszug beschädigt? Die Ursache bestimmt die Korrektur.

#Häufige Stolperfallen

Beschädigte Tabellen

Ein PDF-Extraktor, der eine Tabelle in flachen Text umwandelt, erzeugt Zeilen aus Zellen ohne sinnvollen Zusammenhang: Extrahieren Sie die Struktur vor dem Aufteilen in Abschnitte.

Abgebrochene Codeblöcke

Ein Chunker, der die Syntax nicht berücksichtigt, zerschneidet einen Block mittendrin; verwenden Sie eine strukturorientierte Aufteilung.

Gemischte Dokumente

Ein Chunk, der zur Hälfte aus französischem und zur Hälfte aus englischem Text besteht, erzeugt einen wenig hilfreichen gemittelten Vektor: Trennen Sie die Inhalte nach Sprache, wenn das Korpus gemischtsprachig ist.

Fast leere Chunks

Ein Titel allein („3.2.1 Verpflichtungen“) ohne den folgenden Text ist Rauschen: Filtern Sie zu kurze Chunks oder fügen Sie sie mit dem nächsten zusammen.

Das Chunking ändern, ohne neu zu indexieren

Die Aufteilung wird bei der Indexierung festgelegt: Jede Änderung erfordert eine Neuberechnung der Vektoren. Planen Sie von Anfang an ein Skript zur Neuindexierung ein.

#Häufige Fragen zum Chunking

• Einen Reranker in die Pipeline integrieren
• Hybride Suche: BM25 + Vektorsuche
• Die besten Embedding-Modelle für Französisch
• Lokales RAG mit ChromaDB und Ollama
• LlamaIndex in der Praxis

• Quelle: Chroma, Evaluating Chunking Strategies for Retrieval
• Quelle: Is Semantic Chunking Worth the Computational Cost?
• Quelle: LlamaIndex, Node-Parsers
• Quelle: Modellkarte von BAAI/bge-m3 auf Hugging Face