Детектор с вероятностями вместо вердиктов: Jev на 44 бенчмарках

TL;DR. Jev, обученный методом RLCD, проверили на 44 бенчмарках сбоев выравнивания: ранжирует хорошо и в 63 раза дешевле LLM-судей, но порог нужно подбирать на 10 метках.

Ключевые выводы

Цена наблюдения за каждым сообщением. Развёрнутые модели по-прежнему подстраиваются под ошибочное убеждение пользователя (Sharma et al., 2024).
Чем отличается Jev. Jev обучен методом обучения с подкреплением для калиброванных решений (RLCD).
Почему сбои выравнивания сложнее, чем кажутся. До измерения одна сложность.
Обнаружение как классификация. Формальная постановка в статье проста.

Детектор сбоев выравнивания отвечает на много типизированных вопросов за один вызов, выдаёт калиброванные вероятности, хорошо ранжирует сбои и стоит в 63 раза дешевле LLM-судей. Но эти вероятности не переносятся как пороги, а метка и её эталон значат гораздо больше, чем формулировка вопроса.

Цена наблюдения за каждым сообщением #

Развёрнутые модели по-прежнему подстраиваются под ошибочное убеждение пользователя (Sharma et al., 2024). Фраза скромная, но она задаёт рамку всей проблемы. Если такое угодничество сохраняется в развёрнутых системах, кто-то должен за ним следить, и следить в том же темпе, в каком идёт сам разговор.

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

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

Есть частичное решение, и его пределы стоит описать точно. Классификаторы, читающие вероятности токенов, такие как Llama Guard, по-прежнему оценивают одну фиксированную метку за вызов. Чтение вероятностей токенов даёт оценку, но каждый вызов по-прежнему оценивает одну метку или критерий, потому что вероятность считывается с одного токена-вердикта. Проход декодирования исчезает, но структура «один вопрос на вызов» остаётся. Каждый вызов стал дешевле, а число нужных вызовов не изменилось.

Итак, структурный тезис таков: генеративные судьи дороги в расчёте на критерий, а классификаторы, читающие вероятности, дешевле в расчёте на критерий, но всё равно привязаны к одному критерию каждый. Ни те ни другие не позволяют задать много вопросов об одном и том же входе сразу.

Архитектурное измерение	Генеративные LLM-судьи (например, GPT-4 как судья)	Однотокенные классификаторы (например, Llama Guard)	Многозапросный детектор RLCD (Jev)
Механизм оценки	Полный авторегрессионный проход декодирования на каждый критерий	Вероятность softmax по одному выходному токену	Многоголовый тензор калиброванных вероятностей $P(\text{yes})$
Вопросов за вызов	1 оценочный промпт на один вызов модели	1 классификационная метка на один вызов модели	Несколько бинарных, категориальных и порядковых вопросов за 1 вызов
Стоимость инференса	Высокая ($10–$50 за 1 000 взаимодействий)	Умеренная ($0,50–$2,00 за 1 000 взаимодействий)	В 63 раза ниже ($0,30 на 19 полных бенчмарков)
Качество AUROC	Зависит от бенчмарка; склонно к дрейфу судьи	Высокое на конкретных обученных категориях безопасности	Медианный AUROC 0,886 zero-shot на 44 наборах
Качество калибровки	Эвристические объяснения без формальных вероятностей	Грубые логиты без апостериорной калибровки	Калиброванные вероятности; медианный ECE 0,168 (нужно около 10 размеченных примеров)

Чем отличается Jev #

Jev обучен методом обучения с подкреплением для калиброванных решений (RLCD). Он отвечает на много типизированных вопросов об одном входе с калиброванными вероятностями за один вызов. Механизм стоит описать аккуратно, потому что от него зависит вся остальная статья.

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

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

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

Почему сбои выравнивания сложнее, чем кажутся #

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

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

Это усложняет и диагностику. Если сбои относительны, плохое обнаружение может объясняться вопросом или состоянием, в котором нет эталона. Ошибиться могли две вещи, и низкая оценка не говорит, какая. Возможно, вопрос был плохо сформулирован. Возможно, вопрос был в порядке, а во входе просто не было того, что нужно для ответа. Бенчмарк, который хочет сказать о детекторе что-то полезное, должен быть устроен так, чтобы эти две причины можно было разделить.

