Wann sollte eine KI aufhören, ihrem eigenen Wissen zu vertrauen? — Der Retrieval-Trigger

Frage

Wann sollte eine KI aufhören, sich auf das zu verlassen, was sie bereits weiß, und externe Informationen abrufen, bevor sie antwortet?

Diese Frage erscheint einfach, aber sie steht im Zentrum einer der wichtigsten Designentscheidungen in modernen KI-Systemen.

Große Sprachmodelle enthalten umfangreiches Wissen in ihren Parametern. Retrieval-Augmented Generation fügt zur Laufzeit externe Informationen hinzu. Aber keiner der beiden Extreme ist ideal.

Sich immer auf das Modell zu verlassen, kann veraltete oder nicht belegte Antworten liefern. Immer Informationen abzurufen, erhöht Latenz, Kosten, irrelevanten Kontext und neue Möglichkeiten für Abruffehler.

Das eigentliche Problem kommt daher vor RAG: Wann sollte überhaupt ein Abruf stattfinden?

Dieser Artikel verwendet den Begriff Retrieval Trigger für diese Entscheidung. Retrieval Trigger wird hier nicht als standardisierter Begriff aus der Forschungsliteratur präsentiert. Es ist ein praktisches Systemkonzept, das Ideen zusammenbringt, die bereits in der Forschung zu aktivem, adaptivem und selbstreflektierendem Retrieval sichtbar sind.

Ein Retrieval Trigger ist eine Bedingung, die anzeigt, dass ein KI-System aufhören sollte, sich ausschließlich auf internes Modellwissen zu verlassen, und externe Belege beschaffen sollte, bevor es eine Antwort erzeugt oder finalisiert.— Arbeitsdefinition

Was das wirklich bedeutet

Ein LLM hat zwei grundlegend unterschiedliche Möglichkeiten, Informationen zu erhalten.

Die erste ist Modellwissen. Das sind Informationen, die in den gelernten Parametern des Modells repräsentiert sind. Zur Laufzeit ist keine Datenbankabfrage, Websuche oder Dokumentensuche erforderlich.

Die zweite ist Laufzeitwissen. Das sind Informationen, die bereitgestellt werden, während das Modell arbeitet: Suchergebnisse, Datenbankeinträge, Dokumente, APIs, Benutzerdateien, Tool-Ausgaben oder andere abgerufene Belege.

RAG verbindet diese beiden Welten. Aber RAG selbst beantwortet nicht die Frage, wann diese Verbindung aktiviert werden sollte. Das ist der Zweck des Retrieval Trigger.

Question
   ↓
Model Knowledge
   ↓
Is internal knowledge sufficient?
   ↓
Retrieval Trigger
   ↓
External Retrieval, if required
   ↓
Evidence
   ↓
Reasoning
   ↓
Answer Validity Boundary
   ↓
Answer

Der Retrieval Trigger liegt daher vor dem Abruf. Die Answer Validity Boundary liegt später.

Der erste fragt: Brauche ich externe Belege?

Der zweite fragt: Habe ich jetzt genug Belege, um diese Antwort zu stützen?

Dies sind verwandte Entscheidungen, aber sie sind nicht dieselbe Entscheidung.

Einfachstes Beispiel

Betrachten Sie drei Fragen.

Die erste Frage basiert auf einer äußerst stabilen Tatsache.

User
↓
"What is the capital of France?"

Model knowledge
↓
Paris

Fresh external evidence required?
↓
No

Answer
↓
Paris

Das Abrufen von Dokumenten vor der Antwort würde normalerweise wenig Wert bringen.

Betrachten Sie nun eine Frage, deren Antwort sich ständig ändert.

User
↓
"What is the current NVIDIA stock price?"

Model knowledge
↓
Potentially outdated

Current information required?
↓
Yes

RETRIEVAL TRIGGER
↓
Market data / search / API
↓
Answer

Das Modell mag viel über NVIDIA wissen. Das bedeutet nicht, dass es den aktuellen Kurs kennt.

Das dritte Beispiel ist noch wichtiger.

User
↓
"Does this new scientific paper prove that X causes Y?"

Model knowledge
↓
Can reason about causality,
statistics and scientific methodology.

But:
the actual evidence is not available internally.

RETRIEVAL TRIGGER
↓
Retrieve the paper
↓
Inspect methodology
↓
Inspect results
↓
Compare claim with evidence
↓
Answer Validity Boundary
↓
Answer

Die Schlussfolgerungsfähigkeit des Modells mag durchaus nützlich sein. Die fehlende Komponente sind Beweise.

Diese Unterscheidung ist grundlegend.

Wo das Beispiel nicht mehr funktioniert

Die obigen Beispiele lassen die Entscheidung binär erscheinen: abrufen oder nicht abrufen.

Reale Systeme sind komplizierter. Eine Frage kann mehrere Behauptungen enthalten, einige stabil und einige aktuell. Abgerufene Dokumente können widersprüchlich sein. Ein Retriever kann irrelevante Informationen zurückgeben. Die relevanten Informationen können existieren, aber nicht hoch genug eingestuft werden. Ein Dokument kann maßgeblich, aber veraltet sein.

Der Abruf selbst kann auch falschen Kontext in eine ansonsten vernünftige Antwort einführen.

Deshalb sollte Retrieval nicht als automatisches Synonym für Wahrheit behandelt werden.

Die Forschung zum adaptiven Retrieval hat sich zunehmend von der Annahme entfernt, dass jede Anfrage dieselbe Retrieval-Strategie erhalten sollte.

Self-RAG beispielsweise untersucht explizit Retrieval auf Abruf statt unterschiedslos eine feste Anzahl von Passagen für jede Eingabe abzurufen. Die Autoren diskutieren, wie unnötiges oder irrelevantes Retrieval die Antwortqualität verringern kann.

Adaptive-RAG wählt ebenfalls zwischen keinem Retrieval, einstufigem Retrieval und komplexeren Retrieval-Strategien je nach Fragekomplexität.

Die wichtige Frage ist also nicht: Hat dieses System RAG?

Sie lautet: Kann dieses System erkennen, wann Retrieval notwendig ist und welche Art von Retrieval angemessen ist?

Direkte Antwort

Eine KI sollte Retrieval auslösen, wenn die Beantwortung Informationen erfordert, die ihr internes Modellwissen nicht sicher mit der erforderlichen Aktualität, Spezifität, Herkunft oder Evidenz bereitstellen kann.

In praktischen Systemen kann ein Retrieval-Trigger aus mehreren Bedingungen entstehen:

Need for current information
        OR
Need for exact source-specific information
        OR
Need for evidence or provenance
        OR
Need for private/user-specific information
        OR
Insufficient knowledge coverage
        OR
Conflicting evidence
        OR
High consequence of factual error

Wenn keine dieser Bedingungen wesentlich vorliegt, kann Retrieval unnötig sein. Wenn eine oder mehrere vorliegen, wird externe Evidenz Teil des Antwortgenerierungsprozesses.

Warum das so ist

Das interne Wissen eines Sprachmodells wird oft als parametrisches Wissen bezeichnet. Es wurde während des Trainings gelernt und in die Parameter des Modells kodiert.

Lewis et al.s ursprüngliche RAG-Arbeit rahmte Retrieval als Kombination dieses parametrischen Gedächtnisses mit externem, nicht-parametrischem Gedächtnis. Das externe Gedächtnis kann durchsucht und aktualisiert werden, ohne das gesamte Sprachmodell neu zu trainieren.

Diese Unterscheidung schafft ein unvermeidbares Systemproblem.

Das Modell kann Dinge wissen. Aber das Modell kann nicht annehmen, dass alles, was es weiß, aktuell, vollständig, spezifisch genug und durch die erforderliche Evidenz gestützt ist.

Ein Modell kann daher eine sprachlich überzeugende Antwort produzieren, während es immer noch über den Punkt hinaus operiert, an dem sein internes Wissen ausreichend ist.

Dieser Punkt ist der, an dem ein Retrieval-Trigger nützlich wird.

Kontext

Traditionelles RAG sieht oft so aus:

Question
↓
Retrieve documents
↓
Add documents to context
↓
Generate answer

Diese Architektur geht von einer Abfrage vor der Generierung aus. Das funktioniert gut für viele wissensintensive Anwendungen, kann aber auch unnötige Abfragen durchführen.

Fortschrittlichere Ansätze führen einen adaptiven Schritt ein:

Question
↓
Evaluate information requirement
↓
        ┌───────────────┐
        │               │
   no retrieval      retrieval
        │               │
        ↓               ↓
 model knowledge    external evidence
        │               │
        └───────┬───────┘
                ↓
              answer

FLARE geht weiter, indem es die Abfrage während der Generierung selbst berücksichtigt. Es verwendet die bevorstehende Generierung und Token mit geringer Konfidenz als Signale für die Abfrage zusätzlicher Informationen.

Self-RAG führt ebenfalls Mechanismen ein, die es Abfrage, Generierung und Kritik ermöglichen, zu interagieren, anstatt die Abfrage als unbedingten Vorverarbeitungsschritt zu behandeln.

