ConQual-Audit: проверка чек-листа критериев контррпримерами перед оценкой ответов LLM

ШАГ 1. Построение: профиль + эталон → список утверждений
        («Ответ рекомендует…» / «Ответ НЕ рекомендует…»)
ШАГ 2а. Дубли: объединить одинаковые критерии
ШАГ 2б. Лишние: для каждого критерия написать хороший ответ,
        который его нарушает, но соблюдает остальные.
        Получилось → критерий удалить.
ШАГ 2в. Недостающие: написать плохой ответ,
        который соблюдает ВСЕ критерии.
        Получилось → добавить критерий, который его отсекает
        (максимум 3 новых).
ШАГ 3. Проверка ответа: каждый критерий →
        ENTAILMENT (следует) / CONTRADICTION (противоречит) / NEUTRAL
        Доля выполненных ≥ 0,5 → ответ принят

В чате шаги идут отдельными сообщениями в одном диалоге. Шаг 2 в оригинале сделан с несколькими ролями модели: генератор, проверяющий и судья.

Сильная зона метода: у вас есть персональный ассистент или кастомный GPT, и надо понять, учитывает ли он предпочтения конкретного человека. Субъективные вкусы вроде «красиво» метод проверяет плохо. Явные «любит / избегает / нельзя» он проверяет хорошо.

Задача: вы делаете кастомный GPT для нутрициолога. Клиентка Марина из Казани закупается во «ВкусВилле» и «Самокате». Она не ест красное мясо, у неё аллергия на арахис, бюджет — до 6 000 ₽ в неделю. Нужно построить чек-лист и проверить, как ассистент отвечает на запрос «Составь меню на неделю».

Промпт (шаг 1 — построение):

Профиль клиентки: не ест красное мясо; аллергия на арахис; бюджет до 6 000 ₽ в неделю; покупает во «ВкусВилле» и «Самокате»; хочет больше белка.

Запрос: «Составь меню на неделю».

Эталонный ответ: меню на 7 дней, 3 приёма пищи, с граммовками и ориентировочной стоимостью.

Сделай список критериев для оценки ответа. Правила:
— каждый критерий — одно утверждение об ответе;
— обязательное: «Ответ рекомендует …»;
— запрещённое: «Ответ не рекомендует …»;
— берём только то, что относится к этому запросу;
— одно утверждение = одно требование, без дублей.
Источники: (а) предпочтения из профиля, (б) атомарные требования из эталона.

Промпт (шаг 2б — поиск лишних):

Вот критерии:
1. {критерий_1}
2. {критерий_2}
...
Для критерия №1: напиши ответ на запрос, который НАРУШАЕТ только критерий №1 и соблюдает все остальные. Ответ должен быть при этом хорошим для клиентки. Если такой ответ невозможно написать — так и скажи. Попыток — две. Затем оцени: подходит ли этот ответ клиентке? Если да — критерий лишний.
Повтори для каждого критерия.

Промпт (шаг 2в — поиск недостающих):

Теперь напиши ответ, который соблюдает ВСЕ оставшиеся критерии, но при этом НЕ подходит клиентке (нарушает её предпочтения или требования задачи). Если получилось — предложи не больше трёх новых критериев, которые отсекут такой ответ. Если не получилось — оставь список как есть.

Промпт (шаг 3 — проверка ответа ассистента):

Ответ ассистента: {ответ}
Для каждого критерия определи: ENTAILMENT (ответ это гарантирует), CONTRADICTION (ответ противоречит) или NEUTRAL (ответ об этом не говорит). Для ENTAILMENT процитируй предложения, которые это подтверждают. Затем посчитай долю критериев с ENTAILMENT. Ответ принят, если доля ≥ 0,5.

Результат: сначала модель выдаст 4–6 критериев. После шага 2б часть пропадёт, например дубли «не красное мясо» и «рекомендует курицу или рыбу». После шага 2в может появиться недостающий критерий вроде «Ответ не включает продукты, содержащие арахис». На шаге 3 вы получите таблицу «критерий → метка → цитата» и итоговую долю.

Слабость. Когда модель составляет критерии «с нуля», она пишет либо слишком общее («ответ полезен»), которое проходит любой текст, либо слишком конкретное (копирует детали из эталона). Хороший ответ формулируется иначе и получает отказ. Оценщик с таким чеком-листом ошибается в обе стороны, и по формуле добавление лишнего критерия снижает оценку валидного ответа, а пропуск нужного завышает оценку плохого.

