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

В магазине техники «ТехноМир» работает ИИ-консультант. Однажды покупательница спросила про скидку на ноутбук. Бот ответил: «По промокоду VESNA2026 вы получите 25%». Такого промокода не существовало. Она оформила заказ, ввела код, получила «неверный код» и написала разгневанное письмо со скриншотом бота. Скидку пришлось дать: отказать после обещания значило получить жалобу и репутационный удар.

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

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

Откуда берутся выдумки

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

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

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

Как выглядят выдумки

Выдумки не всегда очевидны. Их можно сгруппировать в пять типов, и каждый опасен по-своему.

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

Бот без источников и бот по источникам

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

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

Почему вообще удаётся достичь такого поведения? Потому что способ работы модели можно изменить инструкцией и устройством системы. Такой подход называют RAG (Retrieval-Augmented Generation, то есть генерация с подтягиванием найденного). Идея описана в научной литературе ещё в 2020 году, а сейчас это стандартная основа корпоративных ассистентов. Вот как он устроен:

Проверка обязательств отдельным слоем

Даже при хорошем RAG остаётся риск, что модель вставит что-то лишнее. Поэтому для самых дорогих случаев (деньги, сроки, гарантии, скидки, юридические формулировки) добавляют отдельную проверку после генерации. Это обычный код, а не нейросеть: он ищет в ответе промокоды, суммы и сроки и сверяет их со справочником. Не нашёл — ответ не уходит.

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

Компромисс: осторожность против пользы

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

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

Как проверять бота до запуска

Самая опасная иллюзия: «мы попробовали, ответил нормально». Десять удачных ответов ничего не говорят о том, что произойдёт на десяти тысячах. Проверять надо системно:

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

Три мифа про галлюцинации

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

Миф второй: «Достаточно написать в промпте „не выдумывай“». Такая фраза помогает, но слабо. Модель не знает, что она выдумывает: для неё выдуманное и известное выглядят одинаково. Инструкция «отвечай только по предоставленным документам» работает заметно лучше, чем «не ври», потому что она даёт проверяемый критерий. Но и она не гарантирует результата, поэтому нужна проверка после генерации.

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

Почему «пусть сама проверит» не работает

Соблазнительная идея: попросить ту же модель перепроверить свой ответ. Иногда это помогает, и самопроверка действительно ловит часть ошибок. Но у неё есть слабость: проверяющий использует то же самое «понимание» мира, что и автор. Если модель не знает, что промокода не существует, то и при проверке она не узнает. Поэтому надёжные проверки опираются на внешние данные: справочник, базу, документ. Модель можно использовать как помощника в проверке (сравнить ответ и источник), но источником правды всегда остаётся ваш документ.

Как говорить с клиентом, когда бот не знает

Формулировка отказа значит почти столько же, сколько и сам ответ. Плохие варианты: «Произошла ошибка», «Я не могу ответить на этот вопрос» (звучит как отписка). Хорошие: «Этой информации нет в моей базе. Я передал вопрос менеджеру, он ответит в течение часа», «Про это лучше уточнить у специалиста, вот как с ним связаться». В хорошем отказе три элемента: честное признание, что именно неизвестно, и конкретный следующий шаг с обещанием срока, которое вы можете выполнить.

Что делать, когда выдумка всё же случилась

Она случится. Поэтому нужен заранее продуманный порядок действий.

1. Сохраняйте журнал. Без записи диалога разобраться нельзя. Храните запрос, найденные фрагменты, ответ и результат проверки.
2. Разберите причину. В базе не было ответа? Был неверный? Поиск не нашёл? Модель пересказала с ошибкой? От причины зависит исправление.
3. Добавьте случай в тестовую выборку. Любая реальная выдумка становится тестом, который не должен проваливаться в будущем.
4. Решите вопрос с клиентом. Иногда выгоднее выполнить обещание, чем спорить. Но это решение принимает человек с полномочиями, а не бот.
5. Если случай серьёзный, пересмотрите зону ответственности бота. Возможно, эту тему нужно целиком передать человеку.

Остальные риски систем с ИИ (утечки данных, права, инъекции) разобраны в статье про безопасность систем с ИИ и в материале про агентов с доступами. А как выстроить маршрутизацию обращений, чтобы опасные темы вообще не попадали к боту, показано в разборе ИИ-поддержки.

Таблица «что бот может обещать»

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

• Цена и скидки. Источник: прайс-лист или справочник акций, подключённый кодом. Если данных нет, не называть цену, а предложить связаться с менеджером.
• Сроки доставки и выполнения. Источник: система учёта заказов. Без неё бот называет только «обычные» сроки из регламента и честно оговаривает, что точный срок зависит от заказа.
• Условия возврата и гарантии. Источник: утверждённый документ. Бот цитирует его и ссылается на пункт, а не пересказывает «своими словами».
• Юридические и медицинские вопросы. Источник: никакой. Бот не отвечает по существу, передаёт специалисту.

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

Что сделать на этой неделе

1. Выпишите всё, что ваш бот или ассистент может пообещать: цены, сроки, гарантии, скидки, юридические условия.
2. Для каждого пункта определите, откуда бот берёт данные. Если «из головы модели», это дыра.
3. Включите правило «отвечай только по источникам, а если нет, говори не знаю» и проверьте его на сотне реальных вопросов.
4. Добавьте проверку обязательств: код, который сверяет упомянутые промокоды, суммы и сроки со справочниками.
5. Сохраняйте журнал диалогов и разбирайте каждый случай выдумки.

Источники и что почитать

• BBC: Air Canada chatbot misinformation — what travellers should know — история о том, как суд обязал компанию выполнить обещание бота.
• Lewis et al., 2020: Retrieval-Augmented Generation — исходная работа про RAG.
• Huang et al., 2023: A Survey on Hallucination in Large Language Models — обзор причин и методов борьбы с галлюцинациями.

---

Пишу из практики студии MKDGRUPP: строим ассистентов на RAG с источниками в ответах, отдельной проверкой обязательств и передачей человеку. Подробнее: mkdgrupp.ru/uslugi/ai-agenty.