GuardRate: архитектура, метрики и инсайты из аудита моделей защиты ИИ

Архитектура GuardRate: как устроен процесс тестирования

Первый этап аудита позволил нам сопоставить результаты 37 guardrail-моделей ИИ и увидеть общую картину. Однако для полного понимания эффективности защиты нейросетей необходимо разобрать внутреннее устройство тестирующего комплекса GuardRate Tool и системы ранжирования GuardRate Leaderboard. Я подробно опишу принципы построения конвейера оценки, логику отбора бенчмарков, математический аппарат метрик и результаты проведенных тестов.

Проект реализован по концепции Evaluation-as-Code — это единая воспроизводимая система тестирования, основанная на трех фундаментальных принципах:

• Полная изоляция среды. Каждая модель проверяется в строгих изолированных условиях. Для этого запускается отдельный Docker-контейнер со специализированным окружением и сервером vLLM. Использование сторонних облачных API полностью исключено, так как их поведение и веса могут меняться прямо во время аудита.
• CLI-автоматизация. Запуск всего цикла испытаний выполняется одной консольной командой. Базовая конфигурация описывается в YAML-файле, а параметры командной строки позволяют при необходимости переопределять конкретные значения:

python -m cli run \
  --config qwen_config.yaml \
  --model "Qwen/Qwen3Guard-Gen-0.6B" \
  --benchmarks "AEGIS,StrongReject_PlusPlus,HarmBench" \
  --device "cuda:0" \
  --artifacts-dir ./runs

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

• Широкий спектр угроз. В финальный тестовый контур вошли 19 бенчмарков, охватывающих прямые атаки (HarmBench, MultiJail), сценарии избыточной блокировки (XSTest, OverRefusalBenchmark), а также мультиязычные и русскоязычные датасеты.

Конвейер обработки данных (Pipeline)

Процесс тестирования состоит из нескольких последовательных шагов:

1. Запуск модели. Оркестратор разворачивает backend (vLLM или Docker-контейнер). Образ собирается под требования конкретной модели и проходит проверку готовности (readiness check).
2. Подготовка датасетов. Все метки исходных данных привозятся к унифицированному виду (safe/harm). Добавление нового бенчмарка требует лишь описания конфигурации.
3. Инференс. Модуль CLI отправляет запросы через API-эндпоинт /chat/completions (совместимый со стандартом OpenAI) и собирает предсказания.
4. Парсинг ответов. Сырой текстовый вывод модели приводится к стандартным бинарным меткам (harm/safe). В случае если парсер получает нерелевантный или нераспознаваемый ответ, кейс помечается как ошибочный, и ему принудительно назначается инвертированная эталонная метка.
5. Расчет метрик. Результаты сравниваются с разметкой, после чего вычисляются F1, FNR, FPR, precision, recall и accuracy.
6. Агрегация и сナップшоты. Данные со всех прогонов упаковываются в единый снимок (snapshot) и сохраняются в директорию артефактов.
7. Публикация и отображение. Команда cli publish отправляет результаты в хранилище на Hugging Face, откуда их считывает публичный веб-интерфейс.

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

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

python -m cli publish \
  --config publisher_service/config.yaml \
  --runs-dir ./runs \
  --run-filter "run_20260219_120000_abc12def"

Конфигурационный файл модели для запуска выглядит следующим образом:

name: "qwen_guard_run"
inference:
  mode: vllm
  vllm:
    base_url: "http://localhost:8000"
    openai_model: "Qwen3Guard-Gen"
    temperature: 0.0
    max_tokens: 256
parser_config:
  parser_class: "regex_parser.RegexParser"
  fields:
    safety_label: "Safety: (Safe|Unsafe|Controversial)"
model:
  name: "Qwen/Qwen3Guard-Gen-0.6B"
  device: "cuda:0"
  base_image: "pytorch/pytorch:2.10.0-cuda13.0-cudnn9-runtime"
artifacts_dir: "./runs"

Методология формирования набора бенчмарков

Для корректного вычисления финального рейтинга требовалось подобрать датасеты с минимальной взаимной корреляцией.

Этап 1: Индивидуальный отбор бенчмарков

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

Этап 2: Кластерный анализ и исключение дублей

