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

Корпоративный RAG-индекс приходится обновлять не только при смене модели эмбеддингов. Меняются инструкции, цены, регламенты, карточки товаров, права доступа и сами источники. Если очистить рабочую коллекцию и строить её заново на месте, запросы во время перестройки могут получать неполные результаты, а ошибка загрузки превращается в инцидент.

Практичнее оставить текущую версию доступной, пока новая собирается отдельно. В Qdrant для этого есть алиасы коллекций: приложение обращается к постоянному имени, а алиас можно атомарно переключить со старой коллекции на новую. Документация Qdrant прямо описывает фоновое построение второй коллекции и атомарное изменение алиаса. У OpenSearch есть аналогичный паттерн для индексов. Это не магическая кнопка «обновить RAG», а способ отделить подготовку новой версии от переключения трафика.

Схема: версия индекса и стабильное имя

Условно назовём коллекции `manuals_v17` и `manuals_v18`, а алиас приложения — `manuals_current`. Сервис поиска всегда запрашивает `manuals_current`; ему не нужно знать, какая физическая коллекция сейчас за этим именем стоит.

Новую версию строят параллельно:

1. Создают целевую коллекцию с нужной схемой, векторными полями, фильтрами и настройками.
2. Нормализуют и разбивают документы на фрагменты, затем загружают их с устойчивыми идентификаторами.
3. Проверяют полноту обработки и запускают тестовый поиск по контрольным вопросам.
4. После допуска переключают алиас одним запросом: снимают привязку со старой коллекции и добавляют привязку к новой.
5. Оставляют предыдущую версию на короткий срок для быстрого отката, затем удаляют по регламенту.

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

Самое важное — поймать изменения во время сборки

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

Для малого контура можно выбрать один из трёх способов:

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

Выбор зависит от источника. Для файловой папки журналом может служить очередь событий с контрольной суммой и временем изменения; у CRM — аудит изменений или CDC; у самописной базы — таблица outbox. Не стоит обещать точную синхронизацию, если источник не сообщает об удалениях: иначе в новой версии останутся «призраки» старых документов.

Как не переключить качественно плохую версию

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

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

До переключения проверьте:

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

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

Переключение и откат — отдельные операции

Во время переключения приложение должно использовать стабильный алиас, а не имя версии в конфигурации. В Qdrant удаление старой привязки и создание новой можно передать одним списком alias-actions; документация указывает, что изменения алиасов атомарны. У OpenSearch смена index alias также описана как атомарная операция. Это значит, что маршрут не должен на миг указывать «ни на что» в момент такого обновления.

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

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

Что понадобится и сколько это стоит

Параллельное построение требует временного запаса ресурсов. Пока существуют старая и новая версии, нужны место для двух коллекций, вычисления эмбеддингов новой версии, пропускная способность загрузчика и время на контрольный набор. При локальном развёртывании диск, RAM, GPU/CPU и фоновая нагрузка могут оказаться важнее цены самой модели — они тоже входят в стоимость владения.

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

Практическая оценка пилота:

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

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

Минимальный план внедрения

1. Выберите один корпус с понятным владельцем и невысоким риском — например, внутренние инструкции без персональных данных.
2. Введите стабильный алиас в приложении и зафиксируйте версию исходных документов.
3. Постройте новую коллекцию рядом с текущей; сохраняйте ID документа, версию, дату и метаданные доступа.
4. Настройте журнал или другой способ применить изменения, появившиеся во время полной загрузки.
5. Подготовьте 20–50 типовых вопросов и критерии допуска: правильный источник, актуальная версия, корректный фильтр прав и приемлемая задержка.
6. Переключите алиас, наблюдайте метрики и оставьте предыдущую коллекцию доступной для отката.
7. После периода наблюдения удаляйте старую версию только контролируемо — с резервной копией или доказуемым способом повторной сборки.

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

Вывод

Атомарный алиас полезен, если бизнесу нужно собирать новую версию RAG параллельно с действующей и переключаться только после проверки. Он снижает риск простоя на этапе cutover, но не отменяет синхронизацию изменений, проверку прав, оценку качества и план отката. Начните с одного корпуса и измеримого набора запросов. Если время сборки, временный объём хранения и риск устаревших данных приемлемы, расширяйте схему на остальные источники.