Замена embedding-модели — миграция в маске конфиг-флага (blue/green для векторов)
Саммари
Есть тип аварии, который не выглядит аварией: сервис зелёный, задержки ровные, ошибок ноль — а поиск тихо начинает возвращать мусор. Это происходит в момент, когда на индекс, построенный старой моделью, нацеливают новую. Ничего не падает, просто результаты перестают иметь смысл. Разбор — о том, почему смена embedding-модели это миграция данных, а не смена версии, и какой runbook её делает безопасной.
Из этого следует: самая опасная авария в этом классе не имеет симптомов в метриках, поэтому проверять апгрейд можно только на собственных запросах — recall@k на golden set до переключения, а не «посмотрим, что скажут пользователи».
На практике для агентной памяти это значит то же, что для векторного индекса: смена модели эмбеддинга у базы уроков, заметок и памяти агентов — это миграция с двойной записью и атомарным переключением, а не правка строки конфигурации.
Важный нюанс: выученный адаптер даёт 85–95% качества и отлично подходит как временная мера, но ошибка зависит от семантической близости двух моделей — при радикально разных моделях процент может оказаться заметно ниже заявленного.