TL;DR
Когда LLM-судью просят пометить ответ как «галлюцинацию», результат зависит от того, как записан критерий. Если написать «ответ должен подтверждаться эталоном», судья бракует всё, чего в эталоне нет. Если написать «ответ ложен, только если противоречит эталону или содержит неверный конкретный факт», он оценивает правду. Меняется одна формулировка, а согласие с людьми-разметчиками подскакивает в разы.
Боль выглядит так. В эталоне написано «Париж», модель ответила «Париж, столица Франции на Сене, около 2 млн жителей». Всё верно, но судья с критерием «соответствие эталону» ставит «галлюцинация»: про Сену в эталоне ничего нет. Ошибки идут почти строго в одну сторону. Судья перебраковывает: у самых сильных моделей до 99–100% ошибок были ложными тревогами. Причина простая: модель буквально исполняет инструкцию. Ей сказали «не подтверждено эталоном — значит плохо», она так и делает.
Решение — переписать критерий в промпте судьи на «фактическую правильность»: ошибка есть только при противоречии или ложном конкретном факте (дата, имя, число). Дополнительные верные детали ошибкой не считаются. Длинный и подробный промпт ничего не добавил: сработала именно смена критерия. Если нужно проверять соответствие источнику (например, в RAG), критерий «верность источнику» остаётся правильным, но его нужно выбрать осознанно.
Схема метода
ШАГ 1: Реши, что ты проверяешь → «верность эталону» ИЛИ «фактическая правильность»
ШАГ 2: Запиши критерий в промпт судьи явно:
что считается ошибкой / что ошибкой НЕ считается
ШАГ 3: Прогони судью на 30–50 ответах, которые ты уже разметил сам
ШАГ 4: Сравни вердикты с твоими → посмотри направление ошибок
(много «ложных тревог» = критерий слишком строгий)
Всё делается в одном промпте судьи, шаги 3–4 — ручная проверка выборки.
Пример применения
Задача: Вы делаете бота для викторин в духе «Своей игры». Есть 200 вопросов с короткими эталонными ответами. Бот отвечает развёрнуто, а LLM-судья должен отметить ответы с выдумкой. Без правильного критерия судья забракует половину нормальных ответов: бот добавляет верные детали, которых нет в эталоне.
Промпт:
Ты проверяешь ответы бота-эрудита на фактическую правильность.
Вопрос: Кто основал Москву по летописной версии?
Эталонный ответ: Юрий Долгорукий
Ответ бота: По летописной версии, Москву основал князь Юрий Долгорукий в 1147 году. Первое упоминание города относится именно к этой дате, а в 1156 году князь велел построить деревянные стены Кремля.
Критерий. Пометь ответ как ГАЛЛЮЦИНАЦИЯ (1), только если выполняется хотя бы одно:
— ответ противоречит эталону;
— в ответе есть конкретное проверяемое утверждение (дата, имя, число, название), которое фактически неверно.
НЕ считай галлюцинацией верные подробности, которых нет в эталоне.
Оценивай ответ целиком: верное ядро не отменяет неверной детали в другом месте ответа.
Порядок: сначала сравни ответ с эталоном. Если эталона не хватает, чтобы проверить конкретное утверждение, проверь его по своим знаниям.
Выведи: сначала список конкретных утверждений из ответа и вердикт по каждому, затем итог: 0 или 1.
Результат: Модель разберёт ответ на утверждения (имя, год основания, год постройки стен) и для каждого напишет, подтверждено ли оно эталоном или знаниями. В конце выдаст итоговую метку 0 или 1. Верные подробности, которых нет в эталоне, судья не забракует. Неверную дату он поймает даже при правильном имени.
Почему это работает
Слабость. LLM-судья не знает, что вы имели в виду. Он исполняет написанное. Фраза «ответ должен следовать из эталона» превращает любую верную добавку в нарушение. Поэтому ошибки однобокие: почти все — ложные тревоги.
Сильная сторона. Современные модели хорошо следуют чётко заданному критерию. Если прописать, что считается ошибкой, а что нет, судья проверяет правду, а не совпадение с шпаргалкой. Подробность промпта тут вторична: сжатый вариант критерия работал не хуже длинного, а длинный по структуре, но со старым критерием не помог.
Рычаги управления: - Что считается ошибкой (противоречие, ложный факт) → главный рычаг, меняет всё. - Что НЕ считается ошибкой (верные детали сверх эталона) → снимает перебраковку. - Единица проверки (ответ целиком, а не только главный ответ) → ловит неверную деталь при верном ядре. - Порядок (сначала эталон, потом знания модели) → эталон остаётся опорой, но не потолком. - Длина промпта → почти не влияет, можно сокращать.
Шаблон промпта
Дословные промпты авторов (p1, p2) вынесены в приложение, в предоставленном тексте их нет. Шаблон ниже собран по описанию критерия из статьи.
Ты проверяешь ответы на фактическую правильность.
Вопрос: {вопрос}
Эталонный ответ: {эталон}
Ответ для проверки: {ответ}
Критерий. Пометь ответ как ГАЛЛЮЦИНАЦИЯ (1), только если:
— ответ противоречит эталону;
— или в ответе есть конкретное проверяемое утверждение
({типы_фактов}), которое фактически неверно.
НЕ считай галлюцинацией верные подробности, которых нет в эталоне.
Оценивай ответ целиком: верное ядро не отменяет неверной детали.
Порядок: сначала сравни с эталоном. Если эталона недостаточно,
проверь утверждение по своим знаниям.
Выведи: {формат_вывода}
{вопрос},{эталон},{ответ}— данные одного примера.{типы_фактов}— что в вашей области считается проверяемым: даты, имена, суммы, названия, артикулы.{формат_вывода}— например, «только 0 или 1» для массовой проверки либо «утверждения + вердикт» для отладки.
Ограничения
⚠️ Не для проверки по источнику: если у вас RAG, пересказ или анализ документа, правильный критерий как раз «верность источнику». Статья прямо говорит, что для таких задач строгая проверка по эталону уместна.
⚠️ Слабые маленькие модели: локальные модели на 7–9 млрд параметров повели себя неровно. Llama-3-8B после смены критерия перекинулась в другую крайность: начала пропускать настоящие ошибки. Для маленьких судей смену критерия нужно проверять отдельно.
⚠️ Не панацея: даже с лучшим критерием согласие автоматического судьи с людьми осталось ниже, чем согласие двух людей между собой. Разметку на выборке всё равно нужно проверять руками.
⚠️ Дальше улучшений нет: расширенный вариант критерия (p3) не дал надёжного выигрыша над базовым. Усложнять промпт после правильной формулировки не нужно.
⚠️ Узкая проверка: тест — короткие вопросы с короткими эталонами. На длинных текстах и сложных рассуждениях вывод не проверялся.
Как исследовали
Исследователи из Хельсинкского университета взяли 300 вопросов из трёх популярных наборов: фактоидные (TriviaQA), многошаговые (HotpotQA) и «ловушки на заблуждения» (TruthfulQA). На каждый вопрос ответили три небольшие открытые модели, получилось 900 пар «вопрос–ответ». Затем люди вручную разметили, есть ли в ответе фактическая ошибка. Второй разметчик независимо проверил треть, и согласие между людьми получилось высоким (κ = 0,81).
Потом сравнили автоматических «судей»: метрики сходства текстов (ROUGE-L, BERTScore), NLI-модель и семь LLM-судей, включая GPT-5.4 и Claude Opus 4.7. Главный эксперимент: один и тот же судья получает либо промпт «верность эталону» (p1), либо «фактическая правильность» (p2). Результат поразил: GPT-5.4 с p1 почти не совпадал с людьми (κ около 0,02–0,3), с p2 — 0,62–0,78. GPT-5-mini вырос с 0,19 до 0,63 на ответах Mistral. Ошибки при p1 почти все были ложными тревогами, до 100%.
Контрольный эксперимент отсёк очевидное возражение: «просто p2 длиннее и подробнее». Исследователи сделали p1 в структуре p2 (без выигрыша) и сжали p2 до структуры p1 (без потери). Значит, дело именно в критерии. Неожиданность: самый сильный судья по возможностям (GPT-5.4) ошибался сильнее всех при p1, а Claude Opus 4.7 уже при p1 был близок к «правильному» поведению. Одна лишь мощность модели не защищает от неверного критерия.
Адаптации и экстраполяции
🔧 Техника: добавить явный список «не считай ошибкой» → меньше ложных тревог
В статье показан эффект переформулировки критерия. Если судья всё равно бракует лишнее, добавьте в промпт пример-исключение:
Не считай ошибкой: уточнения, синонимы, более подробное описание,
верные факты, которых нет в эталоне.
🔧 Техника: считать ошибки по направлению → быстро найти плохой критерий
После прогона на 30–50 ответах разделите ошибки судьи на два типа: «судья сказал плохо, а я считаю нормально» и наоборот. Если почти все ошибки одного типа, виноват критерий, а не случайный шум. Это идея самой статьи (анализ ложных тревог и пропусков), перенесённая на ручной контроль.
Экстраполяция: проверка собственных промптов-проверялок для агента. Если вы даёте агенту инструкцию «сверь результат с ТЗ», то он будет бракуйте всё, чего в ТЗ нет, даже полезное. Допишите в инструкцию: «Дополнения сверх ТЗ не считай ошибкой, если они не противоречат ТЗ и не содержат ложных фактов». Эта идея вытекает из логики статьи, но на агентах авторы её не проверяли.
Ресурсы
- The Labeling Problem in Hallucination Detection Benchmarks: An Empirical Evaluation — Jorma Valjakka, Juha Mylläri, Juhani Kivimäki, Jukka K. Nurminen, Department of Computer Science, University of Helsinki.
- Данные: Harvard Dataverse, https://doi.org/10.7910/DVN/PCHISZ
- Код: https://github.com/jova486/LPHB
- Наборы вопросов: TriviaQA, HotpotQA, TruthfulQA.