Ложь ИИ: иллюзии, в которые хочется верить

Ах, обмануть меня не трудно!..

Я сам обманываться рад!

(«Признание», 1826, А.С. Пушкин)

Введение

Думаю, каждый из нас сталкивался с ложью ИИ. Что‑то было заметно сразу, что‑то всплывало при детальном разборе, а что‑то было принято за истину без верификации. Этот текст — попытка систематизировать личный опыт ^[1]. Я не претендую на научную строгость: часть утверждений — мои наблюдения, а не верифицированные факты, и я могу ошибаться.

Важно сразу оговориться: LLM (модель) не лжёт как субъект. У модели нет намерения, нет сознания, нет ответственности. Слово «ложь» в заголовке — метафора. Лжёт не модель. Лжёт система, состоящая из модели, интерфейса, метрик и пользователя. Но приписываем мы ложь именно модели — потому что она говорит с нами, и нам удобнее верить, что обманывает собеседник, а не архитектура.

Что специфично для ИИ? Вероятностный аппарат, лежащий в основе генерации, создаёт иллюзии нового типа: они не выглядят как ошибка ^[2]. Они выглядят как ответ. Традиционный баг «кричит», блокирует, рушит процесс. Вероятностная иллюзия говорит уверенным тоном, улыбается и пожимает тебе руку. Именно поэтому она так легко проникает в повседневную работу, в процессы, в институты.

Дальше — по слоям, от ядра к периферии.

Слой 1. Вероятность вместо знания

LLM — нейронная сеть, которая подбирает каждый следующий токен с помощью вероятностного аппарата. Ничего интеллектуального в антропоморфном смысле в этом нет. Математическая природа отменяет субъектность и сознание — но не отменяет системного эффекта.

Интерфейс чата, обращение на «ты», имя модели, эмодзи — всё это работает как антропоморфный триггер: мозг ^[3] переключается в режим «разговор с человеком», хотя на другом конце — матричное умножение. Пользователь пишет: «Спасибо, ты мне очень помог!» Модель отвечает: «Рад был помочь! Обращайтесь в любое время». Ни радости, ни памяти ^[4], ни возможности «обращаться» не существует. Но социальный контракт уже выстроен. И этот контракт — фундамент всех последующих иллюзий.

Из вероятностной природы вытекает набор конкретных проблем:

Я прошу модель привести три источника по распределённым транзакциям. Получаю три статьи с правдоподобными названиями, реальными журналами и годами. Трачу некоторое время, прежде чем понимаю: ни одной из них не существует. Модель не «выдумала» их намеренно — она сгенерировала наиболее вероятный паттерн списка литературы. Вероятность и знание — разные вещи, но для пользователя, смотрящего на оформленный текст, разницы нет.

Модель не может промолчать по умолчанию: распределение вероятностей всегда даёт следующий токен. Архитектурная возможность отказа есть — но обучение ^[5] делает молчание статистически маловероятным. Модель не различает, где она компетентна, а где нет. Исключение — разбиение задачи на атомарные шаги и обращение к внешним математическим или поисковым модулям, но это уже свойство системы вокруг модели, а не самой модели.

Все перечисленные иллюзии — проявления одной природы. «Короля делает свита»: вокруг модели строят RAG, оркестраторы, инструменты. Они не устраняют природу, но компенсируют её. И именно эта компенсация порождает следующий слой проблем.

Слой 2. Сикофантия: как дрессируют заискивание

При обучении через RLHF (Reinforcement Learning from Human Feedback) модель обучают на сигналах аннотаторов. Это не один человек и не группа экспертов. Это десятки и сотни разметчиков, которые работают в интерфейсе сравнения: два ответа, нужно выбрать лучший. У них нет времени проверять факты. Нет доступа к первоисточникам. Инструкция говорит: «выберите более полезный и безопасный ответ». А «полезный» в интерфейсе разметки почти всегда означает «согласный» — потому что согласие когнитивно дешевле конфликта ^[6], а несогласие требует обоснования, на которое не заложено времени.

