Chunks mit Köpfchen
KI für KMU, Teil 1
Über die besonderen Herausforderungen, die sich bei der Einführung von KI in kleinen und mittleren Unternehmen stellen, und über clevere Lösungen dafür hat ein Grundlagen-Artikel in der dotnetpro-Ausgabe 10-11/2025 berichtet [1]. In einer Reihe von Folgeartikeln sollen einzelne Aspekte der Thematik weiter vertieft werden. Im Folgenden geht es um das optimale Chunking von Texten.
Wer RAG-Systeme (Retrieval-Augmented Generation) oder KI-gestützte Wissensbasen aufbaut, steht früher oder später vor einer scheinbar trivialen Frage: Wie zerlege ich einen langen Text in kleinere Einheiten? Die Antwort entscheidet maßgeblich darüber, ob ein Large Language Model präzise antwortet oder am Ziel vorbei halluziniert. Denn gutes Chunking ist keine Nebensache – es ist das Fundament jeder semantischen Suche.
Die Herausforderung liegt darin, dass LLMs zwar mit großen Kontextfenstern arbeiten können, aber nicht beliebig viele Informationen gleichzeitig verarbeiten sollten. Ein 200-seitiges Handbuch als Ganzes in einen Prompt zu laden wäre ineffizient und fehleranfällig. Stattdessen müssen Inhalte in thematisch zusammenhängende Segmente – sogenannte Chunks – aufgeteilt werden. Nur so lassen sich relevante Abschnitte gezielt finden und als Kontext verwenden.
Doch wie trennt man den Text sinnvoll? Nach festen Zeichenlängen? Nach Absätzen? Nach Kapiteln? Die Antwort ist: Es kommt darauf an. Unterschiedliche Dokumenttypen erfordern unterschiedliche Strategien. Und wer hier vorschnell mit einfachen String-Splits arbeitet, riskiert fragmentierte Kontexte, die für das LLM wertlos sind.
Das Problem mit naivem Splitting
Der naive Ansatz zur Text-Segmentierung ist denkbar einfach: Man nimmt einen langen Text und teilt ihn alle X Zeichen. Vielleicht noch mit einem kleinen Zugeständnis an die Lesbarkeit, indem man beim letzten Satzzeichen trennt. Das funktioniert technisch – aber semantisch ist es eine Katastrophe.
Stellen wir uns ein Wartungshandbuch vor, das eine Anleitung zum Austausch einer Komponente enthält:
"...muss zunächst die Hauptstromversorgung deaktiviert werden. Anschließend öffnen Sie die Serviceklappe und entfernen die vier Befestigungsschrauben. Wichtig: Die Schrauben müssen in der angegebenen Reihenfolge gelöst werden, beginnend mit..."
Ein so vereinfachtes Splitting nach 200 Zeichen würde diese Anleitung mitten im Satz zerschneiden – etwa nach „Befestigungsschrauben“. Der erste Chunk endet mit einer unvollständigen Information, der zweite beginnt mit einem Satz, dessen Kontext fehlt. Wird später nur einer der beiden Chunks gefunden, ist die Information unbrauchbar.
Noch problematischer wird es bei verschachtelten Strukturen. In technischen Dokumentationen stehen oft Aufzählungen, Tabellen oder nummerierte Schritte. Ein Split, der eine Aufzählung mittendrin trennt, zerstört die logische Struktur. Das LLM erhält dann Fragmente wie „3. Prüfen Sie die Spannung“ – ohne zu wissen, was Schritt 1 und 2 waren.
Die Folge: Das Modell arbeitet mit Halbwissen. Es kann zwar syntaktisch korrekte Sätze generieren, aber die Antworten sind inhaltlich unvollständig oder schlicht falsch. Gutes Chunking bedeutet daher, Texteinheiten so zu schneiden, dass sie semantisch eigenständig bleiben.
Dokumenttypen und ihre Besonderheiten
Nicht jedes Dokument lässt sich gleich behandeln. Ein technisches Handbuch folgt anderen Strukturprinzipien als ein Gesetzestext, eine wissenschaftliche Publikation oder ein interner Prozessleitfaden. Wer Chunking-Strategien entwickelt, muss diese Unterschiede berücksichtigen.
Technische Handbücher und Spezifikationen sind oft hierarchisch aufgebaut: Kapitel, Unterkapitel, nummerierte Schritte, Warnhinweise. Hier bietet sich eine strukturbasierte Segmentierung an. Ein Chunk sollte idealerweise einem logischen Abschnitt entsprechen – etwa einem vollständigen Arbeitsschritt, einem Fehlercode mit Beschreibung oder einer Sicherheitsanweisung inklusive Kontext.
Beispiel: Ein Handbuch zur Fehlerdiagnose könnte so strukturiert sein:
Fehler 317-B: Überhitzung der Kühleinheit Symptome: - Rote LED-Anzeige an der Steuereinheit - Temperaturanzeige über 85°C - Automatische Abschaltung nach 30 Sekunden Ursachen: - Verstopfter Kühlluftfilter - Defekter Temperatursensor - Unzureichende Umgebungskühlung Behebung: 1. Gerät vollständig abschalten und abkühlen lassen 2. Filter prüfen und reinigen 3. Temperatursensor auf Beschädigung prüfen 4. Falls Problem bestehen bleibt: Service kontaktieren
Ein Split, der den Abschnitt „Symptome“ vom Abschnitt „Behebung“ trennt, würde den Kontext zerstören.
Fließtexte und Wissensdokumente hingegen haben oft keine so klare Struktur. Hier muss man auf Absätze, thematische Einheiten oder semantische Marker achten. Ein Absatz, der ein Konzept erklärt, sollte idealerweise zusammenbleiben. Splittet man ihn, verliert man den roten Faden.
Juristische oder regulatorische Texte wiederum leben von Verweisen: „gemäß § 42 Absatz 3“ oder „siehe Anlage A“. Hier entstehen logische Abhängigkeiten zwischen Textteilen, die beim Chunking berücksichtigt werden müssen – entweder durch Kontext-Anreicherung oder durch explizite Chunk-Referenzen.
Dies gilt in vergleichbarer Weise auch für Code. Ein Splitting, welches für Fließtext vorgesehen ist, wird es mit Code schwer haben.
Semantisches Chunking: Mehr als nur Länge
Die Idee hinter semantischem Chunking ist simpel: Statt nach festen Zeichengrenzen zu trennen, orientiert man sich an der inhaltlichen Struktur. Ein Chunk endet dort, wo auch ein thematischer Bruch stattfindet – etwa am Ende eines Absatzes, nach einem Aufzählungsblock oder beim Wechsel zu einem neuen Unterkapitel.
In der Praxis bedeutet das: Man nutzt strukturelle Marker wie Überschriften, Leerzeilen oder Formatierungen, um Trennpunkte zu identifizieren. Viele moderne Frameworks – etwa LangChain oder LlamaIndex – bieten dafür sogenannte „Splitter“, die genau das tun: Sie analysieren den Text auf Absatzebene, prüfen die Länge und entscheiden intelligent, wo getrennt wird.
Überlappungen: Kontext bewahren an den Grenzen
Selbst bei sauberem semantischem Chunking bleibt ein Problem: Informationen, die über Chunk-Grenzen hinwegreichen. Ein klassisches Beispiel sind Verweise wie „wie im vorherigen Abschnitt beschrieben“ oder Konzepte, die erst im Zusammenhang verständlich werden.
Die Lösung: Overlaps, also Überlappungen zwischen Chunks. Dabei wird ein Teil des vorherigen Chunks am Anfang des nächsten wiederholt – typischerweise die letzten 50 bis 200 Zeichen. So entsteht ein fließender Übergang, der verhindert, dass Kontextinformationen verloren gehen.
Beispiel ohne Overlap:
Chunk 1: "...die Düse muss vollständig entfernt werden." Chunk 2: "Danach reinigen Sie die Oberfläche mit einem fusselfreien Tuch."
Das Wort „Danach“ verweist auf eine Aktion, die nur im vorherigen Chunk erwähnt wird. Wird Chunk 2 isoliert gefunden, fehlt der Kontext.
Nutzen wir also nun einen Overlap entweder von fester Größe oder durch Prüfung des vorangegangenen und nachfolgenden Satzes, kann sich folgende Überlappung ergeben:
Chunk 1: "...die Düse muss vollständig entfernt werden." Chunk 2: "...die Düse muss vollständig entfernt werden. Danach reinigen Sie die Oberfläche mit einem fusselfreien Tuch."
Jetzt enthält Chunk 2 genug Kontext, um eigenständig verständlich zu sein. Das kostet zwar etwas Speicherplatz – die Information wird doppelt gespeichert –, erhöht aber die Qualität der Suchergebnisse erheblich.
Tabellen, Code und Fließtext: Unterschiedliche Logiken
Nicht alle Inhalte sind gleich. Während Fließtext sich gut nach Absätzen segmentieren lässt, erfordern Tabellen und Codeblöcke völlig andere Strategien. Stellen Sie sich einmal vor, man würde eine C#- oder JavaScript-Datei mit der gleichen Logik wie für Fließtexte splitten und damit zum Beispiel Punkte als Satztrenner identifizieren. Dies würde in keiner Weise irgendeine passende Logik für den Anwendungszweck darstellen. Ein Codeblock, der mitten in einer Funktion oder Schleife getrennt wird, ist syntaktisch ungültig. Hier muss nach logischen Einheiten getrennt werden: vollständige Funktionen, Klassen oder mindestens abgeschlossene Blöcke.
// Schlechtes Chunking:
Chunk 1: "public void Calculate() { var result = "
Chunk 2: "data.Sum(); return result; }"
// Gutes Chunking:
Chunk 1:
"public void Calculate()
{
var result = data.Sum();
return result;
}"
Viele Entwickler-Tools nutzen AST-Parser (Abstract Syntax Tree), um Code auf Funktions- oder Klassenebene zu zerlegen. Das ist aufwendiger, aber semantisch korrekt.
Ähnliches gilt für Tabellen. Diese sollten idealerweise als Ganzes erhalten bleiben. Eine halbierte Tabelle ist nutzlos – Spalten ohne Header, Zeilen ohne Kontext. Wenn eine Tabelle zu groß ist, sollte man sie zeilenweise aufteilen, aber dabei die Header-Zeile in jedem Chunk wiederholen. Eine weitere Möglichkeit wäre, aus einer Tabelle zum Beispiel teilstrukturierte Texte mit Überschriften-Ebenen und Aufzählungslisten für jede Spalte umzusetzen. So kommt man dem strukturierten Text am nächsten.
Praktische Ansätze und Frameworks
Für viele Entwickler ist die gute Nachricht: Man muss das Rad nicht neu erfinden. Frameworks wie LangChain oder LlamaIndex bieten vorgefertigte Splitter, die viele der beschriebenen Strategien bereits implementieren.
Auch wenn diese Tools primär in Python verfügbar sind, lassen sich die Konzepte problemlos in C# umsetzen. Wer mehr Kontrolle braucht, kann eigene Splitter schreiben – etwa mit RegEx-Mustern, strukturiertem Parsing oder ML-basierten Klassifikatoren.
Wichtig ist: Testen, messen, iterieren. Das Trennen von Textinformationen ist keine exakte Wissenschaft. Was für technische Handbücher funktioniert, versagt vielleicht bei juristischen Texten. Die Qualität lässt sich durch Metriken wie Retrieval Precision oder durch manuelle Stichproben überprüfen.
Gutes Chunking ist kein Detail – es ist eine architektonische Entscheidung mit direktem Einfluss auf die Qualität jeder KI-Anwendung. Wer hier vorschnell zu simplen Lösungen greift, zahlt später mit ungenauen Antworten, frustrierten Nutzern und aufwendigen Nachbesserungen.
Es gibt keine universelle Lösung. Dokumenttypen, Inhaltsstrukturen und Anwendungsfälle sind zu verschieden. Doch mit einem Verständnis für semantische Einheiten, intelligente Overlaps und strukturbasiertes Splitting lässt sich für jedes Projekt eine passende Strategie entwickeln.
[1] Patrick Schnell, KI im Mittelstand braucht mehr als Technik, dotnetpro 10-11/2025, Seite 88 ff.
