Обновление эмбеддингов без остановки сервиса: blue-green

Задача: обновить модель и эмбеддинги без простоя

Когда вы меняете модель эмбеддингов или пересчитываете векторные представления, ломается не один компонент, а вся цепочка. Векторный поиск начинает сравнивать новые векторы со старым индексом (или наоборот), и выдача становится непредсказуемой. Даже если сервис формально жив, пользователи быстро замечают: «раньше находило, а теперь нет».

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

Типичные симптомы при неаккуратной замене модели или эмбеддингов:

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

Обновление затрагивает сразу несколько слоев: версию модели, пайплайн подготовки текста, процесс пересчета эмбеддингов, векторный индекс и сервис выдачи (например, с фильтрами по правам доступа и смешанным ранжированием: векторным и ключевым).

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

В организациях с жесткими требованиями к непрерывности (например, госструктуры или банки, где инфраструктура часто развернута на локальном железе) нельзя просто «обновиться ночью и посмотреть». Нужны стратегии, которые позволяют обновлять модель и эмбеддинги параллельно работающей системе и контролировать эффект до того, как изменения увидят все пользователи.

Карта компонентов: что нужно версионировать

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

Типичный путь запроса: исходные данные (документы и запросы) - модель эмбеддингов - векторный индекс - поиск ближайших соседей - (иногда) доп. ранжирование - ответ пользователю. Версию важно держать не только у модели, но у всего, что влияет на совместимость между шагами.

Что стоит версионировать явно:

• Модель эмбеддингов (веса, имя/хэш версии) и режим работы (например, включена нормализация векторов или нет).
• Токенизатор или словарь (даже небольшое изменение может сдвинуть представления).
• Параметры построения эмбеддинга: размерность, тип данных (float32/float16), pooling, постобработка (L2-нормализация).
• Настройки поиска: метрика расстояния (cosine/dot/L2), параметры индекса (например, число кластеров/графовых связей, efSearch), фильтры и правила дедупликации.

На практике удобно иметь одну «карточку версии» рядом с моделью и индексом: например, embedding_model=v3, tokenizer=v3, dim=768, metric=cosine, normalize=true, index_build=v3.1. Тогда любой эмбеддинг и любой индекс однозначно привязываются к набору настроек.

Критичные зависимости, о которые чаще всего ломаются миграции:

• Размерность вектора. Если новая модель дает 1024 вместо 768, старый индекс не сможет принять такие векторы.
• Метрика и нормализация. Cosine обычно предполагает нормированные векторы, а dot product часто ведет себя иначе.
• Формат хранения. Переход на float16 или квантование может ускорить поиск, но меняет качество и распределение расстояний.

Самые рискованные операции - те, которые сложно быстро откатить. Переиндексация занимает время и деньги, а переключение трафика мгновенно затрагивает всех. Поэтому «опасные» шаги лучше строить так, чтобы старая цепочка (модель + эмбеддинги + индекс + параметры поиска) продолжала жить параллельно и в любой момент могла снова принять трафик.

Выкладка без простоя: blue-green, canary, shadow

Главное правило - не заставлять сотрудников первыми «тестировать» новую версию в рабочее время. Для этого используют три подхода. Они отличаются тем, как вы подаете трафик на новую версию и как быстро можете вернуться назад.

Blue-green

Blue-green - это две одинаковые среды: «синяя» (текущая) и «зеленая» (новая). Вы поднимаете новую модель, новые эмбеддинги и все, что вокруг них, в отдельной среде, прогоняете проверки, а затем переключаете трафик одним переключателем (роутер, балансировщик, флаг).

Плюсы: быстрый откат (переключили обратно), понятная ответственность (в каждый момент активна ровно одна версия). Минусы: дороже по ресурсам, потому что нужно держать две полноценные копии.

Canary и shadow

Canary - это постепенное включение новой версии по доле трафика. Сначала 1-5% запросов, затем больше, пока не дойдете до 100%. Ошибки видны рано, а риск распределен.

Shadow - это «теневая» проверка. Новая версия получает копию запросов и считает ответы, но пользователям вы продолжаете отдавать ответы старой версии. Так можно собрать статистику на живых данных без влияния на опыт пользователей.

Обычно выбор выглядит так:

• Blue-green - когда нужен быстрый откат и вы можете позволить себе двойные ресурсы.
• Canary - когда важнее плавное снижение риска и вы готовы следить за метриками на каждом шаге.
• Shadow - когда хотите проверить качество на реальных запросах, не меняя ответы для людей.
• Canary + shadow - когда сначала сравниваете «в тени», а потом осторожно включаете часть трафика.

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

Чтобы любой из подходов был безопасным, заранее продумайте три вещи:

• Четкий переключатель: один параметр, который меняет, куда идет трафик.
• Быстрый откат: заранее проверенная команда или кнопка, без ручных правок.
• Порог остановки: простое правило, когда вы прекращаете раскатку (например, рост ошибок или падение кликов по результатам).

Параллельные индексы: как мигрировать векторный поиск

Самый безопасный способ обновить векторный поиск - держать рядом два индекса. Старый индекс продолжает отвечать пользователям, а новый строится в фоне на новых эмбеддингах. Так вы снижаете риск «уронить» поиск для сотрудников.

Идея простая: пока трафик идет в индекс v1, вы создаете v2 и доводите его до того же покрытия данных. Переключение делается только тогда, когда v2 показывает сопоставимое или лучшее качество.

Dual write: как не потерять новые данные

Пока новый индекс строится, данные продолжают меняться: добавляются документы, обновляются карточки, появляются новые тикеты. Чтобы v2 не отстал, включают dual write: каждый новый или обновленный объект получает эмбеддинг и записывается сразу в оба индекса.

Здесь важен единый «контракт записи»: одинаковые id, одинаковые правила удаления и одинаковая нормализация текста. Это сильно упрощает проверку.

Backfill: догрузка истории и контроль прогресса

После включения dual write вы догружаете историю в v2 (backfill): все старые документы пересчитываются новой моделью и попадают в новый индекс. Следите не только за процентом готовности, но и за пропусками.

Практичный минимум для контроля:

• счетчик обработанных объектов и оставшегося хвоста
• доля ошибок по типам (таймауты, пустой текст, неверная кодировка)
• выборочная сверка: есть ли id в v2 для «топовых» документов
• время индексации и скорость догрузки

Чтобы не запутаться в версиях, задайте правила именования и не нарушайте их: например, search-index-v1, search-index-v2, плюс дата сборки или номер релиза в метаданных. Тогда переключение и откат будут однозначными.

Пошаговый план миграции: от подготовки до переключения

Критично заранее разделить старую и новую версии и договориться, что именно считается успехом. Тогда переключение будет управляемой операцией.

1) Подготовьте новую версию как отдельный контур

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

Заранее зафиксируйте, какие данные вы будете пересчитывать (все документы или только активные) и как будете маркировать объекты: document_id, версия эмбеддинга, время пересчета.

2) Постройте новый индекс параллельно и проверьте консистентность

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

Простой практичный тест: возьмите 50-100 типовых запросов сотрудников (по базе знаний, заявкам, политикам) и убедитесь, что новый индекс находит нужные документы, а не возвращает случайные.

Удобная схема работ в 4 шага:

• Зафиксировать версию пайплайна и подготовить набор тестовых запросов (ручных и из логов).
• Пересчитать эмбеддинги и собрать новый индекс в отдельной среде.
• Подать запросы в старый и новый контур параллельно (shadow) или на малую долю пользователей (canary).
• Переключить основной трафик, но оставить время и механизм для быстрого отката.

3) Запустите shadow/canary и соберите сигналы

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

4) Переключение и окно для отката

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

Контроль качества: что измерять до и после миграции

Миграции чаще ломаются не на переключении, а на тихой деградации качества. Поэтому базовую линию фиксируют до обновления и сравнивают после.

Начните с набора тестовых запросов, которые отражают реальные задачи сотрудников. Не «красивые» примеры, а то, что люди правда вводят: короткие фразы, опечатки, смешение русского и английского, внутренние названия. Практика: собрать 50-200 запросов из логов и добавить вручную 10-20 «больных» кейсов.

Офлайн проверка: качество без пользователей

Офлайн тесты помогают понять, что изменилось именно из-за модели и индекса. Для каждого тестового запроса зафиксируйте ожидаемые документы (или хотя бы «подходящие» варианты) и сравните старую и новую версию.

