Wenn ein RAG-System eine falsche oder halb richtige Antwort liefert, liegt das meist nicht am Modell. Es liegt am Chunking. Wenn die Passage mit der Antwort nie in den abgerufenen Kontext gelangt, kann kein Modell daraus antworten, und keine Menge an Prompt-Tuning ändert das. Chunking entscheidet, was überhaupt abgerufen werden kann, was es zum ersten macht, das man prüfen sollte, und zum letzten, das die meisten Teams sich ansehen.

Amazon Bedrock Knowledge Bases lässt dich eine Chunking-Strategie wählen, wenn du eine Datenquelle anlegst. Diese eine Entscheidung setzt still die Obergrenze für deine Retrieval-Qualität. Triffst du sie falsch, verbringst du Wochen damit, dem Embedding-Modell, dem Reranker oder dem LLM ein Problem anzulasten, das in der Art liegt, wie du die Dokumente zerschneidest.

Warum Chunking die tragende Entscheidung ist

Retrieval arbeitet mit Chunks, nicht mit Dokumenten. Jeder Chunk wird in einen Vektor eingebettet, und zur Abfragezeit holst du die Top-k-Chunks, die der Frage am nächsten liegen. Zwei Fehlerformen folgen direkt aus der Chunk-Größe.

Zu große Chunks verwässern das Embedding. Ein 2000-Token-Chunk, der vier Unterthemen abdeckt, erzeugt einen Vektor, der der Durchschnitt aller vier ist, sodass er zu allem schwach passt und zu nichts stark. Der richtige Chunk wird unter Beinahe-Treffern begraben. Zu kleine Chunks kappen den Kontext. Eine Definition, die von ihrem Beispiel getrennt wurde, oder ein Schritt, der von seiner Warnung getrennt wurde, wird sauber abgerufen, kommt aber ohne den umgebenden Text an, der ihn nützlich gemacht hätte. Die Antwort ist technisch vorhanden und praktisch unvollständig.

Die Aufgabe einer Chunking-Strategie ist es, an sinnvollen Grenzen zu schneiden, sodass jeder Chunk ein zusammenhängender Gedanke ist: eigenständig genug, um daraus zu antworten, und spezifisch genug, um gut zu ranken.

Die drei Strategien, die Bedrock dir bietet

Fixed-Size-Chunking

Teile alle N Tokens mit etwas Überlappung. Das ist die Standardeinstellung und die günstigste, und sie funktioniert gut für einheitlichen, prosalastigen Inhalt mit allmählichen Themenwechseln. Sie ist aktiv schlecht für strukturierte Dokumente, weil sie schneidet, wo eben der Token-Zähler landet: mitten in einer Tabelle, mitten in einer Liste, zwischen einer Überschrift und dem Absatz, den sie einleitet. Überlappung mildert den Schaden, entfernt ihn aber nicht. Greif zu Fixed-Size, wenn dein Korpus homogen ist und du eine Baseline willst, nicht weil es die Standardeinstellung ist.

Semantic Chunking

Teile nach Bedeutung. Semantic Chunking misst die Embedding-Ähnlichkeit zwischen benachbarten Sätzen und beginnt einen neuen Chunk dort, wo sich das Thema verschiebt, sodass Grenzen zwischen Ideen fallen statt bei einer festen Token-Zahl. Das ist die richtige Standardwahl für gemischte Inhalte: FAQs, Wissensartikel, gemischte Prosa, bei denen jede Antwort oder jedes Konzept ganz bleiben soll. Es kostet mehr, den Index zu bauen, weil beim Chunken zugleich eingebettet wird, aber der Unterschied in der Retrieval-Qualität bei heterogenen Korpora ist der Grund, dafür zu zahlen.

Hierarchical Chunking

Baue Parent- und Child-Chunks. Kleine Child-Chunks werden eingebettet und für präzises Retrieval gematcht, aber der größere Parent-Chunk ist das, was an das Modell zurückgegeben wird, sodass du nach Spezifität rankst und mit Kontext antwortest. Das passt zu Dokumenten mit echter Struktur, technischen Handbüchern, Rechtsverträgen, allem mit Abschnitten und Unterabschnitten, wo eine Anfrage eine enge Klausel trifft, das Modell aber den umgebenden Abschnitt braucht, um sie korrekt zu nutzen. Es ist am aufwendigsten zu durchdenken und passt am besten, wenn deine Dokumente eine echte Hierarchie haben, die sich ausnutzen lässt.

Retrieval bewerten, bevor du dem Modell die Schuld gibst

Die nützlichste Gewohnheit überhaupt ist, die Retrieval-Frage von der Generierungsfrage zu trennen. Bevor du am Prompt herumschraubst oder das Modell wechselst, stell nur eine Frage: Ist bei einer Reihe echter Fragen der Chunk mit der Antwort im abgerufenen Kontext aufgetaucht?

  • Baue ein kleines Evaluierungsset: 30 bis 50 echte Fragen, jede mit der Quellpassage, die sie beantwortet.
  • Führe nur das Retrieval aus. Prüfe für jede Frage, ob die richtige Passage unter den Top-k-Ergebnissen erscheint. Diese Trefferquote ist deine Retrieval-Obergrenze.
  • Wird die richtige Passage nicht abgerufen, ist die Generierungsqualität irrelevant. Der Fix liegt beim Chunking, den Embeddings oder Top-k, nicht beim Modell.
  • Erst wenn Retrieval zuverlässig die richtige Passage liefert, macht es Sinn, daran zu arbeiten, wie das Modell sie nutzt.

Die meisten Teams überspringen das und springen direkt zum Prompt Engineering, weshalb sie so lange an einem Problem sitzen, das eine Retrieval-Trefferquoten-Messung an einem Nachmittag lokalisiert hätte. Verpasst Retrieval die Antwort in der Hälfte der Fälle, hast du ein Chunking-Problem im Modellkostüm.

Ein praktischer Ausgangspunkt

Beginne mit Semantic Chunking für allgemeine Wissensinhalte, wechsle zu Hierarchical, wenn deine Dokumente eine klare Abschnittsstruktur haben und Antworten vom umgebenden Kontext abhängen, und behalte Fixed-Size nur für große, einheitliche Prosa, bei der du Geschwindigkeit und Einfachheit willst. Miss dann die Retrieval-Trefferquote, ändere eine Variable und miss erneut. Chunking ist kein Set-and-Forget-Konfigurationswert. Es ist der Regler mit dem größten Einfluss darauf, ob dein RAG-System überhaupt gut ist.

Das Fazit

RAG-Qualität wird entschieden, bevor das Modell überhaupt läuft, in dem Moment, in dem du deine Dokumente in Chunks zerschneidest. Fixed-Size ist eine Baseline, Semantic ist die vernünftige Standardwahl für gemischte Inhalte, und Hierarchical gewinnt, wenn Struktur zählt. Miss zuerst die Retrieval-Trefferquote an einem echten Fragenset, denn wenn die Antwort nie in den Kontext gelangt, war das Modell nie das Problem.

Lesen Sie als Nächstes

Für die Storage- und Infrastrukturseite von Vector Search im großen Maßstab, die Cloud-Field-Notes sind auf ercan.cloud, und der Hub ist ercanermis.com.