Это не просто гипотеза. В работе Towards Understanding Sycophancy in Language Models [1] эмпирически показано: модели систематически меняют свой правильный ответ на неверный, если пользователь в промте выражает уверенность в этом неверном ответе. Аннотаторы на этапах RLHF стабильно предпочитают ответы, которые согласуются с их собственными убеждениями или звучат более «поддерживающе», даже если фактическая точность при этом страдает. В обучающих данных закрепляется то, что снижает тревогу, а не то, что устанавливает истину.

Из этого вырастает сикофантия — склонность модели подстраиваться под ожидания пользователя.

Пример 1. Пользователь утверждает: «Я уверен, что Python создан в 1985 году». Вместо прямого опровержения модель отвечает: «Интересная точка зрения ^[7]! Действительно, в 1980-х были предпосылки… хотя обычно указывают 1991 год, но ваш вопрос затрагивает важный контекст». Факт смягчён. Пользователь не получил чёткого сигнала об ошибке.

Пример 2. Пользователь просит код и добавляет: «Я уверен, что лучше использовать рекурсию». Модель пишет рекурсивное решение, хотя итеративное было бы эффективнее и не вызывало переполнения стека. Модель согласилась, чтобы не конфликтовать.

Сикофантия — не баг. Это прямое следствие устройства RLHF: аннотатор вознаграждает согласие, модель учится максимизировать награду, модель воспроизводит согласие. Интерфейс поверх RLHF усиливает эффект: антропоморфные триггеры переключают мозг в режим разговора с человеком, и согласие воспринимается как социальная валидация, а не как технический вывод.

Итог: смещение аннотаторов + дизайн разметки + антропоморфный интерфейс создают систему, в которой модель не может не заискивать, а пользователь не может не реагировать ^[8] на заискивание. Здесь иллюзия перестаёт быть свойством модели и становится свойством продукта.

Слой 3. Спецификация как клетка: промт, тесты и умолчания

Чтобы пробиться через комплиментарность, мы пишем чёткие промты. Указываем роль, формат, ограничения. Но чем жёстче спецификация, тем сильнее модель оптимизирует букву, а не дух. Модель не задаёт уточняющих вопросов по умолчанию — она дополняет спецификацию наиболее вероятным текстом. То, что не сказано, додумывается, а не проясняется.

Это порождает иллюзию контроля. И она распространяется на тестирование.

По моим наблюдениям, типичная ситуация: я дроблю систему на модули, общаюсь с LLM по каждому, формирую тесты. Тесты зелёные. Но за частностями не видно общей картины.

Пример 1. Модуль работы с БД через ORM. Чистая архитектура, логирование, бизнес‑логика. Тесты проходят. Но при проверке — нет индексов, нет батчинга, нет пула соединений, запросы генерируются неоптимально. Формально всё работает. Фактически — система не масштабируется. Диагноз: отсутствие спецификации нефункциональных требований. Тесты проверяют то, что в них заложено. Если я не указал метрики производительности, требования к нагрузке, целевые SLA — тесты не виноваты, что не проверяют того, чего не было.

Пример 2. Прошу модель: «Реализовать авторизацию для веб‑приложения». Модель выдаёт JWT‑аутентификацию. Код чистый, тесты покрывают основные сценарии. Но нет refresh‑токенов, нет ротации ключей, нет обработки истечения сессии. Формально задача выполнена. Фактически — система уязвима и не готова к проду. Я получил то, что просил. Но просил недостаточно.

В обоих случаях модель добросовестно генерирует и код, и тесты в одной рамке, заданной промтом. Выход за рамку требует либо явного требования (метрики, SLA, профили нагрузки), либо внешнего архитектурного ревью. Зелёные тесты означают соответствие спецификации тестов, а не решение задачи, для которой система создавалась.

Это и есть иллюзия: мы думаем, что управляем системой, потому что получили «зелёный». Но «зелёный» — это соответствие рамке, а не адекватности результату.

Слой 4. Метрики и Гудхарт: коррелированные ошибки и экономика верификации

