La compressione degli indici vettoriali riduce la RAM memorizzando rappresentazioni a precisione inferiore, ma la conseguente distorsione delle distanze può ridurre il richiamo dei vicini più prossimi.
Un indice RAG domestico può rimanere comodamente entro centomila segmenti e diventare limitato dalla memoria dopo anni di documenti, foto e trascrizioni. La quantizzazione può mantenere residenti più vettori, ma la qualità della ricerca dipende dal fatto che le distanze compresse preservino o meno lo stesso ordinamento dei candidati della precisione completa. Il risultato varia in base alla distribuzione degli embedding, al rapporto di compressione, al tipo di indice, all’ampiezza dell’insieme di candidati e alla disponibilità dei vettori originali per il ricalcolo dei punteggi.
La compressione riduce il carico dei vettori, non tutti i costi dell’indice
Un indice vettoriale usa memoria per i valori degli embedding, le strutture a grafo o a partizioni, gli identificatori, i metadati, l’overhead dell’allocatore e i buffer temporanei delle query. La compressione riduce principalmente la rappresentazione degli embedding. I collegamenti HNSW e i metadati possono rimanere simili, quindi il risparmio complessivo di RAM può essere inferiore a quanto suggerisca il rapporto di compressione dei vettori.
I vettori ad alta dimensionalità sono costosi perché ogni dimensione memorizzata come valore a precisione completa contribuisce al costo della memoria e del calcolo delle distanze. Sostituire questi valori con codici compatti riduce il carico residente e può migliorare l’efficienza della cache.
Il risparmio effettivo dipende quindi dalla composizione dell’indice. I vettori float ad alta dimensionalità offrono solitamente un ampio margine di riduzione; i vettori piccoli con connettività elevata nel grafo possono garantire un risparmio proporzionalmente inferiore. Misura la memoria residente del processo e i file dell’indice prima e dopo la compressione, invece di moltiplicare i byte grezzi dei vettori per il numero di documenti.
La quantizzazione introduce una distorsione delle distanze
La quantizzazione scalare mappa ogni dimensione su un intervallo numerico più piccolo, mentre la quantizzazione del prodotto divide un vettore in sottospazi e memorizza le scelte del codebook. Entrambe sostituiscono le coordinate esatte con approssimazioni. La distanza della query viene quindi calcolata rispetto a valori ricostruiti o alle distanze del codebook, anziché rispetto al vettore float originale.
Gli esperimenti con la quantizzazione del prodotto valutano la compressione misurando la distorsione delle distanze ricostruite e il richiamo. Codici più compatti possono ridurre la latenza o l’uso della memoria, ma rendono anche più difficile ordinare correttamente i candidati vicini quando le loro distanze reali sono simili.
Il richiamo diminuisce quando un vicino rilevante scende sotto la soglia dei candidati, non semplicemente perché ogni distanza è leggermente errata. Le query con un margine netto tra segmenti rilevanti e irrilevanti possono resistere a una compressione elevata; i vicinati semantici densi, con molte distanze quasi equivalenti, sono più sensibili.
L’espansione dei candidati e il ricalcolo dei punteggi possono recuperare il richiamo
Una ricerca in due fasi usa vettori compressi per trovare un’ampia rosa di candidati, quindi ricalcola le distanze con vettori a precisione maggiore per quei candidati. Il sovracampionamento offre agli elementi rilevanti più possibilità di superare la prima fase approssimata; il ricalcolo dei punteggi ripristina l’ordinamento nei casi in cui i codici compatti abbiano sfumato piccole differenze di distanza.
I livelli di compressione più elevati riducono in genere il richiamo, mentre il sovracampionamento e il ricalcolo dei punteggi possono migliorare la precisione. Il recupero richiede letture, memoria e lavoro aggiuntivi durante la query, quindi la compressione sposta il consumo di risorse invece di eliminare il costo in termini di qualità.
Mantenere i vettori completi su disco può preservare un uso ridotto della RAM, ma aggiunge latenza di archiviazione durante il riordinamento. Mantenerli in RAM migliora la latenza, ma riduce il vantaggio in termini di memoria. La configurazione più utile dipende dal fatto che il server domestico sia limitato dalla capacità della memoria, dalle operazioni di I/O al secondo dello storage o dagli obiettivi di tempo di risposta.
Il richiamo deve essere misurato sull’attività di recupero locale
Costruisci un set di riferimento eseguendo una ricerca esatta o ad alta precisione per query rappresentative, quindi confronta se la ricerca compressa restituisce gli stessi vicini rilevanti entro i primi k risultati. Includi parafrasi, nomi propri, documenti quasi duplicati, termini rari e query la cui risposta dipende da una sottile distinzione tra le prove.
Questo completa la fiducia nel grounding del recupero: la similarità dei vicini e il supporto alla risposta sono correlati, ma non identici. Misura Recall@k rispetto alla ricerca di riferimento e verifica anche se i segmenti persi o riordinati modificano le prove disponibili per il generatore.
Non esiste un vincitore universale tra compressione massima e precisione massima. Aumenta la compressione finché RAM, latenza e richiamo sull’attività raggiungono l’equilibrio desiderato, quindi ripeti i test dopo modifiche al modello di embedding o al corpus. Una configurazione efficace per un’ampia ricerca di similarità tra foto potrebbe essere troppo degradante per il recupero di documenti tecnici con molti passaggi semanticamente adiacenti.
Hub Tecnologico e AI
Altro da leggere

Perché l’architettura del server domestico Jellyfin cambia quando aggiungi servizi
Un server Jellyfin diventa uno stack di servizi man mano che vengono aggiunte altre app, quindi CPU, spazio di archiviazione, rete, credenziali, backup e...

Come misurare le prestazioni di Jellyfin senza confondere la cache con la capacità
Un benchmark affidabile di Jellyfin distingue chiaramente lo stato a freddo da quello a caldo, così i metadati memorizzati nella cache o le pagine...

Quanto margine di iGPU serve a Jellyfin multiutente?
Il margine disponibile dell’iGPU per Jellyfin dipende dal carico di lavoro: riserva un margine superiore alla combinazione di transcodifiche simultanee ripetibile più impegnativa, non...

