Руководство по безопасности

Генеративные модели искусственного интеллекта — мощные инструменты, но они не лишены ограничений. Их универсальность и применимость порой приводят к неожиданным результатам, например, неточным, предвзятым или оскорбительным. Постобработка и тщательная ручная оценка крайне важны для снижения риска причинения вреда такими результатами.

Модели, предоставляемые API Gemini, могут использоваться в широком спектре приложений генеративного ИИ и обработки естественного языка (NLP). Использование этих функций доступно только через API Gemini или веб-приложение Google AI Studio. Использование API Gemini также регулируется Политикой запрещенного использования генеративного ИИ и условиями обслуживания API Gemini .

Одна из причин, по которой большие языковые модели (LLM) так полезны, заключается в том, что они представляют собой креативные инструменты, способные решать множество различных языковых задач. К сожалению, это также означает, что большие языковые модели могут генерировать неожиданный результат, включая оскорбительный, бестактный или фактически неверный текст. Более того, невероятная универсальность этих моделей также затрудняет точное предсказание того, какой нежелательный результат они могут выдать. Хотя API Gemini был разработан с учётом принципов искусственного интеллекта Google , разработчики обязаны применять эти модели ответственно. Чтобы помочь разработчикам создавать безопасные и ответственные приложения, API Gemini имеет встроенную фильтрацию контента, а также настраиваемые параметры безопасности по 4 измерениям риска. Подробнее см. в руководстве по настройкам безопасности .

Целью настоящего документа является ознакомление вас с некоторыми рисками безопасности, которые могут возникнуть при использовании LLM, а также рекомендации по проектированию и разработке систем безопасности. (Обратите внимание, что законы и нормативные акты также могут налагать ограничения, но эти вопросы выходят за рамки настоящего руководства.)

При создании приложений с участием степеней LLM рекомендуются следующие шаги:

• Понимание рисков безопасности вашего приложения
• Рассмотрение корректировок для снижения рисков безопасности
• Проведение испытаний безопасности, соответствующих вашему варианту использования
• Получение отзывов от пользователей и мониторинг использования

Фазы настройки и тестирования должны быть итеративными до тех пор, пока вы не достигнете производительности, подходящей для вашего приложения.

Понимайте риски безопасности вашего приложения

В этом контексте безопасность определяется как способность LLM избегать причинения вреда своим пользователям, например, путем создания токсичной лексики или контента, способствующего стереотипам. Модели, доступные через API Gemini, были разработаны с учетом принципов ИИ Google, и ваше использование регулируется Политикой запрещенного использования генеративного ИИ . API предоставляет встроенные фильтры безопасности, помогающие решать некоторые распространенные проблемы языковых моделей, такие как токсичная лексика и разжигание ненависти, а также стремление к инклюзивности и избеганию стереотипов. Однако каждое приложение может представлять разный набор рисков для своих пользователей. Поэтому, как владелец приложения, вы несете ответственность за знание своих пользователей и потенциального вреда, который может причинить ваше приложение, а также за обеспечение безопасного и ответственного использования LLM в вашем приложении.

В рамках этой оценки следует оценить вероятность причинения вреда, определить его серьёзность и меры по его минимизации. Например, приложение, генерирующее эссе на основе реальных событий, должно быть более осторожным в плане предотвращения дезинформации, чем приложение, генерирующее вымышленные истории для развлечения. Хороший способ начать изучение потенциальных рисков безопасности — это изучить ваших конечных пользователей и других лиц, на которых могут повлиять результаты работы вашего приложения. Это может принимать различные формы, включая изучение современных исследований в области вашего приложения, наблюдение за тем, как люди используют аналогичные приложения, проведение исследования пользователей, опроса или неформального интервьюирования с потенциальными пользователями.

Рассмотрите возможность внесения корректировок для снижения рисков безопасности

