Guía de seguridad

Los modelos de inteligencia artificial generativos son herramientas poderosas, pero no lo son sin sus limitaciones. Su versatilidad y aplicabilidad a veces pueden puede generar resultados inesperados, como los que son inexactos, sesgados o ofensivo. El procesamiento posterior y la evaluación manual rigurosa son esenciales limitar el riesgo de daños derivados de dichos productos.

Los modelos que proporciona la API de Gemini pueden usarse para una amplia variedad de la IA generativa y el procesamiento de lenguaje natural (PLN). Uso de estas opciones solo está disponible a través de la API de Gemini o la Web de Google AI Studio . El uso de la API de Gemini también está sujeto al Uso Prohibido de IA Generativas de la API y las Condiciones del Servicio de la API de Gemini.

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 lo que esperas, incluido el texto que sea ofensivo, insensible o incorrecto. Además, la La increíble versatilidad de estos modelos también dificulta para predecir con exactitud qué tipo de resultados no deseados. Si bien el La API de Gemini se diseñó con la IA de Google principios, es responsabilidad de los desarrolladores aplicar estos modelos con responsabilidad. Para ayudar a los desarrolladores a crear soluciones aplicaciones, la API de Gemini tiene un filtro de contenido integrado y también parámetros de seguridad ajustables en 4 dimensiones de daño. Consulta las configuración de seguridad para obtener más información.

Este documento tiene el objetivo de presentarte algunos riesgos de seguridad que pueden surgir cuando con LLM y recomendar diseños y desarrollos de seguridad emergentes recomendaciones. (Ten en cuenta que las leyes y reglamentaciones también pueden imponer restricciones, pero esas consideraciones están fuera del alcance de esta guía).

Se recomiendan los siguientes pasos para compilar aplicaciones con LLM:

• Comprende los riesgos de seguridad de tu aplicación
• Considerar ajustes para mitigar los riesgos de seguridad
• Realizar 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 y 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ños a los usuarios, por ejemplo, a través de la generación de lenguaje o contenido tóxicos que promueve estereotipos. Los modelos disponibles a través de la API de Gemini están diseñado con los principios de la IA de Google en mente y su uso está sujeto al Uso Prohibido de IA Generativas Política. La API proporciona filtros de seguridad integrados que ayudan a abordar algunos modelos de lenguaje problemas como el lenguaje tóxico y la incitación al odio o a la violencia, así como la lucha por la inclusión y evitar los estereotipos. Sin embargo, cada aplicación puede plantear un conjunto diferente de riesgos para sus usuarios. Como propietario de la aplicación, eres responsable de conocer a tus usuarios y los posibles daños que puede causar tu aplicación garantizando que tu aplicación use LLM de manera segura y responsable.

Como parte de esta evaluación, debe considerar la probabilidad de que se produzcan daños y determinar su gravedad y pasos de mitigación. Por ejemplo, un que genera ensayos sobre la base de eventos tendría que ser más cuidadoso para evitar la información errónea, en comparación con una app que genera contenido para entretener. Una buena manera de comenzar a explorar los posibles riesgos de seguridad es investigar a tus usuarios finales y quiénes podrían verse afectados por tu resultados de la aplicación. Esto puede tomar muchas formas, incluida la investigación del estado los estudios de arte en el dominio de su aplicación, observar cómo las personas usan aplicaciones similares, o realizar un estudio de usuarios, una encuesta o realizar entrevistas informales con usuarios potenciales.

Considera realizar ajustes para mitigar los riesgos de seguridad.

Ahora que comprendes los riesgos, puedes decidir cómo mitigarlos de ellos. Determinar qué riesgos priorizar y cuánto debe hacer para intentar prevenirlos es una decisión crítica, similar a priorizar errores en un software en un proyecto final. Una vez que hayas determinado las prioridades, puedes empezar a pensar 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, considera lo siguiente:

• Ajusta la salida del modelo para reflejar mejor lo que es aceptable en tu el contexto de una aplicación. El ajuste puede hacer que la salida del modelo sea más predecibles y coherentes y, por lo tanto, puede ayudar a mitigar ciertos riesgos.
• Proporcionar un método de entrada que facilite los resultados más seguros La entrada exacta que le proporcionas a un LLM puede marcar una diferencia en la calidad del resultado. Experimentar con instrucciones de entrada para descubrir qué funciona de manera más segura en tu caso de uso vale la pena el esfuerzo, ya que puedes proporcionar una UX que lo facilita. Por ejemplo, puedes restringir a los usuarios para que elijan solo una lista desplegable de instrucciones de entrada u ofrece sugerencias en ventanas emergentes con descriptivos las frases que descubriste que funcionan de manera segura en el contexto de tu aplicación.

• Bloquea las entradas no seguras y filtra las salidas 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 requieren revisores humanos para alterar o bloquear manualmente dicho contenido.

• Usar clasificadores capacitados para etiquetar cada instrucción con posibles peligros señales adversarias. Luego, se pueden emplear diferentes estrategias manejar la solicitud según el tipo de daño detectado. Por ejemplo, si el de naturaleza abiertamente adversaria o abusiva, podría bloquearse y en su lugar, mostrará una respuesta prescripta.

  Sugerencia avanzada

  • Si las señales determinan que el resultado es dañino, la aplicación puede emplear las siguientes opciones:
    • Proporciona un mensaje de error o un resultado predefinido.
    • Vuelve a intentar la instrucción, en caso de que una salida segura alternativa sea ya que, a veces, la misma instrucción generará diferentes salidas.

