AI
ТЗ на AI-базу знаний: владельцы, версии, обновление и удаление
Как организовать жизненный цикл AI-базы знаний: реестр источников, ответственность, сроки актуализации, права доступа и проверка удаления.
Сформулируйте контракт актуальности
ТЗ на AI-базу знаний должно отвечать на вопрос, когда изменённый документ действительно начинает определять ответы системы. Загрузка файла — только промежуточный шаг. Текст может остаться в старых фрагментах, индекс обновиться частично, а кэш продолжить отдавать прежний ответ. Поэтому результат проекта нужно описывать через проверяемый жизненный цикл знания.
Этот бриф сосредоточен на ответственности, версиях, обновлении и отзыве материалов. Общая подготовка документов и архитектура RAG рассматриваются в связанных статьях. Здесь важнее договориться, кто допускает источник к использованию, какая редакция действует и каким доказательством подтверждается завершённое изменение. Эти решения нужны независимо от выбранной модели и поисковой технологии.
Выберите одну коллекцию для первой очереди, например инструкции поддержки по конкретному продукту. Назовите её владельца, пользователей и допустимые задачи. Не объединяйте сразу все корпоративные папки под обещанием единой истины. Если разные подразделения имеют разные правила, системе нужны границы применимости, а не попытка автоматически усреднить противоречащие документы.
Введите паспорт источника и владельца решения
Для каждой коллекции определите обязательные поля: устойчивый ID документа, версия, статус, дата действия, область применения, владелец и ссылка на оригинал. Отделите дату редактирования файла от даты вступления правила в силу. Документ может быть подготовлен заранее или исправлен технически без изменения смысла. Эти события не должны смешиваться.
Владелец источника отвечает за содержание и решение о публикации. Технический администратор отвечает за доставку и обработку. Один человек может совмещать роли, но обязанности всё равно нужно различать. Если индексатор не смог прочитать таблицу, это техническая ошибка. Если таблица содержит устаревшее правило, решение принимает владелец знания, а не разработчик коннектора.
Укажите порядок работы с бесхозными документами. Материал без подтверждённого владельца можно временно исключить, ограничить или направить на проверку. Автоматически считать его действующим потому, что он лежит в общей папке, нельзя. В реестре должна быть причина допуска и дата следующего пересмотра, чтобы через несколько месяцев команда могла восстановить основание решения.
Опишите переходы между версиями
Составьте модель состояний: черновик, проверка, действующая версия, отозванная версия, архив. Для каждого перехода определите инициатора, необходимое подтверждение и последствия в поиске. Архив может сохраняться для истории, но не должен безусловно участвовать в ответах о текущих правилах. Если исторические вопросы нужны, они получают отдельный сценарий с датой применимости.
Учебный пример: инструкция версии A разрешает один порядок согласования, версия B меняет ответственного со следующего понедельника. До этой даты система отвечает по A, после — по B. Испытание должно проверить вопрос до даты, после даты и вопрос об историческом периоде. Это редакционный пример приёмки, а не утверждение о возможностях конкретного готового сервиса.
Определите поведение при конфликте. Если два действующих документа дают разные указания и приоритет не задан, система должна показать ограничение или направить уточнение. Выбор более нового файла по времени загрузки может быть неверным. Приоритет устанавливают по смыслу и полномочиям источника, а правило сохраняют как часть контракта коллекции.
Задайте сроки обновления и доказательства завершения
Для каждого события определите начало отсчёта и момент завершения. Например, срок обновления начинается после утверждения версии владельцем, а завершается после проверки, что новые ответы используют нужный материал и старая версия исключена из текущего сценария. «Файл принят» и «знание обновлено» должны иметь разные технические состояния.
Разбейте процесс на наблюдаемые этапы: получение, извлечение, проверка структуры, формирование фрагментов, индексация и контрольный запрос. Если этап не выполнен, отчёт должен показывать причину и ответственного. Полезно хранить идентификатор обработки и контрольную сумму исходника, чтобы повторная загрузка не создавала неразличимые копии.
Сроки выбирают по важности изменения и возможностям инфраструктуры. Срочный отзыв ошибочного правила может требовать отдельного пути, отличного от обычного ночного обновления. Конкретное время подтверждают пилотом и эксплуатационными договорённостями. Не обещайте мгновенную актуальность, если коннектор работает по расписанию и не имеет проверенного механизма немедленного исключения.
Сделайте удаление отдельным приёмочным сценарием
Перечислите места, где может храниться управляемая копия содержания: оригинал, извлечённый текст, фрагменты, поисковый индекс, кэш и журналы. Для каждого определите действие при отзыве и доступный способ проверки. Не все исторические записи обязательно удаляются одинаково; требования к хранению и правовые основания утверждает ответственная сторона. Техническая команда реализует согласованный порядок.
Документация Azure AI Search показывает, что обнаружение изменений и удалений источника — разные механизмы, а поведение зависит от настроенной политики и типа индексирования. Этот пример полезен как предупреждение против предположения «удалили файл — исчезло всё». Для выбранного коннектора нужно подтвердить фактическое поведение, включая связи одного документа с несколькими фрагментами.
Учебный тест: отозван документ, из которого ранее создавался ответ. Проверяющий задаёт исходный вопрос, его переформулировку и запрос к старой ссылке. Затем проверяет, не возвращается ли содержание после повторного запуска индексатора. Критерий должен учитывать все перечисленные хранилища в согласованном охвате. Один успешный ответ нового диалога не является полным доказательством удаления.
Свяжите права с документом и производными данными
Право прочитать документ должно учитываться при использовании его фрагментов и цитат. Если ссылка закрыта, но ответ раскрывает содержание, ограничение фактически не соблюдено. В ТЗ задайте, как роль пользователя передаётся в поиск и где проверяется разрешение. Проверка только видимости кнопки в интерфейсе недостаточна.
OWASP рекомендует минимальные полномочия, отказ по умолчанию и проверку авторизации на каждом запросе. В применении к базе знаний это означает проверять доступ при выдаче соответствующего содержания, а не полагаться на однажды выполненный вход. Конкретные роли, атрибуты и исключения определяются моделью вашей организации и требуют собственных тестов.
Проверьте изменение прав после индексации. Сотрудник мог перейти в другое подразделение или потерять доступ к коллекции. В брифе нужен срок применения такого изменения и поведение уже открытой сессии. Отдельно испытайте поиск, цитату и административный просмотр. Журналы диагностики также не должны превращаться в обходной способ прочитать закрытый материал.
Примите систему на журнале событий
Приёмочный пакет должен содержать последовательность событий для одного учебного документа: создание, утверждение, изменение, конфликт, ограничение доступа, отзыв и восстановление. Для каждого события заранее задайте ожидаемые состояния и контрольные вопросы. Так команда проверяет не только стартовую загрузку, но и жизнь базы после запуска.
Для доказательства сохраняйте время события, версию источника, идентификатор обработки и результат контрольного запроса. Добавьте технический сбой между извлечением и индексацией, повтор события и восстановление после недоступности источника. Система должна показывать неполноту, а не скрывать её под общим зелёным статусом. Последнее успешное обновление и текущая ошибка могут существовать одновременно.
Разделите качество извлечения и актуальность. Новый документ может быть доставлен вовремя, но потерять таблицу или важное исключение. Для представительного набора форматов нужны контрольные фрагменты и проверка содержания. Если документ невозможно корректно обработать, он должен попасть к ответственному с понятной причиной, а не молча стать источником неполного ответа.
Передайте регламент эксплуатации вместе с брифом
Скачиваемый шаблон помогает определить владельцев, версии, события, сроки и проверки. Дополните его реестром коллекций и одним полностью заполненным учебным жизненным циклом. Такой пример гораздо полезнее общего требования «поддерживать актуальность»: по нему можно оценить интеграции, наблюдение и трудозатраты на сопровождение.
Назначьте регулярный пересмотр материалов и очередь документов с истёкшей проверкой. Укажите заместителя владельца на время отсутствия и способ срочного отзыва ошибочного правила. Эти организационные детали влияют на качество ответов не меньше, чем параметры поиска. Автоматизация может напомнить о проверке, но не должна сама объявлять спорный документ утверждённым.
После пилота расширяйте коллекции постепенно, сохраняя прежние сценарии проверки. Наличие большого числа документов не доказывает полезность базы. Практический результат — возможность установить источник ответа, действующую версию и путь её изменения. Если команда может доказать обновление и отзыв знания, база становится управляемым продуктом, а не непрозрачной копией общей папки.
Источники
- Change and delete detection using indexers
Microsoft Learn / доступ 2026-10-12
Первичный источник для соответствующей технической темы. Структура брифа и учебные проверки разработаны редакцией; возможности конкретной системы проверяются перед внедрением.
- Authorization Cheat Sheet
OWASP / доступ 2026-10-12
Первичный источник для соответствующей технической темы. Структура брифа и учебные проверки разработаны редакцией; возможности конкретной системы проверяются перед внедрением.
- Скачать заполняемый бриф / ТЗ (.txt)
Малевич — практическое приложение / доступ 2026-10-12
Сохраните файл и заполните исходные данные, решения и критерии приёмки своего проекта.
FAQ
Чем требования к базе знаний отличаются от ТЗ на RAG?
ТЗ на RAG описывает поиск и формирование проверяемого ответа. Требования к базе знаний задают, кто отвечает за документы, какая версия действует, когда обновление считается завершённым и как отзывается доступ. Эти задачи связаны, но хорошее ранжирование не заменяет управление содержанием.
Достаточно ли удалить исходный файл?
Не всегда. Копии текста могут оставаться в поисковом индексе, фрагментах, кэшах и ранее созданных ответах. Требование должно перечислять управляемые хранилища и способ проверки каждого. Поведение конкретного коннектора при удалении необходимо подтвердить отдельным тестом.
Как работать с документом без владельца?
Такой материал нельзя автоматически считать надёжным рабочим правилом. Назначьте временного ответственного, ограничьте область использования либо исключите документ из ответов до проверки. В реестре должно быть видно, почему источник допущен и кто подтвердит его актуальность при следующем пересмотре.
