Passer au contenu
Tous les articles
·2 min de lecture

Les systèmes RAG hallucinent encore. Voici ce qui les arrête.

RAGHallucination MitigationLLM Reliability

La plupart des gens pensent qu'un meilleur retrieval résout les hallucinations. Ce n'est pas le cas.

J'ai mis en production des systèmes RAG chez BCG et j'en ai construit à la TUM, et le schéma est toujours le même : le retrieval trouve les bons documents, et le modèle invente quand même une réponse que ces documents ne soutiennent pas. L'étape de retrieval a fait son travail. L'étape de génération s'en moquait.

La solution n'est pas le retrieval. Ce sont trois choses que presque personne ne fait vraiment.

1. Une génération bornée

Dire à un modèle « n'hallucine pas » ne sert à rien : ce n'est pas une instruction, c'est un vœu pieux. Ce qui fonctionne, c'est de lui dire ce qu'il a le droit de faire : n'utiliser que les faits présents dans ces documents, et rendre cela vérifiable. Dans certains de nos systèmes, nous le faisons post-hoc : après la génération, on vérifie si la sortie cite effectivement quelque chose, et si cette citation tient la route. Si ce n'est pas le cas, on rejette et on régénère. C'est coûteux. Mais ça marche.

2. Des seuils de confiance, des deux côtés

La plupart des pipelines RAG récupèrent les top-k documents et supposent silencieusement qu'ils sont pertinents. Ce n'est souvent pas le cas. Il faut évaluer séparément la confiance du retrieval et celle de la génération. Si l'une des deux passe sous un seuil, la réponse devrait être « je ne sais pas », pas une estimation déguisée en fait. Cela paraît évident une fois écrit. Presque aucun système en production ne le fait vraiment.

3. Une chaîne de repli explicite

Quand le modèle ne peut pas répondre à partir du contexte, que se passe-t-il ensuite ? Si la réponse est « il hallucine quand même », le système est défectueux dès sa conception. Nous enchaînons les mécanismes de repli : si le retrieval échoue, on essaie une stratégie de retrieval différente ; si cela échoue aussi, on route vers un autre modèle ou vers un humain. Le modèle n'a jamais le droit d'inventer simplement parce que rien d'autre n'a été configuré.

La partie difficile

Rien de tout cela n'est difficile à construire. La partie difficile, c'est d'admettre d'abord que son système en a besoin. Les démos RAG fonctionnent à merveille en laboratoire parce que personne ne teste les cas limites. Le RAG en production hallucine constamment, et les systèmes qui n'hallucinent pas sont justement ceux construits en partant du principe qu'ils le feraient.

Voir aussi : Pourquoi l'atténuation des hallucinations compte plus que la taille du modèle

Mohamed Nejjar , étudiant en M.Sc. Informatique (ML) à la TUM, étudiant salarié chez BCG Platinion. Chercheur publié, 200+ citations en recherche sur les LLM.

Vous travaillez sur un problème similaire, ou avez des retours sur cet article ?

Ce site peut utiliser des analyses respectueuses de la vie privée pour améliorer la qualité du contenu. Aucun cookie publicitaire n'est utilisé.

Vous pouvez modifier ce choix à tout moment sur la page de confidentialité. En savoir plus dans la Politique de confidentialité.