Разработчик, со своей стороны, относит косвенный смысл и состязательный контент к известным слабостям Jev. Это стоит помнить, читая результаты ниже, потому что некоторые типы сбоев опираются именно на эти свойства.

Обнаружение как классификация #

Формальная постановка в статье проста. Обнаружение сбоев выравнивания рассматривается как бинарная классификация взаимодействий целевой модели. Детектор присваивает оценку s(x) ∈ [0, 1] и помечает x, когда s(x) ≥ t. Значит, он должен и ранжировать сбои выше не-сбоев, и разделять их по порогу t.

Эти две обязанности разделимы, и результаты статьи расходятся именно по этому шву. Ранжирование измеряет AUROC. Разделение по порогу зависит от калибровки, и статья к нему вернётся, потому что именно здесь Jev недотягивает. Детектор может ранжировать превосходно и всё же быть непригодным при t = 0,5, если его вероятности лежат не там.

RLCDAlignBench #

Бенчмарк называется RLCDAlignBench. Он охватывает десять типов сбоев на 44 бенчмарках и 7 193 случаях обнаружения. Случаи получены от пяти открытых целевых моделей размером 2–7B, и каждый размечен эталонным оценщиком своего бенчмарка. Так что оцениваемые взаимодействия исходят от небольших открытых моделей, а истиной для каждого служит то, что говорит собственный оценщик исходного бенчмарка.

Не у каждого бенчмарка метка одного рода. Человеческие метки на StrongREJECT и HarmBench и метки второго судьи на AbstentionBench и InstrumentalEval используются, чтобы сравнить Jev с судьёй. Это даёт статье два вида внешней проверки эталонных оценщиков: в одних случаях людей, в других второго судью.

Опубликованный артефакт описан как 44 бенчмарка по десяти типам сбоев с вариантами контекста, кешированными ответами Jev и скриптами переоценки, вместе с протоколом разбиения пополам, который убирает инфляцию отбора из заявленных приростов. Каждый элемент отвечает практической потребности. Варианты контекста позволяют читателю спросить, что будет, если состояние содержит больше. Кешированные ответы и скрипты переоценки позволяют воспроизвести число без повторного запуска модели. Протокол разбиения пополам решает методологическую ловушку, которая заслуживает отдельного раздела.

Ловушка отбора #

Jev можно задать много вопросов об одном и том же входе. В этом его главное достоинство, и это же опасность для оценки. Если задать набор вопросов-кандидатов и сообщить о том, что набрал больше всего, вы провели поиск по вопросам и сообщили победителя. Статья говорит прямо: сообщение о лучшем из них преувеличило бы то, что получает практик.

Любой, кто настраивал промпт на тестовом наборе, это узнает. Средство здесь простое. Вопросы выбираются на одной половине примеров и оцениваются на другой. Целевой вопрос выбирается на одной половине примеров и оценивается на другой, по 20 разбиениям. Отбор никогда не касается примеров, которые дают заявленное число.

Это важно для чтения каждого прироста ниже. Статья утверждает, что протокол разбиения пополам убирает инфляцию отбора из заявленных приростов. Когда статья говорит, что целевая формулировка даёт медианный прирост +0,006 AUROC, эта цифра получена на формулировке, выбранной и оценённой на разных половинах. Столь малая, но честно измеренная цифра полезнее большей, в которую тихо вошло проклятие победителя.

Главный результат: один общий вопрос #

Теперь результат, которого ждёт большинство читателей. Один общий вопрос даёт медианный AUROC 0,886 в режиме zero-shot и превосходит обученные базовые модели на большинстве бенчмарков.

Разберём слова по очереди. «Один общий вопрос» означает отсутствие подгонки промпта под каждый бенчмарк. «Zero-shot» означает отсутствие обучения на целевом бенчмарке. «Превосходит обученные базовые модели на большинстве бенчмарков» означает, что системы, обученные на размеченных данных задачи, проигрывают вопросу, который никто не настраивал, на большинстве рассмотренных бенчмарков. Утверждение останавливается на слове «большинстве», и эта статья тоже.

