Contextual Enrichment: Warum der richtige Chunk nicht reicht

Meta

• Status: Staging Draft
• Zielgruppe: CTO/CIO/CDO, Enterprise-Architekten, Data- und AI-Engineering, Security, Compliance, Wissensmanagement
• Suchintention: Verstehen, warum RAG-Systeme neben semantisch passenden Chunks auch Herkunft, Gültigkeit und Berechtigungsraum mitführen müssen
• Primäres Keyword: Contextual Enrichment
• Sekundäre Keywords: RAG Chunking, Enterprise RAG, Reranking, Kontextanreicherung, Permission-Aware Retrieval, TensorFive RAG API
• URL: /contextual-enrichment-richtige-chunk-reicht-nicht
• CTA: Technisches Architekturgespräch zur TensorFive RAG API und Contextual Enrichment in Enterprise-RAG
• Quellen: Deep Dive 02_contextual_enrichment mit chapter_contextual_enrichment.tex, findings.md, validation_report.md, literature_review.md; T5_Knowledge_API_Zusammenfassung.md; main.tex; benchmarks/scripts/adapters/enrichment_adapter.py; TensorFive RAG API Seite https://tensorfive.com/rag-api; Anthropic Contextual Retrieval https://www.anthropic.com/engineering/contextual-retrieval

• Chunk: Ein kurzer Ausschnitt aus einem Dokument, der separat gespeichert, eingebettet und bei einer Suchanfrage wiedergefunden wird.
• Contextual Enrichment: Die Anreicherung eines Chunks mit erklärendem Kontext, etwa Dokumenttitel, Abschnittspfad, Version, Nachbarschaft, Metadaten und Berechtigungen.
• Embedding: Eine numerische Repräsentation von Text, mit der semantisch ähnliche Inhalte in einer Vektordatenbank gefunden werden können.
• Reranking: Ein zweiter Sortierschritt, der bereits gefundene Treffer genauer nach Relevanz ordnet, häufig mit einem Cross-Encoder oder spezialisierten Ranking-Modell.

Ein RAG-System findet einen Policy-Chunk zu privilegierten Accounts. Der Text klingt eindeutig: privilegierte Konten müssen alle 90 Tage geprüft werden, Service-Accounts sind nur unter bestimmten Bedingungen ausgenommen, jede Ausnahme braucht eine Genehmigung. Semantisch ist das genau der Treffer, den man erwartet.

Aber aus welchem Dokument stammt dieser Chunk?

Aus der freigegebenen Security-Policy? Aus einem Entwurf der Revision? Aus einem Audit-Kommentar, der gerade eine Lücke beschreibt? Aus einer Ausnahmegenehmigung für ein einzelnes Migrationsprojekt? Oder aus einem Altbestand, der beim Umzug von SharePoint in ein neues DMS versehentlich mitindexiert wurde?

Das ist der Punkt, an dem viele RAG-Architekturen zu früh zufrieden sind. Ein Chunk ist nicht schon belastbar, weil er zur Frage passt. Er ist erst belastbar, wenn seine Herkunft mitgeführt wird: Quelle, Version, Gültigkeit, Abschnittspfad, Owner, Nachbarschaft und Berechtigungsraum.

Der richtige Chunk kann trotzdem falsche Antwort erzeugen

Nehmen wir eine Frage, wie sie in einem internen IT- oder Compliance-Chat realistisch ist:

Dürfen privilegierte Service-Accounts von der 90-Tage-Rezertifizierung ausgenommen werden?

Ein klassisches RAG-System sucht semantisch ähnliche Chunks, findet einen Treffer mit den Begriffen "privileged accounts", "recertification", "exception" und "approval", gibt ihn in den Modellkontext und lässt daraus eine Antwort erzeugen. Die Antwort kann sauber formuliert sein und trotzdem eine falsche Governance-Entscheidung unterstützen.

Das Problem ist nicht zwingend Halluzination im engeren Sinn. Das Modell muss nichts erfinden. Es kann eine Aussage korrekt aus einem unzureichend situierten Chunk ableiten. Die Fehlerquelle liegt früher: Der Chunk wurde aus seinem Herkunftsraum herausgelöst.

Ein vereinfachtes Beispiel:

... Privileged service accounts may be exempt from the 90-day recertification cycle
if the migration owner documents compensating controls and receives approval
from IAM governance. Exceptions must be reviewed after project closure. ...

Dieser Text ist nicht falsch. Aber ohne Kontext ist unklar, was er bedeutet. Er könnte eine allgemein gültige Regel beschreiben. Er könnte auch eine befristete Ausnahme aus einem Migrationsprogramm sein. Für eine KI-Antwort ist dieser Unterschied entscheidend.

Angereichert sieht derselbe Chunk anders aus:

context:
  source: "SharePoint / Security / IAM / Migration 2024"
  document: "Privileged Account Exceptions - SAP Migration"
  document_type: "Exception Record"
  version: "0.9-draft"
  validity: "2024-05-01 bis 2024-09-30"
  section_path: "Appendix B > Temporary Migration Exceptions"
  owner: "IAM Governance"
  permissions: "tenant:corp; project:sap-migration; group:iam-governance"
  previous_chunk: "Scope limited to SAP migration service users ..."
  next_chunk: "All exceptions expire automatically at project closure ..."
text: |
  Privileged service accounts may be exempt from the 90-day recertification cycle
  if the migration owner documents compensating controls and receives approval
  from IAM governance. Exceptions must be reviewed after project closure.

Jetzt ist die Antwortarchitektur eine andere. Das System kann erkennen: Dieser Chunk ist eine projektspezifische Ausnahme, kein allgemeiner Policy-Abschnitt. Es kann die Aussage nur innerhalb dieses Gültigkeits- und Berechtigungsraums verwenden oder sie gegenüber einer freigegebenen Policy niedriger gewichten.

Was beim Chunking verloren geht

Chunking ist notwendig. Große Dokumente passen nicht beliebig in Kontextfenster, Embeddings funktionieren besser mit begrenzten Einheiten, und Retrieval muss aus Millionen potenzieller Passagen schnell Kandidaten finden. Die technische Notwendigkeit ändert aber nichts am Informationsverlust.

Beim Zerlegen eines Dokuments wird Text aus einer Struktur herausgeschnitten. Der Chunk enthält vielleicht noch die Fachbegriffe, aber nicht mehr die Dokumentbiografie.

Gerade der Abschnittspfad wird unterschätzt. Ein Satz unter "Allgemeine Anforderungen" hat eine andere normative Kraft als derselbe Satz unter "Beispiele", "Audit Findings", "Open Issues" oder "Temporary Exceptions". Für Embeddings sehen diese Varianten oft ähnlich aus. Für Governance sind sie verschieden.

Warum Reranking allein das Problem nicht löst

Reranking ist wichtig. Ein gutes Ranking-Modell kann aus den ersten 50 oder 100 Retrieval-Kandidaten diejenigen nach oben ziehen, die zur Frage genauer passen. Es hilft gegen Treffer, die nur oberflächlich ähnlich sind. Es verbessert häufig die Präzision im sichtbaren Kontext.

Aber Reranking löst nicht automatisch das Herkunftsproblem.

Ein Reranker bewertet typischerweise die Passung zwischen Anfrage und Kandidat. Wenn der Kandidat nur aus Text besteht, sieht der Reranker denselben Ausschnitt wie das nachgelagerte Sprachmodell: "privilegierte Accounts", "90 Tage", "Ausnahme", "Genehmigung". Ohne Version, Abschnittspfad und Gültigkeit kann er nicht zuverlässig entscheiden, ob der Chunk eine gültige Regel, ein historischer Hinweis oder ein Audit-Kommentar ist.

Schlimmer noch: Reranking kann einen gefährlich unvollständigen Chunk nach oben sortieren, weil er sprachlich perfekt zur Frage passt. Die Relevanz steigt, aber die Belastbarkeit nicht.

Deshalb gehört Reranking hinter eine breitere Kontextstrategie. Erst müssen Kandidaten mit Herkunft, Berechtigungen und struktureller Einordnung versehen sein. Dann kann Reranking diese reicheren Kandidaten sinnvoll sortieren.