Все датасеты были разделены по ключевым направлениям: ложные срабатывания (over-refusal), устойчивость к джейлбрейкам и промпт-атакам, базовая безопасность, базовые проверки (sanity check), а также региональные (русскоязычные) и мультиязычные тесты. В рамках каждого кластера мы оставляли только те наборы, которые не дублировали друг друга по смысловому наполнению. В частности, бенчмарк WildGuard был заменен на PolyGuard, так как последний лучше покрывает мультиязычные сценарии.

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

Параметры экспериментального стенда

Все тесты проводились на ускорителях NVIDIA A100 с 80 ГБ видеопамяти. Мы сравнили две инфраструктурные конфигурации для проведения аудита:

Во всех экспериментах жестко фиксировался random seed, генерация выполнялась при batch_size=1, а максимальная длина контекста max_length бралась из конфигурации модели (по умолчанию 512 токенов). Задержка (latency) замерялась как среднее время ответа на запрос в рамках полного прогона по всем 19 бенчмаркам.

Система метрик и математические «слепые зоны»

Классические метрики вроде F1-score или Accuracy слабо подходят для задач guardrail-фильтрации. Мы сфокусировались на показателях ложных срабатываний (FPR) и пропусков опасного контента (FNR). Общий интегральный скор выстраивается по трехуровневой схеме:

1. Dataset Score ($S_{dataset}$): рассчитывается для каждого сплита внутри бенчмарка на основе взвешенной суммы FPR и FNR. Это гарантирует баланс: модель не должна быть ни гиперопекающей, ни беспечной.
2. Group Score ($S_{group}$): агрегирует оценки сплитов до уровня бенчмарка с помощью гармонического среднего.
3. Integral Score ($S_{integral}$): итоговая метрика ранжирования, вычисляемая как геометрическое среднее по всем 19 группам.

Использование геометрического среднего обусловлено тем, что оно строго наказует за дисбаланс. Если модель идеально отражает джейлбрейки, но проваливает распознавание токсичности, ее общий интегральный рейтинг резко падает.

Анализ слепой зоны метрик

Математический анализ показал наличие слепой зоны у гармонического и геометрического средних. Если четыре группы имеют высокие оценки, а одна — умеренно низкую (на уровне $0.5$), штраф оказывается незначительным. К примеру, при значении выброса $0.50$ Group Score составляет $0.7820$, а Integral Score — $0.8022$. Просадка на $-0.0202$ скрывает тот факт, что на одном из датасетов модель угадывает безопасный контент лишь в половине случаев. Чтобы скомпенсировать этот эффект, в лидерборде дополнительно публикуется минимальная оценка по датасетам (min_group).

Инсайты и разбор аномалий лидерборда

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

Sing-Guard: 2B на втором месте, 4B — на девятнадцатом

Я подробно разобрал семейство Sing-Guard. Казалось бы, 4B-версия должна превосходить 2B. Однако Sing-Guard 2B заняла 2-е место, а 4B упала на 19-ю позицию. Когда я сравнил оценки всех 19 групп, то выяснил: модель 4B обошла младшую версию только в датасете OR-Bench (+0.25) и незначительно в BeaverTails. Во всех остальных группах она продемонстрировала ощутимый провал:

• SimpleSafetyTests: с 0.99 упал до 0.53
• MultiJail: с 0.88 упал до 0.56
• CSRT: с 0.70 упал до 0.41
• XSafety: с 0.52 упал до 0.26

Поскольку геометрическое среднее чувствительно к каждому провалу, один высокий результат на OR-Bench не смог компенсировать пять средних падений. Кроме того, у Sing-Guard 4B показатель FNR оказался выше (0.31 против 0.17 у 2B), то есть она чаще пропускала вредоносные запросы.

Аномалия HaloGuard и поведение Qwen-8B

