Статья
Как собрать базу знаний для ИИ-администратора
Качество ответов начинается не с промпта, а с коротких, проверяемых и регулярно обновляемых источников.
Начните с инвентаризации, а не копирования сайта
Информация обычно разбросана между сайтом, прайсом, таблицами, переписками и памятью сотрудников. Составьте реестр: название источника, владелец, дата проверки, темы и приоритет при конфликте. Не загружайте всё подряд. Старые коммерческие предложения и внутренние обсуждения могут противоречить действующим условиям. Для каждого важного факта должен существовать один утверждённый источник. Если истину пока нельзя установить, отметьте пробел и настройте передачу человеку вместо выбора удобной версии.
Храните знания небольшими карточками
- 01. ТемаОднозначное название услуги или правила и варианты клиентских формулировок.
- 02. ОтветКороткий подтверждённый факт без рекламных вступлений и скрытых исключений.
- 03. УсловияКогда ответ применим, какие уточнения обязательны и что нельзя обещать.
- 04. УправлениеИсточник, владелец, дата проверки, версия и событие для следующего обновления.
Отделите справку от быстро меняющихся данных
Описание подготовки к визиту можно хранить в базе знаний. Свободные окна, остаток товара и статус заказа нужно получать из системы непосредственно перед ответом. Цена бывает обоих типов: фиксированный тариф хранится как утверждённый факт, индивидуальный расчёт требует параметров и участия сотрудника. Такое разделение защищает от устаревших ответов. Интеграция тоже должна сообщать статус честно: если расписание не ответило, администратор не подтверждает запись и предлагает резервный путь. Для динамического значения фиксируйте систему-источник и время получения, чтобы сотрудник мог проверить спорный ответ.
Пример: база знаний языковой школы
Школа начала с большого документа, где смешались программы, заметки преподавателей и прошлогодние акции. На тестах помощник предлагал отменённую скидку. Команда разделила материал на карточки курсов: возраст, уровень, формат, длительность занятия, подготовка, способ расчёта и ограничения. Акции вынесли в отдельный источник с датой окончания, расписание подключили динамически. У каждой программы появился методист-владелец. Вопрос о переводе между группами не получил универсального ответа: система собирала текущий уровень и контакт, затем передавала координатору. Обновление одной программы перестало требовать перечитывать весь документ.
Сделайте обновление частью процесса
Назначьте события пересмотра: изменение прайса, запуск услуги, смена адреса, новая политика возврата. Система должна хранить дату и автора правки, а критичные изменения проходить проверку вторым человеком. Регулярно просматривайте вопросы, на которые ответа не нашлось, и частые передачи — это очередь улучшения базы. Не добавляйте ответ только по одному странному диалогу: сначала подтвердите правило у владельца. После публикации новой версии прогоните связанные эталонные вопросы и убедитесь, что старое условие больше не появляется. Удаление тоже должно быть управляемым: архивируйте карточку с причиной, чтобы отменённое условие нельзя было случайно вернуть из старого файла. Раз в период проверяйте ссылки на первоисточники и карточки без владельца — именно они быстрее всего становятся ненадёжными.
Частые вопросы
Можно ли использовать страницы сайта как базу?
Можно как один из источников, если они актуальны. Для ответов часто нужны явные условия и служебные границы, которых на странице нет.
Кто должен редактировать знания?
Владелец процесса подтверждает факты, а редактор приводит их к ясному формату. Разработчик не назначает цены и правила.
Нужно ли хранить все переписки?
Нет. Извлекайте обезличенные темы и пробелы, соблюдая цель обработки и срок хранения данных.