Entity-Aware Index Enrichment

Die Arbeit mit LLM, bedeutet vor allem: Arbeit mit Sprache. Und auch bei RAG-Architekturen – sofern Vektor-Datenbanken im Spiel sind – ist Sprache das zentrale Element, das es zu verstehen gilt. Es ergibt daher Sinn, einen Blick in die Linguistik zu werfen, um die strukturellen Eigenschaften von Sprache zu verstehen.

Naive RAG setzt auf einen einzigen Retrieval-Kanal: Vektor-Suche über Embeddings. Das funktioniert gut für semantische Ähnlichkeit – „offene Forderung” findet „nicht bezahlte Rechnung” – versagt aber bei spezifischen, eindeutigen Bezeichnern. Eine Artikelnummer wie ART-4471-B hat im Vektorraum keine sinnvolle Nachbarschaft. Sie ist ein Punkt im Nirgendwo, umgeben von Rauschen.

Die Standardantwort der RAG-Community ist Hybrid Search: Ein zweiter Kanal – lexikalische Suche via BM25 über invertierte Indizes (z.B. PostgreSQL tsvector) – wird parallel abgefragt. Beide Ergebnislisten werden über Reciprocal Rank Fusion (RRF) oder vergleichbare Verfahren fusioniert.

Es lohnt sich m.E. an dieser Stelle weiter zu denken und zwar nicht technisch, sonder inhaltlich.

Die linguistische Begründung

Die entscheidende Achse für Information Retrieval ist die der lexikalischen Opazität: Wie viel Bedeutung trägt die Zeichenfolge selbst, und wie viel ist erst aus dem Kontext erschließbar? Das ist kein neuer Gedanke – die Unterscheidung zwischen opaken und transparenten Ausdrücken gehört zum Kernbestand der lexikalischen Semantik (Cruse, Lexical Semantics, 1986).

Transparente Ausdrücke tragen ihre Bedeutung in der Form. „Handschuh” setzt sich kompositionell aus „Hand” und „Schuh” zusammen, „Zahlungsverzug” aus „Zahlung” und „Verzug”. Wer die Bestandteile kennt, kann die Gesamtbedeutung ableiten. Die Form stützt die Bedeutung, und der Ausdruck steht in einem dichten Netz von Verwandtschaften – semantisch wie lexikalisch.

Opake Ausdrücke sind das Gegenteil. Die Bedeutung ist an die Zeichenfolge konventionell gekoppelt, aber nicht aus ihr erschließbar. Eigennamen sind der klassische Fall: „Berlin” verrät nichts über die Stadt. Codes und Identifikatoren sind maximal opak – ART-4471-B referiert exakt auf einen Artikel, aber die Form trägt keinerlei Fragmente, die auf den Artikel hindeuten.

Opake Bezeichner

ART-4471-B (Artikelnummer), P-2024-118 (Projektnummer), § 437 BGB (Gesetzesparagraph), Hoffmann & Söhne GmbH (Firmenname), DE89370400440532013000 (IBAN), SKU-8827 (Stock Keeping Unit).

Diese Bezeichner sind opak im starken Sinn: Wer die Konvention nicht kennt, kann aus der Zeichenfolge nichts ableiten. Sie funktionieren wie Eigennamen – ihre Referenz ist fixiert, aber nicht aus der Form erschließbar.

Ein Embedding-Modell hat für solche Zeichenfolgen keine sinnvolle Repräsentation. Es wurde auf natürlicher Sprache trainiert, in der Wörter in Kontexten auftreten, die ihre Bedeutung konstituieren. ART-4471-B hat im Trainingskorpus keinen solchen Kontext – genauso wenig wie Hoffmann & Söhne GmbH als Zeichenfolge etwas über die Firma verrät. Die resultierenden Vektoren sind bestenfalls zufällig positioniert, schlimmstenfalls aktiv irreführend.

Transparente Begriffe

Die Zeichenfolge trägt Bedeutung, steht in Beziehung zu anderen Begriffen, hat ein semantisches Umfeld.

Zahlungsverzug (verwandt mit: Mahnung, Frist, Forderung), Gewährleistung (verwandt mit: Mangel, Nachbesserung, Rücktritt), Lieferbedingung (verwandt mit: Incoterms, Transport, Gefahrübergang), Rahmenvertrag (verwandt mit: Laufzeit, Abruf, Konditionen).

