Trust but Verify: Mitigating Medical Hallucinations via Post-Hoc Adversarial Auditing and Multi-Agent Feedback Loops

Résumé Technique : Trust but Verify – Atténuer les hallucinations médicales via l'audit adversaire post-hoc et les boucles de rétroaction multi-agents

Énoncé du problème
Les modèles de langage de grande taille (LLM) sont de plus en plus déployés dans le secteur de la santé pour l'aide à la décision clinique, pourtant leur nature probabiliste entraîne des « hallucinations » qui posent de graves risques de sécurité. Un mode de défaillance critique, souvent négligé, est l'obsolescence des connaissances réglementaires : les LLM recommandent fréquemment des produits pharmaceutiques qui étaient historiquement corrects mais qui sont désormais interdits, retirés du marché ou assortis d'avertissements de type « boîte noire » par les organismes de réglementation (ex. : FDA, EMA). Le document souligne que même les modèles de pointe (SOTA) équipés de génération augmentée par récupération (RAG) et de capacités de navigation web ne parviennent pas à prioriser les contraintes de sécurité actuelles sur les données paramétriques d'entraînement, ce qui conduit à des recommandations cliniques dangereuses. Les stratégies d'atténuation existantes, telles que les garde-fous sémantiques statiques ou le RAG simple, manquent souvent de la vérification adversaire active requise pour détecter ces lacunes temporelles de connaissances.

Méthodologie
Les auteurs proposent une architecture modulaire à cinq agents intitulée « Trust but Verify » (Faire confiance mais vérifier), conçue pour faire respecter la conformité réglementaire via une boucle d'audit adversaire post-hoc. Le système utilise un unique squelette de LLM (testé sur les familles GPT-OSS, Llama-3 et Falcon-3) mais différencie les agents par une redirection de persona basée sur le prompt plutôt que par des poids de modèles hétérogènes.

Le flux de travail se compose de cinq rôles fonctionnels :

