Почему AI-бот выдумывает ответы и как это лечится

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

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

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

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

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

Все три слоя видно на нашем продукте для гостиниц. База знаний AI-консьержа собирается из документов конкретного отеля — правил проживания, описаний номеров, перечня услуг и внутренних регламентов в форматах PDF и DOCX. Не из общих представлений о том, как устроены отели, а из бумаг этого объекта. Поэтому на вопрос про заезд с животными бот отвечает правилами этого отеля, а не усреднённой отраслевой практикой.

Изменяемые данные вынесены из базы знаний в интеграцию. Реальное наличие номеров и цены AI-консьерж берёт из системы бронирования TravelLine — то есть из того же источника, которым пользуется отдел бронирования. Это принципиальный момент: цену нельзя «знать», её можно только запросить. Как только цифра перестаёт лежать в тексте документа, исчезает и целый класс ошибок, когда бот уверенно называет прошлогодний тариф.

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

Всё это работает в семи боевых каналах связи с гостем — от WhatsApp и Telegram до VK, MAX, Avito и виджета на сайте — круглосуточно и с автоопределением языка. Решение подаётся как отдельный сервис hotelconcierge.ru и находится в проде. Логика при этом отраслевая только по содержанию базы: та же тройка слоёв собирается для клиники, автосервиса или интернет-магазина — меняются документы и система, из которой берутся живые данные.

Инструкция в промпте — это пожелание, а не ограничение. Фраза «отвечай только по базе знаний, не выдумывай» повышает шансы на аккуратный ответ, но ничего не гарантирует: модель по-прежнему вправе сгенерировать любой текст, и никакого механизма, который бы её остановил, в промпте не появляется. Вы просите вероятностный генератор быть самому себе контролёром — а он не умеет отличать знание от догадки.

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

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

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

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

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

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

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

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

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

И вопрос данных. Персональные данные клиентов, попадающие в переписку, подпадают под 152-ФЗ, поэтому размещение на серверах в РФ и порядок обработки фиксируются в договоре, а не обсуждаются устно. Мы закладываем это в проект с начала — вместе с тем, какие данные вообще уходят во внешнюю модель, а какие остаются в вашем контуре.

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

На бесплатном экспресс-аудите (30 минут) мы смотрим, откуда бот берёт ответы сейчас, какие данные у вас меняются чаще всего и куда их можно запрашивать напрямую, как устроена передача диалога человеку. Дальше собираем контур AI-бота: база знаний из ваших документов, интеграция с CRM или учётной системой через API, эскалация с полным контекстом диалога, аналитика вопросов. Стоимость называем после аудита, когда понятен объём каналов, документов и интеграций — универсального прайса здесь нет.

Форматы дальше зависят от задачи. Если разговор идёт с клиентами в мессенджерах — это AI-боты и поддержка 24/7. Если та же проблема внутри компании, когда сотрудники спрашивают про регламенты и получают выдуманные ответы, подходит корпоративный AI-ассистент: он отвечает по внутренним документам, даёт ссылку на первоисточник и разграничивает доступ по ролям. Если нужен человек, который ведёт AI-контур внутри вашей команды и дорабатывает его постоянно, — это формат выделенного AI-инженера.

И честная развилка. Если у вас нет ни одного документа, по которому можно отвечать, начинать надо не с бота, а с базы знаний: собрать правила, прайсы и регламенты в пригодный для загрузки вид. Бот без источника выдумывает не потому, что его плохо настроили, а потому, что отвечать ему не по чему. Мы говорим это на аудите прямо — иногда первым шагом оказывается не внедрение, а наведение порядка в документах.