Ваш стек вбудовування змушує 100% переіндексувати лише для зміни моделей. І більшість команд вважають це неминучим. Уявіть, що ви побудували RAG-конвеєр з великою моделлю вбудовування для високої якості отримання, і він надходить у виробництво. Через шість місяців трафік вашого додатку та витрати на модель вбудовування стрімко зростають, тоді як ваш конвеєр намагається масштабуватися. Ви хочете перейти на модель, яка пріоритезує вартість і затримку, щоб задовольнити цей новий попит. Але ваші існуючі вкладення знаходяться в одному векторному просторі, тоді як нова модель створює вкладення в іншому, що робить їх несумісними. Перемикання моделей тепер означає перебудову індексу: - Кожен документ потрібно повторно вбудувати - Кожен шматок має бути перерахований - Мільйони векторів потрібно відновити, перш ніж запити знову запрацюють Більшість команд звертають на це увагу і вирішують взяти на себе витрати замість переходу. З часом це затверджується в негласне правило. Ви або оптимізуєте якість, або оптимізуєте за вартістю, і жити з рішенням, прийнятим на початку. Але це не є фундаментальним обмеженням вбудовувань. Це дизайнерський вибір. А що, якби embedding models використовували один і той самий векторний простір? У такій конфігурації можна було індексувати документи великою моделлю і запитувати їх легшою, не перебудовуючи нічого. ...