База знаний компании: как собрать контекст, не отдавая системе все данные подряд

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

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

По состоянию на 28 августа 2026 года Narayana AI Academy & Studio ↗ представлена на публичной карте Narayana ↗ как направление «В развитии». Публичная страница описывает будущий маршрут, где упомянуты база знаний, AI-сценарий, human review и возможная работа Studio. Это описание предложения и замысла, а не доказательство проведённого обучения, работающей Studio, внедрённой базы знаний, RAG, CRM, автоматизации, AI-пилота, партнёрства или результата. Из-за registrar hold фактчек страницы и карты выполнен через верифицированный production-origin `201.24.116.180`; canonical сохраняется, а доступность нужно перепроверить перед публикацией.

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

База знаний — не общий склад файлов

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

В исходной работе Lewis и соавторов RAG ↗ сочетал параметрическую модель с извлечением из внешней памяти на knowledge-intensive задачах. Это важная архитектурная идея, но не универсальная гарантия: качество зависит от корпуса, разбиения, индекса, запроса, ранжирования, контекста, модели и проверки результата.

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

Начните с паспорта вопроса

До первой индексации команда описывает один класс вопросов, например: «какие условия действуют для переноса бронирования?» Паспорт содержит девять полей.

1. Пользователь. Кто задаёт вопрос и в какой роли.
2. Рабочее решение. Для чего будет использован ответ: черновик, подсказка, запись или действие.
3. Область. Какой продукт, подразделение, канал, язык и период входят.
4. Исключения. Какие случаи всегда уходят человеку.
5. Допустимые источники. Какие типы документов могут подтверждать ответ.
6. Запрещённые данные. Что нельзя помещать в корпус, запрос, журнал и ответ.
7. Требование к доказательству. Какая ссылка, дата и версия должны сопровождать утверждение.
8. Полномочие. Кто принимает итог и кто меняет правила.
9. Stop-условие. При каком сбое поиск отключают или возвращают ручной маршрут.

NIST AI RMF Core ↗ предлагает в функции `Map` фиксировать контекст, цели, пользователей, требования, риск-толерантность, задачи и границы знания до решения `go/no-go`. Это добровольная международная рамка, не российское право и не подтверждение соответствия Narayana.

Минимизация — это инженерное решение, а не просьба «быть осторожнее»

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

Не брать документ, если достаточно правила

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

Не брать весь документ, если достаточно фрагмента

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

Не открывать всем то, что нужно одной роли

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

Не хранить дольше рабочей цели

Тестовый корпус, журнал запросов, кеш, резервная копия, векторное представление и выгрузка reviewer — разные копии одного жизненного цикла. Поле «удалено из папки» ничего не говорит о них.

По статье 5 закона № 152-ФЗ ↗ содержание и объём обрабатываемых персональных данных должны соответствовать заявленным целям, избыточность не допускается, а хранение ограничивается сроком цели. Здесь и далее ссылки ведут на консолидированный текст в справочной правовой системе «КонсультантПлюс», а не на официальный портал опубликования. Применимость зависит от фактического оператора, данных, целей, оснований, поручений и архитектуры.

Красные зоны: что не должно попадать «по умолчанию»

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

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

Статья 7 закона № 152-ФЗ ↗ устанавливает конфиденциальность персональных данных для получивших к ним доступ лиц. Статья 10 ↗ отдельно регулирует специальные категории, включая сведения о здоровье, религиозных и философских убеждениях. Это особенно важно для hospitality и retreat-контекста: питание, ограничения здоровья, участие в практике или личная переписка не становятся допустимым AI-контекстом только потому, что находятся на корпоративном диске.

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

Паспорт каждого источника

Файл без происхождения — слабое доказательство. Минимальная карточка источника содержит:

W3C PROV-O ↗ моделирует происхождение через сущности, действия и агентов и позволяет описывать, как один объект был сгенерирован или выведен из другого. Это техническая рекомендация для обмена provenance, а не обязательная схема для компании. ISO 15489-1:2016 ↗ связывает records, metadata, обязанности, мониторинг и процессы создания, захвата и управления записями во времени. Стандарт используется здесь как международная рамка, не как заявление о внедрении или сертификации.

Жизненный цикл важнее красивой структуры папок

У знания должны быть состояния и события перехода.

`Черновик` можно редактировать, но нельзя использовать как основание ответа. `На проверке` видит ограниченный круг. `Действует` доступно только в назначенной области и сроке. `Заменено` остаётся в истории, но исключается из активной выдачи. `Приостановлено` временно не подтверждает ответ. `Отозвано` больше не должно появляться как действующее. `К удалению` проходит проверяемое уничтожение по всем копиям.

Изменение цены или правила должно приводить не к загрузке ещё одного PDF, а к транзакции: новая версия утверждена, старая деактивирована, индекс обновлён, кеш инвалидирован, контрольные вопросы прогнаны, дата и ответственный записаны. Если шаг не завершился, система должна уметь отказать, а не угадывать между версиями.

Статья 21 закона № 152-ФЗ ↗ регулирует блокирование, прекращение обработки и уничтожение персональных данных в предусмотренных случаях, включая достижение цели и отзыв согласия при отсутствии иных оснований. Из неё нельзя вывести один универсальный срок для всех корпоративных документов: retention schedule строится по категории, цели, основанию и обязательствам, а не по удобству векторной базы.

Доступ контролируется и при хранении, и при выдаче

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

