Quand une IA devrait-elle cesser de faire confiance à ses propres connaissances ? — Le déclencheur de récupération

Question

Quand une IA devrait-elle cesser de s'appuyer sur ce qu'elle sait déjà et récupérer des informations externes avant de répondre ?

Cette question semble simple, mais elle se situe au cœur de l'une des décisions de conception les plus importantes des systèmes d'IA modernes.

Les grands modèles de langage contiennent des connaissances substantielles dans leurs paramètres. La génération augmentée par récupération ajoute des informations externes à l'exécution. Mais aucun des deux extrêmes n'est idéal.

Toujours faire confiance au modèle peut produire des réponses obsolètes ou non étayées. Toujours récupérer des informations ajoute de la latence, du coût, un contexte non pertinent et de nouvelles possibilités d'erreurs de récupération.

Le véritable problème se situe donc avant le RAG : quand la récupération doit-elle avoir lieu ?

Cet article utilise le terme Déclencheur de récupération pour cette décision. Le Déclencheur de récupération n'est pas présenté ici comme un terme normalisé issu de la littérature de recherche. C'est un concept système pratique qui rassemble des idées déjà visibles dans la recherche sur la récupération active, adaptative et auto-réflexive.

Un Déclencheur de récupération est une condition indiquant qu'un système d'IA devrait cesser de s'appuyer uniquement sur les connaissances internes du modèle et obtenir des preuves externes avant de produire ou de finaliser une réponse.— Définition de travail

Ce que cela signifie vraiment

Un LLM dispose de deux manières fondamentalement différentes d'obtenir des informations.

La première est la connaissance du modèle. Il s'agit d'informations représentées dans les paramètres appris du modèle. Aucune requête de base de données, recherche web ou consultation de documents n'est nécessaire à l'exécution.

La seconde est la connaissance à l'exécution. Il s'agit d'informations fournies pendant que le modèle fonctionne : résultats de recherche, enregistrements de base de données, documents, API, fichiers utilisateur, sorties d'outils ou autres preuves récupérées.

Le RAG relie ces deux mondes. Mais le RAG lui-même ne répond pas à la question de savoir quand cette connexion doit être activée. C'est le rôle du Déclencheur de récupération.

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

Le Déclencheur de récupération se situe donc avant la récupération. La Limite de validité de la réponse intervient plus tard.

La première demande : Ai-je besoin de preuves externes ?

La seconde demande : Ai-je maintenant suffisamment de preuves pour étayer cette réponse ?

Ce sont des décisions liées, mais ce ne sont pas la même décision.

Exemple le plus simple

Considérez trois questions.

La première question repose sur un fait très stable.

User
↓
"What is the capital of France?"

Model knowledge
↓
Paris

Fresh external evidence required?
↓
No

Answer
↓
Paris

Récupérer des documents avant de répondre n'apporterait généralement que peu de valeur.

Considérez maintenant une question dont la réponse change continuellement.

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

Model knowledge
↓
Potentially outdated

Current information required?
↓
Yes

RETRIEVAL TRIGGER
↓
Market data / search / API
↓
Answer

Le modèle peut en savoir beaucoup sur NVIDIA. Cela ne signifie pas qu'il connaît le prix actuel.

Le troisième exemple est encore plus important.

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

La capacité de raisonnement du modèle peut être parfaitement utile. L'élément manquant est la preuve.

Cette distinction est fondamentale.

Où l'exemple cesse de fonctionner

Les exemples ci-dessus font apparaître la décision comme binaire : récupérer ou ne pas récupérer.

Les systèmes réels sont plus compliqués. Une question peut contenir plusieurs affirmations, certaines stables et d'autres actuelles. Les documents récupérés peuvent être contradictoires. Un récupérateur peut renvoyer des informations non pertinentes. L'information pertinente peut exister mais ne pas être classée assez haut. Un document peut être faisant autorité mais obsolète.

La récupération elle-même peut également introduire un contexte incorrect dans une réponse par ailleurs raisonnable.

C'est pourquoi la récupération ne doit pas être traitée comme un synonyme automatique de vérité.

La recherche sur la récupération adaptative s'est de plus en plus éloignée de l'hypothèse selon laquelle chaque requête devrait recevoir la même stratégie de récupération.

Self-RAG, par exemple, explore explicitement la récupération à la demande plutôt que de récupérer de manière indiscriminée un nombre fixe de passages pour chaque entrée. Les auteurs discutent de la manière dont une récupération inutile ou non pertinente peut réduire la qualité des réponses.

