Chunking: So machst du Texte fit für Embeddings, RAG und Chatbots

Kurzdefinition

Chunking bedeutet, große Texte in kleinere, sinnvolle Abschnitte (Chunks) zu zerlegen, damit du daraus bessere Embeddings erzeugen und in RAG-Setups (Retrieval-Augmented Generation) zuverlässigere Antworten in deinem Chatbot bekommst.

Merksatz: Ein guter Chunk ist klein genug für präzise Suche – und groß genug, um allein verstanden zu werden.

Warum Chunking wichtig ist (Problem & Kontext)

LLMs (z. B. ChatGPT, Gemini, Mistral AI) wirken „magisch“, scheitern aber schnell, wenn sie auf deine Inhalte zugreifen sollen: Webseiten, PDFs, Wissensdatenbanken, Playbooks, Produktdokus. Ohne Chunking hast du typischerweise zwei Probleme:

• Zu große Textblöcke: Embedding- und Chat-Modelle haben Eingabelimits. Wird Text zu lang, kann er gekürzt (truncated) werden – Kontext geht verloren.
• Zu unscharfe Treffer: Wenn du ganze Kapitel oder lange Seiten am Stück „einbettest“, wird ein einzelner Vektor oft zu ungenau. Du findest dann „irgendwas Passendes“, aber nicht die beste Stelle.

Chunking ist deshalb das Fundament für brauchbare semantische Suche, Knowledge Bases und RAG-Chatbots: Es entscheidet, welche Textstellen überhaupt gefunden und in deine Prompts (den Kontext für die Antwort) eingefügt werden.

Präzise Definition

Chunking ist ein Preprocessing-Schritt, bei dem du Inhalte in kleinere Einheiten zerlegst, oft ergänzt um:

• Chunk-Größe (z. B. nach Tokens, Zeichen, Sätzen oder Absätzen)
• Overlap (Überlappung zwischen Chunks, damit Satz- oder Abschnittsgrenzen weniger Kontext verlieren)
• Metadaten (Quelle/URL, Titel, Abschnittsüberschrift, Datum, Produktkategorie, Sprache …)

Wichtig: Chunking ist nicht „Text kürzen“ oder „zusammenfassen“. Du willst nicht Inhalte verlieren, sondern Inhalte so portionieren, dass sie besser auffindbar und nutzbar werden.

Wo wird Chunking vor allem eingesetzt?

• RAG-Chatbots für Support, Sales, interne Wissensdatenbanken (Antworten mit Quellen statt Halluzinationen)
• Semantische Suche über Blogartikel, Landingpages, Dokumentationen, Notion/Confluence
• Content-Operations im Online Marketing: Content-Bibliotheken, FAQ-Automation, Konsistenzprüfung von Aussagen
• Software/Engineering: Doku-Assistenten, Code- und API-Wissenssuche, Incident-Runbooks

In vielen Pipelines ist das Standard: erst Chunks erstellen, dann Embeddings berechnen, dann in einer Vektor-Suche (Vector DB / Vector Index) abrufen – und erst dann das LLM antworten lassen.

Wie funktioniert Chunking?

Praktisch läuft es wie eine kleine Produktionsstraße:

1. Daten holen: HTML, PDF, Markdown, Google Docs, Tickets, Produktdaten.
2. Bereinigen: Navigation, Footer, Cookie-Banner, Dubletten entfernen; Encoding/Zeilenumbrüche normalisieren.
3. Splitten: Nach Regeln (z. B. Überschriften → Absätze → Sätze) oder nach fester Länge.
4. Overlap hinzufügen: Optional ein „Sliding Window“, damit Randbereiche nicht abreißen.
5. Metadaten anreichern: Titel/Section/URL/Tags/„last_updated“ mitschreiben.
6. Embeddings erzeugen: Jeder Chunk wird in einen Vektor umgewandelt und gespeichert.
7. RAG-Abruf: Nutzerfrage → Query-Embedding → ähnliche Chunks finden → als Kontext in den Prompt → Antwort generieren.

Chunk-Größe & Overlap: ein sinnvoller Startpunkt

Es gibt keine „eine richtige Zahl“. Gute Chunking-Parameter hängen ab von:

• Texttyp (FAQ vs. Blog vs. technische Doku)
• Suchziel (präzise Snippets vs. erklärende Passagen)
• Modell-/Pipeline-Limits (Tokens, Kosten, Latenz)

Als konkrete Orientierung (und explizit als Startpunkt, nicht als Gesetz) nennen Plattformen wie Microsoft z. B. feste Chunking-Ansätze mit Overlap, um Token-Limits einzuhalten und Kontextverlust zu reduzieren.

Tools/Frameworks, die du in der Praxis oft siehst

• LangChain Text Splitters (z. B. Recursive Splitting): LangChain: Text splitters
• LlamaIndex Node Parsers (z. B. SentenceSplitter): LlamaIndex: Node Parsers / Text Splitters

Was sind die Vorteile?

• Mehr relevante Treffer: Du findest die eine Passage, die die Frage wirklich beantwortet (statt „das ganze Kapitel“).
• Weniger Halluzinationen im RAG-Chatbot: Das LLM bekommt gezielten, prüfbaren Kontext.
• Geringere Kosten & schnellere Antworten: Du verarbeitest kleinere Einheiten statt riesige Dokumente.
• Bessere Wartbarkeit: Du kannst Inhalte gezielt aktualisieren (nur betroffene Chunks neu einbetten).
• Sauberere Quellenangaben: Mit Metadaten kann dein Chatbot auf Abschnitt/URL verweisen.

Warum ist das wichtig für dich (Im Online Marketing & Business)?

Wenn du Leads, Kundenfragen oder interne Abläufe effizienter machen willst, ist Chunking ein Hebel mit direktem Business-Nutzen:

• Website-Chatbot, der wirklich hilft: Er beantwortet Fragen zu Leistungen, Preisen, Cases – basierend auf deinen Seiten, nicht auf Bauchgefühl.
• Content-Reuse: Du findest schnell passende Textbausteine für Kampagnen, Ads, Landingpages und Newsletter (semantisch, nicht nur per Keyword).
• Konsistenz: Du kannst Aussagen aus unterschiedlichen Quellen (Blog vs. FAQ vs. Produktseite) abgleichen, weil sie granular auffindbar sind.

Praxisbeispiele (konkret)

Beispiel 1 (Online Marketing): RAG-Chatbot für eine Leistungsseite + FAQ

Du hast eine Agentur-Website mit „SEO“, „Google Ads“, „Tracking“ und einer FAQ. Vorgehen:

• Chunking nach H2/H3-Überschriften (Leistungsblöcke) + Absätzen
• Metadaten: service=seo, page=/leistungen/seo, section=Preise, last_updated
• Im Chatbot-Prompt: „Antworte nur mit Kontext, zitiere Abschnitt/URL“

Effekt: Fragen wie „Was kostet SEO?“ ziehen gezielt den Preis-/Leistungsabschnitt statt die komplette Seite.

Beispiel 2 (Online Marketing): Content-Bibliothek für Kampagnenplanung

Du speicherst 100 Blogposts, Case Studies und Webinar-Transkripte. Du chunkst nach Absätzen und packst die Überschrift in jeden Chunk (als Zusatzzeile). Dann kannst du semantisch suchen:

• „Beispiele für Retargeting im B2B“
• „Argumente gegen Tool-Wildwuchs“

Das ist schneller als Ordner klicken oder reine Keyword-Suche – vor allem bei ähnlichen Begriffen und Synonymen.

Beispiel 3 (Software): Doku-Assistent für eine API (Markdown + Codeblöcke)

Du hast eine API-Dokumentation in Markdown. Gute Chunking-Regeln:

• Chunking nach Überschriften (Endpoint pro Chunk) und Codeblöcke separat
• Metadaten: endpoint=/v1/orders, method=POST, version=v2

Wenn ein Entwickler fragt „Wie setze ich Pagination?“, landet er im Chunk „Pagination“, nicht in der gesamten Doku.

Beispiel 4 (Software/Operations): Incident-Runbook als ChatGPT-Assist

Runbooks sind oft Schritt-für-Schritt. Chunking nach „Symptom → Diagnose → Fix“ funktioniert meist besser als fixe Zeichenlängen. So kann das LLM konkrete Handlungsanweisungen aus dem passenden Abschnitt ziehen.