Diese Begriffe leben im semantischen Raum, in dem Embedding-Modelle zuhause sind. Auch ohne konkreten Kontext kann ein kompetenter Sprecher (und ein Embedding-Modell) Verwandtschaften und Nachbarschaften erschließen.

Die Konsequenz für Retrieval

Die Opazitätsachse spiegelt die Stärken der beiden Retrieval-Kanäle:

Ausdruckstyp	BM25 (lexikalisch)	Embedding (semantisch)
Opaker Bezeichner (ART-4471-B)	Exakter Token-Match	Kein sinnvoller Vektor
Transparenter Begriff (Zahlungsverzug)	Exakter Match (wenn Term vorkommt)	Semantische Nachbarschaft
Semantisches Konzept (offene Forderung)	Nur bei lexikalischer Überlappung	Kernkompetenz

Das ist die eigentliche Begründung für Hybrid Search: Es geht nicht um Redundanz oder „zwei Meinungen einholen”. Es geht darum, dass natürliche Sprache strukturell verschiedene Ausdruckstypen enthält, die unterschiedliche Retrieval-Mechanismen erfordern.

BM25 ist der Anker für die symbolische Welt. Embeddings sind die Brücke in der semantischen Welt. Beide zusammen decken das Spektrum ab – aber nur wenn man die Stärken beider Kanäle auch gezielt bedient.

Die Opazitätsachse ist eine inhärente Eigenschaft des Zeichens. Ob ein Embedding-Modell einen opaken Bezeichner trotzdem verarbeiten kann, ist eine kontingente Eigenschaft – sie hängt davon ab, ob und wie oft der Ausdruck im Trainingskorpus in bedeutungsstiftenden Kontexten vorkam. Beides korreliert meist, aber nicht immer. ISO 9001 ist formal opak, aber im Web millionenfach eingebettet – das Embedding-Modell hat hier Signal. Ein interner Produktcode ist opak und unbekannt; der resultierende Vektor ist Rauschen. Faustregel: Opazität ist der Indikator, Korpus-Abdeckung entscheidet.

Die Dichotomie hat eine weitere Grenze. ART-4471-B und ART-4472-B sind beide opak – linguistisch gleichwertig. In der Praxis sind sie wahrscheinlich Varianten desselben Produkts, und Nutzer:innen erwarten diese Nachbarschaft („zeig mir ähnliche Artikel”). Weder BM25 (kein unscharfes Präfix-Matching) noch Embedding (kein Signal) liefern das sauber. Strukturelle Ähnlichkeit zwischen opaken Bezeichnern gehört nicht in einen der beiden Retrieval-Kanäle, sondern in eine eigene Schicht: Produktgraph, Metadaten-Modell, regelbasiertes fuzzy matching über bekannte Code-Muster.

Das Chunk-Problem und der Stand der Technik

Hybrid Search allein löst ein fundamentales Problem nicht: Chunks sind Fragmente. Ein typisches Angebotsdokument enthält die Artikelnummer vielleicht einmal in der Kopfzeile und den Kundennamen im Briefkopf. Der Rest des Dokuments – Konditionen, Lieferbedingungen, Zahlungsziele – referenziert diese Entitäten implizit, ohne sie lexikalisch zu wiederholen.

Wenn das Dokument in Chunks zerlegt wird, geht diese implizite Zuordnung verloren. Chunk 5 handelt von Zahlungsbedingungen, aber der Kundenname aus dem Briefkopf und die Artikelnummer aus Chunk 1 sind nicht mehr erreichbar. Ein BM25-Query nach Hoffmann & Söhne oder ART-4471-B findet den Kopf-Chunk, aber nicht die inhaltlich relevanten Abschnitte. Die semantisch wichtigste Information bleibt unsichtbar.

Die Lösung ist Entity Propagation beim Ingestion: Entitäten, die beim Chunking verloren gehen würden, werden explizit an jeden Chunk des Dokuments angehängt – als Metadata, als zusätzlicher Text, oder beides.

Anthropics Contextual Retrieval

Anthropics Contextual Retrieval (2024) adressiert das Chunk-Problem mit einem eleganten Ansatz: Ein LLM-Call pro Chunk erzeugt eine kurze kontextuelle Erklärung, die dem Chunk vorangestellt wird – sowohl für das Embedding als auch für den BM25-Index.

