AI-консультант, который выдумывает наличие товара или цену — это не «милая ошибка». Один такой ответ клиенту, и вы теряете доверие, заказ, а иногда и возврат денег. Разбираем семь техник, которыми мы прижали галлюцинации модели у живого бота на 200 000+ SKU.
содержали галлюцинации
семи техник
цену» за 6 месяцев
Что такое галлюцинация LLM на пальцах
Языковая модель — это не справочник. Она не «знает» цены, остатки или адрес склада. Она предсказывает следующее слово на основе огромного корпуса текстов. Если модели задать вопрос, на который у неё нет данных в контексте, она всё равно что-то ответит — и часто это «что-то» звучит уверенно и правдоподобно.
В B2B-чате на сайте это выглядит примерно так: клиент пишет «есть ли ВВГнг 3×2.5 в наличии, сколько стоит». Если бот не получил структурированный ответ от парсера каталога, но в контексте есть упоминание «провод ВВГнг от 28 ₽/м» — он скажет «да, есть, 28 рублей за метр». Откуда взял — непонятно. Цена устарела на полгода.
Техника 1: структурированный JSON-ответ от парсера
Самая частая причина галлюцинаций — модели подают сырой HTML страницы каталога и просят «найди цену». Модель честно ищет, но если разметка нестандартная — путается и придумывает.
Решение: парсер источника отдаёт строго структурированный JSON:
{"found": true, "price": 28.5, "stock": 150, "url": "..."}— нашли;{"found": false, "reason": "no_match"}— не нашли;{"found": false, "reason": "service_unavailable"}— источник упал.
Модель получает не HTML, а уже разобранные факты. Её задача — собрать их в человеческий ответ, а не интерпретировать. Это убирает 60–70% галлюцинаций сразу.
Техника 2: жёсткий гайдрейл в system-prompt
В системном промте прописываем явное правило поведения при недостающих данных:
Модели хорошо реагируют на конкретные шаблоны ответа в случаях неопределённости. Это работает лучше, чем общая инструкция «не выдумывай» — потому что даёт модели «выход» из ситуации, не противоречащий её обучению быть полезной.
Техника 3: temperature=0 для классификации, >0 для диалога
Параметр temperature управляет «креативностью» модели. Распространённая ошибка — оставить дефолтный 0.7 на всех этапах.
- Классификатор намерений («о чём вопрос клиента?») —
temperature=0. Нужен детерминизм. - Выбор top-N товаров из карточек —
temperature=0. Нужно стабильное ранжирование. - Финальный диалог с клиентом —
temperature=0.3–0.5. Чуть-чуть «живости», но не «фантазия».
Когда классификатор работает на 0.7, у нас бывали ситуации: один и тот же запрос два раза подряд интерпретировался по-разному. Один раз — как поиск аналога, другой — как общий вопрос. После переключения на 0 — детерминизм восстановился.
Техника 4: whitelist допустимых форматов ответа
Для критичных сценариев — выдача цены, наличия, сроков доставки — заставляем модель отвечать в одном из заранее объявленных шаблонов:
- «Товар найден: название, цена X ₽, в наличии N шт».
- «Товар найден, но нет в наличии. Альтернативы: список».
- «Не нашёл подходящий товар по запросу. Передам менеджеру».
Любой ответ, не соответствующий шаблонам, отлавливается на post-process слое и заменяется на «передам менеджеру». Это финальный страховочный механизм.
Техника 5: журнал диалогов и ручной разбор первый месяц
Самая важная техника — не алгоритмическая. Первый месяц после запуска каждый день читать диалоги. Не «выборочно», а каждый.
Базы данных PostgreSQL под чат-логи хватает на годы. Делаем простую админку: фильтр «диалоги с пометкой пользователя „плохо“», «диалоги с длинными ответами от бота», «диалоги, в которых бот упомянул конкретную цифру цены». Это первичный набор для разбора.
Техника 6: контрольная модель-критик
Перед отправкой ответа клиенту прогоняем его через вторую LLM с инструкцией: «Ниже ответ бота и контекст, который у него был. Содержит ли ответ конкретные цифры (цена, количество, срок), которых нет в контексте? Ответь только Yes/No».
Если критик отвечает «Yes» (т.е. найдены цифры без подтверждения) — финальный ответ переписывается на безопасный шаблон «уточню у менеджера». Технику называют «LLM-as-a-judge» — она снимает оставшиеся ~5% галлюцинаций после первых пяти техник.
Техника 7: явная передача менеджеру с резюме диалога
Если бот не уверен — он не должен «дотягивать» ответ из последних сил. Должен честно сказать клиенту: «Передаю менеджеру, он свяжется в течение N минут». И передать в CRM с историей диалога.
Что важно: выход «на менеджера» — это не провал бота, а его правильная работа. На старте мы боялись таких передач, считали их признаком слабости. По факту это оказалось наоборот: клиенты, которых бот «отдал» вовремя, конвертировались в сделку лучше, чем те, кому бот наговорил неточностей.
Чего НЕ нужно делать
- Не пытаться «обмануть» модель промтом «никогда не выдумывай». Это слишком общая инструкция, модели плохо её выполняют.
- Не отдавать модели сырой HTML или таблицы Excel. Структурированный JSON всегда лучше.
- Не оставлять temperature=0.7 везде. Это убивает детерминизм классификации.
- Не запускать бот «в боевую» сразу. Первая неделя — закрытое тестирование на своей команде.
- Не игнорировать журнал диалогов. Без ручного разбора первый месяц правила не отточить.
Итоги
Галлюцинации LLM в AI-консультанте — управляемая проблема. У нас в проекте она снизилась с ~12% диалогов до <1% за два месяца. Семь техник работают вместе: каждая закрывает свой класс ошибок, и без них нельзя выпускать бота к реальным клиентам.
Если планируете внедрить AI-бота на свой сайт и хотите избежать наших граблей — пройдитесь по чек-листу до запуска, а не после.
