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

Не перезаписывайте действующий индекс на месте. Зафиксируйте model ID, revision, размерность, preprocessing и distance metric для документов и запросов. Создайте новый namespace и сравните качество на эталонном наборе вопросов до переключения трафика.

Что проверить в первую очередь

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

  • Проверьте точное имя и revision embedding-модели по обе стороны поиска.
  • Сверьте размерность, нормализацию и метрику cosine, dot product или L2.
  • Сравните подготовку текста: префиксы query и document, очистку и разбиение.
  • Уточните, не смешаны ли в одном индексе старые и новые записи.
  • Проверьте metadata каждого вектора и дату последней индексации.

Почему возникает проблема

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

  • Документы переиндексированы новой моделью частично, а запросы переключены полностью.
  • API использует плавающий alias модели, который изменился без версии индекса.
  • Для запросов пропущен обязательный instruction prefix.
  • Векторы нормализуются дважды или только на одной стороне.
  • Кеш запроса хранит embedding старой модели без model version в ключе.

Пошаговая диагностика

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

  • Возьмите 30-100 реальных вопросов с заранее ожидаемыми релевантными фрагментами.
  • Для каждого результата сохраните model version, chunk ID, score и rank.
  • Сравните старый и новый pipeline offline по recall at k, MRR и ручной оценке.
  • Проверьте распределение норм и similarity, чтобы увидеть аномальное смешение.
  • Найдите записи без embedding_version или с неверной размерностью.

Версионирование векторного индекса

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

  • Embedding version включает provider, model, revision, preprocessing и chunking version.
  • Каждый индекс или namespace содержит только совместимые векторы.
  • Кеш ключуется хешем текста и полной версией pipeline.
  • Поисковый сервис не принимает запрос, если его версия несовместима с индексом.
  • Исходный текст и metadata позволяют повторную индексацию без потери данных.

Как исправить проблему

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

  • Создайте отдельный индекс для новой модели и не меняйте старый во время миграции.
  • Запустите повторное кодирование из канонического источника с контрольными точками и повторами.
  • Временно используйте dual write для новых или обновленных документов.
  • Проведите shadow query либо A/B сравнение на безопасной доле трафика.
  • Переключите alias атомарно после приемки и оставьте возможность быстрого отката.

Безопасный порядок внедрения

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

Как проверить результат

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

  • Все документы нового индекса имеют одну полную embedding version.
  • Эталонные вопросы находят ожидаемые фрагменты не хуже согласованного порога.
  • Новые документы появляются в обоих индексах во время миграции.
  • После переключения запросы используют ту же модель и preprocessing.
  • Откат alias возвращает старую выдачу без повторной загрузки данных.

Типичные ошибки при исправлении

  • Смешивать новые векторы со старыми только потому, что совпала размерность.
  • Оценивать качество по одному красивому примеру.
  • Удалять исходные chunks после сохранения embeddings.
  • Менять одновременно модель, chunking, prompt и reranker без раздельного сравнения.
  • Забывать очищать кеш векторов после смены версии.

Как предотвратить повторение

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

  • Записывайте версию pipeline в metadata и имя индекса.
  • Запретите запись несовместимой размерности и версии на уровне сервиса.
  • Поддерживайте постоянный набор regression queries.
  • Мониторьте zero results, score distribution и пользовательские сигналы качества.
  • Используйте неизменяемые model revisions вместо плавающих aliases в production.

Что контролировать после выпуска

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

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

  • Описание ожидаемого и фактического поведения с точной последовательностью действий.
  • Время проблемы, идентификатор тестового объекта и версии затронутых компонентов.
  • Фрагменты журналов до и после ошибки без секретов и персональных данных.
  • Перечень последних изменений и уже выполненных проверок.
  • Безопасный доступ к тестовой среде либо способ воспроизвести сбой без влияния на клиентов.

Частые вопросы

Можно ли конвертировать старые векторы в новые?

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

Что делать при одинаковой размерности?

Все равно считать модели несовместимыми, пока их совместимость явно не гарантирована поставщиком и не подтверждена тестами.

Нужен ли простой сайта?

Нет, если строить новый индекс параллельно и переключать alias после проверки.

Когда нужна помощь специалиста

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