Планирование красной команды для больших языковых моделей (LLM) и их приложений (классическая модель)

В настоящее время просмотр:Классическая версия портала Foundry - Переключиться на версию нового портала Foundry

В этом руководстве предлагаются потенциальные стратегии по настройке и управлению красным командированием для рисков ответственного использования искусственного интеллекта (RAI) в течение жизненного цикла продуктов на основе большой языковой модели (LLM).

Что такое красная команда?

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

Почему RAI red teaming является важной практикой?

Анализ с использованием метода «Red Teaming» является наилучшей практикой в ответственной разработке систем и функций с помощью LLM. Хотя и не замена систематической работы по измерению и устранению рисков, красные команды помогают выявить и определить вред, и, в свою очередь, позволяют стратегиям измерения проверить эффективность устранения рисков.

В то время как Microsoft провела учения с участием команды красной проигровки и реализовала системы безопасности (включая контентные фильтры и другие стратегии смягчения) для Azure OpenAI в Microsoft Foundry Models (см. этот Обзор ответственных практик ИИ), контекст каждого приложения LLM будет уникальным, и вы также должны проводить учения с участием команды красной проигровки для:

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

• Выявление и устранение недостатков в существующих фильтрах по умолчанию или стратегиях устранения рисков.

• Предоставьте отзыв о сбоях, чтобы внести улучшения.

• Обратите внимание, что красная команда не является заменой систематического измерения. Рекомендуется выполнить начальный раунд ручного тестирования защиты (red teaming) перед проведением систематических измерений и реализацией мер. Как описано выше, цель красной команды RAI заключается в выявлении нанесения ущерба, понимании поверхности риска и разработке списка угроз, которые могут информировать о том, что необходимо измерять и устранять.

Вот как можно начать работу и запланировать процесс создания красной команды для LLM. Заранеее планирование крайне важно для продуктивного упражнения красной команды.

Перед тестированием

План. Кто будет выполнять тестирование

Собрать разностороннюю группу красных тимеров

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

Нанимайте специалистов по красным командам, обладающих как доброжелательным, так и враждебным мышлением

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

Назначьте специалистов по тестированию безопасности для оценки потенциальных угроз или особенностей продукта

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

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

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

• Рассмотрим, сколько времени и усилий каждый участник красной команды должен посвятить (например, тестирование доброкачественных сценариев может потребовать меньше времени, чем тестирование враждебных сценариев).

Полезно предоставить участникам красной команды:

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

План: что протестировать

Так как приложение разрабатывается с помощью базовой модели, может потребоваться протестировать на нескольких разных уровнях:

• Базовая модель LLM с её системой безопасности, чтобы определить любые пробелы, которые могут потребовать устранения в рамках вашей системы приложений. (Тестирование обычно выполняется через конечную точку API.)

• Ваше приложение. (Тестирование лучше всего выполняется с помощью пользовательского интерфейса.)

• Базовую модель LLM и ваше приложение необходимо оценивать до и после внедрения мер по снижению рисков.

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

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

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

• Проводите тестирование приложений в рабочем пользовательском интерфейсе как можно больше, так как это очень похоже на реальное использование.

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

План: Как провести тестирование

Проводите открытое тестирование, чтобы выявить широкий спектр вреда.

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

Создайте список причинений вреда от открытого тестирования.

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

Проведение управляемого red team'инга и итерации: продолжайте искать угрозы в списке; определите новые угрозы, которые появляются.

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

Планируйте, какие угрозы следует приоритизировать для итеративного тестирования. Некоторые факторы могут влиять на определение приоритетов, включая, но не ограничиваясь серьезностью вреда и контекстом, в котором они, скорее всего, будут проявляться.

План: как записывать данные

Определите, какие данные необходимо собирать и какие данные являются необязательными.

• Определите, какие данные потребуется записать красной команде (например: входные данные, которые они использовали; выходные данные системы; уникальный идентификатор, если он доступен, для будущего воспроизведения примера; и другие заметки).

• Будьте стратегичны с данными, которые вы собираете, чтобы не перегрузить команды красной стороны, при этом не упустить критически важные сведения.

Создание структуры для сбора данных

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

Во время тестирования

Будьте готовы к активному режиму ожидания во время проведения мероприятия красной команды

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

После каждого раунда тестирования

Данные отчета

Предоставляйте краткий отчет с регулярной периодичностью ключевым заинтересованным лицам.

1. Выводит список наиболее выявленных проблем.

2. Предоставляет ссылку на необработанные данные.

3. Обзор плана тестирования на предстоящие раунды.

4. Признает участников красной команды.

5. Предоставляет любую другую соответствующую информацию.

Различие между идентификацией и измерением

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

Кроме того, если отчет содержит проблемное содержимое и примеры, рассмотрите возможность включения предупреждения о содержимом.

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

Дальнейшие шаги

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