TL;DR
Когда просишь GPT или Claude оценить чужой ответ — он судит стиль и структуру, а не правильность. Модель выставляет высокие оценки красиво написанным, но неверным ответам и занижает тем, кто ответил правильно, но коротко и без объяснений. Это показало масштабное исследование с 206 тысячами пар «вопрос — модель» по шести бенчмаркам.
Главная проблема: судья-LLM и реальная точность расходятся на 10–24 процентных пункта. На медицинских вопросах — в обе стороны: крупные модели получают завышенные оценки за «экспертный стиль» даже когда дают неверный ответ. На общих вопросах — наоборот, заниженные за краткость. Модель путает «звучит как эксперт» с «отвечает правильно».
Три источника искажений: предвзятость судьи (оценивает подачу, не суть), обрезание ответа на длинных задачах (незаконченный ответ = плохой ответ) и несовпадение формата (правильный ответ, но не в той структуре). Вместе они раздувают долю «нерешаемых» задач с реальных ~17% до ~40%+. Исследователи предлагают двойную верификацию: LLM-судья + точное совпадение по эталону.
Схема метода
Протокол двойной верификации (dual-judge validation):
ШАГ 1: LLM-судья оценивает ответ → субъективная оценка 0/1/2
ШАГ 2: Точный критерий проверяет ответ → объективная метрика (да/нет)
ШАГ 3: Сравни два результата → расхождение = артефакт оценки, не ошибка модели
ШАГ 4: Если расходятся — доверяй точному критерию для фактических задач
Если задача субъективная — учитывай расхождение как погрешность
Шаги 1–2 можно делать в одном чате. Шаги 3–4 — ваш вывод вручную или через отдельный запрос.
Пример применения
Задача: Ты запускаешь продукт и просишь Claude сравнить два описания для лендинга. Первое — красивое, длинное, с метафорами. Второе — короткое, прямое, без воды. Хочешь понять реально какое лучше конвертирует.
Промпт:
Оцени два текста для лендинга. Оценивай только по одному критерию:
насколько ясно читателю ЧТО он получит и ЗАЧЕМ покупать.
Не оценивай стиль, красоту языка, структуру — только смысловую ясность.
После оценки каждого — ответь на конкретный вопрос:
"Если читатель прочитал только этот текст, он понимает что покупает?" (Да / Частично / Нет)
Текст 1: [вставь первый текст]
Текст 2: [вставь второй текст]
Сначала дай оценку каждого по критерию выше.
Затем скажи какой текст набрал больше по точному критерию (Да/Частично/Нет),
а не по общему впечатлению.
Результат: Модель выдаст две оценки — отдельно по стилю и отдельно по точному критерию ясности. Ты увидишь расхождение: красивый текст может проигрывать по «читатель понял что покупает». Это и есть dual-judge в действии: общее впечатление vs. конкретный проверяемый критерий.
Почему это работает
Слабость LLM: Модель обучалась предсказывать текст, который люди одобряют. Люди чаще одобряют развёрнутые, структурированные, «умно звучащие» ответы — даже когда они неверны. Модель выучила этот паттерн: хорошо написано = правильно. Когда её просят оценивать, она воспроизводит тот же паттерн.
Сила LLM: Она умеет следовать конкретным, измеримым критериям, если ты их сформулировал явно. Попроси оценить «точность последнего утверждения» вместо «качество ответа» — получишь другой результат, ближе к реальности.
Как это использовать: Разбей оценку на два слоя. Первый — общее суждение модели (субъективно, учитывает стиль). Второй — конкретный проверяемый критерий (фактически верно? задача решена? читатель понял?). Расхождение между ними — артефакт оценки, не истина. Для задач с правильным ответом доверяй конкретному критерию.
Рычаги управления: - Критерий — чем точнее формулируешь что проверять, тем меньше судья уходит в оценку стиля - Формат вывода — попроси отвечать Да/Нет/Частично, а не балл: снижает пространство для «красивой» нейтральной оценки - Контроль обрезания — если ответ модели оборван, не считай его плохим; дай больше пространства или попроси продолжить
Шаблон промпта
Оцени {объект_оценки} по точному критерию.
Критерий: {опиши один измеримый критерий}
Не учитывай: стиль, объём, структуру текста — только суть.
После оценки ответь на конкретный вопрос:
"{сформулируй вопрос с ответом Да/Нет/Частично}"
Шаг 1: Оценка по критерию
Шаг 2: Ответ на конкретный вопрос
Шаг 3: Если общая оценка и конкретный ответ расходятся — укажи это явно
{объект_оценки} — текст, ответ, решение, аргумент
{опиши один измеримый критерий} — «наличие конкретного вывода», «точность финального ответа», «решена ли поставленная задача»
{сформулируй вопрос с ответом Да/Нет/Частично} — «Читатель знает что купить после прочтения?», «Задача решена или только описана?»
🚀 Быстрый старт — вставь в чат:
Вот шаблон для честной оценки с двойной верификацией.
Адаптируй под мою задачу: [опиши что хочешь оценить].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит что именно оценивать и какой конкретный критерий важен — потому что без этого невозможно отделить оценку стиля от оценки сути. Она возьмёт структуру двойной проверки и адаптирует под твою задачу.
Ограничения
⚠️ Субъективные задачи: Для оценки «нравится/не нравится», «хорошо звучит/плохо» — метода нет. Dual-judge работает только там, где есть измеримый критерий правильности.
⚠️ Создание критерия — твоя работа: Если не можешь сформулировать точный критерий — судья-LLM вернётся к оценке стиля. Это не баг метода, это его условие.
⚠️ Обрезанные ответы: Если модель не успела дописать ответ из-за ограничений длины — не интерпретируй обрыв как ошибку. Сначала дай больше места, потом оценивай.
⚠️ Судья из той же семьи: Если ты просишь Claude оценить ответ Claude — он склонен предпочитать привычный ему стиль. Для важных задач проверяй двумя разными системами.
Как исследовали
Исследователи взяли 206 756 пар «вопрос — ответ модели»: четыре версии Gemma 4 (от крошечной 2B до большой 31B) отвечали на 51 689 вопросов из шести бенчмарков — общие знания, медицина, код, разговорные задачи. Все ответы оценила одна и та же LLM-модель по шкале 0–1–2.
Хитрость в том, что для двух бенчмарков (MMLU и MedQA) есть эталонные ответы — правильная буква A/B/C/D. Это позволило сравнить: что говорит судья-LLM и что говорит точное совпадение. Результаты разошлись на 10–24 процентных пункта — и в разные стороны в разных доменах. На общих вопросах судья систематически занижал крупные модели (они отвечали кратко и без лишних рассуждений). На медицинских — завышал, потому что большие модели писали «как настоящий врач», но давали неверный ответ.
Дополнительно выяснилось: 65% ответов в MMLU были просто обрезаны из-за жёсткого лимита токенов. Незаконченный ответ — плохая оценка. Это не ошибка модели, это ошибка настройки. Кросс-проверка на моделях Llama подтвердила паттерны — значит, это не особенность одной семьи моделей, а системное явление. Любопытно: Llama-3.1-70B на знаниевых задачах обошла Gemma-4-31B на 22 процентных пункта, но проиграла ей же на задачах программирования. Это значит, что «какая модель лучше» — вопрос без ответа без уточнения для чего.
Адаптации и экстраполяции
🔧 Адаптация: Оценка аргументов в переговорах
Когда готовишься к переговорам и хочешь проверить силу аргументов — LLM-судья по умолчанию оценит «убедительность» через стиль. Адаптируй под точный критерий:
Оцени каждый мой аргумент по единственному критерию:
"Этот аргумент закрывает конкретное возражение клиента или только звучит убедительно?"
Для каждого аргумента:
1. Какое возражение он закрывает (если закрывает)
2. Ответ: Закрывает / Частично / Не закрывает
3. Если "Частично" или "Не закрывает" — что именно не хватает
Аргументы: {список аргументов}
Возражения клиента: {список возражений}
🔧 Адаптация: Проверка фактических утверждений в тексте
Когда просишь проверить статью или пост на фактические ошибки — отдели «стиль» от «факт»:
Проверь утверждения в тексте.
Оценивай только фактическую точность каждого утверждения.
Не оценивай стиль, логику изложения, структуру.
Для каждого утверждения:
— Само утверждение (процитируй)
— Оценка: Верно / Спорно / Неверно
— Если Спорно или Неверно — объясни что не так
Текст: {текст}
Ресурсы
Название работы: Unsolvability Ceiling in Multi-LLM Routing: An Empirical Study of Evaluation Artifacts
Авторы: Saloni Garg (Independent Researcher, San Francisco), Amit Sagtani (San Francisco State University)
Связанные работы упомянутые в статье: - FrugalGPT (Chen et al., 2023) — каскадная маршрутизация между моделями - RouteLLM (Ong et al., 2025) — бинарные роутеры на основе человеческих предпочтений