Сильная сторона модели — писать конкретные примеры по условию. «Напиши ответ, который нарушает только вот это» и «напиши ответ, который выполняет всё, но плохой» — это обычные генеративные задачи. Они решаются намного надёжнее, чем абстрактный вопрос «нужен ли этот критерий?». Контрпример — доказательство: если хороший ответ существует без критерия, критерий лишний.

Что делает метод: превращает размытый вопрос «хороший ли чек-лист?» в два проверяемых теста. Лишний критерий определяется по хорошему ответу, который его нарушает. Недостающий определяется по плохому ответу, который проходит все критерии. Формулировки в виде утверждений позволяют потом проверять ответ как логический вывод: следует / противоречит / не относится.

Рычаги управления: - Число попыток (в статье 2) → больше попыток ловят больше лишних критериев, но растут расходы. - Лимит новых критериев (в статье 3) → не даёт чек-листу раздуться снова. - Порог принятия (0,5) → поднимите, если нужна строгая проверка; опустите, если важнее не потерять хорошие ответы. - Источники → если эталона нет, строите только из профиля. Если профиля нет, только из эталона. - Метка NEUTRAL → полезна: она отделяет «не сказал» от «сказал наоборот».

Ты — аудитор критериев оценки. Работаем в 3 этапа.

ДАНО
Запрос пользователя: {запрос}
Профиль / история предпочтений: {профиль}
Эталон (пример правильного ответа или требования задачи): {эталон}

ЭТАП 1. ПОСТРОЕНИЕ
Составь список критериев. Каждый — одно утверждение об ответе:
— обязательное: «Ответ рекомендует / содержит …»
— запрещённое: «Ответ не рекомендует / не содержит …»
Источники: (а) предпочтения и ограничения из профиля, относящиеся к запросу; (б) атомарные требования из эталона.

ЭТАП 2. АУДИТ (контрпримеры, макс. {число_попыток} попытки на критерий)
2а. Дубли: если два критерия значат одно и то же — оставь первый.
2б. Лишние: для каждого критерия напиши ответ, который нарушает ТОЛЬКО его и соблюдает остальные. Оцени: подходит ли такой ответ пользователю и задаче? Да → критерий удалить. Нет или ответ написать нельзя → оставить.
2в. Недостающие: напиши ответ, который соблюдает ВСЕ оставшиеся критерии, но не подходит пользователю или не решает задачу (отдельно по профилю и по эталону). Получилось → добавь не больше {лимит_новых} критериев, которые его отсекают.
Выведи итоговый список критериев и что удалено / добавлено.

ЭТАП 3. ПРОВЕРКА
Ответ для проверки: {ответ}
Для каждого критерия: ENTAILMENT / CONTRADICTION / NEUTRAL + цитата из ответа.
Итог: доля ENTAILMENT = ... Принят, если ≥ {порог}.

Что подставлять: {запрос} — задача пользователю. {профиль} — привычки, запреты, стиль, ограничения. {эталон} — образец или список требований. {число_попыток} — 2. {лимит_новых} — 3. {порог} — 0,5.

🚀 Быстрый старт — вставь в чат:

Вот шаблон ConQual-Audit. Адаптируй под мою задачу: хочу проверять ответы моего ассистента на соблюдение предпочтений пользователя.
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

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

⚠️ Нужны источник предпочтений и эталон: метод строит критерии из профиля и эталона. Если у вас нет ни того, ни другого, критерии придётся придумывать самому, и метод теряет опору.

⚠️ Нестабильность судьи: в статье модель-проверяющий повторяла свои решения на тех же критериях лишь примерно в трёх случаях из четырёх. Прогоните проверку дважды и сравните результаты. Не доверяйте одному прогону.

⚠️ Дорого по токенам: аудит съедает основную часть расходов. Он единоразовый для каждого запроса, но на одиночный вопрос в чате может не окупиться. Метод полезен, когда один чек-лист проверяет много ответов.

⚠️ Проверяет соблюдение требований, а не качество стиля: тон, красота, оригинальность в такие утверждения не превращаются.

