Как подготовить документы к ИИ-консультанту

Большой архив сам по себе не становится базой знаний. Сначала определите один рабочий сценарий: кто задаёт вопрос, какое решение должен принять сотрудник и какой документ подтверждает ответ.

• Выберите одно подразделение и 20–50 часто используемых материалов.
• Назначьте владельца каждого документа.
• Отделите действующие версии от архивных и черновых.

Документ должен иметь понятное название, дату, версию и область применения. Таблицы, приложения и исключения нужно сохранить: именно в них часто находится условие, меняющее ответ.

• Уберите дубли с разными именами файлов.
• Проверьте качество сканов и распознавание текста.
• Зафиксируйте, какой источник имеет приоритет при противоречии.

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

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

Не все материалы одинаково пригодны для ИИ-консультанта. Регламент с чёткой структурой даст точные ответы почти сразу; переписка в чате — почти никогда. Перед загрузкой разделите документы по типу и решите, что с каждым типом делать.

ИИ-консультант не читает документ целиком при каждом вопросе. Он находит фрагменты, похожие на вопрос, и отвечает по ним. Значит, каждый фрагмент должен быть понятен сам по себе. Раздел «Исключения» без заголовка «Возврат товара» — это фрагмент, который система найдёт и не поймёт, к чему он относится.

Практически это означает три вещи. Заголовки должны называть тему, а не номер пункта: «3.2. Порядок возврата» лучше, чем «3.2». Таблицы не должны разрываться: условие в одной строке, а сумма — в другой, разнесённой на страницу. Ссылки внутри документа («см. приложение 4») должны быть либо развёрнуты, либо приложение должно быть загружено с тем же названием.

У каждого документа должны быть записаны: владелец, дата утверждения, дата следующего пересмотра, область применения (подразделение, регион, категория товара) и приоритет при противоречии с другими. Это не бюрократия: когда два документа отвечают на один вопрос по-разному, система должна знать, какой из них главнее, — иначе она выберет случайный или «усреднит» ответ, что хуже.

• Владелец — конкретный человек, не отдел. К нему приходит вопрос «это ещё действует?».
• Область применения — чтобы сотрудник розницы не получил ответ по регламенту опта.
• Приоритет — числом или списком: «при противоречии действует более поздний документ того же уровня».
• Дата пересмотра — чтобы документы без движения год не считались действующими по умолчанию.

Пилот имеет смысл, когда база небольшая, но чистая. Лучше 30 проверенных документов, чем 300 «всех, что были». По этому списку можно проверить готовность за час.

• Один сценарий и одно подразделение выбраны; вопросы сотрудников собраны — 30–50 реальных.
• У каждого документа есть владелец, дата, версия, область применения.
• Дубли и устаревшие версии удалены или помечены.
• Сканы распознаны и проверены выборочно — хотя бы по одной странице из каждого.
• Матрица прав составлена; три пограничных случая проверены.
• Для каждого контрольного вопроса записан эталон: какой документ, какой раздел, что должно прозвучать.
• Назначен человек, который читает отчёт о вопросах без ответа раз в неделю.

База знаний устаревает быстрее, чем кажется: меняется прайс, выходит новый регламент, увольняется владелец документа. Если этим не управлять, консультант через полгода будет уверенно отвечать по прошлогодним правилам — и это хуже, чем отсутствие консультанта, потому что ему верят.

Минимальный режим: еженедельный отчёт о вопросах, на которые система не нашла источник или ответила с низкой уверенностью, — это список пробелов в базе. Ежемесячно — проверка документов с истёкшей датой пересмотра. При каждом изменении регламента — замена документа в базе тем же днём, а не «когда дойдут руки». Ответственный за это — один человек с правом удалять и добавлять, и его имя известно всем, кто пишет регламенты.