Ein Chunk wie „Zahlung innerhalb von 30 Tagen netto” wird angereichert zu: „Dieser Abschnitt stammt aus dem Angebot AN-2024-118 für die Hoffmann & Söhne GmbH und beschreibt die Zahlungskonditionen. Zahlung innerhalb von 30 Tagen netto.”

Das funktioniert — Anthropic berichtet eine Reduktion der Retrieval-Fehlerrate um 49%.

Der im Folgenden skizzierte Ansatz baut auf demselben Grundprinzip — Anreicherung beim Ingestion — auf und ergänzt zwei Differenzierungen, die direkt aus der Opazitäts-Achse folgen:

Eine Anreicherung für zwei Indizes. Bei Contextual Retrieval fließt der generierte Kontexttext identisch in Embedding- und BM25-Index. Die Opazitäts-Achse legt einen feineren Schnitt nahe: Opake Bezeichner stärken den BM25-Kanal, transparente Begriffe den Embedding-Kanal — jede Entität dort, wo sie ihren Wert entfaltet.

Narrative statt strukturierter Form. Der LLM-Call erzeugt einen Kontextsatz – und Kontextsätze sind selektiv. Die Haupt-Artikelnummer wird erwähnt, fünf Neben-Artikelnummern aus der Positionsliste eher nicht — für eine narrative Zusammenfassung sind sie nicht zentral. Eine strukturierte Extraktion erfasst gerade diese opaken Bezeichner systematisch, die in der narrativen Form leicht durchrutschen.

Entity-Aware Index Enrichment

Hier setzt das zentrale Konzept an: Die Entity Extraction beim Ingestion identifiziert nicht nur welche Entitäten in einem Dokument vorkommen, sondern klassifiziert sie nach ihrem Ausdruckstyp. Diese Klassifikation steuert, wie die extrahierten Entitäten in die bestehenden Indizes eingespeist werden – nicht als narrative Zusammenfassung, sondern als strukturierte, typengerechte Anreicherung.

Der eigentliche Architekturmove ist die asymmetrische Optimierung. BM25 und Embedding haben entgegengesetzte Fehlerprofile: Ein überflüssiger Term im BM25-Index ist folgenlos, jeder irrelevante Begriff im Embedding-Input verschiebt den Vektor. Folglich muss der Extraction-Schritt zwei unterschiedliche Ziele bedienen – Recall für den lexikalischen Kanal, Precision für den semantischen. Das gelingt nicht mit einem generischen Prompt, sondern mit zwei spezialisierten Calls, jeweils auf ihr Zielsystem hin zugeschnitten.

Stufe 1 – Typklassifikation und Propagation

Der BM25-Index wird geschärft, weil opake Bezeichner – Artikelnummern, Firmennamen, Projektkürzel – an jeden Chunk propagiert werden. Ein Query nach Hoffmann & Söhne oder ART-4471-B matcht jetzt nicht nur den einen Chunk, in dem der Name oder die Nummer steht, sondern jeden Chunk des zugehörigen Dokuments. Der lexikalische Index gewinnt Reichweite, ohne an Präzision zu verlieren.

Der Embedding-Index wird geschärft, weil transparente Fachbegriffe – die zentralen Konzepte des Dokuments – als zusätzlicher Kontext in den Embedding-Input jedes Chunks einfließen. Ein Chunk, der nur „Zahlung innerhalb von 30 Tagen netto” enthält, bekommt den extrahierten Begriff „Zahlungsverzug” als Kontext dazu. Der Vektor dieses Chunks rückt näher an verwandte Konzepte im semantischen Raum – Mahnung, Forderung, Fristüberschreitung – und wird auffindbar für Queries, die semantisch verwandt, aber lexikalisch verschieden formuliert sind.

Der entscheidende Strukturvorteil gegenüber undifferenzierter Anreicherung: Weil jede Entität nur dort landet, wo sie Wert stiftet, kann die Extraction aggressiver werden. Bei Contextual Retrieval muss man konservativ bleiben – zwanzig Identifikatoren (Artikelnummern, Projektkürzel, Firmennamen) an jeden Chunk propagieren würde den Embedding-Input zumüllen. Bei typengerechter Anreicherung landen die zwanzig Nummern nur im BM25-Text. Der Embedding-Input bleibt sauber. Die Differenzierung hebt die Obergrenze für die Extraction-Tiefe an.

