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

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

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

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

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

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

2. 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, нужны бенчмарки с разным содержанием.

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

• популярность в сообществе (цитирования);

• специфика бенчмарка;

• языковая поддержка;

• разнообразие категорий вреда;

• применимость к реальным сценариям;

• качество и разнообразие источников данных.

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

1. Выделили кластеры: over-refusal, устойчивость к промпт-атакам, общая безопасность, sanity check, русскоязычные и мультиязычные бенчмарки.

2. В каждом кластере оставляли бенчмарки без пересечения по содержанию и специфике. WildGuard заменили на PolyGuard: он шире по языкам и лучше ложится на наш мультиязычный контур.

3. Для наглядности построили ориентированный граф зависимостей между бенчмарками и источниками данных (рис. 2). На графе убирали вершины, которые образуют сильно связные компоненты, чтобы снизить пересечение источников. Ссылка на исходник.

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

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

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

Для всех запусков мы фиксируем 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 () агрегирует базовые оценки (взвешенную сумму FPR и FNR) сплитов внутри одного бенчмарка:

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

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

Почему геометрическое среднее? Потому что оно жёстко наказывает за дисбаланс. Другими словами, если модель блестяще справляется с 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 моделей.

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

1. Не верить размеру. 2B может быть топ-2, а 4B из того же семейства — топ-19; 12B Llama-Guard-4 ниже 8B Llama-Guard-3. 

2. Не интегралом единым. Integral score награждает за отсутствие ошибок, а не стремление к идеальному результату. Halo поднимается выше Qwen в рейтинг

3. Обращайте внимание на и русские бенчмарки. Там прячутся самые неприятные сюрпризы топа.

4. Один ноль = конец. Высокий F1 при нулевой группе — ловушка

5. Скорость отдельно. Если низкая задержка имеет решающее значение, 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.

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