Как подготовить базу знаний для ответов чат-бота
Шаблон карточки ответа для поддержки: источник, владелец, версия и исключения. Как проверить ответы бота и вовремя обновлять базу знаний.
Начните с одного типа клиентских вопросов, для которого уже есть утверждённый ответ. Запишите сам ответ, ссылку на правило, владельца и дату пересмотра. Затем задайте вопрос несколькими способами и проверьте, нашёл ли помощник нужный источник и не добавил ли условий от себя. Если источника нет или версии противоречат друг другу, оставьте ответ сотруднику. Этот порядок пригодится и без ИИ: сотрудники смогут пользоваться теми же карточками как внутренним FAQ.
Руководителю сервиса не нужно сначала превращать весь архив компании в базу. Важно определить, на какие вопросы вы хотите отвечать, и убедиться, что документы действительно содержат ответы на них. Такой порядок подготовки вопросов, документов и тестовых запросов описан в руководстве Microsoft по RAG. Ниже — рабочий шаблон для службы поддержки, а не инструкция по настройке конкретной платформы.
1. Выберите вопрос с ясной границей
Возьмите повторяющийся вопрос, ответ на который не зависит от договора, личности клиента или неописанного исключения. Например: «Где находится действующая инструкция по оформлению возврата?» Сначала решите, что система должна сделать: дать ссылку на инструкцию, подготовить черновик для сотрудника или передать обращение. Если вопрос о том, положен ли возврат именно этому клиенту, одной общей инструкции может не хватить.
Запишите также запрет: какие обещания бот не должен делать на основании этой карточки. Не включайте в исходный набор переписку с клиентами или закрытые документы только потому, что они лежат рядом с FAQ. Состав и доступ к данным проверяет владелец процесса до загрузки в выбранную систему. Документация Microsoft по RAG отдельно отмечает необходимость контроля доступа к извлекаемому содержимому и риск раскрытия чувствительной информации при неверной настройке.
2. Сделайте карточку ответа
Для начала хватит одной карточки для одного повторяющегося вопроса. Скопируйте таблицу и заполните её своими данными:
| Поле | Что записать |
|---|---|
| Вопрос и варианты | Как клиент спрашивает; синонимы и неполные формулировки без личных данных. |
| Утверждённый ответ | Короткий текст или ссылка; условия, при которых он верен. |
| Первоисточник | Адрес документа или страницы, раздел и действующая версия. |
| Владелец | Кто вправе подтвердить и изменить правило. |
| Проверено / пересмотреть | Дата проверки и событие для новой проверки: изменение услуги, цены, порядка работы. |
| Исключение и маршрут | При каких словах или обстоятельствах нужен сотрудник; какой контекст ему передать. |
| Статус | Черновик, утверждено, на пересмотре или снято. В ответах использовать только утверждённую версию. |
Не подменяйте «источник» ссылкой на черновик ответа самого бота. Чтобы сотрудник мог сверить ответ с документом, сохраняйте название и адрес исходного документа: индекс RAG может хранить поля вроде названия и URL для ссылок на источник, как описано в документации Microsoft. Это техническая возможность конкретной схемы; у выбранного продукта её нужно проверить во время демонстрации.
3. Разберите конфликты до загрузки
Если в FAQ написан один срок, а в инструкции отдела — другой, нельзя выбирать более удобную цифру. В карточке поставьте «на пересмотре», укажите оба документа и передайте противоречие владельцу правила. После решения он указывает действующую версию, снимает устаревшую и сообщает об изменении тем, кто отвечает клиентам.
Учебный пример, не клиентский кейс. На сайте указано: «Порядок возврата — в разделе „Помощь“». В старом файле отдела хранится иной путь. Карточка остаётся на пересмотре, пока владелец не подтвердит нужную ссылку. После подтверждения бот может дать путь к инструкции, но вопрос о возврате по конкретному заказу всё равно передаёт сотруднику, если нужны данные заказа или решение об исключении.
4. Проверьте ответ и обновление
Для каждой карточки подготовьте несколько разрешённых тестовых вопросов: обычную формулировку, разговорную, неполную, вопрос об исключении и вопрос, на который база не отвечает. Зафиксируйте версию базы и ожидаемое действие до прогона. Проверяющий отмечает отдельно: найден ли нужный источник, верно ли переданы условия, появилась ли выдуманная деталь, нужна ли передача человеку. Если источник отсутствует, удачная на вид фраза не считается подтверждённым ответом. Даже при использовании найденных документов ответ может быть неточным, если поиск вернул неполный фрагмент; это ограничение описывает Microsoft.
После изменения правила проверьте не только исходный файл, но и то, какой ответ система выдаёт теперь. В Amazon Bedrock, например, добавленные, изменённые и удалённые файлы требуют синхронизации источника, чтобы обновить базу; это прямо указано в документации AWS. В другой системе механизм может быть иным. В тестовом сценарии проверьте, что старый ответ исчез, а действующий ссылается на подтверждённую версию.
Удобно вести короткий журнал: карточка → что изменилось → кто утвердил → когда обновили источник → контрольный вопрос → результат. Если нет человека, который обновляет правила, начните с внутреннего FAQ и шаблонов ответов для сотрудников. Автоответ имеет смысл обсуждать после того, как карточки можно поддерживать в актуальном состоянии.
После подготовки базы решите, какие ответы поручить боту, а какие передавать человеку. Тот материал посвящён маршруту обращения; здесь вы подготовили проверяемый источник для такого маршрута.