Chunking
Chunking zerlegt ein Dokument in kleinere Abschnitte, die separat eingebettet, indexiert und bei Bedarf abgerufen werden können. In RAG-Systemen bilden solche Passagen die unmittelbare Brücke zwischen einer Wissensbasis und dem Kontext eines Sprachmodells.1 Ein Chunk ist daher keine bloße Längeneinstellung, sondern die kleinste praktische Einheit, an der Inhalt, Herkunft und Zugriff für den Abruf zusammenkommen.
Einordnung
Chunking ist vom Retriever zu trennen. Chunking bestimmt, welche Einheiten verfügbar sind; der Retriever entscheidet anschließend, welche davon zur Anfrage passen und in den Kontext gelangen. Eine ungünstige Segmentierung kann die fachliche Aussage eines Dokuments auseinanderreißen, widersprüchliche Passagen zusammenführen oder Kontext ohne ausreichenden Herkunftshinweis liefern. Für die Sicherheit folgt daraus: Die Berechtigung des Ursprungsdokuments darf beim Zerlegen nicht verlorengehen.
OWASP empfiehlt, Daten in der Wissensbasis zu kennzeichnen und zu klassifizieren, um Zugriffsebenen und Fehlzuordnungen zu steuern.2 Praktisch heißt das, dass jedes abrufbare Segment die erforderlichen Metadaten erben muss, etwa Mandant, Quelle, Dokumentversion, Datenklasse und Freigabestatus. Die Entscheidung gehört in den Abrufpfad. Eine Anzeigeprüfung nach der Generierung ist zu spät, falls ein unzulässiger Abschnitt bereits in den Modellkontext übernommen wurde.
Dokumentiertes Beispiel
Die USENIX-Studie PoisonedRAG dokumentiert, dass die Wissensdatenbank eines RAG-Systems als Angriffsfläche fungieren kann und dass manipulierte Texte unter den getesteten Bedingungen in den Kontext einer Zielanfrage gelangen können.3 Die Studie ist keine Untersuchung einer bestimmten Chunking-Strategie und erlaubt deshalb keine Aussage, welche Abschnittslänge „sicher“ sei. Sie zeigt aber die Sicherheitsbedeutung der Abrufeinheit: Was als indexierbarer Textbestandteil aufgenommen wird, kann später als Kontext wirken. OWASP ergänzt dieses Bild mit einem veröffentlichten Szenario, in dem nicht erkannter verborgener Inhalt in ein RAG-Wissenssystem gelangt; die empfohlene Gegenmaßnahme ist Validierung vor der Aufnahme.4
Bedeutung für die Abwehr
Chunking-Design muss neben Antwortqualität auch Datenschutz und Integrität prüfen. Segmente sollten an nachvollziehbaren Dokumentgrenzen erzeugt werden, ihre Herkunft lückenlos vererben und niemals Berechtigungen aus benachbarten Abschnitten ableiten. Vor dem Indexieren sind extrahierte Inhalte sowie Metadaten zu validieren; beim Retrieval werden Rechte und Vertrauensklasse pro Segment durchgesetzt. Protokolle sollten festhalten, welches Segment aus welcher Dokumentversion in welchen Prompt aufgenommen wurde. So wird aus Chunking keine unkontrollierte Kontextzerlegung, sondern eine überprüfbare Sicherheitsgrenze.
Quellen
- Lewis, Patrick et al., „Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks“, 12. April 2021, https://arxiv.org/abs/2005.11401 ↩
- OWASP, „LLM09:2026 Vector and Embedding Weaknesses“, 3. August 2026, https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/ ↩
- Zou, Wei; Geng, Runpeng; Wang, Binghui; Jia, Jinyuan, „PoisonedRAG: Knowledge Corruption Attacks to Retrieval-Augmented Generation of Large Language Models“, 2025, https://www.usenix.org/conference/usenixsecurity25/presentation/zou-poisonedrag ↩
- OWASP, „LLM09:2026 Vector and Embedding Weaknesses“, 3. August 2026, https://github.com/OWASP/www-project-top-10-for-large-language-model-applications/blob/main/2_0_vulns/LLM08_VectorAndEmbeddingWeaknesses.md ↩