TL;DR
LLM склонна отвергать правильные определения, критикуя и находя проблемы даже там, где их нет. Эта склонность — rejection bias — означает, что когда модель говорит «это неправильно», она частично фабрикует причины для критики, а не честно оценивает.
Это неочевидно. Казалось бы, модель должна хорошо узнавать правильные вещи — она же обучена на корректных текстах. Но оказывается: LLM значительно лучше замечает поддельные/неверные определения, чем принимает правильные. Модель «ищет, к чему придраться» — и находит, даже когда всё верно.
Практический вывод: не используй LLM как бинарный валидатор формулировок, определений, описаний требований. Если попросить «это правильно или нет?» — модель скорее скажет «нет» и придумает причину. Вместо этого используй двухшаговую проверку: сначала попроси модель аргументировать в защиту формулировки, потом — найти реальные слабости.
Схема метода
Исследование описывает поведенческую ловушку, а не готовую технику. Из неё вытекает конкретный приём — Steel-Man Validation:
ШАГ 1: Стил-мэн → попроси модель аргументировать ПОЧЕМУ формулировка правильна
Вывод: список сильных сторон определения
ШАГ 2: Критика → попроси найти реальные пробелы или неточности
Вывод: список конкретных замечаний с обоснованием
(Оба шага — в одном промпте или двух запросах подряд)
Пример применения
Задача: Ты пишешь техническое задание для разработчиков. Хочешь проверить, чётко ли сформулировано требование — нет ли двусмысленности или пропущенных ограничений.
Промпт:
Я хочу проверить точность этого требования:
"{текст формулировки}"
Сделай это в два шага:
1. ЗАЩИТА: Объясни, что эта формулировка делает правильно.
Что в ней точно, полно и однозначно?
Почему разработчик поймёт её верно?
2. КРИТИКА: Теперь найди реальные слабости.
Что пропущено? Где возможна двусмысленность?
Какой крайний случай не учтён?
Разделяй шаги явно. Не смешивай.
Результат: Модель сначала сформулирует, что формулировка делает хорошо — это «обнуляет» rejection bias и заставляет её честно искать сильные стороны. Затем в блоке критики замечания будут более точными и обоснованными — меньше выдуманных проблем, больше реальных пробелов. Ты получишь сбалансированную оценку, а не автоматическое «здесь неточно».
Почему это работает
Слабость LLM: Когда задаёшь бинарный вопрос «правильно или нет?» — модель входит в режим поиска ошибок. Она обучена на огромном массиве текстов, включая форумы где люди спорят, исправляют, критикуют. Этот паттерн «найди проблему» становится доминирующим при валидирующих запросах.
Что происходит на практике: Модель генерирует критику, потом подбирает под неё объяснение — а не наоборот. Исследование это зафиксировало буквально: LLM отвергает правильные определения и придумывает причины. Это как ревьюер, который решил «нет» ещё до прочтения — и потом ищет, чем обосновать.
Как двухшаговый подход ломает этот паттерн: Принудительная защита на первом шаге меняет «режим» модели. Она сначала генерирует паттерн принятия и обоснования — и после этого критика во втором шаге становится более точечной. Модель уже не может быть огульно критичной: она только что сама написала, что здесь правильно.
Рычаги управления промптом: - «Не смешивай шаги» → без этого модель съедет в критику сразу, на первом же шаге - Явные заголовки ЗАЩИТА / КРИТИКА → сигнализируют модели о смене режима - Добавь «приведи конкретный пример края, где это сломается» → фокусирует критику на реальных проблемах, а не на стилистике - Убери ШАГ 1 совсем → получишь обычный rejection bias в чистом виде, полезно для сравнения
Шаблон промпта
Проверь точность этой формулировки:
"{формулировка}"
Два шага:
1. ЗАЩИТА
Что здесь сделано правильно? Что точно, полно, однозначно?
Почему {целевая аудитория} поймёт это верно?
2. КРИТИКА
Что пропущено или неточно?
Где возможна двусмысленность?
Приведи конкретный пример ситуации, где формулировка даст сбой.
Шаги — отдельно. Без смешивания.
Плейсхолдеры:
- {формулировка} — ваше определение, требование, условие договора, описание фичи
- {целевая аудитория} — кто будет читать: разработчик, клиент, юрист, пользователь
🚀 Быстрый старт — вставь в чат:
Вот шаблон двухшаговой проверки формулировок.
Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит что именно проверять и кто целевой читатель — потому что без этого второй шаг (критика) будет слишком общим и не попадёт в реальные риски.
Почему это важно за пределами SE
Rejection bias — не специфика технической терминологии. Вот где он проявляется в обычной работе:
- Договорные формулировки → попросил проверить пункт, LLM найдёт «проблему» даже в стандартном условии
- Описание вакансии → проверяешь требование к кандидату — получаешь критику стиля вместо анализа полноты
- Бриф клиенту → просишь «всё точно?» — придёт список правок, половина из которых выдуманная
- Любой чеклист или критерий приёмки → бинарный «да/нет» запускает режим придирок
Во всех этих случаях двухшаговый подход даёт более честный результат.
Ограничения
⚠️ Reasoning-режим не помогает, иногда вредит: Включение расширенного рассуждения (например, o3, Opus с extended thinking) не снижает rejection bias систематически. Часть моделей начинает «перемудрять» — и отвергает правильное с ещё большей уверенностью.
⚠️ Метод работает для проверяемых формулировок: Если критерий правильности субъективен (стиль, тон, «нравится ли покупателю») — двухшаговая схема не помогает. Нужен чёткий стандарт: договор, техническое требование, описание с известным правильным ответом.
⚠️ Разные модели — разный перекос в сторону: Большинство моделей страдает over-rejection (всё плохо). Claude Opus 4.6 показал обратную картину — over-acceptance (принимал даже подделки). Учитывай это при выборе инструмента для валидации.
Как исследовали
Команда взяла официальный стандарт ISO 24765 — 5 381 определение из области разработки ПО, самый авторитетный источник SE-терминологии. Из каждого определения сделали подделку двумя способами: структурная — убрали уточняющую фразу (определение осталось грамматически правильным, но потеряло критичный смысл); семантическая — заменили ключевые слова на похожие, но неверные (вместо «terms» — «relation», вместо «knowledge» — «aspects»). Получилось 4 618 пар: правильное + подделка.
Каждое определение показали шести моделям с простым промптом: «Это определение правильное? True/False + объяснение». Ожидали, что модели хорошо распознают правильные вещи и плохо — тонкие подделки. Получили ровно противоположное. Почти все модели точнее выявляли подделки, чем принимали правильное. Логика простая: интернет полон споров и исправлений — модель обучена «искать проблему», а не «подтверждать правильность».
Потом вручную разобрали 1 200 объяснений (по 200 на модель) и нашли закономерность: при неправильных ответах модели либо придумывали проблему с нуля, либо замечали несоответствие, но всё равно принимали («ну, в каком-то смысле это и так можно понять»). Это показало, что проблема не в знаниях модели — а в паттерне поведения при валидирующих запросах.
Адаптации и экстраполяции
🔧 Техника: явный арбитраж → снижение fabricated critique
Добавь третий шаг — попроси модель оценить насколько критика из шага 2 реально меняет смысл, а не просто стилистическая придирка:
3. АРБИТРАЖ Из замечаний в Критике — какие меняют смысл принципиально? Какие — просто о стиле или незначительны? Оцени: нужно ли переписывать?Это отсекает «шум» из rejection bias — оставляет только содержательные замечания.
🔧 Техника: обратная проверка → поймать LLM на противоречии
Если модель сказала, что формулировка неверна — дай ей другой запрос:
Предположи, что эта формулировка написана экспертом и намеренно точная. Как её правильно интерпретировать?Если модель легко «принимает» ту же формулировку в таком контексте — первый отказ был именно rejection bias, не реальной проблемой.
Ресурсы
Large Language Models Have Unreliable Understanding of Software Engineering Terminology Huzaifa Ejaz, Fabian C. Peña, Steffen Herbold University of Passau, Faculty of Computer Science and Mathematics, Passau, Germany ISO/IEC/IEEE 24765:2017 Systems and Software Engineering — Vocabulary (стандарт-основа исследования)