Die RAG-Probleme bestehen weiterhin – hier sind fünf Fixes.

Es ist an der Zeit, der Wahrheit über Retrieval-Augmented Generation (RAG) ins Auge zu sehen: Es ist eine Lösung, die ihrerseits einer Lösung bedarf.

RAG sollte die Leistung großer Sprachmodelle verbessern und Halluzinationen reduzieren, indem es großen Sprachmodellen (LLMs) ermöglichte, über ihre Trainingsdaten hinaus Zugriff auf externe Wissensdatenbanken zu erhalten. Die realen Grenzen traditioneller RAG-Systeme sind jedoch schmerzhaft deutlich geworden.

„Das RAG-System ist in weiten Teilen fehlerhaft“, sagte Dinesh Nirmal, Senior Vice President von IBM Software. „Reine RAG liefert nicht wirklich die optimalen Ergebnisse, die erwartet wurden.“

Die Herausforderungen, denen Nutzer mit RAG gegenüberstehen, umfassen Einschränkungen bei Kontextfenstern und Aggregationsoperationen, Unfähigkeit, komplexe Beziehungen zu verstehen, sowie minderwertige Ausgaben im Zusammenhang mit suboptimalem Chunking. Die Implementierung von RAG kann nämlich auch Sicherheitsbedenken mit sich bringen, wie z. B. Datenlecks.

Die gute Nachricht ist, dass Fortschritte bei künstlichen Intelligenz-Werkzeugen und -Strategien dazu beitragen, die Schwächen des traditionellen RAG-Algorithmus auszugleichen, was zu genaueren Antworten auf Benutzeranfragen führt. Werfen wir einen genaueren Blick darauf, wie man die RAG-Leistung verbessern kann.

Wenn Sie eine LLM-Anwendung, die auf herkömmlichem RAG basiert, auffordern, Aggregationsoperationen (wie z. B. die Ermittlung einer Summe) für einen riesigen Datensatz durchzuführen, ist das oft nicht nur schwierig, sondern buchstäblich unmöglich. Ein Faktor, der die Leistung des Systems beeinträchtigen könnte, ist die Größe des Kontextfensters: LLM-Kontextfenster sind im Allgemeinen nicht skalierbar genug, um beispielsweise eine Sammlung von 100.000 Rechnungen zu verarbeiten. Darüber hinaus basiert die traditionelle RAG-Pipeline auf Vektordatenbanken, die für Ähnlichkeitssuchen und nicht für Aggregationsoperationen konzipiert sind.

„Im Wesentlichen bedeutet dies, dass eine Vektordatenbank für diese Fälle nicht ausreicht“, erklärte IBM Distinguished Engineer Sudheesh Kairali. „Das Kontextfenster ist ein Problem.“ Das andere ist die Unfähigkeit, mathematische Operationen zu handhaben.“

Geben Sie SQL RAG ein.  

Wenn LLM-Nutzer Antworten aus großen Datensätzen suchen, kann die Kombination einer Retrieval-Augmented Generation mit einem SQL präzise Ergebnisse liefern, erklärte Kairali.

SQL enthält integrierte Aggregationsfunktionen, und SQL-Datenbanken haben eine größere Kapazität als LLM-Kontextfenster. Wenn ein Unternehmen seine Rechnungsdaten in eine SQL-Datenbank eingibt, kann es ein LLM verwenden, um Abfragen – wie zum Beispiel „Wie hoch ist die Summe aller Rechnungen des letzten Jahres?“ – in SQL umzuwandeln, SQL Database mithilfe von RAG abfragen und die Antwort erhalten.

„Wenn man es aufbauen kann, sind viele Aggregationen möglich“, sagte Kairali. Nachdem die SQL Database eine Aggregation durchgeführt hat, „muss das LLM nur noch die natürliche Sprache verarbeiten (NLP).“

Eine weitere Schwäche der traditionellen RAG ist die Feststellung, wie die verschiedenen abgerufenen Informationen oder Entitäten miteinander zusammenhängen. Betrachten wir zum Beispiel den Anwendungsfall eines Patienten mit einer komplexen Krankengeschichte. Durch den traditionellen RAG-Abrufprozess kann ein LLM relevante Informationen liefern. Diese Daten könnten Details wie die Anzahl der Ärzte, die der Patient innerhalb eines Jahres aufgesucht hat, enthalten, es könnte jedoch schwierig sein, anzugeben, welche Behandlungen jeder Arzt verschrieben hat.

GraphRAG, das 2024 von Microsoft Research eingeführt wurde, geht diese Herausforderung an, indem es Beziehungen mittels Wissensgraphen verarbeitet und identifiziert. GraphRAG organisiert Informationen als Netzwerk von Knoten und Edge, die Entitäten und deren Beziehungen zueinander repräsentieren.

„Wenn ein Patient in ein Krankenhaus gegangen ist und die Frage lautet: Zeigen Sie mir alle seine vorherigen Besuche – das kann nicht nur in Worten, sondern als Wissensrepräsentation mittels eines Graphen dargestellt werden“, erklärte Nirmal. „Man kann sich verschiedene Punkte ansehen und die verschiedenen Ärzte, die er aufgesucht hat, die verschiedenen Medikamente, die er eingenommen hat, die Behandlungen, denen er sich unterzogen hat – alles in einer einzigen grafischen Darstellung.“

