Il tuo stack di embedding costringe a un re-indicizzazione del 100% solo per cambiare modello. E la maggior parte dei team considera questo come inevitabile. Immagina di aver costruito una pipeline RAG con un grande modello di embedding per una qualità di recupero elevata, e che venga messa in produzione. Sei mesi dopo, il traffico della tua applicazione e i costi del tuo modello di embedding stanno aumentando vertiginosamente mentre la tua pipeline fatica a scalare. Vuoi passare a un modello che dia priorità ai costi e alla latenza per soddisfare questa nuova domanda. Ma i tuoi embedding esistenti vivono in uno spazio vettoriale, mentre il nuovo modello produce embedding in un altro, il che li rende incompatibili. Passare a un nuovo modello ora significa ricostruire l'indice: - Ogni documento deve essere ri-embedded - Ogni chunk deve essere ricalcolato - Milioni di vettori devono essere rigenerati prima che le query funzionino di nuovo La maggior parte dei team guarda a questo e decide di assorbire il costo invece di cambiare. Col tempo, questo si indurisce in una regola non scritta. O ottimizzi per la qualità o ottimizzi per il costo, e vivi con la decisione che hai preso all'inizio. Ma questa non è una limitazione fondamentale degli embedding. È una scelta di design. E se i modelli di embedding condividessero lo stesso spazio vettoriale? In quella configurazione, potresti indicizzare documenti utilizzando un grande modello e interrogarli utilizzando uno più leggero, senza ricostruire nulla. ...