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

Статья
2025-03-27

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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