Stufe 2 – Spezialisierte Extraction

Hier wird die asymmetrische Optimierung konkret. BM25 ist tolerant gegenüber false positives – ein überflüssiger Term im Index schadet dem Ranking kaum. Embedding ist intolerant gegenüber false positives: Jeder irrelevante Begriff im Embedding-Input verschiebt den resultierenden Vektor.

Daraus folgt die Zwei-Call-Architektur: Call 1 – Symbol Extraction (Ziel: BM25) optimiert auf Recall. Auch Neben-Artikelnummern, Unter-Projektnummern, referenzierte Normen – alles, was ein Nutzer als exakten Suchbegriff eingeben könnte. Call 2 – Concept Extraction (Ziel: Embedding) optimiert auf Precision. Nur Begriffe, die den Vektor in eine semantisch sinnvolle Richtung verschieben.

Mit Prompt Caching auf dem Quelldokument – das bei beiden Calls identisch ist – kosten zwei spezialisierte Calls kaum mehr als ein generischer. Der Mehraufwand ist marginal, die Spezialisierung substanziell.

Stufe 3 – Taxonomy Matching

Unabhängig von der Typklassifikation, aber verstärkend: Die extrahierten Entitäten werden gegen ein vordefiniertes Vokabular gematcht – Tags, Ordnerstrukturen, Kategorien, Kundenklassifikationen.

Das gibt strukturierte Facetten für Pre-Filtering – noch bevor BM25 oder Embedding überhaupt laufen. Eine Query wie „Zahlungsbedingungen Hoffmann” kann zuerst auf Kunde K-2847 gefiltert werden, dann durchsucht das System nur die Chunks dieses Kunden.

Diese Stufe unterscheidet sich von den ersten beiden in einem wesentlichen Punkt: Die Taxonomie kommt nicht aus dem LLM. Sie kommt aus dem Unternehmen – aus CRM-Systemen, ERP-Strukturen, Organigrammen, Produktkatalogen. Die Extraction-Schicht wird zum Bindeglied zwischen dem unstrukturierten Corpus und der Geschäftslogik des Kunden.

Einordnung

Die Unterscheidung opak/transparent ist mehr als eine akademische Analogie. Sie liefert ein kommunizierbares Entscheidungskriterium, das auch außerhalb der NLP-Community sofort verständlich ist.

Trägt die Zeichenfolge selbst Bedeutung, oder ist sie ein willkürlich vergebenes Kürzel?

• Wenn ein Mensch, der den Begriff noch nie gesehen hat, etwas über seine Bedeutung erschließen kann → transparent → stärkt den Embedding-Index
• Wenn die Zeichenfolge ohne Kontextwissen unverständlich ist → opak → stärkt den BM25-Index

Diese Prüfung ist domänenunabhängig. Sie funktioniert für juristische Aktenzeichen genauso wie für Maschinentypenbezeichnungen, für SAP-Materialnummern genauso wie für Markennamen. Die Achse ist ein Spektrum mit klaren Polen – in der Praxis ist die Binärunterscheidung ausreichend. Grenzfälle können konservativ behandelt werden: Im Zweifel beide Indizes anreichern.

Was es nicht ist

Es ist kein GraphRAG. Entity-Aware Index Enrichment extrahiert Entitäten, baut aber keinen Graphen. Ein Graph-Layer kann darauf aufsetzen, ist aber orthogonal.

Es ist kein Query Routing. Beide Indizes werden bei jeder Query abgefragt – die Schärfung passiert ausschließlich beim Ingestion.

Es ist keine Alternative zu Hybrid Search. Es ist eine Verbesserung innerhalb der bestehenden Architektur.

Fazit

Der Mehraufwand gegenüber undifferenzierter Anreicherung ist marginal. Der Effekt ist eine gezielte Signalverstärkung beider Retrieval-Kanäle, die gleichzeitig die Obergrenze für die Extraction-Tiefe anhebt – weil nicht alles in beide Indizes muss, kann jeder Index aggressiver und passgenauer bedient werden.

Kein neues Verfahren, sondern typgerechtes Routing beim Ingestion. Inspiriert durch Begriffe aus der Linguistik.