Обычно измеряют:

• Доля запросов, где нужный документ найден в топ-1 или топ-5 (recall@k).
• Средняя позиция правильного результата.
• Стабильность: насколько часто ответы «прыгают» при одинаковом запросе.
• Доля «пустых» ответов и доля нерелевантных ответов в топе.
• Время поиска и время до первого результата.

Полезно вручную просмотреть 20-30 запросов: люди быстро замечают смысловые подмены, которые метрики иногда пропускают.

Онлайн сигналы: что видят пользователи

После включения новой версии смотрите на поведение, а не только на «точность». Если людям стало сложнее находить нужное, это проявится в кликах и времени.

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

Заранее задайте пороги. Пример: релиз останавливается, если recall@5 падает больше чем на 2-3 п.п., доля запросов без кликов растет больше чем на 5% относительно базы, или время до результата ухудшается больше чем на 10-15%. Такие правила снимают спор «кажется стало хуже».

Наблюдаемость: метрики и алерты, чтобы не пропустить деградацию

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

Что измерять: от железа до поведения пользователей

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

Минимальный набор:

• Технические метрики: p95 задержка по ключевым эндпоинтам, доля 5xx и таймаутов, CPU/GPU загрузка, память, очереди на обработку.
• Метрики векторного поиска: время поиска и подготовки запроса, размер индекса и темп роста, процент пустых результатов, доля запросов с очень низким скором.
• Сигналы качества на потоке: CTR по подсказкам, доля переформулировок, среднее число попыток до клика, доля отказов.
• Бизнес-сигналы: обращения в поддержку, жалобы в чатах, рост ручных операций.

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

Алерты: что должно срабатывать автоматически

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

Примеры правил, которые часто спасают миграции:

• p95 задержка выросла на X% относительно blue за последние 10-15 минут.
• Доля пустых результатов превысила порог и держится Y минут.
• Ошибки 5xx или таймауты превысили порог, плюс выросли ретраи.
• Резкий рост использования памяти или падение свободного места на узлах индекса.
• Сработал «бизнес-стоп»: всплеск обращений или отмен действий в интерфейсе выше нормы.

Чтобы алерты не были слепыми, добавьте контекст в уведомление: версия модели, версия индекса, регион, процент трафика, и последние изменения (переключение, прогрев, ребилд).

Пример: после включения green на 20% трафика p95 задержка не изменилась, но процент пустых результатов вырос с 1% до 6%. Часто это означает проблему в пайплайне эмбеддингов (другая нормализация, неверный язык, не тот энкодер) или в фильтрах поиска. Такой алерт должен вести к действию: остановить рост трафика, вернуть пользователей на blue или временно направить часть запросов на старый индекс.

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

Частые ошибки и ловушки при обновлении эмбеддингов

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

Технические несостыковки, которые ломают поиск

Первая ловушка - несовместимость размерности векторов. Модель могла перейти, например, с 768 на 1024 измерения, а индекс или клиентский код все еще ожидает старый формат. В лучшем случае это упадет с ошибкой, в худшем - тихо начнет отдавать мусор.

Вторая - несоответствие метрики расстояния и настроек нормализации. Если раньше использовали cosine и нормализованные векторы, а в новой версии переключились на dot product или L2 без пересмотра параметров, качество может просесть резко и без очевидной причины. Опасно и то, что разные векторные базы по-разному трактуют «cosine»: иногда это отдельная метрика, иногда это dot product + обязательная нормализация.

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

Ошибки планирования и контроля

Недооценка времени переиндексации почти гарантирует пиковые проблемы. Переиндексация нагружает CPU, диск и сеть, а еще создает очереди в пайплайне. Если параллельно идут рабочие запросы, можно получить и деградацию качества (из-за таймаутов), и деградацию скорости.

План отката часто бывает формальным: «вернемся назад, если что». Нужны конкретные стоп-сигналы и действия. Например:

• качество упало ниже порога (клики, ручная оценка топ-5)
• p95 задержки поиска выросла в 2 раза и держится 15 минут
• доля пустых ответов или ошибок превысила X%
• нагрузка на базу/очередь вышла за безопасный лимит

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

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

Чтобы избегать таких ловушек, заранее фиксируйте совместимость (размерность, метрика, нормализация), не смешивайте версии в одном индексе, планируйте переиндексацию как отдельную нагрузку и держите быстрый откат с понятными порогами остановки.

Короткий чеклист перед переключением

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

Что должно быть готово до переключения

Проверьте, что версии зафиксированы и понятны всем участникам. В карточке релиза (или простом документе) укажите: версию модели, версию токенизатора, схему препроцессинга текста и версию индекса. Если менялись параметры эмбеддингов (размерность, нормализация, язык), это тоже должно быть записано.

Убедитесь, что новый индекс построен полностью и прошел проверку на контрольных данных. Речь не только о «индекс собрался без ошибок», а о том, что результаты поиска на заранее выбранных запросах выглядят ожидаемо. Желательно иметь набор из 50-200 «эталонных» запросов и документов, которые отражают реальную работу сотрудников.

Проверьте режим безопасного запуска: canary или shadow. В canary часть трафика идет в новую связку, а в shadow новая связка получает копию запросов без влияния на ответы. В обоих случаях должен быть дашборд с понятными метриками, чтобы за 5 минут увидеть проблему.

Что обязательно для отката

Откат должен быть таким же простым, как переключение. Если для возврата нужно «вручную пересобрать индекс» или «откатить несколько сервисов в правильном порядке», это уже отдельная операция.

• Готов переключатель трафика (быстро вернуть старую версию без деплоя)
• Старый индекс сохранен и доступен (не удален и не перезаписан)
• Заданы лимиты нагрузки для нового контура (QPS, таймауты, размер очередей)
• Описан критерий отката (рост ошибок, падение качества, рост задержки)

Проверка на сценариях сотрудников

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

Если вы работаете в организации с требованиями к надежности и поддержке 24/7 (как это бывает в госструктурах, медицине или финансах), такой чеклист лучше сделать обязательным.

Пример сценария и следующие шаги

Сценарий: корпоративный поиск по документам и заявкам

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

Задача - провести обновление так, чтобы сервис оставался доступным, а качество не провалилось на типовых запросах.

Как провести обновление без риска

Практичный путь: параллельный индекс + shadow, затем canary. Старый и новый контуры живут рядом и сравниваются на реальных запросах без влияния на пользователей до момента уверенности.

Типовой план:

• Поднимите новый индекс параллельно старому и начните пересчет документов в фоне, с версионированием модели и настроек.
• Включите shadow: пользователей обслуживает старый индекс, а новый получает те же запросы «в тени» и пишет результаты и метрики в логи.
• Выберите 20-50 типовых запросов (по ролям и отделам) и заведите простой «эталон»: что считается хорошим ответом и какие документы должны быть в топе.
• Запустите canary: 1-5% трафика (или одна группа пользователей) получает результаты из нового индекса, остальные остаются на старом.
• После стабильных метрик увеличьте долю и переключите основной трафик, оставив быстрый откат.

Между шагами заложите паузу на проверку. Скорость миграции почти всегда менее важна, чем контроль качества.

Как поймать проблему на ранней стадии

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

Самый заметный сигнал - просадка качества по типовым запросам: больше кликов на нерелевантные результаты, рост переформулировок, падение доли «успешных» сессий (когда сотрудник находит нужное за 1-2 попытки). Поэтому shadow-логи и ручной прогон контрольных запросов перед расширением canary часто спасают релиз.

Следующие шаги

Чтобы такие обновления не превращались в разовый подвиг, закрепите процесс:

• Введите обязательные версии: модель, параметры эмбеддинга, схема индекса и набор контрольных запросов.
• Автоматизируйте переиндексацию и переключение, чтобы откат занимал минуты, а не часы.
• Договоритесь о стоп-условиях для canary (какие метрики и на сколько могут ухудшиться).
• Запланируйте ресурсы под параллельные индексы и нагрузку на пересчет заранее.

Если обновление упирается в инфраструктуру (ресурсы под два контура, надежность хранения, мониторинг, поддержка 24/7), иногда проще привлечь системного интегратора. В Казахстане этим, в том числе, занимается GSE.kz (gse.kz): у них есть опыт поставки локально произведенных серверов S200 и построения инфраструктуры для корпоративных ИТ-систем, где простои недопустимы.