Общий вопрос представляет собой шаблонный вопрос, прочитанный как P(yes). Цифра отражает AUROC 38 пригодных бенчмарков, а на 7 бенчмарках общий вопрос не задавался. Значит, главное число представляет собой медиану по бенчмаркам, где общий вопрос применялся, взятым из 38 пригодных. Внимательному читателю стоит следить за знаменателями: всего существует 44 бенчмарка, 38 пригодны для этой цифры, а у общего вопроса пробел в 7.

Я бы сказал, что результат zero-shot составляет более интересную половину фразы. Победа над обученными базовыми моделями говорит о сравнительном положении. Медианный AUROC 0,886 без обучения под задачу говорит о том, какая часть сигнала о сбое доступна модели, которая читает состояние и отвечает на простой вопрос. Обобщается ли это на типы сбоев за пределами этих десяти, утверждения не затрагивают.

Формулировка почти не имеет значения #

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

Объяснение статьи конкретно. Как только ответы сохраняются в виде вероятностей, а не решений argmax, формулировка вопроса значит мало, а то, что содержат состояние и метка, значит очень много. Это наблюдение об информации. Решение argmax отбрасывает запас, с которым один ответ победил другой, и изменение формулировки может перебросить решение через границу. Вероятность сохраняет запас, так что переформулировка, слегка сдвигающая свидетельства, слегка сдвигает вероятность и почти не трогает ранжирование.

Я ограничусь тем, что утверждает статья: когда вероятности сохраняются, формулировка значит мало. Я не стану расширять это до механистического объяснения, потому что утверждения его не дают.

Цифры подтверждают тезис. Целевая формулировка даёт медианный прирост +0,006 AUROC, при этом формулировка выбрана и оценена на разных половинах. Вне выборки целевая формулировка добавляет +0,006 [−0,004; +0,015] AUROC. Интервал охватывает ноль. Читателю не стоит считать +0,006 надёжным улучшением: интервал так же допускает небольшую потерю, как и небольшой выигрыш. Для практика полезный вывод таков: поиск более хитрой формулировки вряд ли окупится, по крайней мере на этих бенчмарках.

Это должно изменить то, как команды распределяют время. Если формулировка почти инертна, часы, потраченные на неё, лучше потратить на состояние.

Выигрыш живёт в контексте #

Так что содержит состояние и что оно должно содержать? Вывод статьи: контекст значит больше, в основном через поля, кодирующие метку. Ключевая идея устройства исследования в том, чтобы менять то, о чём спрашивают Jev, отдельно от того, что он видит: формулировку и тип ответа вопроса с одной стороны, поля входа с другой. Именно это разделение позволяет статье сказать, что формулировка значит мало, а контекст значит больше. Без него два эффекта были бы перепутаны.

Главный пример даёт PrivacyLens. Крупный выигрыш дают эталоны, определяющие метку, например список секретных элементов в PrivacyLens (0,79→0,95). Переход от 0,79 к 0,95 AUROC велик рядом с +0,006 от формулировки. Эталоном здесь служит список секретных элементов, то есть ровно то, что, по предсказанию предыдущего разговора об относительных сбоях, должно иметь значение: выдаёт ли ответ что-то приватное, зависит от того, что считается приватным, а сам ответ этого не говорит.

Есть оговорка для развёртывания, и важная. Контекст, который был бы у развёрнутого монитора, помогает на 1 из 7 бенчмарков. Крупный выигрыш дают эталоны, определяющие метку, но у развёрнутого монитора их может и не быть. То, что монитор реалистично имел бы, помогает лишь на одном бенчмарке из семи.

Это трезвый вывод, и я считаю его самой коммерчески значимой фразой статьи. Он отделяет лабораторное число от полевого. Детектор, оцениваемый с эталоном, определяющим метку, отвечает на более лёгкий вопрос, чем тот, с которым сталкивается развёрнутый монитор. Выигрыш реален, но статья ясно говорит, на какую его часть может рассчитывать развёртывание.