Adaptive-RAG sélectionne de même entre l'absence de récupération, la récupération en une étape et des stratégies de récupération plus complexes selon la complexité de la question.

La question importante n'est donc pas : Ce système dispose-t-il de RAG ?

C'est : Ce système peut-il reconnaître quand la récupération est nécessaire et quel type de récupération est approprié ?

Réponse directe

Une IA devrait déclencher la récupération lorsque la réponse nécessite des informations que les connaissances internes de son modèle ne peuvent pas fournir de manière sûre avec la fraîcheur, la spécificité, la provenance ou le support probatoire requis.

Dans les systèmes pratiques, un déclencheur de récupération peut émerger de plusieurs conditions :

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

Si aucune de ces conditions n'est matériellement présente, la récupération peut être inutile. Si une ou plusieurs sont présentes, les preuves externes font partie du processus de génération de la réponse.

Pourquoi il en est ainsi

Les connaissances internes d'un modèle de langage sont souvent décrites comme des connaissances paramétriques. Elles ont été apprises pendant l'entraînement et encodées dans les paramètres du modèle.

Le travail original de Lewis et al. sur le RAG a présenté la récupération comme une combinaison de cette mémoire paramétrique avec une mémoire externe non paramétrique. La mémoire externe peut être recherchée et mise à jour sans réentraîner l'ensemble du modèle de langage.

Cette distinction crée un problème systémique inévitable.

Le modèle peut savoir des choses. Mais le modèle ne peut pas supposer que tout ce qu'il sait est actuel, complet, suffisamment spécifique et soutenu par les preuves requises.

Un modèle peut donc produire une réponse linguistiquement convaincante tout en opérant au-delà du point où ses connaissances internes sont suffisantes.

C'est à ce point qu'un déclencheur de récupération devient utile.

Contexte

Le RAG traditionnel ressemble souvent à ceci :

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

Cette architecture suppose une récupération avant la génération. Cela fonctionne bien pour de nombreuses applications à forte intensité de connaissances, mais elle peut aussi effectuer une récupération inutile.

Des approches plus avancées introduisent une étape adaptative :

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

FLARE va plus loin en considérant la récupération pendant la génération elle-même. Il utilise la génération à venir et les tokens à faible confiance comme signaux pour récupérer des informations supplémentaires.

Self-RAG introduit de même des mécanismes permettant à la récupération, la génération et la critique d'interagir au lieu de traiter la récupération comme une étape de prétraitement inconditionnelle.

Adaptive-RAG aborde le même problème plus large sous l'angle de la complexité des requêtes : différentes questions peuvent nécessiter différentes stratégies de récupération.

Ces approches diffèrent techniquement. Mais elles révèlent la même intuition architecturale : la récupération devrait être une décision, pas simplement un interrupteur permanent.

Hypothèses

Le cadre Retrieval Trigger suppose qu'un système a accès à au moins une source d'information externe lorsque la récupération est nécessaire.

Cette source pourrait être une recherche web, un stockage de documents, une base de données vectorielle, une base de données SQL, un graphe de connaissances, une API, un système d'entreprise, un document téléchargé par l'utilisateur ou une sortie d'outil.

Il suppose également que la récupération a un coût. Ce coût n'est pas nécessairement financier.

La récupération introduit de la latence, une consommation de tokens, une utilisation du contexte, une complexité d'infrastructure et la possibilité de récupérer des informations trompeuses.

Le système optimal ne maximise donc pas la récupération. Il maximise la récupération appropriée.

Variables

Un Retrieval Trigger pratique peut considérer cinq variables principales.

Fraîcheur

Quelle est la probabilité que l'information requise ait changé ? La capitale de la France a une très faible volatilité. Le cours d'une action a une volatilité extrêmement élevée.

Spécificité

La question nécessite-t-elle des informations provenant d'une source, d'un document, d'une organisation, d'un compte ou d'un ensemble de données particulier ? Si l'utilisateur demande ce que dit un contrat spécifique, les connaissances générales du modèle sont non pertinentes. Le contrat doit être récupéré.

Exigence de preuve

La réponse a-t-elle besoin d'une provenance ? Un modèle peut savoir qu'une affirmation est généralement acceptée mais avoir tout de même besoin d'une source lorsque la tâche exige une vérification.

Couverture des connaissances

