TL;DR
RADAR — способ проверить рубрику (набор критериев оценки) до того, как ты начнёшь массово гонять через неё тексты. Суть простая: создаёшь тестовые примеры, которые специально "прокачивают" только один критерий, а остальные оставляешь нейтральными. Потом просишь LLM-оценщика оценить эти примеры по ВСЕМ критериям сразу. Если критерий, который ты не трогал, тоже подскочил — критерии "слиплись" в голове модели.
Главная находка: LLM-судья часто не различает формально разные критерии. Например, "краткость" и "по существу" — разные вещи на бумаге, но модель обычно видит их через одно общее чувство "гладкости текста". В итоге, когда ты просишь оценить текст по пяти критериям отдельно, реально работают два-три "скрытых измерения", а остальные — просто их эхо. Это незаметно раздувает итоговую оценку и искажает сравнение вариантов (например, какая версия бота лучше).
Метод работает в три шага: (1) генерируешь примеры, где один критерий явно завышен или занижен, остальные — не трогаешь; (2) просишь LLM оценить каждый пример по каждому критерию отдельным запросом; (3) сравниваешь — двинулись ли "нетронутые" критерии вместе с целевым. Если да — это утечка (leakage) между критериями.
Схема метода
ШАГ 1: Генерация тестовых проб — для каждого критерия создать текст,
который ЯВНО хорош/плох именно по нему, остальные критерии не трогать
→ набор текстов (по 2 на критерий: "высокий" и "низкий")
ШАГ 2: Оценка каждого текста по ВСЕМ критериям рубрики
отдельными запросами (не одним общим) → таблица оценок
ШАГ 3: Сравнение — если оценка "нетронутого" критерия сильно
изменилась вслед за целевым → это утечка/связь между критериями
→ матрица связей рубрики
Все три шага можно провести в обычном чате, без кода. Для полноценного анализа исследователи гоняли это через API и много моделей, но принцип работает и с одной моделью в одном диалоге.
Пример применения
Задача: HR-специалист хочет использовать ChatGPT как автоматического оценщика резюме — скорить сотни кандидатов по критериям "релевантный опыт", "коммуникативные навыки" и "мотивация", чтобы не читать всё вручную. Перед запуском массовой проверки хочет убедиться, что GPT не путает эти три критерия между собой.
Промпт (шаг 1 — генерация пробы):
Напиши короткое резюме кандидата на позицию менеджера по продажам.
Сделай его ЯРКО демонстрирующим высокую мотивацию к работе.
При этом опыт работы и коммуникативные навыки сделай нейтральными,
не старайся их специально улучшать или ухудшать.
Выдай только текст резюме, без пояснений.
(Повторить с "явно демонстрирующим НИЗКУЮ мотивацию" — и так для каждого из трёх критериев, в обе стороны — всего 6 проб)
Промпт (шаг 2 — оценка, отдельный запрос на каждый критерий):
Вот резюме кандидата:
{текст пробы}
Оцени его по критерию "коммуникативные навыки" от 0 до 4.
Дай оценку и одно предложение обоснования.
(Повторить для каждого критерия отдельно — не смешивать в один запрос)
Результат: Ты получишь таблицу из 6 проб × 3 критерия = 18 оценок. Сравнивая их, увидишь: если резюме, специально написанное с "высокой мотивацией", случайно получило и высокую оценку по "коммуникативным навыкам" — значит GPT в своей оценке путает эти два критерия. Это сигнал: перед массовым скорингом стоит либо переформулировать критерии яснее, либо учитывать, что баллы по ним будут дублировать друг друга.
Почему это работает
LLM-судья не оценивает критерии как независимые измерения — она читает текст через своё общее "чувство качества" и часто цепляет за него сразу несколько формально разных критериев. Поэтому простое сравнение оценок ("совпадают — значит связаны") ничего не доказывает: возможно, тексты просто похожи, а не критерии реально совпадают в голове модели.
Сильная сторона LLM — она отлично выполняет точечные инструкции типа "сделай текст явно плохим по X, но нейтральным по остальному". Это и есть управляемый эксперимент, а не пассивное наблюдение.
Метод использует эту силу для создания контролируемой "интервенции" — искусственно давит на один критерий и смотрит, что случится с другими. Если давление на один критерий двигает соседний — это не совпадение в данных, а реальная связь в том, как модель читает рубрику.
Рычаги управления: - Количество проб на критерий — исследование показало, что даже 3-5 проб дают ту же точность, что и 20. Для быстрой проверки в чате достаточно 2-3 пары. - Формулировка критерия в промпте — чем чётче разграничены определения, тем меньше утечки. Можно тестировать разные формулировки и сравнивать связность. - Направление проверки — можно проверять не только "высокий/низкий" по шкале качества, но и позиционные критерии (например, "длина текста": короткий/длинный).
Шаблон промпта
ШАГ 1 — Генерация пробы (повтори для каждого критерия, в обе стороны):
Напиши {тип_контента} на тему «{задача}».
Сделай его ЯВНО {сильным/слабым} по критерию «{критерий}»: {описание_критерия}.
Остальные критерии — {список_остальных_критериев} — оставь нейтральными,
не старайся их специально улучшить или ухудшить.
Выдай только текст, без пояснений.
ШАГ 2 — Оценка (отдельный запрос на каждый критерий для каждой пробы):
Вот текст: {текст_пробы}
Оцени его по критерию «{критерий}»: {описание_критерия}.
Поставь оценку от 0 до 4 и дай одно предложение обоснования.
ШАГ 3 — Сравнение:
Собери оценки всех проб по всем критериям в таблицу.
Для пробы, написанной под критерий А, посмотри — изменились ли
оценки по критериям Б, В в ту же сторону?
Если да — критерии А и Б связаны в восприятии модели-судьи.
Что подставлять: {тип_контента} — что оцениваешь (резюме, рекламный текст, ответ поддержки), {задача} — конкретная тема/ситуация, {критерий} и {описание_критерия} — из твоей рубрики, {список_остальных_критериев} — все остальные критерии рубрики через запятую.
🚀 Быстрый старт — вставь в чат:
Вот шаблон RADAR для проверки, не путает ли LLM-судья критерии оценки
между собой. Адаптируй под мою задачу: {опиши свою рубрику и что оцениваешь}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про твои критерии (их точные формулировки) и тип контента — потому что без чётких определений критериев невозможно сгенерировать пробу, которая точно бьёт по одному критерию и не задевает остальные.
Ограничения
⚠️ Трудоёмкость: метод требует много отдельных запросов — генерация проб + оценка каждой пробы по каждому критерию отдельно. При рубрике из 5+ критериев вручную в чате это долго; практично для 2-3 критериев или для разовой проверки перед масштабным запуском.
⚠️ Результат привязан к конкретной модели: связь критериев — это свойство пары "модель-генератор + модель-оценщик", а не самой рубрики. Смена модели требует повторной проверки.
⚠️ Диагностика, не решение: метод только показывает, что критерии связаны — но не говорит, плохо это или нормально. Может быть, это дублирование (плохо), а может — осознанная иерархия критериев (нормально). Решать нужно самому.
⚠️ Эталон для сравнения несовершенен: человеческие оценки, с которыми сверяли результат, тоже шумные — это ориентир, а не точная истина.
Как исследовали
Исследователи взяли три готовых набора данных с человеческой разметкой по нескольким критериям: HelpSteer2 (оценка ответов ассистента), SummEval (оценка новостных выжимок) и SumPubMed (медицинские рефераты). Для каждой рубрики генератор (GPT-5, Claude Opus/Sonnet) писал короткие тестовые тексты, специально сильные или слабые по одному критерию, а верификатор (другая модель) оценивал их по всем критериям рубрики отдельными запросами — так убрали эффект "модель видит все критерии сразу и подгоняет оценки друг под друга".
Полученную "карту связей" сравнили с реальными корреляциями в человеческих оценках — совпадение оказалось очень высоким (Пирсон от 0.84 до 0.96), в то время как простые альтернативы (просто коррелировать оценки без целевых проб, или готовый метод RRD) давали слабое или даже противоречивое совпадение — на одном из наборов данных корреляция вообще получилась отрицательной.
Самое удивительное: хватило 3-5 проб на критерий, чтобы добиться той же точности, что и на 20 — то есть метод дешёвый и не требует масштабной разметки данных. Вывод для практики: LLM-судья реально путает критерии из-за общего "чувства качества" текста (часто это просто гладкость слога), и это можно поймать заранее буквально несколькими тестовыми примерами — вместо того чтобы потратить бюджет на разметку тысяч ответов и обнаружить проблему постфактум.