CRCP: envenenamiento de corpus RAG que sobrevive al chunking y al reranking

¿De qué se trata?

El 9 de junio de 2026, Xi Nie, Hongwei Li, Shenghao Wu, Mingxuan Li, Jiachen Li y Wenbo Jiang publicaron “When Poison Fails After Retrieval: Revisiting Corpus Poisoning under Chunking and Reranking Pipelines” (arXiv:2606.11265, cs.CR). El artículo plantea una observación engañosamente simple: muchos ataques publicados de envenenamiento de corpus RAG parecen sólidos en el laboratorio y luego se desmoronan en un pipeline realista.

El envenenamiento de corpus es la familia de ataques en la que un adversario inyecta documentos manipulados en la base de conocimiento que utiliza un sistema de generación aumentada por recuperación (RAG), para que esos documentos sean recuperados y orienten la respuesta del modelo. Trabajos previos —por ejemplo el ataque GASLITE contra recuperadores densos (CCS ‘25)— demostraron que es viable incluso con tasas de envenenamiento insignificantes. El nuevo artículo formula la pregunta de seguimiento que casi todos omitieron: ¿sigue funcionando una vez que los documentos pasan por el chunking, la recuperación densa, el reranking y la generación fundamentada, es decir, tal como funcionan realmente los sistemas en producción?

Cómo funciona

El hallazgo de los autores es que muchos ataques existentes se degradan notablemente tras el reranking, aun cuando el pasaje envenenado obtuvo alta relevancia en la etapa de recuperación densa. Nombran la causa desajuste de granularidad de recuperación (retrieval granularity mismatch).

Dos mecanismos rompen las suposiciones del atacante:

Etapa del pipeline    Función                       Efecto sobre un payload a nivel documento
--------------------  ----------------------------  -----------------------------------------
Chunking              divide los docs en pasajes    la señal adversaria se fragmenta
Recuperación densa    codifica + ordena los chunks  el chunk envenenado puede seguir alto
Reranking             re-puntúa los candidatos      favorece pasajes localmente coherentes
Generación            responde desde los que pasan  el payload a menudo no supera el filtro

La mayoría de los ataques previos optimizan un documento completo para que quede cerca de una consulta en el espacio de embeddings. Pero el pipeline nunca ve ese documento completo: ve los fragmentos que deja el chunking, y un reranker de tipo cross-encoder que prefiere un pasaje que localmente se lea como una respuesta frente a otro con mera alta similitud global. La señal adversaria, dispersa en el documento original, se corta y se descarta.

La contribución del artículo, CRCP (Chunk-aware and Rerank-Consistent Poisoning), es un método que optimiza contra esta realidad en lugar de eludirla. CRCP apunta conjuntamente a la relevancia de recuperación, la consistencia frente al reranker y la robustez ante los límites de chunk, y modela explícitamente las transformaciones de chunking durante la optimización para que los pasajes resultantes sean localmente autónomos: cada chunk superviviente sigue portando la intención adversaria, caigan donde caigan los límites. En benchmarks RAG estándar con varios recuperadores y rerankers, los métodos existentes resultan muy sensibles al tamaño de chunk y a la estrategia de reranking, mientras que CRCP resiste mucho mejor. (Aquí no se reproduce ningún payload ni código de optimización; es un resumen de un método publicado.)

Por qué importa

Hay dos conclusiones distintas, y la segunda es la importante.

La conclusión estrecha: un reranker no es una defensa fiable contra el envenenamiento de corpus. Eleva el listón frente a los ataques ingenuos a nivel documento —lo cual es realmente útil—, pero se puede construir un atacante “chunk-aware” que lo supere.

La conclusión amplia es metodológica, y vale en ambos sentidos. Si evalúa un ataque en un entorno de recuperación simplificado, lo sobrestimará. Si evalúa una defensa del mismo modo, subestimará la amenaza y desplegará un control que solo parece eficaz porque se probó contra ataques que ignoraban su pipeline. Es la misma trampa en la que cayó el campo de la prompt injection con las cadenas de ataque estáticas: una defensa que resiste los ataques de ayer dice muy poco. Los autores enmarcan el envenenamiento RAG como un problema de consistencia multietapa de la recuperación, no como un problema solo de recuperación: la superficie de ataque relevante es toda la cadena chunk → recuperación → reranking → generación.

Se trata de investigación sobre benchmark, no de un incidente observado en producción, y el atacante debe primero lograr introducir contenido en su corpus, la condición previa de todo ataque de envenenamiento.

Defensas

1. Controle quién puede escribir en el corpus. El envenenamiento necesita una vía de inyección: rastreos web abiertos, documentos subidos por usuarios, wikis scrapeados, unidades compartidas. Trate la ingesta como una frontera no confiable: trazabilidad de procedencia, listas de fuentes permitidas y revisión de todo corpus que el modelo tomará como verdad de referencia.

2. No trate el reranking como un control de seguridad. Úselo para la calidad, pero asuma que un atacante decidido puede producir pasajes a nivel chunk que lo sobrevivan. Superponga defensas en lugar de depender de una sola etapa.

3. Filtre con granularidad de chunk. Como el ataque vive en los chunks, la detección también debería hacerlo. El filtrado por perplejidad y anomalía a nivel chunk —como en la defensa RAGuard (arXiv:2510.25025)— detecta pasajes estadísticamente atípicos antes de la generación. Combínelo con una puntuación de procedencia del documento fuente.

4. Combine recuperación sparse y densa. La recuperación híbrida BM25 + vectores rompe los ataques ajustados solo contra un espacio de embeddings, porque un pasaje optimizado para la proximidad de embedding rara vez gana también en coincidencia léxica. No es una solución completa, pero elimina toda una clase de optimizaciones puramente densas.

5. Evalúe frente a su pipeline real. Es la lección central del artículo aplicada a la defensa: haga red-teaming del envenenamiento a través de su verdadero tamaño de chunk, recuperador y reranker, con atacantes adaptativos, no un montaje de una sola etapa. Un control validado solo en un entorno simplificado queda sin probar en producción.

6. Inspeccione lo que se recuperó. Registre los pasajes y documentos fuente que alimentaron cada respuesta. Cuando una salida parezca manipulada, la trazabilidad a nivel de recuperación es lo que le permite encontrar el registro envenenado.

Estado

Elemento	Referencia	Fecha	Notas
Artículo CRCP	arXiv:2606.11265	2026-06-09	Envenenamiento de corpus “chunk-aware” y consistente con el reranker
Envenenamiento de recuperación densa	GASLITE, arXiv:2412.20953	CCS ‘25	Viable con ≤0,0001 % de tasa de envenenamiento
Referencia de defensa	RAGuard, arXiv:2510.25025	2025-10	Filtrado por perplejidad a nivel chunk
Estado real	—	—	Investigación sobre benchmark; sin incidente reportado en producción

El titular no es “los rerankers son inútiles”. Es que la seguridad de RAG debe medirse de extremo a extremo —chunking, recuperación, reranking, generación—, porque un atacante que optimiza para su pipeline real encontrará los eslabones que su evaluación de una sola etapa nunca probó.