Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Очередь тревог монитора безопасности научились сортировать так, чтобы проверяющие раньше находили безопасные действия, ошибочно помеченные как опасные. Метод Xichen Yan и коллег нашёл на 33,3% больше ложных тревог, чем сильнейший из проверенных аналогов, при бюджете проверки 5%, хотя работа пока не рецензирована и все числа получили сами авторы. Для команды это означает, что сократить ручной аудит можно без переобучения монитора и без меток безопасности для самих тревог.
Почему безопасные примеры плохо описывают ложные тревоги
Монитор анализирует траекторию агента — историю его действий, ответов среды и обращений к инструментам. Консервативный монитор старается не пропустить опасное поведение, поэтому вместе с настоящими нарушениями останавливает часть безопасных операций.
Порог по исходной оценке риска проблему не решает. Безопасные и опасные траектории перемешаны в очереди: одинаковая оценка монитора может соответствовать и реальной угрозе, и ложной тревоге. Чтобы подобрать новый порог, всё равно приходится вручную проверять значительную часть очереди.
При этом у команды часто уже есть небольшой набор подтверждённых безопасных траекторий, которые не вызвали тревогу. Авторы предлагают считать их положительными примерами, а все тревоги — неразмеченной смесью. Такая постановка называется обучением по положительным и неразмеченным примерам: алгоритм ищет внутри смеси объекты, похожие на известный целевой класс.
Здесь возникает смещение выборки. Известные безопасные примеры прошли фильтр монитора, а нужные аудитору ложные тревоги тот же фильтр отверг. Если напрямую обучить обычный алгоритм на этих данных, он рискует повторить границу монитора вместо того, чтобы найти его ошибки.
Как безопасные траектории переносят к границе тревог
На первом этапе отдельный классификатор учится отличать безопасные примеры от тревог. Его граница описывает не безопасность, а решение монитора: пропустить траекторию или поднять тревогу. Представления безопасных примеров сдвигают к этой границе, причём величина сдвига зависит от того, насколько надёжен такой перенос.
Алгоритм также ослабляет давление на тревоги, которые похожи на потенциальные ложные срабатывания. Он не объявляет их безопасными, а лишь перестаёт использовать каждую тревогу как полноценный отрицательный пример. Это важно: иначе обучение систематически отталкивало бы вниз именно те элементы, которые нужно поднять в очереди проверки.
Несколько независимо обученных вариантов дают разные очереди. Метод собирает их позиции, берёт устойчивый общий порядок и переносит его в одну итоговую модель. Если исходные варианты расходятся или перенос безопасных примеров выглядит ненадёжным, специальный коэффициент уменьшает влияние такого согласования.
После обучения модель больше не меняют. Очередь дополнительно уточняют по структуре данных: учитывают близость тревог друг к другу и поддержку со стороны безопасных примеров на разных уровнях группировки. В рабочей системе остаётся одна модель, а исходный монитор продолжает принимать прежние решения.
Меняет ли метод планы внедрения
На основной выборке было 510 тревог. Качество ранжирования по площади под кривой точности и полноты достигло 0,6444 против 0,5917 у PULDA. Эта метрика показывает, насколько плотно ложные тревоги сосредоточены в начале очереди при разных объёмах ручной проверки.
Направление результата сохранилось на внешней выборке из 4054 тревог. Метод также обошёл повторную проверку каждой траектории через Qwen2.5-7B-Instruct. Последовательное отключение частей системы показало, что вклад дают и перенос безопасных примеров, и объединение очередей, и структурное уточнение.
Эксперименты использовали по 40 подтверждённых безопасных траекторий для каждого сочетания датасета и монитора. Для обучения также нужны сохранённые представления монитора, признаки задачи и сведения о группах траекторий. Поэтому метод подходит не как универсальная надстройка над любым API, а как часть контура, где команда контролирует журнал действий агента и промежуточные признаки.
Работа меняет планы команд, у которых уже накопилась очередь тревог, но разметка каждой из них слишком дорога. Вместо проекта по замене монитора можно добавить отдельный ранжировщик и направлять проверяющих к наиболее вероятным ошибкам. Это особенно полезно, если безопасные примеры доступны из штатных запусков или обучающих данных.
Поднимать элемент в очереди не значит автоматически признавать его безопасным. Метод только задаёт приоритет ручной проверки, не снимает тревогу и не меняет решение основного монитора. Такое разделение позволяет сначала проверить экономию времени на исторических журналах, а затем подключить ранжирование к рабочему процессу без ослабления действующих блокировок.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
