Определить роль консультанта
Перед выбором модели нужно описать задачу: объяснять услуги, помогать выбрать направление, отвечать на организационные вопросы или готовить передачу обращения. Чем яснее роль, тем проще определить допустимый ответ и проверить результат. Формулировка «пусть отвечает на всё» не задаёт ни границ, ни критерия полезности.
Уточните каналы, язык, тон и условия передачи человеку. Отдельно опишите чувствительные вопросы и факты, которые нельзя достраивать: цены, доступность, ограничения, документы, гарантии. Если консультант собирает обращение, заранее определите нужные данные и реальный способ передачи сотруднику. Внешний вид виджета не заменяет этот процесс.
Что делает RAG
RAG связывает генерацию ответа с поиском релевантных материалов. Сначала система извлекает подходящий контекст из базы, затем использует его при подготовке ответа. Это помогает опираться на документы организации, которые модель сама по себе может не знать или помнить неточно.
Качество зависит от нескольких этапов: состава источников, их обработки, поиска, объёма найденного контекста и правил ответа. Microsoft отдельно рассматривает качество извлечения и соблюдение доступа к материалам. Поэтому подключение RAG не устраняет все ошибки автоматически. Система может найти не тот фрагмент, получить противоречивые сведения или не увидеть нужное условие.
Подготовить проверяемую базу знаний
Начните с утверждённых страниц услуг, условий, FAQ и документов. Для каждого источника важны владелец, дата актуальности и назначение. Устаревшие предложения нужно удалить или явно отделить от действующих. Если один документ противоречит другому, конфликт сначала разрешают в самом бизнесе: модель не должна случайно выбирать удобную версию.
Деление материала на фрагменты должно сохранять смысл. Цена без названия варианта или исключение без основного правила создают риск неверного ответа. Полезно связывать фрагмент с адресом первоисточника, чтобы результат можно было проверить. Внутренние материалы с ограниченным доступом нельзя превращать в публичный источник только ради удобства поиска.
Отделить ответы от действий
Консультант, который только объясняет услугу, и агент, который меняет запись в CRM, требуют разных прав. Для действий через API задаются конкретные операции, проверки входных данных и условия подтверждения. Общий доступ к сервису без ограниченного сценария делает контроль сложнее.
Повторы, ошибки и отмены проектируют заранее. Один запрос не должен случайно создавать несколько обращений. Если внешняя система недоступна, посетитель должен получить честное сообщение и запасной канал связи. В журнале полезно сохранять технический статус и причину передачи сотруднику, соблюдая правила работы с пользовательскими данными.
Проверить обычные и сложные вопросы
Набор приёмочных запросов собирают из реальных обращений и пограничных ситуаций. Для каждого вопроса фиксируют допустимые факты, нужный источник и условие передачи человеку. Оценка «звучит уверенно» недостаточна: ответ может быть хорошо написан и при этом неправилен.
Проверяйте, как консультант реагирует на отсутствие информации, устаревший материал, неоднозначный вопрос и попытку изменить правила. Если источник не содержит цену, система не должна её придумывать. Если вопрос выходит за разрешённый сценарий, нужен понятный маршрут к сотруднику, а не длинный вымышленный совет.
Начать с ограниченного пилота
Выберите один полезный сценарий и сопоставьте качество ответов с затратами на поддержку. После запуска база требует обновления, а новые вопросы становятся материалом для следующей проверки. Масштабировать стоит подтверждённый процесс, сохраняя условия контроля и ответственность за источники.
- Какие вопросы консультант решает самостоятельно.
- Какие источники считаются действующими и кто их обновляет.
- Какие данные и действия разрешены.
- Когда и как подключается сотрудник.
- Какие ошибки блокируют выпуск и как организован контроль после него.
О подходе и составе работы: ИИ-системы и автоматизация для бизнеса ↗