Adaptive-RAG nähert sich demselben übergeordneten Problem aus der Perspektive der Abfragekomplexität: Verschiedene Fragen können unterschiedliche Abfragestrategien erfordern.

Diese Ansätze unterscheiden sich technisch. Aber sie offenbaren dieselbe architektonische Erkenntnis: Die Abfrage sollte eine Entscheidung sein, nicht nur ein dauerhafter Schalter.

Annahmen

Das Retrieval-Trigger-Framework geht davon aus, dass ein System Zugriff auf mindestens eine externe Informationsquelle hat, wenn eine Abfrage erforderlich ist.

Diese Quelle könnte eine Websuche, ein Dokumentenspeicher, eine Vektordatenbank, eine SQL-Datenbank, ein Wissensgraph, eine API, ein Unternehmenssystem, ein vom Benutzer hochgeladenes Dokument oder eine Tool-Ausgabe sein.

Es wird auch davon ausgegangen, dass die Abfrage Kosten verursacht. Diese Kosten müssen nicht finanzieller Natur sein.

Die Abfrage führt zu Latenz, Token-Verbrauch, Kontextnutzung, Infrastrukturkomplexität und der Möglichkeit, irreführende Informationen abzurufen.

Das optimale System maximiert daher nicht die Abfrage. Es maximiert die angemessene Abfrage.

Variablen

Ein praktischer Retrieval-Trigger kann fünf primäre Variablen berücksichtigen.

Aktualität

Wie wahrscheinlich ist es, dass sich die erforderliche Information geändert hat? Die Hauptstadt von Frankreich hat eine sehr geringe Volatilität. Ein Aktienkurs hat eine extrem hohe Volatilität.

Spezifität

Erfordert die Frage Informationen aus einer bestimmten Quelle, einem Dokument, einer Organisation, einem Konto oder einem Datensatz? Wenn der Benutzer fragt, was ein bestimmter Vertrag besagt, ist allgemeines Modellwissen irrelevant. Der Vertrag muss abgerufen werden.

Nachweisanforderung

Benötigt die Antwort eine Herkunftsangabe? Ein Modell weiß möglicherweise, dass eine Behauptung allgemein akzeptiert wird, benötigt aber dennoch eine Quelle, wenn die Aufgabe eine Überprüfung erfordert.

Wissensabdeckung

Ist das Thema wahrscheinlich angemessen im internen Modellwissen repräsentiert? Seltene, proprietäre, stark lokale oder neu veröffentlichte Informationen erzeugen einen stärkeren Abrufdruck.

Folgen eines Fehlers

Nicht jede falsche Antwort hat die gleiche Auswirkung. Wenn die faktische Genauigkeit eine Entscheidung wesentlich beeinflusst, kann die akzeptable Nachweisschwelle höher sein.

Diese Variablen müssen nicht als wörtliche numerische Werte implementiert werden. Sie beschreiben die Entscheidungsfläche.

Diagnose- / Entscheidungsmethode

Ein sehr einfacher Retrieval-Trigger kann ohne maschinelles Lernen implementiert werden.

def should_retrieve(
    time_sensitive=False,
    source_specific=False,
    evidence_required=False,
    private_context=False,
    knowledge_uncertain=False,
    conflicting_information=False
):
    return any([
        time_sensitive,
        source_specific,
        evidence_required,
        private_context,
        knowledge_uncertain,
        conflicting_information,
    ])

Für eine stabile Faktenfrage:

should_retrieve()
# False

Für einen aktuellen Aktienkurs:

should_retrieve(
    time_sensitive=True
)
# True

Für eine wissenschaftliche Behauptung:

should_retrieve(
    source_specific=True,
    evidence_required=True
)
# True

Produktionssysteme können diese Entscheidung weitaus ausgefeilter treffen. Ein Klassifikator könnte den Abrufbedarf vorhersagen. Ein Modell könnte spezielle Steuertoken ausgeben. Ein Router könnte die Abfragekomplexität klassifizieren. Der Abruf könnte auch während der Generierung wiederholt ausgelöst werden.

Die Implementierung kann sich ändern. Die architektonische Frage bleibt dieselbe:

Sind die dem Modell derzeit verfügbaren Belege ausreichend für die Antwort, die es gerade produzieren will?

Belege

Das hier vorgeschlagene Konzept steht im Einklang mit mehreren Forschungsrichtungen zum Abruf.

Die ursprüngliche RAG-Architektur zeigte den Nutzen der Kombination von parametrischem Modellwissen mit externem nicht-parametrischem Wissen, insbesondere für wissensintensive Aufgaben.

