Детектор з імовірностями замість вердиктів: 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. Перевидання вимагає посилання на канонічну URL-адресу.

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

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

Originally published at https://sebastienrousseau.com/uk/2026-09-30-detektor-imovirnostyamy-zamist-verdyktiv-jev-44/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER