Guía de seguridad

Parte de lo que hace que los modelos grandes de lenguaje (LLM) sean tan útiles es que son herramientas creativas que pueden abordar muchas tareas lingüísticas diferentes. Lamentablemente, esto también significa que los modelos grandes de lenguaje pueden generar resultados inesperados, como texto ofensivo, insensible o con datos incorrectos. Además, la increíble versatilidad de estos modelos es lo que dificulta predecir exactamente qué tipo de resultados no deseados podrían producir. Si bien la API de Gemini se diseñó teniendo en cuenta los principios de la IA de Google, la responsabilidad es que los desarrolladores apliquen estos modelos de manera responsable. Para ayudar a los desarrolladores a crear aplicaciones seguras y responsables, la API de Gemini tiene filtrado de contenido integrado, así como configuración de seguridad ajustable en 4 dimensiones de daño. Consulta la guía de configuración de seguridad para obtener más información.

El objetivo de este documento es presentarte algunos riesgos de seguridad que pueden surgir cuando se usan LLM y recomendar recomendaciones emergentes de diseño y desarrollo de seguridad. (ten en cuenta que las leyes y reglamentaciones también pueden imponer restricciones, pero tales consideraciones están fuera del alcance de esta guía).

Los siguientes pasos se recomiendan cuando se compilan aplicaciones con LLM:

• Información sobre los riesgos de seguridad de tu aplicación
• Considerar ajustes para mitigar los riesgos de seguridad
• Realiza pruebas de seguridad adecuadas para tu caso de uso
• Solicitar comentarios de los usuarios y supervisar el uso

Las fases de ajuste y prueba deben ser iterativas hasta que alcances un rendimiento adecuado para tu aplicación.

Comprende los riesgos de seguridad de tu aplicación

En este contexto, la seguridad se define como la capacidad de un LLM de evitar causar daño a sus usuarios, por ejemplo, mediante la generación de lenguaje o contenido tóxico que promueva estereotipos. Los modelos disponibles a través de la API de Gemini se diseñaron teniendo en cuenta los principios de la IA de Google, y tu uso está sujeto a la Política de Uso Prohibido de IA Generativas. La API proporciona filtros de seguridad integrados para ayudar a abordar algunos problemas comunes de los modelos de lenguaje, como el lenguaje tóxico y la incitación al odio o a la violencia, y la lucha por la inclusión y la prevención de estereotipos. Sin embargo, cada aplicación puede representar un conjunto diferente de riesgos para los usuarios. Por lo tanto, como propietario de la aplicación, eres responsable de conocer a tus usuarios y de los posibles daños que esta puede causar, y de asegurarte de que esta use los LLM de forma segura y responsable.

Como parte de esta evaluación, debes considerar la probabilidad de que ocurra un daño y determinar su gravedad y las medidas de mitigación. Por ejemplo, una app que genera ensayos basados en hechos fácticos debería tener más cuidado a la hora de evitar la información errónea que una app que genera historias ficticias para el entretenimiento. Una buena manera de comenzar a explorar los posibles riesgos de seguridad es investigar a tus usuarios finales y a otras personas que podrían verse afectadas por los resultados de tu aplicación. Esto puede adoptar muchas formas, como investigar estudios de vanguardia en el dominio de tu app, observar cómo las personas usan apps similares o ejecutar un estudio de usuarios o encuestas, o realizar entrevistas informales a usuarios potenciales.

Considera realizar ajustes para mitigar los riesgos de seguridad.

Ahora que comprendes los riesgos, puedes decidir cómo mitigarlos. Determinar qué riesgos priorizar y cuánto debes hacer para evitarlos es una decisión crítica, similar a clasificar errores en un proyecto de software. Una vez que hayas determinado las prioridades, puedes comenzar a pensar en los tipos de mitigaciones que serían las más adecuadas. A menudo, los cambios simples pueden marcar la diferencia y reducir los riesgos.

Por ejemplo, cuando diseñes una aplicación, ten en cuenta lo siguiente:

