Почему нельзя просто заменить файл модели

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

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

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

Что подготовить до миграции

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

Перед стартом зафиксируйте:

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

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

Надёжный путь: две коллекции и один адрес поиска

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

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

После заполнения сравните контрольные суммы и количество ожидаемых объектов, выборочно сверьте версии и права, прогоните тестовые вопросы на обоих индексах. Затем переключите рабочий алиас или конфигурацию поиска на новую коллекцию вместе с моделью, которая кодирует запросы. У Qdrant действия с алиасами атомарны: запрос не должен попасть в полупереключённый адрес коллекции. Но алиас не переключает саму модель запросов — пару «кодировщик вопроса + индекс» нужно менять согласованно на уровне приложения. Для этого держите версионированную конфигурацию или маршрут, который выбирает обе части как один релиз.

Старую коллекцию сразу не удаляйте. Она нужна для отката, пока новый поиск не прошёл наблюдение на реальных, но безопасных запросах. Откат — это возврат старой пары «модель запросов + коллекция», а не только смена алиаса. Дальше отключите двойную запись и удаляйте старые данные лишь по утверждённому сроку хранения и после проверки резервной копии.

Когда подойдут именованные векторы

В документации Qdrant есть другой путь для коллекций с именованными векторами на версии 1.18 и новее. Добавляется новое векторное поле, новые записи получают оба представления, существующие точки пересчитываются в фоне, а запросы затем переключаются параметром `using` вместе с моделью вопросов. Старые идентификаторы и метаданные остаются на месте; прежний вектор можно временно сохранить для отката. У этого подхода меньше дублирования текстовых метаданных, но на время перехода всё равно нужны вычисления и место под два набора векторов.

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

Проверки качества важнее красивого переключения

Тест «API вернул 200» не говорит, стало ли знание доступнее. На одной и той же выборке сравнивайте старую и новую пары: правильный документ в топе поиска, полноту цитат, долю верных и принятых человеком ответов, ошибки на артикуле или имени клиента, задержку на 95-м процентиле. Не смешивайте в одном эксперименте новую модель эмбеддингов, новый reranker и новый шаблон ответа: иначе причина улучшения или регресса потеряется.

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

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

Сколько это стоит и с чего начать

Бюджет миграции состоит из пересчёта всего корпуса, временного хранения второй коллекции или второго вектора, двойной обработки новых документов, тестирования и резерва на откат. Оценку удобно строить как модельный расчёт: число фрагментов × измеренное время кодирования одного фрагмента на вашем оборудовании, плюс пиковое место под оба индекса и труд проверки. Не подставляйте чужую скорость GPU в смету: длинные документы, размер пакета, CPU/GPU и конкурирующая нагрузка сильно меняют результат.

Первый шаг — не перестраивать всю базу. Возьмите один отдел, неизменный набор документов и 50–100 вопросов. Постройте вторую маленькую коллекцию, измерьте поиск и стоимость, затем отрепетируйте переключение и откат на тестовом адресе. Если качество не лучше или цена перехода не окупается, оставьте прежнюю модель. Если лучше — у вас уже есть проверенный план миграции без выключения помощника и без молчаливой потери документов.