FAISS: la libreria alla base della ricerca vectorielle

#Una libreria, non un database

Spesso si confronta FAISS con i database vettoriali come se fossero alternative. Non appartengono alle stesse categorie. Un database vettoriale è un servizio con un'API, archiviazione, filtraggio e permessi. FAISS è un componente: scritto in C++ con wrapper completi per Python e NumPy, riceve i vettori che gli fornisci, costruisce un indice in memoria e risponde alla domanda «quali sono i più vicini a questo vettore?». Diversi database vettoriali lo utilizzano, o utilizzano qualcosa di simile, al loro interno. Il progetto è pubblicato con licenza MIT, contava più di 41.000 stelle su GitHub a fine settembre 2026 e i suoi autori indicano che alcuni dei suoi metodi possono gestire miliardi di vettori nella memoria principale di un solo server.

La conseguenza pratica è che scegliere FAISS vuol dire accettare di gestire tutto il resto: salvare l'indice su disco, ricaricarlo, mantenerlo coerente con i tuoi documenti, collegare la posizione di un vettore al testo da cui proviene e decidere cosa succede quando due processi vogliono scrivere contemporaneamente. Niente di tutto questo è fornito di default; è una scelta architetturale consapevole, non una dimenticanza del progetto.

#Gli indici che contano

Il consiglio che fa risparmiare più tempo: iniziare con la ricerca esatta. Gli indici approssimati esistono per risolvere un problema di scala; adottarli prima di avere quel problema equivale a comprare parametri da regolare e un recall da misurare, in cambio di millisecondi che nessuno ha notato. Su un corpus locale, il recupero dei risultati non è quasi mai la fase lenta — è la generazione da parte del modello linguistico a dominare il tempo di risposta percepito dall'utente finale.

#Il minimo per iniziare in Python

1. 01
   Installare la libreria

   pip install faiss-cpu installa il pacchetto ufficiale PyPI (versione 1.15.1 alla fine di settembre 2026). Per la variante GPU, il progetto documenta un'installazione tramite conda: conda install -c pytorch -c nvidia -c conda-forge faiss-gpu=1.15.1.
2. 02
   Costruire un indice esatto

   index = faiss.IndexFlatL2(dimension) crea un indice di ricerca esatta per vettori della dimensione del tuo modello di embedding.
3. 03
   Aggiungere i vettori

   index.add(vecteurs), dove vecteurs è un array NumPy di forma (n, dimension) con valori in virgola mobile a 32 bit.
4. 04
   Interrogare

   distances, indices = index.search(requete, k) restituisce i k vicini più prossimi e le loro distanze; spetta a te associare indices ai frammenti di testo originali.
5. 05
   Salvare e ricaricare

   faiss.write_index(index, chemin) e poi faiss.read_index(chemin) permettono di conservare l'indice su disco tra due esecuzioni, poiché FAISS non lo fa da solo.

#Scegliere un indice in base alla dimensione del corpus

Il wiki ufficiale del progetto fornisce riferimenti precisi, espressi come stringhe da passare alla sua fabbrica di indice (index_factory). Per meno di un milione di vettori, IVF_K basta, con K scelto tra 4×√N e 16×√N in base al numero di vettori N, e un set di apprendimento composto da 30×K a 256×K vettori. Tra 1 e 10 milioni, la combinazione consigliata è IVF65536_HNSW32, che utilizza HNSW per accelerare l'assegnazione ai cluster. Tra 10 e 100 milioni, IVF262144_HNSW32; oltre, fino a un miliardo, IVF1048576_HNSW32 — in questo caso, l'apprendimento diventa notevolmente più lento e si svolge generalmente su GPU mentre il resto funziona su CPU.

Per un corpus documentale locale — da qualche migliaio a qualche centinaio di migliaia di frammenti di testo — questi riferimenti confermano soprattutto che si è lontani dalla soglia oltre la quale diventa necessario un indice approssimato: un indice esatto o, nel peggiore dei casi, un semplice IVF_K coprono la quasi totalità dei casi reali, e le configurazioni con diverse centinaia di migliaia di voci di addestramento restano fuori dalla portata di un normale uso documentale.

#La memoria, numeri alla mano

