База знаний для ИИ-агента: что собрать до внедрения

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

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

База знаний для ИИ-агента начинается с разбора источников. Нужно понять, какой документ отвечает на какой вопрос, кто подтверждает его актуальность, кому разрешено видеть данные и что агент должен делать, если ответа нет. Ниже - практический маршрут подготовки. Он поможет подойти к внедрению ИИ в компанию с понятным набором материалов, а не с архивом «посмотрите всё».

Быстрый ответ: что должно быть готово

До технической настройки соберите восемь вещей.

Если половину строк пока некому заполнить, рано спорить о модели и векторной базе. Сначала назначьте владельцев решений.

База знаний не равна обучению модели

Фразу «обучить ИИ на данных компании» часто понимают буквально. Будто документы меняют саму модель и она навсегда запоминает содержимое. Во многих рабочих решениях процесс устроен иначе.

Документы индексируются, система находит подходящие фрагменты по запросу и передаёт их модели вместе с вопросом. Такой подход называют RAG - генерацией с поиском по внешней базе. Например, в Retrieval API OpenAI файлы в векторном хранилище автоматически разбиваются на фрагменты, получают представление для поиска и индексируются.

Практический вывод простой: качество ответа зависит не только от модели. Важно, какой фрагмент нашёл поиск, не устарел ли он, имеет ли пользователь право его видеть и что система делает при конфликте источников.

Начните с одной роли и одного процесса

Не собирайте базу знаний всей компании «на будущее». Выберите один рабочий маршрут. Например:

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

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

Семь групп материалов для базы

Удобно собирать источники не по папкам, а по назначению.

Факты о продукте и компании

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

Регламенты и рабочие правила

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

Частые вопросы и реальные формулировки

Вопросы из обращений показывают, как люди говорят на самом деле. «Какие условия расторжения?» и «как выйти из договора?» могут вести к одному источнику, но для поиска это разные формулировки. Перед использованием переписок удалите персональные и лишние внутренние данные.

Примеры принятого результата

Хороший ответ, заполненная карточка, согласованное письмо или правильно разобранная заявка помогают описать критерии качества. Пример не заменяет правило, но показывает, как оно выглядит в работе.

Исключения и запреты

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

Словарь компании

Одинаковые слова могут означать разные вещи в продажах, производстве и финансах. Зафиксируйте термины, сокращения, названия продуктов и нежелательные формулировки. Это уменьшает путаницу в поиске и ответах.

Данные из рабочих систем

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

Соберите реестр источников

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

Не прячьте поле «владелец» за названием отдела. Нужен человек или понятная должность, которая может сказать: «Да, это действующая версия».

Определите источник истины

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

Для каждой изменчивой темы назначьте один источник истины:

• цены - действующий прайс или учётная система;
• статус заказа - CRM или система доставки;
• правила возврата - утверждённая политика;
• продуктовые ограничения - актуальная спецификация;
• допустимый стиль ответа - редакционный регламент;
• полномочия сотрудника - матрица ролей и доступов.

Остальные материалы могут объяснять тему, но не должны спорить с главным источником. Если конфликт обнаружен, система должна отметить его и остановить уверенный ответ по спорному факту.

Нарисуйте карту доступа до загрузки файлов

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

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

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

Не помещайте пароли, токены и ключи в документы, промпты и примеры. Секреты хранятся отдельно и выдаются системе штатным способом.

Подготовьте документы к поиску

Сложная верстка выглядит аккуратно для человека, но не всегда помогает поиску. Перед загрузкой приведите материал к понятной структуре.

1. Один документ - одна тема или один устойчивый процесс.
2. Заголовок прямо отвечает, о чём материал.
3. В начале указаны назначение, владелец и дата актуальности.
4. Таблицы и списки имеют понятные заголовки столбцов.
5. Скан без распознанного текста заменён на текстовую версию.
6. Повторяющиеся колонтитулы, меню и рекламные блоки удалены.
7. Ссылки и вложения подписаны по смыслу.
8. Старая версия вынесена из рабочего набора, но сохранена в архиве.

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

Отделите знания от инструкций и действий

В рабочем агенте смешиваются три разных слоя.

Документ может объяснять, что заявку нужно создать. Это ещё не означает, что агенту разрешено нажимать кнопку в CRM. Права на чтение базы и права на действие настраиваются отдельно.

Такое разделение стоит зафиксировать и в техническом задании на ИИ-агента. Иначе «умеет отвечать» незаметно превращается в «может менять данные».

Соберите проверочный набор до пилота

Приёмка не должна начинаться с вопроса «ну как вам ответы?». Соберите реальные запросы заранее и разложите их по группам.

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

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

Минимальный пакет для первого пилота

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

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

Размер пакета зависит от процесса. Важнее покрытие ключевых вопросов, чем число файлов. Один актуальный справочник с владельцем полезнее десятка похожих презентаций.

Зафиксируйте границы пилота прямо в описании задачи. Например: агент отвечает только сотрудникам отдела продаж, использует утверждённые продуктовые материалы, не рассчитывает индивидуальные скидки и не меняет CRM. Тогда ошибки можно разобрать по конкретным причинам, а не по общему впечатлению от «умности» системы.

Критерии готовности базы знаний

Проверьте каждый пункт ответом «да» или «нет».

1. Выбран один процесс и один тип пользователя.
2. Выписаны вопросы и решения внутри процесса.
3. У каждого источника есть владелец.
4. Для изменчивых фактов назначен источник истины.
5. Указаны дата проверки и повод для обновления.
6. Старые версии отделены от действующих.
7. Персональные и закрытые данные размечены.
8. Доступы разделены по ролям.
9. Знания отделены от инструкций и действий.
10. Определены вопросы для передачи человеку.
11. Собран проверочный набор из реальных формулировок.
12. Команда знает, кто разбирает ошибки после запуска.

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

Что не стоит загружать

Четыре папки особенно часто создают ложное ощущение готовности.

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

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

Кто отвечает за базу после запуска

Без владельца база начинает стареть сразу после публикации. Нужен короткий рабочий цикл:

1. пользователь задаёт вопрос;
2. система находит источник или передаёт запрос человеку;
3. команда отмечает ошибку, пропуск или конфликт;
4. владелец правит источник;
5. изменённый раздел проходит повторные тесты;
6. новая версия попадает в рабочую базу;
7. в журнале остаётся дата и причина изменения.

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

Чем эта подготовка отличается от аудита и ТЗ

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

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

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

Кому пока рано собирать большую базу

Не начинайте с масштабной базы, если:

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

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

FAQ

Нужно ли загружать все документы компании

Нет. Собирайте материалы под один процесс и круг вопросов. Остальные источники подключаются только после проверки пользы и прав доступа.

Можно ли использовать переписки сотрудников

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

Что делать, если документы противоречат друг другу

Назначить источник истины и владельца темы. До решения конфликта агент не должен выбирать удобную версию или смешивать цифры.

Нужна ли векторная база

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

Как часто обновлять базу знаний

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

Как понять, что база готова к запуску

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