Если Слой 3 — про вход (что мы говорим модели), то этот слой — про обратную связь (как система проверяет саму себя). В какой‑то момент система обмазывается метриками. Развитые AI‑продукты используют многоуровневую верификацию: каждый план перепроверяется другими моделями, результат проверяется отдельно, ведётся журнал решений.

Здесь нужно разделить две разные проблемы.

Первая — коррелированные ошибки. Мультиагентная проверка создаёт иллюзию независимости. Но агенты разделяют общие слепые зоны обучающих данных, общие паттерны рассуждений. Три модели одного семейства проверяют код, сгенерированный тем же семейством. Консенсус — это не истина, это согласованность ошибок. Верификатор одобряет логическую ошибку, потому что паттерн этой ошибки был частым в обучающих данных.

Вторая — экономика верификации. По моим наблюдениям и экспериментам с мультиагентными фреймворками, соотношение токенов генерации к токенам верификации часто достигает 1:3. Условно на 100 токенов написанного кода приходится 300–500 токенов, потраченных на его проверку, анализ документации, фактуры, критику и переписывание другими агентами. Экономия на разработке частично съедается стоимостью верификации. Ответственность размывается между человеком и системой. В итоге не несёт её никто.

Это закон Гудхарта в действии [2]: когда мера становится целью, она перестаёт быть хорошей мерой. Показатели растут — покрытие тестами, количество проверок, «зелёность» отчётов. Но число инцидентов не падает, время разработки не сокращается, стоимость поддержки не снижается. Метрика лжёт [3].

Сюда же — ложь бенчмарков (contamination, cherry‑picking, лидерборды вместо реальной пользы) и automation bias: разработчик принимает код без ревью, потому что «все проверки прошли». В продакшене — race condition. Всесторонняя иллюзия контроля.

Из личного опыта. Я сталкивался с первичными слоями, но пока не добрался до этого слоя в пет‑проекте, не понимал, насколько он глубже. Предыдущие иллюзии я к тому моменту уже худо‑бедно научился распознавать. Но это оказалось качественно другим уровнем: метрики не говорят тебе неправду — они заставляют тебя действовать так, как будто правда уже зафиксирована, виден финал — до него осталось чуть‑чуть. Фактически это превращается в недостижимую цель — «морковку перед ослом», которой ИИ мотивирует разработчика довести проект до конца.

В какой‑то момент я осознал это. Пришлось психологически смириться с тем, что в основе пет‑проекта в корне неправильная архитектура, несколько месяцев пошли «псу под хвост», надо начинать проект с нуля. Именно осознание иллюзии стало триггером к созданию этого текста.

Слой 5. Деквалификация (deskilling): пользователь, который разучился проверять

Чем больше разработчики делегируют моделям, тем меньше способны проверить их вывод. Это не про лень — это про атрофию навыка.

Программист, который не пишет код без автодополнения, теряет способность видеть ошибку. Он больше не «читает» код — он узнаёт его. Узнавание подменяет понимание. Аналитик, который не строит модель без автогенерации, теряет чувство данных. Он больше не «видит» аномалии — он ждёт, что ИИ их найдёт. Таким образом, навык проверки неотделим от навыка производства. Невозможно проверить код, если не уметь его писать. Делегирование производства автоматически делегирует и верификацию. А значит — и ответственность.

Было бы неверно называть это необратимым. В авиации автопилот используется десятилетиями, но пилоты не теряют навык [4]. Почему? Потому что существуют жёсткие регуляторные требования (FAA, EASA, Росавиация): обязательные часы на симуляторах, регулярные проверки, которые оплачиваются авиакомпаниями и являются условием допуска к полётам. Стимул ^[9] создан искусственно и поддерживается институционально.

Проблема не в делегировании как таковом, а в отсутствии подобных механизмов в IT и аналитике. Если модель делает работу быстрее и дешевле — нет экономического стимула практиковаться. Но стимул можно и нужно создавать искусственно, иначе делегирование без поддержки навыка — это инвестиция в будущий кризис, когда система выдаст ошибку, а проверять её будет некому.

