TL;DR
Исследование показывает, где LLM-судья ломается при проверке персонализации. Вы даёте ему историю диалога, новый запрос и ответ ассистента. Судья должен решить: RIGHT (память о пользователе использована верно), UNDER (нужное не учтено) или OVER (учтено то, что не должно влиять). Авторы собрали бенчмарк с контролируемыми ошибками и проверили, насколько судьи находят их по сравнению с людьми.
Главная боль: судья часто видит, что с ответом что-то не так, но называет не ту болезнь. Ассистент проигнорировал пожелание пользователя, а судья пишет «применил лишнее». Нужный факт в истории он находит. Он неверно определяет его роль: актуален ли факт, чей он, на какую задачу распространяется, насколько силён. Подсветка нужных реплик почти не помогает, потому что проблема не в поиске факта. Если же обрезать историю, судья начинает ругать правильные ответы.
Метод из статьи — не лечение, а способ видеть проблему. Каждому факту о пользователе заранее назначают роль: IGNORE (не должен влиять), SUPPORT (может направлять), DOMINATE (обязан быть выполнен). Ответ сверяют с ролями и выбирают один из трёх вердиктов. Рабочую версию судьи для своей задачи можно собрать по этим определениям (шаблон ниже).
Схема метода
ШАГ 1: Выписать из истории факты о пользователе → список (чей, на что распространяется, актуален ли, насколько жёсткий, переносится ли на новую задачу)
ШАГ 2: Назначить каждому факту роль → IGNORE / SUPPORT / DOMINATE
ШАГ 3: Сверить ответ с ролями → RIGHT / UNDER / OVER + тип ошибки
Всё это можно уместить в один промпт.
Шаги 1–2 заимствованы из того, как авторы строили эталонные сценарии. Там же были «формулировка с таблицей состояний» и «сначала доказательства». Результатов их сравнения в доступном тексте нет. Что именно улучшает такая разметка, неизвестно.
Пример применения
Задача: Вы делаете телеграм-бота-помощника по путешествиям на базе LLM. Нужно проверять сотню его ответов в неделю с помощью LLM-судьи. Типичный случай: пользователь раньше говорил «летаю только прямыми рейсами, у меня маленький ребёнок». Потом написал: «в Сочи в этот раз еду один, пересадка не проблема». Бот предложил только прямой рейс Москва — Сочи за 14 500 ₽. Рядом в истории есть чужой факт: «жена не ест глютен». К перелёту он отношения не имеет.
Промпт:
Ты проверяешь, как ассистент использовал информацию о пользователе из истории диалога.
<История>
[Эпизод 1, март] Пользователь: «Летаю только прямыми рейсами, с нами маленький ребёнок».
[Эпизод 2, октябрь] Пользователь: «Хочу в Сочи на выходные. В этот раз еду один, пересадка не проблема, главное — подешевле».
[Там же] Пользователь: «Жена, кстати, не ест глютен, так что в отель с завтраком не смотрю».
<Запрос>
Подбери билеты Москва — Сочи на 14–16 ноября.
<Ответ_ассистента>
Нашёл прямой рейс Москва — Сочи за 14 500 ₽. Прямые рейсы — самый удобный вариант, особенно с ребёнком.
Шаг 1. Выпиши все факты о пользователе. Для каждого укажи: чей факт, на какую задачу он распространяется, актуален ли сейчас, насколько жёсткий, переносится ли на этот запрос.
Шаг 2. Назначь каждому факту роль: IGNORE (не должен влиять на ответ), SUPPORT (может направлять), DOMINATE (ответ обязан это выполнить).
Шаг 3. Сравни ответ с ролями. Дай один вердикт:
- RIGHT: применимое использовано верно, неприменимое не использовано;
- UNDER: применимое опущено или учтено слишком слабо;
- OVER: использовано то, что не должно влиять, или ему дан слишком большой вес.
Если вердикт не RIGHT, назови один главный тип ошибки: полное или частичное упущение, явное нарушение, нерелевантное использование, утечка из другой области, домысел, устаревшее состояние, чрезмерное доминирование, недовес.
Для каждого вывода процитируй реплику из истории.
Результат: Модель выдаст таблицу фактов с ролями: прямые рейсы — устаревшее (IGNORE), «еду один, пересадка не проблема» — актуальное (DOMINATE), глютен жены — не относится к запросу (IGNORE). Потом придёт вердикт с цитатами и названным типом ошибки — скорее всего, использование устаревшего состояния. Само по себе это не гарантирует, что судья не перепутает направление. Но направление, роль каждого факта и цитаты окажутся на виду. Спорные вердикты проще проверить глазами.
Почему это работает
Слабость LLM-судьи. Просьба «оцени, хорошо ли ассистент использовал память» в лоб приводит к смешению двух вопросов. Первый — есть ли в ответе след истории. Второй — должна ли эта история влиять на ответ. Судья легко находит факт и его след. Но решение «факт устарел», «чужой» или «не из этой области» он принимает неточно. Поэтому в статье 26,6% ошибок типа UNDER получили вердикт OVER.
Сильная сторона. Модель хорошо работает с явной структурой. Когда нужно перечислить факты, сопоставить их с ответом и процитировать источник, она это делает. Читателю остаётся проверять видимые решения, а не угадывать, как рассуждал судья.
Как метод использует силу против слабости. Он разделяет решение на два вопроса. Сначала: какую роль должен играть каждый факт. Потом: сыграл ли он эту роль в ответе. Но здесь честная оговорка: авторы измерили, где судья ошибается, а не то, что такая декомпозиция чинит ошибки. Это гипотеза, которую надо проверять на своих данных.
Рычаги управления: - Дайте судье всю историю, а не последние реплики. В статье урезание контекста резко увеличивало ложные тревоги. - Просите цитату для каждого решения. Так вы видите, на что судья опирался. - Для строгости или мягкости меняйте судью и порог: модели сильно различаются по настроению. - Вместо трёх вердиктов можно использовать подтипы ошибок. Так вы увидите, какой тип чаще всего путается.
Шаблон промпта
Ты проверяешь, как ассистент использовал информацию о пользователе из истории диалога.
<История>
{полная_история_диалога}
<Запрос>
{целевой_запрос_пользователя}
<Ответ_ассистента>
{ответ_ассистента}
Шаг 1. Выпиши все факты о пользователе из истории. Для каждого укажи: чей это факт, на какую область распространяется, актуален ли сейчас (не отменён ли позже), насколько он жёсткий (требование или пожелание), переносится ли на этот запрос.
Шаг 2. Назначь каждому факту роль: IGNORE (не должен влиять на ответ), SUPPORT (может направлять ответ), DOMINATE (ответ обязан это выполнить).
Шаг 3. Сравни ответ с ролями и дай один вердикт:
- RIGHT: применимое использовано верно, неприменимое не использовано;
- UNDER: применимое опущено или учтено слишком слабо;
- OVER: использовано то, что не должно влиять, или ему дан слишком большой вес.
Если вердикт не RIGHT, назови один главный тип ошибки из списка: {список_типов_ошибок}.
Для каждого вывода процитируй реплику из истории.
Формат ответа: таблица фактов → вердикт → тип ошибки → цитаты.
{список_типов_ошибок} — подтипы из статьи: полное упущение, частичное упущение, явное нарушение, нерелевантное использование, утечка из другой области, домысел, устаревшее состояние, чрезмерное доминирование, недовес. Оставьте только нужные.
🚀 Быстрый старт — вставь в чат:
Вот шаблон судьи для проверки персонализации. Адаптируй под мою задачу: [твоя задача, например «проверяю ответы бота поддержки, который помнит клиента»].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, что считается «историей» в вашей системе, какие факты о клиенте бывают, когда они устаревают и чем отличается чужой факт от своего. Эти ответы нужны, чтобы роли IGNORE / SUPPORT / DOMINATE получили смысл для вашей области. Она возьмёт структуру из шаблона и адаптирует под вашу задачу.
Ограничения
⚠️ Лечение не проверено: Статья показывает, где судья ошибается. Что именно исправит ошибки, она не доказывает. В доступной части результатов сравнения форматов «сначала доказательства» и «таблица состояний» нет. Шаблон выше — моя сборка по определениям авторов, а не проверенный промпт.
⚠️ Судья слабее человека: На ошибках «не учёл» разрыв с людьми самый большой. Нельзя полагаться на LLM-судью как на единственный фильтр. Выборку нужно проверять вручную.
⚠️ Подсветка не спасает: Если вы подчеркнёте судье нужные реплики, это почти не поможет. Не тратьте время на сложный поиск релевантных кусков, если проблема в оценке роли факта.
⚠️ Урезанная история вредит: Если дать судье только последние реплики или один запрос, он начнёт видеть ошибки там, где их нет. В статье это объясняется именно потерей релевантных ходов, а не длиной контекста.
⚠️ Данные синтетические: Сценарии построены на сервисных задачах (бронирование, заказ) и сгенерированы моделью, проверенной людьми на выборке в 100 сценариев. Переносить цифры на ваш домен нельзя.
⚠️ Результаты частично скрыты: Данные по одному из сильнейших судей отсутствуют в публичной версии.
Как исследовали
Авторы поставили вопрос иначе, чем обычно: проверили не ассистента, а того, кто его оценивает. Они взяли 20 сервисных областей из набора Schema-Guided Dialogue, развернули их в 48 типов задач и 480 затравок, а модель превратила их в 456 спецификаций. После проверки осталось 403 сценария, по два ответа на каждый (правильный и с одной контролируемой ошибкой), всего 806 ответов. Ошибки бывают девяти подтипов трёх семейств: «недоучёл», «переучёл» и «неверное состояние».
Сценарии устроены в трёх вариантах. История должна сохраниться, перенестись в другую задачу или перестать действовать. Каждому факту заранее присвоена роль (игнорировать, поддерживать или выполнять обязательно). Таким образом правильный ответ определён заранее, а не угадан.
Людей проверили на 100 сценариях. Разметка ошибок подтвердилась в 88% случаев, роли фактов совпали в 86,3%. Затем сравнили людей и четырёх судей, чьи результаты опубликованы (Kimi K2.5, GLM-5, DeepSeek-V3.2, Qwen3-32B; результаты пятого, Claude Opus 4.6, не приведены). На «недоучёл» люди нашли 94,4% ошибок, лучший судья — 63,9%. 26,6% таких ошибок судьи назвали «переучёл».
Любопытные детали. Констатный ответ «всегда OVER» набирает 67,7% распознанных ошибок, но бракует каждый правильный ответ. Поэтому нужно смотреть и долю ложных тревог. Судьи работают в разных режимах: Kimi K2.5 находит больше, но чаще бракует правильное, Qwen3-32B почти не ложно тревожит, но находит мало. А на «переучёл» люди оказались слабее (56%), чем лучшие модели. Если убрать из истории ходы с применимым фактом, ложные тревоги вырастают на 55,2 пункта. Если убрать столько же нерелевантных, то на 2,0. Так показано, что дело в потере нужной истории, а не в длине.
Вывод для практики: проблема не в доступе к доказательствам, а в суждении, какую роль должен играть факт.
Адаптации и экстраполяции
🔧 Техника: отдельный вердикт по каждому факту → меньше путаницы в направлении
Вместо одного вердикта на весь ответ просите оценку каждой роли:
Для каждого факта из таблицы напиши отдельно: роль (IGNORE/SUPPORT/DOMINATE), как факт проявился в ответе (не проявился / слабо / сильно), и совпадает ли это с ролью. Только после этого дай общий вердикт.
Это моя идея, статьёй не проверена. Она основана на том, что и UNDER, и OVER — следствия одного неверно назначенного веса.
Экстраполяция для инструкций агенту с памятью. Если ваш агент хранит правила или предпочтения (например, в CLAUDE.md), для каждого указывайте область действия и срок: «действует только в проекте X», «отменяет предыдущее правило Y», «относится только к клиенту Z». Так вы заранее задаёте роли, а не заставляете модель угадывать их по контексту. Вывод по мотивам статьи, прямо она это не проверяла.
Ресурсы
- PersEvalBench: Can LLM Evaluators Judge Contextually Appropriate Use of Persona Information?
- Авторы: Xinyi Liu, Hooshang Nayyeri, Emine Yilmaz, Dilek Hakkani-Tur, Charith Peris, Hari Thadakamalla (Amazon; University of Illinois Urbana-Champaign; University College London)
- Основа сценариев: Schema-Guided Dialogue (Rastogi et al., 2020)
- Близкие работы: Personalized Judge (Dong et al., 2024); работы про избирательное использование предпочтений (Hu et al., 2026; Yoon et al., 2026; Feng et al., 2026)