Planeamiento de red equipoing 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 equipoing 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 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é es el red equipoing de RAI una práctica importante?

El red equipoing es un procedimiento recomendado en el desarrollo responsable de sistemas y características con LLM. 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 equipoing 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.
  • Tener en cuenta que los procedimientos de red equipoing no reemplazan la medición sistemática. Un procedimiento recomendado consiste en completar una ronda inicial de red equipoing manual antes de realizar mediciones sistemáticas e implementar mitigaciones. Como se ha indicado anteriormente, el objetivo de los procedimientos de red equipoing 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 equipoing 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.

Reclute miembros del equipo red con mentalidad tanto positiva como adversa

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.

Asigne miembros del equipo red a daños o características del producto

  • Asigne miembros del equipo red 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 equipo red 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 equipo 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 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 lo siguiente a los miembros del red equipo:

  • 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 LLM con su sistema de seguridad para identificar cualquier brecha que se deba abordar en el contexto de su sistema de aplicación. (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 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 equipoing:

  • 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 esas mitigaciones. (Tenga en cuenta que un proceso de red equipoing manual puede no ser suficiente: use también mediciones sistemáticas, pero solo después de completar una ronda inicial de red equipoing manual).
  • 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 miembros del red equipo 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 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.

Realice procesos de red equipoing guiados e itere: continúe con el sondeo de daños de la lista; identifique nuevos daños que aparezcan.

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).
  • Aplique una estrategia a los datos que recopila para evitar sobrecargar a los miembros del red equipo pero, al mismo tiempo, no perder información crítica.

Creación de 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 equipoing. 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

Esté activo en espera mientras se llevan a cabo los procesos de red equipoing

  • Esté preparado para ayudar a los miembros del red equipo con las instrucciones y los 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 el rol de los procesos de red equipoing 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 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