Корпоративная база знаний¶

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

Главная ошибка — считать, что для этого достаточно «загрузить все файлы, которые нашлись на общем диске».

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

Что считается хорошей базой знаний¶

Хорошая база:

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

С чего начать¶

Не начинайте со всей компании.

Выберите одну предметную область.

Например:

ИТ-инструкции;
эксплуатация конкретного продукта;
база службы поддержки;
регламенты отдела;
документация проекта.

Соберите 20–50 наиболее важных документов и сначала добейтесь хорошего качества на них.

Шаг 1. Назначьте владельца знаний¶

У каждой коллекции должен быть человек или подразделение, которое отвечает на вопросы:

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

Администратор ИИ Студии не должен автоматически становиться владельцем содержания всех документов компании.

Шаг 2. Определите назначение¶

Плохо:

«База знаний компании».

Слишком широко.

Лучше:

«Эксплуатационная база знаний продукта X для первой и второй линии поддержки».

Так проще определить состав, права и тестовые вопросы.

Шаг 3. Проведите инвентаризацию¶

Для каждого документа зафиксируйте:

Поле	Пример
Название	Регламент управления доступом
Владелец	Отдел ИБ
Версия	3.2
Дата	2026-08-01
Статус	действующий
Заменяет	v3.1
Уровень доступа	ИТ + ИБ
Источник истины	СЭД / Git / портал

Шаг 4. Удалите дубли¶

Особенно опасны файлы:

reglament.docx
reglament_new.docx
reglament_final.docx
reglament_final2.docx
reglament_2025_old.docx

RAG не знает организационный смысл слова final2.

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

Шаг 5. Используйте понятные имена¶

Рекомендуемый шаблон:

<область>_<документ>_v<версия>_<дата>.<ext>

Например:

ИБ_Управление_доступом_v3.2_2026-08-01.pdf
ИТ_Backup_v2.1_2026-07-15.pdf
Support_ProductX_Runbook_v5.0_2026-09-01.md

Шаг 6. Выберите хороший формат¶

Если исходник существует в Markdown, не обязательно превращать его в PDF только ради «официальности» базы.

Для поиска часто удобны:

Markdown;
DOCX;
цифровой PDF;
структурированный TXT.

Сканы сначала распознавайте.

Шаг 7. Разделяйте слишком большие документы логически¶

Один PDF на 4 000 страниц может работать, но сопровождать его сложно.

Иногда лучше разделить:

ProductX_Install.pdf
ProductX_Backup.pdf
ProductX_Security.pdf
ProductX_Troubleshooting.pdf

Преимущества:

понятнее цитаты;
проще обновлять часть базы;
легче ограничивать доступ;
проще тестировать retrieval.

Не дробите документ на сотни файлов по одной странице без причины.

Шаг 8. Загрузите материалы для File Search¶

Корпоративные знания должны использовать режим смыслового поиска, а не постоянное помещение всех текстов в системную инструкцию.

При создании специализированного помощника добавляйте файлы в его базу знаний/File Search.

После загрузки дождитесь готового статуса.

Шаг 9. Настройте инструкцию помощника¶

Пример строгой инструкции:

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

Это важнее, чем фраза «будь умным корпоративным помощником».

Шаг 10. Настройте доступ¶

Не создавайте единую базу, доступную всем, если исходные документы имеют разные уровни доступа.

Лучше создавать отдельные помощники/коллекции:

общие инструкции;
ИТ;
ИБ;
финансы;
HR;
руководство.

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

Шаг 11. Создайте тестовый набор¶

Минимально 20 вопросов.

Лучше 50–100 для критичной базы.

Типы тестов:

Точный факт¶

«Каков срок хранения ежедневного backup?»

Перефразированный вопрос¶

Документ: «привилегированная учётная запись».

Вопрос:

«Как часто администратор должен менять пароль?»

Отрицательный тест¶

«Требует ли документ менять пароль каждые 17 дней?»

Правильный ответ должен сказать, что такого требования нет.

