Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Оценщик LLM может уверенно вернуть вероятность для разрешённых ответов, хотя модель в этой точке собирается отвечать на другой вопрос. В препринте Stanford University и University of Maryland, который не прошёл рецензирование и где числа получены самими авторами, заготовка начала ответа подняла средний AUC с 0,493 до 0,615. Командам стоит проверять позицию чтения и полный набор вероятностей до того, как менять модель или метрику.
Как фиксированные варианты скрывают неверный ответ
В эксперименте модель прогнозирует, ответит ли другой читатель на вопрос по тексту. В запрос вставлены сам вопрос, варианты A–D и инструкция выбрать букву, а ниже стоит другая инструкция: оценить число читателей, которые ответят правильно, и выбрать один из заданных числовых вариантов.
Оценка по фиксированным вариантам читает вероятности следующего токена только для разрешённых чисел. Затем она пересчитывает их доли так, чтобы сумма стала единицей. Вероятность всех остальных продолжений исчезает из результата, даже если модель почти наверняка собирается вывести букву.
На Qwen3-4B буква ответа оказалась наиболее вероятным следующим токеном в 118 из 120 строк. Свободное продолжение подтверждало причину: модель сначала отвечала на вложенный вопрос, а уже затем переходила к прогнозу. Оценщик при этом снимал показания с первой позиции и выдавал корректно оформленное число.
Такой прогноз почти не различал правильные и неправильные ответы читателя. AUC — площадь под ROC-кривой; она показывает, насколько часто оценка ставит положительный пример выше отрицательного. Результат находился на уровне случайного ранжирования, хотя внутри разрешённого набора распределение выглядело полноценным.
Как проверить, что оценщик читает нужную позицию
Первый тест — посмотреть не только разрешённые ответы, но и самый вероятный токен без ограничений. Ещё надёжнее сгенерировать короткое свободное продолжение: оно показывает, какую инструкцию модель фактически выполняет первой.
Второй тест — посчитать массу вариантов: сложить вероятности первых токенов всех разрешённых ответов в реальном контексте. Низкая масса означает, что оценщик строит распределение по продолжениям, которые модель почти не рассматривает. Высокая масса сама по себе не доказывает качество прогноза, поэтому связь с целевым результатом всё равно нужно измерять отдельно.
Варианты следует кодировать после полностью отрисованного запроса, включая шаблон чата. Если кодировать их отдельно, можно потерять пробел или получить общий первый токен у нескольких ответов. Тогда оценщик либо читает другую позицию, либо вообще не может различить варианты по первому токену.
Удаление инструкции выбрать A–D убрало буквенный старт у Qwen3 и тем самым связало сбой именно со вложенной командой. Практическим исправлением стала заготовка начала ответа в сообщении модели: она заранее переводила генерацию к прогнозу. После такой вставки медианная масса разрешённых вариантов превысила половину на всех девяти проверенных версиях моделей.
Похожий сбой обнаружился в стандартном оценщике P(True) библиотеки lm-polygraph. На MMLU он читал True в позиции, где Qwen3 предпочитал букву ответа, а на TriviaQA — метку из самого запроса. Перенос позиции чтения и явное сопоставление вариантов улучшили ранжирование, поэтому проблема не ограничивается одним экспериментальным шаблоном.
Планы меняются для пайплайнов с вложенными инструкциями
Работа не требует отказаться от оценки по фиксированным вариантам. Она меняет критерии приёмки: корректный формат числа ещё не подтверждает, что модель оценивала нужное событие. Особенно это касается самооценки ответов, моделей-оценщиков и пайплайнов, где в запрос цитируют вопросы, документы или сообщения с собственными командами.
Перед запуском такого оценщика в продукте стоит закрепить четыре проверки: свободное продолжение начинается с ожидаемого формата; разрешённые варианты получают заметную суммарную вероятность; их первые токены различаются после реального контекста; итоговая оценка ранжирует именно целевой исход. Удаление или замена вложенной инструкции служит дополнительным контрольным тестом: показание не должно незаметно переключаться на неё.
Основное сравнение качества провели на 240 отрывках RACE-H с тремя версиями Qwen3 и Llama-3-8B-Instruct. Отдельные проверки охватили более широкий набор архитектур, а lm-polygraph тестировали на выборках по 500 примеров MMLU и TriviaQA. Метод требует доступа к вероятностям выбранных токенов в заданной позиции, поэтому результаты не охватывают API, которые возвращают только готовый текст.
Если пайплайн уже использует вероятности следующего токена, исправление обычно лежит в шаблоне и позиции чтения, а не в смене модели. Но после переноса позиции метрику нужно проверить заново: большая масса вариантов показывает, что модель вошла в нужный режим ответа, но не гарантирует, что её оценка предсказывает требуемый результат.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