flowchart LR
    A["Dokument<br/>Policy, Entwurf, Audit, Ausnahme"] --> B["Chunking"]
    B --> C["Roh-Chunk<br/>Text ohne Herkunft"]
    C --> D["Embedding / Suche"]
    D --> E["Reranking"]
    E --> F["Antwort<br/>riskant, wenn Kontext fehlt"]

    A --> G["Contextual Enrichment"]
    G --> H["Kontext-Hülle<br/>Quelle, Version, Gültigkeit,<br/>Abschnitt, Owner, Nachbarschaft,<br/>Berechtigungsraum"]
    H --> I["Embedding / Hybrid Search"]
    I --> J["Permission Filter + Reranking"]
    J --> K["Antwort<br/>mit belastbarer Einordnung"]

Das Diagramm zeigt den Architekturunterschied: Contextual Enrichment ist kein hübscher Textzusatz am Ende. Es verändert, was indexiert, gesucht, gefiltert, gerankt und später als Quelle erklärt werden kann.

Was Contextual Enrichment wirklich bedeutet

Contextual Enrichment bedeutet nicht, einfach den Dokumenttitel vor jeden Chunk zu schreiben. Das kann helfen, ist aber nur die kleinste Variante. In Enterprise-RAG geht es um eine Kontext-Hülle, die jeden Chunk in seinen Herkunftsraum zurücksetzt.

Technisch kann diese Hülle regelbasiert, LLM-basiert oder hybrid erzeugt werden. Regelbasierte Verfahren sind schnell und deterministisch: Dateipfad, Ordnerstruktur, URL, Dokumenttyp, Position im Dokument und vorhandene Metadaten lassen sich oft ohne Modellkosten übernehmen. LLM-basierte Verfahren können zusätzlich formulieren, worum es in einem Chunk geht, wie er sich in das Gesamtdokument einordnet und welche Entitäten oder Referenzen relevant sind.

Der sinnvolle Standard ist meistens nicht "alles per LLM" oder "alles per Regex", sondern eine gestufte Architektur:

1. Struktur zuerst: Dokument-ID, Quelle, Pfad, Titel, Abschnitt, Position, Nachbarschaft und technische Metadaten werden deterministisch übernommen.
2. Governance explizit: Version, Gültigkeit, Owner, Freigabestatus und Berechtigungsraum werden als eigene Felder modelliert, nicht in Fließtext versteckt.
3. LLM gezielt: Für lange, schlecht strukturierte oder fachlich dichte Dokumente erzeugt ein Modell eine knappe Situierung des Chunks.
4. Retrieval getrennt bewerten: Der angereicherte Text kann für Embeddings und BM25 genutzt werden; die strukturierten Felder bleiben zusätzlich filter- und auditierbar.

Der letzte Punkt ist zentral. Wenn die Herkunft nur als natürlicher Satz im Chunk steht, kann sie zwar semantisch helfen, aber sie ist noch keine saubere Kontrollfläche. Ein produktionsreifes System braucht beides: erklärenden Kontext für Retrieval-Qualität und strukturierte Metadaten für Filter, Rechte, Audits und Aktualisierung.

Für den Policy-Fall heißt das: "Exception Record", "draft", "valid until 2024-09-30" und "group:iam-governance" sollten nicht nur hübsch im Kontexttext stehen. Sie müssen als Felder existieren, gegen die das System prüfen kann.

Wann es sich lohnt

Contextual Enrichment ist nicht für jedes Archiv in gleicher Tiefe notwendig. Bei einer kleinen, stabilen FAQ mit eindeutig freigegebenen Artikeln kann Titel- und Abschnittskontext genügen. Wenn die Wissensbasis klein genug ist, kann in manchen Fällen sogar ein längerer Prompt einfacher sein als ein komplexes Retrieval-System.

Je stärker aber Dokumente wachsen, Versionen wechseln und Berechtigungen differenzieren, desto wichtiger wird Enrichment. Besonders relevant ist es in sechs Situationen:

