Las pruebas adversarias son un método para evaluar sistemáticamente un modelo de AA con la intención de aprender cómo se comporta cuando se proporciona una entrada maliciosa o perjudicial. En esta guía, se describe un ejemplo de flujo de trabajo de prueba adversario para la IA generativa.
¿Qué son las pruebas adversarias?
Las pruebas son una parte fundamental de la compilación de aplicaciones de IA sólidas y seguras. Las pruebas adversarias implican, de forma proactiva, intentar “interrumpir” una aplicación, proporcionándole datos que probablemente generen resultados problemáticos. Es probable que las consultas adversarias hagan que un modelo falle de manera no segura (es decir, incumplimientos de la política de seguridad) y que causen errores que son fáciles de identificar para las personas, pero difíciles de reconocer por las máquinas.
Las búsquedas pueden ser “adversales” de diferentes maneras. Las consultas adversarias explícitas pueden contener lenguaje que incumpla las políticas o expresar puntos de vista que incumplen las políticas, o indagar o intentar "engañar" al modelo para que diga algo inofensivo, ofensivo o dañino. Las consultas adversarias implícitas pueden parecer inofensivas, pero pueden contener temas delicados que son contenciosos, sensibles a nivel cultural o potencialmente dañinos. Estos pueden incluir información sobre datos demográficos, salud, finanzas o religión.
Las pruebas adversarias pueden ayudar a los equipos a mejorar los modelos y los productos mediante la exposición de fallas actuales a fin de guiar las rutas de mitigación, como el ajuste, la protección de modelos o los filtros. Además, puede ayudar a informar las decisiones de lanzamiento de productos, ya que mide los riesgos que pueden no mitigarse, como la probabilidad de que el modelo tenga contenido que incumple la política de resultados.
Como práctica recomendada emergente para la IA responsable, esta guía proporciona un flujo de trabajo de ejemplo para pruebas adversarias de modelos y sistemas generativos.
Flujo de trabajo de ejemplo de prueba adversaria
Las pruebas adversarias siguen un flujo de trabajo similar a la evaluación de modelos estándar.
Identifica y define entradas
El primer paso del flujo de trabajo de las pruebas adversarias es determinar las entradas para aprender el comportamiento de un sistema cuando se ataca de forma intencional y sistemática. Los comentarios considerados pueden influir directamente en la eficacia del flujo de trabajo de las pruebas. Las siguientes entradas pueden ayudarte a definir el alcance y los objetivos de una prueba adversaria:
- Política del producto y modos de falla
- Casos de uso
- Requisitos de diversidad
Política del producto y modos de falla
Los productos de IA generativa deben definir políticas de seguridad que describan el comportamiento del producto y los resultados del modelo que no están permitidos (es decir, se consideran "no seguros"). La política debe enumerar los modos de falla que se considerarían incumplimientos de política. Esta lista de modos de falla debe usarse como base para las pruebas adversarias. Algunos ejemplos de modos de falla pueden incluir contenido que incluye lenguaje vulgar o consejos financieros, legales o médicos.
Casos de uso
Otra entrada importante a las pruebas adversarias son los casos de uso que el modelo generativo o producto busca entregar, de modo que los datos de prueba contengan alguna representación de las formas en las que los usuarios interactuarán con el producto en el mundo real. Cada producto generativo tiene casos de uso ligeramente diferentes, pero algunos comunes incluyen: búsqueda de datos, resumen y generación de código para modelos de lenguaje; o generación de imágenes de fondos por geografía o terreno, arte o estilo de ropa.
Requisitos de diversidad
Los conjuntos de datos de prueba adversarios deben ser lo suficientemente diversos y representativos en relación con todos los modos de falla y casos de uso objetivo. Medir la diversidad de los conjuntos de datos de prueba ayuda a identificar posibles sesgos y garantiza que los modelos se prueben exhaustivamente con una población de usuarios diversa en mente.
Estas son tres maneras de pensar en la diversidad:
- Diversidad léxica: Asegúrate de que las consultas tengan un rango de longitudes diferentes (p.ej., recuento de palabras), usen un rango amplio de vocabulario, no contengan duplicados y representen diferentes formulaciones de consultas (p.ej., wh-questions, directas e indirectas).
- Diversidad semántica: Asegúrate de que las consultas abarquen una amplia gama de temas diferentes por política (p.ej., diabetes para la salud), incluidas características sensibles y basadas en la identidad (p.ej., género, etnia), en diferentes casos de uso y contextos globales.
- Diversidad de casos de uso de políticas y casos de uso:Asegúrate de que las consultas abarquen todos los casos de incumplimiento de políticas (p.ej., incitación al odio o a la violencia) y de uso (p.ej., consejos de expertos).
Busca o crea conjuntos de datos de prueba
Los conjuntos de datos de prueba para pruebas adversarias se construyen de forma diferente a los conjuntos de prueba estándar de evaluación de modelos. En las evaluaciones de modelos estándar, los conjuntos de datos de prueba suelen estar diseñados para reflejar con exactitud la distribución de los datos que el modelo encontrará en el producto. En las pruebas adversariales, los datos de prueba se seleccionan para exigir resultados problemáticos del modelo, ya que prueban el comportamiento del modelo en ejemplos fuera de distribución y casos extremos que son relevantes para las políticas de seguridad. Un conjunto de pruebas adversarios de alta calidad debe abarcar todas las dimensiones de la política de seguridad y maximizar la cobertura de los casos de uso que el modelo pretende admitir. Debe ser diverso de forma léxica (p.ej., consultas de varias longitudes e idiomas) y semántica (p.ej., que abarque diferentes temas y datos demográficos).
Investiga conjuntos de datos de prueba existentes para determinar la cobertura de las políticas de seguridad, los modos de falla y los casos de uso de los modelos de generación de texto y de imagen a imagen. Los equipos pueden usar conjuntos de datos existentes para establecer un modelo de referencia del rendimiento de sus productos y, luego, realizar análisis más detallados sobre modos de falla específicos con los que tienen problemas.
Si los conjuntos de datos de prueba existentes no son suficientes, los equipos pueden generar datos nuevos para orientarse a modos de falla y casos de uso específicos. Una forma de crear conjuntos de datos nuevos es comenzar con la creación manual de un pequeño conjunto de datos de consultas (es decir, decenas de ejemplos por categoría) y, luego, expandir este conjunto de datos “semilla” con herramientas de síntesis de datos.
Los conjuntos de datos iniciales deben contener ejemplos que sean lo más similares posible a lo que el sistema encontrará en la producción y se crearán con el objetivo de provocar un incumplimiento de política. Es probable que las funciones de seguridad detecten un lenguaje muy tóxico, por lo que debes considerar el fraseo creativo y las entradas implícitamente adversarias.
Puedes usar referencias directas o indirectas a atributos sensibles (p.ej., edad, género, raza, religión) en tu conjunto de datos de prueba. Ten en cuenta que el uso de estos términos puede variar según la cultura. Varía el tono, la estructura de las oraciones, la elección de palabras de longitud y el significado. Los ejemplos en los que se pueden aplicar varias etiquetas (p. ej., incitación al odio o a la violencia) y omisiones, pueden generar ruido y duplicación, y es posible que los sistemas de evaluación o entrenamiento no los manejen de forma adecuada.
Los conjuntos de pruebas adversarios deben analizarse para comprender su composición en términos de diversidad léxica y semántica, cobertura de los incumplimientos de política y los casos de uso, y la calidad general en términos de singularidad, adversaria y ruido.
Genera resultados de modelos
El siguiente paso es generar resultados de modelos basados en el conjunto de datos de prueba. Los resultados informarán a los equipos de productos cuál será el rendimiento de sus modelos cuando se expongan a usuarios maliciosos o entradas no deseadas de forma inadvertida. Identificar estos comportamientos y patrones de respuesta del sistema puede proporcionar mediciones de referencia que pueden mitigarse en el desarrollo futuro del modelo.
Anota los resultados
Una vez que se generen resultados de pruebas adversarias, anótalas para categorizarlas en modos de falla o daños. Estas etiquetas pueden ayudar a proporcionar indicadores de seguridad para el contenido de texto y de imagen. Además, los indicadores pueden ayudar a medir y mitigar los daños en los modelos y productos.
Los clasificadores de seguridad se pueden usar para anotar automáticamente los resultados (o entradas) del modelo en caso de incumplimientos de política. La precisión puede ser baja en los indicadores que intentan detectar construcciones que no están estrictamente definidas, como la incitación al odio o a la violencia. Para estos indicadores, es fundamental usar evaluadores humanos a fin de verificar y corregir las etiquetas generadas por el clasificador en las que las puntuaciones son "inciertas".
Además de la anotación automática, puedes aprovechar a los evaluadores humanos para que anoten una muestra de tus datos. Es importante tener en cuenta que anotar los resultados del modelo como parte de las pruebas adversarias implica necesariamente observar el texto o las imágenes problemáticos o potencialmente dañinos, de manera similar a la moderación manual del contenido. Además, los evaluadores humanos pueden anotar el mismo contenido de manera diferente según su origen, sus conocimientos o creencias. Puede ser útil desarrollar lineamientos o plantillas para evaluadores, teniendo en cuenta que la diversidad de tu grupo de evaluadores podría influir en los resultados de la anotación.
Informa y mitiga
El paso final es resumir los resultados de la prueba en un informe. Métricas de procesamiento y resultados de informes para proporcionar porcentajes de seguridad, visualizaciones y ejemplos de fallas problemáticas. Estos resultados pueden servir para guiar las mejoras del modelo y justificar las protecciones, como los filtros o las listas de entidades bloqueadas. Los informes también son importantes para la comunicación con las partes interesadas y los responsables de tomar decisiones.
Recursos adicionales
El equipo rojo de la IA de Google: los hackers éticos que mejoran la IA
Modelos de idiomas en equipo rojos con modelos de idiomas
Pruebas de equidad de productos para desarrolladores de aprendizaje automático (video):
Pruebas de equidad de productos para desarrolladores (Codelab)