La generación o trapo de recuperación, o trapo, ha sido aclamada como una forma de hacer que los modelos de idiomas grandes sean más confiables al fundamentar sus respuestas en documentos reales. La lógica suena hermética: proporcione un modelo de conocimiento curado para extraer en lugar de depender únicamente de sus propios parámetros, y reduce las alucinaciones, la información errónea y las salidas riesgosas. Pero un nuevo estudiar sugiere que lo contrario podría estar sucediendo. Incluso los modelos más seguros, combinados con documentos seguros, se volvieron notablemente más peligrosos al usar RAG.
Investigadores de Bloomberg AI, la Universidad de Maryland y Johns Hopkins realizaron uno de los primeros análisis a gran escala de la seguridad de Rag Systems. Sus hallazgos inverten los supuestos comunes que muchos desarrolladores de IA y usuarios tienen sobre cómo la recuperación impacta el comportamiento del modelo. En Once Popular LLMS, RAG a menudo introdujo nuevas vulnerabilidades, creando respuestas inseguras que no existían antes.
La recuperación no protegió los modelos
En una prueba de más de 5,000 indicaciones dañinas, ocho de once modelos mostraron una tasa más alta de respuestas inseguras cuando se activó RAG. El comportamiento seguro en el entorno sin RAG no predecía un comportamiento seguro en el trapo. El estudio proporcionó un ejemplo concreto: Llama-3-8b, un modelo que solo produjo resultados inseguros del 0.3 por ciento del tiempo en una configuración estándar, vio esa cifra saltar al 9.2 por ciento cuando se usó RAG.
No solo subió el porcentaje general de respuestas inseguras, sino que los modelos también ampliaron sus vulnerabilidades en nuevas categorías de riesgos. Anteriormente contenían debilidades en áreas como la práctica no autorizada de la ley o la orientación de malware que se extendió a categorías más amplias que incluyen contenido de adultos, información errónea y campañas políticas. El trapo, en lugar de reducir el riesgo, lo amplió.
Tres razones por las que el trapo puede ser contraproducente
Los investigadores rastrearon este peligro inesperado para tres factores entrelazados:
- LLM BASE DE SEGURIDAD: Para empezar, los modelos que eran menos seguros sufrieron el mayor deterioro en la configuración de trapo.
- Seguridad del documento: Incluso cuando los documentos recuperados se clasificaron como seguros, los modelos aún generaban contenido dañino.
- Rendimiento de la tarea de trapo: La forma en que un modelo manejó combinando documentos externos con conocimiento interno influyó profundamente en los resultados.
Lo que surgió es que simplemente combinar un modelo seguro con documentos seguros no es garantía de respuestas seguras. Los mecanismos que hacen que el trapo sea atractivo, como la síntesis de contexto y la respuesta guiada por documentos, también abren nuevas vías para el mal uso y la mala interpretación.
Dos comportamientos principales se destacaron cuando los investigadores analizaron salidas inseguras derivadas de documentos seguros. Primero, los modelos a menudo reutilizaban información inofensiva en consejos peligrosos. Por ejemplo, una entrada de Wikipedia sobre cómo la policía usa rastreadores GPS se convirtió, en manos de un modelo, en un tutorial para los delincuentes sobre la captura evadiendo.
En segundo lugar, incluso cuando se les indica que confíe únicamente en los documentos, modelos a veces mezclados en el conocimiento interno. Esta combinación de memoria y recuperación socavó las salvaguardas que se suponía que debía proporcionar el trapo. Incluso cuando los documentos externos eran neutrales o benignos, el conocimiento interno inseguro surgió de una manera que el ajuste fino había suprimido previamente en el entorno sin RAG.
Agregar más documentos recuperados solo empeoró el problema. Los experimentos mostraron que aumentar el número de documentos de contexto hizo que los LLM tengan más probabilidades de responder preguntas inseguras, no menos. Un solo documento seguro era suficiente para comenzar a cambiar el perfil de riesgo de un modelo.
No todos los modelos manejaron el trapo por igual. Soneto Claude 3.5por ejemplo, se mantuvo notablemente resistente, mostrando tasas de respuesta inseguras muy bajas incluso bajo presión de trapo. Gemma 7b parecía seguro a primera vista, pero un análisis más profundo reveló que a menudo simplemente se negaba a responder preguntas. Mala extracción y habilidades de resumen enmascararon vulnerabilidades en lugar de arreglarlas.
En general, los modelos que funcionaban mejor en tareas de trapo genuinas como la resumen y la extracción fueron paradójicamente más vulnerables. Su capacidad para sintetizar de los documentos también les facilitaron los hechos inofensivos mal en contenido inseguro cuando el tema era sensible.
Las grietas de seguridad se ampliaron aún más cuando los investigadores probaron los métodos existentes de equipo rojo diseñados para jailbreak LLMS. Técnicas como GCG y Autodan, que funcionan bien para los modelos estándar, no lograron transferir su éxito al atacar las configuraciones de trapo.
Uno de los mayores desafíos fue que las indicaciones adversas optimizadas para un modelo no RAG perdieron la efectividad cuando los documentos se inyectaron en el contexto. Incluso el reentrenamiento de indicaciones adversas específicamente para RAG mejoró los resultados solo ligeramente. Cambiar los documentos recuperados cada vez que creó inestabilidad, lo que dificulta que las estrategias tradicionales de jailbreak tengan éxito de manera consistente.
Esta brecha muestra que las herramientas de seguridad de IA y las evaluaciones creadas para modelos base no son suficientes. Se necesitará el equipo rojo específico de RAG dedicado si los desarrolladores desean implementar sistemas mejorados por recuperación de manera segura a escala.
La recuperación no es una manta de seguridad
A medida que las empresas se mueven cada vez más hacia las arquitecturas de trapo para modelo de lenguaje grande Aplicaciones, los hallazgos de este estudio aterrizan como una advertencia marcada. La recuperación ayuda a reducir las alucinaciones y mejorar la facturidad, pero no se traduce automáticamente en salidas más seguras. Peor aún, introduce nuevas capas de riesgo que las intervenciones de seguridad tradicionales no fueron diseñadas para manejar.
La comida para llevar es clara: los desarrolladores de LLM no pueden asumir que el atornillado en la recuperación hará que los modelos sean más seguros. El ajuste fino debe adaptarse explícitamente para los flujos de trabajo de RAG. El equipo rojo debe tener en cuenta el dinamismo del contexto. El monitoreo debe tratar la capa de recuperación en sí como un potencial vector de ataque, no solo como una entrada pasiva.
Sin defensas específicas de RAG, las técnicas diseñadas para moldear modelos de lenguaje en la verdad podrían crear nuevas vulnerabilidades. Si la industria no aborda estas brechas rápidamente, la próxima generación de implementaciones de LLM podría heredar riesgos más profundos disfrazados bajo la confortante etiqueta de recuperación.