• Policies und Compliance-Dokumente: Die normative Bedeutung hängt an Freigabe, Abschnitt und Gültigkeitsdatum.
• HR, Legal, Finance und Security: Berechtigungen, Vertraulichkeit und Aktualität sind nicht Beiwerk, sondern Teil der fachlichen Wahrheit.
• Migrations- und Projektarchive: Temporäre Ausnahmen dürfen nicht wie Dauerregeln erscheinen.
• Technische Dokumentation: Version, Produktlinie, Release und Plattform entscheiden, ob eine Anleitung passt.
• Audit- und Review-Kommentare: Befunde, Empfehlungen und finale Regeln müssen auseinandergehalten werden.
• Mehrmandanten- oder Projektumgebungen: Der gleiche Begriff kann in verschiedenen Tenants, Kundenprojekten oder Datenräumen unterschiedliche Bedeutung haben.

Ein guter Daumenwert: Je häufiger ein Mensch beim Lesen fragen würde "Aus welchem Dokument ist das?", "Gilt das noch?", "Für wen gilt das?" oder "Wer hat das freigegeben?", desto eher sollte der Chunk diese Antworten maschinenlesbar mitführen.

Was die 49%-Zahl bedeutet

Die oft zitierte 49%-Zahl stammt aus Anthropics Beitrag zu Contextual Retrieval. Anthropic berichtet dort für ein spezifisches Setup eine Reduktion fehlgeschlagener Retrievals: von 5,7% Failure Rate in der Baseline auf 2,9% mit Contextual Embeddings plus Contextual BM25. Mit zusätzlichem Reranking nennt Anthropic 1,9%, also 67% weniger fehlgeschlagene Retrievals gegenüber der Baseline.

Das ist ein wichtiger Referenzwert, aber keine allgemeine Garantie.

Warum die Einordnung wichtig ist:

• Die Datensätze waren proprietär und nicht eins zu eins reproduzierbar.
• Die Metrik war Retrieval-Failure, nicht "keine Halluzinationen".
• Der Effekt hängt von Corpus, Chunking, Query-Typen, Embedding-Modell, BM25, Reranking und Baseline-Qualität ab.
• Ein besserer Retrieval-Treffer verhindert nicht automatisch falsche Antworten, wenn Gültigkeit, Rechte oder Dokumentstatus fehlen.

Interne Vorarbeiten auf einem kleinen BEIR-Natural-Questions-Setup zeigen in dieselbe Richtung, aber deutlich vorsichtiger: Regelbasiertes Enrichment verbesserte dort den Mean Reciprocal Rank um 10,9% und Recall@5 um 12,0%. Die 49%-Reduktion wurde in diesem kleinen, anders aufgebauten Experiment nicht reproduziert. Das ist kein Widerspruch zur Methode, sondern ein Hinweis auf saubere Kommunikation: Contextual Enrichment ist ein Qualitätshebel, kein Prozentversprechen und keine Halluzinationsgarantie.

Für Enterprise-Architektur ist die Prozentzahl ohnehin nicht der Kern. Der Kern ist: Chunks ohne Herkunft sind schwache Evidenz. Chunks mit Quelle, Version, Gültigkeit, Abschnittspfad, Owner, Nachbarschaft und Berechtigungsraum sind belastbarer, prüfbarer und besser auditierbar.

Fazit

Der richtige Chunk reicht nicht, wenn er aus dem falschen Kontext kommt.

RAG-Systeme werden häufig als Suchproblem diskutiert: bessere Embeddings, bessere Chunk-Größen, bessere Reranker. Diese Komponenten sind wichtig. Aber bei Unternehmenswissen entscheidet nicht nur semantische Nähe, sondern Herkunft. Ein Policy-Satz, ein Audit-Kommentar und eine temporäre Ausnahme können sprachlich fast identisch sein und fachlich völlig unterschiedliche Konsequenzen haben.

Contextual Enrichment bringt den abgeschnittenen Chunk zurück in seine Architektur: Quelle, Version, Gültigkeit, Abschnittspfad, Owner, Nachbarschaft und Berechtigungsraum. Erst damit wird aus einem Treffer eine belastbare Grundlage für eine Antwort.

Wenn Sie prüfen möchten, wie Contextual Enrichment, Permission-Aware Retrieval und Reranking in Ihrer Enterprise-RAG-Architektur zusammenspielen sollten, ist die TensorFive RAG API ein guter Ausgangspunkt für ein technisches Architekturgespräch: nicht als Prozentversprechen, sondern als konkrete Pipeline für kontrollierbare, nachvollziehbare Antworten auf Unternehmenswissen.