Il costo ricorrente di embedding e vector store
Aggiornato September 1, 2026 · pubblicato inizialmente September 1, 2026
Il costo degli embedding viene approvato come voce di progetto: un corpus di qualche milione di documenti, una sola esecuzione, una cifra che sembra piccola accanto alla spesa per la generazione. Poi non si ferma mai, perché tre forze distinte rifanno l'embedding di cose per cui hai già pagato.
I tre motori di aggiornamento
Il ricambio dei contenuti è quello più onesto e il più piccolo. Documenti che cambiano, nuovi che arrivano, vecchi da rimuovere. Cresce con il business ed è prevedibile.
Le modifiche a chunking e pipeline sono quelle subdole. Ogni ritocco a dimensione del chunk, overlap, metadati o preprocessing invalida ogni vettore nello store. Un esperimento sulla qualità del retrieval che sembra un semplice ritocco di configurazione è un re-embedding completo dell'intero corpus, e in un buon trimestre i team ne fanno parecchi.
I cambi di modello sono quelli grossi. Gli spazi di embedding non sono compatibili tra modelli, quindi adottare un modello migliore o più economico significa rifare l'embedding di tutto prima di poter interrogare qualsiasi cosa. Non esiste un percorso incrementale né una migrazione parziale — si tengono due store in parallelo oppure si accetta un'interruzione.
Lo store è una voce a sé
Anche tenere i vettori ha un costo. I database vettoriali gestiti addebitano lo storage e il calcolo per servire le query, e la dimensionalità incide su entrambi: un modello a dimensioni più alte, appena migliore nel retrieval, può costare molto di più da ospitare per sempre. Questo compromesso di solito lo fa chi ha scelto il modello, guardando solo la qualità, senza alcuna visibilità sulla bolletta dell'hosting.
Budgetalo come un'annualità
Prevedi un re-embedding completo del corpus almeno una volta all'anno e trattalo come un evento programmato, non come un'eccezione. Valuta un modello candidato su costo del re-embedding più un anno di storage e di servizio delle query, non sul prezzo per token. Mantieni il contenuto sorgente indirizzabile, così un re-embedding è un job batch e non un progetto di re-ingestione — e lancia quei job tramite un endpoint batch, perché il re-embedding completo è il carico più tollerante alla latenza che possiedi, quindi quello in cui il prezzo batch rende di più.
Correlati
Correlati
Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito →