Почему ИИ-бот на сайте врёт клиентам — и как мы это починили

Есть такой момент, когда смотришь в переписку своего ИИ-бота с клиентом и понимаешь, что он только что уверенно соврал. Не злобно, не намеренно — просто сказал что-то правдоподобное вместо правильного.

Клиент спросил про доставку в Екатеринбург. Бот ответил: «Да, доставляем, обычно 3–5 дней». Проблема в том, что в Екатеринбург мы доставляем 7–10 дней и с доплатой. Бот это просто не знал точно, но уверенности не занимать.

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

Откуда берётся проблема

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

Казалось бы — вали туда всё что нужно. Прайс, условия, гарантии, частые вопросы.

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

Модель начинает «интерполировать». Знает что доставка есть — значит скажет что есть. Сроки? Назовёт что-нибудь похожее на правду. Это и есть галлюцинация: не выдумка, а уверенная интерполяция при недостатке точных данных.

Второй сценарий — промпт разрастается. Сначала пишешь 500 символов, потом добавляешь цены, потом условия возврата, потом ответы на возражения. Через месяц это 5 000 символов, которые сложно поддерживать и в которых сам запутаешься.

Что такое RAG и почему это не страшное слово

RAG — Retrieval-Augmented Generation. Звучит как что-то из академической статьи, но идея простая.

Представьте двух сотрудников:

Первый выучил всё наизусть перед сменой. Знает много, но в деталях путается.

Второй держит перед собой папку с карточками. Клиент спрашивает про доставку — он открывает карточку «Доставка» и читает точный ответ. Клиент спрашивает про гарантию — открывает карточку «Гарантия».

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

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

Что изменилось когда мы это внедрили

Раньше клиенты нашего виджета жаловались на два типа проблем:

1. Бот называет неточные цены или условия
2. Промпт разросся и его страшно трогать — непонятно что сломается

После добавления базы знаний обе проблемы стали управляемыми.

Конкретный пример: один из клиентов — небольшая мебельная компания. У них 40+ позиций с ценами, 3 варианта доставки в зависимости от суммы заказа, нюансы по сборке. Раньше всё это жило в промпте. Бот периодически называл цену доставки неверно.

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

Что стоит туда добавлять в первую очередь

Из наблюдений за тем, как клиенты заполняют базы знаний:

Работает хорошо: конкретные цифры (цены, сроки, размеры), условия с вариантами («если сумма до 3000 — доставка 290 ₽, если больше — бесплатно»), ответы на конкретные возражения («почему у вас дороже чем у X»).

Работает хуже: абстрактные описания («мы лучшие на рынке»), дублирование того что уже есть в промпте, слишком длинные карточки — лучше разбить на несколько коротких.

Хороший ориентир: если вопрос задают несколько раз в неделю — он должен быть в базе знаний. Если вопрос уникальный и непредсказуемый — это работа для промпта и общей логики бота.

Честно о том что не идеально

RAG не серебряная пуля. Несколько наблюдений:

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

Маленькая база работает лучше большой. 20 точных карточек про реальные частые вопросы лучше чем 200 карточек с полным FAQ. Система ищет топ-3 релевантных — если их слишком много и они размыты, точность падает.

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

Вывод

Если у вас стоит или планируется ИИ-бот на сайте — отделяйте поведение бота от данных о бизнесе. Промпт должен отвечать на вопрос «как он общается», база знаний — на вопрос «что он знает».

Это снижает галлюцинации, упрощает поддержку и позволяет обновлять информацию без страха сломать логику бота.

Если интересно как это работает технически на уровне эмбеддингов и векторного поиска — пишите в комментарии, разберём отдельно.

Мы сделали эту функцию в своём продукте — ИИ-виджете для сайтов с передачей диалога оператору в MAX. База знаний доступна всем клиентам LLMCOD в личном кабинете.