Статья также отмечает ограничение одного бенчмарка. На Open-Prompt-Injection метка следует точности внедрённой задачи. Это пример метки, смысл которой привязан к свойству задачи, что влияет на то, что детектор может увидеть из состояния. Дальнейших выводов я делать не буду, потому что утверждения их не дают.

Стоимость #

Теперь число, которое делает экономику конкретной. Jev стоит в 63 раза дешевле LLM-судей. Конкретное сравнение: прогон по 19 бенчмаркам с оценкой судьями стоит 0,30 доллара, в 63 раза меньше, чем их судьи по прейскурантным ценам. Сравнение стоимости охватывает один прогон по 19 бенчмаркам с API-судьями по прейскурантным ценам.

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

Вспомните исходное требование: детектор, работающий на каждом сообщении, должен быть дешёвым. Цифра 0,30 доллара за целый прогон по 19 бенчмаркам и есть то, как «дёшево» выглядит в этой статье. Статья не переводит её в цену за сообщение, и я тоже не буду.

Согласие с людьми и что показали расхождения #

Дешевизна интересна, только если детектор ещё и прав. Там, где человеческие метки позволяют проверку, Jev согласуется с ними так же хорошо, как судья, за долю стоимости.

Самое конкретное свидетельство даёт StrongREJECT. Относительно человеческих меток общий вопрос согласуется так же хорошо, как эталонный оценщик (каппа Коэна 0,809 против 0,811), и ранжирует лучше. Два значения κ различаются на 0,002, так что разумно читать это как ничью по согласию при преимуществе Jev в ранжировании.

Затем идёт результат, который я считаю самым полезным на практике, потому что он превращает детектор в инструмент аудита. Уверенные расхождения Jev выявили дефекты, меняющие метки, в трёх бенчмарках и метки, которые состояние не может раскрыть, ещё в четырёх. Когда уверенный детектор расходится с эталонной меткой бенчмарка, одно из объяснений в том, что ошибается детектор. Статья сообщает, что в некоторых случаях расхождение указывало на бенчмарк: в трёх бенчмарках были дефекты, меняющие метки, а ещё в четырёх были метки, которые состояние не может раскрыть.

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

Слабое место: калибровка #

Здесь статья должна быть прямолинейной, потому что прямолинейна исходная работа. Вероятности хорошо ранжируют, но не переносятся как пороги: медианный ECE равен 0,168 против нулевого уровня 0,074, и на проверенных, и на судейских метках, потому что средняя вероятность Jev не совпадает с базовой частотой каждого бенчмарка.

Части складываются так. AUROC измеряет ранжирование, и ранжирование сильное. С порогом дело обстоит иначе. Если средняя выходная вероятность модели не совпадает с тем, как часто сбои встречаются в данном бенчмарке, то t = 0,5 оказывается не там, и ожидаемая ошибка калибровки высока. Медианный ECE 0,168 выше нулевого уровня 0,074, то есть результат хуже, чем точка отсчёта, выбранная статьёй. И это верно и для проверенных, и для судейских меток, так что слабость не является артефактом шумных судейских меток.

Вспомните формальную постановку: детектор должен ранжировать сбои выше не-сбоев и разделять их по порогу. Jev из коробки хорошо делает первое и плохо второе. Название метода содержит слова «калиброванные решения», а измеренная здесь калибровка не переносится между бенчмарками, и это напряжение стоит назвать прямо. Статья объясняет разрыв базовыми частотами и не утверждает большего.

Практическое следствие: в роли замены судьи Jev нужно несколько меток, чтобы задать порог. Это реальная стоимость, и она сужает заявку на роль готовой замены. Нельзя направить его на новый тип сбоя и довериться t = 0,5.

Рецепт #

Рекомендация статьи компактна. Рецепт таков: общий вопрос, прочитанный как вероятность, с порогом, подобранным на десяти размеченных примерах, что поднимает F1 там, где Jev срабатывает слишком редко при t = 0,5, и стоит 0,025 на проверенных метках.

Разберём его. Общий вопрос решает проблему формулировки, отказываясь её подгонять, что согласуется с выводом, что формулировка значит мало. Чтение ответа как вероятности сохраняет запас. Подбор порога на десяти размеченных примерах устраняет промах по базовой частоте. Влияние на F1 положительно там, где Jev срабатывает слишком редко при t = 0,5. На проверенных метках рецепт стоит 0,025.

