Kontext und Kontextabruf in RAG verstehen

In meinem neuesten BeitragIch erläutere, wie die Hybridsuche genutzt werden kann, um die Effektivität einer RAG-Pipeline deutlich zu verbessern. RAG kann in seiner Basisversion, die nur die semantische Suche bei Einbettungen verwendet, sehr effektiv sein und es uns ermöglichen, die Leistungsfähigkeit der KI in unseren eigenen Dokumenten zu nutzen. Dennoch kann es bei der semantischen Suche, so leistungsfähig sie auch ist, bei der Verwendung in großen Wissensdatenbanken manchmal vorkommen, dass exakte Übereinstimmungen mit der Suchanfrage des Benutzers übersehen werden, selbst wenn sie in den Dokumenten vorhanden sind. Diese Schwäche des traditionellen RAG kann durch das Hinzufügen einer Schlüsselwortsuchkomponente wie BM25 in die Pipeline behoben werden. Auf diese Weise führt die Hybridsuche, die semantische und Schlüsselwortsuche kombiniert, zu wesentlich umfassenderen Ergebnissen und verbessert die Leistung eines RAG-Methods deutlich.

Wie dem auch sei, selbst wenn wir RAG mit Hybridsuche verwenden, können wir manchmal immer noch wichtige Informationen übersehen, die in verschiedenen Teilen des Dokuments verstreut sind. Dies kann passieren, weil bei der Aufteilung eines Dokuments in Textabschnitte manchmal der Kontext – additionally der umgebende Textual content des Abschnitts, der Teil seiner Bedeutung ist – verloren geht. Dies kann insbesondere bei komplexen Texten der Fall sein, deren Bedeutung miteinander verbunden und über mehrere Seiten verstreut ist und zwangsläufig nicht vollständig in einem einzigen Textblock zusammengefasst werden kann. Denken Sie zum Beispiel daran, auf eine Tabelle oder ein Bild in mehreren verschiedenen Textabschnitten zu verweisen, ohne explizit zu definieren, auf welche Tabelle wir uns beziehen (z. B. „Wie in der Tabelle gezeigt, stiegen die Gewinne um 6 %” – welche Tabelle?). Wenn die Textabschnitte dann abgerufen werden, werden sie daher aus ihrem Kontext entfernt, was manchmal dazu führt, dass irrelevante Abschnitte abgerufen und irrelevante Antworten generiert werden.

Dieser Kontextverlust conflict einige Zeit lang ein großes Drawback für RAG-Systeme, und es wurden mehrere nicht so erfolgreiche Lösungen zur Verbesserung untersucht. Ein offensichtlicher Versuch, dies zu verbessern, besteht darin, die Blockgröße zu erhöhen. Dies verändert jedoch häufig auch die semantische Bedeutung jedes Blocks und führt dazu, dass der Abruf ungenauer wird. Ein anderer Ansatz besteht darin, die Chunk-Überlappung zu erhöhen. Dies trägt zwar dazu bei, den Kontext besser zu erhalten, erhöht aber auch die Speicher- und Rechenkosten. Am wichtigsten ist, dass das Drawback dadurch nicht vollständig gelöst wird – wir können immer noch wichtige Verbindungen zum Chunk über Chunk-Grenzen hinweg haben. Fortgeschrittenere Ansätze zur Lösung dieser Herausforderung umfassen: Hypothetische Dokumenteinbettungen (HyDE) oder Dokumentzusammenfassungsindex. Dennoch bringen diese noch immer keine wesentlichen Verbesserungen.

Letztendlich gibt es einen Ansatz, der dieses Drawback effektiv löst und die Ergebnisse eines RAG-Methods erheblich verbessert Kontextbezogenes Abrufen, ursprünglich von Anthropic im Jahr 2024 eingeführt. Der Kontextabruf zielt darauf ab, den Kontextverlust zu beheben, indem der Kontext der Chunks erhalten bleibt und somit die Genauigkeit des Abrufschritts der RAG-Pipeline verbessert wird.

