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

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

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

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

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

Красная команда — это передовая практика в ответственной разработке систем и функций с использованием LLM. Хотя и не замена систематической работы по измерению и устранению рисков, красные команды помогают выявить и определить вред, и, в свою очередь, позволяют стратегиям измерения проверить эффективность устранения рисков.

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

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

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

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

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

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

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

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

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

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

Нанять красных тимеров с позитивным и соперничающим мышлением

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

Назначьте участников красной команды для анализа рисков и/или функций продукта

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

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

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

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

Это может быть полезно, чтобы обеспечить команды красных чем-либо.

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

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

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

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

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

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

Следующие рекомендации помогут вам выбрать, что тестировать на различных этапах при проведении red teaming.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Планируйте быть в активном режиме ожидания, пока проводится проверка безопасности методом красной команды

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

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

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

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

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

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

  3. Предварительный просмотр плана тестирования для предстоящих раундов.

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

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

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

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

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

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

Дальнейшие действия

  • Last updated on