Конфликт версий¶

Намеренно проверить, что старая версия не побеждает новую.

Пограничный вопрос¶

Вопрос, на который база не содержит ответа.

Правильное поведение — признать отсутствие данных.

Шаг 12. Проверяйте retrieval отдельно от модели¶

Если ответ неправильный, сначала выясните:

найден ли правильный документ;
найден ли правильный фрагмент;
только затем — правильно ли модель его поняла.

Это две разные причины ошибки.

Если retrieval не нашёл источник, смена модели может вообще не помочь.

Версионность документов¶

Не храните устаревшую версию без статуса¶

Если старая редакция нужна для истории, не смешивайте её с действующей базой без явного разделения.

Фиксируйте дату вступления в силу¶

Дата файла на диске не всегда равна дате действия документа.

Удаляйте заменённый индекс¶

После обновления проверьте, что старая копия больше не участвует в пользовательском поиске.

Процесс обновления базы¶

Рекомендуемый цикл:

новый документ
  ↓
проверка владельцем
  ↓
определение версии и доступа
  ↓
удаление/архивирование старой редакции
  ↓
индексирование новой
  ↓
контрольные вопросы
  ↓
публикация пользователям

Нельзя использовать RAG как архив документов¶

Векторная база — не замена СЭД, Git или файловому хранилищу.

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

ИИ Студия получает материал для поиска и ответа.

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

Нельзя использовать базу знаний как обучение модели¶

После обновления документа модель не переобучается.

Новый текст индексируется и становится доступен retrieval.

Это преимущество: обновление знаний не требует дорогостоящего fine-tuning.

Права доступа¶

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

Принцип должен быть таким:

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

При проектировании критичных коллекций выполняйте отдельный security-test пользователем с минимальными правами.

Секреты в базе знаний¶

Не индексируйте:

пароли;
приватные ключи;
service-account JSON keys;
recovery codes;
API tokens;
содержимое секретных хранилищ;
дампы баз данных с учётными данными.

RAG создан для знаний, а не для хранения секретов.

Персональные данные¶

До добавления документов с персональными данными определите:

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

Само наличие локальной модели не заменяет организационные меры по 152-ФЗ.

Yandex AI и корпоративная база¶

Если активна облачная модель, релевантные фрагменты внутренней базы, переданные для ответа, отправляются в Yandex AI Studio.

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

Интернет-поиск и база знаний¶

Для внутреннего помощника часто лучше по умолчанию разделять:

корпоративный факт — только внутренние документы;
внешняя справка — интернет.

Иначе модель может смешать внутреннюю процедуру с общепринятой практикой.

Как измерять качество¶

Полезные метрики:

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

Как улучшать базу¶

Если тест провален, не спешите менять модель.

Проверьте:

качество исходного документа;
формат;
наличие скана;
дубли;
названия;
chunking/retrieval;
инструкцию помощника;
только затем модель.

Типовые архитектуры¶

База поддержки¶

Документы:

FAQ;
runbooks;
known issues;
инструкции диагностики.

База ИТ¶

стандарты;
инструкции эксплуатации;
резервное копирование;
сетевые правила;
документация внутренних сервисов.

База продукта¶

руководство пользователя;
release notes;
ограничения;
интеграции;
FAQ.

Нормативная база¶

Требует особенно строгого контроля версии и источников.

Частые ошибки¶

«Загрузили всё — качество стало хуже»¶

Причина: мусор, дубли, конфликты и нерелевантные документы.

«Новая версия есть, но отвечает по старой»¶

Старая редакция осталась в индексе.

«Помощник отвечает общими знаниями»¶

Усилите инструкцию и требование источников.

«Поиск не находит очевидный раздел»¶

Проверьте извлечение текста и контрольный вопрос по уникальной фразе.

«Пользователь увидел не предназначенную ему информацию»¶

Это security incident. Ограничьте доступ, проверьте ACL/группы и аудит до продолжения эксплуатации.

Checklist перед публикацией базы¶