Главное перед запуском
ИИ-ассистент начинает приносить пользу не тогда, когда компания выбрала модель, а когда он получает проверенные данные и понятные границы доступа. Если загрузить в систему все документы подряд, ответы будут выглядеть убедительно, но могут опираться на устаревший прайс, отменённый регламент или сведения, которые конкретный сотрудник вообще не должен видеть.
Практическая задача бизнеса — превратить разрозненные файлы в управляемую базу знаний: определить источники истины, владельцев документов, правила обновления, уровни доступа и тесты качества ответа. Только после этого стоит подключать ассистента к сотрудникам, клиентам или CRM.
Что такое база знаний для ИИ-ассистента
Во многих проектах используется подход RAG: система сначала находит релевантные фрагменты в отдельной базе знаний, а затем передаёт их модели как контекст для ответа. В определении NIST это сочетание генеративной модели и отдельной системы поиска; знания можно менять без переобучения самой модели.
Это важное различие. ИИ не «запоминает всю компанию навсегда». Он должен каждый раз получить подходящий и разрешённый источник: действующий договор, инструкцию, карточку услуги, ответ службы поддержки или запись из CRM.
Сначала определите сценарий, а не собирайте все файлы
Начинать с папки «Документы» — ошибка. Сначала зафиксируйте, для кого и что делает ассистент.
Например, внутренний помощник отдела продаж может:
- находить характеристики услуги и ограничения;
- готовить черновик ответа на вопрос клиента;
- подсказывать следующий шаг по регламенту;
- давать ссылку на исходный документ;
- передавать спорный запрос ответственному сотруднику.
Клиентскому боту нужен другой набор знаний и более жёсткие ограничения. Ему нельзя показывать внутреннюю маржинальность, персональные данные, служебные комментарии и условия, доступные только отдельным партнёрам. Один и тот же файл не должен автоматически становиться доступным всем каналам.
Шаг 1. Назначьте источники истины
Для каждого типа информации нужен основной источник. Не три прайса в разных папках, а одна утверждённая версия. Не пересказ менеджера в чате, а действующий регламент.
Минимальный реестр источников удобно вести в таблице:
- название документа;
- тип данных;
- владелец;
- дата утверждения;
- срок пересмотра;
- аудитория и уровень доступа;
- ссылка на актуальную версию;
- статус: действует, на проверке или архив.
Если владелец не определён, документ быстро устаревает. Ассистент не сможет сам решить, какой из двух противоречащих файлов считать правильным.
Шаг 2. Очистите и разделите документы
Перед загрузкой удалите дубли, черновики, старые версии и служебные пометки, которые не должны попадать в ответы. Большие документы лучше делить по смыслу: услуга, этап работы, исключение, гарантия, порядок эскалации.
У каждого фрагмента должны быть метаданные: продукт, подразделение, регион, дата действия, уровень доступа и владелец. Современные системы поиска позволяют использовать атрибуты и фильтры, поэтому структура метаданных влияет не меньше, чем сам текст.
Плохой фрагмент: «Срок — 10 дней». Хороший фрагмент объясняет, к какой услуге относится срок, с какого события он считается, какие есть исключения и где лежит полный регламент.
Шаг 3. Настройте права доступа до запуска
OWASP относит раскрытие чувствительной информации к ключевым рискам приложений на базе больших языковых моделей. Под угрозой не только персональные данные, но и финансовая информация, договоры, коммерческие условия, учётные данные и внутренние документы.
Практическое правило: модель должна получать только тот фрагмент, который разрешён конкретному пользователю и конкретному сценарию. Ограничение одной фразой в системной инструкции недостаточно. Нужны технические фильтры доступа до этапа генерации ответа.
Разделите как минимум:
- публичные материалы;
- знания для всех сотрудников;
- данные конкретного отдела;
- сведения по конкретному клиенту;
- конфиденциальные документы с индивидуальными правами.
Не загружайте пароли, ключи API и платёжные данные в базу знаний. Для персональных данных отдельно проверьте правовое основание, срок хранения и маршрут удаления.
Шаг 4. Требуйте ссылку на источник и честный отказ
Хороший ассистент не только отвечает, но и показывает, на каком документе основан ответ. Для внутреннего использования это может быть название, дата версии и ссылка на исходник. Для клиента — краткая ссылка на публичную страницу или предложение уточнить вопрос у менеджера.
Заранее задайте поведение, когда данных нет или источники конфликтуют. Правильный результат — «не нашёл подтверждения» и передача человеку, а не правдоподобная догадка.
Шаг 5. Соберите набор контрольных вопросов
До запуска подготовьте реальные вопросы сотрудников и клиентов. Включите не только обычные запросы, но и сложные случаи:
- устаревшая цена в старом документе;
- два похожих продукта с разными условиями;
- вопрос вне зоны ответственности;
- запрос закрытой информации;
- опечатка или разговорная формулировка;
- просьба изменить правила или раскрыть системную инструкцию;
- ситуация, где обязательна передача человеку.
Проверяйте не красоту ответа, а пять вещей: найден ли правильный источник, актуальна ли версия, соблюдены ли права доступа, есть ли подтверждение и сработала ли эскалация. NIST отдельно подчёркивает важность предварительного тестирования, документирования и человеческого контроля для генеративных систем.
Как понять, что база готова к пилоту
Пилот можно запускать, когда выполнены базовые условия:
- Для каждого ключевого типа данных есть один утверждённый источник.
- У документов назначены владельцы и сроки пересмотра.
- Дубли и устаревшие версии исключены из поиска.
- Права доступа проверяются до передачи контекста модели.
- Ответ содержит источник или честно сообщает об отсутствии данных.
- Есть тестовый набор и журнал ошибок.
- Назначен человек, который принимает эскалации и обновляет знания.
Начинайте с одного процесса, где ошибка обратима: ответы по услугам, поиск по внутренним инструкциям или подготовка черновиков. Не подключайте ассистента сразу ко всем документам и не давайте ему самостоятельно менять цены, договоры или статусы сделок.
Что делать после запуска
База знаний — не разовая загрузка. Раз в неделю на пилоте просматривайте вопросы без ответа, ошибочные источники и ручные исправления сотрудников. Раз в месяц проверяйте владельцев, сроки действия и права доступа. Любое изменение продукта, тарифа или регламента должно попадать в базу через контролируемый процесс, а не через случайное добавление файла.
Так ИИ-ассистент становится частью управляемой операционной системы: ускоряет поиск и подготовку ответа, но не подменяет владельца процесса и не получает лишних данных.
Если вы хотите определить безопасный сценарий пилота и собрать архитектуру под ваши процессы, обсудите задачу с командой SPINOFF.