. . .

Wie sieht es mit dem Kontext aus?

Bevor wir etwas über kontextbezogenes Abrufen sagen, gehen wir einen Schritt zurück und sprechen ein wenig darüber, was Kontext ist. Sicher, wir haben alle vom Kontext von LLMs oder Kontextfenstern gehört, aber worum geht es eigentlich?

Genauer gesagt bezieht sich der Kontext auf alle Token, die dem LLM zur Verfügung stehen und auf deren Grundlage er das nächste Wort vorhersagt – Denken Sie daran, dass LLMs funktionieren, indem sie Textual content generieren, indem sie ihn Wort für Wort vorhersagen. Dabei handelt es sich additionally um die Benutzeraufforderung, die Systemaufforderung, Anweisungen, Fähigkeiten oder andere Richtlinien, die Einfluss darauf haben, wie das Modell eine Antwort erzeugt. Wichtig ist, dass der Teil der endgültigen Antwort, die das Modell bisher erzeugt hat, auch Teil des Kontexts ist, da jedes neue Token auf der Grundlage aller vorangegangenen Token generiert wird.

Offenbar führen unterschiedliche Kontexte zu sehr unterschiedlichen Modellergebnissen. Zum Beispiel:

• ‚Ich ging in ein Restaurant und bestellte ein‚ könnte ausgeben ‚Pizza.‚
• „Ich bin in die Apotheke gegangen und habe mir eins gekauft‚ könnte ausgeben ‚Medizin.‚

Eine grundlegende Einschränkung von LLMs ist ihre Kontextfenster. Das Kontextfenster eines LLM ist die maximale Anzahl von Tokens, die gleichzeitig als Eingabe an das Modell übergeben und zur Erzeugung einer einzelnen Antwort berücksichtigt werden können. Es gibt LLMs mit größeren oder kleineren Kontextfenstern. Moderne Frontier-Modelle können Hunderttausende Token in einer einzigen Anfrage verarbeiten, während frühere Modelle oft Kontextfenster von nur 8.000 Tokens hatten.

In einer perfekten Welt würden wir einfach alle Informationen weitergeben wollen, die der LLM im Kontext wissen muss, und wir würden höchstwahrscheinlich sehr gute Antworten erhalten. Und das stimmt bis zu einem gewissen Grad – ein Grenzmodell wie Opus 4.6 Bei einem 200.000-Token-Kontextfenster entspricht dies etwa 500–600 Seiten Textual content. Wenn alle Informationen, die wir bereitstellen müssen, dieser Größenbeschränkung entsprechen, können wir tatsächlich einfach alles so wie es ist als Eingabe in das LLM einbeziehen und eine großartige Antwort erhalten.

Das Drawback besteht darin, dass wir für die meisten realen KI-Anwendungsfälle eine Artwork Wissensbasis nutzen müssen, deren Größe weit über diesem Schwellenwert liegt – denken Sie zum Beispiel an juristische Bibliotheken oder Handbücher für technische Geräte. Da Modelle diesen Einschränkungen im Kontextfenster unterliegen, können wir leider nicht einfach alles an das LLM übergeben und es auf magische Weise reagieren lassen – wir müssen uns irgendwie entscheiden Was ist die wichtigste Data, die in unserem begrenzten Kontextfenster enthalten sein sollte. Und genau darum geht es bei der RAG-Methodik: die passenden Informationen aus einer großen Wissensdatenbank auszuwählen, um die Anfrage eines Benutzers effektiv zu beantworten. Letztlich stellt sich heraus, dass dies ein Optimierungs-/Konstruktionsproblem ist – Kontext-Engineering — Identifizieren der geeigneten Informationen, die in ein begrenztes Kontextfenster aufgenommen werden sollen, um die bestmöglichen Antworten zu erzielen.