• Implementar protecciones contra el uso inadecuado deliberado, como la asignación de un ID único a cada usuario y, además, imponer un límite en el volumen de consultas de los usuarios que pueden enviarse en un período determinado. Otra medida de protección es tratar de protegerte contra una posible inyección de instrucciones. Inyección de instrucciones, similar a SQL de texto, es una forma para que los usuarios maliciosos diseñen una instrucción de entrada Manipula la salida del modelo, por ejemplo, enviando una instrucción de entrada. que le indique 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 riesgos. 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 (es decir, el contenido que revisa una persona), a menudo representan un riesgo menor. Entonces, para en lugar de crear una aplicación desde la cual escribir una respuesta de correo electrónico desde cero, puedes limitarlo a expandir 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 creación de aplicaciones sólidas y seguras, pero el alcance y las estrategias de las pruebas variarán. Por ejemplo, un haiku solo por diversión generador de perfiles posiblemente suponga riesgos menos graves que, por ejemplo, una aplicación diseñada para que los estudios de abogados los usen para resumir documentos jurídicos y ayudar en la redacción de contratos. Sin embargo, una mayor variedad de usuarios puede usar el generador de haiku, por lo que la posibilidad de intentos adversarios o incluso de entradas dañinas no deseadas mayores. El contexto de la implementación también es importante. Por ejemplo, una aplicación con resultados revisados por expertos humanos antes de tomar medidas podrían considerarse menos propensas a producir resultados dañinos que los productos de la aplicación sin tal supervisión.

No es inusual pasar por varias iteraciones a la hora de hacer cambios y pruebas antes de sentirte seguro de que estás listo para lanzarlo, incluso para aplicaciones que tienen un riesgo relativamente bajo. Hay dos tipos de pruebas que son particularmente útiles para la IA aplicaciones:

• Las comparativas de seguridad implican el diseño de métricas de seguridad que reflejen la maneras en las que tu aplicación podría ser insegura en el contexto de cómo es probable que se utilicen y, luego, prueben el rendimiento de la aplicación según las métricas con conjuntos de datos de evaluación. Es una buena práctica pensar en las especificaciones mínimas aceptables de métricas de seguridad antes de realizar las pruebas, de modo que 1) pueda evalúa los resultados de la prueba en función de esas expectativas y 2) puedes reunir el conjunto de datos de evaluación basado en las pruebas que evalúan las métricas que te interesan más.

  Sugerencias avanzadas

  • Ten cuidado de depender demasiado de los enfoques listos para usar, ya que es probable tendrás que crear tus propios conjuntos de datos de prueba con evaluadores humanos para adaptar completamente al contexto de tu aplicación.
  • Si tienes más de una métrica, deberás decidir cómo compensación si un cambio genera mejoras en una métrica del en detrimento de otra. Al igual que con otras ingeniería de rendimiento, se recomienda que te enfoques en el peor de los casos en tu evaluación establecido, en lugar del rendimiento promedio.

• Las pruebas adversarias implican tratar proactivamente de dañar tu y mantener la integridad de su aplicación. El objetivo es identificar los puntos de debilidad para que puedas pasos para solucionarlos según corresponda. Las pruebas adversarias pueden tardar tiempo y esfuerzo considerables de los evaluadores con experiencia en tu aplicación, pero cuanto más lo hagas, mayor será la probabilidad de detectar problemas, especialmente aquellos que ocurren rara vez o solo después de ejecuciones repetidas de la y mantener la integridad de su aplicación.

  • Las pruebas adversarias son un método para evaluar sistemáticamente un AA modelo con la intención de aprender cómo se comporta cuando se le proporciona entrada maliciosa o dañina inadvertidamente:
    • Una entrada puede ser maliciosa cuando está claramente diseñada para produce un resultado no seguro o dañino, por ejemplo, pedir un mensaje de texto de generación de demanda para generar una incitación al odio o a la violencia religión.
    • Una entrada es dañina de forma involuntaria cuando la entrada en sí puede ser inocuo, pero produce resultados dañinos (por ejemplo, pedir a un texto de generación de demanda para describir a una persona de una etnia determinada y de recibir acciones racistas.
  • Lo que distingue una prueba adversaria de una evaluación estándar es el la composición de los datos que se usan para las pruebas. Para pruebas adversarias, selecciona probar datos que tengan más probabilidades de generar resultados problemáticos el modelo. Esto significa sondear el comportamiento del modelo para todos los tipos de posibles daños, como ejemplos raros o inusuales y de casos extremos relevantes para las políticas de seguridad. También deben incluir diversidad en las diferentes dimensiones de una oración, como la estructura, el significado y la longitud. Consulta el Centro de IA responsable prácticas en equidad para conocer más detalles sobre lo que debes tener en cuenta a la hora de crear un conjunto de datos de prueba.

    Sugerencias avanzadas

    • Usa pruebas automatizadas en lugar del método tradicional de reunir a personas en "equipos rojos" para dañar tu aplicación. En las pruebas automatizadas, "equipo rojo" es otro modelo de lenguaje que encuentra texto de entrada pueden provocar resultados dañinos del modelo que se está probando.

Supervisa para detectar problemas

No importa cuánto pruebes y mitigues, nunca puedes garantizar la perfección, así que planificar por adelantado cómo detectarás y resolverás los problemas que surjan. Común Entre otros enfoques, se incluye configurar un canal supervisado para que los usuarios compartan comentarios (p.ej., calificaciones de Me gusta o No me gusta) y realizar un estudio de usuarios para realizar solicitudes proactivas comentarios de una mezcla diversa de usuarios, en especial valiosos si se determinan diferente de las expectativas.

Próximos pasos

• Consulta las guía de parámetros de configuración de seguridad para obtener información sobre los controles parámetros de configuración de seguridad disponibles a través de la API de Gemini.
• Consulta la introducción a las instrucciones para obtener empezaste a escribir tus primeras consignas.