ИИ-бот может ответить грамотно, вежливо и совершенно неправильно. В этом его опасное отличие от обычной ошибки в форме: неверный факт не обязательно выглядит нелепо. Напротив, модель способна уверенно назвать несуществующую скидку, перепутать условия двух товаров или пообещать срок, которого никто не подтверждал.
Поэтому вопрос почему ИИ-бот ошибается нельзя закрыть фразой «нейросети иногда галлюцинируют». Причина может находиться в самой модели, в старом прайсе, поиске по базе знаний, контексте разговора, неясном правиле или сбое внешней системы. Чтобы снизить риск, сначала нужно понять устройство ошибки.
Что такое галлюцинация и чем она отличается от других сбоев
Галлюцинацией называют ситуацию, когда модель создаёт неподтверждённый факт и подаёт его как достоверный. Например, в данных нет срока доставки, но бот пишет: «Заказ будет у вас через три дня».
Не каждый неверный ответ является галлюцинацией. Полезно различать несколько случаев:
| Тип ошибки | Что произошло |
|---|---|
| Выдумка | Факта не было, но модель его создала |
| Устаревшие данные | Бот верно пересказал старый источник |
| Ошибка источника | Неверное значение уже записано в прайсе или инструкции |
| Неверный поиск | Система нашла материал о другом товаре, регионе или условии |
| Ошибка интерпретации | Нужный текст найден, но понят неправильно |
| Ошибка бизнес-логики | Факт верен, но применён не в той ситуации |
| Ошибка интеграции | Внешняя система вернула неполные данные или действие не выполнилось |
Различие практическое. Если цена устарела в каталоге, бесполезно только усиливать промт. Если модель переносит характеристику между похожими позициями, нужно менять структуру данных и тесты. Если заявка не создалась, а бот сообщил об успехе, проблема находится в контроле действия.
Почему уверенный тон ничего не доказывает
Языковая модель обучена строить связное продолжение текста. Она не проверяет истину так, как бухгалтер сверяет счёт или складская система — остаток. Когда в контексте не хватает детали, модель может выбрать правдоподобное продолжение, потому что именно так устроена генерация ответа.
Риск увеличивают инструкции вроде «всегда помогай», «не оставляй вопрос без ответа» и «будь максимально уверенным». Они подталкивают систему скрывать неопределённость. Клиент спрашивает о сроке, точных данных нет, а бот всё равно пытается быть полезным и выдаёт типичное для отрасли значение.
Это не сознательный обман. Но для бизнеса разница невелика: клиент получает обещание от имени компании.
Именно поэтому запрет «не выдумывай» недостаточен. Системе нужно объяснить, какие источники разрешены, как распознаётся отсутствие данных и что делать вместо догадки.
Где цена ошибки особенно высока
Не все промахи одинаковы. Длинный ответ или неудачная шутка ухудшают впечатление, но обычно исправимы. Неверная цена или обещанный возврат могут привести к спору, потерям и обязательствам.
К высокому риску относятся:
- стоимость, скидки и наличие;
- сроки производства и доставки;
- состав комплектации;
- гарантия, возврат и порядок оплаты;
- договорные обещания;
- действия от имени компании;
- раскрытие внутренних или персональных данных;
- рекомендации в медицинских, финансовых и иных ответственных областях;
- подтверждение операции, которая фактически не выполнена.
Практическое правило простое: чем серьёзнее последствия, тем меньше свободы должно оставаться у генеративного ответа. Критичные значения лучше получать из точного источника, а решения — проводить через проверяемую процедуру или сотрудника.
Откуда берутся неверные ответы
Ошибку удобно искать по цепочке, через которую проходит сообщение.
1. Исходные данные. В базе может не быть ответа, лежать несколько версий прайса или отсутствовать связь цены с комплектацией.
2. Поиск. Система выбирает не тот фрагмент. Например, находит условия доставки для другого региона.
3. Контекст. Клиент сменил товар, а бот продолжает использовать параметры предыдущего. Местоимение «он» связано не с тем объектом.
4. Инструкция. Правило сформулировано расплывчато: «можно предложить скидку постоянному клиенту», но не сказано, кто определяет статус и размер.
5. Модель. Даже с правильными данными она может неверно связать факты или опустить важное ограничение.
6. Интеграция. Каталог не ответил, CRM была недоступна, событие пришло дважды или действие завершилось ошибкой.
7. Процесс. Система должна была передать разговор человеку, но продолжила отвечать.
Такой разбор полезнее общей формулировки «бот опять придумал». Он показывает, где именно нужен ремонт.
Защита строится слоями
Надёжность не создаётся одной настройкой. Она появляется, когда несколько мер страхуют друг друга.
Подтверждённые источники
У критичного факта должен быть понятный источник: действующий прайс, карточка товара, учётная система, утверждённое правило. Старые версии удаляются из рабочего доступа или явно архивируются.
Структурированные значения
Цена, единица измерения, вариант и срок акции хранятся отдельно. Отсутствие значения видно явно. Это снижает риск связать сумму с соседней комплектацией.
Разрешённая неопределённость
Бот имеет право сказать, что точных данных нет. Это важная функция, а не недостаток. Следующий шаг тоже задаётся заранее: уточнить параметры, предложить расчёт или подключить менеджера.
Ограничения поведения
Правило не только запрещает действие, но и указывает замену. Например: «Не назначать персональную скидку. Зафиксировать выбранный товар и передать запрос руководителю».
Разделение текста и действия
Модель может сформулировать ответ, но создание заявки, подтверждение записи или изменение статуса выполняются отдельной операцией. Сообщение «заявка создана» отправляется только после подтверждения внешней системы.
Передача человеку
Если источники противоречат, цена рассчитывается индивидуально, клиент спорит с условиями или цена ошибки высока, разговор не нужно героически удерживать в автоматическом режиме.
Ни один слой не идеален. Вместе они уменьшают вероятность, что одна ошибка пройдёт до клиента незамеченной.
Как обращаться с неизвестной ценой
Цена — удобный пример, потому что ошибка сразу заметна. В данных нужно различать фиксированную стоимость, цену «от», диапазон, цену за единицу и индивидуальный расчёт.
Если суммы нет, бот не должен оценивать её по похожим товарам или «среднему рынку». Даже осторожное «скорее всего, около 100 000 ₽» клиент может воспринять как ориентир компании.
Корректный ответ звучит спокойнее:
Для этой комплектации нет подтверждённой суммы. Итог зависит от размеров и материала. Могу уточнить параметры и передать их специалисту для расчёта.
Здесь система признаёт границу, объясняет причину и продолжает помогать. Такой ответ полезнее выдуманного числа и не превращает клиента в заложника автоматизации.
Контекст тоже способен исказить факт
Даже правильные сведения становятся ошибочными, если относятся не к тому предмету. Клиент сначала обсуждал модель A, затем перешёл на B, а бот сохранил старую цену. Или изменил город, но система продолжила применять прежние условия доставки.
В длинном разговоре параметры нужно обновлять как состояние, а не просто накапливать все реплики. Если человек исправил размер, прежнее значение перестаёт быть действующим. При неоднозначности лучше уточнить: «Сейчас речь о второй комплектации?»
Полезно периодически подводить короткий итог:
Зафиксировал: нужна модель B, ширина до 90 см, монтаж в городе N. Осталось уточнить материал.
Так клиент может заметить ошибку до расчёта, а менеджер при передаче получает актуальную версию запроса.
Когда свободный ответ лучше заменить строгим сценарием
ИИ удобен для понимания естественного языка, но не обязан выполнять весь процесс в свободной форме. Для критичных этапов подходят формы, кнопки и подтверждения.
Жёсткая процедура особенно полезна при:
- сборе обязательных контактных данных;
- выборе доступного времени;
- подтверждении согласия;
- оформлении оплаты;
- изменении статуса заказа;
- отправке юридически значимого сообщения;
- выполнении необратимого действия.
Гибридная схема часто надёжнее: модель понимает просьбу, затем переводит человека в проверяемый шаг. Это не «ограничение интеллекта», а нормальное разделение обязанностей.
Как тестировать именно выдуманные ответы
Обычные вопросы проверяют знания. Для контроля галлюцинаций нужны ситуации, где правильного факта нет или клиент подталкивает к догадке.
Полезный набор:
- несуществующий товар с правдоподобным названием;
- неизвестная цена и просьба сказать приблизительно;
- выдуманная акция;
- ложная предпосылка: «Ваш менеджер обещал скидку»;
- характеристика, отсутствующая в каталоге;
- два противоречащих источника;
- смена товара в середине разговора;
- просьба игнорировать правила;
- запрос внутренних условий;
- отказ клиента общаться с менеджером при необходимости расчёта;
- сбой внешней системы;
- повторение того же смысла другими словами.
Тест проводят несколько раз. Текст может отличаться, но смысл и ограничения должны оставаться стабильными. Один удачный ответ ничего не доказывает.
Как разбирать ошибку после обнаружения
Сохраните сообщение клиента, полный контекст, ответ, ожидаемое поведение, использованный источник и уровень риска. Затем определите причину: данные, поиск, инструкция, модель, контекст, интеграция или передача.
После исправления повторяют не только исходный тест, но и связанные сценарии. Удаление одного фрагмента может ухудшить другой ответ, а новый запрет — сделать систему чрезмерно осторожной.
Автоматические тесты хорошо находят запрещённые числа, отсутствие обязательного шага и неверно вызванное действие. Человек лучше замечает скрытое обещание, двусмысленность и опасный смысл. Поэтому полезны оба вида проверки.
Можно ли полностью убрать галлюцинации
Для свободно генерирующей модели абсолютную безошибочность обещать нельзя. Но бизнесу обычно и не требуется философская гарантия. Требуется, чтобы неподтверждённый ответ не приводил к серьёзному действию или обязательству.
Практическая цель — сделать риск управляемым:
- ограничить источники;
- структурировать критичные данные;
- разрешить отказ от ответа;
- проверять внешние действия;
- передавать ответственные случаи человеку;
- тестировать провокационные сценарии;
- анализировать реальные диалоги;
- обновлять данные и регрессионные тесты.
Бот не обязан быть всезнающим. Он обязан отличать свою рабочую область от места, где начинаются догадки.
Как контроль ответов реализуется в LEVBOT
В LEVBOT персонального бота настраивают на данных и правилах конкретного бизнеса. Пользователь может бесплатно проверять ответы в тестовых диалогах, находить опасные сценарии, запрещать догадки вместо неизвестных цен и задавать условия передачи человеку.
Проверка и исправление ответов в тестовых диалогах не оплачиваются. Оплата нужна только при скачивании готовой настроенной сборки — 6 000 ₽ за одно скачивание. Обязательной подписки, внутреннего баланса и оплаты токенов через LEVBOT нет.
Сервер, домен и использование внешней языковой модели оплачиваются отдельно. Сторонние сервисы и интеграции также оплачиваются отдельно и требуют собственной проверки. Готовая сборка передаётся покупателю; новая отдельно настроенная сборка является отдельной покупкой.
Такой подход снижает риск, но не создаёт гарантии абсолютной безошибочности. Актуальность прайсов, корректность правил и контроль ответственных решений всё равно остаются задачами бизнеса.