FLARE untersucht explizit den aktiven Abruf während der Generierung, einschließlich eines Abrufs, der durch bevorstehende Inhalte mit geringer Konfidenz ausgelöst wird.

Self-RAG demonstriert eine Architektur, in der ein Abruf bei Bedarf erfolgen kann und auf die ein Nachdenken über die abgerufenen Passagen und den generierten Inhalt folgt.

Adaptive-RAG wählt dynamisch zwischen verschiedenen Strategien je nach Fragekomplexität, einschließlich Situationen, in denen kein Abruf erforderlich ist.

Der Begriff Retrieval Trigger wird hier als systemweite Abstraktion über diese breitere Familie von Entscheidungen verwendet.

Es wird nicht behauptet, dass diese Arbeiten dieselbe Terminologie verwenden. Stattdessen wird das gemeinsame architektonische Problem identifiziert: Was veranlasst ein KI-System, von internem Wissen zu externen Belegen überzugehen?

Reale Beispiele

Betrachten Sie einen Support-Assistenten, der mit der Dokumentation eines Unternehmens verbunden ist.

"How do I reset my password?"

Wenn das Verfahren stabil und zuverlässig in den aktuellen Anweisungen des Assistenten dargestellt ist, kann eine direkte Antwort angemessen sein.

"What permissions does my account currently have?"

Diese Informationen sind benutzerspezifisch und dynamisch. Der Retrieval-Trigger wird ausgelöst. Das System muss die tatsächlichen Konto- oder Autorisierungsdaten überprüfen.

"Why was my production deployment rejected yesterday?"

Das Modell kann Bereitstellungssysteme verstehen und häufige Gründe erklären. Die Frage bezieht sich jedoch auf ein bestimmtes Ereignis. Protokolle, CI/CD-Ausgaben oder Vorfallberichte sind erforderlich.

Dieselbe Logik gilt für die Websuche.

"What is RAG?"

Eine allgemeine Erklärung erfordert möglicherweise keinen Abruf.

"What did the authors of Self-RAG specifically conclude about unnecessary retrieval?"

Jetzt sind quellenspezifische Belege erforderlich.

"What is the latest research on adaptive retrieval?"

Dies führt auch eine Aktualitätsanforderung ein. Das zugrunde liegende Thema hat sich nicht geändert. Der Informationsbedarf hat sich geändert.

Häufige Missverständnisse und Fehlermodi

Mehr Abruf führt automatisch zu einer besseren Antwort. Das ist nicht der Fall. Irrelevante Dokumente verbrauchen Kontext und können die Generierung ablenken.

Hohe Modellkonfidenz bedeutet, dass ein Abruf unnötig ist. Ein Modell kann selbstsicher eine falsche Antwort geben. Selbstberichtete Konfidenz sollte daher nicht als einziger Auslöser behandelt werden.

Erfolgreicher Abruf bedeutet, dass die Antwort verifiziert ist. Der Abruf liefert nur Kandidatenbelege. Die Belege müssen weiterhin relevant, ausreichend autoritativ und korrekt interpretiert sein.

RAG löst automatisch veraltetes Wissen. Das tut es nur, wenn der Abrufkorpus selbst aktuelle Informationen enthält. Das Abrufen eines veralteten Dokuments erzeugt keine aktuelle Antwort.

Ein Abrufschritt ist immer ausreichend. Komplexe Fragen können mehrere Belege oder iterative Abrufe erfordern.

Randfälle

Einige Fragen enthalten sowohl stabile als auch instabile Informationen.

"Who founded NVIDIA, and what is its market capitalization today?"

Der erste Teil ist möglicherweise aus stabilem Modellwissen beantwortbar. Der zweite Teil erfordert aktuelle Informationen.

Ein ausreichend fähiges System sollte nicht unbedingt die gesamte Anfrage als eine einzige Retrieval-Entscheidung behandeln. Es kann Retrieval nur dort auslösen, wo es erforderlich ist.

Ein weiterer Randfall ist die Uneinigkeit zwischen Quellen. Angenommen, das Retrieval liefert drei Dokumente mit unvereinbaren Behauptungen zurück.

Der Retrieval-Trigger war bereits erfolgreich: Das System erkannte, dass externe Evidenz erforderlich war. Aber die Aufgabe ist nicht abgeschlossen.

Das System ist nun an einem Problem der Evidenzbewertung angelangt. Hier wird die Answer Validity Boundary wichtig.

Das System hat möglicherweise Informationen abgerufen und besitzt dennoch nicht genügend Evidenz, um eine starke Schlussfolgerung zu ziehen.