Un vettore di 1.024 dimensioni rappresentato con numeri in virgola mobile a 32 bit occupa circa 4 KB. Un milione di vettori occupa quindi circa 4 GB, senza contare la struttura dell'indice stesso. Nello specifico, per un indice HNSW, il wiki ufficiale fornisce la formula (d×4 + M×2×4) byte per vettore, dove d è la dimensione e M il numero di collegamenti per vettore (tra 4 e 64: più collegamenti, maggiore precisione, più memoria). Questi calcoli determinano la maggior parte delle architetture: è per questo che esiste la compressione ed è per questo che una macchina che ospita anche un modello linguistico dispone di meno margine di quanto si supponga.

Per quanto riguarda la compressione, la quantizzazione a prodotto (PQ) codifica ogni vettore in M byte, in genere al massimo 64 — oltre questa soglia, una quantizzazione scalare (SQ) è generalmente altrettanto precisa e più veloce. Quando la qualità della compressione conta davvero, la guida ufficiale consiglia di aggiungere una trasformazione OPQ prima della quantizzazione: questa riduce innanzitutto la dimensione del vettore mediante una trasformazione lineare che lo rende più facile da comprimere, poi applica la quantizzazione a prodotto al risultato. È un passaggio aggiuntivo da calcolare durante l'indicizzazione, ma riduce la perdita di precisione rispetto a una quantizzazione a prodotto diretta, a parità di dimensione del codice. RaBitQ, l'opzione di compressione massima, scende a circa (d/8 + 8) byte per vettore mantenendo un solo bit per dimensione, al prezzo di un passaggio di rotazione casuale necessario per conservare una precisione adeguata; esistono varianti con più bit per dimensione per recuperare un po' di precisione in cambio di un po' più di spazio di archiviazione.

#La funzione mancante che decide tutto

Le domande reali includono condizioni: solo i documenti di questo cliente, solo dopo questa data, solo ciò che questa persona ha il diritto di leggere. FAISS non ha alcuna nozione di metadati. La soluzione alternativa abituale — recuperare più risultati del necessario e poi filtrarli in Python — è sbagliata per un motivo preciso: se i cinquanta risultati migliori appartengono tutti a un altro reparto, il filtraggio non lascia nulla e il tuo assistente dichiara di non aver trovato alcuna informazione invece di dire che non ne ha trovata nessuna che tu possa vedere.

Il filtraggio in base ai permessi di accesso, in particolare, non deve essere implementato dopo il recupero dei dati. È l'argomento pratico più forte a favore di un sistema che filtra durante la ricerca: un database vettoriale, oppure vettori in PostgreSQL, dove il filtro è una clausola WHERE.

• pgvector: filtrare durante la ricerca, in SQL
• Qdrant: il servizio dedicato
• Milvus: il database vettoriale per grandi volumi
• La pipeline RAG completa
• Il kit RAG locale QuelLLM
• Fonte: repository ufficiale FAISS su GitHub
• Fonte: guida ufficiale alla scelta dell'indice
• Fonte: avvio rapido FAISS in Python

#Quando FAISS è la scelta giusta

Un'applicazione a singolo processo

Che carica un indice all'avvio e lo interroga: uno strumento desktop, un'elaborazione in batch, un notebook.

Un corpus fisso

Ricostruito secondo un calendario anziché aggiornato continuamente.

Nessun filtro per utente

O un filtraggio così grossolano che un indice per categoria resti ragionevole.

Una latenza critica

Quando il costo di un'andata e ritorno sulla rete verso un database è proprio ciò che vuoi eliminare, ad esempio in uno strumento embedded senza una connessione garantita.

Fuori da questi casi, il servizio che si evita di installare in generale costa meno nel tempo rispetto al codice di persistenza, filtraggio e concorrenza che si finisce per riscrivere da soli man mano che il progetto cresce.

Un ultimo punto di riferimento utile prima di decidere: diversi database vettoriali che incontrerai altrove non sostituiscono magicamente FAISS, ma lo incapsulano oppure si ispirano alle stesse famiglie di indici (IVF, HNSW, quantizzazione di prodotto), dietro un'API di rete, un sistema di persistenza gestito e un motore di filtraggio. Comprendere FAISS significa quindi comprendere buona parte del funzionamento interno degli stessi database vettoriali — un passaggio utile anche se il progetto finale usa Qdrant o Milvus anziché FAISS direttamente, perché gli stessi compromessi tra memoria e precisione si ritrovano con nomi di parametri diversi.

#FAQ