Теперь, когда вы понимаете риски, вы можете решить, как их снизить. Определение приоритетных рисков и необходимых мер по их предотвращению — критически важное решение, подобное сортировке ошибок в программном проекте. Определив приоритеты, можно начать думать о наиболее подходящих способах снижения рисков. Зачастую простые изменения могут иметь решающее значение и снижать риски.

Например, при проектировании приложения следует учитывать:

• Настройка выходных данных модели для лучшего соответствия требованиям вашего приложения. Настройка может сделать выходные данные модели более предсказуемыми и последовательными, а следовательно, помочь снизить определённые риски.
• Предоставление метода ввода, обеспечивающего более безопасные выходные данные. Точность ввода, предоставляемого LLM, может повлиять на качество выходных данных. Эксперименты с подсказками для ввода, чтобы найти наиболее безопасный вариант в вашем случае, стоят затраченных усилий, поскольку затем вы можете создать пользовательский интерфейс, который будет этому способствовать. Например, вы можете ограничить выбор пользователей только раскрывающимся списком подсказок для ввода или предлагать всплывающие подсказки с описательными фразами, которые, по вашему мнению, безопасны в контексте вашего приложения.

• Блокировка небезопасных входных данных и фильтрация выходных данных перед их отображением пользователю. В простых ситуациях чёрные списки могут использоваться для выявления и блокировки небезопасных слов или фраз в подсказках или ответах, а также для того, чтобы люди-рецензенты вручную изменяли или блокировали такой контент.

• Использование обученных классификаторов для маркировки каждого запроса с потенциально вредоносными или враждебными сигналами. В зависимости от типа обнаруженного вредоносного воздействия можно применять различные стратегии обработки запроса. Например, если ввод носит явно враждебный или оскорбительный характер, его можно заблокировать и вместо этого вывести заранее заданный ответ.

  Расширенный совет

  • Если сигналы определяют, что выводимые данные являются вредоносными, приложение может использовать следующие возможности:
    • Предоставьте сообщение об ошибке или заранее заданный вывод.
    • Попробуйте снова ввести приглашение на случай, если будет сгенерирован альтернативный безопасный вывод, поскольку иногда одно и то же приглашение может вызывать разные выводы.

• Внедрение мер защиты от преднамеренного нецелевого использования, таких как присвоение каждому пользователю уникального идентификатора и ограничение количества запросов, которые можно отправить за определённый период. Ещё одной мерой защиты является защита от возможного внедрения подсказок. Внедрение подсказок, подобно SQL-инъекции, — это способ, с помощью которого злоумышленники могут создать подсказку, которая манипулирует результатами работы модели, например, отправляя подсказку, которая предписывает модели игнорировать все предыдущие примеры. Подробнее о преднамеренном нецелевом использовании см. в Политике запрещённого использования генеративного ИИ .

• Адаптация функциональности к чему-то, что изначально сопряжено с меньшим риском. Задачи с более узким охватом (например, извлечение ключевых слов из отрывков текста) или требующие более тщательного контроля со стороны человека (например, создание краткого контента, который будет проверен человеком), часто представляют меньший риск. Например, вместо того, чтобы создавать приложение для написания ответа на электронное письмо с нуля, вы можете ограничиться расширением плана или предложением альтернативных формулировок.

Проведите тестирование безопасности, соответствующее вашему варианту использования.

Тестирование — ключевой элемент создания надёжных и безопасных приложений, но масштаб, область применения и стратегии тестирования могут различаться. Например, генератор хайку, предназначенный просто для развлечения, вероятно, представляет меньшие риски, чем, скажем, приложение, разработанное юридическими фирмами для составления юридических документов и составления договоров. Однако генератор хайку может использоваться более широким кругом пользователей, что означает большую вероятность попыток противодействия или даже непреднамеренного вредоносного ввода. Контекст реализации также имеет значение. Например, приложение, выходные данные которого проверяются экспертами-людьми перед выполнением каких-либо действий, может считаться менее склонным к созданию вредоносных результатов, чем аналогичное приложение без такого контроля.

