Embedding lifecycle: почему векторную базу нужно переиндексировать после смены модели

Обновление embedding-модели часто выглядит как обычная замена одной строки в конфигурации. Указали новое имя модели, перезапустили сервис — и ждём, что поиск станет точнее. На практике именно в этот момент RAG-система может начать находить странные документы, пропускать очевидные совпадения или уверенно подсовывать языковой модели нерелевантный контекст.

Проблема не обязательно проявится как ошибка. Иногда размерность векторов совпадает, база принимает новые данные, запросы выполняются, метрики инфраструктуры остаются зелёными. Ломается только смысл поиска — самая важная и одновременно самая трудная для наблюдения часть системы.

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

Что именно хранится в векторной базе

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

[0.021, -0.184, 0.067, ..., 0.109]

Отдельные числа почти ничего не говорят человеку. Ценность появляется, когда модель размещает семантически близкие объекты рядом в многомерном пространстве. Благодаря этому запрос «как восстановить базу после сбоя» может оказаться близко к фрагменту документации о резервных копиях, даже если в исходном тексте нет точного совпадения слов.

Векторная база хранит эти представления вместе с идентификаторами и метаданными, а затем ищет ближайшие точки по cosine similarity, dot product, евклидову расстоянию или другой метрике.

Здесь важно разделить два понятия

• embedding — числовое представление конкретного объекта

• векторный индекс — дополнительная структура, ускоряющая поиск по большому набору embeddings.

• HNSW-граф, IVF-кластеры или другой ANN-индекс строятся поверх уже полученных векторов. Поэтому после смены embedding-модели недостаточно удалить и заново построить только HNSW. Если исходные векторы остались прежними, семантическое представление данных не изменилось.

Полная миграция обычно состоит из двух операций

• Повторно пропустить исходные тексты через новую embedding-модель.

• Построить поисковый индекс поверх нового набора векторов.

Именно весь этот процесс обычно называют reindexing, хотя технически re-embedding и перестроение ANN-структуры — разные этапы.

Почему векторы разных моделей несовместимы

У координат embedding-вектора нет универсального значения. Нельзя сказать, что 117-я координата всегда отвечает за тематику текста, а 408-я — за его эмоциональную окраску. Значение каждой оси формируется в процессе обучения конкретной модели.

Представим две карты одного города. На первой координаты отсчитываются от железнодорожного вокзала, на второй — от центра старого города. Точка (2, 5) существует на обеих картах, но обозначает разные места. Сравнивать расстояния между точками с разных карт бессмысленно, пока координаты не приведены к одной системе.

То же происходит с embeddings:

document_vector = model_A(document)
query_vector    = model_B(query)

Даже если оба результата содержат по 768 чисел, они не обязаны находиться в общем семантическом пространстве. Cosine similarity между ними математически посчитать можно, но полученное значение не будет надёжной мерой смысловой близости.

Разная размерность — самый заметный сценарий

Одна модель может выдавать 384 координаты, другая — 768, 1536 или 3072. В таком случае несовместимость обычно обнаруживается быстро: схема коллекции или индекса не принимает вектор неправильной длины.

Например, при создании индекса Pinecone размерность задаётся явно и должна соответствовать размерности embedding-модели. В Milvus размер поля также должен совпадать с фактическим размером результирующего вектора.

У моделей OpenAI третьего поколения максимальная размерность также зависит от выбранной модели: text-embedding-3-large, например, поддерживает векторы длиной до 3072 и позволяет уменьшать их через параметр dimensions.

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

Одинаковая размерность — более опасный сценарий

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

Но координатные пространства всё равно могут быть разными.

Допустим, миллион документов был обработан моделью model_A, а поисковый сервис после релиза начал создавать запросы через model_B. Запрос имеет правильную длину, поэтому поиск выполняется. Только ближайшими оказываются случайные или слабо связанные документы.

Снаружи это выглядит не как падение сервиса, а как постепенная деградация качества

• пользователю приходится переформулировать запрос

• в top-5 появляются документы с совпадающими словами, но неподходящим смыслом

• RAG-модель отвечает уверенно, однако использует неверный контекст

• растёт число ответов «информация не найдена»

• падают recall, MRR, nDCG и продуктовые метрики поиска.

