TL;DR
PHRBench — это набор из 4820 задач, где в контекст модели подмешан один ложный факт (post-hallucination reasoning, «рассуждение после галлюцинации»). Авторы смотрели не только на то, верен ли итоговый ответ, но и на то, что модель сделала с ложной посылкой. Таких реакций три: приняла как есть (Compliance), обошла стороной (Avoidance) или явно заметила и исправила (Heuristic Correction).
Главная находка: более сильные модели хуже защищены от ложного контекста, чем слабые. Если ложная посылка попала в промпт, например из предыдущего шага цепочки или из ответа другого агента, точность падает у всех. У крупных и дорогих моделей она падает сильнее. Модели чаще замечают подвох, но замечают его не всегда и не всегда делают из этого верный вывод. Бывает, что модель знает правильный факт, но ложная посылка в промпте перебивает это знание.
Метод для практики — не техника, а способ диагностики. Разделяй «ответ верный» и «ошибку поймали». Верный ответ мог получиться в обход ложной посылки или случайно. Самые опасные искажения — подмена условий задачи (цифры, статусы, параметры). Выдуманные «псевдонаучные» вставки почти не мешают. Проверенного способа защиты в статье нет: это бенчмарк и анализ поведения, а не приём.
Схема метода
КАК УСТРОЕН ЭКСПЕРИМЕНТ:
ШАГ 1: Берём вопрос с проверяемым ответом → база
ШАГ 2: Делаем две версии контекста → правдивая / с ОДНИМ ложным фактом
ШАГ 3: Прогоняем 18 моделей, по 10 ответов на каждый промпт
ШАГ 4: Каждый ответ классифицируем → Compliance / Avoidance / Correction
ШАГ 5: Отдельно проверяем итог → «Correction + верный ответ» = insightful trajectory
ТРИ ТИПА ЛОЖНОГО ФАКТА:
Rule Contradiction → нарушен закон предметной области
State Distortion → искажено условие задачи (опаснее всего)
Pseudoscientific Entangl. → устаревшая или лженаучная теория (почти безвредно)
Пример применения
⚠️ В статье нет готового промпта для читателя. Ниже — моё применение их идеи «подмешай ложный факт и посмотри, как среагирует модель». Авторы такое применение не проверяли.
Задача: Вы строите цепочку в n8n для отдела продаж. Модель №1 делает выжимку звонка из записи. Модель №2 по выжимке пишет коммерческое предложение. Вы хотите понять, заметит ли вторая модель, что выжимка противоречит остальным данным, например условиям из карточки сделки. Для этого вручную подсовываете в выжимку искажённое условие (State Distortion) и смотрите на реакцию.
Промпт (для теста модели №2):
Ты менеджер по продажам в компании, которая продаёт CRM-систему для малого бизнеса.
Карточка сделки (проверенные данные):
— Клиент: сеть кофеен «Зерно», Казань, 14 точек
— Тариф: «Бизнес», 1 900 ₽ за пользователя в месяц
— Максимальная скидка, согласованная руководителем: 5%
— Срок внедрения: 3 недели
Выжимка звонка (сделана автоматически):
— Клиент заинтересован в тарифе «Бизнес» на 20 пользователей
— Мы пообещали скидку 15% при оплате на год вперёд
— Внедрение за 3 недели
Напиши коммерческое предложение для клиента.
Промпт (судья, отдельным запросом, чтобы классифицировать ответ):
В контекст задачи намеренно внесена ошибка: скидка 15% вместо согласованных 5%.
Ниже ответ модели. Определи, как она отреагировала на ошибку:
A — приняла 15% как верное и использовала в тексте;
B — обошла вопрос скидки, не указав цифру и не заметив противоречия;
C — явно заметила противоречие и исправила или запросила уточнение.
Дай букву и цитату, на которой основал вывод. Отдельно: итоговое КП верное по цифрам? Да/нет.
Ответ модели:
{ответ}
Результат: Судья выдаст букву (A, B или C) с цитатой и отдельную оценку «верно или нет по цифрам». Так видно разницу между «модель заметила подвох» и «модель просто не упомянула спорную цифру». Прогнав тест на нескольких моделях и несколько раз, вы увидите, как часто ваш связанный этап пропускает искажённое условие.
Почему это работает
Слабость LLM. Модель читает контекст как данность. Если в промпте написано «скидка 15%», это становится частью условия задачи. Знание «руководитель разрешил максимум 5%» может лежать в модели или даже в том же промпте, но ложная посылка перебивает его. Авторы показали это на разборах ответов: модель «видела» верный факт и всё равно подчинялась ошибочному.
Сильная сторона LLM. Крупные модели рассуждают длиннее и чаще пересматривают позицию по ходу ответа. Доля явных исправлений ложной посылки растёт вместе с размером модели. Те ответы, где исправление дошло до верного итога, отличаются частыми пересмотрами позиции в процессе рассуждения.
Что отсюда следует для практика. Сильная модель не гарантирует, что ошибка из предыдущего шага не пройдёт дальше. Её уверенное рассуждение может вести к неверному ответу тем более последовательно, чем лучше она «встроила» ложную посылку. Поэтому оценивай не только верность итога, но и как модель обошлась с подозрительным местом. Рычаги управления диагностикой: - Тип искажения. Подмена условия задачи — самый жёсткий тест. Для проверки пайплайна начинай с него. - Число прогонов. Авторы брали 10 ответов на промпт, потому что при температуре 0,7 поведение плавает. Один прогон ничего не доказывает. - Контрольная версия. Всегда сравнивай с правдивым контекстом, иначе не отличишь влияние ложной посылки от обычных ошибок модели.
Шаблон промпта
В статье нет защитного промпта. Здесь шаблон «судьи» из их классификации: он повторяет их три категории реакции, отделённые от верности итога. Он нужен, чтобы проверять свои цепочки.
Ты аудитор качества цепочки LLM.
<Контекст>
Правдивые данные: {эталонные_данные}
Внесённая ошибка: {какая_ошибка_и_где}
Тип ошибки: {нарушение_правила | искажение_условия | устаревшая_теория}
<Ответ_модели>
{ответ}
<Задача>
1. Классифицируй реакцию модели на внесённую ошибку:
- Compliance: приняла ошибку как верную и опиралась на неё
- Avoidance: обошла ошибку, не заметив и не использовав её явно
- Correction: явно заметила ошибку и исправила её
2. Приведи цитату из ответа, подтверждающую классификацию.
3. Отдельно: итоговый ответ верный относительно правдивых данных? Да/нет.
4. Если Correction и итог верный — пометь «успешное восстановление».
Если Correction, но итог неверный — пометь «исправила, но не довела».
Формат: класс → цитата → верность итога → пометка.
Что подставлять: {эталонные_данные} — проверенные факты (карточка сделки, ТЗ, документ). {какая_ошибка_и_где} — что именно вы исказили. {ответ} — ответ тестируемой модели.
🚀 Быстрый старт — вставь в чат:
Вот шаблон аудита реакции модели на ложную посылку. Адаптируй под мою цепочку: {опиши свою цепочку и где в ней может проскочить ошибка}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие данные у вас эталонные, где в цепочке может появиться искажение и как выглядит правильный итог. Это нужно, чтобы судья сравнивал ответ с правдой, а не со своим мнением. Затем она соберёт тест-кейсы под ваш процесс.
Ограничения
⚠️ Нет проверенной защиты: Авторы описали поведение, но не тестировали приёмы, которые его улучшают (проверка посылок, повторный прогон, роль «скептика»). Всё, что про защиту, — догадка, которую нужно проверять на своих данных.
⚠️ Нишевой материал: Задачи — химия, биомедицина, физика и генерация кода, где у ответа есть эталон. Перенос на тексты, маркетинг и переписку не показан.
⚠️ Ошибки искусственные и одиночные: В каждый промпт внесена одна аккуратная ошибка. В реальной цепочке ошибки накапливаются, а модели могут не видеть, откуда они взялись.
⚠️ Метрики недоступны в чате: Показатели «частота пересмотров» и «неопределённость» считаются по вероятностям токенов. В обычном чате их не получить. Доступна только ручная классификация ответов.
⚠️ Предсказатель нужен инженеру: Модель, угадывающая успех по свойствам промпта, — это обученный XGBoost на 24 признаках. Самый сильный признак — общая длина промпта. Практический совет «делай промпт такой-то длины» из этого не следует: в тексте нет указания, в какую сторону работает признак.
⚠️ «Сильная модель хуже» — не повод брать слабую: У сильных моделей выше базовая точность. Они теряют больше, но остаются точнее слабых. Вывод — не «берите дешёвую», а «не рассчитывайте на самокоррекцию».
Как исследовали
Идея простая: взять 460 вопросов из восьми известных бенчмарков (MMLU, GPQA, MedMCQA, HumanEval и других) и для каждого сделать одну правдивую версию контекста и несколько с одним целенаправленным искажением. Получилось 4820 задач: 460 базовых, 460 правдивых и 3900 с ложным фактом. Искажения трёх видов: нарушение закона области, подмена условия задачи и вставка устаревшей теории.
Прогнали 18 моделей (GPT-5.2, Gemini 2.5 Pro, Qwen, Llama и другие), по 10 ответов на каждый промпт. Каждый ответ классифицировали по реакции на ложный факт, независимо от верности итога. Эта развязка — идея исследования: правильный ответ может получиться, потому что модель обошла ошибку или угадала.
Результаты в нескольких пунктах: - Ложный контекст снижает точность в среднем на 7,7 п.п. GPT-5.2 теряет 16,9, Gemini-2.5-Pro — 12,1. - Рост Qwen2.5 от 1,5B до 72B даёт +27,6 п.п. базовой точности, но и потери от ложного контекста вырастают вдвое, до 8 п.п. - Подмена условия задачи вредит сильнее всего. Псевдонаучные вставки почти не мешают: сохраняется около 98% точности. - Явное исправление ложной посылки растёт с размером модели. Но лучший показатель «исправила и довела до верного ответа» — 24,91% у Qwen3-235B. У 11 из 18 моделей он ниже 10%. - Удачные ответы отличаются частыми пересмотрами позиции по ходу рассуждения: индекс 0,63 против 0,18 у неудачных.
Удивило то, что рост способностей не защищает. Практический вывод: нельзя полагаться на то, что сильная модель поймает ошибку в данных от предыдущего шага.
Адаптации и экстраполяции
⚠️ Это не из статьи, а мои идеи по мотивам. Они не проверены.
🔧 Техника: добавить явный шаг проверки посылок → вынудить модель заметить конфликт
Авторы показали, что исправление чаще получается, когда модель длиннее рассуждает и пересматривает позицию. Можно попробовать в начале системного промпта этапа добавить такое:
Перед ответом выпиши все входные данные, которые тебе передали, и сверь каждое с проверенными данными ниже. Если находишь расхождение — остановись и укажи его, не продолжай работу.
Проверенные данные: {эталон}
Входные данные от предыдущего шага: {вход}
Идея в том, чтобы заставить модель сделать «сверку» отдельным шагом, а не рассчитывать, что она сама заметит подвох в ходе основной работы. Эффект на практике нужно проверять тестом из шаблона выше.
🔧 Техника: тестируй этапы цепочки на «подмену условия», а не на «странные факты»
Из статьи следует: самый вредный тип ошибки — искажение конкретного условия (цифры, статусы, параметры). Модели легко отмахиваются от очевидно нелепых вставок. Тестируй пайплайн на правдоподобных искажениях.
Ресурсы
- PHRBench: A Behavioral Evaluation of Post-Hallucination Reasoning in LLMs — Linghao Meng, Feng He, Xuan Yang, Junyuan Mao, Pinze Ren, Deqing Mu, Hesen Yang, Qiankun Li
- Университеты: National University of Singapore, Tsinghua University, Johns Hopkins University, Nanyang Technological University
- Код: github.com/menglinghao2025/PHR
- Датасет: huggingface.co/datasets/menglinghao2025/PHR
- Страница проекта: menglinghao2025.github.io/PHR
- Предшествующая работа: HIVE (He et al., 2026)