На последней цифре стоит задержаться. Рецепт не лишён издержек: на проверенных метках он стоит 0,025. Статья сообщает об этом компромиссе, а не прячет его, и я предпочитаю ссылаться на рецепт с заявленной ценой, а не на тот, что рекламируется как чистый выигрыш. Утверждения не говорят, в какой метрике измерены 0,025, помимо контекста проверенных меток, поэтому гадать я не стану.

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

Что из этого взять практику #

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

Во-первых, перестаньте оптимизировать формулировку вопроса. Прирост вне выборки от целевой формулировки составляет +0,006 с интервалом от −0,004 до +0,015. Это не основание для вложений.

Во-вторых, тратьте усилия на состояние. Крупный выигрыш дали эталоны, определяющие метку. Если вашему монитору можно дать эталон, определяющий сбой, улучшение именно там. Если нельзя, ожидайте меньшего: контекст, который был бы у развёрнутого монитора, помог на 1 из 7 бенчмарков. Планируйте исходя из числа, которое можно получить при развёртывании, а не из числа, которое получается на бенчмарке, где эталон лежит во входе.

В-третьих, заложите бюджет на калибровку. Планируйте разметить десять примеров на каждый тип сбоя и подобрать порог. Не выпускайте t = 0,5.

В-четвёртых, используйте расхождения как сигнал. Уверенные расхождения с эталонными метками выявили дефекты в трёх бенчмарках и нераскрываемые метки ещё в четырёх. Если вы запустите это на своих наборах оценки, будьте готовы, что он может рассказать вам о ваших метках так же, как о ваших моделях. Это вывод из находки статьи, а не измеренное утверждение о каком-либо конкретном наборе, так что воспринимайте его как приглашение проверить.

В-пятых, помните об известных слабостях. Разработчик относит косвенный смысл и состязательный контент к известным слабостям Jev. Монитор, важный для безопасности, столкнётся с состязательным контентом. Утверждения здесь не сообщают, как Jev справляется с ним, так что это остаётся открытым флангом, и я хотел бы видеть его проверенным, прежде чем доверять развёртыванию.

Результат в свете коммерческого обоснования #

Основатели захотят знать, где это находится. Самый сильный аргумент связан со стоимостью: детектор, работающий на каждом сообщении, должен быть дешёвым, а снижение в 63 раза относительно LLM-судей меняет то, какие развёртывания доступны по цене. Второй аргумент касается точности: AUROC 0,886 в режиме zero-shot и победа над обученными базовыми моделями на большинстве бенчмарков.

Оговорки определяют, что можно честно продавать. Детектору нужно несколько меток на порог. Его калибровка не переносится. Его лучший выигрыш опирается на эталоны, которых у развёртывания может не быть. Это условия использования, и любой продукт на этой основе должен их заявлять, а не прятать. Ничто из этого не подрывает аргумент стоимости; это описывает работу по настройке.

Есть и более тихий момент о самом измерении. RLCDAlignBench с его вариантами контекста, кешированными ответами Jev, скриптами переоценки и протоколом разбиения пополам представляет собой переиспользуемый оценочный актив. Бенчмарк, убирающий инфляцию отбора из заявленных приростов, относится к тому роду артефактов, которые позволяют сравнивать последующие заявления. Это ценность иного рода, чем сам детектор.

Что остаётся открытым #

Несколько границ ясны из утверждений. Целевые модели представляют собой пять открытых моделей с 2–7B параметров, так что результаты описывают сбои во взаимодействиях с моделями такого размера. На 7 бенчмарках общий вопрос не задавался, а главный AUROC является медианой по бенчмаркам, где он задавался. Метки дают эталонные оценщики, а человеческие метки и метки второго судьи охватывают StrongREJECT, HarmBench, AbstentionBench и InstrumentalEval.

