ИИ-ассистент может ответить уверенно, сослаться на документ и всё равно ошибиться. Не потому, что модель что-то придумала, а потому, что нашла старую инструкцию, отменённый тариф или прежнюю редакцию регламента.
RAG подключает языковую модель к внешней базе знаний. Поэтому при изменении корпоративных данных обычно не требуется переобучать саму модель: обновляются источники и поисковый индекс.[1] Но слово «обновляются» скрывает отдельный бизнес-процесс. Кто сообщает об изменении? Как старая версия исчезает из поиска? Что делать с дополнительным соглашением? Когда новые данные становятся доступны пользователям?
Главный тезис простой: актуальность базы знаний — не свойство RAG, а управляемый контур из документов, правил версий, синхронизации, контроля и тестов.
Если этого контура нет, система со временем превращается в аккуратный интерфейс к архиву.
Где появляется устаревший ответ
Между исходным документом и ответом пользователя находится несколько этапов:
источник → обнаружение изменения → обработка документа → разбиение на фрагменты → индекс → поиск → ответ
Сбой возможен на каждом из них.
Документ могли обновить в общей папке, но не запустить синхронизацию. Новый файл мог загрузиться с ошибкой. Старые фрагменты могли остаться в векторной базе после удаления исходника. Права доступа могли измениться в SharePoint или корпоративном портале, но не попасть в индекс. Наконец, обе версии могли корректно сохраниться, и поиск начал возвращать их одновременно.
Поэтому задача не сводится к команде «переиндексировать папку». Сначала нужно определить, какая информация считается действующей и по каким правилам система отличает её от архива.
Сначала определите источник истины
У базы знаний для ИИ должен быть источник истины — система, где документ создаётся, согласуется и получает статус. Это может быть корпоративный портал, CRM, документооборот, Git-репозиторий, файловое хранилище или специализированная база знаний.
Папка, куда сотрудники копируют «финальные версии», источником истины обычно не является. Через несколько месяцев в ней появляются файлы регламент_финал, регламент_финал2 и регламент_точно_финал. Для человека это неудобно. Для автоматического поиска — опасно.
Минимально полезные метаданные выглядят так:
| Поле | Зачем нужно |
|---|---|
document_id | Стабильный идентификатор документа |
version | Номер или идентификатор редакции |
status | Черновик, согласован, действует, отменён, архив |
effective_from | Дата начала действия |
effective_to | Дата окончания действия |
supersedes | Какую версию или документ заменяет |
scope | Продукт, регион, подразделение, тип клиента |
owner | Кто отвечает за содержание |
updated_at | Когда источник изменился |
access | Каким ролям доступен документ |
Не обязательно хранить эти поля именно в таком виде. Важно, чтобы их смысл существовал в исходной системе и не восстанавливался моделью из названия файла.
Как задать приоритет основной версии и дополнительного соглашения
Поиск по смысловой близости не умеет сам определять юридическую или операционную силу документа. Более свежая дата тоже не всегда означает более высокий приоритет.
Представим условную ситуацию: действует основной регламент продаж, а для одного региона выпущено дополнительное соглашение. В базе находятся оба документа. Если просто передать модели несколько похожих фрагментов, она может объединить правила или выбрать более убедительно написанный текст.
Приоритет нужно формализовать до генерации ответа:
- Сначала отфильтровать документы по статусу и периоду действия.
- Затем применить область: регион, продукт, подразделение, тип договора.
- Проверить явную связь
supersedesилиamends. - Для одного семейства документов выбрать действующую редакцию.
- Если правила пересекаются, но приоритет не задан, не просить модель решать конфликт — передать вопрос ответственному.
Для договоров и нормативных документов конкретное правило приоритета должен утвердить владелец процесса вместе с юристом или предметным специалистом. Архитектура может исполнить это правило, но не должна придумывать его.
Выберите способ обновления под скорость изменений
Microsoft перечисляет несколько стратегий: обновление по расписанию, запуск по событию, выборочную переиндексацию, хранение версий и полное перестроение при значительных изменениях.[2] Выбор зависит не от моды на real time, а от стоимости устаревшего ответа.
| Ситуация | Рациональный подход |
|---|---|
| Инструкции меняются редко, ошибка обратима | Ручное утверждение и обновление по расписанию |
| Документы регулярно меняются в рабочей системе | Инкрементальная синхронизация по расписанию |
| Новый регламент должен действовать сразу | Событие после утверждения и приоритетная обработка |
| Меняется структура, способ разбиения или модель эмбеддингов | Полное перестроение индекса и регрессионный тест |
| Значение меняется постоянно: остаток, цена, статус заказа | Запрос к API или базе данных во время ответа, а не документ в RAG |
Последняя строка особенно важна. Не стоит превращать оперативную базу данных в набор PDF-файлов только ради того, чтобы ассистент мог их искать. Остатки, лимиты, баланс, статус заявки и другие быстро меняющиеся значения надёжнее получать из исходной системы через контролируемый API.
RAG нужен там, где ответ основан на неструктурированном знании: инструкциях, описаниях, регламентах, договорах и документации.
Обрабатывайте четыре типа изменений отдельно
Новый документ
Система должна обнаружить файл, проверить формат и обязательные метаданные, извлечь текст, разбить его на фрагменты, создать эмбеддинги и добавить записи в индекс.
До публикации полезно проверить, что документ действительно доступен поиску по контрольным вопросам. Успешная загрузка файла ещё не доказывает, что нужный фрагмент находится.
Изменённый документ
Нужно определить, что именно изменилось: содержание, метаданные, права доступа или только техническое поле. В управляемых сервисах инкрементальная синхронизация может повторно обработать только изменённые документы. Например, Amazon Bedrock при изменении содержания или метаданных повторно выполняет разбор, разбиение, создание эмбеддингов и индексацию.[3]
Для собственной архитектуры принцип тот же: изменение должно приводить к предсказуемому обновлению связанных фрагментов. Нельзя просто добавить новую копию рядом со старой.
Отменённый или удалённый документ
Удаление — самый недооценённый сценарий. Поведение зависит от платформы и коннектора.
Amazon Bedrock при синхронизации обрабатывает добавленные, изменённые и удалённые документы и удаляет соответствующие записи из векторного хранилища.[3] В Azure AI Search для некоторых источников удаление нужно спроектировать отдельно: документация предупреждает, что индексатор сам по себе не всегда отслеживает физическое удаление объекта, поэтому применяется soft delete или собственная метка удаления.[4]
Практический вывод: не считайте удаление исходного файла доказательством удаления знания из индекса. Это отдельный тест.
Изменение прав доступа
Права — тоже данные, которые устаревают.
Если сотрудника перевели в другое подразделение, а ACL документа обновился только в исходной системе, старая копия разрешений может продолжать влиять на выдачу. В управляемых решениях права могут синхронизироваться вместе с документами, но это не отменяет аутентификацию в приложении. AWS прямо отмечает, что ACL-фильтрация базы знаний не является самостоятельной границей безопасности: приложение должно проверить пользователя и передать подтверждённый контекст его роли.[5]
После изменения прав нужно проверять не только финальный ответ, но и найденные системой документы.
Как должен выглядеть рабочий контур обновления
Для небольшого пилота достаточно понятной последовательности:
утверждение документа → событие или расписание → проверка метаданных → обработка → обновление индекса → контрольные запросы → публикация → журнал
Для критичной базы рациональнее добавить промежуточное состояние. Новые данные сначала попадают в тестовый индекс или непубличную версию базы. Система проверяет количество добавленных, изменённых, удалённых и ошибочных документов, прогоняет обязательные вопросы и только после этого делает обновление доступным пользователям.
Это сложнее, чем немедленно записывать всё в рабочий индекс. Зато неудачная обработка одного PDF не превращается в незаметную производственную ошибку.
Журнал обновления должен сохранять:
- источник и версию документа;
- тип изменения;
- время обнаружения и завершения;
- статус обработки;
- количество созданных и удалённых фрагментов;
- ошибки и предупреждения;
- версию схемы разбиения и эмбеддингов;
- результаты контрольных запросов;
- человека или систему, утвердившую публикацию.
У некоторых платформ успешный статус задачи не означает, что каждый документ обработан без проблем. Например, Azure AI Search допускает успешное завершение индексатора при наличии ошибок отдельных документов в пределах настроенного порога, поэтому нужно смотреть предупреждения и подробные результаты запуска.[6]
Что тестировать после обновления
После значимого изменения базы знаний нужен не общий вопрос «бот отвечает?», а короткий регрессионный набор.
Минимум четыре проверки:
- Новая версия находится. Контрольный запрос возвращает действующий документ.
- Старая версия не находится. Отменённый фрагмент не попадает в верхние результаты и контекст модели.
- Приоритет работает. Для нужного региона, продукта или договора применяется правильное правило.
- Доступ не расширился. Пользователи разных ролей видят только разрешённые источники.
Microsoft рекомендует использовать golden dataset — набор вопросов с утверждёнными ответами, метаданными и ссылками на ожидаемые документы — и повторять тесты после обновлений системы.[2]
Подробный подход к отдельной проверке поиска, ответа, отказа и прав доступа описан в статье «Тестирование чат-ботов с ИИ: как проверить RAG-систему перед запуском».
Метрики, которые показывают реальную актуальность
Количество документов в индексе почти ничего не говорит о качестве обновления. Полезнее следить за такими показателями:
- время до актуальности — сколько проходит от утверждения документа до появления правильного ответа;
- доля успешных изменений — сколько новых и изменённых документов обработано без ошибок;
- доля устаревших находок — как часто тесты или реальные запросы возвращают отменённую версию;
- ошибки удаления — остались ли фрагменты после отзыва документа;
- ошибки доступа — попал ли закрытый источник в поиск для неверной роли;
- конфликты версий — сколько запросов пришлось передать человеку из-за неразрешённого приоритета;
- стоимость обновления — обработка документов, эмбеддинги, хранение и регрессионные прогоны.
Порог зависит от процесса. Для внутренней справки допустима одна задержка, для тарифов, договоров или инструкций по безопасности — другая. Сначала нужно определить стоимость ошибки, а уже затем выбирать частоту синхронизации.
Когда не нужно строить сложный контур
Автоматическое обновление не всегда оправдано.
Если база состоит из нескольких стабильных инструкций, которые меняются раз в год, может быть достаточно ручной публикации и обязательного теста. Если данные меняются каждую минуту, их лучше получать через API. Если в компании никто не отвечает за документы, автоматизация лишь быстрее перенесёт беспорядок в индекс.
И ещё одна граница: не каждая работа с документами требует ИИ. Извлечение номера, проверка обязательного поля, выбор маршрута по статусу и расчёт срока надёжнее выполняются правилами. Как разделить процесс между workflow и моделью, разобрано в статье «Автоматизация с помощью ИИ: какие процессы ему поручать».
С чего начать пилот
Возьмите одно семейство документов, где изменения происходят регулярно и ошибка заметна бизнесу: регламент поддержки, условия поставки, продуктовые инструкции или договорные шаблоны.
Для него нужно зафиксировать:
- источник истины и владельца;
- статусы и правила версий;
- событие, которое запускает обновление;
- обработку добавления, изменения, удаления и прав;
- контрольные вопросы;
- допустимое время до актуальности;
- условие передачи человеку при конфликте.
После этого уже можно выбирать коннектор, векторное хранилище и частоту переиндексации.
Обновление базы знаний начинается не с кнопки Sync. Оно начинается с ответа на вопрос: какой документ система имеет право считать действующим прямо сейчас?
Если этот ответ не формализован, RAG лишь быстрее найдёт противоречие. Если формализован — ИИ-ассистент становится управляемой частью процесса, а не ещё одним местом хранения копий.
Если документы, владельцы, правила обновления и критерии пилота пока не определены, сначала имеет смысл провести аудит бизнес-процесса: выбрать источник истины, стоимость ошибки и минимальный контур, который действительно стоит автоматизировать.
Частые вопросы
Нужно ли переобучать модель после обновления базы знаний?
Обычно нет. В RAG-системе модель получает актуальный контекст из внешнего индекса, поэтому при изменении инструкций обновляют источник, фрагменты и индекс. Переобучение может потребоваться для другой задачи — например, изменения поведения модели, — но не для обычной замены документа.
Как часто обновлять базу знаний для ИИ?
Частота должна соответствовать скорости изменений и стоимости устаревшего ответа. Для стабильных материалов достаточно расписания. Для критичных регламентов лучше запускать обработку по событию утверждения. Данные, которые меняются постоянно, рациональнее получать через API.
Что делать со старыми версиями документов?
Их можно сохранять в архиве, но исключать из обычного поиска по статусу и периоду действия. Для вопросов «что действовало на конкретную дату» нужен отдельный режим поиска с временным фильтром.
Как избежать конфликта двух документов?
Задать метаданные области действия, даты, статуса и связи между версиями. Если бизнес не определил правило приоритета, ассистент должен показать источники и передать вопрос ответственному, а не выбирать документ по сходству текста.
Можно ли автоматически синхронизировать документы из корпоративного портала?
Можно, если у системы есть API, вебхуки или поддерживаемый коннектор. Но отдельно нужно проверить удаление документов, ошибки обработки и обновление прав доступа. Наличие интеграции не гарантирует актуальность без мониторинга и регрессионных тестов.
Источники
- Yandex Cloud. RAG: учим искусственный интеллект работать с новыми данными, 20 мая 2025 года.
- Microsoft Learn. Build advanced retrieval-augmented generation systems, обновлено 30 января 2026 года.
- Amazon Bedrock. Sync your data with your knowledge base, проверено 27 июля 2026 года.
- Microsoft Learn. Changed and deleted blobs in Azure AI Search, обновлено 2 июня 2026 года.
- Amazon Bedrock. Document-level access controls, проверено 27 июля 2026 года.
- Microsoft Learn. Monitor indexer status and results in Azure AI Search, проверено 27 июля 2026 года.