Галлюцинации нейросети: что это и как с ними бороться

Галлюцинация нейросети — короткий ответ

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

Если нейросеть объясняет отчёт менеджеру, ошибка особенно опасна: текст выглядит законченным и не содержит сигналов сомнения. Рабочее правило: просите показать источник и воспроизводимый расчёт. Для числа таким источником будет выполненный запрос или код, для цитаты — открытый первичный документ, для вывода — проверяемая цепочка от наблюдения к утверждению.

• Проверьте, существует ли названный источник и подтверждает ли он именно этот тезис.
• Для сумм, медиан и долей требуйте исполняемый код, а не готовое число.
• Сравните число строк и общий итог до и после каждой трансформации.
• Разрешите модели ответить «не знаю» и обозначить недостающие данные.

Почему ИИ придумывает убедительные ответы

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

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

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

Четыре формы ошибок, которые попадают в отчёт

Первая — придуманный факт или ссылка. Ассистент уверенно цитирует «исследование», но по адресу открывается другая публикация или нет ничего. Следствие: вывод остаётся без доказательства, даже если звучит разумно.

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

Третья — выдуманный столбец либо функция. SQL синтаксически правдоподобен, но схема базы не содержит gross_revenue или движок не знает предложенную функцию. Иногда код вообще не запускается; хуже, когда он запускается, но выбирает похожее поле с другим смыслом.

Четвёртая — уверенный неверный вывод. Цифры в абзаце могут быть точны, а причинное объяснение не доказано: совпадение во времени названо эффектом редизайна. Здесь проверка требует не только повторить расчёт, но и назвать альтернативные объяснения и ограничения данных.

Наш эксперимент: одна таблица, двенадцать ответов о выручке

Мы взяли из учебной базы «Авиаперевозки» 548 рейсов за 5 августа 2026 года. Эталонная сумма столбца выручки — 438 406 200 ₽, медиана выручки на рейс — 209 750 ₽. Данные, задания, сырые ответы и код проверки сохранены в статье об эксперименте.

Четыре модели OpenAI получали CSV как текст, без выполнения кода. Каждую спрашивали трижды. На вопрос о суммарной выручке ни один из двенадцати ответов не совпал с эталоном: диапазон — от 106 млн до 2,04 млрд ₽. Медиану тоже не назвала верно ни одна модель. При этом число строк и отменённых рейсов модели называли верно в 11 из 12 прогонов. Быстрый осмотр таблицы им давался, арифметика по сотням строк — нет.

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

Почему проверка «похоже на правду» не помогает

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

Особенно коварна медиана. Чтобы получить её по рейсам, нужно отсортировать 548 значений и взять середину. Просьба «будь точен» не заставляет текстовую модель выполнить сортировку. Прикреплённый файл, доступ к Python и выполненный код меняют механизм: арифметику делает интерпретатор. Но переданный файл нужно проверить на полноту, а код — на верное поле и фильтры.

У одной и той же модели ответ в нескольких прогонах может различаться. Поэтому повторный прогон полезен как сигнал нестабильности: если версии расходятся, доверие снижайте. Совпадение двух ответов не является доказательством. Обе версии могут повторять одну неверную догадку.

Давайте модели контекст, который можно проверить

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

У модели не должно быть необходимости угадывать, что значит «пользователь» или «активный». В SQL это превращается в неправильный JOIN, в Python — в неверный фильтр. Для внешних фактов приложите документ или ссылку на официальную страницу и попросите отмечать, какая фраза откуда взята. При отсутствии подтверждения пусть ответ остаётся пустым.

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

Используй только приложенный словарь метрик и схему.
Задача: напиши SQL для <метрика> за <период>.
Верни запрос, зерно результата, фильтры и отдельный список допущений.
Если нужного столбца или определения нет — напиши «недостаточно данных»; не придумывай.
Число назови только после выполнения запроса. Затем сверим его с <контрольный итог>.

Отделите генерацию кода от вычисления

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

В эксперименте с той же базой модели решали 14 SQL-задач по схеме. Верными оказались 91% запросов в совокупности. Остальные содержали узнаваемые дефекты: соединение, размножившее строки, значение города «Moscow» вместо «Москва», выдуманные столбцы. Это хороший результат для черновика и плохое основание запускать запрос без проверки.

Если инструмент сам выполняет Python, выгружайте и сохраняйте код. В нашем опыте с загруженным файлом верными были 99 из 108 ответов; единственный сбой — прогон, закончившийся без финального ответа. Код может быть исполнен без синтаксических ошибок, но обработать неполный файл или неправильный период. Правильность исполнения и правильность постановки — разные проверки.

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

