Questo scritto nasce da una domanda pratica: capire perché un sistema di memoria AI appena esaminato, Memory Vault di Faibrick, abbia scelto un certo modello di embedding e non un altro, e cosa avrebbe potuto scegliere di meglio. Ma per rispondere serve prima capire che cos'è davvero un embedder, come nasce, e su quali assi si misura. È un pezzo di infrastruttura invisibile su cui poggia quasi tutto il retrieval semantico moderno.
Un embedder è un modello che prende un pezzo di testo e lo trasforma in una lista di numeri, un vettore. L'idea è che testi con significato simile finiscano vicini in questo spazio numerico, e testi con significato lontano finiscano distanti. Se scrivi "il gatto dorme sul divano" e "il felino riposa sul sofà", un buon embedder li piazza a due passi l'uno dall'altro, anche se non condividono quasi nessuna parola. È qui la magia rispetto alla ricerca per parole chiave: l'embedder cattura il senso, non la forma.
Nella memoria di un sistema AI questo serve a una cosa sola ma cruciale: dato quello che l'utente sta chiedendo ora, ritrovare i frammenti di memoria più pertinenti anche se sono scritti con parole diverse. Si calcola il vettore della domanda, si cercano i vettori più vicini tra quelli archiviati, e si restituiscono i frammenti corrispondenti. La qualità di quel "più vicini" dipende interamente da quanto è bravo l'embedder.
Gli embedder moderni si addestrano quasi tutti con una tecnica chiamata apprendimento contrastivo. Si danno al modello milioni di coppie di testi: coppie "positive" che dovrebbero stare vicine (una domanda e la sua risposta, una frase e la sua parafrasi) e coppie "negative" che dovrebbero stare lontane. Il modello viene spinto, iterazione dopo iterazione, ad avvicinare le positive e allontanare le negative. La funzione di perdita più usata si chiama InfoNCE. È un principio semplice che, su scala di miliardi di esempi, produce spazi semantici sorprendentemente buoni.
Una distinzione tecnica che conta per capire il resto: esistono i bi-encoder e i cross-encoder. Un embedder è un bi-encoder: codifica ogni testo indipendentemente in un vettore, e poi confronta i vettori. È velocissimo, perché puoi pre-calcolare i vettori di tutta la tua memoria una volta sola. Il cross-encoder invece prende la domanda e un candidato insieme e li giudica in coppia: molto più accurato, ma molto più lento, perché non puoi pre-calcolare nulla. Questa differenza tornerà utile quando parleremo di reranking.
C'è poi la distillazione, ed è esattamente la storia del modello scelto da Faibrick. Un modello grande e potente (il "maestro") viene usato per addestrarne uno piccolo e veloce (lo "studente") che cerca di imitarne il comportamento. Si ottiene un modello minuscolo che gira su una CPU comune, al prezzo di una parte della qualità. È un compromesso legittimo, ma è un compromesso.
Memory Vault usa all-MiniLM-L6-v2, della famiglia sentence-transformers. È un modello distillato del 2021: sei strati, circa ventidue milioni di parametri, vettori da 384 dimensioni. Gira in locale su CPU, non chiama nessuna API, non manda dati da nessuna parte, ed è gratis. Per un prodotto che vende sovranità e self-hosting, la logica della scelta è trasparente: piccolo, veloce, autonomo, zero costi ricorrenti.
Il problema è che è anche modesto e datato. Trecentottantaquattro dimensioni sono poche: lo spazio semantico è compresso, e su corpus grandi o domande sottili la capacità di discriminare cala. È stato addestrato prevalentemente su inglese, il che è un limite serio per chi lavora in francese e in più lingue. E sui benchmark di riferimento si colloca a metà classifica, superato da un margine ampio da modelli usciti negli anni successivi. Va benissimo per una demo o un uso personale leggero; per un retrieval enterprise di qualità è il collo di bottiglia più evidente dell'intero sistema.
La cosa importante è che per superare MiniLM non serve rinunciare al self-hosting. Esistono modelli aperti, scaricabili, che girano sul tuo ferro e battono MiniLM di parecchie lunghezze.
La famiglia BGE, della Beijing Academy of AI, è il riferimento aperto più citato: bge-large produce vettori da 1024 dimensioni con qualità nettamente superiore, e soprattutto esiste bge-m3, multilingua su oltre cento lingue, con finestra di contesto lunga e la capacità di produrre insieme rappresentazioni dense e sparse. Per un caso d'uso francofono e multilingue come quello di Generations, bge-m3 è quasi la risposta ovvia.
La famiglia E5 di Microsoft è l'altro pilastro: e5-large e la variante multilingual-e5 sono forti sul retrieval e introducono l'idea dei prefissi, distinguendo esplicitamente una "query" da un "passage" per aiutare il modello. GTE di Alibaba gioca nello stesso campionato e nelle sue versioni più grandi sta stabilmente in cima ai benchmark. E poi c'è Nomic Embed, interamente aperto fin nei dati di addestramento, con una finestra di contesto molto lunga e la proprietà Matryoshka, che permette di tagliare le dimensioni del vettore a piacere per bilanciare qualità e costo.
Se si accetta di chiamare un servizio esterno, e quindi di mandare fuori i propri dati, la qualità sale ancora. I modelli text-embedding-3 di OpenAI, con vettori fino a 3072 dimensioni, Voyage con i suoi voyage-3 pensati apposta per il retrieval, e la famiglia embed-v3 di Cohere sono oggi il vertice pratico. Ma per un prodotto che si vende sulla sovranità del dato, questa strada è preclusa: nel momento in cui il testo esce dal tuo server per essere vettorializzato, hai perso esattamente la cosa che stavi vendendo. È una tensione reale, non un dettaglio.
C'è un intervento che spesso migliora il retrieval più del cambio di embedder, e costa poco: il reranker. Si usa l'embedder per pescare velocemente i primi trenta o cinquanta candidati, e poi si passa quella manciata a un cross-encoder che li rigiudica uno per uno in coppia con la domanda, riordinandoli. È il classico schema a due stadi: recupero veloce e grossolano, poi riordino lento e preciso su pochi elementi. Modelli come bge-reranker o i rerank di Cohere e Voyage danno spesso un salto di qualità superiore a quello che otterresti raddoppiando la potenza dell'embedder. Nel sistema di Faibrick, questo stadio semplicemente non c'è.
Quando si confrontano gli embedder non lo si fa a naso, ma su un benchmark condiviso chiamato MTEB, il Massive Text Embedding Benchmark. Raccoglie decine di compiti diversi, dal retrieval alla classificazione al clustering, e produce una classifica pubblica. È lo strumento onesto per rispondere alla domanda "questo modello è meglio di quello": si guarda il punteggio sui compiti di retrieval, nella lingua che interessa. È anche il modo più rapido per vedere, in un colpo d'occhio, quanto MiniLM sia ormai indietro rispetto alla generazione successiva.
Il modello scelto da Faibrick, all-MiniLM-L6-v2, è la scelta della sobrietà: minuscolo, locale, gratuito, ma del 2021, a bassa dimensionalità e sostanzialmente monolingue. È perfetto per far girare una dimostrazione ovunque, ed è il tetto di qualità del loro retrieval.
Restando sul terreno del self-hosting, gli aggiornamenti naturali si chiamano bge-m3 e la famiglia BGE, multilingual-e5 e la famiglia E5 di Microsoft, GTE di Alibaba, e Nomic Embed con le sue dimensioni regolabili. Sul versante a pagamento e non sovrano, il vertice è text-embedding-3 di OpenAI, Voyage e Cohere embed-v3. Sopra a tutto, come metodo, resta il principio del reranking con un cross-encoder in seconda battuta, e MTEB come metro di giudizio. Chi conosce questa mappa non guarda un sistema di memoria chiedendosi se usa i vettori, ma quali vettori usa, in che lingua, e se dopo il recupero c'è qualcuno che riordina.