Практический контур включает отдельные роли, least privilege, аутентификацию, срок доступа, журнал административных изменений и повторную проверку прав перед каждым retrieval. Пользователь должен получать только те chunks, которые он имел бы право открыть в исходной системе. Сервисный аккаунт не получает лишних функций, а модель не хранит секреты в system prompt.

NIST SP 800-53 Rev. 5 ↗ группирует меры по access control, identification and authentication, audit and accountability, incident response, PII processing и другим областям. Это каталог контролей для американского федерального контекста, здесь — источник контрольных вопросов, а не российское требование.

RAG не превращает документы в истину

У RAG есть минимум три независимых испытания.

1. Retrieval: нашёл ли поиск нужный фрагмент и не принёс ли запрещённый.
2. Grounding: опирается ли ответ на найденное, а не на память модели или домысел.
3. Usefulness: отвечает ли текст на рабочий вопрос в допустимой форме.

ARES ↗ оценивает context relevance, answer faithfulness и answer relevance, используя небольшую человеческую выборку для калибровки. RAGAS ↗ также разделяет качество retrieval и генерации. Эти методы полезны как исследовательские инструменты, но автоматический judge сам ошибается; критические тесты требуют заранее размеченных примеров и human review.

Набор должен включать нормальные вопросы, перефразировки, отсутствие ответа, конфликт версий, запрос вне полномочий, устаревший источник, редкую формулировку и попытку получить закрытые данные. Для retrieval измеряют, попал ли правильный источник в top-k и не утёк ли запрещённый. Для ответа — цитируемость, верность, полноту, корректный отказ и эскалацию.

Просто передать модели длинный архив тоже недостаточно. Исследование Lost in the Middle ↗ показало на multi-document QA и key-value retrieval, что качество может заметно зависеть от позиции релевантной информации и падать в середине длинного контекста. Это не оценка конкретной современной модели, но сильная причина тестировать собственный корпус, а не считать большое context window доказательством надёжности.

Документ из базы может атаковать систему

Текст внутри письма, PDF или веб-страницы может содержать инструкцию модели: игнорировать правила, раскрыть контекст, вызвать инструмент или изменить ответ. Для человека это данные; для модели — потенциальная команда. RAG не устраняет эту границу.

OWASP LLM01:2025 ↗ прямо указывает, что RAG и fine-tuning не полностью снимают prompt injection; среди мер — ограничение поведения, фильтрация, least privilege, отделение внешнего контента, human approval и adversarial testing. Британский NCSC ↗ рассматривает cyber security как необходимое условие безопасности, устойчивости и приватности AI-систем и рекомендует secure-by-design подход по жизненному циклу. Это не обещание абсолютной защиты: надёжнее ограничить последствия детерминированными правами, чем надеяться, что модель всегда распознает вредную инструкцию.

Поэтому retrieved content маркируется как недоверенные данные; tool calls проверяются кодом и полномочиями; операции записи, отправки, удаления и изменения доступа требуют отдельного подтверждения. Низкорисковый помощник по поиску не должен автоматически становиться агентом с CRM, почтой и файловыми правами.

Удаление должно доходить до производных копий

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

Удаление из интерфейса не гарантирует мгновенного исчезновения из backup. Это не обязательно нарушение само по себе: важны документированный цикл, техническая возможность восстановления, блокирование использования, договорные обязательства и фактическая применимость права. Но обещание «удалим всё» нельзя давать, пока не проверены API, сроки поставщика, модельное обучение, журналы и резервные контуры.

NIST Privacy Framework ↗ описывает data processing как полный жизненный цикл, включая collection, retention, transformation, use, sharing и disposal, и подчёркивает роли сторон в data processing ecosystem. Это добровольная американская рамка. ISO/IEC 42001:2023 ↗ даёт требования к системе управления AI; ссылка не означает, что Narayana внедрила эту систему или прошла сертификацию.

Human review — это право остановить ответ

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

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

Минимальный пилот без выгрузки компании

Безопасный первый контур можно собрать из одного вопроса и десятка утверждённых источников.

1. Назначить владельца процесса, владельца знания и reviewer.
2. Зафиксировать паспорт вопроса, допустимое решение и stop-условия.
3. Сделать inventory источников без копирования содержимого.
4. Выбрать минимальный corpus и исключить персональные, специальные, секретные и устаревшие данные.
5. Присвоить источникам ID, версию, область, статус, доступ и срок.
6. Настроить retrieval с наследованием исходных прав.
7. Подготовить тесты retrieval, grounding, отказа, утечки и prompt injection.
8. Запустить read-only пилот без отправки сообщений и изменения систем.
9. Сравнить с обычным поиском и ручной работой на одинаковых вопросах.
10. Принять решение `stop`, `rework`, `hold` или ограниченный `scale`.

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

Как это относится к Narayana AI Academy & Studio

Для направления «В развитии» эта модель может быть только принципом будущего дизайна. Публичная страница упоминает «базу знаний компании», Obsidian или другой стек, синхронизацию, backup, AI-сценарий и human review. Она не показывает фактического оператора, утверждённый corpus, RAG-архитектуру, договоры поставщиков, доступы, retention, deletion evidence, тестовые результаты или действующий процесс Studio.

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

База знаний ценна не объёмом. Она ценна способностью ответить: зачем этот источник здесь, кто вправе его видеть, откуда он пришёл, действует ли сейчас, когда будет пересмотрен и как удалить все его производные копии. RAG может ускорить поиск, но не наследует автоматически истину, полномочие или совесть. Финальная ответственность остаётся у человека и организации.