Чат-бот поддержки отвечает не по теме: что проверить

В чем проблема на самом деле

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

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

Часто причина вообще не в модели. Команда начинает переписывать промпт, менять температуру или сравнивать разные LLM, хотя сбой случился раньше. Система могла неверно определить намерение пользователя, подтянуть не те документы из базы знаний или не распознать, что на такой вопрос нельзя отвечать без уточнения.

Полезно сразу разделить два типа ошибок:

• Ошибка распознавания. Пользователь спрашивает про возврат, а система отправляет запрос в ветку про доставку, статус заказа или общие правила магазина.
• Ошибка ответа. Маршрут выбран верно, но бот берет слабый фрагмент из базы, смешивает разные политики или додумывает то, чего в данных нет.

Это простое разделение экономит время. Если сломан intent routing, нет смысла долго править текст ответа. Если маршрут верный, но бот все равно уводит разговор в сторону, смотрите на документы, чанки, метки, приоритеты источников и политику отказа.

Небольшой пример. Клиент пишет: "Хочу вернуть наушники, коробка вскрыта, прошло 9 дней". Хороший бот либо ведет его в сценарий возврата с нужными условиями, либо задает один уточняющий вопрос. Плохой бот делает вид, что все понял, и выдает общий абзац: "Возврат товара регулируется правилами магазина". Формально ответ по теме. По сути - нет.

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

Где ломается intent routing

Часто routing ломается еще до поиска ответа. Бот выбирает не тот интент, а дальше уже честно делает неверное действие: ищет статью не в том разделе, просит лишние данные или переводит диалог в чужой сценарий.

Первая частая причина - слишком длинный список интентов без ясных границ. Если у вас есть отдельные интенты "не пришел код", "не пришло письмо", "не приходит уведомление" и "проблема со входом", модель начинает гадать по словам, а не по смыслу. Пользователь пишет "не пришло", и бот может выбрать почти что угодно.

Особенно плохо работают пары, где формулировки похожи, а действия разные. Например, "хочу закрыть аккаунт" и "хочу отвязать карту" звучат как запрос на изменение профиля, но последствия у них разные. Если такие интенты учили на пересекающихся примерах, ошибка почти неизбежна.

Откройте список интентов и для каждого ответьте на два вопроса: чем он отличается от соседнего и какое действие запускает. Если разницу трудно объяснить человеку одним предложением, боту тоже будет трудно.

Короткие фразы лучше проверять отдельно. "Не пришло", "не работает", "ошибка", "зависло", "не могу" - это обычные сообщения для пользователя, но ловушки для маршрутизации. Без контекста бот должен не угадывать, а задавать уточняющий вопрос. Если он сразу уходит в один сценарий, вы получаете гладкий, но мимо ответ.

Еще одна слабая точка - сообщения с двумя задачами сразу. Пользователь может написать: "Смените почту и пришлите счет за март". Если система умеет выбрать только один интент на реплику, она почти всегда теряет вторую часть. Потом команда видит жалобу: счет не отправили, хотя бот "понял запрос".

Проверьте вручную хотя бы четыре группы случаев: похожие интенты с разными действиями, короткие фразы без контекста, один и тот же смысл в разных словах и реплики с двумя запросами. Отдельно полезно посмотреть сообщения, где сначала идет жалоба, а потом вопрос. Именно там routing часто ломается.

Хороший тест очень простой. Возьмите 30-50 реальных фраз из логов, уберите персональные данные и дайте их системе без истории диалога. Потом смотрите не только на точность, но и на тип ошибки. Если бот путает соседние интенты, проблема в границах. Если он уверенно классифицирует "не пришло" без уточнения, проблема в политике маршрутизации.

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

Что проверить в базе знаний

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

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

С чего начать проверку

Для начала достаточно пройтись по четырем точкам.

• Если две статьи отвечают на один вопрос, оставьте одну основную версию. Остальные удалите или явно пометьте как архив.
• Общие инструкции держите отдельно от редких исключений. Иначе бот начнет вставлять частный случай туда, где он не нужен.
• У каждой статьи должны быть дата обновления и конкретный владелец. Без владельца статья быстро стареет.
• Поиск нужно проверять на живых формулировках из чатов, а не только на названиях внутренних процессов.

Разделение общего и частного сильно влияет на качество. Если в одной статье смешаны базовый порядок возврата, спорные кейсы, ручные проверки и исключения для отдельных тарифов, бот берет самый заметный кусок текста. В итоге клиент с простым вопросом получает редкий сценарий, который к нему не относится.

Хорошо работает простое правило: одна статья - одна задача. Отдельно лежит общий порядок, отдельно - исключение, отдельно - служебная инструкция для оператора. Так поиск ошибается реже, а ответы становятся короче и точнее.

Проверьте язык, а не только содержание

Люди не пишут так, как статьи называют внутри компании. Клиент спрашивает: "Где моя посылка?", "Почему карта не проходит?", "Как вернуть деньги?". А в базе могут лежать заголовки вроде "Статусы логистического трекинга" или "Обработка отказа авторизации". Формально тема одна, но поиск легко промахивается.

Возьмите 20-30 реальных фраз из обращений и посмотрите, какие статьи система находит первыми. Если наверху оказываются не те материалы, допишите в статьи разговорные формулировки, синонимы и короткие вопросы, которыми люди пользуются в чате. Это простая правка, но она часто дает больше эффекта, чем смена модели.

Когда бот должен отказаться от ответа

Уверенный неверный ответ хуже почти любого честного уточнения. Если бот звучит спокойно и убедительно, а потом уводит человека не туда, проблема не в стиле. Ему просто не стоило отвечать без проверки.

Правило здесь простое: при низкой уверенности бот не гадает. Он не достраивает смысл по одному слову, старому сообщению или похожему кейсу. Если intent routing не дал ясного сигнала, бот прямо говорит, что не понял запрос, и просит уточнить его в одном шаге.

Фраза отказа должна быть короткой и человеческой. Без канцелярита вроде "ваш запрос не может быть обработан". Лучше так: "Не могу точно ответить по этому сообщению. Уточните номер заказа" или "Не вижу достаточно данных. Опишите проблему одной фразой". Такая политика снижает риск и обычно не раздражает пользователя.

После отказа нужен следующий ход. Иначе человек просто повторит тот же вопрос и разозлится еще сильнее. Обычно хватает трех вариантов:

• попросить один недостающий факт;
• предложить выбор из 2-3 тем;
• перевести диалог на сотрудника, если вопрос уже вне сценария.

Отдельно задайте темы, где бот молчит, пока не пройдет проверка данных. Это особенно важно для аккаунта, платежей, возвратов, персональных данных и любых действий, которые меняют доступ или деньги. Для команд, которые работают с требованиями 152-ФЗ, сюда же попадают запросы с паспортными данными, телефонами, адресами и историей заказов.

Хорошее правило звучит так: если ошибка может стоить пользователю денег, доступа или раскрытия чужих данных, бот не импровизирует. Он либо запрашивает проверочный признак, либо зовет человека.

Стоит заранее зафиксировать и стоп-темы. Бот не должен сообщать статус чужого заказа, менять контактные данные без подтверждения, объяснять причины блокировки без проверки личности или давать советы там, где нужен сотрудник с доступом к системе.

Проверить это легко на реальных диалогах. Возьмите несколько сложных обращений и найдите места, где бот ответил гладко, но без фактов. Именно там отказ был бы полезнее любого красивого ответа.

Как провести проверку по шагам

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

Для первой проверки хватает 30-50 диалогов из логов. Берите не только простые вопросы, но и спорные случаи: короткие фразы, сообщения с опечатками, два вопроса в одном, эмоциональные жалобы. Такой набор показывает слабые места быстрее, чем сотня однотипных запросов.

1. Для каждого обращения задайте эталон. Отметьте ожидаемый интент, откуда бот должен взять ответ и какой ответ вы считаете верным. Источник тоже нужно фиксировать: статья базы знаний, карточка товара, CRM, шаблон оператора или осознанный отказ.
2. Прогоните весь набор через текущую схему без ручных правок по ходу. Иначе вы не поймете, где живет ошибка. Сохраняйте для каждого кейса маршрут, найденный источник, текст ответа и факт отказа, если он случился.
3. Отдельно разберите случаи, где бот написал уверенно и вежливо, но ошибся по смыслу. Это самые дорогие ошибки.
4. Для каждой ошибки выберите один тип причины. Обычно проблема одна из трех: роутер отправил запрос не туда, база знаний подтянула не ту статью или бот должен был отказаться от ответа, но не сделал этого.
5. Исправьте только конкретный узел и запустите набор снова. Если дело в intent routing, меняйте правило или классификатор. Если дело в знаниях, правьте статью, заголовок, метаданные или куски для поиска. Если бот не умеет молчать, уточняйте политику отказа и формулировку безопасного ответа.

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

Ошибки, которые повторяются чаще всего

