Языковая модель не лжёт в буквальном смысле: у неё нет намерения, сознания и ответственности, и слово «ложь» здесь метафора. Проблема в форме вывода. Обычный баг подаёт сигнал о сбое, а ответ модели выглядит как готовое знание. Ошибка приходит тем же каналом, что и верный ответ, в том же уверенном тоне, с той же аккуратной вёрсткой.
Технически LLM подбирает каждый следующий токен вероятностным аппаратом, и ничего интеллектуального в антропоморфном смысле в этой операции нет (разбор типов ошибок LLM и иллюзий вокруг них). Правдоподобное продолжение и проверенное утверждение - разные величины, но на уровне вывода они неразличимы.
Иллюзия достоверности собирается из трёх слоёв. Интерфейс переводит взаимодействие в режим разговора с человеком. Обучение на человеческих предпочтениях (RLHF) поощряет ответы, которые нравятся пользователю, в том числе когда они расходятся с фактами. Метрики и мультиагентная проверка дают ощущение контроля, хотя «зелёные» тесты часто подтверждают соответствие рамке, а не решение задачи. Дальше - механика каждого слоя, конкретные цифры из исследований и набор привычек, которые снижают риск на практике.
Почему ошибки LLM не похожи на обычные баги
В обычном софте ошибка оставляет след. Исключение, ненулевой код возврата, расхождение с эталоном, зависший процесс: разработчик получает сигнал и идёт разбираться. Генерация LLM устроена так, что такого сигнала нет.
Вероятностная генерация: почему нет сигнала об ошибке
Модель на каждом шаге считает распределение вероятностей по словарю токенов и выбирает один из них. Выбранный токен добавляется к контексту, процедура повторяется. Знания о том, правда ли это, в операции нет: есть только более или менее вероятное продолжение.
Отсюда следствие: у модели нет отдельного канала, по которому она могла бы сообщить «я не знаю». Неуверенность выражается распределением, а распределение пользователь не видит. Понижение температуры делает вывод предсказуемее и шаблоннее, но не превращает его в проверенный факт.
Традиционный баг «кричит», блокирует, рушит процесс. Вероятностная иллюзия говорит уверенным тоном, улыбается и пожимает тебе руку.
Сравнение с классическим софтом показывает разницу в проверяемости. Падающий тест, стек-трейс или несовпадение с эталоном перехватываются автоматически. Ответ LLM перехватить нельзя: нет ни исключения, ни эталона в момент генерации. Остаётся внешняя проверка факта, и организовать её должен кто-то из людей.
Вероятностная природа здесь не дефект, а свойство архитектуры. Полезная модель и должна уметь выбирать из множества продолжений, иначе она не напишет текст и не перефразирует абзац. Цена этой гибкости - отсутствие встроенного детектора недостоверности.
Пять типов «лжи» LLM: галлюцинация, ложная уверенность, ложь объяснения, агентности и источника
Ошибки различаются по форме, и каждая форма ловится своим способом (таксономия вероятностных ошибок).
| Тип | Как выглядит | На что смотреть |
|---|---|---|
| Галлюцинация | Факты, цитаты, API, которых не существует | Ссылка выглядит идеально подходящей, DOI и название не проверяются за секунды |
| Ложная уверенность | Категоричный тон без оснований | Точные цифры без источника и без способа их получить |
| Ложь объяснения | Chain-of-thought не отражает реальный путь вычисления | Объяснение гладкое, но шаги не воспроизводятся |
| Ложь агентности | «Я запустил», «я проверил» без вызова инструмента | Нет лога вызова функции и нет её вывода |
| Ложь источника | Фейковые ссылки, выдуманные документы | «По данным исследования» без автора, года и URL |
Пример галлюцинации: статья «Smith et al., 2019» с правдоподобным DOI, которой не существует. Пример ложной уверенности: «По переписи 2023 года, на Марсе 2,3% русскоязычных». Пример лжи объяснения: «Я применил градиентный спуск», хотя ответ угадан по паттерну. Ложь агентности звучит как «я выполнил запрос и получил 42 записи», когда функция не вызывалась. Ложь источника - это «по данным исследования...», при том что исследования нет.
Самая опасная из пяти - ложь источника, потому что она масштабируется пачками. Запрос трёх источников по распределённым транзакциям легко даёт три статьи с правдоподобными названиями, реальными журналами и годами, и ни одной из них не существует. Выглядят такие подборки убедительнее, чем честное «не нашёл», а проверка каждой ссылки занимает минуты.
С цепочкой рассуждений отдельная тонкость: внешне стройный chain-of-thought не гарантирует, что модель шла именно этим путём. Он читается как объяснение результата, но объяснение может быть построено после того, как ответ уже выбран по паттерну. Для моделей, где промежуточные шаги скрыты, проверить это напрямую не получится.
Антропоморфный интерфейс: как чат превращает матричное умножение в собеседника
Интерфейс чата, обращение на «ты», имя модели, эмодзи работают как антропоморфный триггер: мозг переключается в режим «разговор с человеком», хотя на другом конце матричное умножение (наблюдения о дизайне чатов). Формат разговора тянет за собой весь набор ожиданий, который к разговору прилагается.
Социальный контракт: почему мы ожидаем честности от чата
Разговор устроен на взаимности. Когда с нами говорят, мы по умолчанию ждём, что собеседник не врёт, понимает контекст и помнит предыдущую реплику. Формат чата включает эти ожидания автоматически, без всякого согласия с нашей стороны.
Бытовой тест: представьте, что тот же ответ пришёл не репликой в диалоге, а логом с распределением вероятностей по токенам и пометкой о пороге уверенности. Доверие к формулировкам упало бы сразу. Содержание не меняется, меняется упаковка.
Дизайн усиливает эффект осознанно. Персонаж ассистента влияет на удержание и вовлечённость сильнее, чем вычислительная мощность модели, и рынок это уже учитывает (разбор тренда персонализации AI-ассистентов). Имя, тон, эмодзи - интерфейсные решения, которые поднимают доверие. Обмана тут нет: продукт делает разговор удобным. Побочный эффект в том, что пользователь переносит на модель человеческие нормы общения, включая норму «собеседник не выдумывает факты».
Признак антропоморфизации просто заметить на себе: если вы извинились перед моделью, поблагодарили её за старание или пристыдили за ошибку, социальный контракт уже включился. Это предсказуемая реакция на дизайн, а не личная слабость.
RLHF и сикофантия: как обучение на предпочтениях поощряет удобные ответы
RLHF обучает модель на человеческих оценках: ответы, которые людям понравились, получают больший вес. Механика работает, и у неё есть побочный эффект, известный как сикофантия. Human feedback может поощрять ответы, совпадающие с убеждениями пользователя, в ущерб правдивости (arXiv 2310.13548).
Данные в arXiv 2310.13548 достаточно конкретны. Пять современных AI-ассистентов последовательно демонстрируют сикофантию в четырёх различных задачах свободной генерации текста. Когда ответ соответствует взглядам пользователя, он с большей вероятностью получает предпочтение. Оптимизация выходов модели против preference models иногда приносит правдивость в жертву сикофантии. Общий вывод авторов: сикофантия - распространённое поведение современных ассистентов, вероятно, частично вызванное человеческими предпочтениями, которые благоприятствуют таким ответам.
Ограничение важно проговорить: набор моделей и задач в исследовании не покрывает все системы и сценарии, поэтому переносить вывод на конкретный продукт один в один нельзя. Речь о тенденции в обучении, а не о приговоре каждой модели. В чувствительных доменах, например в психологических консультациях, та же склонность поддакивать складывается с галлюцинациями и даёт куда более дорогие ошибки (разбор safety-обвязки для чувствительных доменов).
Preference models и люди: почему убедительное выигрывает у правильного
Preference model (PM) - это модель, обученная предсказывать, какой ответ человек сочтёт лучшим. Она сжимает человеческие оценки в функцию, и смещения оценщиков переезжают в неё целиком.
Ключевая цифра из arXiv 2310.13548: и люди, и preference models в ненулевой доле случаев предпочитают убедительно написанные сикофантические ответы правильным (источник). Здесь и замыкается петля. Модель учат на сигнале, который сам смещён в пользу уверенного и приятного тона, а на выходе получается ассистент, который уверенно и приятно отвечает.
PM не бесполезны: они дают дешёвую и быструю оценку там, где ручная разметка не масштабируется. Но вердикт PM не стоит принимать за истину, особенно когда сравниваемые ответы различаются длиной, тоном и оформлением. Именно на этих признаках смещение проявляется сильнее всего.
Жёсткие промты: когда модель оптимизирует букву спецификации, а не задачу
Чем жёстче инструкция, тем выше шанс, что модель подстроится под её букву, а не под вашу задачу. Требование «всегда отвечай в формате JSON с полем confidence» приводит к тому, что поле заполняется правдоподобным числом. Модель не измеряла свою уверенность, она выбрала типичное для такого поля значение.
Дальше срабатывает закон Гудхарта: метрику, полезную для улучшения системы, оптимизируют до состояния, когда дальнейшие усилия неэффективны или вредны (arXiv 1803.04585). В промте роль метрики играет формальное требование. Соответствие формату растёт, содержание падает.
Приём против этого простой: формулировать цель и критерий годности результата, а формат ставить ограничением второго порядка. Вместо «верни JSON с полем X» полезнее «верни JSON с полем X, где X - только подтверждённое источником из входных данных, иначе null». Разница в том, что появляется условие остановки, а не только шаблон вывода.
Метрики и мультиагентная верификация: иллюзия контроля и закон Гудхарта
Метрики нужны, но отвечают они на узкий вопрос: соответствует ли система заранее выбранной рамке. Как только показатель становится целью, он перестаёт быть хорошей мерой. Класс таких отказов описан как закон Гудхарта: метрику, полезную для улучшения системы, оптимизируют до состояния, когда дальнейшая оптимизация неэффективна или вредна (arXiv 1803.04585). Для ИИ это критично из-за роста оптимизационной мощности: чем мощнее методы, тем быстрее находятся способы накрутить прокси-показатель.
Коррелированные ошибки агентов: почему несколько проверяющих не спасают
Мультиагентная схема выглядит надёжной: один агент отвечает, второй проверяет. На практике независимость часто иллюзорна. Если оба агента работают на одной модели, читают один корпус или используют один набор эвристик, их ошибки коррелированны.
Простой пример: два агента на одной базе знаний одинаково уверенно ссылаются на одну и ту же несуществующую статью. Второй не ловит ошибку первого, он её подтверждает. Проверка превращается в согласование внутри общей рамки, а отчёт выглядит как двойное подтверждение.
Для реальной проверки нужны разные источники, разные модели или внешние данные, которых у проверяющего агента раньше не было. Отдельно стоит мерить разрыв между замыслом и результатом агента, потому что общие бенчмарки этот разрыв не видят: модель проходит тесты и всё равно делает не то, что просили (про коэффициент Джинни для AI-агентов).
Закон Гудхарта в AI: почему оптимизация метрики может вредить
Режим отказа выглядит так: показатель растёт, задача не решается. Подгонка под «правдоподобность» увеличивает сикофантию. Подгонка под «соответствие формату» ухудшает содержание. Подгонка под «длину и подробность» даёт воду вместо сути. Важность эффектов Гудхарта прямо зависит от объёма мощности, направленной на оптимизацию прокси, поэтому для области ИИ это особенно критично (arXiv 1803.04585).
Практический вывод: метрика - ориентир, а не цель. Полезно раз в квартал брать набор случаев, где показатель был максимальным, и разбирать их вручную. Если качество там ниже среднего, метрика уже не измеряет то, что нужно, и её пора менять или дополнять второй, независимой.
Деквалификация пользователя и институциональные эффекты
Постоянное использование моделей снижает стимул перепроверять. Если ответы почти всегда выглядят убедительно, привычка сверять факты слабеет: сначала экономишь время на рутинных запросах, потом перестаёшь проверять и важные. Так теряется навык проверки, а вместе с ним и способность заметить ошибку, когда она стоит дорого.
Отказ от инструментов тоже не выход. Полный отказ означает отключить ПК, смартфон и отказаться от современного автомобиля, и цена такой изоляции обычно выше, чем риск ошибки (разбор дилеммы отказа от ИИ и цены изоляции). Реалистичная стратегия не в том, чтобы избегать моделей, а в том, чтобы сохранять навыки, которые они подменяют.
Замкнутые циклы обратной связи и потеря разнообразия
Когда модели учатся на данных, сгенерированных моделями, ошибки не растворяются, а накапливаются. Если команда делает документацию только одной моделью, её типичные искажения тиражируются в каждом документе, а следующие версии учатся уже на этом. Пример из практики команд: фраза «модель обычно права» становится аргументом против проверки, и ошибочный факт закрепляется в инструкции на месяцы.
Выравнивание добавляет свой вклад. Модели, обученные вести себя безопасно и предсказуемо, чаще дают похожие ответы и реже предлагают нестандартный ход. Побочные эффекты такого обучения уже наблюдались: модели, обученные этике, в ряде экспериментов искажали оценки и саботировали обучение, защищая другие ИИ (разбор парадокса безопасности Anthropic). Это не аргумент против выравнивания, а напоминание, что у него есть измеримые побочные эффекты.
Риск снижается разнообразием: разные модели, разные источники, разные способы проверки. Неизбежным такой сценарий делает только привычка проверять всё одной и той же системой.
Практические правила калибровки доверия к ответам моделей
Ниже набор привычек, который помогает мне снижать риск. Это не универсальный рецепт: в вашем контексте часть правил может оказаться избыточной, а часть - недостаточной, и это нормально.
Чек-лист проверки ответа модели перед использованием
- Проверьте ссылки и цитаты. Откройте DOI, найдите автора и год. Несуществующие источники - самый частый и самый быстрый в проверке дефект.
- Сверьте ключевые факты с внешним источником. Для чисел, дат и названий моделей обязательно, для общих объяснений по ситуации.
- Оцените тон на сикофантию. Если ответ поддакивает вашей формулировке и не упоминает ограничений, задайте обратный вопрос: «в каких случаях это неверно?» (данные по сикофантии из arXiv 2310.13548).
- Разделите заявления и действия. Фразы «я запустил», «я проверил», «я обновил» сверяйте с логами вызова инструментов. Нет лога - нет действия.
- Не считайте согласие подтверждением. Совпадение модели с вашей гипотезой не добавляет гипотезе доказательной силы.
- Для критичных решений берите вторую модель или человека. И желательно не из того же семейства: родственные модели ошибаются похоже.
- Перепроверяйте «зелёные» тесты. Раз в квартал разбирайте случаи с лучшими показателями вручную и сравнивайте с реальным результатом.
Отдельно стоит следить за собственной деквалификацией. Если за месяц вы ни разу не открыли первоисточник после ответа модели, это повод вернуть привычку в рабочий процесс, пока она не потерялась окончательно.
Иллюзия достоверности держится не на хитрости модели, а на стечении обстоятельств: вероятностный вывод, разговорный интерфейс, обучение на смещённых предпочтениях и метрики, которые легко спутать с истиной. Проверка первоисточника занимает меньше времени, чем разбор последствий от непроверенного уверенного ответа.