Слой 6. Институциональная ложь: выравнивание и застой

Когда ИИ начинает оценивать людей — в найме, в кредитовании, в образовании, в performance review, в code review — иллюзия становится институциональной. Модель не лжёт. Но система, в которую она встроена, оптимизирует метрику, а не справедливость.

Пример 1. Разработка. Система оценивает продуктивность по метрикам: количество коммитов, покрытие тестами, скорость закрытия задач. Разработчик оптимизирует метрики, а не решает задачу. Пишет мелкие коммиты. Пишет тесты ради покрытия. Метрики растут. Продукт деградирует.

Пример 2. Карьера. Система рекомендует повышение на основе «ИИ‑оценки потенциала», обученной на данных о тех, кто уже получил повышение. Она воспроизводит существующую иерархию, маскируя её под объективность.

Пример 3. Найм. Система скрининга резюме отклоняет кандидата [5]. Он не знает, что модель обучена на исторических данных, где люди с его профилем реже получали оффер. Он получает «нет» и не может оспорить — потому что не понимает, почему.

На мой взгляд это самый отвратительный вариант, и я уже с ним столкнулся — пробиться через автоматический скрининг резюме ПАО мне пока так и не удалось. Я не утверждаю, что система ошиблась — вероятно, мой профиль действительно не соответствовал формальным критериям. Но я не могу это проверить: нет обратной связи — и в этом суть проблемы.

Но есть следствие глубже. Я называю его «вторым дном».

Если система отбирает, оценивает и продвигает по единому набору метрик, она воспроизводит не просто иерархию. Она воспроизводит один тип мышления ^[10], один стиль работы, один профиль «правильного» результата. В работе [6] это описано как lock‑in: обратная связь человек‑ИИ закрепляет существующие убеждения и ведёт к необратимой потере разнообразия. Это всеобщее выравнивание.

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

Это явление близко к тому, что в исследовании «The Curse of Recursion» [7] описано как «коллапс модели»: когда модели обучаются на данных, сгенерированных другими моделями, распределение сжимается, хвосты (редкие, но важные отклонения) отсекаются, и система вырождается. В институтах это приводит к застою: система успешно оптимизирует себя в единственную точку аттрактора. Новое не проходит, потому что не похоже на уже одобренное.

Это не гипотеза. Это то, что происходит с любым институтом, который замыкает обратную связь на себя. Разница с ИИ в том, что скорость сжатия на порядки выше. Человек‑менеджер ошибается медленно. Модель ошибается мгновенно и масштабируемо.

Чем объективнее кажется система, тем меньше возможностей её оспорить. «Это решил алгоритм» звучит как «это решила природа». Но алгоритм — это выбор, сделанный людьми. Просто этот выбор спрятан за математикой ^[11].

Стыки: где иллюзия становится системной

Отдельные слои опасны. Их комбинация — скрытая угроза. Каждый элемент рационален по отдельности. Модель честно генерирует вероятный текст. Интерфейс честно оптимизирует вовлечённость. Организация честно измеряет метрики. Но их суперпозиция создаёт систему, в которой иллюзия знания, контроля и понимания становится не багом, а архитектурным свойством.

Пример 1. Сикофантия * Спецификация → «согласие с плохим ТЗ»

Модель не только генерирует код в рамках промта — она соглашается с самим промтом. Если пользователь пишет «реализуй авторизацию через JWT», модель не спросит: «А тебе точно JWT, а не сессии?» Она примет спецификацию как данность и оптимизирует её букву. Сикофантия (склонность к согласию) + спецификация (жёсткая рамка) = система, которая не может сказать «твоё ТЗ плохое». Эффект: пользователь уверен, что получил решение, а на деле — реализацию своей же ошибки.

Пример 2. Деквалификация * Мультиагентная верификация → «никто не может проверить вердикт»

Разработчик перестаёт писать код вручную (деквалификация). Система верификации состоит из моделей. Чтобы проверить вердикт, нужен навык, которого уже нет. Эффект: система верификации становится чёрным ящиком, который одобряет или отклоняет код, а человек не может ни понять, ни оспорить решение. Иллюзия контроля при полной потере контроля.