GraphRAG hat, wie Nirmal anmerkte, seine Grenzen, da die Darstellung eines Graphen mit zunehmendem Datenvolumen schwieriger wird. Die Kartierung von Hunderttausenden von Knoten ist eine größere Herausforderung als beispielsweise die Kartierung von nur ein paar Dutzend Knoten. „Alles hat Einschränkungen“, sagte Nirmal, „aber der Grund, warum GraphRag so richtig durchstartet, sind die Einschränkungen von reinem RAG selbst.“

Mehr erfahren über GraphRAG.

Chunking ist für RAG-Anwendungen entscheidend. Beim traditionellen Chunking durch Embedding-Modelle werden relevante Dokumente an festen Punkten in kleinere Teile zerlegt, die jeweils in einer Vektordatenbank dargestellt sind. Diese Methode kann jedoch dazu führen, dass eine LLM-Anwendung unvollständige oder ungenaue Antworten liefert, selbst wenn sie einen semantischen Suchalgorithmus für maschinelles Lernen auf einer domänenspezifischen Wissensdatenbank verwendet.

„Bei diesem Prozess geht oft die Genauigkeit verloren, weil man nicht weiß, wo man die Daten in Abschnitte unterteilt“, erklärte Nirmal. „Sagen wir, Sie teilen einen Tisch in der Mitte, sodass Sie beim Zurückbringen des Tisches nur noch die Hälfte des Tisches mitbringen.“ Jetzt haben Sie die Genauigkeit verloren.“

Glücklicherweise können bessere Chunking-Strategien durch Agentenmethoden die Informationsabfrage verbessern. Dieses agentenbasierte Chunking umfasst Strategien wie die Erstellung überlappender Chunks und die dynamische Änderung der Chunk-Größe auf der Grundlage des Kontexts der abgerufenen Dokumente. Orchestrierungsframeworks für LLM können für diesen Zweck hilfreich sein. Zum Beispiel können die TextSplitters-Tools von LangChainText in kleine, semantisch aussagekräftige Abschnitte unterteilen. Solche Strategien helfen, den Verlust relevanter Informationen zu vermeiden, wenn ein Dokument zerlegt wird.

Erfahren Sie mehr über Agentic Chunking.

Agentische KI ist hilfreich beim Chunking und kann die Abrufgenauigkeit auch auf andere Weise verbessern. Betrachten wir agentisches RAG: Es ist ein fortschrittliches KI-Framework, das RAG-Pipelines integrieren kann, um sowohl strukturierte Daten in SQL-Datenbanken als auch unstrukturierte Daten in Dokumentenrepositorien abzufragen und Vektordatenbanken für die Ähnlichkeitssuche zu nutzen. 

Agentic RAG bereichert jeden Chunk zudem mit Metadaten. Dieser Prozess korreliert strukturierte Daten (die Metadaten, die in einer transaktionalen Datenbank gespeichert sind) mit unstrukturierten Daten, um die Abrufgenauigkeit zu optimieren.

„Wenn wir die Power einer Vektordatenbank mit dem Transaktions- oder SQL-Aspekt kombinieren und diese beiden Aspekte zusammenführen können“, sagte Nirmal, „können wir die Genauigkeit und die Leistung deutlich steigern.“

Erfahren Sie, was Sie tun müssen, um die drei zentralen Herausforderungen unstrukturierter Daten zu meistern.

Datenlecks sind ein bekanntes Problem bei KI-Systemen im Allgemeinen, und LLMs, die RAG verwenden, bilden da keine Ausnahme. Ohne die richtigen Maßnahmen könnte ein LLM niedrigrangigen Nutzern Informationen bereitstellen, auf die sie keinen Zugriff haben, von personenbezogenen Daten (PII) bis hin zu sensiblen Finanzdaten.

„Das ist bei RAG Realität“, sagt Kairali. „Wenn man mit dem Proof-of-Concept beginnt, sind alle zufrieden. Doch wenn man das Produkt dann in die Produktion überführen und sicherstellen will, dass es produktionsreif ist, merkt man, dass es ein Datenschutzproblem gibt.“

Die Lösung des Problems bedeutet, dass Zugriffskontrolllisten (Access Control Lists, ACLs) und andere Governance-Richtlinien beibehalten werden, wenn unstrukturierte Daten in mehrere Datenbanken aufgenommen werden. „Wenn die Anfrage eingeht und Daten abgerufen werden, ist es wichtig sicherzustellen, dass die Zugriffskontrolllisten (ACLs) und die Governance-Richtlinien eingehalten werden“, sagte Kairali. „Es ist im Grunde ein technisches Problem.“

Die Lösung dieses technischen Problems kann mit den richtigen Datenplattformen erleichtert werden, wie z. B. verwaltete, Open-Source-fähige Data Lakehouses. Zum Beispiel sorgt watsonx.data® von IBM, ein hybrides, offenes Data Lakehouse, dafür, dass Zugriffskontrollen von Dokumentquellensystemen übernommen werden, wenn Daten abgerufen werden. Es bietet außerdem die Möglichkeit, personenbezogene Daten zu kennzeichnen, um die Weitergabe sensibler Informationen zu verhindern.

Wenn LLMs und andere generative KI-Systeme immer stärker in alltägliche Workflows integriert werden, hilft die Verbesserung von RAG Unternehmen dabei, einen größeren Nutzen aus ihren Unternehmensdaten zu freischalten. „Die richtigen Tools und Strategien auf Unternehmensebene ermöglichen eine höhere Leistung und Genauigkeit, sodass Daten überschaubar und wertvoll werden“, sagte Nirmal. „Das ist es, wonach jeder Kunde sucht.“