Ваш стек встраивания требует 100% переиндексации только для смены моделей. И большинство команд рассматривают это как неизбежное. Представьте, что вы построили RAG-пipeline с большой моделью встраивания для высокого качества извлечения, и она отправляется в продакшен. Через шесть месяцев трафик вашего приложения и затраты на модель встраивания стремительно растут, в то время как ваш pipeline испытывает трудности с масштабированием. Вы хотите переключиться на модель, которая приоритизирует стоимость и задержку, чтобы удовлетворить этот новый спрос. Но ваши существующие встраивания находятся в одном векторном пространстве, в то время как новая модель производит встраивания в другом, что делает их несовместимыми. Смена моделей теперь означает перестройку индекса: - Каждый документ нужно пере-встраивать - Каждый фрагмент должен быть пересчитан - Миллионы векторов должны быть сгенерированы заново, прежде чем запросы снова будут работать Большинство команд смотрят на это и решают поглотить затраты, вместо того чтобы переключаться. Со временем это становится негласным правилом. Вы либо оптимизируете качество, либо оптимизируете стоимость, и живете с решением, которое приняли в начале. Но это не фундаментальное ограничение встраиваний. Это выбор дизайна. Что если модели встраивания делили одно и то же векторное пространство? В такой конфигурации вы могли бы индексировать документы, используя большую модель, и запрашивать их, используя более легкую, не перестраивая ничего. ...