Häufige Missverständnisse / Fehler (und wie du sie vermeidest)

• „Ich embedde einfach ganze Dokumente.“ Ergebnis: unscharfe Treffer. Besser: thematisch geschlossene Chunks.
• Chunks ohne Kontext (z. B. „Ja, das ist möglich.“). Lösung: Überschrift/Titel als Präfix in den Chunk aufnehmen.
• Boilerplate wird mit eingebettet (Navigation, Footer, Cookie-Hinweise). Lösung: HTML sauber extrahieren (Main-Content) und wiederkehrende Blöcke filtern.
• Kein Overlap, harte Schnitte: Wichtige Sätze reißen auseinander. Lösung: kleiner Overlap oder Splitting nach Sätzen/Absätzen.
• Zu viel Overlap: Du speicherst Duplikate, Retrieval wird „spammy“. Lösung: Overlap sparsam starten, Ergebnis prüfen.
• Keine Metadaten: Du findest Text, aber nicht die Quelle. Lösung: URL/Section/Datum konsequent mitschreiben.
• Keine Evaluation: „Fühlt sich ok an“ reicht nicht. Lösung: 20 echte Fragen sammeln und prüfen, ob die Top-Chunks wirklich passen.

Best Practices: Checkliste für gutes Chunking

• Ziel klären: FAQ-Chatbot, Sales-Assist, interne Suche? (Das bestimmt Chunk-Größe und Struktur.)
• Struktur nutzen: Erst nach Überschriften, dann Absätze, dann Sätze splitten (statt blind nach Zeichen).
• „Macht allein Sinn?“ Jeder Chunk sollte ohne Nachbartext verständlich sein.
• Overlap bewusst einsetzen: Nur so viel, dass Ränder nicht abreißen – nicht mehr.
• Metadaten standardisieren: source, title, section, tags, last_updated, language.
• HTML/PDF sauber extrahieren: Header/Footer/Navigation entfernen, Tabellen/Listen korrekt übernehmen.
• Getrennte Behandlung: Codeblöcke, Tabellen, FAQ-Frage+Antwort als Einheit – nicht zerstückeln.
• Iterativ verbessern: Retrieval-Logs anschauen, Fehlgriffe markieren, Split-Regeln anpassen.

Wenn du Frameworks nutzt: Starte mit bewährten Splittern (z. B. LangChain Recursive Splitting) und passe nur an, wenn du konkrete Probleme siehst.

Fazit + nächster Schritt

Chunking ist der Hebel, der aus „LLM kann reden“ ein System macht, das deine Inhalte zuverlässig findet und in RAG-Chatbots nutzbar macht. Wenn du Embeddings, RAG oder einen Chatbot für Website/Support planst, ist Chunking keine Option, sondern Pflicht.

Nächster Schritt: Nimm 1–2 deiner wichtigsten Seiten (z. B. „Leistungen“ + „FAQ“), chunk sie nach Überschriften/Absätzen, generiere Embeddings, teste 20 echte Nutzerfragen und prüfe die Top-3 Treffer pro Frage. Optimieren erst danach.

Mini-Glossar verwandter Begriffe

• Embeddings: Vektoren, die die Bedeutung von Text repräsentieren und semantische Suche ermöglichen. OpenAI: Vector embeddings
• RAG (Retrieval-Augmented Generation): Pipeline aus Retrieval (Chunks finden) + Generation (LLM antwortet mit Kontext).
• Vektor-Datenbank / Vector Index: Speichert Embeddings und findet ähnliche Vektoren (Nearest Neighbor Search).
• Token: „Text-Bausteine“, in denen Modelle rechnen; relevant für Limits und Chunk-Größe.
• Kontextfenster: Maximale Token-Menge, die ein Modell auf einmal verarbeiten kann.
• Text Splitter / Node Parser: Tool/Komponente, die Chunking-Regeln umsetzt (z. B. LangChain, LlamaIndex).
• Overlap (Sliding Window): Überlappung zwischen Chunks, um Kontext an Rändern zu erhalten.
• Metadaten: Zusatzinfos pro Chunk (URL, Abschnitt, Tags), wichtig für Quellen und Filter.
• Semantic Chunking: Chunk-Grenzen orientieren sich an inhaltlichen Übergängen statt fixer Länge.