Галлюцинации нейросетей: ключевые факторы искажения данных

Для компании это превращает удобную генерацию текста в операционный риск: сотруднику приходится проверять результат, а клиент может принять ответ за официальную позицию сервиса.

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

От распознавания изображений к языковым моделям

Термин «галлюцинация» появился в машинном обучении задолго до массовых чат-ботов. В 1999–2000 годах исследователи Саймон Бейкер и Такео Канаде использовали понятие Hallucinating Faces для описания того, как алгоритм достраивает детали размытых изображений лиц. Модель не восстанавливала утраченную информацию из надёжного источника. Она добавляла элементы, которые соответствовали выученным закономерностям.

В генеративном ИИ действует похожая логика, хотя объектом достраивания становится последовательность слов. Большая языковая модель, или LLM, получает текстовый контекст и шаг за шагом выбирает следующий токен. Токеном может быть слово, часть слова или знак. Выбор опирается на вероятности, рассчитанные по закономерностям обучающих данных. Модель умеет создавать связный текст, но сама по себе связность не подтверждает истинность каждого утверждения.

Это принципиальное различие между языковой компетентностью и проверкой фактов. Если запрос подразумевает конкретный ответ, модель часто продолжает рассуждение даже тогда, когда исходных сведений недостаточно. Она может собрать правдоподобную формулировку из фрагментов, которые встречались в похожих контекстах, и не обозначить границу между известным и предполагаемым.

В деловой среде такая ошибка нередко выглядит убедительнее, чем очевидная бессмыслица. Чат-бот поддержки может сообщить несуществующее условие возврата. Помощник аналитика способен приписать документу вывод, которого в нём нет. Генератор отчётов может объединить показатели с разными периодами, если задача сформулирована расплывчато. Во всех случаях ответ грамматически гладкий, а значит, его легче пропустить при беглом чтении.

Уверенный тон модели описывает качество генерации текста, а не степень достоверности фактов.

Почему обучение поощряет догадки

В сентябре 2025 года OpenAI опубликовала работу о причинах языковых галлюцинаций. Один из её выводов касается не только объёма данных, но и того, какое поведение система обучения поощряет. Если при оценке модели правильный ответ получает преимущество перед признанием незнания, модель получает стимул отвечать даже при недостатке оснований.

Это не означает, что система намеренно вводит пользователя в заблуждение. Речь идёт о статистической генерации: модель выбирает продолжение, которое кажется наиболее подходящим с учётом контекста и обученных закономерностей. Если задача требует назвать факт, а неопределённость не подкреплена подходящим поведением в обучении, ответ может оказаться догадкой.

Особенно наглядный случай связан с редкими фактами, которые встречались в обучающей выборке один раз. Такой показатель называют singleton rate, то есть долей фактов, представленных одиночным примером. В теоретическом расчёте OpenAI описан предел: если 20% фактов относятся к таким одиночным случаям, минимальный уровень ошибок может составлять 20%. Это не универсальный прогноз для любой модели или бизнес-задачи. Расчёт показывает другое: редкие сведения трудно надёжно усвоить по единичному примеру, даже если система в целом хорошо работает с частыми закономерностями.

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

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

Контекст определяет границы ответа

Для корпоративного ИИ контекстом служат документы, записи CRM, база знаний, каталог услуг, переписка или сведения из внутренних систем. Если модель получает неполный, устаревший или плохо организованный контекст, она может достроить недостающие связки на основе общих закономерностей. Поэтому один и тот же запрос способен дать разные результаты в зависимости от того, какие данные приложены и насколько они соответствуют задаче.

В исследовании IBM 72% сбоев ИИ при корпоративных внедрениях связывались с недостаточным или некачественным контекстом, а не с ограничениями самой модели. Эта цифра не означает, что все остальные ошибки вызваны исключительно алгоритмами, и её нельзя механически переносить на любую компанию. Она подчёркивает системную проблему: модель часто оценивают отдельно, хотя в рабочем процессе она зависит от качества данных, которые получает на входе.

Внешне контекстная ошибка может выглядеть как проблема рассуждения. Например, внутренний помощник отвечает по инструкции, но использует архивную версию документа; чат-бот знает общие правила, но не видит исключений для конкретного типа клиента. В обоих случаях модель может построить последовательный ответ. Ошибка находится в связке между запросом, источником и генерацией, а не обязательно в параметрах самой нейросети.

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

Поэтому качество контекста оценивают как отдельную часть системы. Для этого полезно разбирать не только финальный ответ, но и путь к нему:

• Нашла ли система документ, который действительно относится к запросу, или выбрала похожий по словам фрагмент?
• Актуален ли источник и совпадает ли его версия с действующими правилами компании?
• Достаточно ли найденных данных для ответа на весь вопрос, а не только на его часть?
• Можно ли связать ключевые утверждения модели с конкретными фрагментами источника?

Эти вопросы особенно важны там, где ответ влияет на деньги, условия обслуживания или соблюдение внутренних регламентов. В цифровом банкинге, например, внешне корректная консультация не заменяет проверки юридического статуса и операционных ограничений организации. Для отдельного контекста полезен разбор причин и последствий отзыва лицензии у РНКО «Цифровые решения»: финансовые решения зависят от фактического и нормативного основания, а не от убедительности формулировки.

Сложный запрос умножает места для ошибки

Чем больше составных операций выполняет ИИ, тем больше в ответе промежуточных шагов, на каждом из которых может появиться искажение. Поисковые системы с генеративным ответом способны разбивать исходный вопрос на параллельные подзапросы. Этот механизм называют query fan-out, то есть веерной декомпозицией запроса. Он расширяет охват поиска, но усложняет сборку результата: найденные фрагменты могут относиться к разным аспектам вопроса, а при их объединении возникают некорректные связи или вымышленные детали.

Допустим, руководитель просит сравнить условия трёх поставщиков и определить, какой вариант выгоднее для отдела. Для точного результата системе нужно найти актуальные тарифы, учесть одинаковый период сравнения, привести дополнительные сборы к сопоставимому виду и правильно применить критерий выгоды. Если один из шагов не обеспечен данными, итог может выглядеть аккуратно, но содержать ошибку в исходном условии или выводе.

Сложность здесь не обязательно связана с объёмом текста. Короткий запрос может требовать нескольких источников и вычислений. Длинный вопрос может быть простым, если все нужные сведения приведены прямо в нём. Поэтому факторы нестабильности ответов LLM разумнее оценивать по структуре задачи: сколько фактов нужно извлечь, сколько сущностей сопоставить, есть ли неоднозначность и требуется ли актуальная информация.

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

Бенчмарки дают полезную, но ограниченную картину. По данным Vectara, измеренная частота галлюцинаций у разных языковых моделей варьируется от менее 1% до 27% и выше в зависимости от сложности задачи и архитектуры. В качестве примера приводится результат 0,7% у Gemini 2.0 Flash на базовом наборе данных. Такие числа нельзя трактовать как постоянную характеристику модели для любой корпоративной нагрузки: методика, состав теста, длина ответа и требования к проверке меняют результат. Сопоставление имеет смысл, когда модели испытывают на одинаковых данных и сценариях, близких к будущему применению.

Цена ошибки включает работу по проверке

Ошибки генеративного ИИ в аналитике создают расходы не только тогда, когда неверный вывод уже повлиял на решение. Компания тратит время на контроль, исправление ответов и разбор инцидентов. В данных, собранных в 2025 году, среднее время сотрудников на проверку ответов ИИ оценивалось в 4,3 часа в неделю. Это не универсальная норма для всех профессий: нагрузка зависит от частоты использования, цены ошибки и того, насколько результат можно проверить автоматически.

Опрос EY, проведённый в октябре 2025 года среди 975 респондентов, оценил средний зафиксированный ущерб организации от инцидентов, связанных с ошибками и галлюцинациями ИИ, в 4,4 млн долларов. Среднее значение не описывает типичный случай в каждой отрасли и не говорит, что именно языковые модели были причиной каждого ущерба. Оно показывает масштаб возможных последствий, когда недостоверный результат попадает в процесс без достаточного контроля.

Для оценки проекта полезно разделять три категории затрат:

1. Проверка до использования. Сотрудник сверяет ответ с первичным документом, внутренней базой или расчётом. Чем критичнее решение, тем меньше оснований полагаться на выборочную проверку.

2. Исправление после обнаружения ошибки. Команде приходится повторно обработать запрос, обновить клиентскую коммуникацию или пересобрать аналитический вывод.

3. Последствия использования неверных данных. Они зависят от области применения: ошибка в черновике внутреннего письма и неверное условие в финансовой консультации имеют разную стоимость.

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

При этом уверенность, выраженная самой моделью, нельзя считать надёжной оценкой фактической точности. Модель может формулировать ошибочный ответ без заметных признаков сомнения. Следовательно, интерфейсные маркеры уверенности имеют смысл только тогда, когда они калиброваны на конкретной задаче и проверены на реальных данных; одного впечатления от уверенного тона недостаточно.

Как встроить генерацию в рабочий процесс

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

Для корпоративного внедрения обычно полезны следующие меры:

• Разделять задачи по уровню риска. Генерация черновика и формирование ответа клиенту требуют разного режима контроля.
• Передавать модели актуальные документы и ограничивать ответ материалами, которые относятся к вопросу. Если источника нет, система должна явно обозначить этот предел.
• Проверять качество извлечения данных отдельно от качества генерации. Хорошая формулировка не компенсирует документ, найденный по ошибке.
• Сохранять возможность проследить, на каких источниках основан ответ, чтобы специалист мог быстро проверить ключевые утверждения.
• Тестировать модель на примерах реальных запросов, включая неполные данные, конфликтующие инструкции и редкие факты.
• Отслеживать ошибки после запуска. Меняются документы, процессы и формулировки запросов, поэтому прежние результаты тестирования со временем теряют актуальность.

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

В ближайшей перспективе развитие генеративных сервисов будет зависеть не только от размера моделей и скорости ответа. Для бизнеса не менее значимы качество поиска по внутренним данным, прозрачность происхождения утверждений и способность системы корректно отступать, когда оснований недостаточно. Выигрывать будут не те внедрения, где нейросеть выглядит наиболее уверенной, а те, где её вклад можно измерить, проверить и встроить в процесс с понятной ценой ошибки.