Контрольный итог — число, которое уже известно независимо от нового расчёта. Для CSV рейсов это число строк и сумма выручки. Если код возвращает правильную медиану, но его сумма отличается от 438 406 200 ₽, сначала найдите причину расхождения. Возможно, часть строк выпала, пропуски были превращены в ноль или фильтр исключил отмены.

Проверяйте зерно на каждом этапе. После объединения рейсов с билетами строк станет больше, потому что на один рейс приходится несколько билетов. Сумма revenue из таблицы рейсов после такого JOIN тоже вырастет. Простая сверка «строк до / строк после» перехватывает дефект раньше, чем он попадёт в график.

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

import pandas as pd
df = pd.read_csv('day.csv')
assert len(df) == 548
assert df['revenue'].sum() == 438_406_200
assert df['revenue'].median() == 209_750
print('Контрольные итоги совпали')

Когда помогает поиск по документам и RAG

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

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

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

Просите признать неизвестное — и проверяйте признание

Фраза «если не уверен, скажи не знаю» полезна, но не равна настройке точности. Модель может написать оговорку, а ниже всё же назвать придуманное число. Поэтому задавайте критерий: ответ только при наличии строки источника или успешного запуска запроса; иначе — перечень недостающих данных.

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

Оценивать надо обе стороны поведения. Сколько ответов верны среди данных, где ответ существует? И сколько раз система честно воздерживается, когда его нет? Если считать только долю верных среди выданных ответов, можно поощрить либо агрессивное угадывание, либо отказ отвечать на всё. Для рабочего процесса важно заранее договориться, какая ошибка обходится дороже.

Повторный прогон и второй способ расчёта

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

Лучше получить одну и ту же величину разными способами: SQL на исходной таблице и Python на экспортированном CSV; агрегат по строкам и сумма агрегатов по группам. Совпадение двух методов повышает уверенность только при одинаково определённой метрике и одинаковом срезе. Если оба запроса скопированы из ответа модели, ошибки могут совпасть.

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

Что делать, если модель уже ошиблась

Не просите её «перепроверь внимательнее» без новой информации. Верните конкретное несоответствие: ожидали 548 строк, получили 430; столбца gross_revenue нет; после JOIN сумма выросла. Попросите исправить код и объяснить причину. Затем снова выполните его самостоятельно.

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

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

Четыре ошибки самого процесса проверки

Ошибка первая — проверять только синтаксис. Запрос запускается, поэтому кажется правильным; при соединении таблиц умножаются строки и сумма. Нужна проверка зерна и контрольной суммы.

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

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

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

Чек-лист перед отправкой результата

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

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

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

• Назовите источник, дату среза и определение метрики.
• Покажите код и результат его выполнения.
• Сверьте строки, сумму и одну группу с независимым эталоном.
• Проверьте источник каждого внешнего факта.
• Отделите факты от предположений и запишите ограничения.

Как проверить ссылку, которую придумал ассистент

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

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

Если источник недоступен, оставьте утверждение непроверенным. «Похоже, это писали в официальном блоге» недостаточно для цитаты. Внешнюю ссылку нужно воспринимать как приглашение к проверке, а не как печать достоверности.

Как ловить неверную цифру без готового эталона

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

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

Независимая сверка особенно полезна на границе систем. Сумма заказов в аналитической витрине и сумма в платёжном реестре могут различаться законно, но причина различия должна быть записана. Если объяснения нет, модель не должна оформлять число как окончательное.

Как проверить правдоподобный вывод, а не только арифметику

Фраза «после релиза выручка упала, значит релиз виноват» выглядит логичной, если оба факта верны. Но последовательность событий не доказывает причину. Могла измениться рекламная смесь, календарь, доступность товара или качество трекинга. Попросите модель разделить наблюдения, альтернативные гипотезы и данные, которые отличат их друг от друга.

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

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

Разный риск — разная глубина проверки

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

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

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

Частые вопросы

Что такое галлюцинация нейросети простыми словами? Это убедительный ответ, который не подтверждается данными или источником: придуманная ссылка, число, поле в коде или вывод.

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

Можно ли полностью убрать галлюцинации? Нет. Вы можете уменьшить риск и сделать ошибку обнаружимой: дать источник, разрешить «не знаю», выполнить код и сверить ответ с эталоном.

Как проверить число, названное нейросетью? Попросите запрос или скрипт, выполните на исходных данных и сравните с независимым контрольным итогом. Одинаковый ответ при повторном вопросе доказательством не служит.

Что читать дальше

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

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