⚠️ Аудит чужих чек-листов даёт слабый эффект: при подключении к другим оценщикам ошибки снизились лишь немного (примерно с 0,50 до 0,49 и с 0,51 до 0,46). Основной выигрыш получен в собственном конвейере метода.

⚠️ Малые модели: всё проверяли на небольшой модели Qwen3-8B. На сильных моделях результат, вероятно, лучше, но это не проверено.

Исследователи взяли два набора: LaMP (ответы под конкретного пользователя, 100 пользователей, по 10 перефразированных верных, 10 отрицающих и 10 неверных ответов на каждого) и PrefEval (200 ответов, где одни сгенерированы с учётом предпочтения, а другие без). Смысл LaMP — проверить, отличает ли оценщик смысл от формы. Перефраз верного ответа должен проходить, ответ с отрицанием — нет. Против метода выставили девять оценщиков трёх семейств: по совпадению слов (BLEU, ROUGE), по эмбеддингам (BERTScore), «модель-судья» (GEMBA, PerSE, FActScore) и методы с чек-листом (ExPerT, PREF). Все модули ConQual работали на одной небольшой модели, чтобы выигрыш объяснялся методом, а не размером модели.

Результаты наглядно показали, почему чек-лист нужно проверять. BLEU отвергал 65% верных ответов, а BERTScore принимал все ответы с отрицанием. ExPerT, привязанный к словам эталона, отклонял 92–97% верных ответов. PREF с общими критериями принял все неправильные ответы на PrefEval. ConQual-Audit снизил долю ошибок до 0,21 на обоих наборах, то есть на 16% и 28% относительно сильнейшего конкурента. При этом ему хватало около 2–3 критериев против 5–8 у соперников. Разрыв между оценками хороших и плохих ответов стал почти вдвое больше.

Любопытно, что меньше критериев = точнее. Практический вывод: каждый лишний пункт чек-листа — это дополнительный шанс отклонить хороший ответ. Аудит чужих чек-листов удалял 19–29% критериев, но выигрыш был небольшой: проверяющая модель сама шумела. Расходы: около 12,6 тыс. токенов на ответ, и более 80% из них уходит на единоразовое построение и аудит критериев. Сама проверка стоит около 2,5 тыс. токенов на ответ.

🔧 Техника: убрать эталон → строить критерии только из профиля. Когда эталона нет, оставьте в шаблоне только источник (а). Эталонная часть этапа 2в тогда пропускается. Эффект: метод работает для персонализации «с нуля», но недостающие критерии будут искаться только по предпочтениям.

🔧 Техника: добавить print результатов 2б. Попросите вывести пару «критерий → контрпример → вердикт». Вы увидите, почему критерий удалён, и сможете вернуть его вручную.

Экстраполяция (не из статьи): аудит правил в инструкции агента. Правила в CLAUDE.md или системном промпте — те же критерии. Принцип контрпримеров можно перенести на них:

Вот правила из моей инструкции агенту:
{список_правил}

1. Для каждого правила опиши ситуацию, где агент его нарушил бы, а результат остался хорошим. Если такая ситуация есть — правило лишнее или слишком жёсткое.
2. Опиши ситуацию, где агент соблюл все правила, но результат плохой. Предложи не больше трёх правил, которые это закрывают.
Итог: сокращённый список правил.

В статье это не проверялось: в ней аудитируются критерии оценки, а не инструкции агенту. Но логика та же: лишнее правило ограничивает хорошие ответы, а недостающее пропускает плохие.

• Работа: Neither Over- nor Under-Constrained: Evaluating LLM Personalization under a Constraint Qualification Audit (ConQual-Audit)
• Авторы: Xuran Li, Guanqin Zhang, Imran Razzak, Hakim Hacid, Eleanna Kafeza, Hao Xue, Flora D. Salim
• Организации: University of New South Wales; Mohamed bin Zayed University of Artificial Intelligence; Technology Innovation Institute; Hong Kong University of Science and Technology
• Бенчмарки: PrefEval (Zhao et al., 2025), LaMP (Salemi et al., 2024)
• Сравнивали с: ExPerT (Salemi et al., 2025), PREF (Fu et al., 2025), GEMBA, PerSE, FActScore, BERTScore, MoverScore
• Код и промпты: авторы заявляют о публикации в анонимном репозитории