Нередко приходится проходить несколько итераций внесения изменений и тестирования, прежде чем быть уверенным в готовности к запуску, даже для приложений с относительно низким уровнем риска. Для приложений ИИ особенно полезны два вида тестирования:

• Бенчмаркинг безопасности включает в себя разработку метрик безопасности, отражающих возможные риски для вашего приложения в контексте его вероятного использования, а затем тестирование производительности приложения по этим метрикам с помощью оценочных наборов данных. Рекомендуется заранее продумать минимально приемлемые уровни метрик безопасности, чтобы 1) можно было сравнить результаты тестирования с этими ожиданиями и 2) собрать оценочный набор данных на основе тестов, оценивающих наиболее важные для вас метрики.

  Дополнительные советы

  • Остерегайтесь чрезмерно полагаться на «готовые» подходы, поскольку, скорее всего, вам придется создавать собственные наборы данных для тестирования с использованием оценщиков-людей, чтобы полностью соответствовать контексту вашего приложения.
  • Если у вас несколько метрик, вам нужно решить, как вы будете компенсировать ущерб, если изменение приведет к улучшению одной метрики в ущерб другой. Как и в случае с другими аспектами проектирования производительности, вам может потребоваться сосредоточиться на худшем варианте производительности в вашем наборе оценок, а не на среднем.

• Состязательное тестирование подразумевает проактивные попытки взлома вашего приложения. Цель — выявить слабые места и принять меры по их устранению. Состязательное тестирование может потребовать значительного времени и усилий от экспертов, специализирующихся на вашем приложении, но чем больше вы будете это делать, тем выше ваши шансы обнаружить проблемы, особенно те, которые возникают редко или только после многократных запусков приложения.

  • Состязательное тестирование — это метод систематической оценки модели машинного обучения с целью изучения ее поведения при предоставлении вредоносных или непреднамеренно вредоносных входных данных:
    • Входные данные могут быть вредоносными, если они явно предназначены для создания небезопасного или вредоносного результата — например, когда модель генерации текста получает задание сгенерировать оскорбительную тираду о конкретной религии.
    • Ввод данных является непреднамеренно вредным, когда сам по себе он может быть безобидным, но приводит к вредоносному выводу — например, если попросить модель генерации текста описать человека определенной этнической принадлежности и получить расистский вывод.
  • Состязательный тест отличается от стандартной оценки составом данных, используемых для тестирования. Для состязательных тестов выбираются тестовые данные, которые с наибольшей вероятностью приведут к проблемным результатам работы модели. Это означает проверку поведения модели на все возможные типы вреда, включая редкие или необычные примеры и пограничные случаи, имеющие отношение к политике безопасности. Также следует учитывать разнообразие в различных аспектах предложения, таких как структура, смысл и длина. Подробнее о том, что следует учитывать при создании тестового набора данных, можно узнать в руководстве Google «Ответственный ИИ в вопросах справедливости».

    Дополнительные советы

    • Используйте автоматизированное тестирование вместо традиционного метода привлечения людей в «красные команды», которые пытаются взломать ваше приложение. В автоматизированном тестировании «красная команда» — это ещё одна языковая модель, которая находит входной текст, вызывающий вредоносные результаты в тестируемой модели.

Мониторинг проблем

Сколько бы вы ни тестировали и ни устраняли проблемы, идеала гарантировать невозможно, поэтому заранее планируйте, как будете выявлять и устранять возникающие проблемы. Распространенные подходы включают в себя создание контролируемого канала для пользователей, где они смогут делиться отзывами (например, ставить оценки «нравится» или «не нравится»), и проведение исследования пользователей для заблаговременного сбора отзывов от разных групп пользователей — это особенно полезно, если модели использования отличаются от ожидаемых.

Следующие шаги

• Информацию о настраиваемых параметрах безопасности, доступных через API Gemini, см. в руководстве по настройкам безопасности.
• Ознакомьтесь с введением в подсказки, чтобы начать писать свои первые подсказки.