CRCP : l'empoisonnement de corpus RAG qui survit au chunking et au reranking

De quoi s’agit-il ?

Le 9 juin 2026, Xi Nie, Hongwei Li, Shenghao Wu, Mingxuan Li, Jiachen Li et Wenbo Jiang ont publié « When Poison Fails After Retrieval: Revisiting Corpus Poisoning under Chunking and Reranking Pipelines » (arXiv:2606.11265, cs.CR). L’article énonce un constat trompeusement simple : nombre d’attaques publiées par empoisonnement de corpus RAG paraissent solides en laboratoire, puis s’effondrent dans un pipeline réaliste.

L’empoisonnement de corpus désigne la famille d’attaques où un adversaire injecte des documents fabriqués dans la base de connaissances qu’exploite un système de génération augmentée par récupération (RAG), afin que ces documents soient récupérés et orientent la réponse du modèle. Des travaux antérieurs — par exemple l’attaque GASLITE contre les retrievers denses (CCS ‘25) — ont montré que c’est faisable même à des taux d’empoisonnement négligeables. Le nouvel article pose la question de suivi que presque tout le monde a éludée : cela fonctionne-t-il encore une fois les documents passés par le chunking, la récupération dense, le reranking et la génération ancrée — c’est-à-dire la manière dont les systèmes de production fonctionnent réellement ?

Comment ça marche

Le constat des auteurs : beaucoup d’attaques existantes se dégradent fortement après le reranking, alors même que le passage empoisonné obtenait une forte pertinence à l’étape de récupération dense. Ils nomment la cause désalignement de granularité de récupération (retrieval granularity mismatch).

Deux mécanismes brisent les hypothèses de l’attaquant :

Étape du pipeline    Rôle                          Effet sur un payload au niveau document
-------------------  ----------------------------  ---------------------------------------
Chunking             découpe les docs en passages  le signal adverse est fragmenté
Récupération dense   encode + classe les chunks    le chunk empoisonné peut rester bien classé
Reranking            re-score les candidats        favorise les passages localement cohérents
Génération           répond depuis les survivants  le payload ne passe souvent pas le filtre

La plupart des attaques antérieures optimisent un document entier pour qu’il se situe près d’une requête dans l’espace d’embedding. Mais le pipeline ne voit jamais ce document entier : il voit les morceaux laissés par le chunking, et un reranker de type cross-encoder qui préfère un passage localement lisible comme une réponse à un passage simplement doté d’une forte similarité globale. Le signal adverse, dispersé dans le document d’origine, est découpé puis écarté.

La contribution de l’article, CRCP (Chunk-aware and Rerank-Consistent Poisoning), est une méthode qui optimise contre cette réalité plutôt que de la contourner. CRCP cible conjointement la pertinence de récupération, la cohérence vis-à-vis du reranker et la robustesse aux frontières de chunk, et modélise explicitement les transformations de chunking durant l’optimisation afin que les passages obtenus soient localement autonomes — chaque chunk survivant porte encore l’intention adverse, où que tombent les frontières. Sur des benchmarks RAG standards avec plusieurs retrievers et rerankers, les méthodes existantes se révèlent très sensibles à la taille des chunks et à la stratégie de reranking, tandis que CRCP résiste bien mieux. (Aucun payload ni code d’optimisation n’est reproduit ici ; il s’agit d’un résumé d’une méthode publiée.)

Pourquoi c’est important

Il y a deux enseignements distincts, et le second est le plus important.

L’enseignement étroit : un reranker n’est pas une défense fiable contre l’empoisonnement de corpus. Il relève la barre face aux attaques naïves au niveau document — ce qui est réellement utile — mais on peut concevoir un attaquant « chunk-aware » qui la franchit.

L’enseignement large est méthodologique, et il vaut dans les deux sens. Si vous évaluez une attaque dans un cadre de récupération simplifié, vous la surestimez. Si vous évaluez une défense de la même façon, vous sous-estimez la menace et déployez un contrôle qui ne paraît efficace que parce qu’il a été testé contre des attaques ignorant votre pipeline. C’est le piège dans lequel le champ de la prompt injection est tombé avec les chaînes d’attaque statiques : une défense qui résiste aux attaques d’hier ne vous apprend pas grand-chose. Les auteurs présentent l’empoisonnement RAG comme un problème de cohérence multi-étapes de la récupération, et non comme un problème de récupération seule — la surface d’attaque pertinente est donc toute la chaîne chunk → récupération → reranking → génération.

Il s’agit de recherche sur benchmark, pas d’un incident observé en production, et l’attaquant doit d’abord parvenir à introduire du contenu dans votre corpus — la condition préalable de toute attaque par empoisonnement.

Défenses

1. Contrôlez qui peut écrire dans le corpus. L’empoisonnement nécessite une voie d’injection : crawls web ouverts, documents téléversés par les utilisateurs, wikis scrapés, partages réseau. Traitez l’ingestion comme une frontière non fiable — traçabilité de provenance, listes d’autorisation de sources, et relecture de tout corpus que le modèle prendra pour vérité de référence.

2. Ne considérez pas le reranking comme un contrôle de sécurité. Utilisez-le pour la qualité, mais supposez qu’un attaquant déterminé peut produire des passages au niveau chunk qui y survivent. Superposez les défenses au lieu de vous reposer sur une seule étape.

3. Filtrez à la granularité du chunk. Comme l’attaque vit dans les chunks, la détection doit y vivre aussi. Le filtrage par perplexité et anomalie au niveau chunk — comme dans la défense RAGuard (arXiv:2510.25025) — repère les passages statistiquement aberrants avant la génération. Associez-le à un score de provenance du document source.

4. Combinez récupération sparse et dense. La récupération hybride BM25 + vecteurs casse les attaques réglées uniquement contre un espace d’embedding, car un passage optimisé pour la proximité d’embedding gagne rarement aussi sur la correspondance lexicale. Ce n’est pas une solution complète, mais cela élimine toute une classe d’optimisations purement denses.

5. Évaluez face à votre vrai pipeline. C’est la leçon centrale de l’article appliquée à la défense : red-teamez l’empoisonnement à travers votre vraie taille de chunk, votre retriever et votre reranker, avec des attaquants adaptatifs — pas un montage à étape unique. Un contrôle validé uniquement dans un cadre simplifié reste non prouvé en production.

6. Inspectez ce qui a été récupéré. Journalisez les passages et documents sources ayant alimenté chaque réponse. Lorsqu’une sortie semble manipulée, la traçabilité au niveau récupération est ce qui vous permet de retrouver l’enregistrement empoisonné.

Statut

Élément	Référence	Date	Notes
Article CRCP	arXiv:2606.11265	2026-06-09	Empoisonnement de corpus « chunk-aware » et cohérent au reranker
Empoisonnement de récupération dense	GASLITE, arXiv:2412.20953	CCS ‘25	Faisable à ≤0,0001 % de taux d’empoisonnement
Référence défense	RAGuard, arXiv:2510.25025	2025-10	Filtrage par perplexité au niveau chunk
Statut réel	—	—	Recherche sur benchmark ; aucun incident en production rapporté

Le titre n’est pas « les rerankers sont inutiles ». C’est que la sécurité RAG doit se mesurer de bout en bout — chunking, récupération, reranking, génération — car un attaquant qui optimise pour votre vrai pipeline trouvera les maillons que votre évaluation à étape unique n’a jamais testés.