Stack-ul tău de embedding forțează un re-index 100% doar pentru a schimba modelul. Și majoritatea echipelor tratează asta ca fiind inevitabil. Imaginează-ți că construiești un pipeline RAG cu un model mare de embedding pentru o calitate ridicată a recuperării și acesta este livrat în producție. Șase luni mai târziu, traficul aplicației și costurile modelului de embedding cresc vertiginos, în timp ce pipeline-ul tău se chinuie să scaleze. Vrei să treci la un model care prioritizează costul și latența pentru a răspunde acestei noi cereri. Dar încorporațiile tale existente trăiesc într-un spațiu vectorial, în timp ce noul model produce încorporații într-unul diferit, ceea ce le face incompatibile. Comutarea modelelor înseamnă acum reconstruirea indexului: - Fiecare document trebuie reîncorporat - Fiecare bucată trebuie recalculată - Milioane de vectori trebuie regenerați înainte ca interogările să funcționeze din nou Majoritatea echipelor analizează asta și decid să preia costul în loc să schimbe. În timp, acest lucru se întărește într-o regulă nespusă. Ori optimizezi pentru calitate, ori optimizezi pentru costuri și trăiești cu decizia luată devreme. Dar aceasta nu este o limitare fundamentală a încorporațiilor. Este o alegere de design. Ce s-ar întâmpla dacă modelele de încorporare ar avea același spațiu vectorial? În această configurație, ai putea indexa documente folosind un model mare și să le interogezi folosind unul mai ușor, fără să reconstruiești nimic. ...