Dies ist der wichtigste Teil eines RAG-Methods – er stellt sicher, dass die richtigen Informationen abgerufen und als Eingabe an das LLM übergeben werden. Dies kann, wie bereits erläutert, mit der semantischen Suche und der Stichwortsuche erfolgen. Selbst wenn alle semantisch relevanten Teile und alle exakten Übereinstimmungen berücksichtigt werden, besteht jedoch immer noch eine gute Probability, dass dies der Fall ist manche Wichtige Informationen können verloren gehen.

Aber was für Informationen wären das? Nachdem wir die Bedeutung mit der semantischen Suche und die genauen Übereinstimmungen mit der Stichwortsuche abgedeckt haben, welche anderen Arten von Informationen gibt es dann noch zu berücksichtigen?

Verschiedene Dokumente mit grundsätzlich unterschiedlicher Bedeutung können Teile enthalten, die ähnlich oder sogar identisch sind. Stellen Sie sich ein Rezeptbuch und ein Handbuch zur chemischen Verarbeitung vor, die den Leser dazu anleiten „Die Mischung langsam erhitzen“. Die semantische Bedeutung eines solchen Textblocks und der tatsächlichen Wörter sind sehr ähnlich – identisch. Was in diesem Beispiel die Bedeutung des Textes ausmacht und es uns ermöglicht, zwischen Kochen und Chemieingenieurwesen zu unterscheiden, ist das, worauf wir uns beziehen Kontext.

Dies ist additionally die Artwork von zusätzlichen Informationen, die wir bewahren möchten. Und genau das macht die kontextbezogene Abfrage: Sie bewahrt den Kontext – die umgebende Bedeutung – jedes Textabschnitts.

. . .

Wie sieht es mit dem kontextuellen Abruf aus?

Der kontextbezogene Abruf ist additionally eine in RAG angewandte Methode, die darauf abzielt, den Kontext jedes Blocks zu bewahren. Auf diese Weise können wir, wenn ein Block abgerufen und als Eingabe an das LLM übergeben wird, so viel wie möglich von seiner ursprünglichen Bedeutung bewahren – die Semantik, die Schlüsselwörter, den Kontext – alles davon.

Um dies zu erreichen, schlägt der kontextbezogene Abruf vor, dass wir zunächst für jeden Block einen Hilfstext generieren – nämlich den Kontexttext – Dadurch können wir den Textabschnitt im Originaldokument verorten, aus dem er stammt. In der Praxis bitten wir einen LLM, diesen Kontexttext für jeden Block zu generieren. Dazu stellen wir das Dokument zusammen mit dem eigentlichen Block in einer einzigen Anfrage an einen LLM und fordern ihn auf, „Stellen Sie den Kontext bereit, um den spezifischen Abschnitt im Dokument zu positionieren„. Eine Eingabeaufforderung zum Generieren des Kontexttextes für unsere Italienisches Kochbuch chunk würde etwa so aussehen:

<doc> 
all the doc Italian Cookbook doc the chunk comes from
</doc> 

Right here is the chunk we wish to place throughout the context of the complete doc.

<chunk> 
the precise chunk
</chunk> 

Present a quick context that situates this chunk throughout the general 
doc to enhance search retrieval. Reply solely with the concise 
context and nothing else.

Das LLM gibt den Kontexttext zurück, den wir mit unserem anfänglichen Textblock kombinieren. Auf diese Weise generieren wir für jeden Abschnitt unseres Ausgangstextes einen Kontexttext, der beschreibt, wie dieser spezifische Abschnitt in seinem übergeordneten Dokument platziert wird. Für unser Beispiel wäre das etwa so:

Context: Recipe step for simmering selfmade tomato pasta sauce.
Chunk: Warmth the combination slowly and stir often to stop it from sticking.

