Metadatenverfeinerung in RAG: Filter, Zitierungen, Aktualität und Zugriffskontrolle
Warum ein RAG-System die Richtlinie der falschen Region zurückgibt und wie Quell-, organisatorische, zeitliche sowie Sicherheitsmetadaten die Suche korrigieren, wenn sie bei der Eingabe hinzugefügt werden.
Quellen: Metadata Enrichment in RAG: The Secret Ingredient for Better Retrieval
Nehmen wir an, ein Team hat für das Unternehmen einen Chatbot zur generativen Texterstellung mit Suchfunktion entwickelt. Es vergingen Tage mit der Auswahl des Embedding-Modells, eine Vektordatenbank wurde konfiguriert und darauf ein leistungsstarkes LLM gesetzt. Zufrieden damit gibt jemand eine Frage zur Mutterschutzrichtlinie für die Mitarbeiter im europäischen Büro ein.
Die Antwort kommt schnell: Die Mitarbeiter haben Anspruch auf 20 Wochen bezahlten Mutterschutz. Das scheint korrekt zu sein. Doch bei einer Überprüfung der Queldokumente stellt sich heraus, dass der abgerufte Text aus der Richtlinie stammt, die für Mitarbeiter in den Vereinigten Staaten gilt, nicht für Europa. Der Suchmechanismus fand zwar einen Abschnitt über Mutterschutz, wusste aber nicht, zu welchem Gebiet er gehört, da der umgebende Kontext bei der Aufteilung in Abschnitte und der Indexierung verloren ging.
Dies gehört zu den häufigsten Fehlern in RAG-Systemen. Die meisten Diskussionen über RAG konzentrieren sich auf Embeddings, Chunking-Strategien und Vektordatenbanken, während einer der größten Einflussfaktoren auf die Qualität der Informationsabrufung übersehen wird: die Erweiterung durch Metadaten. Metadaten ermöglichen es einem Abrufsystem, nicht nur zu verstehen, was ein bestimmter Teilinhalt besagt, sondern auch, woher er stammt, wofür er gilt, wann er verfasst wurde und wo er im Verhältnis zu den anderen Materialien einzuordnen ist. In vielen Unternehmensanwendungen unterscheiden sie ein Ergebnis, das lediglich zum Thema passt, von einem, das tatsächlich richtig ist.
Was schiefgeht bei der rein inhaltsbasierten Informationsabrufung
Betrachten Sie, wie ein Anfänger-RAG-System typischerweise funktioniert. Eine Organisation besitzt drei Richtliniedokumente: ein Mitarbeiterhandbuch für die USA, eines für Europa und eines für Asien-Pazifik. Alle drei enthalten einen Abschnitt zur Mutterschutzzeit. Nach dem Chunking enthält die Vektordatenbank nahezu identische Sätze, die sich nur in der Zahl unterscheiden: 20 Wochen in einem, 16 in einem anderen und 26 im dritten.
Für ein Embedding-Modell sind diese Chunks äußerst ähnlich, da alle drei das gleiche Thema behandeln. Wenn man nach der Mutterschutzzeit fragt, kann der Retriever beliebig einen dieser Chunks zurückgeben. Das Modell versteht die semantische Bedeutung, hat aber kein automatisches Verständnis für den Geschäftskontext. Genau da werden Metadaten unerlässlich.
Was Metadaten sind
Metadaten sind Daten über Daten. In einem RAG-System beschreiben sie einen Chunk, ohne Teil des Hauptinhalts des Chunks zu sein. Sie umfassen alles, was über einen Text wahr ist, ohne dass es sich um den Inhalt des Textes selbst handelt.
Nehmen Sie den Abschnitt aus dem Beispiel am Anfang:
Employees are entitled to 20 weeks of paid maternity leave.
Allein betrachtet ist dieser Satz klar und vollständig, und der Inhalt liefert eine Antwort. Doch er gibt nicht an, aus welchem Dokument er stammt, welche Richtlinie einer Region er beschreibt, wer dafür sorgt, dass sie aktuell bleibt, oder wann sie zuletzt überprüft wurde. Der Text beantwortet, was die Richtlinie besagt. Er kann jedoch nicht beantworten, ob es sich um die richtige Richtlinie für die Situation dieser Person handelt – genau das ist schiefgelaufen, als ein US-Beitrag wegen einer europäischen Frage zurückgeschickt wurde.
Nun derselbe Beitrag mit hinzugefügten Metadaten:
{
"source": "EU_HR_Policy.pdf",
"region": "Europe",
"department": "Human Resources",
"last_updated": "2025-03-15"
}
Aus diesen vier Feldern ist keines Teil des Satzes. Das Wort „Europa“ sowie der Dateinamen kommen im eigentlichen Text überhaupt nicht vor. Dennoch verfügt der Suchalgorithmus nun über weitaus mehr Material zur Verarbeitung. Der Datenblock enthält Kontexte, die zur Suche, Filterung, Rangfolgebestimmung und Erstellung von Antworten genutzt werden können, und dieser Kontext befindet sich neben dem Inhalt, ohne mit ihm vermischt zu werden.
Genau diese Trennung ist die Grundlage der Stärke von Metadaten. Das Embedding-Modell kodiert nach seiner Konzeption nur den page_content des Datenblocks und sieht die Metadaten niemals. Metadaten sollen nicht beeinflussen, wie ein Datenblock eingebettet wird. Sie existieren dafür, dass jeder andere Teil des Systems – einschließlich Filtern, Zugriffsprüfungen, Zitaten und Rangfolgealgorithmen – unabhängig davon, was das Embedding-Modell zur semantischen Ähnlichkeit feststellt, etwas Konkretes zum Handeln hat.
Ein einfaches mentales Modell: Metadaten sind die Sammlung von Labels, die jedem Wissensstück zugeordnet werden. Ohne Labels ist jedes Stück Wissen lediglich eine Bedeutung, die ohne Kontext existiert, und die Wiederauffindung muss allein anhand der Ähnlichkeit raten – wie es der Fall war, als drei regionale Richtlinien für das Embedding-Modell fast identisch aussahen. Mit Labels wird das Raten durch etwas ersetzt, das das System direkt überprüfen kann. Die Frage ändert sich von der, ob ein Stück Wissen der Anfrage ähnlich klingt, zu der, ob es tatsächlich zur beschriebenen Situation gehört.
Wie Metadaten die Wiederauffindung verbessern
Kehren wir zum Fall des Mutterschaftsurlaubs zurück und verfolgen wir den Wiederauffindungsschritt mit und ohne Metadaten.
Ohne Metadaten wird eine Abfrage nach europäischem Personal gegen die gesamte Vektordatenbank durchgeführt. Es zählen nur die semantischen Ähnlichkeiten, und da die drei regionalen Abschnitte fast identisch mit einem Embedding sind, kann der Suchmechanismus zuverlässig Richtlinientexte aus der falschen Region zurückgeben. Der Ähnlichkeitswert gibt keinerlei Hinweis auf ein Problem.
Ein System mit Metadaten kann hingegen vor oder zusammen mit der Ähnlichkeitssuche einen Filter anwenden:
filter = {
"region": "Europe"
}
Die Suche ist nun auf mit „Europa“ markierte Abschnitte beschränkt. Anstatt jedes Richtliniedokument durchzusuchen, betrachtet der Suchmechanismus nur den relevanten Teil, wodurch die Auswahl an Kandidaten bereits vorher eingeschränkt wird, bevor Ähnlichkeitsvergleiche zu falschen Ergebnissen führen können.
Der Ort, an dem das Filtern stattfindet, spielt eine wichtige Rolle. Die meisten produktiven Vektordatenbanken unterstützen das Vorfiltern, bei dem zunächst der Metadatenfilter angewendet wird, sodass die Ähnlichkeitssuche nur auf passenden Abschnitten durchgeführt wird. Dies ist schneller und zuverlässiger als das Nachfiltern, bei dem die vollständige Ähnlichkeitssuche in allen Daten durchgeführt wird und anschließend nicht passende Ergebnisse verworfen werden. Beim Nachfiltern kann Rechenleistung in irrelevanten Bereichen verschwendet werden, und in Einzelfällen werden weniger Ergebnisse zurückgegeben, als angefordert, wenn zu viele hochwertige Treffer spät im Prozess ausgeschlossen werden. Sowohl Qdrant als auch Weaviate sind dafür konzipiert, effizientes Vorfiltern zu unterstützen.
Hier ist das Szenario der Mutterschutzzeit von Anfang bis Ende detailliert dargestellt:
from sentence_transformers import SentenceTransformer
import numpy as np
embedding_model = SentenceTransformer("all-MiniLM-L6-v2")
chunks = [
{"text": "Employees are entitled to 20 weeks of paid maternity leave.", "region": "United States"},
{"text": "Employees are entitled to 16 weeks of paid maternity leave.", "region": "Europe"},
{"text": "Employees are entitled to 26 weeks of paid maternity leave.", "region": "Asia-Pacific"},
]
for c in chunks:
c["embedding"] = embedding_model.encode(c["text"])
query = "What is the maternity leave policy for employees in the European office?"
query_embedding = embedding_model.encode(query)
def search(chunks, query_embedding, region_filter=None):
candidates = chunks if region_filter is None else [c for c in chunks if c["region"] == region_filter]
scored = [(np.dot(query_embedding, c["embedding"]), c) for c in candidates]
scored.sort(key=lambda x: x[0], reverse=True)
return scored[0][1]
print("Without metadata filter:")
result = search(chunks, query_embedding)
print(f" Returned: '{result['text']}' (region: {result['region']})")
print("\nWith metadata filter (region='Europe'):")
result = search(chunks, query_embedding, region_filter="Europe")
print(f" Returned: '{result['text']}' (region: {result['region']})")
Das reproduziert den fehlerhaften Start direkt. Ohne Filter wählt allein die Ähnlichkeit den US-Teilabschnitt, weil er einen leicht höheren Wert aufweist – und nicht, weil er für die Frage geeignet ist. Sobald der Regionenfilter angewendet wird, schrumpft der Suchraum auf den einzigen europäischen Teilabschnitt, und die richtige Antwort wird angezeigt, egal wie ähnlich die anderen Embeddings sind.
Die Genauigkeit verbessert sich stark, und der Unterschied wird größer, je größer das Korpus wird. Unter drei Dokumenten könnte ein Embedding-Modell durch reines Glück das richtige Dokument an erster Stelle platzieren. Bei Hunderten von Dokumenten, die viele Regionen, Abteilungen und Jahre abdecken, wird die Ähnlichkeit allein unzuverlässig – und das Filtern nach Metadaten ist die einzige zuverlässige Methode, um alles Weitere auszuschließen.
Vier Arten von Metadaten, die nützlich sind
Nicht alle Metadaten sind gleichermaßen nützlich. Vier Kategorien tauchen in echten Unternehmenssystemen häufig auf, wobei jede ein anderes Problem löst.
Quellmetadaten
Diese geben an, woher die Informationen stammen. Typische Felder sind der Dateinamen, die Seitenzahl, die URL und die Dokument-ID. Sie sind wichtig, wenn Nutzer Zitate benötigen oder eine Antwort überprüfen wollen. So entsteht ein Zitat:
def format_citation(metadata):
return f"Source: {metadata['source']}, Page {metadata['page']}"
chunk_metadata = {"source": "Employee_Handbook_2025.pdf", "page": 42}
print(format_citation(chunk_metadata))
Welches wird ausgegeben:
Source: Employee_Handbook_2025.pdf, Page 42
Der Zitierstring entsteht nicht dadurch, dass das LLM errät, woher eine Antwort stammt. Es handelt sich um eine deterministische Abfrage der bei der Dokumentladung erfassten Felder. Das Vertrauen wächst, wenn Nutzer Informationen bis zu ihrer Quelle zurückverfolgen können – und das hängt davon ab, dass die Metadaten von der Eingabe bis zur endgültigen Antwort vollständig erhalten bleiben.
Organisatorische Metadaten
Unternehmenswissen ist in der Regel auf Abteilungen und Geschäftseinheiten wie Personalwesen, Finanzen, Recht und Ingenieurwesen aufgeteilt. Durch solches Taggen kann die Suche bereits vor Durchführung von Ähnlichkeitsvergleichen auf den relevanten Teil des Unternehmens eingegrenzt werden, wobei derselbe Filtermechanismus wie oben verwendet wird:
filter = {"department": "Finance"}
Das Suchen in technischer Dokumentation nach einer Finanzfrage ist zeitaufwendig, doch es gibt ein weiteres Problem: Eine Finanzanfrage, die an technischen Texten getestet wird, kann einen eindeutig falschen, themenfremden Textabschnitt liefern, der aufgrund der reinen Ähnlichkeit täuschend gut bewertet wird.
Zeitbasierte Metadaten
Informationen ändern sich im Laufe der Zeit, da Richtlinien aktualisiert, Verfahren weiterentwickelt und Vorschriften geändert werden. Ohne Zeitstempel kann ein Suchsystem nicht zwischen einer aktuellen und einer veralteten Richtlinie unterscheiden. Es kennt zwar die Textabschnitte, die semantisch der Anfrage nahekommen, weiß aber nicht, welche noch in Kraft sind.
Betrachten wir zwei Textabschnitte zur gleichen Richtlinie mit unterschiedlichen Aktualisierungsdaten:
chunks = [
{"text": "Employees receive 15 vacation days per year.", "last_updated": "2023-01-10"},
{"text": "Employees receive 20 vacation days per year.", "last_updated": "2025-03-15"},
]
Sowohl Systeme werden bei einer Frage zu Urlaubstagen wahrscheinlich ähnliche Ergebnisse liefern, da das Thema und die Formulierung nahezu identisch sind. Das Speichern eines Zeitstempels ermöglicht es dem System, bewusst das neueren Ergebnis zu bevorzugen und es nicht dem Zufall zu überlassen:
most_recent = max(chunks, key=lambda c: c["last_updated"])
print(most_recent["text"])
Ergebnis:
Employees receive 20 vacation days per year.
Das ist in Branchen, in denen sich Informationen häufig ändern, von entscheidender Bedeutung. Ohne eine explizite Aktualitätsprüfung sind eine alte Richtlinie und ihre Ersetzung für einen Suchmechanismus, der nur auf Ähnlichkeit achtet, funktional nicht voneinander zu unterscheiden.
Sicherheitsmetadaten
Viele Organisationen benötigen rollenbasierte Zugriffskontrolle: HR-Dokumente sind nur für HR-Mitarbeiter sichtbar, Finanzberichte nur für die Finanzabteilungen. Metadaten ermöglichen die Durchsetzung dieser Regelung. Ein Datensatz kann Felder wie diese enthalten:
chunk_metadata = {
"access_level": "confidential",
"allowed_roles": ["HR_Manager", "HR_Admin"]
}
Vor dem Abrufen vergleicht das System die Rolle des anfragenden Benutzers mit den Rollen, denen das Ansehen des Teils gestattet ist:
def can_access(user_role, chunk_metadata):
return user_role in chunk_metadata["allowed_roles"]
print(can_access("HR_Manager", chunk_metadata)) # True
print(can_access("Engineering", chunk_metadata)) # False
Ausgabe:
True
False
In einer echten Pipeline wird diese Überprüfung während der Abrufung als Filter durchgeführt und nicht erst im Nachhinein, nachdem das LLM bereits den Inhalt besitzt. Ein Teilinhalt, den ein Benutzer nicht sehen darf, sollte niemals bis zum Prompt vordringen. Ohne Metadaten ist es äußerst schwierig, sichere RAG-Systeme zu erstellen, da kein zuverlässiger Hinweis an jeden Teilinhalt angehängt wird, den das System mit den Berechtigungen des Benutzers vergleichen kann, bevor es entscheidet, ob dieser abgerufen werden soll.
Metadaten hinzufügen während der Aufnahme
Metadaten entstehen nicht von selbst. Sie müssen während der Aufnahme von Dokumenten hinzugefügt werden, und wenn sie dort nicht erfasst werden, können sie nicht wiederhergestellt werden, denn bis ein Teilinhalt zur Embedding- oder Speicherung gelangt, ist der Verweis auf seine Quelle bereits verschwunden.
Nehmen wir ein PDF mit einer HR-Richtlinie, das geladen wird. Der übliche Aufnahmeprozess führt diese Schritte nacheinander aus:
- Das Dokument laden.
- Den Text extrahieren.
- Den Inhalt in Teilinhalte aufteilen.
- Metadaten hinzufügen.
- Embeddings erzeugen.
- Die Chunks, Embeddings und Metadaten in die Vektordatenbank schreiben.
Die Hinzufügung von Metadaten erfolgt nach dem Aufteilen in Chunks und nicht davor, und die Reihenfolge ist wichtig. Die Metadaten müssen jedem einzelnen Chunk übertragen werden, in den ein Dokument aufgeteilt wird, anstatt einmal dem gesamten Dokument hinzugefügt zu werden.
from langchain_core.documents import Document
doc = Document(
page_content="Employees receive 20 weeks of maternity leave.",
metadata={
"department": "HR",
"region": "Europe",
"source": "EU_HR_Policy.pdf"
}
)
print(doc.page_content)
print(doc.metadata)
Ausgabe:
Employees receive 20 weeks of maternity leave.
{'department': 'HR', 'region': 'Europe', 'source': 'EU_HR_Policy.pdf'}
Das ist einfach, solange ein Dokument klein genug ist, um in einem einzigen Block zu bleiben. Reale Dokumente werden jedoch in viele Blöcke aufgeteilt, und die Metadaten müssen auf jeden dieser Blöcke kopiert werden:
def chunk_with_metadata(document, chunk_size=60):
text = document.page_content
chunks = [text[i:i+chunk_size] for i in range(0, len(text), chunk_size)]
return [
Document(page_content=chunk_text, metadata=document.metadata)
for chunk_text in chunks
]
source_doc = Document(
page_content="Employees receive 20 weeks of maternity leave. Eligibility begins after six months of employment.",
metadata={"department": "HR", "region": "Europe", "source": "EU_HR_Policy.pdf"}
)
chunked_docs = chunk_with_metadata(source_doc)
for i, chunk in enumerate(chunked_docs, 1):
print(f"Chunk {i}: {chunk.page_content!r}")
print(f" Metadata: {chunk.metadata}\n")
Ausgabe:
Chunk 1: 'Employees receive 20 weeks of maternity leave. Eligibility b'
Metadata: {'department': 'HR', 'region': 'Europe', 'source': 'EU_HR_Policy.pdf'}
Chunk 2: 'egins after six months of employment.'
Metadata: {'department': 'HR', 'region': 'Europe', 'source': 'EU_HR_Policy.pdf'}
Auch wenn die beiden Abschnitte unterschiedliche Fragmente desselben Dokuments sind, erben sie jeweils identische Werte für Region, Abteilung und Quelle. Genau das sorgt dafür, dass die oben gezeigten Filterbeispiele funktionieren: Unabhängig davon, wie der Text aufgeteilt wurde, kann jeder Abschnitt weiterhin angeben, dass er Teil der europäischen HR-Politik ist. Jeder Abschnitt enthält nun neben seiner Einbettung durch Suchfunktionen, Filter und Zitierungen auch wertvolle Kontextinformationen.
Erlauben, dass ein LLM die Metadaten erzeugt
Moderne RAG-Systeme nutzen zunehmend LLMs zur Erstellung von Metadaten, anstatt sich ausschließlich auf manuelles Taggen zu verlassen. Anstatt dass eine Person jedes Dokument liest und manuell Etiketten zuweist, kann ein Modell ein Dokument analysieren und Felder wie Thema, Abteilung, Kategorie, Schlüsselwörter sowie eine Zusammenfassung bestimmen. Der folgende Code zeigt den Prompt, der dies erzeugt – und nicht nur die Ausgabe:
def generate_metadata(text, llm):
prompt = f"""Analyze the following document and return metadata as JSON with these fields:
topic, category, and keywords (a list of 3-5 relevant terms).
Document:
{text}
Respond with only the JSON, no other text."""
response = llm.generate(prompt)
return response
sample_text = "Employees are entitled to 20 weeks of paid maternity leave, with eligibility beginning after six months of continuous employment. Additional unpaid leave may be requested with manager approval."
# In practice, llm.generate() would call an actual model (Claude, GPT, etc.)
# Below is the kind of output this prompt is designed to produce:
example_output = {
"topic": "Employee Benefits",
"category": "HR Policy",
"keywords": ["maternity leave", "eligibility", "employee benefits"]
}
print(example_output)
Ausgabe:
{'topic': 'Employee Benefits', 'category': 'HR Policy', 'keywords': ['maternity leave', 'eligibility', 'employee benefits']}
Diese Metadaten werden dem Chunk genauso zugeordnet wie manuell zugewiesene Metadaten. Nur die Partei, die die Werte festlegt, unterscheidet sich. Das Ergebnis ist eine verbesserte Sucherfahrung mit weniger manueller Arbeit, insbesondere in großem Umfang: Das Manuell-Kennzeichnen einiger Dokumente ist machbar, doch das Kennzeichnen von Zehntausenden von Chunks in einer wachsenden Wissensbasis ist in der Regel nicht möglich. Immer mehr fortschrittliche Pipelines betrachten einen solchen Schritt als routinemäßige Vorausverarbeitung, die beim Einlesen zusammen mit dem Chunking und Embedding einmal ausgeführt wird.
Eine praktische Einschränkung: Überprüfen Sie die von LLMs erzeugten Ausgaben regelmäßig, besonders zu Beginn. Ein Modell kann gelegentlich ein Thema oder eine Kategorie zuweisen, die nicht zum tatsächlichen Inhalt passt, und im Gegensatz zu einem Menschen, der ein Dokument falsch kennzeichnet, kann ein automatischer Fehler, sofern der Prompt systematische Schwachstellen aufweist, sich stillschweigend auf viele Dokumente gleichzeitig ausbreiten.
Metadatenfilterung und hybride Suche
Metadaten sind am wirkungsvollsten, wenn sie mit semantischer Suche kombiniert werden, wobei Genauigkeit bei dieser Kombination hilfreich ist, da im RAG-Bereich der Begriff „hybrid“ für mehr als eine Technik verwendet wird.
Im strengen Sinne bedeutet hybride Suche das Koppeln zweier Suchmethoden – nämlich der dichten Vektor Suche und der spärlichen Schlüsselwort Suche (BM25) – deren gleichzeitige Ausführung sowie die Zusammenführung der Ergebnisse. Metadatenfiltering hingegen ist etwas anderes: Es handelt sich dabei nicht um eine weitere Suchmethode, sondern um eine Möglichkeit, den Pool der möglichen Ergebnisse vor oder zusammen mit der bereits verwendeten Methode oder Methodekombination einzuschränken.
Die Vektorsuche fragt, welche Fragmente semantisch der Anfrage ähneln. Das Metadatenfiltering fragt, welche Fragmente zur richtigen Kategorie, Region, Abteilung oder Zeitperiode gehören. Die beiden Fragen sind unabhängig voneinander, sodass ein Filter genauso gut mit reiner Vektorsuche, allein mit BM25 oder mit einem vollständigen hybriden Suchsystem funktioniert. Es handelt sich dabei um eine zusätzliche Schicht, die jedes dieser Systeme umgeben kann.
Zusammen steigern sie die Suchqualität erheblich, wie das Beispiel der Mutterschutzzeit zeigt. Das System hört auf, blind in der gesamten Wissensdatenbank zu suchen, und durchsucht stattdessen intelligent den am relevantestenen Teilmenge – wobei allein die Ähnlichkeit über die Rangfolge innerhalb dieser bereits eingegrenzten, richtigen Menge entscheidet. Deshalb verlässt sich moderne Unternehmens-RAG-Systeme selten allein auf Embeddings: Embeddings bestimmen, was ähnlich ist, doch Metadaten entscheiden, was überhaupt in Betracht gezogen werden darf.
Die übersehene Hebelwirkung
Viele Organisationen investieren viel Mühe in die Auswahl von Embedding-Modellen und Vektordatenbanken. Diese Entscheidungen sind wichtig, doch in der Praxis scheitert die Suche oft aus einem viel einfacheren Grund: Wichtige kontextuelle Informationen wurden nie erfasst, egal wie gut das Modell oder die Datenbank auch sein mag.
Stellen Sie sich eine Bibliothek vor, in der jedes Buch seinen Titel, Autor, Erscheinungsdatum und die Kategorie verloren hat und nur noch Rohtext vorhanden ist. Selbst mit einem hervorragenden Regalsystem und Suchkatalog wäre es sehr schwierig, etwas zu finden. Das Speichern von Datenblöcken ohne Metadaten ist genauso: Die Suchinfrastruktur kann perfekt sein, hilft aber trotzdem nicht, wenn kein Kontext vorhanden ist, auf den sie sich beziehen kann.
Metadaten liefern die organisatorische Struktur, die es ermöglicht, in großen Wissensbasen effektiv zu suchen. Da Sammlungen von Hunderten von Dokumenten auf Millionen von Datenblöcken anwachsen, wird dies immer wichtiger. In kleinem Maßstab kann ein Embedding-Modell durch reines Glück den richtigen Datenblock an erste Stelle setzen – wie es bei drei Richtliniedokumenten fast der Fall war. In einer echten Unternehmens-Wissensbasis geht dieses Glück jedoch schnell zur Neige. Viele Unternehmensteams berichten, dass eine Verbesserung der Metadatenqualität größere Vorteile bringt als der Wechsel zu einem neueren Embedding-Modell – was angesichts der großen Aufmerksamkeit, die der Modellauswahl geschenkt wird, und der geringen Aufmerksamkeit für die Metadatenstrategie bedacht werden sollte.
Fazit
Das Anreichern von Textblöcken mit Metadaten zählt zu den besten Methoden, um die Ergebnisse von RAG zu verbessern, erhält jedoch weitaus weniger Aufmerksamkeit als Embeddings, Vektordatenbanken und LLMs. Embeddings erfassen die Bedeutung des Inhalts, während Metadaten den Kontext darum erfassen; gemeinsam ermöglichen sie es einem System, nicht nur ähnliche Informationen, sondern die richtigen Informationen zu finden. Egal ob es um das Verfolgen von Quellen, das Filtern nach Region, die Gewährleistung der Sicherheit, das Erfassen von Zeitstempeln oder das Hinzufügen von von KI verfassten Labels geht – Metadaten helfen dabei, eine einfache Suchanlage in eine für den Einsatz bereite Wissensplattform zu verwandeln.
Daher geht es bei der Bewertung eines RAG-Pipelines nicht nur darum, welches Embedding-Modell verwendet werden soll, sondern auch darum, welche Metadaten den Textblöcken hinzugefügt werden sollten. In vielen realen Systemen bedeutet besseres Metadatenmaterial eine bessere Suche, eine bessere Suche bedeutet bessere Antworten und bessere Antworten bedeuten ein besseres Erlebnis für die Nutzer.
Verwandte Artikel
- Vectorloses RAG: Wie PageIndex Dokumente ohne Embeddings liest — Die Vektorsuche teilt lange Dokumente in Blöcke auf und verliert dabei den Kontext. Erfahren Sie, wie ein auf Schlussfolgerungen basierender Baumindex Antworten in komplexen Berichten mithilfe von Code findet.
- Praktische Notizen: Prompt Engineering zum AI-Systemdesign – RAG, Speicher, Tools — Detaillierte Anleitung zu den Praktischen Notizen: Prompt Engineering zum AI-Systemdesign – RAG, Speicher, Tools: Verträge, Überprüfungen sowie Code-Blöcke, die Teams nutzen können, die dieses Muster implementieren.