GuardRate: метрики, бенчмарки и инсайты из первого аудита (часть 2)

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

Теперь пришло время заглянуть во внутреннюю кухню: в этой статье мы подробно разберем устройство GuardRate Tool и GuardRate Leaderboard, ответим на вопрос, почему выбрали именно такие бенчмарки и метрики, опишем методологию и расскажем о том, как проводились эксперименты.

Архитектура: как устроен прогон

Система собрана как единый конвейер оценки (Evaluation-as-Code). Три ключевых концепта:

Изоляция. Все модели тестируются в одинаковых условиях: Docker-среда под конкретную модель и VLLM. Мы не используем облачные API, которые могут менять поведение в процессе работы.
CLI-автоматизация. Весь процесс стартует одной командой. Конфиг задается в YAML, а CLI-флаги лишь переопределяют отдельные поля:

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

Инструмент сам подтягивает датасеты, загружает модели, получает предсказания от модели и записывает сырые логи с метриками. Человеческий фактор практически исключён, оценка качества становится воспроизводимой.

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

Pipeline данных

Запуск модели. Оркестратор поднимает backend (vLLM или Docker). Docker-образ собирается с учётом требований модели и проходит readiness check.
Подготовка данных. Метки приводятся к виду safe/harm. Новый датасет можно добавить, задав конфигурацию.
Инференс. CLI отправляет запросы через OpenAI-совместимый API /chat/completions и получает предсказания модели.
Парсинг. Сырые ответы модели преобразуются в стандартные метки harm/safe. Если парсер получает на вход неожиданный формат, пример помечается как ошибочный. При подсчёте метрик такие примеры учитываются как ошибки (назначается противоположная ground-truth метка).
Оценка. Сырые ответы сравниваются с эталоном, рассчитываются метрики: F1, FNR, FPR, precision, recall, accuracy.
Агрегация. Результаты нескольких прогонов собираются в snapshot (data prepare → snapshot) и сохраняются в artifacts dir.
Публикация. Команда cli publish загружает артефакты в bucket на Hugging Face.
Frontend. Клиентская часть подтягивает свежие данные из bucket — пользователь видит обновлённые результаты.

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

Публикация в лидерборд отдельной командой:

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  # или docker    
    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"

Как выбирали коллекцию бенчмарков

Чтобы оценки меньше коррелировали при подсчёте Integral Score, нужны бенчмарки с разным содержанием.

Первый этап: независимая оценка каждого бенчмарка

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

Второй этап: совместный анализ набора

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

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

Установка для эксперимента

Все запуски выполнялись на GPU NVIDIA A100 (80 GB VRAM).

Среда	GPU	vCPU	RAM	Disk	Стоимость/час	Стоимость 1 аудита (19 бенчмарков)
Docker backend (VPS)	Tesla A100 (80GB)	16	64 GB	160 GB	$2.3/час (210 ₽/час)	~840–1 050 ₽ (~$9–11.5)
vLLM RunPod (Cloud Bursting)	NVIDIA A100 (80GB)	16	117 GB	160 GB	$1.49/час (117₽/час)	~468–585 ₽ (~$5.2–10.4)

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

Метрики: формулы и слепые зоны

В первой части мы объяснили, почему F1 и Accuracy плохо работают для guardrail-моделей, и остановились на FPR и FNR. Ниже описано, как из них формируется Integral Score.

Многие бенчмарки делятся на сплиты не случайно: каждый проверяет свою специфику. Склеивать их в один набор для общей оценки нецелесообразно, поэтому мы используем другой подход. Наша формула оценки основывается на балансе: мы стремимся к тому, чтобы модель не была излишне осторожной, но и не проявляла халатности. Сначала мы считаем оценку по каждому сплиту (Dataset Score, ) на основе FPR и FNR (показателей ложных срабатываний и пропусков атак), затем агрегируем их до уровня бенчмарка (Group Score, ) и в конце, агрегируя скоры по группам, получаем ранжирующий показатель (Integral Score).

Три формулы снизу вверх:

Dataset Score ( $s_{ds}$ ) агрегирует базовые оценки (взвешенную сумму FPR и FNR) сплитов внутри одного бенчмарка:

$s_{ds} = \frac{2 \cdot (1 - FPR) \cdot (1 - FNR)}{(1 - FPR) + (1 - FNR)}$

Group Score ( $s_{group}$ ) поднимает оценки сплитов до уровня бенчмарка (гармоническое среднее):

$s_{group} = \frac{N}{\sum_{i=0}^{N} \frac{1}{s_{ds_i}}}$

Integral Score ( $s_{integral}$ ): итоговая метрика ранжирования (геометрическое среднее):

$s_{integral} = \left( \prod_{j=0}^{M} s_{group_j} \right)^{\frac{1}{M}}$