1. Agent Routeur (Router Agent) : Classifie les requêtes comme « Médicales » ou « Générales ». Seules les requêtes médicales déclenchent le pipeline de sécurité, optimisant ainsi la latence et les coûts.
2. Agent Clinique Médical (Medical Clinical Agent) : Agit comme le moteur de raisonnement principal, générant des recommandations de traitement candidates basées sur la requête d'entrée.
3. Agent d'Extraction d'Entités (Entity Extractor Agent) : Analyse la sortie en langage naturel de l'agent clinique en un format JSON structuré (extrayant le médicament et la pathologie) pour faciliter une vérification lisible par machine.
4. Agent Auditeur de Sécurité (Safety Auditor Agent) : Le composant de sécurité central. Il effectue des recherches fondées sur le web en temps réel (via l'API Tavily) contre des sources réglementaires faisant autorité (FDA, NIH) pour vérifier le statut actuel du médicament extrait. Si un médicament est signalé comme interdit ou retiré, l'auditeur déclenche une boucle de rétroaction, renvoyant la violation à l'Agent Clinique pour forcer une nouvelle tentative ou un refus sécurisé.
5. Agent de Chat Général (General Chat Agent) : Gère les interactions non critiques pour conserver les ressources.

Le système autorise jusqu'à trois tentatives de nouvel essai. Si aucune alternative sûre n'est trouvée parmi les options, le système est conçu pour émettre un « refus sûr » plutôt qu'une recommandation hallucinée.

Configuration Expérimentale
L'étude a utilisé un jeu de données adversaire de 103 questions à choix multiples (QCM) cliniques. Dans ces questions, la réponse historiquement correcte correspond à un médicament qui a depuis été retiré ou interdit. Le jeu de données a été construit à l'aide de DrugBank, garantissant que l'étiquette « correcte » dans le contexte des données d'entraînement est en réalité une violation de sécurité dans le contexte réglementaire actuel.

Trois configurations expérimentales ont été évaluées :

• Expérience I (Vanilla) : Inférence en une seule étape où le LLM agit comme un expert clinique sans audit externe.
• Expérience II (Agentic) : Le pipeline à cinq agents proposé avec la boucle de rétroaction adversaire.
• Expérience III (Évaluation SOTA) : Test de modèles propriétaires de pointe (ChatGPT-5.1/5.3, Gemini 3 Flash/3.1 Pro) avec navigation native activée pour évaluer si les solutions commerciales actuelles atténuent ce mode de défaillance spécifique.

Métriques Clés
La performance a été évaluée à l'aide de :

• Précision de l'étiquette (Label Accuracy) : Exactitude standard par rapport à la vérité de terrain du jeu de données (qui est intrinsèquement non sûre dans cette configuration adversaire).
• Score Ponctuel (Pointwise Score - PS) : Une métrique spécialisée pénalisant les recommandations définitives pour des médicaments interdits (-0,25), récompensant les refus sûrs (0,0) et récompensant les prédictions correctes sûres (+1,0).
• Taux d'Erreur d'Hallucination (Hallucination Error Rate - HER) : La fréquence des recommandations définitives pour des substances retirées.
• Fidélité des Composants (Component Fidelity - CF) : Le ratio des sorties fonctionnelles réussies par rapport au total des invocations d'agents, mesurant la fiabilité de l'orchestration multi-agents.

Résultats

• Performance Vanilla : Tous les modèles en accès libre testés ont affiché une « précision » élevée (correspondant au médicament interdit) mais des taux de HER (Hallucination Error Rate) élevés (allant de 90,29 % à 99,03 %). Les scores ponctuels se sont regroupés près de -0,25, indiquant une pénalité de sécurité maximale.
• Performance Agentique : L'architecture proposée a réduit de manière significative les HER sur tous les modèles d'environ 53 % en moyenne (par exemple, Llama-3-70B est passé de 99,03 % à 37,86 %). Bien que la précision brute de l'étiquette ait diminué (car le système a correctement refusé de sélectionner le médicament interdit « correct »), le Score Ponctuel s'est déplacé de -0,25 vers 0,0, indiquant une transition réussie vers des refus sûrs.
• Échec SOTA : L'expérience III a révélé que même les modèles propriétaires dotés de capacités de raisonnement et de navigation avancées ont échoué à empêcher la recommandation de médicaments interdits. Ces modèles reconnaissent souvent le statut de retrait dans leurs résultats de recherche, mais finissent par donner la priorité à leurs connaissances paramétriques pour sélectionner le médicament interdit comme réponse, démontant ainsi une « régression de la sécurité clinique ».
• Intégrité du Système : Les scores de Fidélité des Composants pour le pipeline agentique variaient entre 73,82 % et 85,71 %, confirmant la robustesse de l'orchestration multi-agents.

Signification et Revendications
Le document affirme démontrer une approche pratique et indépendante du modèle pour le déploiement d'IA autonomes dans des contextes de soins de santé critiques pour la sécurité. Ses principales contributions sont :

1. Identification d'une lacune critique : Souligner que les RAG et les modèles SOTA actuels ne parviennent pas à intégrer efficacement les données réglementaires en temps réel, menant à la recommandation de substances interdites.
2. Innovation Architecturale : Proposer une boucle d'audit adversaire non linéaire qui traite la sécurité comme un processus de vérification déterministe plutôt que comme une tâche de génération probabiliste. En découplant le raisonnement clinique (LLM) de la vérité factuelle (auditeur en temps réel), le système garantit la conformité sans nécessifier de réentraînement du modèle.
3. Sécurité plutôt que Fluidité : Le cadre privilégie la sécurité du patient en convertissant les recommandations dangereuses en refus appropriés, déplaçant l'objectif du système de « répondre correctement » vers « répondre en toute sécurité ».
4. Scalabilité : L'utilisation d'un squelette unique avec une différenciation d'agent par prompt offre une solution évolutive qui ne nécessite ni expansion de paramètres ni réentraînement coûteux.

Les auteurs concluent que, bien que l'approche multi-agents introduise une latence d'inférence, ce compromis est nécessaire pour une sécurité déterministe dans les environnements cliniques à enjeux élevés. Ils positionnent ce travail comme une étape vers l'intégration des données réglementaires en temps réel dans les pipelines de LLM pour soutenir, plutôt que remplacer, la prise de décision clinique.