Váš embedding stack nutí 100% reindex jen kvůli změně modelu. A většina týmů to považuje za nevyhnutelné. Představte si, že jste vytvořili RAG pipeline s velkým modelem embeddingu pro vysokou kvalitu získávání a ten se odesílá do výroby. O šest měsíců později vaše aplikační provoz a náklady na model vkládání vystřelují, zatímco váš pipeline se snaží škálovat. Chcete přejít na model, který upřednostňuje náklady a latenci, abyste vyhověli této nové poptávce. Ale vaše stávající embeddingy jsou v jednom vektorovém prostoru, zatímco nový model vytváří embeddingy v jiném, což je činí neslučitelnými. Přechod na model nyní znamená přestavbu indexu: - Každý dokument je třeba znovu vložit - Každý blok musí být znovu spočítán - Je třeba znovu generovat miliony vektorů, než dotazy opět fungují Většina týmů se na to podívá a rozhodne se náklady pokrýt místo přechodu. Postupem času se to ztvrdne v nevyřčené pravidlo. Buď optimalizujete kvalitu, nebo náklady a žijete s rozhodnutím, které jste učinili brzy. Ale to není zásadní omezení embeddingů. Je to designová volba. Co kdyby embedding modely sdílely stejný vektorový prostor? V tomto nastavení jste mohli indexovat dokumenty pomocí velkého modelu a dotazovat je pomocí lehčího, aniž byste museli cokoli znovu budovat. ...