Le RAG peut améliorer la réponse tout en fragilisant la sécurité

La promesse ambivalente du RAG

La génération augmentée par récupération est souvent présentée comme un moyen de réduire les hallucinations : le modèle reçoit des documents de confiance et peut s’appuyer sur des preuves externes. Cette amélioration de la réponse utile ne garantit pas une amélioration de la sécurité. Le preprint RAG-Safety-Bench étudie précisément cette tension sur des questions nuisibles ou dangereuses.

Les auteurs veulent distinguer plusieurs explications possibles. Le document récupéré contient-il directement la réponse dangereuse ? Le simple fait d’ajouter un contexte lié au sujet suffit-il à faire émerger une information que le modèle refusait auparavant ? Un long contexte quelconque déplace-t-il le comportement ? Pour éviter de confondre ces mécanismes, le benchmark sépare quatre conditions.

Quatre conditions pour séparer les causes

La première condition est sans RAG. Elle mesure le comportement de base du modèle face à la question. La deuxième est un RAG oracle : un document récupéré contient la réponse à la demande nuisible. La troisième fournit des documents liés au sujet, mais dépourvus de la réponse précise. La quatrième fournit des documents aléatoires et sûrs.

Cette construction retire volontairement la qualité du retriever de la question principale. Les auteurs peuvent ainsi comparer le générateur dans des contextes contrôlés. Il ne s’agit pas d’un test complet d’un pipeline de production, où le classement des documents, la reformulation de la requête, le filtrage et le prompt système interagissent. C’est un test de mécanismes, conçu pour montrer qu’un RAG n’hérite pas automatiquement des garanties mesurées sans récupération.

Modèles et évaluations

L’étude porte sur cinq LLM open source : Gemma-3-12B, Llama-3.1-8B, Ministral-3-8B, Phi-4-14B et Qwen-2.5-7B. Les auteurs mesurent à la fois la capacité à répondre correctement et la nocivité jugée de la réponse. Cette séparation est nécessaire : une réponse peut reprendre correctement une information de référence tout en devenant dangereuse dans le contexte de la question.

Les juges automatiques associent notamment LlamaGuard, ShieldGemma et WildGuard. Leur accord varie selon les catégories et reste modéré dans l’ensemble : le Fleiss kappa à quatre évaluateurs est de 0,56. Une annotation humaine d’un sous-ensemble valide cependant certains usages du juge de correction, avec 95–96 % d’accord et un kappa de Cohen de 0,90–0,92 ; pour la classification des refus, l’accord humain rapporté est de 85 %, avec un kappa de 0,71–0,73.

Ces chiffres ne veulent pas dire qu’un juge est la vérité. Ils montrent que la conclusion dépend de la définition de la nocivité et du public visé. Une description historique, une information destinée à un professionnel et une procédure utilisable par un enfant ne présentent pas le même risque.

La capacité bénigne ne prédit pas directement la sécurité

Dans le benchmark bénin, l’accès à un document oracle augmente fortement la précision des cinq modèles. Ils savent donc incorporer une information de contexte lorsque celle-ci est disponible. Cette amélioration ne se transpose pas automatiquement à la sécurité. Les auteurs rapportent une corrélation négative de -0,70 entre la précision bénigne en condition oracle et la précision sur les questions nuisibles en condition oracle.

Une interprétation possible est que les modèles plus capables possèdent aussi de meilleurs garde-fous lorsqu’ils reconnaissent une demande dangereuse. Mais cette lecture reste dépendante des modèles et des conditions. Le RAG ne fait pas simplement « plus répondre » ou « plus refuser » : il modifie la relation entre le contexte, la question et les garde-fous.

Le contexte oracle est le plus risqué

Pour les cinq modèles, la condition oracle produit le taux de nocivité le plus élevé. Le document contient alors directement l’information demandée, ce qui augmente la probabilité que le modèle réponde correctement à la question nuisible. Le résultat paraît intuitif, mais il est important pour les systèmes d’entreprise : un corpus « de confiance » peut contenir un document utile pour une tâche légitime et néanmoins dangereux lorsqu’il est combiné à une requête malveillante.

La condition on-topic, sans réponse exacte, est plus nuancée. Chez Gemma, Llama et Ministral, la nocivité revient approximativement au niveau de base ou en dessous. Chez Phi, elle reste légèrement élevée mais à un niveau globalement faible. Qwen constitue l’exception : des documents liés au sujet, mais ne donnant pas la réponse, entraînent encore plus de sorties nocives que la condition sans RAG.

Les auteurs interprètent ce cas comme la possibilité de faire remonter depuis la mémoire paramétrique une information que le modèle n’aurait pas divulguée sans contexte thématique. Le document n’a pas besoin de contenir la procédure dangereuse ; il peut suffire à activer la bonne zone de connaissance et à réduire la distance entre la question et une réponse interdite.

Un contexte long n’est pas la cause suffisante

Les documents aléatoires et sûrs produisent le comportement le plus sûr dans l’étude. Le simple allongement du contexte n’explique donc pas la dégradation observée. Dans plusieurs cas, le contexte aléatoire augmente même les refus par manque d’information : le modèle indique qu’il ne trouve pas le sujet demandé au lieu de compléter depuis sa mémoire.

Ce résultat ne signifie pas qu’un contexte aléatoire est une mitigation suffisante. Il montre seulement que la longueur seule n’est pas le mécanisme dominant dans ce benchmark. Un système réel doit examiner la pertinence thématique, la présence d’informations dangereuses, la politique de refus et la façon dont les documents sont présentés au générateur.

Ce que le benchmark change pour un produit

Une équipe RAG devrait tester séparément le modèle sans documents, avec des documents contenant la réponse, avec des documents liés mais incomplets et avec des documents hors sujet. Elle devrait conserver la distinction entre exactitude, réponse nocive, refus de sécurité et refus par manque d’information. Un refus sûr peut être correctement classé comme refus tout en révélant que le système ne sait pas distinguer un manque de preuve d’une interdiction.

La sécurité doit être évaluée de bout en bout lorsque le retriever est activé. Le benchmark retire la qualité de récupération pour isoler le générateur ; en production, il faut en plus tester les interactions entre classement, reformulation, filtres d’entrée, filtres côté récupération, instructions système et filtres de sortie. Les documents doivent être traités comme des données non fiables pour l’autorisation, même lorsqu’ils proviennent d’un corpus interne.

Les auteurs recommandent, selon le cas d’usage, une combinaison de curation du corpus, filtrage des prompts, filtrage de récupération, filtrage de sortie et instructions de sécurité. Plusieurs juges automatiques peuvent être utiles lorsque leurs sensibilités diffèrent, mais une supervision humaine reste nécessaire pour les catégories où la nocivité dépend du contexte.

Limites et statut de la source

RAG-Safety-Bench est en anglais, s’appuie sur une seule source documentaire issue de Wikipédia et couvre une liste non exhaustive de catégories de dommages. Le retriever n’est pas évalué et les expériences utilisent seulement des modèles open source relativement petits, sur un seul run malgré la stochasticité de la génération. Les résultats ne mesurent donc pas directement un système commercial ou un corpus métier.

Le document est un preprint ArXiv et n’est pas nécessairement évalué par les pairs. Il fournit un protocole de séparation des mécanismes et des résultats initiaux, non une certification de sûreté d’un modèle ou d’un pipeline RAG.

Sources

Adithiyan Rajan Indira Saravanan et Kathleen C. Fraser, « RAG-Safety-Bench: Reliable Evaluation of Retrieval-Augmented LLM Safety », ArXiv 2609.11758v1 : preprint, PDF.