Planeamiento de red teaming para modelos de lenguaje grandes (LLM) y sus aplicaciones
En esta guía se ofrecen algunas estrategias potenciales para planear cómo configurar y administrar procesos de red teaming para abordar riesgos de la IA responsable (RAI) en todo el ciclo de vida del producto de modelo de lenguaje de gran tamaño (LLM).
¿Qué es el red teaming?
El término Red Teaming (Equipo rojo en español) ha descrito históricamente ataques adversarios sistemáticos para probar vulnerabilidades de seguridad. Con el aumento de los LLM, el término se extendió más allá de la ciberseguridad tradicional y evolucionó en el uso común para describir muchos tipos de sondeo, prueba y ataque de sistemas de IA. Con los LLM, tanto el uso beneficioso como el perjudicial pueden producir resultados potencialmente dañinos, que pueden adoptar muchas formas, incluido el contenido perjudicial como la incitación al odio, la incitación o glorificación de la violencia o el contenido sexual.
¿Por qué es el red teaming de RAI una práctica importante?
El red teaming es un procedimiento recomendado en el desarrollo responsable de sistemas y características con LLM. Aunque no sustituye al trabajo sistemático de medición y mitigación, los equipos rojos ayudan a descubrir e identificar los daños y, a su vez, permiten estrategias de medición para validar la eficacia de las mitigaciones.
Aunque Microsoft ha realizado ejercicios de red teaming e implementado sistemas de seguridad (incluidos filtros de contenido y otras estrategias de mitigación) para sus modelos de Azure OpenAI Service (consulte esta Introducción a las prácticas de inteligencia artificial responsable), el contexto de cada aplicación LLM será único, por lo que también debe llevar a cabo procedimientos de red teaming para:
Probar el modelo base LLM y determinar si existen lagunas en los sistemas de seguridad existentes, dado el contexto de su aplicación.
Identificar y mitigar las deficiencias en los filtros predeterminados o estrategias de mitigación existentes.
Proporcionar información sobre los errores para realizar mejoras.
Tener en cuenta que los procedimientos de red teaming no reemplazan la medición sistemática. Un procedimiento recomendado consiste en completar una ronda inicial de red teaming manual antes de realizar mediciones sistemáticas e implementar mitigaciones. Como se ha indicado anteriormente, el objetivo de los procedimientos de red teaming de la RAI es identificar daños, entender la superficie de riesgo y desarrollar una lista de daños que pueda aportar información sobre qué es necesario medir y mitigar.
A continuación, le indicamos cómo puede comenzar y planear su proceso de red teaming de LLM. Es fundamental planificar con antelación para que el ejercicio de red teaming sea productivo.
Antes de las pruebas
Plan: quién realizará las pruebas
Reúna un grupo diverso de miembros del red team
Determine la composición ideal de los miembros de dicho equipo en lo que se refiere a conocimientos, demografía y experiencia en todas las disciplinas (por ejemplo, expertos en IA, ciencias sociales, seguridad) para el dominio del producto. Por ejemplo, si diseña un chatbot para ayudar a los proveedores de atención médica, los expertos en medicina pueden ayudarle a identificar riesgos en ese ámbito.
Reclute miembros del red team con mentalidad tanto positiva como adversa
Tener Red Teamers con una mentalidad adversaria y experiencia en pruebas de seguridad es esencial para comprender los riesgos de seguridad, pero los Red Teams que son usuarios normales de su sistema de aplicación y no participan en su desarrollo pueden aportar perspectivas valiosas sobre los daños que los usuarios normales podrían encontrar.
Asigne miembros del red team a daños o características del producto
Asigne miembros del red team de RAI con conocimientos específicos para sondear tipos de daños concretos (por ejemplo, expertos en materia de seguridad pueden realizar sondeos para detectar jailbreaks, extracción de solicitudes meta y contenido relacionado con ciberataques).
Si hay varias rondas de pruebas, decida si quiere cambiar las asignaciones de miembros de red team en cada ronda para obtener diversas perspectivas sobre cada daño y mantener la creatividad. Si cambia las asignaciones, dé tiempo a los miembros del red team para que se pongan al día respecto a las instrucciones de los nuevos daños que se les han asignado.
En fases posteriores, cuando se desarrollen la aplicación y su interfaz de usuario, puede asignar miembros de red team a partes concretas de la aplicación (es decir, características) para garantizar que se cubra toda la aplicación.
Considere cuánto tiempo y esfuerzo debe dedicar cada miembro del red team (por ejemplo, los que prueban escenarios positivos pueden requerir menos tiempo que aquellos que prueban escenarios adversos).
Puede ser útil proporcionar lo siguiente a los miembros del red team:
- Instrucciones claras, que pueden incluir:
- Introducción que describe el propósito y objetivo de la ronda de red teaming concreta; el producto y las características que se van a probar y cómo acceder a ellos; qué tipos de problemas se van a probar; áreas en las que deben centrarse los miembros del red team, si las pruebas son más específicas; cuánto tiempo y esfuerzo debe dedicar cada miembro del red team a realizarlas; cómo registrar resultados; y con quién ponerse en contacto si se tienen preguntas.
- Un archivo o ubicación para registrar sus ejemplos y conclusiones, incluida información como:
- Fecha en la que se encontró un ejemplo; un identificador único para el par de entrada/salida, si está disponible, a fin de poder reproducirlo; el símbolo del sistema de entrada; una descripción o captura de pantalla de la salida.
Plan: qué probar
Dado que una aplicación se desarrolla con un modelo base, es posible que tenga que realizar pruebas en varias capas diferentes:
El modelo base LLM con su sistema de seguridad para identificar cualquier brecha que se deba abordar en el contexto de su sistema de aplicación. (Las pruebas suelen realizarse a través de un punto de conexión de API).
Su aplicación. (Las pruebas se realizan mejor a través de una interfaz de usuario).
Tanto el modelo base de LLM como la aplicación están en vigor antes y después de las mitigaciones.
Las siguientes recomendaciones le ayudarán a elegir qué probar en varios puntos durante el proceso de red teaming:
Puede comenzar por probar el modelo base para comprender la superficie de riesgo, identificar los daños y guiar el desarrollo de mitigaciones de RAI para el producto.
Pruebe las versiones del producto de forma iterativa con y sin mitigaciones RAI para evaluar la eficacia de esas mitigaciones. (Tenga en cuenta que un proceso de red teaming manual puede no ser suficiente: use también mediciones sistemáticas, pero solo después de completar una ronda inicial de red teaming manual).
Realice pruebas de las aplicaciones en la interfaz de usuario de producción en la medida de lo posible, ya que esto es lo más parecido al uso real.
Al notificar los resultados, deje claro qué puntos de conexión se han utilizado para las pruebas. Si las pruebas se han realizado en un punto de conexión distinto del producto, considere la posibilidad de volver a probar en la interfaz de usuario o punto de conexión de producción en futuras rondas.
Plan: cómo probar
Realice pruebas indefinidas para descubrir una amplia gama de daños.
La ventaja de los miembros del red team de RAI que deben explorar y documentar cualquier contenido problemático (en lugar de pedírseles que encuentren ejemplos de daños concretos) es que esto les permite explorar de forma creativa una amplia gama de problemas y descubrir puntos ciegos en su comprensión de la superficie de riesgo.
Cree una lista de daños a partir de las pruebas indefinidas.
- Considere la posibilidad de crear una lista de daños, con definiciones y ejemplos de estos.
- Proporcione esta lista como guía para los miembros del red team en rondas de pruebas posteriores.
Realice procesos de red teaming guiados e itere: continúe con el sondeo de daños de la lista; identifique nuevos daños que aparezcan.
Use una lista de daños, si está disponible, y continúe probando para encontrar daños conocidos y ver la eficacia de sus mitigaciones. Durante el proceso, puede que identifique nuevos daños. Inclúyalos en la lista y esté abierto a cambiar las prioridades de medición y mitigación para abordar los daños recién identificados.
Planee qué daños deben priorizarse para las pruebas iterativas. Existen varios factores que pueden determinar la priorización, entre los que se incluyen la gravedad de los daños y el contexto en el que es más probable que aparezcan.
Plan: cómo registrar datos
Decida qué datos debe recopilar y cuáles son opcionales.
Decida qué datos deberán registrar los miembros del red team (por ejemplo, la entrada que han usado; la salida del sistema; un identificador único, si lo hay, para reproducir el ejemplo en el futuro; y otras notas).
Aplique una estrategia a los datos que recopila para evitar sobrecargar a los miembros del red team pero, al mismo tiempo, no perder información crítica.
Cree una estructura para la recopilación de datos
Una hoja de cálculo compartida de Excel suele ser el método más sencillo para recopilar datos de red teaming. Una ventaja de este archivo compartido es que cada miembro del red team puede revisar los ejemplos de los demás y, así, obtener ideas creativas para sus propias pruebas y evitar la duplicación de los datos.
Durante las pruebas
Esté activo en espera mientras se llevan a cabo los procesos de red teaming
- Esté preparado para ayudar a los miembros del red team con las instrucciones y los problemas de acceso.
- Supervise el progreso en la hoja de cálculo y envíe recordatorios a los miembros del red team en el momento adecuado.
Después de cada ronda de pruebas
Informe sobre los datos
Comparta un breve informe a intervalos regulares con las partes interesadas clave en el que:
Se enumeren los principales problemas identificados.
Se proporcione un vínculo a los datos sin procesar.
Se anticipe el plan de pruebas de las próximas rondas.
Se identifique a los miembros del red team.
Se proporcione cualquier otra información pertinente.
Diferencie entre la identificación y la medición
En el informe, asegúrese de aclarar que el rol de los procesos de red teaming de RAI es exponer la superficie de riesgo y ayudar a comprenderla, y no es un reemplazo de la medición sistemática y del trabajo riguroso de mitigación. Es importante que las personas no interpreten ejemplos específicos como una métrica de la generalización de ese daño.
Además, si el informe incluye contenido y ejemplos problemáticos, considere la posibilidad de incluir una advertencia sobre el contenido.
Las instrucciones de este documento no pretenden ser asesoramiento jurídico, ni deben interpretarse como tal. La jurisdicción en la que trabaja puede tener diversos requisitos normativos o legales que se apliquen al sistema de IA. Tenga en cuenta que no todas estas recomendaciones son adecuadas para todos los escenarios y, por otro lado, pueden ser insuficientes para algunos.