У моделей HaloGuard наблюдается противоположная динамика: версия 4B (#6 место, скор 0.727) оказалась лучше 0.8B (#12 место, скор 0.708). При этом HaloGuard-4B показала наивысшую стабильность: значение min_group составило 0.509, то есть у нее нет ни одного серьезного провала.

Показательный момент: по метрике F1 модель Halo-4B набирает всего 0.74 (что соответствует 14-му месту при обычной сортировке). Но в лидерборде GuardRate она находится на 6-й строчке благодаря отсутствию слабых мест. Модель Qwen-8B, наоборот, имеет рекордный F1 во всем лидерборде (0.834), но из-за просадки в одной из групп (худшая оценка — 0.108) занимает лишь 7-е место.

Слепота лидера YuFeng на русскоязычном контенте

Победитель общего рейтинга — YuFeng-XGuard-Reason-8B — показал катастрофически низкий результат на русскоязычных токсичных ответах: датасет RTP-LX (RU, response) дал оценку всего 0.051. У Qwen-8B этот показатель еще ниже — 0.031. Только у моделей HaloGuard этот результат составил приемлемые 0.53.

Внутри группы гармоническое среднее превращает такую локальную ошибку в провал: при оценке русскоязычных запросов на уровне ~0.87 низкий показатель ответов (0.05) обрушивает Group Score до 0.16, что критически бьет по интегральному баллу.

Работа гармонического среднего на датасетах OR-Bench

На примере Sing-Guard-2B отлично видно влияние гармоники. В сплите OR-Bench (toxic) модель набрала ~0.99, а в OR-Bench (hard 1k) — всего 0.25. Простая средняя арифметическая дала бы 0.62, однако гармонический Group Score равен всего 0.39. Математика жестко наказывает модель за наименьший результат.

Версия и размер не гарантируют качество: пример Llama-Guard

Модель Llama-Guard-4-12B (#20, скор 0.631) уступила предшественнице Llama-Guard-3-8B (#17, скор 0.663). Аналогичная ситуация зафиксирована у ShieldGemma: версия 9B оказалась ниже версии 2B из-за просадок в Aya Red Teaming, RTP-LX и HarmBench. Увеличение числа параметров не гарантирует ровного прохождения тестов безопасности.

Скорость против точности: HiveTrace 0.6B

Для боевого применения задержка ответа критична. Модель HiveTraceGuard-Pro 0.6B заняла 3-е место с интегральным скором 0.743 при задержке p95 всего ~29 мс. Компактная YuFeng-0.6B расположилась на 9-м месте при задержке 25 мс. В то же время Halo-4B (6-е место) отрабатывает за ~393 мс, а Nemotron-Guard-8B — за ~398 мс. Для большинства продакшен-систем легкая модель с задержкой 29 мс будет предпочтительнее тяжелого аналога, работающего в 13 раз медленнее.

Ловушка узкой специализации

Наличие нулевой оценки в любой из 19 групп обнуляет шансы на высокое место. У классификатора gliner-guard-uniencoder метрика F1 достигает 0.73, но Integral Score составляет лишь 0.26 из-за нулевого значения в XSafety. Модель Octavio prompt-injection-detection продемонстрировала Integral Score = 0, так как полностью провалила распознавание safe-примеров (FNR=0, FPR=1). Геометрическое среднее моментально выявляет узкоспециализированные или деградировавшие классификаторы.

Сравнительный профиль топа моделей

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

• HaloGuard-4B: сильна в RTP-LX, но уязвима к prompt injection.
• Qwen-8B: отличные результаты в CSRT и SimpleSafety, но недееспособна на RTP-LX.
• YuFeng-8B: лидирует в OR-Bench, но проседает на русскоязычных текстах.
• Sing-Guard 2B: сбалансирована по большинству проверок, за исключением OR-Bench.

Итоги и дальнейшие шаги проекта

Проведенный аудит позволяет сделать главные практические выводы: не следует слепо доверять числу параметров ИИ-модели; высокий F1 не гарантирует стабильности; при выборе решения важно проверять узкопрофильные и локализованные датасеты; скорость инференса должна оцениваться наравне с метриками защиты.

Публичный веб-интерфейс GuardRate доступен на платформе Hugging Face Space, где можно самостоятельно изучить профиль каждой из 37 моделей. Разработчики open-source решений могут прислать ссылку на репозиторий и Dockerfile для включения своей модели в тестовый прогон.

В четвертом квартале 2026 года планируется открытие исходного кода CLI-инструментария и запуск API для регрессионного тестирования моделей защиты ИИ. Подать заявку на аудит модели можно по адресу: guardratetools@gmail.com.

Источник: habr.com