Как подготовить базу знаний для корпоративной ИИ-функции

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

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

Сначала зафиксируйте одну функцию

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

До подбора источников определите:

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

Эти сведения удобно собрать в паспорте ИИ-функции. Без них невозможно решить, нужен ли документ для задачи или он лишь увеличивает объём поиска.

Создайте реестр источников

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

Реестр нужен не ради полноты описания. Он позволяет воспроизвести состав знаний, с которым проходила приёмка, и не подменить его незаметно другой версией документов.

Отберите только необходимые документы

Проверяйте каждый источник четырьмя вопросами.

Он относится к задаче?

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

У него есть владелец?

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

Понятно, какая версия действует?

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

Доступ допустим для всех пользователей функции?

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

Разрешите конфликты до загрузки

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

Для каждого конфликта:

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

Если решение ещё не принято, корректное поведение функции — остановиться или сообщить о разночтении, а не составить усреднённый ответ.

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

После содержательного отбора проверьте техническую пригодность материалов:

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

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

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

До пилота подготовьте вопросы четырёх типов:

1. Типичные — частые рабочие запросы с однозначным ответом.
2. Пограничные — запросы, где применимость правила зависит от условия.
3. Конфликтные — вопросы по сведениям, которые раньше расходились.
4. Недостаточные — запросы, на которые в разрешённых источниках ответа нет.

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

NIST AI Risk Management Framework рассматривает управление рисками ИИ как работу на протяжении жизненного цикла, а не как разовую проверку перед запуском. Для базы знаний это означает повторять тесты после изменения источников, правил доступа или конфигурации функции. Страница NIST проверена 19 сентября 2026 года. Приведённый здесь чек-лист — практическая рекомендация Тау Хаб, а не дословное требование NIST.

Назначьте порядок обновления

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

Рабочий цикл выглядит так:

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

Если обновление нельзя проверить сразу, сохраните прежнюю рабочую версию или временно остановите затронутую функцию. Незаметная замена источника лишает пилот воспроизводимости.

Как это применить в Тау Хаб

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

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

Следующий шаг — выбрать одну функцию, составить реестр из необходимых источников и подготовить 15–20 контрольных вопросов. После технической проверки базы переходите к измеримому пилоту на одинаковых задачах.