TL;DR
Verification elicitation («извлечение через проверку») — способ получить оценки от модели без генерации текста. На каждую категорию задаётся отдельный закрытый вопрос вида «Выражает ли это X?». Из ответа берут не слово «да» или «нет», а вероятность токена «да» (logprobs, то есть логиты первого токена ответа). В итоге у каждой категории есть число, и по этим числам можно ранжировать.
Главная находка: требование «назови ровно N пунктов» ломает результат. В исследовании модель просили вернуть ровно 25 эмоций из 40, даже если на лице видны две-три. Остальные ~22 она выдумывала, и по числу пунктов нельзя было понять, что в данных. Одна и та же модель на тех же картинках с тем же метрикой показала качество на уровне случайного угадывания при «ровно 25». Когда ей позволили назвать около пяти, качество дошло до уровня согласия экспертов-людей. Выводы «модели не умеют» оказались ошибкой способа считывания ответа, а не способностей модели.
Метод решает проблему в три шага: один запрос на категорию, чтение вероятности «да», сохранение градации. Градация критична. Если округлить вероятности до «да/нет», качество падает ниже обычной генерации. Вся польза сидит в оттенках уверенности, а не в самом закрытом вопросе.
Схема метода
ШАГ 1: Разбить задачу на категории → список из N категорий
ШАГ 2: На каждую категорию отдельный запрос «Выражает ли это X? Answer:» → один токен ответа
ШАГ 3: Прочитать P(да) из logprobs первого токена → число 0..1 на категорию
ШАГ 4: Ранжировать/сравнивать по числам → НЕ округлять до да/нет
Шаги выполняются в N отдельных запросах через API с logprobs или на локальной модели. В обычном чате метод не воспроизвести.
Пример применения
Задача: Команда маркетплейса разбирает 5 000 отзывов на Wildberries и Ozon. Нужно понять, какие отзывы затрагивают темы «доставка», «брак», «не подошёл размер», «упаковка», «цена». Отзыв может касаться сразу трёх тем или одной. Сначала попробовали «выдели ровно 5 тем из списка» и получили мусор: у каждого отзыва пять тем, у всех одинаково.
Промпт (один запрос на каждую пару «отзыв × тема», 5 запросов на отзыв):
Отзыв покупателя: «Курьер привёз на три дня позже, коробка была помята, но сама кофточка хорошая, села идеально.»
Вопрос: Жалуется ли автор отзыва на доставку?
Ответь одним словом: Да или Нет.
Answer:
Дальше из API берётся вероятность токена «Да» в первой позиции (параметры logprobs и top_logprobs).
Результат: Для каждого отзыва получится таблица «тема → вероятность». Тема, о которой в тексте сказано явно, будет близка к 1. Тема, которой нет, будет около 0. Спорные случаи окажутся посередине. Количество «сработавших» тем будет разным у разных отзывов и будет отражать содержание. По этим числам можно сортировать отзывы («самые сильные жалобы на упаковку») и сравнивать темы между собой. Порог «да/нет» лучше ставить поздно, а при возможности не ставить вовсе.
Почему это работает
Слабость. Когда модель пишет ответ текстом, он проходит через формат и парсер. Если промпт требует «ровно 25 пар», счёт пунктов определяется промптом, а не картинкой. Модель не может сказать «подходят только три», и остальные пункты придумывает. Даже если она колеблется, в тексте это не видно: остаётся «7» или слово. Градация уверенности стирается при генерации.
Сильная сторона. Внутри модели информация о степени уверенности есть. На первой позиции ответа у «да» и «нет» разные вероятности, и разница между 0.99 и 0.34 несёт сигнал. Четыре эмоции с вероятностью 0.99+ для глаза выглядят одинаково, но их порядок совпадал с оценками экспертов (7, 5, 3, 2). Ответ «да/нет» сохраняет четыре категории и теряет порядок.
Как метод использует это. Он убирает навязанное число пунктов: на каждую категорию отдельный вопрос, и категория получает ответ независимо от остальных. Он читает уверенность напрямую из логитов, пока генерация её не разрушила. Дообучение при этом не нужно: в статье эксперимент с дообучением на 21 тыс. запросов оставил качество почти без изменений.
Рычаги управления:
- Формулировка вопроса: закрытая, с одним токеном ответа («Да/Нет»), чтобы вся масса вероятности легла на нужные токены.
- Префилл Answer: — чтобы модели с «рассуждением» не потратили первый токен на мысль, а сразу ответили.
- Не бинаризуй: сохраняй число и принимай решение по порогу в самом конце, на своей выборке.
- Не фиксируй число пунктов: если генерация неизбежна, разреши «только то, что реально есть».
Шаблон промпта
{входной_объект}
Вопрос: {закрытый_вопрос_про_категорию}
Ответь одним словом: Да или Нет.
Answer:
Подставляй:
- {входной_объект} — отзыв, письмо, тикет, описание вакансии или другой объект, который оцениваешь.
- {закрытый_вопрос_про_категорию} — вопрос в форме «Выражает/содержит/затрагивает ли это X?». Один запрос на одну категорию.
Из ответа бери вероятность токена «Да» из logprobs, а не слово.
🚀 Быстрый старт — вставь в чат:
Нужен небольшой Python-скрипт: для каждого {объекта} из CSV и каждой категории из списка делает отдельный запрос в API с закрытым вопросом «Да/Нет» и сохраняет вероятность токена «Да» из logprobs. Вот шаблон запроса. Адаптируй под мою задачу: {моя задача}. Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про список категорий, формат данных и используемую модель (поддерживает ли она logprobs). Это нужно, потому что метод держится на конкретных токенах «Да/Нет» и на том, что API возвращает вероятности.
Ограничения
⚠️ Нужны логиты: метод требует API с logprobs или локальную модель. В обычных чатах и у ряда популярных API вероятностей нет — метод там не воспроизвести. Основное в статье — инженерный приём, а не текстовый промпт.
⚠️ Бинаризация вредит: округление вероятностей до «да/нет» не просто сохраняет часть пользы, а ухудшает результат ниже обычной генерации. Если приходится брать только «да/нет», выигрыша не будет.
⚠️ На реальных фото эффект слабее и неоднозначен: на живых фотографиях позирующих людей из десяти валидных моделей выиграла лишь часть, одна показала ухудшение. Метод не универсален.
⚠️ Ранжирование моделей нестабильно: между моделями разница стирается внутри погрешности измерения. По такому бенчмарку нельзя уверенно выбрать «лучшую».
⚠️ Калибровка использовала эталонные оценки: чтобы привести вероятности к шкале 0–7, авторам нужно было знать распределение экспертных оценок. Это «подсказка из ответа», её влияние они проверяли отдельно, но в боевой задаче такого эталона может не быть.
⚠️ Модели с рассуждением: без префилла
Answer:у трёх таких моделей почти вся вероятность уходит на другие токены, и число превращается в шум, который выглядит правдоподобно. Нужна проверка, сколько массы лежит на «да/нет».
⚠️ Нишевая задача: лица и эмоции — область, где даже эксперты согласны лишь умеренно. Перенос на ваши категории надо проверять на своей выборке.
Как исследовали
Исследователи взяли готовый бенчмарк EmoNet-Face-HQ: 2 500 сгенерированных портретов, разметка экспертов по 40 категориям эмоций. Авторы бенчмарка показали, что обычные VLM (модели, понимающие картинки) на нём провалились, и вывели: нужна специально дообученная модель EIF. Команда не стала менять ни картинки, ни категории, ни оценки экспертов — изменила только способ считывания ответа. Вместо «напиши JSON из 25 эмоций» — 40 закрытых вопросов и чтение вероятности «да».
Ключевая проверка пришла из самого бенчмарка. Gemini 2.5 Flash там запускали с двумя промптами. С «ровно 25 категорий» она называла 25 на каждой картинке и получала κ ≈ 0.002 (случайность). С другим промптом называла в среднем около 5 и получала 0.419. Одна модель, те же картинки, та же метрика — разница целиком из-за способа извлечения ответа.
Все 11 открытых VLM при генерации не дотянули до уровня согласия экспертов (κ 0.468). При чтении логитов все 11 его превзошли (0.507–0.586), а три статистически обогнали дообученную EIF. Самое неожиданное: дообучение на 21 тыс. запросов почти не изменило результат, а смена способа считывания дала прирост больше. Контрольный эксперимент показал, что вся польза в градации: если те же вероятности округлить до «да/нет», качество упало ниже генерации. Практический вывод: способ считывания ответа может быть важнее самой модели.
Адаптации и экстраполяции
🔧 Техника: убрать фиксированное число пунктов → вернуть сигнал в обычном чате
В статье показано, что требование «ровно N» вредит. Это можно применить прямо в промпте, хотя этот вариант в статье отдельно не измеряли:
Отметь только те темы из списка, которые реально есть в тексте. Если подходит одна — назови одну, если ни одной — напиши «ни одной». Не добавляй темы ради количества.
🔧 Техника: добавить Answer: в конец → не потерять первый токен
Для моделей с рассуждением заверши закрытый вопрос префиксом Answer:. В статье это нужно, чтобы первый токен был ответом, а не началом рассуждения.
Экстраполяция: вместо вероятностей — шкала уверенности по каждой категории в чате
Если logprobs нет, можно воспроизвести дух метода: попросить оценить каждую категорию отдельным запросом по шкале 0–100. Это не проверено в статье и может дать грубую градацию, а не настоящую вероятность:
Отзыв: «{текст}»
Оцени от 0 до 100, насколько отзыв затрагивает тему «{тема}». Ответь одним числом.
Ресурсы
- «The Failure Is in the Readout: Fine-Grained Emotion Recognition Benchmarks Measure Elicitation, Not Perception» — Tobias Hallmen, Fabian Deuser, Robin-Nico Kampa, Norbert Oswald, Elisabeth André. Университет Аугсбурга (Chair for Human-Centered AI), Университет Бундесвера, Мюнхен.
- Код, валидационный фильтр и предсказания по каждому изображению: https://github.com/saveli/emonet-readout
- Исходный бенчмарк: EmoNet-Face-HQ (Schuhmann et al.). Набор для переноса: FACES. Близкая работа по чтению вероятности «Yes»: Atabuzzaman et al.