Planeamiento de la formación de equipos rojos 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 el equipo rojo para los riesgos de inteligencia artificial responsable (RAI) en todo el ciclo de vida del producto del modelo de lenguaje grande (LLM).

¿Qué es el red teaming?

El término formación de equipos rojos ha descrito históricamente ataques adversarios sistemáticos para probar vulnerabilidades de seguridad. Con el aumento de los LLMs, el término se ha ampliado más allá de la ciberseguridad tradicional y ha evolucionado para ser utilizado comúnmente para describir muchos tipos de exploraciones, pruebas y ataques a sistemas de inteligencia artificial. Con las LLM, tanto el uso benigno como el adversario pueden producir salidas potencialmente perjudiciales, que pueden adoptar muchas formas, incluido contenido dañino, como el discurso de odio, la incitación o la exaltación de la violencia o el contenido sexual.

¿Por qué la formación de equipos de RAI rojo es una práctica importante?

El uso de equipos rojos es una mejor práctica en el desarrollo responsable de sistemas y características mediante modelos de lenguaje extensos (LLMs). Aunque no es un reemplazo del trabajo sistemático de medición y mitigación, los equipos rojos ayudan a descubrir e identificar daños y, a su vez, permiten estrategias de medición para validar la eficacia de las mitigaciones.

Aunque Microsoft ha realizado ejercicios de equipo rojo e implementado sistemas de seguridad (incluyendo filtros de contenido y otras estrategias de mitigación) para su Azure OpenAI en Microsoft Foundry Models (consulte esta visión general de prácticas de IA responsable), el contexto de cada aplicación LLM será único y también debería llevar a cabo el red teaming para:

  • Pruebe el modelo base de LLM y determine si hay lagunas en los sistemas de seguridad existentes, dado el contexto de la aplicación.

  • Identifique y mitigue las deficiencias en los filtros predeterminados existentes o las estrategias de mitigación.

  • Proporcione comentarios sobre los errores para realizar mejoras.

  • Tenga en cuenta que el "red teaming" no es un reemplazo de la medición sistemática. Un procedimiento recomendado consiste en completar una ronda inicial de formación manual de equipos rojos antes de realizar medidas sistemáticas e implementar mitigaciones. Como se ha destacado anteriormente, el objetivo del red teaming de RAI es identificar los perjuicios, comprender la superficie de riesgo y desarrollar la lista de problemas que pueden informar sobre lo que se debe medir y mitigar.

Aquí se muestra cómo puede comenzar y planificar su proceso de equipos rojos de LLM. La planificación avanzada es fundamental para un ejercicio productivo de equipo rojo.

Antes de realizar pruebas

Plan: Quién hará las pruebas

Formar un grupo diverso de miembros del equipo rojo

Determine la composición ideal de los miembros del equipo rojo en términos de experiencia, datos demográficos y competencia en diferentes áreas (por ejemplo, expertos en inteligencia artificial, ciencias sociales, seguridad) para el ámbito de su producto. Por ejemplo, si va a diseñar un bot de chat para ayudar a los proveedores de atención médica, los expertos médicos pueden ayudar a identificar los riesgos en ese dominio.

Contratar a los equipos rojos con mentalidades benignas y adversas

Tener red teamers con una mentalidad adversarial y experiencia en pruebas de seguridad es esencial para comprender los riesgos de seguridad, pero los red teamers que son usuarios normales del sistema de aplicaciones, y que no han participado en su desarrollo, pueden aportar perspectivas valiosas sobre los daños que podrían encontrar los usuarios habituales.

Asignar equipos rojos a riesgos y/o características del producto

  • Asigne equipos RAI red teams con experiencia específica para investigar tipos específicos de daños (por ejemplo: expertos en seguridad pueden investigar jailbreaks, extracción de prompts y contenido relacionado con ciberataques).

  • Para varias rondas de pruebas, decida si cambiar las tareas de los miembros del equipo rojo en cada ronda para darle diversas perspectivas sobre cada daño y mantener la creatividad. Si cambia las asignaciones, deje tiempo para que los red teamers se familiaricen con las instrucciones de sus nuevas tareas asignadas.

  • En fases posteriores, cuando se desarrolla la aplicación y su interfaz de usuario, es posible que quiera asignar a los miembros del equipo rojo a partes específicas de la aplicación (es decir, funcionalidades) para garantizar la cobertura de toda la aplicación.

  • Tenga en cuenta cuánto tiempo y esfuerzo debe dedicar cada miembro del equipo rojo (por ejemplo, aquellos que prueban escenarios benignos podrían necesitar menos tiempo que aquellos que prueban escenarios adversarios).

Puede ser útil proporcionar al equipo rojo:

  • Instrucciones claras que podrían incluir:
    • Introducción que describe el propósito y el objetivo de la ronda dada de formación de equipos rojos; el producto y las características que se probarán y cómo acceder a ellos; qué tipos de problemas se van a probar; áreas de enfoque de los equipos rojos, si las pruebas son más dirigidas; cuánto tiempo y esfuerzo debe dedicar cada equipo rojo a realizar pruebas; cómo registrar resultados; y quién ponerse en contacto con preguntas.
  • Un archivo o ubicación para registrar sus ejemplos y hallazgos, incluida información como:
    • Fecha en la que se ha expuesto un ejemplo; un identificador único para el par de entrada/salida si está disponible, con fines de reproducibilidad; 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 mediante un modelo base, es posible que tenga que probar en varias capas diferentes:

  • El modelo base de LLM con su sistema de seguridad implementado para identificar las lagunas que pueden necesitar abordarse en el contexto del sistema de aplicaciones. (Normalmente, las pruebas se realizan a través de un punto de conexión de API).

  • Tu 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, antes y después de que las mitigaciones se apliquen.

