Практика внедрения · 10 минут на чтение

Как подготовить базу знаний для ИИ-ассистента: структура, качество и запуск

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

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

Сначала определить задачу и границы базы знаний

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

Зафиксируйте в техническом задании четыре пункта:

• Сценарий. Что спрашивает пользователь и какое действие следует за ответом.
• Источники. Какие документы считаются официальными, а какие используются только как справочные.
• Ограничения. Что ассистент не имеет права обещать, менять или отправлять без подтверждения человека.
• Ответственный. Кто обновляет материалы и принимает решение, какой документ является действующим.

Границы особенно важны, если ассистент работает с персональными или коммерчески чувствительными сведениями. Правила доступа, срок хранения и маршрут данных лучше определить до загрузки документов — это продолжение чек-листа безопасности при внедрении ИИ.

Провести инвентаризацию документов

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

Архивные файлы не обязательно удалять навсегда, но их нельзя оставлять наравне с действующими. Перенесите их в отдельное хранилище или явно пометьте как архив. Иначе поиск может вернуть старое условие рядом с новым, а пользователь не поймёт, какому из них доверять.

Собрать структуру, которую понимают и люди, и поиск

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

Практичная карточка документа может выглядеть так:

1. Короткий ответ. Формулировка для первого сообщения ассистента.
2. Условия и исключения. Когда правило не применяется и что нужно уточнить.
3. Пошаговое действие. Что делает сотрудник после ответа.
4. Источник. Ссылка, номер версии или название утверждённого регламента.
5. Владелец и дата пересмотра. Контакт для исправлений и плановая проверка.

Не превращайте документы в набор ключевых слов. Ассистенту нужен естественный контекст: определения, примеры, ограничения и связи между сущностями. Если термин имеет несколько значений, добавьте пояснение. Например, «активный клиент» должен быть описан через условие, а не оставлен на усмотрение модели.

Проверить качество, версии и противоречия

Перед индексацией проведите редакторскую и операционную проверку. Уберите дубли, незаполненные шаблоны, комментарии для внутреннего обсуждения и файлы с тестовыми данными. Проверьте, что таблицы, списки и сканы действительно читаются системой поиска. Для сканов понадобится распознавание текста, а для сложных таблиц — отдельный тест извлечения.

Минимальный контроль качества включает:

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

Если в разных отделах действуют разные условия, не «усредняйте» их в одном абзаце. Разделите материалы по продукту, региону или роли пользователя и добавьте правило выбора источника. Такая детализация снижает риск ответа, который звучит убедительно, но относится к другой ситуации.

Настроить поиск и правила ответа

В большинстве проектов база знаний подключается к поиску по смыслу: система находит подходящие фрагменты и передаёт их модели вместе с запросом. Качество зависит не только от модели, но и от размера фрагмента, метаданных и порога релевантности. Слишком маленькие фрагменты теряют контекст, слишком большие подтягивают в ответ соседние правила.

На старте задайте простые ограничения:

• ассистент отвечает только по найденным источникам и сообщает, если данных недостаточно;
• в каждом ответе указывается название документа или ссылка на источник;
• при конфликте версий приоритет получает действующий документ с более узкой областью применения;
• опасные или необратимые действия передаются сотруднику на подтверждение;
• вопросы вне области базы знаний маршрутизируются в поддержку, а не заполняются догадкой.

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

Запустить пилот и измерить результат

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

Полезные метрики для первых двух недель:

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

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

Когда база знаний готова и сценарий подтверждён, можно переходить к интеграции с CRM и оценке бюджета. Подход к затратам разобран в статье «Стоимость ИИ-ассистента: из чего складывается бюджет».

Итог: база знаний — это управляемый продукт

Рабочая база знаний состоит не из максимального числа файлов, а из проверенных источников с владельцами, версиями и понятной областью применения. Сначала ограничьте сценарий, затем проведите инвентаризацию, уберите противоречия, настройте правила ответа и только после этого расширяйте набор документов. Такой порядок сокращает риск дорогой переделки и помогает измерить пользу ИИ-ассистента уже на первом пилоте.