В первой версии эталонной сборки поддержки я помещал всю базу знаний в промпт. Модель отвечала уверенно даже тогда, когда документы не подтверждали наличие товара или срок доставки. Текст выглядел пригодным для отправки. Читателю было трудно понять, где заканчивается содержание базы и начинается догадка модели. Обычная проверка на гладкость ответа такой дефект не обнаруживает: выдуманная фраза может звучать совершенно естественно.
Этот разбор относится к эталонной сборке, а не к клиентскому внедрению. Я изменил процесс так, чтобы отсутствие информации стало отдельным результатом обработки. Система сначала находит подходящие документы, затем формирует ответ на их основе. Если найденного материала недостаточно, вопрос передаётся человеку. Пользователю нужно понятно объяснить этот переход, иначе технически корректный отказ всё равно оставит его без следующего шага.
Правила доставки не показывают местонахождение заказа
Вопрос «Где мой заказ?» кажется обычным вопросом поддержки. Документ о доставке может описать порядок работы, нужный для поиска номер заказа и дальнейшие действия покупателя. Однако из него нельзя узнать, покинул ли конкретный заказ склад. Для этого нужен источник с текущим состоянием именно этого заказа. Общая формулировка о сроках не превращается в подтверждение отправки только потому, что подходит по теме.
В измеренном прогоне 6 сентября 2026 года бот запросил номер в формате NV-XXXXX и указал использованный документ. Статус заказа он не выдумал. Ответ занял 2,6 секунды в одном прогоне. Этот замер описывает одно выполнение; он не задаёт гарантированное время для всех запросов и не доказывает, что любой вопрос будет обработан правильно.
Запросить недостающий идентификатор в такой ситуации полезно. Если после этого ответ всё ещё нельзя подтвердить документами или разрешённой интеграцией, нужен оператор. Продолжение диалога с более уверенными формулировками не добавляет сведений о заказе. В приёмке важно проверять и этот следующий шаг, поскольку первый уточняющий вопрос сам по себе ещё не означает, что обращение можно закрыть.
Неуверенность должна менять маршрут
Инструкция «не выдумывай» не определяет, что делать с запросом, для которого нет ответа. В этой сборке модель возвращает явный флаг insufficient. Сценарий использует его, чтобы запустить передачу человеку и не публиковать предположение как подтверждённую информацию. Такое решение можно увидеть в логе и проверить отдельно от того, насколько убедительно написан текст.
Сначала флаг срабатывал слишком редко: модель предпочитала закончить ответ. Пришлось явно поощрять отказ при недостаточном материале и проверять вопросы за пределами базы знаний. Если тестировать только вопросы с очевидным ответом в документах, проблемная ветка почти не проверяется. Удачный демонстрационный разговор тогда создаёт впечатление готовности, хотя поведение в сложном случае остаётся неизвестным.
Требование к источнику относится к конкретному утверждению. Найденный документ может содержать слова из вопроса и при этом не подтверждать ответ. Например, правила возврата описывают процедуру, но не доказывают, что определённый возврат уже согласован. При проверке я сопоставляю утверждение с найденным фрагментом. Тематическое совпадение полезно для поиска, но недостаточно для обещания клиенту.
После отказа нужен ответственный
Сообщение «не знаю» без продолжения заставляет покупателя начинать заново. В эталонном сценарии интерфейс сообщает, что подключается человек через согласованный канал, а обращение попадает в очередь операторов. Этот путь используется и при недоступности провайдера модели. Пользователь не должен разбираться в технической ошибке, чтобы понять, кто будет заниматься его вопросом дальше.
У этой сборки ограниченный объём: бот отвечает и передаёт обращения. Он не отменяет заказы, не делает возвраты денег и не меняет записи заказов. Такие действия потребовали бы отдельного проекта и отдельных прав. Явная граница помогает проверять ответы без скрытого предположения, будто правдоподобная фраза одновременно разрешает системе выполнить операцию с деньгами.
Источник должен быть понятен читателю
Ранняя версия интерфейса показывала технические идентификаторы документов. Для внутренней отладки они были полезны, но покупатель не понимал, что стоит за таким обозначением. Я заменил их читаемыми названиями разделов. Ссылка на источник должна помогать найти основание ответа. Сам по себе внутренний идентификатор эту задачу не решал, даже если технически указывал на правильный документ.
Повторяющиеся вопросы с флагом insufficient дают список для доработки базы. По нему видно, каких сведений не хватает и где стоит уточнить порядок передачи оператору. Такой отчёт не превращает вопросы в утверждённые ответы автоматически. Ответственный человек должен добавить информацию и проверить её, прежде чем система начнёт использовать новый материал в разговоре с покупателем.
В кейсе поддержки описаны схема, обработка сбоев и разница между измеренным временем ответа и плановой долей решённых обращений. В приёмку входят вопросы, на которые документы не отвечают. Они проверяют маршрут к человеку и позволяют увидеть, сохраняется ли обращение после отказа модели отвечать самостоятельно.