Retrieval Trigger
≠
permission to answer

Der Trigger beschafft Evidenz. Die Validitätsgrenze bestimmt, ob diese Evidenz ausreichend ist.

Einschränkungen

Der Retrieval-Trigger ist ein konzeptioneller Rahmen, kein universeller Algorithmus.

Verschiedene Systeme erfordern unterschiedliche Trigger-Regeln. Ein Kundensupport-Bot, ein wissenschaftlicher Rechercheassistent, eine Suchmaschine und ein autonomer Software-Agent haben keine identischen Evidenzanforderungen.

Trigger-Schwellenwerte können auch ihre eigenen Fehlermodi erzeugen. Ein zu niedriger Schwellenwert verursacht übermäßiges Retrieval. Ein zu hoher Schwellenwert verursacht nicht gestützte Antworten.

Auch die Retrieval-Infrastruktur selbst ist wichtig. Ein perfekter Trigger, der mit einer schlechten Quellensammlung verbunden ist, erzeugt immer noch schlechte Evidenz.

Ebenso bietet eine hervorragende Wissensbasis wenig Wert, wenn der Trigger nie aktiviert wird, wenn er benötigt wird.

Der Retrieval-Trigger löst daher nur einen Teil einer größeren Architektur.

Was würde diese Antwort ändern?

Zukünftige Modelle könnten bessere Mechanismen enthalten, um ihre eigenen Wissensgrenzen zu erkennen. Retriever könnten kostengünstiger und schneller werden. Langkontext-Systeme könnten weit mehr Quellenmaterial kontinuierlich mitführen.

Modelle könnten zunehmend auch Suche, Datenbanken, Tools und strukturiertes Wissen kombinieren, ohne dem Anwendungsentwickler eine eigenständige RAG-Phase offenzulegen.

Diese Änderungen könnten die Art und Weise verändern, wie der Trigger implementiert wird. Sie beseitigen nicht unbedingt die zugrunde liegende Entscheidung.

Solange es einen Unterschied zwischen Informationen gibt, die dem Modell bereits zur Verfügung stehen, und Informationen, die extern beschafft werden müssen, benötigt ein System weiterhin einen Mechanismus, um zu bestimmen, wann diese Grenze überschritten werden soll.

Die Implementierung mag aus dem Blickfeld verschwinden. Die architektonische Frage bleibt bestehen.

Fazit

RAG beginnt zu spät, um das gesamte Problem zu erklären.

Bevor ein Retrieval stattfinden kann, muss ein KI-System bestimmen, ob ein Retrieval notwendig ist. Diese Entscheidung ist der Retrieval-Trigger.

Stable known fact
→ answer from model knowledge

Current fact
→ retrieve

Source-specific or evidence-dependent claim
→ retrieve and verify

Doch die weiterreichende Implikation ist wichtiger. Zuverlässige KI benötigt nicht nur Zugang zu Wissen. Sie benötigt eine Methode, um festzustellen, wann ihr aktuelles Wissen unzureichend ist.

Model Knowledge
        ↓
Retrieval Trigger
        ↓
Runtime Knowledge / RAG
        ↓
Evidence
        ↓
Reasoning
        ↓
Answer Validity Boundary
        ↓
Answer

Der Retrieval-Trigger bestimmt, wann das System nach Belegen suchen sollte. Die Antwortgültigkeitsgrenze bestimmt, ob diese Belege ausreichend sind.

Zusammen beschreiben sie etwas Nützlicheres als RAG allein: einen Entscheidungsprozess, um von dem, was eine KI zu wissen scheint, zu dem zu gelangen, was sie tatsächlich stützen kann.

Primärquellen

Patrick Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (2020). Grundlegende RAG-Arbeit, die die Kombination von parametrischem Modellgedächtnis mit externem nicht-parametrischem Gedächtnis beschreibt.

Zhengbao Jiang et al., Active Retrieval Augmented Generation (2023). Führt FLARE und aktives Retrieval während der Generierung ein, einschließlich Retrieval basierend auf vorhergesagten Inhalten mit geringer Konfidenz.

Akari Asai et al., Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection (2023). Untersucht adaptives Retrieval auf Anfrage und Selbstreflexion anstelle von unbedingtem festem Retrieval.

Soyeong Jeong et al., Adaptive-RAG: Learning to Adapt Retrieval-Augmented Large Language Models through Question Complexity (2024). Wählt dynamisch zwischen keinem Retrieval, einstufigem Retrieval und komplexeren Retrieval-Strategien entsprechend der eingehenden Frage.