Почему «LLM-судья» ошибается: новый способ проверять ответы ИИ бинарными вопросами

Команды всё чаще поручают одной языковой модели оценивать ответы другой. Подход LLM-as-a-Judge помогает масштабировать тестирование, но итоговая оценка вроде «8 из 10» часто не объясняет, что именно сломалось и можно ли доверять результату.

Исследователи предложили BINEVAL — метод, который раскладывает критерий качества на набор простых бинарных вопросов. Вместо общего впечатления модель независимо отвечает, выполнено ли каждое конкретное требование.

Проблема одного балла

Оценка целого ответа требует одновременно учитывать фактическую точность, полноту, стиль, соблюдение инструкции и безопасность. Модель может компенсировать серьёзную ошибку хорошей формулировкой или ставить высокие баллы большинству ответов, создавая эффект потолка.

Кроме того, числовой результат трудно превратить в действие. Команда видит падение средней оценки, но не понимает, какой промпт, источник данных или компонент системы нужно исправить.

Как работает BINEVAL

Сначала мета-промпт превращает критерии задачи в мелкие вопросы, на которые можно ответить «да» или «нет». Например:

• содержит ли ответ конкретный срок;
• подтверждена ли каждая цифра предоставленным контекстом;
• указал ли ассистент ограничение метода;
• избежал ли он запрещённого совета;
• выполнен ли требуемый формат.

Затем модель оценивает каждый пункт отдельно, а результаты объединяются в многомерную оценку. Команда получает не только балл, но и диагностическую карту.

Что показало исследование

Авторы проверили подход на наборах SummEval, Topical-Chat и QAGS. По их данным, BINEVAL соответствует или превосходит сильные базовые методы, включая UniEval и G-Eval, особенно в задачах фактической согласованности. Метод также лучше воспроизводил распределение человеческих оценок и давал меньше завышенных результатов.

Это результаты научной работы, а не гарантия для любого продукта. Эффективность нужно проверять на собственных данных, языках и типах ошибок.

Как применить в AI-продукте

1. Соберите 50–200 реальных запросов, включая сложные и опасные случаи.
2. Опишите критерии на языке продукта: точность, полнота, ссылки, тон и ограничения.
3. Разбейте каждый критерий на наблюдаемые бинарные вопросы.
4. Добавьте программные проверки там, где возможен точный тест.
5. Сравните ответы судьи с оценками экспертов и измерьте расхождения.
6. Отслеживайте не только общий балл, но и частоту провала каждого вопроса.

Где нужен человек

LLM-судья не должен быть единственным контролем в медицине, финансах, праве и других высокорисковых областях. Модель может разделять те же предубеждения, что и оцениваемая система. Человеческая проверка нужна для калибровки, спорных случаев и регулярного аудита.

Практическая ценность

Главное достоинство подхода — связь между оценкой и улучшением. Если система регулярно проваливает вопрос о подтверждении цифр, команда может изменить retrieval или формат цитирования. Прозрачная диагностика полезнее ещё одного среднего числа на дашборде.

Источник: Ask, Don’t Judge: Binary Questions for Interpretable LLM Evaluation and Self-Improvement. Работа опубликована как препринт и может быть обновлена.