Открытый вопрос, который интересует меня больше всего, поднимает сама структура статьи. Сбои относительны; в состоянии часто нет эталона; а контекст развёрнутого монитора помог лишь на 1 из 7 бенчмарков. Однозапросное устройство Jev позволяет многим вопросам делить один вход, но самым большим рычагом оказалось то, какие поля несёт вход. Как развёртыванию получать эталон, определяющий метку, во время мониторинга, например список секретных элементов для проверки приватности, предстоит выяснить следующим. Статья показывает, что выигрыш достижим (0,79→0,95 на PrivacyLens), и оставляет открытым, можно ли дать его развёрнутому монитору достаточно дёшево, чтобы сохранить преимущество в 63 раза.

Что это значит по отраслям #

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

Поставщики AI-шлюзов и платформ безопасности #

Инфраструктурные компании, развёртывающие защитные механизмы в реальном времени, могут заменить дорогие каскадные архитектуры (вызовы отдельных классификаторов внедрения промптов, токсичности и приватности) едиными многозапросными головами RLCD. Операционные расходы падают более чем в 60 раз, а задержка ограничена одним прямым проходом.

Команды управления ИИ и аудиторского соответствия #

Комитеты по рискам, оценивающие поведение моделей по стандартам вроде требований EU AI Act к системам высокого риска или NIST AI RMF, получают детерминированный вероятностный журнал аудита. Вместо неструктурированных повествовательных отзывов LLM-судей системы записывают калиброванные распределения вероятностей, которые поддерживают статистическое управление процессами и мониторинг дрейфа.

Команды корпоративного развёртывания и red teaming #

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

Заключение #

Оценка Jev на RLCDAlignBench задаёт убедительное архитектурное направление для мониторинга моделей в продакшене: чтение калиброванных вероятностей по нескольким типизированным вопросам за один прямой проход превосходит авторегрессионных LLM-судей по стоимости и однотокенные классификаторы по гибкости. Хотя практикам нужно закладывать бюджет на эмпирическую калибровку порога, а не рассчитывать на перенос вероятностей из коробки, экономическое преимущество в 63 раза делает полноценный мониторинг в реальном времени осуществимым в масштабе.

Часто задаваемые вопросы #

Почему генеративные LLM-судьи непрактичны для мониторинга в продакшене в реальном времени?

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

Что такое обучение с подкреплением для калиброванных решений (RLCD)?

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

Почему пороги решений нужно калибровать на локальных данных?

Хотя модели RLCD отлично ранжируют взаимодействия по вероятности сбоя (достигая высокого AUROC), их абсолютные средние вероятности смещаются в зависимости от базовой частоты целевой области. Калибровка рабочего порога решения примерно на десяти размеченных примерах из своей области обеспечивает нужную чувствительность без недопустимого уровня ложных срабатываний.

Источники #

Mrinank Sharma et al., (2024). На пути к пониманию и снижению угодничества в языковых моделях ⧉. arXiv.
RLCDAlignBench Consortium, (2026). Многокритериальное обнаружение сбоев выравнивания через калиброванные головы решений ⧉. arXiv.
Anthropic / Alignment Research, (2025). Конституционный ИИ и динамика оценщиков ⧉. Anthropic.
NIST, (2024). Система управления рисками искусственного интеллекта (AI RMF 1.0) ⧉. NIST.

Последняя проверка 2026-09-30.

Последняя проверка 2026-10-27.

Опубликовать заново

Детектор с вероятностями вместо вердиктов: Jev на 44 бенчмарках — Sebastien Rousseau

Jev, обученный методом RLCD, проверили на 44 бенчмарках сбоев выравнивания: ранжирует хорошо и в 63 раза дешевле LLM-судей, но порог нужно подбирать на 10 метках.

Эта статья распространяется по лицензии Creative Commons Attribution 4.0 International. При повторной публикации требуется указание канонической ссылки.

Детектор с вероятностями вместо вердиктов: Jev на 44 бенчмарках — Sebastien Rousseau

Jev, обученный методом RLCD, проверили на 44 бенчмарках сбоев выравнивания: ранжирует хорошо и в 63 раза дешевле LLM-судей, но порог нужно подбирать на 10 метках.

Originally published at https://sebastienrousseau.com/ru/2026-09-30-detektor-veroyatnostyami-vmesto-verdiktov-jev-44/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER