Бот пообещал скидку: как проверять реплики до отправки клиенту

Скидка «в порядке исключения». Срок доставки «завтра точно». Гарантия «пожизненная». Обычный бот выдумает любую из этих фраз за секунду — и вы узнаете об этом от клиента, который уже на неё рассчитывает.

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

Здесь неприятная правда о рынке: все продают AI-бота, и почти никто не продаёт способ проверить, что он не навредит. В коробочных CRM такого слоя нет вовсе. А он существует и устроен понятнее, чем кажется.

Главное за минуту

Почему «напишите хороший промпт» не работает как защита

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

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

Четыре контура: что происходит с репликой перед отправкой

1. Стоп-слова и запретные темы

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

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

2. Запрещённые обещания

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

Правила отличают обещание от упоминания. «Скидок не даём» проходит. «Уточню, есть ли скидка» проходит. «Дам вам скидку 10%» — нет. Разница принципиальная: фильтр по ключевому слову «скидка» сломал бы половину нормальных ответов.

3. Опора на источник

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

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

4. Порог уверенности

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

В телефонном разговоре проверка идёт до озвучки

В переписке у вас есть запас: сообщение можно не отправить. В звонке запаса нет — сказанное вслух не отзовёшь.

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

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

Вы поменяли одну фразу в инструкции. Что теперь сломалось?

Второй страх после «наговорит лишнего» — и он обоснованный. Промпт — это код без тестов: правка в одном месте меняет поведение в трёх других, и узнаёте вы об этом от клиента.

Решение то же, что в разработке: регрессионные проверки. Для бота заводится набор эталонных сценариев с семью типами проверок:

• инструмент вызван;
• инструмент не вызван — отдельный тип, и он важнее, чем кажется: бот не должен создавать заказ на вопрос о наличии;
• товар найден;
• сделка создана;
• ответ опирается на базу знаний;
• ответ подходит под образец;
• оценка модели-судьи с порогом 70 из 100.

Прогон идёт по боевому конвейеру настоящими инструментами, но в одноразовой песочнице: заводится служебный клиент «[проверка бота] #номер», а после прогона всё созданное убирается. То есть тестируется реальное поведение, а не имитация, и при этом в базе не остаётся мусора.

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

Провалы находят себя сами — без второй статьи расходов

Читать все диалоги бота вручную не будет никто. Тимлид по выходным — не масштабируемое решение.

Поэтому платформа каждые 10 минут просматривает свежую переписку по пяти объективным признакам:

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

По понедельникам в 9 утра по часовому поясу компании владелец получает сводку: сколько случаев, сколько разных обращений задето, три главные причины.

Из провала — в правку, из правки — в доказательство

Найти проблему мало. Цикл должен замыкаться, иначе отчёты копятся, а бот не меняется.

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

Оба ответа хранятся копией — поэтому сравнение «было / стало» переживает и следующую правку, и удаление исходной переписки. На разборе с руководителем вы показываете не рассказ, а два текста.

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

Как выпускать бота к клиентам: план на три недели

Порядок, который снимает риск, а не откладывает его.

• Неделя 1. Ограждение в режиме наблюдения: ответы уходят, срабатывания пишутся в журнал. Вы просто смотрите, сколько раз бот собирался придумать цену.
• Неделя 1. Свой список запрещённых формулировок — по тем обещаниям, которые в вашем бизнесе стоят дороже всего.
• Неделя 2. 5–10 эталонных сценариев из реальных диалогов, включая «инструмент не должен вызываться».
• Неделя 2. Включить автопрогон, чтобы правки промпта сразу проверялись.
• Неделя 3. Перевести опору на источник и запрет обещаний в строгий режим — по данным первой недели, а не наугад.
• Неделя 3. Настроить реакцию: подмена ответа плюс передача человеку плюс задача оператору.
• Постоянно. Понедельничная сводка разбора диалогов — как утренняя почта, а не как проект.

Промпт — это культура поведения, а не техника безопасности. Проверка должна стоять между моделью и клиентом, а не в логах после отправки.

Границы: чего мы не обещаем

Этот блок — тоже часть контроля качества. Только уже нашего, а не ботовского.

И то, что обычно не пишут в маркетинге: сам механизм ограждения покрыт автотестами — 31 проверка ограждения, 18 проверок сценариев, 19 проверок детектора проблемных диалогов. То, на что компания полагается в вопросе «бот не скажет лишнего», не держится на честном слове разработчика.

Связанные материалы

• ИИ-сотрудник или чат-бот: в чём разница на практике
• Сколько стоит ИИ: себестоимость каждого разговора с ботом
• База знаний и RAG: как снизить нагрузку на поддержку без потери качества
• BI-аналитика и контроль качества