Red Teaming

Red teaming — это структурированное тестирование ИИ, часто с использованием атакующих сценариев, чтобы найти изъяны, уязвимости, нежелательное поведение и риски злоупотребления. В актуальной практике его проводят и до публичного релиза, и после него; при этом единого кросс-вендорного стандарта пока нет, поэтому процесс и критерии зависят от организации и конкретного случая.

Английский термин: red teaming. В документации также встречаются формулировки AI red teaming и LLM red teaming.

Простыми словами

Грубо говоря, red teaming можно представить как специально организованную попытку «сломать» систему до того, как это сделают реальные пользователи или злоумышленники. Не в смысле взлома инфраструктуры вообще, а в смысле проверки: можно ли заставить модель отвечать опасно, обходить правила, выдавать нежелательный результат или поддаваться злоупотреблению.

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

Как это работает

По официальным источникам, red teaming начинается не с набора «хитрых промптов», а с постановки рамки: что именно вы тестируете, кто входит в команду, какой уровень доступа допустим и в каком формате будут зафиксированы результаты. OpenAI отдельно подчёркивает важность заранее определённых scope, состава red team, уровней доступа и формата финального отчёта, а Microsoft рекомендует сначала решить, тестируется ли базовая модель, приложение или оба слоя.

Цель и область теста
        ↓
Что проверяем: базовую модель / приложение / оба слоя
        ↓
Состав команды и уровень доступа
        ↓
Открытое тестирование
        ↓
Направленные проверки по гипотезам риска
        ↓
Логирование находок
        ↓
Отчёт по раунду
        ↓
Перепроверка через production UI/endpoint
        ↓
Систематические измерения и решения по рискам

1. Определяется область теста. До начала кампании фиксируют цели, границы, доступ и формат отчёта.
2. Собирается команда. NIST и Microsoft рекомендуют разнообразный состав red team, потому что разные участники находят разные классы проблем.
3. Проводится открытое тестирование. Microsoft советует начинать со свободного исследования, чтобы увидеть неожиданные режимы поведения.
4. Добавляются направленные сценарии. После первого раунда тестирование становится более управляемым: проверяются конкретные риски, политики и уязвимости.
5. Все находки записываются. Microsoft рекомендует фиксировать результаты и оформлять отчёт после каждого раунда.
6. Находки перепроверяются. Red teaming не заменяет систематические измерения: Microsoft прямо пишет, что выводы нужно подтверждать повторным тестом через production UI или endpoint и отдельными измерениями.
7. Результаты анализируются до управленческих решений. NIST отдельно отмечает, что итоги red teaming нужно анализировать до того, как использовать их в governance или risk-management решениях.

Практически это значит, что red teaming — не разовая атака на модель, а цикл: нашли проблему, задокументировали, проверили повторяемость, исправили, протестировали заново.

Где применяется

• До публичного релиза модели или приложения. NIST прямо допускает red teaming до выпуска, чтобы заранее выявить нежелательное поведение и риски злоупотребления.
• После релиза. Те же источники указывают, что red teaming применяют и постфактум; Microsoft рекомендует перепроверять выводы именно на production UI или endpoint, а не только в лабораторной среде.
• Во время обучения и оценки модели. Публикации OpenAI по GPT-Red описывают автоматизированный внутренний red teaming во время обучения модели для поиска уязвимостей и adversarial training, с акцентом на устойчивость к prompt injection.
• В специальных форматах проверки. Anthropic описывает policy vulnerability testing, model-assisted red teaming, multimodal red teaming и community red teaming как актуальные практики.

Отдельно полезно понимать, что результаты red teaming могут идти дальше самого теста. OpenAI пишет, что такие результаты можно использовать в оценке рисков и как вход для автоматизированных оценок.

Практический пример

Если вам нужен минимальный рабочий старт без выдуманных интерфейсов, самый безопасный пример из исходников — проверить установку и базовую доступность PyRIT, который в репозитории Microsoft описан как фреймворк для автоматизированного и human-led AI red teaming.

pip install pyrit
python -c 'import pyrit; print(pyrit.__version__)'
pyrit_scan --help

Что это даёт на практике:

1. Вы устанавливаете инструмент из официального репозитория.
2. Проверяете, что пакет импортируется и отвечает номером версии.
3. Смотрите доступный scanner workflow через pyrit_scan --help.

Дальше начинается уже не «магия инструмента», а собственно red teaming: вы задаёте область теста, список рисков, выбираете уровень доступа и подключаете целевую систему по актуальной документации репозитория. Здесь важно ограничение: в открытом пакете источников нет универсального, одинакового для всех провайдеров конфига, а стоимость и доступность зависят от внешних сервисов, если вы их подключаете.

Если вам нужен не только глоссарий, а прикладной сценарий, посмотрите материал Как провести red teaming для вашей модели.

Чем отличается от…

Ограничения и заблуждения

• Заблуждение: red teaming нужен только до релиза. NIST прямо пишет, что его можно проводить и до, и после публичного выпуска.
• Заблуждение: если red team ничего не нашла, система безопасна. В источниках нет единого межвендорного pass/fail-стандарта; объём находок зависит от области теста, состава команды и уровня доступа.
• Заблуждение: red teaming заменяет измерения. Microsoft отдельно подчёркивает обратное: это дополнительный контур, а не замена систематических оценок.
• Ограничение: качество результата зависит от постановки кампании. Если плохо заданы scope, доступ и формат отчёта, то часть проблем просто не попадёт в результаты.
• Ограничение: процедуры сильно зависят от контекста. Подходы OpenAI, Microsoft и Anthropic полезны как образцы, но не образуют единого универсального протокола для всех моделей и приложений.
• Ограничение: сложность меняется вместе с моделями. В работе Anthropic 2022 года опубликован набор из 38,961 red-team атак, а авторы сообщили, что по мере роста масштаба RLHF-модели становились труднее для red teaming.

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

Редакционное ограничение: в открытых источниках из этого пакета нет единого общепринятого протокола red teaming с общими порогами прохождения. Если вам нужен формальный процесс для продакшна, придётся дополнительно определить собственные критерии, scope и способ верификации.

Связанные материалы

• В жизненном цикле модели red teaming часто идёт после этапов Pre-training (предобучение) и Fine-tuning (дообучение).
• Для прикладных интерфейсов полезно отдельно понимать, как меняется поведение модели при Prompt tuning (мягком промпте).
• Пошаговую прикладную процедуру смотрите в материале Как провести red teaming для вашей модели.

Источники

• Planning red teaming for large language models (LLMs) and their applications – Microsoft Foundry | Microsoft Learn
• Microsoft AI Red Team | Microsoft Learn
• Releases · microsoft/PyRIT · GitHub
• GPT‑Red: Automated Red Teaming via Self-Play at Scale

• red teaming – Glossary | CSRC
• NIST Trustworthy and Responsible AI
• Planning red teaming for large language models (LLMs) and their applications – Microsoft Foundry | Microsoft Learn
• GitHub – microsoft/PyRIT
• OpenAI’s Approach to External Red Teaming for AI Models and Systems
• GPT‑Red: Unlocking Self-Improvement for Robustness
• Challenges in Red Teaming AI Systems | Anthropic
• Red Teaming Language Models to Reduce Harms: Methods, Scaling Behaviors, and Lessons Learned

Вопросы и ответы

Нужно ли делать red teaming только до релиза?

Нет. NIST указывает, что red teaming можно проводить как до публичного выпуска, так и после него.

Что именно тестировать: базовую модель или приложение?

Это нужно определить заранее. Microsoft рекомендует отдельно решить, тестируется ли базовая модель, приложение или оба слоя.

Заменяет ли red teaming автоматические оценки и систематические измерения?

Нет. Microsoft прямо пишет, что red teaming не является заменой systematic measurement и что выводы нужно подтверждать повторной проверкой production UI или endpoint и отдельными измерениями.

Можно ли автоматизировать red teaming?

Да, частично. PyRIT описан как фреймворк для автоматизированного и human-led red teaming, а OpenAI публиковала работу GPT-Red про автоматизированный внутренний red teaming во время обучения модели.

Нужна ли обязательно внешняя команда?

Не обязательно. OpenAI описывает внешний формат как полезную практику с заранее заданными scope, доступом и отчётностью, но в источниках есть и внутренний, и model-assisted, и community-подходы. Универсально обязательной формы нет.