Планирование красной команды для больших языковых моделей (LLM) и их приложений
В этом руководстве представлены некоторые потенциальные стратегии планирования настройки и управления красным командированием для ответственных рисков искусственного интеллекта (RAI) на протяжении всего жизненного цикла продукта большой языковой модели (LLM).
Что такое красная команда?
Термин red teaming исторически описал систематические атаки состязательности для тестирования уязвимостей безопасности. С ростом LLM термин расширился за рамки традиционной кибербезопасности и развивался в общем использовании, чтобы описать множество видов проверки, тестирования и атаки систем искусственного интеллекта. При использовании LLM доброкачественное и состязательное использование может создавать потенциально вредные выходные данные, которые могут принимать множество форм, включая вредное содержимое, например речь ненависти, подстрекательство или славение насилия, или сексуального содержимого.
Почему RAI red teaming является важной практикой?
Красная команда — это рекомендация в ответственном разработке систем и функций с помощью LLM. Хотя и не замена систематической работы по измерению и устранению рисков, красные команды помогают выявить и определить вред, и, в свою очередь, позволяют стратегиям измерения проверить эффективность устранения рисков.
Хотя корпорация Майкрософт провела красные команды и реализовала системы безопасности (включая фильтры содержимого и другие стратегии устранения рисков) для своих моделей Azure OpenAI Service (см. этот обзор ответственных методик ИИ), контекст каждого приложения LLM будет уникальным, и вы также должны проводить красные команды в следующих случаях:
Проверьте базовую модель LLM и определите, существуют ли пробелы в существующих системах безопасности, учитывая контекст приложения.
Выявление и устранение недостатков в существующих фильтрах по умолчанию или стратегиях устранения рисков.
Предоставьте отзыв о сбоях, чтобы внести улучшения.
Обратите внимание, что красная команда не является заменой систематического измерения. Рекомендуется выполнить первоначальный раунд ручной командной команды перед проведением систематических измерений и реализацией мер. Как описано выше, цель красной команды RAI заключается в выявлении вреда, понимании поверхности риска и разработке списка вредов, которые могут информировать о том, что необходимо измерять и устранять.
Вот как можно приступить к работе и запланировать процесс красных командных LLM. Заранеее планирование крайне важно для продуктивного упражнения красной команды.
Перед тестированием
План: Кто будет выполнять тестирование
Собрать разнообразную группу красных команд
Определите идеальную композицию красных команд с точки зрения опыта людей, демографических данных и опыта в области дисциплин (например, экспертов ВИ, социальных наук, безопасности) для вашего продукта. Например, если вы разрабатываете чат-бот для помощи поставщикам медицинских услуг, медицинские эксперты могут помочь определить риски в этом домене.
Вербовка красных команд с доброкачественными и состязательности мышления
Наличие красных команд с состязательности и опытом тестирования безопасности является важным для понимания рисков безопасности, но красные команды, которые являются обычными пользователями вашей системы приложений и не были вовлечены в его разработку, могут привести ценные перспективы на вред, с которыми могут столкнуться обычные пользователи.
Назначьте красным командам вред и /или функции продукта
Назначьте красным командам RAI с определенным опытом для проверки конкретных типов вреда (например, эксперты по вопросам безопасности могут пробовать для тюрьмы, мета-запроса извлечения и содержимого, связанного с кибератаками).
Для нескольких раундов тестирования решите, следует ли переключать красные назначения команды в каждом раунде, чтобы получить разнообразные перспективы по каждому вреду и поддерживать творчество. Если переключение назначений, разрешите время красным командам, чтобы ускорить выполнение инструкций по их вновь назначенному вреду.
На последующих этапах, когда приложение и его пользовательский интерфейс разрабатываются, может потребоваться назначить красным командам определенные части приложения (т. е. функции), чтобы обеспечить охват всего приложения.
Рассмотрим, сколько времени и усилий каждый красный командер должен выделить (например, эти тесты для доброкачественных сценариев могут потребовать меньше времени, чем те, которые тестируются для состязательные сценарии).
Это может быть полезно для предоставления красных команд с:
- Четкие инструкции, которые могут включать:
- Введение, описывающее цель и цель данного раунда красной команды; продукт и функции, которые будут протестированы и как получить к ним доступ; какие виды проблем для тестирования; области фокусировки красных команд, если тестирование является более целевым; сколько времени и усилий каждый красный командер должен тратить на тестирование; запись результатов; и кто связаться с вопросами.
- Файл или расположение для записи их примеров и выводов, включая такие сведения, как:
- Дата, когда был показан пример; уникальный идентификатор пары входных и выходных данных, если он доступен, в целях воспроизводимости; входной запрос; описание или снимок экрана выходных данных.
План: что протестировать
Так как приложение разрабатывается с помощью базовой модели, может потребоваться протестировать на нескольких разных уровнях:
Базовая модель LLM с ее системой безопасности, чтобы определить все пробелы, которые могут быть устранены в контексте вашей системы приложений. (Тестирование обычно выполняется через конечную точку API.)
Приложение. (Тестирование лучше всего выполняется с помощью пользовательского интерфейса.)
Базовая модель LLM и приложение до и после устранения рисков выполняются.
Следующие рекомендации помогут вам выбрать, что тестировать в различных точках во время красной команды:
Вы можете начать с тестирования базовой модели, чтобы понять поверхность риска, определить вред и руководство по разработке мер по устранению рисков RAI для вашего продукта.
Тестируйте версии продукта итеративно без устранения рисков RAI, чтобы оценить эффективность устранения рисков RAI. (Обратите внимание, что красная команда вручную может быть недостаточной для оценки— используйте систематические измерения, но только после завершения первоначального раунда ручной красной команды.)
Проводите тестирование приложений в рабочем пользовательском интерфейсе как можно больше, так как это очень похоже на реальное использование.
При составлении отчетов убедитесь, какие конечные точки использовались для тестирования. Когда тестирование было выполнено в конечной точке, отличной от продукта, рассмотрите возможность повторного тестирования на рабочей конечной точке или пользовательском интерфейсе в будущих раундах.
План. Тестирование
Проводите открытое тестирование, чтобы выявить широкий спектр вреда.
Преимущество красных команд RAI исследует и документирует любое проблемное содержимое (а не просит их найти примеры конкретного вреда) позволяет им творчески изучить широкий спектр вопросов, обнаруживая слепые пятна в вашем понимании поверхности риска.
Создайте список причинений вреда от открытого тестирования.
- Рассмотрите возможность создания списка причинений вреда с определениями и примерами вреда.
- Предоставьте этот список в качестве руководства красным командам в последующих раундах тестирования.
Проведение управляемой красной команды и итерации: продолжайте пробы за вред в списке; определите новые повреждения этой поверхности.
Используйте список причинений вреда, если они доступны и продолжают тестировать на известные вреды и эффективность их устранения. В процессе вы, скорее всего, определите новые повреждения. Интегрируйте их в список и быть открытыми для изменения приоритетов измерения и устранения рисков для решения недавно выявленных вредов.
План, который вредит приоритету для итеративного тестирования. Некоторые факторы могут сообщить о приоритете, включая, но не ограничивается, серьезностью вреда и контекстом, в котором они, скорее всего, будут отображаться.
План. Запись данных
Определите, какие данные необходимо собирать и какие данные являются необязательными.
Определите, какие данные потребуется записать красным командам (например, входные данные, которые они использовали; выходные данные системы; уникальный идентификатор, если он доступен, чтобы воспроизвести пример в будущем; и другие заметки).)
Будьте стратегически с данными, которые вы собираете, чтобы избежать подавляющих красных команд, не пропуская критически важные сведения.
Создание структуры для сбора данных
Общая электронная таблица Excel часто является самым простым способом сбора данных красной команды. Преимущество этого общего файла заключается в том, что красные команды могут просматривать примеры друг друга, чтобы получить творческие идеи для собственного тестирования и избежать дублирования данных.
Во время тестирования
Планирование работы в активном режиме ожидания в то время как красная команда продолжается
- Будьте готовы помочь красным командам с инструкциями и проблемами доступа.
- Отслеживайте ход выполнения на электронной таблице и отправляйте своевременные напоминания красным командам.
После каждого раунда тестирования
Данные отчета
Поделитесь коротким отчетом по регулярному интервалу с ключевыми заинтересованными лицами, которые:
Выводит список наиболее выявленных проблем.
Предоставляет ссылку на необработанные данные.
Предварительный просмотр плана тестирования для предстоящих раундов.
Признает красных командистов.
Предоставляет любую другую соответствующую информацию.
Различие между идентификацией и измерением
В докладе обязательно уточняйте, что роль красной команды RAI заключается в том, чтобы предоставить и повысить понимание поверхности риска и не является заменой систематического измерения и строгой работы по устранению рисков. Важно, чтобы люди не интерпретировали конкретные примеры как метрики для распространенности этого вреда.
Кроме того, если отчет содержит проблемное содержимое и примеры, рассмотрите возможность включения предупреждения о содержимом.
Руководство, приведенное в этом документе, не предназначено и не должно рассматриваться как предоставление юридических консультаций. Юрисдикция, в которой вы работаете, может иметь различные нормативные или юридические требования, применимые к вашей системе ИИ. Имейте в виду, что не все эти рекомендации подходят для каждого сценария и, наоборот, эти рекомендации могут оказаться недостаточными для некоторых сценариев.