Le sujet est-il susceptible d'être représenté adéquatement dans les connaissances internes du modèle ? Des informations rares, propriétaires, très locales ou nouvellement publiées créent une pression de récupération plus forte.

Conséquence d'une erreur

Toutes les réponses incorrectes n'ont pas le même impact. Lorsque l'exactitude factuelle affecte matériellement une décision, le seuil de preuve acceptable peut être plus élevé.

Ces variables n'ont pas besoin d'être implémentées sous forme de scores numériques littéraux. Elles décrivent la surface de décision.

Méthode de diagnostic / de décision

Un déclencheur de récupération très simple peut être implémenté sans apprentissage automatique.

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,
    ])

Pour une question factuelle stable :

should_retrieve()
# False

Pour un cours actuel :

should_retrieve(
    time_sensitive=True
)
# True

Pour une affirmation scientifique :

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

Les systèmes de production peuvent rendre cette décision bien plus sophistiquée. Un classifieur pourrait prédire les besoins de récupération. Un modèle pourrait émettre des jetons de contrôle spéciaux. Un routeur pourrait classifier la complexité de la requête. La récupération pourrait également être déclenchée de manière répétée pendant la génération.

L'implémentation peut changer. La question architecturale reste la même :

Les preuves actuellement disponibles pour le modèle sont-elles suffisantes pour la réponse qu'il s'apprête à produire ?

Preuves

Le concept proposé ici est cohérent avec plusieurs axes de recherche sur la récupération.

L'architecture RAG originale a démontré l'utilité de combiner les connaissances paramétriques d'un modèle avec des connaissances externes non paramétriques, en particulier pour les tâches à forte intensité de connaissances.

FLARE explore explicitement la récupération active pendant la génération, y compris la récupération déclenchée par un contenu à venir de faible confiance.

Self-RAG démontre une architecture dans laquelle la récupération peut se produire à la demande et est suivie d'une réflexion sur les passages récupérés et le contenu généré.

Adaptive-RAG choisit dynamiquement parmi différentes stratégies selon la complexité de la question, y compris les situations où aucune récupération n'est nécessaire.

Le terme Retrieval Trigger est utilisé ici comme une abstraction au niveau du système pour cette famille plus large de décisions.

Il ne prétend pas que ces articles utilisent la même terminologie. Il identifie plutôt le problème architectural commun : qu'est-ce qui amène un système d'IA à passer de connaissances internes à des preuves externes ?

Exemples réels

Considérez un assistant de support connecté à la documentation d'une entreprise.

"How do I reset my password?"

Si la procédure est stable et représentée de manière fiable dans les instructions actuelles de l'assistant, une réponse directe peut être appropriée.

"What permissions does my account currently have?"

Cette information est spécifique à l'utilisateur et dynamique. Le déclencheur de récupération se déclenche. Le système doit inspecter les données réelles du compte ou d'autorisation.

"Why was my production deployment rejected yesterday?"

Le modèle peut comprendre les systèmes de déploiement et expliquer les raisons courantes. Mais la question porte sur un événement particulier. Les journaux, la sortie CI/CD ou les enregistrements d'incidents sont nécessaires.

La même logique s'applique à la recherche web.

"What is RAG?"

Une explication générale peut ne pas nécessiter de récupération.

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

Maintenant, des preuves spécifiques à la source sont requises.

"What is the latest research on adaptive retrieval?"

Cela introduit également une exigence de fraîcheur. Le sujet sous-jacent n'a pas changé. L'exigence d'information a changé.

Idées fausses courantes et modes de défaillance

Plus de récupération produit automatiquement une meilleure réponse. Ce n'est pas le cas. Les documents non pertinents consomment du contexte et peuvent distraire la génération.

Une confiance élevée du modèle signifie que la récupération est inutile. Un modèle peut produire une réponse incorrecte avec assurance. La confiance auto-déclarée ne doit donc pas être traitée comme le seul déclencheur.

Une récupération réussie signifie que la réponse est vérifiée. La récupération ne fournit que des preuves candidates. Les preuves doivent encore être pertinentes, suffisamment faisant autorité et correctement interprétées.

Le RAG résout automatiquement les connaissances obsolètes. Il ne le fait que si le corpus de récupération lui-même contient des informations à jour. Récupérer un document obsolète ne crée pas une réponse actuelle.

Une étape de récupération suffit toujours. Les questions complexes peuvent nécessiter plusieurs éléments de preuve ou une récupération itérative.

Cas limites

Certaines questions contiennent à la fois des informations stables et instables.

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