• Ajusta la salida del modelo para que refleje mejor lo que es aceptable en el contexto de tu aplicación. El ajuste puede hacer que el resultado del modelo sea más predecible y coherente y, por lo tanto, puede ayudar a mitigar ciertos riesgos.
• Proporcionar un método de entrada que facilite resultados más seguros La entrada exacta que le proporciones a un LLM puede marcar una diferencia en la calidad del resultado. Experimentar con mensajes de entrada para encontrar lo que funciona de forma más segura en tu caso de uso vale la pena el esfuerzo, ya que así podrás proporcionar una UX que lo facilite. Por ejemplo, puedes impedir que los usuarios elijan entre una lista desplegable de mensajes de entrada, o bien ofrecer sugerencias emergentes con frases descriptivas que funcionen de forma segura en el contexto de la aplicación.

• Bloquear entradas no seguras y filtrar resultados antes de que se muestren al usuario En situaciones simples, se pueden usar listas de entidades bloqueadas para identificar y bloquear palabras o frases no seguras en instrucciones o respuestas, o exigir que los revisores manuales alteren o bloqueen ese contenido de forma manual.

• Usar clasificadores entrenados para etiquetar cada instrucción con posibles daños o indicadores adversarios Luego, se pueden usar diferentes estrategias para manejar la solicitud según el tipo de daño detectado. Por ejemplo, si la entrada es abiertamente adversaria o abusiva, se podría bloquear y mostrar una respuesta preestablecida.

  Sugerencia avanzada

  • Si los indicadores determinan que el resultado es dañino, la aplicación puede emplear las siguientes opciones:
    • Proporciona un mensaje de error o un resultado prescrito.
    • Prueba la instrucción de nuevo, en caso de que se genere un resultado seguro alternativo, ya que, a veces, la misma instrucción generará diferentes resultados.

• Implementar protecciones contra el uso inadecuado deliberado, como asignar a cada usuario un ID único o imponer un límite en el volumen de consultas de los usuarios que se pueden enviar en un período determinado Otra protección es tratar de brindar protección contra una posible inyección de instrucciones. La inyección de instrucciones, al igual que la inyección de SQL, permite que los usuarios maliciosos diseñen una instrucción de entrada que manipule la salida del modelo, por ejemplo, mediante una solicitud de entrada que le indica al modelo que ignore los ejemplos anteriores. Consulta la Política de Uso Prohibido de IA Generativas para obtener detalles sobre el uso inadecuado deliberado.

• Ajustar la funcionalidad a algo que es inherentemente menos riesgoso Las tareas que tienen un alcance menor (p.ej., extraer palabras clave de pasajes de texto) o que tienen una mayor supervisión humana (p.ej., generar contenido de formato corto que una persona revisará), suelen suponer un riesgo menor. Por ejemplo, en lugar de crear una aplicación para escribir una respuesta por correo electrónico desde cero, puedes limitarla a ampliar un esquema o sugerir frases alternativas.

Realiza pruebas de seguridad adecuadas según tu caso de uso.

Las pruebas son una parte clave de la compilación de aplicaciones sólidas y seguras, pero el alcance, el alcance y las estrategias para las pruebas variarán. Por ejemplo, es probable que un generador de haiku solo por diversión suponga riesgos menos graves que, por ejemplo, una aplicación diseñada para que la usen los bufetes de abogados para resumir documentos legales y ayudar a redactar contratos. Sin embargo, una variedad más amplia de usuarios puede usar el generador de haiku, lo que significa que puede ser mayor el potencial de intentos adversarios o, incluso, de entradas nocivas no deseadas. El contexto de implementación también es importante. Por ejemplo, es posible que se considere menos probable que una aplicación con resultados revisados por expertos humanos antes de tomar cualquier medida produzca resultados dañinos que una aplicación idéntica sin esa supervisión.

Es común pasar por varias iteraciones para realizar cambios y pruebas antes de sentirte seguro de que está todo listo para el lanzamiento, incluso para aplicaciones que presentan un riesgo relativamente bajo. Hay dos tipos de pruebas que son particularmente útiles para aplicaciones de IA:

• Las comparativas de seguridad implican diseñar métricas de seguridad que reflejen las formas en que tu aplicación podría no ser segura en el contexto de cómo es probable que se use y, luego, probar el rendimiento de la aplicación en las métricas con conjuntos de datos de evaluación. Te recomendamos que pienses en los niveles mínimos aceptables de métricas de seguridad antes de realizar las pruebas, de modo que 1) puedas evaluar los resultados de la prueba en función de esas expectativas y 2) puedas recopilar el conjunto de datos de evaluación en función de las pruebas que evalúan las métricas que más te interesan.

  Sugerencias avanzadas

  • Ten cuidado de no depender demasiado de los enfoques “listos para usar”, ya que es probable que debas compilar tus propios conjuntos de datos de prueba con evaluadores manuales para que se adapten completamente al contexto de tu aplicación.
  • Si tienes más de una métrica, deberás decidir cómo realizarás el intercambio si un cambio genera mejoras para una métrica en detrimento de otra. Al igual que con otra ingeniería de rendimiento, te recomendamos que te enfoques en el peor de los casos de rendimiento en todo el conjunto de evaluación en lugar del rendimiento promedio.

• Las pruebas adversarias implican intentar interrumpir tu aplicación de forma proactiva. El objetivo es identificar los puntos débiles para que puedas tomar medidas y corregirlos según corresponda. Las pruebas adversarias pueden requerir mucho tiempo o esfuerzo de los evaluadores con experiencia en tu aplicación, pero cuanto más hagas, mayor será la probabilidad de detectar problemas, especialmente aquellos que ocurren rara vez o solo después de ejecuciones repetidas de la aplicación.

  • 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 le proporcionan entradas maliciosas o dañinas de forma involuntaria:
    • Una entrada puede ser maliciosa cuando está claramente diseñada para producir un resultado inseguro o dañino, por ejemplo, pedirle a un modelo de generación de texto que genere insultos sobre una religión en particular.
    • Una entrada es dañina de forma inadvertida cuando puede ser inocua, pero produce una salida dañina, por ejemplo, solicitar a un modelo de generación de texto que describa a una persona de un origen étnico en particular y recibir un resultado racista.
  • Lo que distingue una prueba adversaria de una evaluación estándar es la composición de los datos que se usan para las pruebas. Para pruebas adversarias, selecciona los datos de prueba que tengan más probabilidades de generar resultados problemáticos en el modelo. Esto significa sondear el comportamiento del modelo para todos los tipos de daños posibles, incluidos los ejemplos raros o inusuales y los casos límite que son relevantes para las políticas de seguridad. También debe incluir diversidad en las diferentes dimensiones de una oración, como la estructura, el significado y la longitud. Puedes consultar las prácticas de IA responsable de Google sobre equidad para obtener más detalles sobre lo que se debe tener en cuenta cuando se compila un conjunto de datos de prueba.

    Sugerencias avanzadas

    • Usa las pruebas automatizadas en lugar del método tradicional para incorporar personas a los “equipos de emergencia” a fin de intentar dañar tu aplicación. En las pruebas automatizadas, el "equipo de simulación de ataque" es otro modelo de lenguaje que encuentra texto de entrada que provoca resultados dañinos en el modelo que se está probando.

Monitorear problemas

Sin importar cuánto pruebes y mitigues, nunca puedes garantizar la perfección, así que planifica con anticipación cómo detectarás y abordarás los problemas que surjan. Los enfoques comunes incluyen configurar un canal supervisado para que los usuarios compartan comentarios (p.ej., calificar los Me gusta o No me gusta) y ejecutar un estudio de usuarios para solicitar de manera proactiva comentarios de una combinación diversa de usuarios, en especial si los patrones de uso son diferentes a las expectativas.

Próximos pasos

• Consulta la guía de configuración de seguridad para obtener información sobre las configuraciones de seguridad ajustables disponibles en la API de Gemini.
• Consulta la introducción a las instrucciones para comenzar a escribir tus primeras instrucciones.