Las siguientes recomendaciones le ayudarán a elegir qué probar en varios puntos durante la ejecución de un red teaming:

  • Puede comenzar probando el modelo base para comprender la superficie de riesgo, identificar daños y guiar el desarrollo de mitigaciones RAI para el producto.

  • Pruebe las versiones del producto de forma iterativa con y sin mitigaciones RAI para evaluar la eficacia de las mitigaciones RAI. (Tenga en cuenta que es posible que la formación manual de equipos rojos no sea suficiente, use también medidas sistemáticas, pero solo después de completar una ronda inicial de formación manual de equipos rojos).

  • Realice pruebas de aplicaciones en la interfaz de usuario de producción tanto como sea posible, ya que esto se parece más al uso real.

Al notificar los resultados, aclare qué puntos de evaluación se usaron para las pruebas. Cuando se realizaron pruebas en un punto de conexión distinto del producto, considere la posibilidad de volver a probar en el punto de conexión de producción o la interfaz de usuario en futuras rondas.

Plan: Cómo probar

Realice pruebas abiertas para descubrir una amplia gama de daños.

La ventaja de los equipos rojos de Inteligencia Artificial Responsable (RAI) que exploran y documentan cualquier contenido problemático (en lugar de pedirles que encuentren ejemplos de daños específicos) les permite explorar creativamente una amplia gama de problemas, descubriendo puntos ciegos en su comprensión del panorama de riesgos.

Cree una lista de perjuicios de las pruebas abiertas.

  • Considere la posibilidad de crear una lista de daños, con definiciones y ejemplos de daños.
  • Proporcione esta lista como una guía para el equipo rojo en rondas subsiguientes de pruebas.

Realizar ejercicios de red teaming guiados e iterar: Continuar sondeando los daños en la lista e identificar nuevos daños que surjan.

Utilice una lista de daños si está disponible y continúe probando los daños conocidos y la eficacia de sus mitigaciones. En el proceso, es probable que identifique nuevos daños. Integrarlos en la lista y estar abiertos a cambiar las prioridades de medición y mitigación para abordar los daños recién identificados.

Planifique qué daños priorizar para las pruebas iterativas. Varios factores pueden orientar su priorización, incluyendo, entre otros, la gravedad de los daños y el contexto en el que es más probable que se presenten.

Plan: Cómo registrar datos

Decida qué datos necesita recopilar y qué datos son opcionales.

  • Decida qué datos deberán registrar los red teamers (por ejemplo, la entrada que usaron; la salida del sistema; un identificador único, si está disponible, para reproducir el ejemplo en el futuro; y otras notas).

  • Sea estratégico con los datos que está recopilando para evitar sobrecargar a los equipos rojos, a la vez que no pierde información crítica.

Creación de una estructura para la recopilación de datos

Una hoja de cálculo de Excel compartida suele ser el método más sencillo para recopilar datos de red teaming. Una ventaja de este archivo compartido es que los equipos rojos pueden revisar los ejemplos de los demás para obtener ideas creativas para sus propias pruebas y evitar la duplicación de datos.

Durante las pruebas

Planee estar en espera activa mientras la formación de equipos rojas está en curso

  • Esté preparado para ayudar a los equipos de red con instrucciones y problemas de acceso.
  • Monitorea el progreso en la hoja de cálculo y envía recordatorios oportunos a los miembros del equipo rojo.

Después de cada ronda de pruebas

Datos de informe

Comparta un breve informe a intervalos regulares con las partes interesadas clave que:

  1. Enumera los principales problemas identificados.

  2. Proporciona un vínculo a los datos sin procesar.

  3. Presenta el plan de pruebas de las próximas rondas.

  4. Reconoce a los integrantes del equipo rojo.

  5. Proporciona cualquier otra información relevante.

Diferenciar entre la identificación y la medición

En el informe, asegúrese de aclarar que la función del red team de RAI es exponer y aumentar la comprensión de la superficie de riesgos y no es un reemplazo de la medición sistemática y el trabajo riguroso de mitigación. Es importante que las personas no interpreten ejemplos específicos como una métrica para la penetración de ese daño.

Además, si el informe contiene contenido problemático y ejemplos, considere la posibilidad de incluir una advertencia de contenido.

Las instrucciones de este documento no están pensadas para ser y no deben interpretarse como asesoramiento jurídico. La jurisdicción en la que está trabajando puede tener varios requisitos normativos o legales que se aplican al sistema de inteligencia artificial. Tenga en cuenta que no todas estas recomendaciones son adecuadas para cada escenario y, por el contrario, estas recomendaciones pueden ser insuficientes para algunos escenarios.

Pasos siguientes

  • Last updated on