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

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

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

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

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

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

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

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

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

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

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

Например, при разработке приложения учитывайте:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Следите за проблемами

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

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

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