Die Chunk-Größe entscheidet mehr als das Modell
Wie aus Dokumenten Vektoren werden, was Überlappung und Dimension wirklich kosten und warum die teuerste Position einer RAG-Anwendung nicht der Speicher ist, sondern der abgerufene Kontext.
Was beim Zerlegen passiert
Retrieval-Augmented Generation klingt nach einer Modellfrage und ist eine Datenfrage. Der Ablauf ist immer derselbe: Dokumente in Stücke zerlegen, jedes Stück in einen Vektor übersetzen, bei einer Anfrage die ähnlichsten Stücke suchen und dem Sprachmodell mitgeben.
Die einzige echte Entwurfsentscheidung darin ist die Größe der Stücke. Sie bestimmt, wie viele Vektoren entstehen, wie präzise die Suche trifft, wie viel Zusammenhang das Modell bekommt und was jede einzelne Anfrage kostet. Alles andere – Datenbankwahl, Einbettungsmodell, Indexverfahren – ist demgegenüber zweitrangig.
Ein Beispiel: 1.000 Dokumente mit im Mittel 5.000 Token ergeben fünf Millionen Token. Bei 512 Token Chunk-Größe und 15 Prozent Überlappung beträgt die Schrittweite 435 Token – daraus werden rund 11.500 Chunks, nicht die knapp 9.800, die ohne Überlappung entstünden. Jedes Token wird im Mittel 1,18-mal gespeichert und eingebettet.
Rechner: Chunks, Speicher und Kontextkosten
Bestand, Chunk-Größe, Dimension und Zahlenformat eintragen – der Rechner liefert die Anzahl der Chunks, den Speicherbedarf getrennt nach Vektoren, Index und Text sowie die laufenden Kontextkosten.
Wissensbestand
Abfrage und Index
Der Zielkonflikt bei der Chunk-Größe
Ein Vektor ist eine Zahl gewordene Zusammenfassung. Genau daraus folgt der Konflikt:
| kleine Chunks (128 – 256) | große Chunks (1024 – 2048) | |
|---|---|---|
| Trefferpräzision | hoch – ein Vektor, ein Gedanke | unscharf – viele Aussagen gemittelt |
| Zusammenhang für das Modell | bruchstückhaft | vollständig |
| Anzahl Vektoren | hoch | niedrig |
| Kontextkosten je Anfrage | niedrig | hoch |
| Gefahr | Antwort ohne Kontext | Antwort mit Beiwerk |
Die Verdünnung bei großen Chunks ist der unterbewertete Effekt. Ein Abschnitt von 2.000 Token behandelt selten nur ein Thema. Sein einzelner Vektor liegt dann irgendwo zwischen allen behandelten Themen – und damit näher an vielen Anfragen, aber nah genug an keiner. Die Suche liefert Ergebnisse, die zu allem ein bisschen passen.
Der übliche Ausweg ist, die beiden Anforderungen zu trennen: klein suchen, groß ausliefern. Eingebettet und durchsucht werden kleine Abschnitte; übergeben wird der Treffer zusammen mit seinen Nachbarn oder dem umgebenden Kapitel. Das kostet etwas Verwaltung in den Metadaten und löst beide Probleme auf einmal.
Konkrete Startwerte kann man nennen – 256 bis 512 Token für Fakten- und Handbuchtexte, größer bei zusammenhängender Prosa – aber sie ersetzen keine Messung. Chunk-Größe ist ein Parameter, den man an echten Fragen misst, nicht aus einer Empfehlung übernimmt.
Überlappung: was sie kostet
Überlappung existiert gegen ein einziges Problem: Ein Satz, der genau an der Schnittstelle steht, würde sonst in beiden Nachbarn nur halb vorkommen. Der Preis dafür ist Vervielfachung.
Dieser Faktor wirkt dreifach: auf den Speicher, auf die einmaligen Einbettungskosten des Bestands und auf jede spätere Neuindizierung. Bei 50 Prozent Überlappung zahlt man alles doppelt.
Zehn bis zwanzig Prozent sind der übliche Bereich. Deutlich mehr lohnt sich in aller Regel nicht – wer an Schnittstellen Probleme hat, fährt besser damit, an sinnvollen Grenzen zu trennen: an Überschriften, Absätzen oder Listenpunkten statt nach fester Tokenzahl. Ein Chunking, das die Struktur des Dokuments kennt, braucht kaum Überlappung.
Dimension und Zahlenformat
Jeder Vektor belegt Dimension × Bytes je Zahl. Bei 1.536 Dimensionen in float32 sind das 6,0 kB – je Chunk, nur für den Vektor.
| Format | je Dimension | bei 1536 Dim. | Faktor |
|---|---|---|---|
| float32 | 4 Byte | 6,0 kB | 1,0 × |
| float16 | 2 Byte | 3,0 kB | 2 × kleiner |
| int8 | 1 Byte | 1,5 kB | 4 × kleiner |
| binär | 1 Bit | 192 Byte | 32 × kleiner |
Der Sprung ist erheblich, und er kostet weniger Genauigkeit als man erwartet – die Verfahren sind darauf ausgelegt, die Rangfolge der nächsten Nachbarn zu erhalten, nicht die exakten Abstände. Ein übliches Vorgehen ist zweistufig: grob mit stark komprimierten Vektoren vorsortieren, dann die besten hundert Kandidaten mit den vollen Vektoren neu ordnen. Das verbindet den kleinen Index mit der genauen Rangfolge.
Bei der Dimension gilt: Mehr Dimensionen trennen besser, kosten aber linear Speicher und Suchzeit. Viele neuere Einbettungsmodelle erlauben es, den Vektor hinten abzuschneiden – die wichtigsten Informationen stehen dann vorn, und aus 1.536 Dimensionen lassen sich 768 machen, ohne neu einzubetten. Ob das für das eingesetzte Modell gilt, steht in dessen Dokumentation.
Der Posten, den niemand einplant
Speicher ist bei RAG selten das Problem. 11.500 Chunks passen in unter hundert Megabyte – das kostet nichts, was der Rede wert wäre.
Teuer ist die Abfrage. Jede Anfrage übergibt dem Sprachmodell die gefundenen Chunks, und jedes dieser Token wird bezahlt – bei jeder einzelnen Anfrage, dauerhaft.
bei 1.000 Anfragen am Tag und 5 USD je Million Input-Token:
384 USD im Monat – nur für den abgerufenen Kontext
Dazu kommen System-Prompt, Frage und Antwort. Wer top-k von 5 auf 10 erhöht, weil das die Trefferquote hebt, verdoppelt diesen Posten – und bekommt oft schlechtere Antworten, weil zusätzliches Beiwerk vom Passenden ablenkt.
Hier hilft dieselbe Technik wie bei jeder anderen Anwendung: Was sich zwischen Anfragen nicht ändert, gehört in den Prompt-Cache – System-Prompt und Werkzeuge davor, die wechselnden Chunks danach. Wie das rechnet, steht im Beitrag zu LLM-API-Kosten.
Was Chunking allein nicht löst
Drei Punkte, an denen reine Vektorsuche regelmäßig scheitert – unabhängig davon, wie gut die Chunks geschnitten sind.
Exakte Begriffe. Artikelnummern, Fehlercodes, Eigennamen und Versionsangaben findet eine Vektorsuche schlecht, weil sie auf Bedeutungsähnlichkeit optimiert ist und nicht auf Zeichenketten. Eine Suche nach „Fehler E-217“ liefert Abschnitte über ähnliche Fehler. Die Abhilfe ist eine hybride Suche: klassische Volltextsuche und Vektorsuche parallel, die Ergebnisse zusammengeführt. Das ist bei technischen Wissensbeständen kein Zusatz, sondern Grundausstattung.
Rangfolge. Der ähnlichste Vektor ist nicht immer die beste Antwort. Ein nachgeschaltetes Modell, das die zwanzig besten Kandidaten gegen die konkrete Frage bewertet, hebt die Qualität spürbar – zu überschaubaren Kosten, weil es nur auf wenigen Kandidaten arbeitet.
Zugriffsrechte und Aktualität. Ein Wissensbestand im Unternehmen ist nie für alle gleich. Rechte gehören als Metadaten an den Chunk und in den Filter der Suche – nicht in eine nachträgliche Prüfung der Antwort. Dasselbe gilt für Versionsstände: Ein Chunk aus einem überholten Handbuch ist schlimmer als kein Treffer, weil er plausibel klingt.
Checkliste
1. An echten Fragen messen, nicht an Beispielen. Zwanzig bis fünfzig reale Fragen mit bekannter richtiger Quelle sind die Grundlage jeder Entscheidung über Chunk-Größe und top-k.
2. An Strukturgrenzen trennen, nicht nach fester Tokenzahl. Überschriften, Absätze, Tabellen – ein Chunking, das die Dokumentstruktur kennt, spart Überlappung.
3. Klein suchen, groß ausliefern. Die Größe für die Einbettung und die Größe für die Übergabe an das Modell müssen nicht dieselbe sein.
4. Hybride Suche von Anfang an. Sie nachträglich einzubauen bedeutet, den Index neu aufzubauen.
5. Metadaten mitführen – Quelle, Abschnitt, Version, Rechte, Datum. Sie kosten kaum Speicher und entscheiden später darüber, ob die Anwendung im Unternehmen einsetzbar ist. Nachträglich hinzufügen heißt neu einbetten.
RAG-Systeme im Unternehmen aufbauen
Wir bauen Wissensdatenbanken mit semantischer Suche – von der Aufbereitung der Dokumente über Chunking, hybride Suche und Rechtefilter bis zur Auswertung an echten Fragen. Einschließlich der Frage, welche Teile überhaupt in ein Sprachmodell gehören und welche eine klassische Suche besser bedient.
Auch als Prüfung bestehender Systeme: Wenn ein Dokumenten-Chatbot häufig danebenliegt, liegt es fast immer am Abruf, nicht am Modell. Das Erstgespräch ist unverbindlich.
Telefon: +49 (0) 176 820 42391
Weiterlesen
LLM-Token-Verbrauch & API-Kosten kalkulieren – was die abgerufenen Chunks im laufenden Betrieb kosten und wie Caching darauf wirkt.
KI für Ihr Unternehmen
Alle Engineering Guides
Der Rechner schätzt den Indexspeicher als M · 2 Nachbarn je Knoten zu 4 Byte und den Textspeicher mit 4 Byte je Token. Beides sind Näherungen – die tatsächlichen Werte hängen von der eingesetzten Datenbank, ihrer Kompression und der gewählten Indexstruktur ab. Speicherangaben für Vektoren sind dagegen exakt, sie folgen unmittelbar aus Dimension und Zahlenformat.