Такая поломка способна неделями жить в production, если команда следит только за latency, CPU и количеством HTTP-ошибок.

Совместимость определяет не одно имя модели

Фраза «мы используем одну и ту же embedding-модель» ещё не гарантирует, что векторы совместимы. Полный embedding-контракт шире.

На результат влияют

• поставщик и точное имя модели

• версия или snapshot модели

• размерность выходного вектора

• тип данных: float32, float16, int8 и другие варианты

• нормализация

• режим обработки query и document

• префиксы и инструкции, добавляемые перед текстом

• токенизация и правила обрезки

• pooling

• язык и формат входных данных

• версия препроцессинга

• правила chunking

• метрика расстояния в базе.

Поменяли модель — контракт изменился очевидно. Но тот же эффект может дать незаметная правка шаблона:

Было:
  "search_document: {text}"

Стало:
  "Represent this document for semantic retrieval: {text}"

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

Ещё один пример — уменьшение размерности. Некоторые модели специально обучены так, чтобы поддерживать сокращённые embeddings. Это полезно для экономии памяти, однако векторы длиной 1024 нельзя поместить в индекс, созданный под 3072 координаты, или сравнивать с ранее сохранёнными полными представлениями как с одной однородной коллекцией.

Поэтому embedding следует версионировать не строкой, а набором параметров.

embedding_contract:
  provider: example-provider
  model: embedding-model
  revision: "2026-07-15"
  dimensions: 1024
  dtype: float32
  normalized: true
  metric: cosine
  query_template_version: 3
  document_template_version: 5
  tokenizer_version: 2
  chunking_version: 4

Такой объект удобно хешировать. Полученный embedding_contract_hash можно хранить в конфигурации приложения, метаданных коллекции и каждой записи. Если хеш запроса не совпадает с хешем активного индекса, поиск лучше остановить, чем вернуть правдоподобный мусор.

Что такое embedding drift

Термин drift часто используют для описания любых изменений в поведении ML-системы. В контексте embeddings полезно разделять несколько видов дрейфа.

Model drift

Один и тот же текст начинает получать другое представление из-за смены модели, её версии, весов или конфигурации inference.

Самый очевидный случай — переход с model_v1 на model_v2. Менее очевидный — использование плавающего алиаса вроде latest, за которым поставщик может переключить конкретную версию модели.

Если система зависит от стабильности результатов, лучше использовать закреплённые версии или snapshots там, где провайдер их предоставляет. В актуальной документации OpenAI, например, snapshots описываются как способ зафиксировать конкретную версию модели и сохранить стабильность её поведения.

Pipeline drift

Модель остаётся той же, но меняется подготовка данных

• HTML очищается другим парсером

• заголовок документа начинают добавлять к каждому фрагменту

• размер chunk меняется с 500 до 900 токенов

• добавляется overlap

• таблицы преобразуются в другой текстовый формат

• меняется Unicode-нормализация

• из документов удаляются или, наоборот, сохраняются служебные поля.

Для embedding-модели это уже другие входные данные. Даже небольшое изменение chunking может заметно изменить состав top-k, потому что поисковыми единицами становятся другие фрагменты.

Data drift

Меняется сам корпус. В базе появляются новые продукты, термины, языки или типы документов, которые не были представлены в исходной оценочной выборке.

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

Index drift

Embeddings остаются прежними, но меняются параметры ANN-поиска

• тип индекса

• quantization

• число кластеров

• HNSW-параметры

• search depth

• metric

• параметры фильтрации.

ANN-индекс намеренно обменивает часть точности на скорость. Поэтому изменение его конфигурации может ухудшить recall даже без смены модели. Milvus прямо отмечает, что индекс ускоряет поиск ценой дополнительной подготовки, памяти и потенциального снижения recall.

Quality drift

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

Quality drift может быть вызван моделью, индексом, данными, chunking или изменением самого поведения пользователей. Поэтому одной метрики cosine similarity недостаточно. Нужна отдельная система оценки retrieval-качества.

Когда переиндексация обязательна

Полный reindex нужен не после каждой правки, но существует несколько явных триггеров.

Смена embedding-модели

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

Правило простое:

Модель запроса должна соответствовать модели документов в выбранном индексе.

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

При самостоятельном pipeline ответственность лежит на приложении.

Смена версии модели

Новая версия может сохранить API, размерность и даже название семейства, но изменить геометрию embedding-пространства.

При закреплённой версии переход следует рассматривать как breaking change, пока обратная совместимость не доказана отдельными тестами.

Изменение размерности

Индекс обычно создаётся под конкретное количество координат. Если размер изменился, понадобится новая схема или новая коллекция.

Даже когда модель позволяет управлять размерностью через параметр, выбранное значение является частью контракта. model_X/1024 и model_X/512 — две разные конфигурации индекса.

Изменение нормализации или метрики

Нормализованные векторы и ненормализованные векторы могут требовать разной интерпретации dot product, cosine similarity и L2.

Например, embeddings OpenAI нормализованы до длины 1; для таких векторов cosine similarity и евклидово расстояние дают одинаковое ранжирование, а cosine можно вычислять через dot product. Это свойство конкретного формата выходных данных, а не универсальное правило для всех моделей.

Если новая модель не нормализует результат или pipeline начинает делать это самостоятельно, конфигурацию индекса и пороги релевантности нужно проверить заново.

Существенное изменение chunking

После изменения границ фрагментов старые embeddings больше не соответствуют поисковым единицам.

Допустим, раньше каждый документ делился на блоки по 300 токенов, а теперь — по смысловым разделам до 1000 токенов. Даже при той же модели это новый корпус:

• изменились тексты фрагментов

• изменилось количество объектов

• поменялись идентификаторы

• изменился баланс между точностью попадания и полнотой контекста.

Значит, требуется повторное создание embeddings и индекса.

Смена типа данных или quantization

Переход с float32 на int8, product quantization или binary representation может существенно сократить потребление памяти. Но это не просто настройка хранения: квантование влияет на расстояния и recall.

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

Когда полного reindex можно избежать

Не всякое обновление данных требует пересчёта миллионов векторов.

Если embedding-контракт не изменился, можно обновлять только записи, у которых изменился исходный текст. Для этого у каждой поисковой единицы полезно хранить:

{
  "document_id": "doc-1842",
  "chunk_id": "doc-1842:07",
  "source_hash": "sha256:...",
  "source_updated_at": "2026-07-29T14:31:00Z",
  "embedded_at": "2026-07-29T14:32:12Z",
  "embedding_contract_hash": "sha256:..."
}

Если source_hash остался тем же и embedding_contract_hash совпадает с активным контрактом, повторно обращаться к модели не нужно.

Это особенно важно для больших баз. Пересчёт embeddings может упираться в:

• стоимость API

• rate limits

• сетевую пропускную способность

• CPU или GPU при локальном inference

• скорость записи в базу

• время перестроения индекса

• дополнительный объём диска

• нагрузку на production-источники.

Инкрементальная обработка экономит ресурсы, но она безопасна только внутри одной версии embedding-пространства. Нельзя пересчитать новой моделью 20% коллекции и оставить остальные 80% старыми, если затем поиск выполняется по всей коллекции как по однородному набору.

Почему нельзя обновлять векторы прямо в production-коллекции

На первый взгляд схема кажется удобной

• Берём документ.

• Получаем новый embedding.

• Перезаписываем старый вектор.

• Повторяем для следующего документа.

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

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

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

In-place-обновление допустимо только в специальных архитектурах, где разные версии хранятся в отдельных именованных vector fields и запрос явно выбирает нужное поле. Например:

embedding_v1
embedding_v2

Но даже в этом случае необходимо отдельно построить индекс для нового поля, контролировать его готовность и не удалять старое поле до завершения миграции.

Для большинства production-систем проще и безопаснее использовать отдельные коллекции.

Безостановочная миграция: blue-green для векторного индекса

Надёжная схема выглядит так

index_v1  — текущий production
index_v2  — новый индекс, строящийся в фоне

Приложение обращается не к физическому имени, а к логическому алиасу:

knowledge_search -> index_v1

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

knowledge_search -> index_v2

Qdrant прямо рекомендует такой подход для обновления версии нейросети: вторую коллекцию можно построить в фоне, а затем атомарно переключить alias, не затрагивая конкурентные запросы. Elasticsearch также использует aliases как механизм reindex без простоя.

Рассмотрим процесс подробнее.

Шаг 1. Зафиксировать исходное состояние

До начала миграции нужно записать

• физическое имя активной коллекции

• embedding-контракт

• количество объектов

• схему metadata

• параметры векторного индекса

• актуальную версию приложения

• контрольную выборку поисковых результатов

• p50, p95 и p99 latency

• продуктовые метрики retrieval

• время последней синхронизации с источником.

Без baseline невозможно объективно определить, стала ли новая система лучше. В рекомендациях Qdrant по проверке миграции первым этапом также указано сохранение исходных счётчиков, конфигурации, примеров metadata и результатов поиска.

Шаг 2. Создать новую коллекцию

Имя должно отражать версию, а не назначение:

knowledge_chunks__emb_v3__chunk_v5__20260731

Логический alias при этом остаётся стабильным:

knowledge_chunks_current

Новая коллекция создаётся с параметрами новой модели

• нужной размерностью

• правильной метрикой

• новым типом данных

• выбранным ANN-индексом

• идентичной или осознанно изменённой схемой metadata.

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

Шаг 3. Запустить backfill из первичного источника

Векторная база не должна быть единственным хранилищем исходного текста. Для повторного создания embeddings нужен source of truth:

• объектное хранилище

• PostgreSQL

• CMS

• Git-репозиторий

• data lake

• поисковый каталог с исходным контентом.

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

source
  -> parsing
  -> normalization
  -> chunking
  -> embedding
  -> metadata enrichment
  -> upsert into index_v2

Backfill должен быть идемпотентным. Повторный запуск одного batch не должен создавать дубли или повреждать коллекцию.

Практичный идентификатор можно собрать из стабильных компонентов:

chunk_id = hash(document_id + chunking_version + chunk_sequence)

Шаг 4. Организовать dual write

Пока идёт backfill, production-данные продолжают меняться. Появляются новые документы, старые редактируются и удаляются.

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

Поэтому изменения нужно направлять одновременно в две версии

write event
  -> pipeline_v1 -> index_v1
  -> pipeline_v2 -> index_v2

У каждой ветки своя embedding-модель и, при необходимости, своя версия chunking.

Если синхронный dual write слишком сильно увеличивает latency, события можно отправлять в очередь:

source update
  -> event log
     -> consumer_v1
     -> consumer_v2

Kafka, RabbitMQ, NATS JetStream или даже надёжная outbox-таблица здесь важны не сами по себе. Главное — иметь повторяемый журнал изменений и возможность догнать отставание.

Шаг 5. Выполнить catch-up

После основного backfill необходимо дождаться, пока новый consumer обработает все события, накопившиеся во время миграции.

Полезная метрика:

migration_lag = latest_source_event - latest_v2_applied_event

Переключение нельзя выполнять, пока lag не приблизился к нулю и не остаётся стабильным.

Также нужно сравнить

• количество активных документов

• количество chunks

• число удалённых записей

• распределение по типам и tenant

• долю записей с ошибками

• долю записей с правильным contract hash.

Равенство общего количества объектов само по себе ничего не гарантирует. Один пропущенный tenant может потеряться внутри миллионов корректных записей.

Шаг 6. Провести shadow testing

На этом этапе пользователь всё ещё получает результаты из index_v1, но каждый запрос параллельно отправляется в index_v2.

Ответ новой системы не влияет на production, а записывается для сравнения

query
  -> index_v1 -> response to user
  -> index_v2 -> evaluation log

Так можно измерить

• overlap между top-k

• появление заранее размеченных релевантных документов

• изменение MRR и nDCG

• долю пустых выдач

• различие score distribution

• latency

• частоту ошибок

• стоимость генерации query embeddings.

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

Пример: старая выдача возвращала три документа с точным совпадением терминов, но без ответа на вопрос. Новая — два действительно полезных документа и один формально менее похожий. Overlap низкий, однако качество выросло.

Шаг 7. Запустить canary

После offline-оценки небольшой процент реального трафика можно направить на новый индекс

95% -> index_v1
 5% -> index_v2

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

На canary сравнивают уже продуктовые показатели

• click-through rate

• успешность ответа RAG

• число переформулировок

• долю эскалаций оператору

• feedback пользователей

• конверсию после поиска

• количество ответов без подтверждающих источников.

Если система генерирует ответы через LLM, retrieval и generation лучше оценивать раздельно. Плохой ответ может быть вызван не индексом, а изменением prompt, reranker или генеративной модели.

Шаг 8. Атомарно переключить alias

После прохождения проверок логический alias переводится на новый индекс.

Важно переключить согласованно две вещи

• Коллекцию, в которой лежат новые document embeddings.

• Модель или pipeline, создающий query embeddings.

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

Лучше хранить эти параметры в одной конфигурационной сущности

retrieval_release:
  id: retrieval-2026-07-31
  collection_alias: knowledge_chunks_current
  collection_target: knowledge_chunks__emb_v3
  query_embedding_contract: emb_contract_v3
  reranker_version: reranker_v2

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

Как организовать rollback

Хорошая миграция определяется не только тем, как команда двигается вперёд, но и тем, насколько быстро она может вернуться назад.

Rollback должен занимать минуты, а не требовать повторной загрузки терабайтов данных.

Не удалять старый индекс сразу

После переключения index_v1 нужно оставить доступным на согласованный период

• несколько часов для некритичного внутреннего поиска

• несколько дней для публичного RAG

• дольше для систем с сезонным трафиком или редкими типами запросов.

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

Проблемы могут проявляться только

• на конкретном языке

• у одного tenant

• в редкой категории документов

• на длинных запросах

• при сочетании metadata-фильтров

• после обновления ночного набора данных.

Сохранять старый query pipeline

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

Поэтому нужно сохранять

• старую версию модели или endpoint

• старые prompt-префиксы

• параметры нормализации

• tokenizer

• конфигурацию размерности

• старую версию query preprocessing.

Rollback — это переключение всей retrieval-версии, а не только имени коллекции.

Продолжать синхронизировать обе версии

Если после cutover запись идёт только в index_v2, старый индекс начинает отставать. Через два дня alias можно вернуть, но пользователь потеряет документы, появившиеся после миграции.

В течение rollback window разумно продолжать dual write. Альтернатива — сохранять журнал событий и гарантировать, что перед откатом index_v1 будет быстро догнан.

Заранее определить критерии отката

Решение не должно приниматься в разгар инцидента на основе ощущений.

Примеры критериев

• p95 retrieval latency вырос более чем на 25%

• доля пустых результатов выросла более чем на 10%

• Recall@10 упал более чем на 3 процентных пункта

• доля отрицательного feedback превысила контроль на 15%

• ошибка embedding API держится выше 2% в течение 10 минут

• обнаружено смешивание embedding_contract_hash.

После срабатывания критерия

• Останавливается расширение canary или выполняется обратное переключение alias.

• Query pipeline возвращается на предыдущий контракт.

• Dual write и журналы событий сохраняются.

• Ошибочная коллекция изолируется, но не удаляется до анализа.

Snapshot не заменяет старую коллекцию

Резервный снимок полезен для аварийного восстановления, но обычно медленнее атомарного переключения alias.

В Qdrant snapshot коллекции включает данные, конфигурацию и индекс, однако collection aliases в такой snapshot не входят. В распределённой установке снимки также требуют отдельной работы с узлами или shard.

Поэтому оптимальная схема выглядит так

• старая online-коллекция — для немедленного rollback

• snapshot или backup — для disaster recovery

• source of truth и журнал изменений — для полного восстановления pipeline.

Это три разных уровня защиты.

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

Сравнение средней cosine similarity почти ничего не говорит о качестве миграции. У разных моделей score может иметь разное распределение. Порог 0.78, работавший в старом пространстве, необязательно имеет тот же смысл в новом.

Нужен набор реальных запросов с ожидаемыми результатами.

Минимальный evaluation dataset

Для небольшого проекта достаточно начать с нескольких сотен запросов

{
  "query": "как сменить SSH-порт на сервере",
  "relevant_document_ids": [
    "security-guide-ssh",
    "server-hardening-checklist"
  ],
  "language": "ru",
  "category": "security",
  "tenant": "public-docs"
}

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

• опечатки

• смешение языков

• профессиональный жаргон

• короткие запросы

• длинные вопросы

• запросы с отрицанием

• редкие названия

• похожие, но разные продукты

• вопросы без ответа в базе.

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

Основные offline-метрики

Recall@k показывает, попал ли хотя бы один релевантный документ в первые k результатов.

Precision@k отражает долю релевантных результатов среди первых k.

MRR учитывает позицию первого релевантного результата.

nDCG полезна, когда существует несколько документов разной степени релевантности.

Top-k overlap показывает, насколько сильно новая выдача отличается от старой, но не оценивает её полезность напрямую.

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

Для RAG дополнительно важны

• наличие ответа в извлечённом контексте

• faithfulness сгенерированного ответа

• корректность ссылок на источник

• объём нерелевантного контекста

• число токенов, отправленных в LLM.

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

Наблюдаемость embedding lifecycle

Обычный infrastructure monitoring отвечает на вопрос «работает ли сервис». Для embedding pipeline нужен второй слой: «работает ли он в правильной версии и сохраняет ли качество».

Метрики ingestion

Стоит собирать

• документов и chunks в минуту

• токенов в минуту

• latency embedding API

• количество retries

• rate-limit errors

• долю неуспешных записей

• размер очереди

• возраст самого старого события

• стоимость обработки

• процент объектов каждого contract hash.

Особенно полезна метрика:

wrong_contract_vectors_total

В корректной коллекции её значение всегда должно быть равно нулю.

Метрики retrieval

В production пригодятся

• query latency

• embedding latency

• vector search latency

• filter latency

• reranking latency

• количество результатов

• распределение similarity score

• доля запросов ниже минимального порога

• доля пустой выдачи

• распределение по языкам и tenant.

Агрегированная метрика может скрыть локальную проблему. Например, русский поиск ухудшился на 20%, но английский трафик настолько велик, что общий Recall@10 изменился всего на 1%.

Трассировка версии

Каждый запрос должен оставлять в trace

{
  "retrieval_release": "retrieval-2026-07-31",
  "query_embedding_contract": "emb-v3-d1024-q2",
  "collection": "knowledge_chunks__emb_v3",
  "index_type": "hnsw",
  "metric": "cosine",
  "top_k": 20,
  "reranker": "reranker-v2"
}

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

Планирование ресурсов для reindexing

На больших объёмах миграция становится инфраструктурной задачей.

Нужно заранее оценить четыре категории ресурсов.

Вычисления для embeddings

Примерная длительность

migration_time =
  total_input_tokens
  / effective_embedding_throughput

Но реальная скорость зависит от rate limits, размера batch, сетевой задержки, повторных запросов и распределения длины документов.

При локальном inference ограничением могут стать GPU memory, длина последовательности и эффективность batching.

Память и диск

Во время blue-green-миграции одновременно существуют

• старые embeddings

• новый набор embeddings

• два ANN-индекса

• временные сегменты

• очереди и журналы

• snapshots.

Если новая модель увеличивает размерность с 768 до 1536, объём сырых float32-векторов примерно удваивается:

vector_bytes = object_count × dimensions × 4

Для 100 миллионов объектов:

100 000 000 × 1536 × 4 ≈ 614 ГБ

Это только массивы чисел — без metadata, служебных структур, реплик и ANN-графа.

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

Пропускная способность записи

Векторная база должна одновременно

• принимать backfill

• обрабатывать dual write

• строить индекс

• обслуживать shadow-запросы

• не мешать production-трафику.

Иногда выгоднее временно отключить или отложить тяжёлое построение ANN до загрузки основного массива, а затем создать индекс. В других системах индекс обновляется постепенно. Правильная стратегия зависит от движка и SLA.

Стоимость

В расчёт входят не только вызовы embedding API

• временный кластер

• дополнительные реплики

• исходящий трафик

• хранение двух коллекций

• очередь сообщений

• snapshot

• инженерное время

• повторные запуски после ошибок.

Полезно провести пробную миграцию на 1% корпуса и измерить фактическую стоимость, а не строить оценку только по прайс-листу модели.

Типичные ошибки при смене embedding-модели

«Размерность совпадает, значит всё совместимо»

Нет. Совпадение размерности означает только то, что база способна принять массив. Оно ничего не говорит о геометрии пространства.

«Достаточно обновить модель запросов»

Если документы остаются в старом пространстве, новый query embedding сравнивается с несовместимыми векторами.

«Можно постепенно заменять записи в одной коллекции»

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

«Новый benchmark выше — можно сразу переключаться»

Публичный benchmark измеряет усреднённую способность модели на определённых наборах данных. Ваши документы, языки, фильтры и пользовательские запросы могут вести себя иначе.

«Если индекс построился, миграция успешна»

Техническая целостность ещё не означает релевантность. Нужно отдельно проверить данные, metadata, конфигурацию и качество поиска. Именно такое разделение используется и в рекомендациях по проверке векторных миграций: сначала integrity, затем search quality.

«Старую коллекцию можно удалить сразу после cutover»

Редкие регрессии могут проявиться позже. Без старого индекса и старой модели быстрый rollback невозможен.

«Snapshot решит любую проблему»

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

«Порог similarity останется прежним»

Распределение score меняется от модели к модели. Порог нужно калибровать заново на размеченных positive и negative examples.

Практический чек-лист миграции

До начала

Зафиксировать embedding-контракт старой системы.

Закрепить точную версию новой модели.

Подготовить evaluation dataset.

Снять baseline качества, latency и стоимости.

Оценить объём токенов, диска и временных ресурсов.

Убедиться, что исходные тексты доступны вне векторной базы.

Подготовить журнал изменений или dual write.

Определить rollback criteria.

Во время backfill

Писать данные в отдельную коллекцию.

Использовать стабильные идентификаторы.

Хранить source_hash и embedding_contract_hash.

Делать pipeline идемпотентным.

Контролировать rate limits и retries.

Проверять данные по tenant, языку и типу документа.

Измерять migration lag.

Не смешивать версии в одном vector field.

Перед переключением

Сравнить количество документов и chunks.

Проверить удаления и metadata.

Дождаться нулевого lag.

Выполнить shadow testing.

Провести offline-оценку.

Запустить canary.

Проверить latency и стоимость.

Убедиться, что новая query-модель развёрнута вместе с индексом.

Подготовить одну операцию переключения retrieval release.

После переключения

Продолжать dual write в течение rollback window.

Не удалять старую коллекцию.

Следить за качеством по сегментам.

Сохранять traces с версиями.

Проверить ночные и пакетные обновления.

Сделать snapshot новой стабильной версии.

Зафиксировать результаты и решение о завершении миграции.

Embedding lifecycle как часть архитектуры

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

исходный документ
  + парсер
  + нормализация
  + chunking
  + embedding-модель
  + параметры inference
  + метрика
  + настройки ANN
  = версия retrieval-системы

Изменился любой существенный компонент — появилась новая версия retrieval.

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

Нужны всего несколько архитектурных принципов

• неизменяемый source of truth

• версионированный embedding-контракт

• отдельная коллекция для каждой несовместимой версии

• стабильный alias для production

• dual write или журнал изменений

• автоматическая проверка данных и качества

• сохранённая предыдущая версия для rollback.

Тогда новая модель не заменяет старую «на живую». Она проходит путь от кандидата до полноценного production-релиза: backfill, проверку, shadow traffic, canary и только затем атомарное переключение.

Вывод

Смена embedding-модели — это миграция данных, а не косметическое обновление зависимости. Новая модель создаёт новое координатное пространство, поэтому старые document vectors в большинстве случаев нельзя корректно сравнивать с новыми query vectors. Совпадающая размерность этого не исправляет — она лишь позволяет ошибке остаться незаметной.

Безопасная стратегия строится вокруг versioned collections и blue-green-подхода: новая коллекция создаётся параллельно, заполняется из первичного источника, догоняет поток изменений, проверяется на реальных запросах и подключается через атомарное переключение alias. Старая версия остаётся доступной до окончания rollback window.

Чем раньше embedding lifecycle становится частью архитектуры, тем проще обновлять модели, экспериментировать с chunking и улучшать поиск без ночных остановок и рискованных миграций. Векторный индекс в этом случае перестаёт быть «чёрным ящиком» и превращается в управляемый, версионированный компонент production-системы.