Как подготовить базу знаний для AI-бота

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

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

AI хуже работает с «свалкой файлов», чем с системным набором документов. Поэтому важно не только собрать материалы, но и привести их к логичной структуре: отдельные темы, единые названия, предсказуемые форматы и понятные связи между материалами.

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

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

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

Проверять нужно не то, насколько красиво написан документ, а способен ли AI на его основе ответить на реальный запрос пользователя. Для этого полезно собрать набор тестовых вопросов из истории обращений и прогонять по нему обновления базы знаний.

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

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

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