La première partie peut être résolue à partir des connaissances stables du modèle. La seconde partie nécessite des informations actuelles.

Un système suffisamment capable ne devrait pas nécessairement traiter l'ensemble de la requête comme une seule décision de récupération. Il peut déclencher la récupération uniquement là où c'est nécessaire.

Un autre cas limite est le désaccord entre les sources. Supposons que la récupération renvoie trois documents contenant des affirmations incompatibles.

Le Déclencheur de Récupération a déjà réussi : le système a reconnu que des preuves externes étaient nécessaires. Mais la tâche n'est pas terminée.

Le système est maintenant confronté à un problème d'évaluation des preuves. C'est là que la Frontière de Validité de la Réponse devient importante.

Le système peut avoir récupéré des informations et ne pas encore posséder suffisamment de preuves pour tirer une conclusion solide.

Retrieval Trigger
≠
permission to answer

Le déclencheur obtient des preuves. La frontière de validité détermine si ces preuves sont suffisantes.

Limites

Le Déclencheur de Récupération est un cadre conceptuel, pas un algorithme universel.

Différents systèmes nécessiteront différentes règles de déclenchement. Un bot de support client, un assistant de recherche scientifique, un moteur de recherche et un agent logiciel autonome n'ont pas des exigences de preuves identiques.

Les seuils de déclenchement peuvent également créer leurs propres modes de défaillance. Un seuil trop bas provoque une récupération excessive. Un seuil trop élevé provoque des réponses non étayées.

L'infrastructure de récupération elle-même compte également. Un déclencheur parfait connecté à une mauvaise collection de sources produit toujours des preuves médiocres.

De même, une excellente base de connaissances offre peu de valeur si le déclencheur ne s'active jamais lorsqu'il est nécessaire.

Le Déclencheur de Récupération ne résout donc qu'une partie d'une architecture plus vaste.

Qu'est-ce qui changerait cette réponse ?

Les futurs modèles pourraient contenir de meilleurs mécanismes pour identifier leurs propres limites de connaissances. Les récupérateurs pourraient devenir moins chers et plus rapides. Les systèmes à long contexte pourraient transporter beaucoup plus de matériel source en continu.

Les modèles peuvent aussi de plus en plus combiner recherche, bases de données, outils et connaissances structurées sans exposer une étape RAG distincte au développeur d'application.

Ces changements pourraient modifier la façon dont le déclencheur est implémenté. Ils ne suppriment pas nécessairement la décision sous-jacente.

Tant qu'il existe une différence entre les informations déjà disponibles pour le modèle et les informations qui doivent être obtenues à l'extérieur, un système a encore besoin d'un mécanisme pour déterminer quand franchir cette frontière.

L'implémentation peut disparaître de la vue. La question architecturale demeure.

Conclusion

Le RAG commence trop tard pour expliquer tout le problème.

Avant que la récupération puisse avoir lieu, un système d'IA doit déterminer si la récupération est nécessaire. Cette décision est le Déclencheur de Récupération.

Stable known fact
→ answer from model knowledge

Current fact
→ retrieve

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

Mais l'implication plus large est plus importante. Une IA fiable n'a pas seulement besoin d'accéder à la connaissance. Elle a besoin d'une méthode pour déterminer quand sa connaissance actuelle est insuffisante.

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

Le Déclencheur de Récupération détermine quand le système doit chercher des preuves. La Frontière de Validité de la Réponse détermine si ces preuves sont suffisantes.

Ensemble, ils décrivent quelque chose de plus utile que le RAG seul : un processus de décision pour passer de ce qu'une IA semble savoir à ce qu'elle peut réellement soutenir.

Sources Primaires

Patrick Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (2020). Travail fondateur sur le RAG décrivant la combinaison de la mémoire paramétrique du modèle avec une mémoire externe non paramétrique.

Zhengbao Jiang et al., Active Retrieval Augmented Generation (2023). Introduit FLARE et la récupération active pendant la génération, y compris la récupération basée sur un contenu prédit à faible confiance.

Akari Asai et al., Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection (2023). Explore la récupération adaptative à la demande et l'auto-réflexion au lieu d'une récupération fixe inconditionnelle.

Soyeong Jeong et al., Adaptive-RAG: Learning to Adapt Retrieval-Augmented Large Language Models through Question Complexity (2024). Sélectionne dynamiquement entre aucune récupération, une récupération en une étape et des stratégies de récupération plus complexes selon la question entrante.