Cómo Salesforce crea una infraestructura de Red Teaming reproducible

Introducción

Imagine que está trabajando en un producto de IA que puede resumir las llamadas telefónicas de éxito de los clientes con fines de formación. El producto de su empresa aprovecha grandes modelos de lenguaje (LLM) para resumir, sintetizar, clasificar y generar resultados relevantes. Usted es consciente de que los LLM pueden alucinar, generar texto dañino o tendencioso, o ser manipulados mediante ataques de inyección puntual. Como empleado responsable, desea ejecutar pruebas más sólidas que las pruebas de aceptación rutinarias, como utilizar más datos y ampliar la superficie de riesgo. ¿Qué necesita para ejecutar esas pruebas? Los profesionales que intentan diseñar, implementar y ejecutar estas pruebas están tratando de responder a esta pregunta. Esta entrada de blog proporciona nuestra respuesta de alto nivel, describiendo cuatro componentes que recomendamos a la hora de diseñar, implementar y ejecutar una prueba:

1. Datos: Los datos de alta calidad son esenciales para probar características, productos y modelos de IA.
2. Acceso programático a los productos: La capacidad de automatizar las pruebas, lo que permite la reproducibilidad y la reducción del tiempo de obtención de valor.
3. Taxonomía: Cree una taxonomía para evaluar los resultados, asegurándose de que su análisis se alinea con las políticas de la empresa, los principios de IA responsable (RAI) y los objetivos de su prueba específica.
4. Plan de pruebas: La creación de un plan de pruebas alinea adecuadamente a todas las partes interesadas con los mismos objetivos y ayuda a determinar el alcance del trabajo técnico para ejecutar la prueba.

El equipo Responsible AI & Tech de Salesforce ha realizado varias actividades internas de red teaming para mejorar la eficacia y seguridad de nuestros productos de IA. A continuación encontrará más información sobre cada componente.

Data

La base de cualquier prueba de un sistema de IA son los datos de «alta calidad». Pero, ¿qué significa que los datos sean de alta calidad? Nos centramos en tres aspectos de los datos de alta calidad que representan algunos de los mayores obstáculos a los que se enfrentan las organizaciones hoy en día: Datos específicos de casos de uso, almacenamiento de datos para su reproducibilidad y mantenimiento de datos. 

1. Datos específicos de casos de uso

Los datos de alta calidad son contextuales, tanto si está realizando una prueba adversarial amplia para un modelo como una prueba más profunda para un producto. Estos son algunos consejos para crear datos específicos de casos de uso:

• Asegúrese de que los datos que está generando cumplen los casos de uso que espera probar. Como ejemplo, para resumir las llamadas telefónicas de éxito de los clientes con fines de formación, las transcripciones o los datos de llamadas de voz serían útiles. Pero los datos deben proceder de llamadas de atención al cliente. Las llamadas de ventas pueden ser un proxy decente, pero agarrar transcripciones de un tutorial de cocina de YouTube no funcionaría.
• Tenga un método para transformar sus datos. Una vez que tenga datos, habrá ocasiones en las que querrá transformarlos en algo que cumpla con una definición de prueba específica. Por ejemplo, puede utilizar un LLM para transformar las transcripciones de llamadas en transcripciones con lenguaje nocivo para probar si el producto emitirá lenguaje nocivo.
• Tener un mecanismo para generar datos. Entre los ejemplos se incluyen:
• Hacer que un LLM genere datos y luego hacer que los humanos validen los datos;
• Involucrarse en pruebas de usuario y recopilar sus pares de entrada/salida;
• Involucrarse en un ejercicio interno de equipo rojo; o
• Contratar a un proveedor que pueda elaborar datos para su caso de uso específico.

Cada una de estas opciones tiene sus pros y sus contras en términos de coste, tiempo y eficacia, pero disponer de al menos un mecanismo para generar datos es importante para asegurarse de que puede realizar pruebas.

2. Almacenamiento de datos para la reproducibilidad

Ahora que se han obtenido los datos, almacenarlos es el siguiente paso para disponer de datos de alta calidad. Hay un par de componentes clave a la hora de almacenar los datos:

• Permisos: Asegúrese de que muchos equipos tienen acceso a los datos, pero pocos pueden editarlos. Esto es para que los equipos puedan replicar sus pruebas, pero no puedan corromper los datos de base sobre los que se construyeron las pruebas.
• Trazabilidad: Cada punto de datos debe ser identificable de forma única para que los equipos puedan triar puntos de datos específicos y rastrear violaciones éticas específicas.
• Lineamiento: También es muy importante realizar un seguimiento de la procedencia de los datos, el tiempo que llevan almacenados y los casos de uso para los que estaban destinados. Si un equipo tiene tiempo para crear y mantener una hoja de datos, aún mejor.

En un mundo ideal, su equipo crearía una base de datos adecuada para almacenar sus datos. Sin embargo, si la gente se siente más cómoda con las hojas de cálculo, empiece con eso y evolucione la estrategia de almacenamiento de datos con el tiempo. Lo más importante es contar con una estrategia clara de almacenamiento de datos y luego convertirla en algo sostenible para la empresa.

3. Mantenimiento de datos

Por último, los datos de alta calidad requieren mantenimiento. Se trata de un cambio de mentalidad: en lugar de pensar en los datos como un objeto estático que una empresa recopila, piense en los datos como un recurso sobre el que seguir construyendo. Entre los problemas más comunes están los datos que llevan mucho tiempo almacenados, que obligan a recopilar nuevos datos con fines similares o que tienen algo adyacente a los datos exactos que se necesitan. Hay una miríada de otros ejemplos que son muy específicos para cada caso de uso, pero conciliar el hecho de que los datos deben mantenerse actualizados es crucial para la eficacia de las pruebas.

Acceso programático a productos

Cuando están en preproducción, la mayoría de las organizaciones tendrán una interfaz de usuario para hacer pruebas. Pero eso no escala bien si quieres usar cientos o más puntos de datos. Por eso es necesario tener código para acceder programáticamente a los productos. Esto puede sonar básico, pero a menos que su producto fue construido para tener acceso programático, esto sería muy difícil. Recomendamos:

1. Diseñar su producto para tener accesibilidad programática para escalar las pruebas. Para los modelos, esto normalmente significa sacar un modelo de Hugging Face o acceder a un punto de control de la API. Sin embargo, para los productos esto puede ser un poco más complicado, ya que depende de cómo los equipos de ingeniería de arquitectura del producto. Si primero crearon la API del producto, esto es fácil de resolver. Pero si los productos no se construyen con una API fácil de usar, la construcción de algo así como un cliente Python puede ser necesario.
2. Tener alguna documentación para otros ingenieros en su org para entender cómo utilizar la API o cliente Python. Esto incluye los parámetros necesarios, la configuración requerida, y el código boilerplate.
3. Si se satisface lo anterior, se puede tomar un paso adicional opcional: la construcción de su propio paquete que puede automatizar sus pruebas. Al vincularse a las API de forma adecuada, un paquete bien construido puede ayudar a garantizar que las pruebas repetidas sean réplicas reales, mejorando la reproducibilidad.

En una futura entrada del blog, discutiremos cómo la construcción de un paquete de este tipo permite la creación de equipos rojos automatizados y qué componentes se deben construir para ello.

Taxonomía

Una vez que se reciben los resultados del modelo, es necesario evaluarlos para determinar qué tan bien funcionó el sistema. Para informar sobre ello con confianza, tendrá que crear definiciones claras que puedan utilizarse como punto de calibración para todas las partes interesadas. Por ejemplo, para las pruebas de toxicidad, debe definir qué es la toxicidad para su caso de uso. Determinar cómo de específico quieres ser en tu conceptualización te ahorrará mucho trabajo de refactorización. Este trabajo debe hacerse en conjunto con los equipos de producto e ingeniería para crear el mejor ajuste para su caso de uso.

Algunas de las mejores prácticas para el diseño, mantenimiento e implementación de taxonomías y normas son las siguientes:

1. Crear un glosario de términos específicos para su proyecto y dominio. A menudo, habrá términos que se reutilicen con significados ligeramente diferentes dentro del mismo espacio del proyecto. Encuentre todos los usos de términos ambiguos y facilite una conversación para lograr una alineación sobre cuál debería ser la definición singular estándar para cada término. Documente bien esta definición singular y asegúrese de que todas las partes interesadas tienen acceso al glosario.
2. Determine la superficie del problema. Considere tantos casos límite como sea posible y traiga colaboradores con diferentes perspectivas para que le ayuden a ampliar su pensamiento. Una vez que haya determinado la superficie general, puede avanzar en la definición de las entradas taxonómicas, crear ejemplos y pensar en cómo implementar esto en las pruebas.
3. Defina los umbrales para las pruebas. Cuando cualquier persona, ya sea interna, externa o crowdsourced, evalúa la calidad de los resultados del modelo, debe estar alineada con la taxonomía y las definiciones que ha desarrollado. Estas funcionan como normas que aumentan la fiabilidad entre evaluadores y ayudan a garantizar que su evaluación responde a la pregunta central de sus pruebas.
4. Alinearse con las partes interesadas en esta única fuente de verdad. Para colaborar con la mayor eficacia posible, todas las partes interesadas deben «hablar el mismo idioma» Una vez que se ha establecido una taxonomía y todas las partes interesadas están de acuerdo, las pruebas resultan más sencillas. Una taxonomía bien elaborada alimenta los procesos automatizados, aportando rigor y estructura al etiquetado automático y a la generación de preguntas. Las normas y definiciones, especialmente en ámbitos con un alto grado de subjetividad (como la ética), permiten una programación más eficaz de estos conceptos de alto nivel en la infraestructura de pruebas.

   Plan de pruebas

   Se han recopilado los datos. Se ha establecido una base de código para automatizar fácilmente las pruebas. La organización y los datos se han alineado con una taxonomía. La última capa de la infraestructura es cómo comunicarse e interactuar con los equipos de producto. Esto puede ir desde integrar a un experto en RAI en el equipo hasta asesorar a los equipos sobre cómo deben diseñar e implementar las pruebas.

   En Salesforce, los equipos de producto rellenan un formulario que recoge detalles como la forma en que funcionará el producto, qué salvaguardas éticas existen ya, etcétera. Las respuestas a estas preguntas son evaluadas por nuestro equipo de gestores de producto responsables de IA y tecnología. Si determinan que el producto necesita ser revisado, elaboran una Revisión Ética del Producto, que clasifica los diversos riesgos potenciales y los daños derivados. Dependiendo de la naturaleza del producto o del modelo, los riesgos identificados pueden ser limitados y profundos o diversos y amplios.

   El equipo de Pruebas, Evaluación y Alineación de nuestro equipo de Inteligencia Artificial y Tecnología Responsables diseña pruebas con el equipo de producto en torno a los riesgos identificados. Se genera un plan de pruebas para gestionar las expectativas de las partes interesadas, así como para delimitar el alcance de cualquier trabajo técnico. Durante la ejecución de la prueba, pueden elaborarse directrices de etiquetado y guardarraíles de salud mental para facilitar el etiquetado de los resultados nocivos. Se analizan los resultados, se comunican los fallos y se redacta un informe para la dirección. Una vez implementadas las mitigaciones, también se realizan pruebas de seguimiento para garantizar que se han reducido los riesgos.

   Conclusión

   Cada vez que una organización realice pruebas, necesitará datos para ejecutarlas, una forma de acceder al producto mediante programación, taxonomías para la alineación y un proceso para la comunicación y la ejecución. Aunque el objetivo es tener esta infraestructura establecida cada vez que se ejecuta una prueba, a veces tenemos que hacer datos ad hoc, y a veces nuestros planes de prueba no están escritos con el mayor detalle. Pero utilizamos esto como nuestra estrella polar, algo a lo que aspirar cada vez que hacemos una prueba. Porque al final del día, si podemos ejecutar pruebas de alta calidad rápidamente, eso reducirá la cantidad de tiempo que necesitamos para entregar nuestros resultados, y aumentará la cantidad de tiempo que los equipos de producto necesitan para mitigarlos, asegurando que los productos puedan ser enviados de forma segura.

   Test de calidad