Faktenprüfung per KI: Ist Google mit "Generate - Ground" auf dem Holzweg?

Google verwendet zum Erzeugen seiner KI-Antworten vermutlich eine Technik, die im ersten Schritt eine Antwort vorbereitet, die dann mithilfe von Quellen aus dem Web ergänzt und dadurch angepasst wird. Es bestehen aber Zweifel, ob das der beste Weg für eine hohe Qualität der Antworten ist.

TL;DR: das Wichtigste in Kürze

Google setzt in der Suche sehr wahrscheinlich auf einen Ansatz, bei dem erst ein Textentwurf erzeugt und dieser dann mithilfe verschiedener Suchanfragen geprüft wird.
Das kann allerdings zu fehlerhaften Antworten führen.
Das Abrufen von Informationen vor dem Erzeugen von Antworten könnte sich als der bessere Weg erweisen.

Die Fähigkeit großer Sprachmodelle (LLMs), zusammenhängende und menschenähnliche Texte zu generieren, ist beeindruckend. Doch diese Modelle haben eine bekannte Schwäche: Sie können Fakten erfinden oder verfälschen, ein Phänomen, das oft als "Halluzination" bezeichnet wird.

Sie benötigen SEO-Beratung für Ihre Website?

Jetzt unverbindlich anfragen

Um dieses Problem anzugehen, wurden verschiedene Strategien entwickelt. Eine davon, der sogenannte "Generate - Ground"-Ansatz, wird unter anderem von Googles RARR (Retrofit Attribution using Research and Revision) verfolgt. Dieser Ansatz steht im Kontrast zu "Retrieve - Then - Generate"-Methoden wie RAG (Retrieval-Augmented Generation) und FiD (Fusion-in-Decoder).

Google nutzt zum Erzeugen von KI-Antworten und der Anreicherung mit Quellen und Links zum Beispiel für die Google AI Overviews sehr wahrscheinlich einen "Generate-Ground"-Ansatz. Dabei stellt sich die Frage, ob Google mit der Fokussierung auf "Generate - Ground" möglicherweise eine ungünstige Wahl getroffen hat.

Inspiriert ist dieser Beitrag von Dan Petrovics Artikel mit dem Titel: “I think Google got it wrong with Generate→Ground Approach”.

RARR: Generieren und nachträglich Fakten prüfen

RARR ist Ansatz, bei dem das Sprachmodell zunächst eine Antwort oder einen Textentwurf generiert und anschließend versucht, die darin enthaltenen Fakten zu überprüfen und gegebenenfalls zu korrigieren. Die Funktionsweise lässt sich in etwa wie folgt zusammenfassen:

Entwurf (Draft): Das LLM generiert eigenständig einen ersten Textentwurf, basierend auf seinem internen Wissen.
Query-Generierung (Query-auto-gen): Das Modell formuliert aus seinem eigenen Textentwurf Suchanfragen, um relevante Informationen im Internet zu finden.
Abrufen und Überarbeiten (Retrieve & Revise): Anhand der Suchergebnisse werden relevante Textpassagen abgerufen, die Fakten im ursprünglichen Entwurf überprüft und dieser gegebenenfalls korrigiert. Zudem werden Quellenangaben hinzugefügt.

Ein Vorteil von RARR ist, dass es relativ einfach in bestehende Sprachmodelle integriert werden kann, ohne diese neu trainieren zu müssen. Es kann auch den ursprünglichen Stil und die Struktur des generierten Textes beibehalten, während lediglich die Fakten korrigiert werden. Dies macht es zu einer potenziell schnellen Lösung, um die Faktentreue bestehender Produkte zu verbessern.

Allerdings birgt RARR auch einige Nachteile. Ein zentrales Problem ist die Abhängigkeit von der Qualität der generierten Suchanfragen. Wenn die Suchanfragen ungenau oder irrelevant sind, werden auch die abgerufenen Informationen wenig hilfreich sein, und die Faktenprüfung schlägt fehl. Dies kann zu einer Fehlerkaskade führen, bei der eine schlechte Anfrage zu falschen Beweisen und somit zu fehlerhaften Korrekturen führt. Zudem erfordert dieser Ansatz mehrere Durchläufe (Generierung, Suche, Überarbeitung), was zu einer höheren Latenz führen kann. Und schließlich besteht die Gefahr, dass RARR Fakten "korrigiert", indem es sie einfach löscht, wodurch wertvolle Nuancen im Text verloren gehen können.

RAG: Fakten abrufen und dann generieren

Im Gegensatz zu RARR kehrt der Ansatz der Retrieval-Augmented Generation (RAG) die Reihenfolge um. Hier werden relevante Informationen abgerufen, bevor das Sprachmodell die Antwort generiert. Die grundlegenden Schritte sind:

Abrufen (Retrieve): Basierend auf der Nutzerfrage oder dem Kontext werden zunächst relevante Dokumente oder Textpassagen aus einer externen Wissensdatenbank abgerufen. Hierbei kommen oft spezialisierte Retrieval-Modelle zum Einsatz, die die semantische Bedeutung der Anfrage erfassen.
Kontextualisierung: Die abgerufenen Informationen werden zusammen mit der ursprünglichen Anfrage in das Eingabefenster des Sprachmodells gegeben.
Generierung (Generate): Das LLM generiert nun seine Antwort oder den gewünschten Text, wobei es sich auf den bereitgestellten Kontext stützen kann und sollte.

Ein wesentlicher Vorteil von RAG ist die verbesserte Faktentreue. Weil das Modell seine Antwort auf realen, abgerufenen Texten aufbaut, ist die Wahrscheinlichkeit von Halluzinationen geringer. Zudem entfällt die fehleranfällige Generierung von Suchanfragen durch das LLM selbst. Die Latenz kann geringer sein, weil in der Regel nur ein Generierungsdurchlauf erforderlich ist. Außerdem kann das Modell bei fehlenden relevanten Informationen frühzeitig signalisieren, dass es die Frage nicht beantworten kann.

Ein potenzieller Nachteil von RAG liegt in der Qualität des Retrieval-Systems. Wenn irrelevante oder unzureichende Informationen abgerufen werden, kann auch die generierte Antwort darunter leiden.

FiD: Fusion-in-Decoder als Weiterentwicklung von RAG

Fusion-in-Decoder (FiD) kann als eine Weiterentwicklung des RAG-Ansatzes betrachtet werden. Es verbessert die Nutzung mehrerer abgerufener Textpassagen. Die Funktionsweise umfasst:

Separates Enkodieren: Jede der abgerufenen Textpassagen wird einzeln durch den Enkodierer des Modells verarbeitet.
Fusionsmechanismus: Der Dekodierer des Modells verfügt über einen Mechanismus, der die Informationen aus allen enkodierten Passagen durch sogenannte Cross-Attention-Mechanismen zusammenführt ("fusioniert").
Generierung: Basierend auf der fusionierten Information generiert der Dekodierer die Antwort.

FiD ermöglicht eine bessere Nutzung der bereitgestellten Evidenz, insbesondere wenn mehrere relevante Passagen existieren, die unterschiedliche Aspekte der Frage beleuchten. Das kann zu einer noch höheren faktischen Genauigkeit führen als bei einfacheren RAG-Implementierungen.

Warum Googles Fokus auf RARR möglicherweise problematisch ist

Obwohl RARR eine pragmatische Lösung für die kurzfristige Verbesserung der Faktentreue darstellen mag, deuten mehrere Aspekte darauf hin, dass Google mit einer primären Ausrichtung auf diesen "Generate - Ground"-Ansatz möglicherweise eine weniger zukunftssichere Wahl getroffen hat.

Die zentrale Schwachstelle der Query-Generierung in RARR verursacht ein erhebliches Risiko für falsche Antworten. Eine fehlerhafte Suchanfrage kann den gesamten Faktencheck-Prozess untergraben und zu falschen oder irrelevanten Ergebnissen führen. Im Gegensatz dazu nutzt RAG die direkte Nutzerintention für den Abruf relevanter Informationen, was diesen potenziellen Fehlerpunkt eliminiert.

Die höhere Latenz von RARR durch die sequentiellen Schritte der Generierung, Suche und Überarbeitung ist ein weiterer Nachteil, insbesondere für nutzerorientierte Anwendungen, bei denen schnelle Reaktionszeiten entscheidend sind.

Zudem besteht bei RARR die Gefahr, dass der ursprüngliche Sinn und die stilistische Konsistenz des generierten Textes durch das nachträgliche Editieren verloren gehen. Das einfache Löschen unbestätigter Fakten, um die Attributionsrate zu erhöhen, kann zu inhaltlich reduzierten oder vom ursprünglichen Sinn abweichenden Antworten führen.

Die Forschung und Entwicklung im Bereich der generativen KI verschiebt sich zunehmend in Richtung integrierter Retrieval- und Generierungsansätze wie RAG und FiD. Diese Methoden scheinen eine robustere Grundlage für die Erzeugung faktisch korrekter und nachvollziehbarer Texte zu bieten, weil die relevanten Informationen bereits vor der Generierung in den Kontext des Modells einfließen.. RARR hingegen kann als ein "Pflaster" oder Workaround betrachtet werden, das zwar kurzfristig helfen mag, aber die fundamentalen Herausforderungen der Faktentreue in LLMs nicht so effektiv angeht wie Retrieval-First-Ansätze.

Fazit

Während Googles RARR-Ansatz eine Möglichkeit bietet, die Faktentreue bestehender Sprachmodelle nachträglich zu verbessern, deuten die potenziellen Nachteile in Bezug auf Fehleranfälligkeit, Latenz und Verlust der ursprünglichen Intention darauf hin, dass eine stärkere Fokussierung auf "Retrieve - Then - Generate"-Methoden wie RAG und FiD langfristig die robustere Strategie für die Erzeugung verlässlicher und faktisch korrekter Texte sein könnte.

Quellen