Многие проблемы начинаются еще до того, как модель пишет первый ответ. Команда собирает слишком широкий интент и складывает в него разные запросы, потому что они похожи для человека. Для бота это уже ошибка. Вопросы "не пришел чек", "нужен счет" и "где акт" звучат близко, но ведут в разные сценарии, в разные данные и иногда в разные отделы.

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

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

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

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

• решил ли ответ вопрос с первого раза;
• назвал ли бот точное действие;
• не пропустил ли он ограничение или исключение;
• отправил ли человека туда, где ему правда помогут;
• отказался ли он отвечать, если данных не хватало.

С отказом тоже ошибаются регулярно. Его ставят слишком поздно. Бот уже успевает придумать лишнее, а потом в конце добавляет осторожную фразу вроде "уточните у оператора". Такой ответ хуже честного отказа в первых двух строках, потому что пользователь уже увидел неверный совет и может ему поверить.

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

Простой сценарий из поддержки

Клиент пишет: "Списали деньги дважды, где возврат?" Человек сразу понимает смысл вопроса. Он не спрашивает, как оплатить подписку и какие есть тарифы. Он хочет понять, почему прошло два списания и что делать дальше.

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

Здесь ошибка выглядит как плохой текст, хотя текст ни при чем. Сбой случился раньше - на этапе маршрутизации и поиска.

Обычно проблема состоит из трех частей.

1. Интент "оплата" слишком широкий. В него попадают и возвраты, и двойные списания, и спорные транзакции.
2. База знаний описывает продукт, а не жалобы людей. В ней есть "Как оплатить" и "Тарифы", но нет статей с формулировками вроде "списали дважды".
3. Бот не умеет остановиться. Даже когда найденный ответ не совпадает с вопросом, он все равно продолжает объяснение.

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

После этого перепишите статьи под реальные формулировки клиентов. Добавьте в заголовки и примеры фразы "списали дважды", "когда вернут деньги", "не согласен с платежом". Если бот не уверен между двумя сценариями, пусть задаст один короткий вопрос: "У вас было два списания или вы ждете возврат по одному платежу?"

Такой сценарий полезно прогнать вручную 20-30 раз. Если бот снова уходит в "оплату", не меняйте модель первой. Сначала сузьте интенты, почистите базу знаний и пропишите отказ для случаев со слабым совпадением.

Короткий список проверок перед релизом

Перед релизом лучше смотреть не на то, как бот звучит, а на то, как он ошибается. Самые частые проблемы обычно сидят в трех местах: intent routing, база знаний и политика отказа.

Быстрая проверка занимает немного времени, но часто ловит самые дорогие сбои еще до запуска.

• Прогоните тесты чат-бота поддержки на коротких, длинных и эмоциональных запросах. Пользователи пишут не только "где статус заказа", но и "почему у вас опять ничего не работает, я жду третий день".
• Проверьте каждый интент отдельно. У него должны быть хорошие примеры, явные антипримеры и понятный порог уверенности, после которого бот выбирает этот сценарий.
• Откройте статьи базы знаний и посмотрите на метаданные. У каждой статьи должны быть дата обновления и конкретный ответственный, иначе устаревшие ответы быстро смешаются с актуальными.
• Убедитесь, что бот умеет остановиться. Если он не знает точный ответ, он должен честно это сказать, запросить уточнение или перевести диалог на человека, а не придумывать инструкцию.
• Смотрите не только на точность маршрутизации. Отдельно считайте долю вредных ответов: неверные шаги, выдуманные правила, ложные обещания, опасные советы.

Этого уже хватает, чтобы увидеть слабые места. Например, интент "возврат" может хорошо работать на фразе "хочу вернуть товар", но промахиваться на сообщении "деньги не пришли, заказ забрал курьер". Формально тема рядом, но ответ для пользователя будет мимо.

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

Что делать дальше

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

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

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

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

Если у вас несколько моделей, проверка должна быть одинаковой для всех. Иначе одна модель отвечает аккуратно, другая звучит убедительно, но ошибается чаще, а команда спорит о впечатлениях вместо цифр. В таком случае помогает единый слой доступа к моделям. Если вы тестируете разных провайдеров и при этом держите данные в РФ, RU LLM дает один OpenAI-совместимый эндпоинт, а биллинг и хранение данных остаются внутри РФ. Это удобно именно для сравнения моделей в одном контуре, без разъезда по разным API.

Худшее решение - ждать большого редизайна. Намного полезнее взять один поток, провести ближайший еженедельный разбор и пополнить тестовый набор хотя бы двадцатью живыми примерами. Уже через две-три итерации станет ясно, бот правда начал решать задачи лучше или просто стал звучать увереннее.