Почему геометрическое среднее? Потому что оно жёстко наказывает за дисбаланс. Другими словами, если модель блестяще справляется с jailbreak, но полностью игнорирует токсичность, её общий скор резко упадет. Геометрическое среднее не прощает локальных провалов.

Почему одного Integral Score недостаточно

Мы рассмотрели допустимую область значений метрик и обнаружили «слепую зону».

Коротко: четыре высокие оценки и один выброс (низкое качество):

Group Score измеряет качество по группе датасетов внутри бенчмарка. Гармоническое среднее штрафует за слабые звенья: один плохой датасет может обрушить всю группу.

Однако существует слепая зона: при outlier ≥ 0.5 штраф невелик. Например, при outlier = 0.50 Group Score = 0.7820, Integral = 0.8022 (см. график дельты). Разница составляет −0.0202: обе метрики выглядят приемлемо, хотя = 0.50 означает, что модель права лишь в половине случаев баланса FPR/FNR.

В остальном Group Score вместе с Integral Score хорошо работает на сильных выбросах. Поэтому мы дополнительно публикуем минимальную оценку по датасетам: так проще увидеть самые слабые места модели.

Разбор этого этапа доступен в ноутбуке: metrics_guide.ipynb

Почему у модели такой integral score?

Как работает система оценки (это важно для понимания следующих моментов):

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

Из-за такой методологии оценки рейтинг иногда может вводить в заблуждение. Хотя модель может быть большой, иметь высокий F1 и почти идеальные результаты на половине бенчмарков, её итоговый ранг может быть 15–20-м.

Мы подготовили ещё один ноутбук, который поможет вам понять, почему конкретная модель занимает такой ранг в рейтинге. Кроме того, поможет подсветить слабые стороны выбранной модели и провести сравнительный анализ двух моделей. Ноутбук доступен по ссылке: leaderboard_analysis.ipynb.

Наши инсайты (на момент 14.08.2026):

Главный трюк восприятия: Sing-Guard 2B и 4B Sing-Guard 2B на 2-м месте, 4B — на 19-м

Тот случай, когда маленькая модель оказывается гораздо выше большой в рейтинге, и нагляднее всего это видно на Sing-Guard, где версия 2B занимает 2-е место, а 4B падает на 19-е, хотя интуитивно кажется, что должно быть наоборот, но когда я сравнила все 19 group scores + вклад каждой группы в разрыв log(integral), то обнаружила, что 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 просто не может вытянуть пять средних просадок, да ещё и FNR у 4B выше (0.31 против 0.17 у 2B), то есть она чаще пропускает небезопасный контент, и размер сам по себе тут абсолютно ничего не гарантирует.

А вот HaloGuard — наоборот (и это тоже странно)

А вот с HaloGuard ситуация прямо противоположная и тоже довольно странная, потому что здесь работает правило «больше параметров примерно равно лучше», но отрыв между моделями крошечный, При этом 4B — самая ровная модель в топе: min_group = 0.509, ни одной группы ниже 0.5. У Qwen-8B при почти том же integral худшая группа - 0.108 и если смотреть на HaloGuard1-Gen-0.8B (12 место, скор 0.708) и HaloGuard1-Gen-4B (6 место, скор 0.727), то 4B версия оказывается самой ровной моделью в топе с min_group = 0.509, ни одной группы ниже 0.5, тогда как у Qwen-8B при почти том же integral худшая группа - 0.108.

Примечательно то, что Halo-4B по F1 имеет всего 0.74 (это было бы примерно 14 место при сортировке по F1), но в рейтинге она 6-ая исключительно потому, что integral судит по отсутствию «дыр», а Qwen-8B — наоборот, лучший F1 во всём лидерборде (0.834), но лишь 7 место, что лишний раз доказывает: integral score награждает стабильность, а не пиковую производительность.

Слепота чемпиона YuFeng на русских токсичных ответах

Чемпион рейтинга (YuFeng-XGuard-Reason-8B) показывает себя намного хуже на русских токсичных ответах, его dataset score на RTP-LX (RU, response) равен всего 0.051, а у Qwen-8B ещё хуже — 0.031, и только у обоих HaloGuard показатель равен 0.53.

Причём внутри группы гармоническое среднее превращает эту историю в настоящую трагедию, request-и у YuFeng ~0.87, а response RU 0.05 тянет ~76% веса гармонического среднего, обрушивая group до 0.16 — и это уже бьёт по общему integral.

Рейтинг награждает «среднее по всем мирам», и модель может быть лучшей почти везде, но всё равно иметь катастрофическую дыру ровно там, где пользователю больно, а если бы у Qwen RTP-LX подняли с 0.11 до уровня Halo (0.67), её integral прыгнул бы примерно до 0.80, и она легко обогнала бы текущего лидера, что подтверждает: одна группа решает всё.