Das ist in der Tat viel informativer und spezifischer! Nun besteht kein Zweifel daran, um was es sich bei dieser mysteriösen Mischung handelt, denn alle Informationen, die man braucht, um zu erkennen, ob es sich um Tomatensauce oder um Laborstärkelösungen handelt, sind praktischerweise in einem einzigen Stück enthalten.

Von diesem Punkt an behandeln wir den anfänglichen Blocktext und den Kontexttext als untrennbares Paar. Anschließend werden die restlichen Schritte von RAG mit Hybridsuche im Wesentlichen auf die gleiche Weise durchgeführt. Das heißt, wir erstellen Einbettungen, die in einer Vektorsuche und dem BM25-Index für jeden Textblock gespeichert werden, dem der Kontexttext vorangestellt wird.

Dieser Ansatz, so einfach er auch ist, führt zu erstaunlichen Verbesserungen der Abrufleistung von RAG-Pipelines. Laut Anthropic verbessert Contextual Retrieval die Abrufgenauigkeit um stolze 35 %.

. . .

Reduzierte Kosten durch sofortiges Caching

Ich höre Sie fragen: „Aber wird das nicht ein Vermögen kosten?„Überraschenderweise nein.

Intuitiv verstehen wir, dass dieses Setup die Aufnahmekosten für eine RAG-Pipeline erheblich erhöhen wird – im Wesentlichen um das Doppelte, wenn nicht sogar mehr. Immerhin haben wir dem LLM doch eine Menge zusätzlicher Anrufe hinzugefügt, nicht wahr? Dies trifft bis zu einem gewissen Grad zu – tatsächlich führen wir jetzt für jeden Block einen zusätzlichen Aufruf an das LLM durch, um ihn in seinem Quelldokument zu positionieren und den kontextuellen Textual content abzurufen.

Dabei handelt es sich jedoch um Kosten, die wir nur einmal in der Part der Dokumentenerfassung bezahlen. Im Gegensatz zu alternativen Techniken, die versuchen, den Kontext zur Laufzeit beizubehalten – wie zum Beispiel Hypothetical Doc Embeddings (HyDE) – übernimmt der kontextbezogene Abruf die schwere Arbeit während der Dokumentaufnahmephase. Bei Laufzeitansätzen sind für jede Benutzerabfrage zusätzliche LLM-Aufrufe erforderlich, wodurch sich Latenz und Betriebskosten schnell steigern lassen. Im Gegensatz dazu verschiebt der kontextbezogene Abruf die Berechnung in die Aufnahmephase, was bedeutet, dass die verbesserte Abrufqualität keinen zusätzlichen Overhead während der Laufzeit mit sich bringt. Darüber hinaus können zusätzliche Techniken eingesetzt werden, um die Kosten für den kontextbezogenen Abruf weiter zu reduzieren. Genauer gesagt kann Caching verwendet werden, um die Zusammenfassung des Dokuments nur einmal zu erstellen und dann jeden Teil mit der erstellten Dokumentzusammenfassung zu vergleichen.

. . .

In meinen Gedanken

Der kontextbezogene Abruf stellt eine einfache, aber leistungsstarke Verbesserung gegenüber herkömmlichen RAG-Systemen dar. Indem wir jeden Block mit kontextbezogenem Textual content anreichern und seine semantische Place innerhalb seines Quelldokuments genau bestimmen, reduzieren wir die Mehrdeutigkeit jedes Blocks drastisch und verbessern so die Qualität der an das LLM übergebenen Informationen. In Kombination mit der Hybridsuche ermöglicht uns diese Technik die gleichzeitige Beibehaltung von Semantik, Schlüsselwörtern und Kontext.

Hat Ihnen dieser Beitrag gefallen? Lasst uns Freunde sein! Begleiten Sie mich auf:

📰Unterstapel 💌 Medium 💼LinkedIn ☕Kauf mir einen Kaffee!

Alle Bilder vom Autor, sofern nicht anders angegeben.