Più modelli di embedding possono coesistere in un unico sistema di ricerca privato?

Sì. Un singolo sistema di ricerca privato può archiviare e interrogare contemporaneamente embedding provenienti da più modelli. L'approccio sicuro consiste nel trattare ogni modello di embedding come un proprio spazio vettoriale, con dimensioni, metrica di distanza, versione e configurazione dell'indice esplicite. Non mescolare vettori incompatibili in un'unica colonna anonima dando per scontato che siano confrontabili.

Più modelli sono utili per le migrazioni, la ricerca multilingue, il recupero combinato di immagini e testo, gli embedding specifici per dominio o i test A/B. La complessità emerge quando è necessario combinare i risultati provenienti da questi spazi.

Perché conservare più di un modello di embedding?

Una knowledge base privata si evolve. Vincolare permanentemente ogni documento al primo modello di embedding scelto rende gli aggiornamenti inutilmente problematici.

Modelli diversi producono spazi vettoriali diversi

Due modelli possono entrambi generare vettori da 768 dimensioni e rimanere incompatibili. Le coordinate hanno significato solo in relazione al modello che le ha prodotte.

Documento A
  |
  +-- Modello v1 -> vector_v1 [768]
  |
  +-- Modello v2 -> vector_v2 [1024]
  |
  +-- modello di immagini -> vector_image [512]

Una query generata con il Modello v2 dovrebbe cercare nello spazio v2. Confrontarla direttamente con i vettori del Modello v1 non ha senso, anche se un'API accetta le dimensioni.

L'attuale documentazione sui vettori denominati di Qdrant supporta esplicitamente più vettori di dimensioni e tipi diversi nello stesso punto, ciascuno in uno spazio vettoriale denominato separato.

Usa un registro dei modelli, non solo un nome per il vettore

Registra metadati sufficienti per riprodurre ogni embedding:

spazio_embedding: text_v2
id_modello:        esempio/nome-modello
revisione_modello:  sha-o-versione
dimensione_vettore:      1024
metrica:          coseno
normalizzato:      vero
politica_di_chunking: semantica-v3
creato_il:      2026-09-03

Anche il chunking deve rientrare nel registro. Se cambi sia il modello di embedding sia il modo in cui i documenti vengono suddivisi, il recupero cambia per due motivi. Rendere esplicita la versione della pipeline permette il confronto e il rollback.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Una raccolta con vettori denominati o raccolte separate?

Entrambe le progettazioni possono essere corrette.

Anche la documentazione delle raccolte di Weaviate supporta più spazi vettoriali denominati per oggetto, ciascuno con la propria configurazione di vectorizer e indice.

Se le autorizzazioni differiscono, ad esempio tra documenti familiari e documenti di lavoro, le raccolte separate possono comunque essere più semplici che inserire ogni rappresentazione nello stesso oggetto.

Pgvector può archiviare dimensioni diverse?

Sì. La documentazione di Pgvector mostra una colonna generica vector con un model_id, quindi utilizza indici basati su espressioni e parziali per le righe con una dimensionalità specifica.

Il principio è lo stesso: mantieni l'identità del modello nel modello dei dati e crea l'indice ANN solo sulle righe compatibili.

Non confrontare i punteggi grezzi di similarità tra modelli

Questo è il problema più subdolo. Una similarità coseno di 0.78 dal Modello A non indica necessariamente la stessa qualità di 0.78 dal Modello B. Le distribuzioni dei punteggi dipendono dall'addestramento del modello, dalla normalizzazione, dalla metrica, dal dominio e dal comportamento dell'indice.

Se vuoi un unico elenco di risultati da due modelli di embedding, esegui prima il recupero separatamente:

Query
  |
  +-- Modello A -> primi 20 risultati + ranking
  |
  +-- Modello B -> primi 20 risultati + ranking
                      |
                      v
               fusione / reranker
                      |
                      v
                  primi 10 finali

I metodi di combinazione più sicuri includono la fusione dei ranking, la normalizzazione dei punteggi specifica per il modello e calibrata sui tuoi dati, oppure un cross-encoder/reranker che valuta il testo candidato dopo il recupero.

La documentazione di Weaviate sulla ricerca multi-target illustra strategie di combinazione, incluse combinazioni normalizzate/pesate, mostrando perché la fusione tra spazi richiede una strategia esplicita anziché un ordinamento ingenuo basato sui punteggi grezzi.

Come si esegue la migrazione a un nuovo modello di embedding senza tempi di inattività?

Non eliminare prima i vecchi embedding. Usa una migrazione parallela:

1. registra il nuovo modello e lo spazio vettoriale;
2. genera nuovi embedding per i documenti acquisiti di recente;
3. ricostruisci i dati dei vecchi documenti in batch;
4. esegui ricerche shadow in entrambi gli spazi;
5. confronta il richiamo e il successo delle attività su domande reali;
6. imposta il nuovo spazio di query come predefinito;
7. mantieni i vecchi vettori per un periodo di rollback;
8. rimuovili solo quando la fiducia è elevata.

Weaviate osserva che l'aggiunta di un nuovo vettore denominato non ricalcola automaticamente i vettori degli oggetti esistenti. È utile ricordarlo perché “lo schema supporta il nuovo modello” e “tutti i dati esistenti hanno i nuovi vettori” sono traguardi distinti.

Più embedding aumentano lo spazio di archiviazione più rapidamente di quanto molti utenti si aspettino

Ogni rappresentazione vettoriale aggiuntiva può introdurre un altro array denso e un altro indice ANN. Pertanto, un secondo modello di embedding può all'incirca moltiplicare la parte del database relativa a vettori e indici, anche se i documenti originali vengono archiviati una sola volta.

Stima:

byte dei vettori ~=
  segmenti di documento
  x dimensioni
  x byte per elemento
  x numero di spazi di embedding

+ overhead dell'indice ANN
+ indici di metadati / payload

Gli indici quantizzati o a mezza precisione possono ridurre l'ingombro, ma verifica la qualità del recupero prima di applicare la compressione a ogni modello.

Questo si ricollega alla questione dell'architettura delle knowledge base locali: gli embedding sono dati derivati sostituibili, mentre i documenti sorgente e i metadati sono risorse durevoli che consentono di ricrearli.

Usa modelli diversi per percorsi di query diversi

Non è necessario cercare in ogni spazio vettoriale per ogni domanda. Instrada la ricerca in base alle necessità:

Un piccolo classificatore delle query può selezionare lo spazio appropriato, mentre le ricerche ambigue possono essere eseguite su due rappresentazioni e combinarne i risultati.

Le autorizzazioni devono essere applicate prima della fusione

Non recuperare candidati non autorizzati da ogni spazio vettoriale sperando che il reranker finale li nasconda. Applica i permessi dell'utente e del documento in ogni fase del recupero, così i segmenti sensibili non entrano nel gruppo di candidati, nei log o nel prompt del reranker.

Per la ricerca privata su NAS, la stessa regola di controllo degli accessi deve essere mantenuta durante le migrazioni del modello. Un nuovo indice deve ereditare i metadati delle autorizzazioni del documento, anziché diventare una copia temporanea non protetta.

La guida all'assistente IA privato fornisce il contesto più ampio: la ricerca vettoriale è utile solo quando rispetta gli stessi confini dei dati privati dell'archivio di file.

Checklist QA per gli embedding multipli

• Assegna a ogni spazio di embedding un ID univoco del modello e della versione.
• Registra le dimensioni, la normalizzazione e la metrica di distanza.
• Versiona la suddivisione in segmenti e la preelaborazione.
• Non interrogare l'indice di un modello usando il vettore di un altro modello.
• Non confrontare direttamente i punteggi grezzi tra spazi senza calibrarli.
• Applica i permessi all'interno di ogni percorso di recupero.
• Ricostruisci i nuovi vettori prima di modificare l'impostazione predefinita.
• Valuta il sistema con domande reali e documenti noti pertinenti.
• Mantieni l'indice precedente per tutta la finestra di rollback.
• Includi i vettori e gli indici aggiuntivi nella pianificazione della capacità del disco e della RAM.

Domande frequenti

Due modelli di embedding possono usare dimensioni diverse nello stesso database?

Sì, se il database supporta spazi vettoriali denominati, raccolte o indici separati per ogni dimensione compatibile. Qdrant, Weaviate e pgvector offrono tutti approcci adatti a questo scopo.

Posso cambiare modello di embedding senza ricalcolare gli embedding dei vecchi documenti?

Non se vuoi che i vecchi documenti siano ricercabili nello spazio vettoriale del nuovo modello. Un nuovo vettore di query non è compatibile con gli embedding prodotti da un altro modello.

Devo conservare per sempre i vecchi embedding?

No. Conservali durante la valutazione e per il rollback. Una volta convalidato il nuovo modello e completata la migrazione, rimuovere i vettori obsoleti può recuperare una quantità considerevole di spazio di archiviazione e memoria degli indici.

Verdetto finale

Più modelli di embedding possono coesistere ordinatamente in un unico sistema di ricerca privato quando i relativi spazi vettoriali rimangono espliciti. Memorizza i metadati del modello e della pipeline, interroga ogni spazio con l'encoder corrispondente, combina deliberatamente i risultati ed esegui la migrazione ricostruendo gli indici in parallelo. Il design pericoloso non è usare «più di un modello», ma perdere traccia di quale modello abbia prodotto ciascun vettore e fingere che ogni punteggio di similarità abbia lo stesso significato.