Гармоника внутри группы на примере Sing-2B и OR-Bench

Чтобы наглядно доказать вам, как работает гармоническое среднее, заглянем внутрь датасетов OR-Bench у Sing-Guard-2B. OR-Bench (toxic) показывает примерно 0.99, а OR-Bench (hard 1k) — всего 0.25, и если бы мы считали обычную арифметику, то получили бы около 0.62, но group score равен всего 0.39.

Гармоническое среднее специально и жёстко штрафует минимум, из-за чего «почти идеал на одном датасете» практически не выражается в значении group score.

Забавно, что именно в этом конкретном месте 4B Sing-Guard сильнее 2B, но всё равно проигрывает рейтинг, потому что, повторюсь, integral не прощает слабых мест.

Когда новее и больше не значит лучше на примере Llama-Guard

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

Это важно помнить, чтобы не попасть в ловушку больше параметров — лучше, когда глаз автоматически ставит 12B выше 8B только из-за названия версии и размера, хотя рейтинг говорит об обратном, и это идёт в ту же копилку заблуждений, что и история с Sing-Guard.

HiveTrace 0.6B в топ-3 — и ещё быстрый

Для продакшена скорость часто важнее места в таблице, и HiveTraceGuard-Pro на 0.6B — тому подтверждение, ведь он занимает 3-е место, integral 0.743, latency p95 ≈ 29 мс. Рядом YuFeng-0.6B: 9-е место и 25 мс. А Halo-4B при 6-м месте тормозит ~393 мс, Nemotron-Guard-8B — ~398 мс. Модель на 3-м месте с p95 ≈ 29 мс для продакшена часто представляет больший интерес, чем модель на 6-м месте с p95 ≈ 393 мс.

Как один ноль убивает весь рейтинг даже при нормальном F1

Достаточно одного нуля в любой группе критически снижает integral score: у gliner-guard-uniencoder F1 составляет 0.73 (выше, чем у Halo-0.8B), но integral равен всего 0.26 из-за XSafety = 0 при среднем по группам ~0.67, а Octavio prompt-injection-detection на датасетах показывает, где почти всё unsafe, score = 1.0; где есть safe-примеры — score = 0 (FNR=0, FPR=1), Integral = 0. При этом F1 ещё выглядит как «ну, 0.58, середнячок». Классификатор скатывается до тривиального и это хорошо замечает геометрическое среднее, а F1 этот эффект не отражает, поэтому модели специализирующиеся на чём-то конкретном оказываются в нижней части рейтинга.

Профили топа — таблица прячет специализацию

Я сравнила YuFeng #1, Sing-2B #2, HiveTrace #3, Halo-4B #6, Qwen-8B #7 по ключевым группам.

Что бросается в глаза:

Halo показывает себя хорошо на RTP-LX, но проседает в prompt injection;
Qwen хорошо справился с CSRT и почти идеален на SimpleSafety, но мёртв на RTP-LX;
YuFeng доминирует в OR-Bench, но тоже тонет в RTP-LX;
Sing-2B ровнее, чем многие «большие» модели, но OR-Bench — его слабое место.

Для контекста оставляю картинку топ-15 моделей.

Вывод по таблице рейтинга

Не верить размеру. 2B может быть топ-2, а 4B из того же семейства — топ-19; 12B Llama-Guard-4 ниже 8B Llama-Guard-3.
Не интегралом единым. Integral score награждает за отсутствие ошибок, а не стремление к идеальному результату. Halo поднимается выше Qwen в рейтинг
Обращайте внимание на и русские бенчмарки. Там прячутся самые неприятные сюрпризы топа.
Один ноль = конец. Высокий F1 при нулевой группе — ловушка
Скорость отдельно. Если низкая задержка имеет решающее значение, HiveTrace и YuFeng-0.6B являются альтернативными вариантами.

Рейтинг считает «не у кого f1 больше», а «кто меньше провалился хоть где-то» — и именно поэтому она такая цепкая и прозорливая.

Что дальше

Заходите на публичный HF Space: смотрите результаты оценок, сравнивайте модели, выбирайте под свой кейс.

Если у вас есть open-source guardrail, пришлите HF-ссылку и Dockerfile или особые требования к парсеру: поставим на прогон, и модель появится на публичном Space.

Что касается GuardRate, то в Q4 2026 года мы планируем открыть исходники CLI и запустить API для регрессионного тестирования. Наша цель — сделать процесс оценки guardrail более прозрачным и воспроизводимым, чтобы каждый мог самостоятельно оценить результаты.

Присылайте свою модель на проверку: guardratetools@gmail.com

Автор статьи и создатель этого лидерборда — Софья Балаба из HiveTrace & AI Security Lab.

Я хотел бы поблагодарить Антона Малыхина, Сабрину Садиех и Никиту Облакова за их помощь в создании этого замечательного инструмента.