RAG-чатбот для внутренних команд: чек-лист
Внутренний ассистент, который отвечает по базе знаний компании, кажется простым проектом. На практике большинство таких ботов перестают использовать через месяц. Собрали чек-лист, который помогает этого избежать.
RAG — это подход, при котором языковая модель отвечает не «из головы», а опираясь на найденные в вашей базе документы. Регламенты, инструкции, договоры, переписка с клиентами — всё это может стать источником ответов для сотрудников. Ниже то, что мы проверяем перед запуском каждого такого проекта.
1. Данные
Есть ли актуальная база знаний, или половина регламентов устарела?
Кто отвечает за обновление документов после запуска?
Есть ли документы, которые нельзя показывать всем сотрудникам? Права доступа нужно учесть с первого дня.
2. Сценарии
Начинайте с двух-трёх конкретных сценариев, а не с «бота, который знает всё». Например: ответы на вопросы новых сотрудников, поиск по договорам, подсказки для поддержки. Для каждого сценария соберите 30–50 реальных вопросов — это будущий набор для проверки качества.
3. Качество ответов
Каждый ответ сопровождается ссылкой на источник.
Если ответа в базе нет, бот честно говорит «не знаю», а не придумывает.
Перед запуском прогоните тестовый набор вопросов и оцените ответы вручную.
Бот, который уверенно ошибается, хуже, чем отсутствие бота. Им просто перестанут доверять.
4. Встраивание в работу
Ассистент должен жить там, где сотрудники и так проводят время: в корпоративном мессенджере, в CRM, в интерфейсе поддержки. Отдельный сайт, на который нужно заходить, используют в разы реже.
5. Обратная связь и метрики
Кнопки «помогло / не помогло» под каждым ответом.
Еженедельный разбор вопросов, на которые бот не ответил: это готовый список пробелов в базе знаний.
Метрики: доля вопросов с ответом, доля положительных оценок, количество активных пользователей в неделю.
6. Безопасность
Определите заранее, где хранятся данные и куда они передаются. Для чувствительной информации может потребоваться модель, развёрнутая внутри контура компании. Это влияет на стоимость и сроки, поэтому решать вопрос нужно до старта разработки, а не после.
Журнал