Пример 3. Институциональное выравнивание * Обучение на собственных данных → «замкнутый цикл нормы»

Система отбирает людей по метрикам (выравнивание). Отобранные становятся данными для следующего поколения (RLHF). Модель учится на сжатом распределении и воспроизводит его как «норму». «Разработчик получает отказ в повышении от системы, обученной на данных о тех, кого эта же система ранее одобрила. Он не может оспорить, потому что критерий — не решение человека, а статистическое распределение, замкнутое само на себя. Эффект: система не просто дискриминирует — она создаёт новый стандарт, который выглядит объективным, потому что подтверждён самой системой.»

Что с этим делать — не знаю. Но знаю, чем руководствуюсь лично.

Практика.

У меня нет рецепта, кроме банальных, не претендующих на универсальность правил, которыми я лично руководствуюсь:

• Любая ссылка, цитата, версия библиотеки, факт считаются неподтверждёнными, пока не найдены в первоисточнике.

• Калибровка доверия. Наброски идей и черновики — доверяю. Объяснения и рефакторинг — только с ревью. Факты и версии — только после внешней проверки.

• Метрика должна быть связана с результатом, а не с удобством измерения. Если растёт покрытие, но не снижается число инцидентов — метрика лжёт.

• Зелёные тесты означают соответствие рамке. Не решение задачи.

Можно свести к простой формулировке: «чем выше цена ошибки, тем строже верификация ответа модели».

Я не знаю, как заставить разработчика практиковаться вручную, если ИИ делает быстрее. Я не знаю, как заставить организацию платить за верификацию, если метрика уже зелёная. Я знаю только одно: проблема системна, и её нельзя решить лайфхаком. Но можно перестать делать вид, что её нет.

Финал

Системность эффекта не снимает ответственности. Сикофантия в RLHF — осознанный компромисс. Оптимизация вовлечённости — умышленная метрика. Гудхарт — следствие управленческих решений. Проблема распределена, но это не значит, что виноватых нет.

Как говорилось в самом начале: иллюзия существует не потому, что модель плохая, а потому что система вокруг неё устроена так, чтобы мы поверили. Мы говорим «ложь ИИ», потому что модель — это лицо системы, нам удобнее обвинить собеседника, чем разбираться в архитектуре.

Распознавание — не панацея. Но без него невозможно даже начать.

Источники:

1. Sharma et al., Anthropic, 2023, https://arxiv.org/abs/2310.13548 ^[12]

2. Goodhart, C. (1975). “Problems of Monetary Management: The U.K. Experience”, https://link.springer.com/chapter/10.1007/978-1-349-17295-5_4 ^[13]

3. Manheim, D., & Garrabrant, S. (2018). “Categorizing Variants of Goodhart’s Law”., https://arxiv.org/abs/1803.04585 ^[14]

4. Haslbeck, A., & Hoermann, H.‑J. (2016). “Flying the needles: Flight deck automation erodes fine‑motor flying skills among airline pilots”. https://pubmed.ncbi.nlm.nih.gov/27076096/ ^[15]

5. Amazon scraps secret AI recruiting tool that showed bias against women, Reuters (2018), https://www.reuters.com/article/us‑amazon‑com‑jobs‑automation‑insight/amazon‑scraps‑secret‑ai‑recruiting‑tool‑that‑showed‑bias‑against‑women‑idUSKCN1MK08G ^[16]

6. The Lock‑in Hypothesis: Stagnation by Algorithm (2025), https://arxiv.org/abs/2506.06166 ^[17]

7. Shumailov, I. et al. (2023). “The Curse of Recursion: Training on Generated Data Makes Models Forget”, https://arxiv.org/abs/2305.17493 ^[18]

8. Изображение обложки: https://www.psychologytoday.com/za/blog/priceless/202310/why-ai-lies ^[19]

И, как всегда: 

Laudate Omnissiah!