OpenAI опубликовала исследовательский материал Why language models hallucinate, в котором объясняет, почему современные языковые модели продолжают уверенно выдавать неверные факты. Страница опубликована 5 сентября 2025 года: https://openai.com/index/why-language-models-hallucinate
Главный акцент в материале сделан не на очередном «сбое» отдельной модели, а на системной причине: популярные способы оценки LLM могут подталкивать модели к угадыванию. Если тест засчитывает только правильный ответ и не различает честное «не знаю» и ошибку, модель получает стимул отвечать даже тогда, когда надежных данных у нее нет.
Для разработчиков AI-продуктов это практический сигнал. Галлюцинации нельзя рассматривать только как проблему промпта или температуры генерации. Если метрики качества внутри команды поощряют полный, уверенный и быстрый ответ, но не штрафуют за ложную уверенность, продукт будет выглядеть лучше в демо и хуже в реальных сценариях: поддержке клиентов, юридических черновиках, аналитике, медицинских справках, финансовых отчетах и внутренних корпоративных поисках.
Галлюцинация как следствие обучения на правдоподобный текст
Языковые модели обучаются предсказывать следующий фрагмент текста на основе статистических закономерностей в данных. Такой подход хорошо работает для связности, стиля и обобщения, но сам по себе не гарантирует фактическую истинность. Модель может построить грамматически безупречный ответ, который выглядит убедительно, но содержит вымышленные детали, неверные даты, несуществующие ссылки или приписанные людям утверждения.
OpenAI в новом материале связывает это с ситуациями неопределенности. Когда вопрос допускает несколько трактовок, касается редкого факта или выходит за пределы надежно усвоенной информации, модель может не остановиться. Вместо отказа она продолжает генерировать наиболее вероятную последовательность слов. Для пользователя это особенно опасно потому, что ошибка часто выглядит не как сбой, а как обычный уверенный ответ.
В этом смысле галлюцинации отличаются от простых опечаток или стилистических неточностей. Пользователь может не заметить проблему без внешней проверки. Чем более гладким становится текст LLM, тем сложнее визуально отличить проверенный факт от правдоподобной реконструкции.
Почему обычные тесты могут ухудшать честность модели
Самая полезная для инженеров часть материала OpenAI — критика оценок. Во многих бенчмарках модель получает баллы за совпадение с правильным ответом. Если она отказывается отвечать, просит уточнение или пишет, что данных недостаточно, такой ответ часто не приносит пользы в итоговой метрике. В результате угадывание становится рациональной стратегией.
Эта логика знакома по экзаменам с множественным выбором: если за неправильный ответ не штрафуют сильнее, чем за пропуск, участнику выгодно отвечать наугад. По версии OpenAI, похожий стимул возникает и в оценке языковых моделей. Система, обученная и донастроенная на высокие баллы, может предпочитать уверенное предположение аккуратному отказу.
Из этого следует важное ограничение для сравнений моделей. Таблица с лидербордами не всегда показывает, насколько безопасно модель ведет себя в неопределенности. Две модели могут иметь близкий общий результат, но одна чаще признает нехватку данных, а другая чаще придумывает недостающие факты. Для поисковых агентов, RAG-систем и корпоративных ассистентов это различие критичнее, чем небольшая разница в среднем балле.
OpenAI уже развивала отдельные инструменты и наборы для оценки моделей. Для контекста компания ведет проект OpenAI Evals: https://github.com/openai/evals. Также ранее OpenAI представляла SimpleQA — бенчмарк для проверки кратких фактических ответов: https://openai.com/index/introducing-simpleqa/. Эти ссылки не заменяют независимую проверку нового исследования, но показывают, что тема оценки фактической точности давно встроена в публичную исследовательскую повестку компании.
Что это меняет для RAG, агентов и корпоративных ассистентов
Для команд, которые строят продукты поверх LLM, вывод достаточно прямой: мало подключить модель к базе знаний и попросить «не придумывать». Нужно измерять, как система ведет себя при отсутствии ответа в источниках.
В RAG-приложениях частая ошибка — оценивать только удобство финального текста. Если ассистент красиво пересказывает документы, но иногда добавляет утверждения, которых в них нет, пользователь получает рискованную смесь факта и догадки. Более надежный тест должен проверять не только правильность ответа, но и привязку каждого существенного утверждения к найденному фрагменту источника.
Для AI-агентов проблема еще острее. Агент может не просто написать неверный текст, а выполнить действие: отправить письмо, изменить запись в CRM, подготовить заявку, сгенерировать команду для терминала. В таких сценариях галлюцинация превращается из информационного дефекта в операционный риск. Поэтому полезно тестировать не один идеальный путь, а случаи с неполными данными, конфликтующими документами и запросами, на которые система должна ответить отказом.
Практический критерий для внутреннего теста: добавьте в набор проверки вопросы, где правильное поведение — «нет данных в доступных источниках». Если модель все равно отвечает конкретными фактами, проблема не в формулировке одного промпта, а в метрике и контуре контроля.
Как менять проверки качества без лишней бюрократии
OpenAI предлагает смотреть на галлюцинации через призму стимулов: что именно награждает оценка. Для продуктовой команды это можно перевести в несколько рабочих правил.
Во-первых, разделяйте правильный ответ, неверный ответ и честный отказ. Если отказ в ситуации неопределенности оценивается как провал, модель будет меньше отказываться. Если неверная уверенность штрафуется сильнее, система получает другой сигнал.
Во-вторых, проверяйте калибровку уверенности. Недостаточно, чтобы модель иногда писала «возможно» или «вероятно». Нужно смотреть, совпадает ли степень уверенности с доступными доказательствами. В интерфейсе это может выражаться не процентами, а простыми статусами: найдено в источнике, требуется проверка, данных нет.
В-третьих, не смешивайте творческие и фактические задачи в одной метрике. Для генерации идей допустима вариативность. Для ответа о политике компании, лицензии, цене, медицинском противопоказании или юридическом сроке нужна совсем другая планка. Один и тот же набор настроек модели не должен автоматически переноситься между этими режимами.
В-четвертых, сохраняйте трассировку. Для каждого ответа, который претендует на фактологичность, полезно хранить запрос, найденные документы, версию модели, системную инструкцию и финальный текст. Без этого невозможно понять, была ли ошибка вызвана моделью, поиском, устаревшей базой знаний или плохо заданным вопросом.
Чего исследование OpenAI не доказывает
Материал OpenAI не означает, что галлюцинации можно полностью устранить одной новой метрикой. Авторегрессионная природа LLM, неполнота обучающих данных, неоднозначность запросов и ошибки в подключенных источниках остаются реальными ограничениями. Более строгие оценки могут снизить стимул к угадыванию, но не превращают модель в базу фактов.
Не стоит также считать выводы OpenAI независимым аудитом всех моделей на рынке. Это исследовательская публикация компании, которая сама разрабатывает и продает языковые модели. Ее тезисы полезны для инженерной практики, но при выборе модели или архитектуры стоит сверять их с собственными тестами, отраслевыми бенчмарками и поведением системы на данных конкретной организации.
Минимальная проверка для читателей Comrad404: возьмите десять вопросов из своей рабочей области, на которые в вашей базе знаний нет ответа, и прогоните их через используемую LLM или агента. Если система отвечает уверенно и без ссылки на источник, метрика качества настроена в пользу правдоподобия, а не надежности.