Un database vettoriale risponde a una domanda, molto in fretta
Dagli una lista di numeri e restituisce le liste memorizzate più vicine ad essa. Questa è tutta l'interfaccia.
Le liste sono embedding. Un modello di embedding trasforma un passaggio, una descrizione di prodotto o un'immagine in poche centinaia o migliaia di numeri, posizionati in modo che significati simili finiscano vicini tra loro, e cosa sono gli embedding nell'IA spiega come. Un database vettoriale è dove vivono quelle liste una volta che ne hai molte. Memorizza ognuna con un ID e alcuni metadati, costruisce un indice su di esse e risponde alla ricerca del vicino più prossimo: "ecco un vettore di query, dammi i dieci più vicini."
La parte difficile è la parola veloce. Confrontare una query con un milione di vettori memorizzati di 1.536 numeri ciascuno significa 1,5 miliardi di moltiplicazioni, e farlo a ogni tasto premuto non è scalabile. Per questo i database vettoriali usano indici di ricerca approssimata del vicino più prossimo, il più diffuso dei quali è HNSW, una struttura a grafo tratta da un paper del 2016 di Malkov e Yashunin che visita poche centinaia di candidati invece di tutto il milione e restituisce la risposta giusta quasi sempre. Quel "quasi" è il compromesso: un po' di richiamo per un'accelerazione di mille volte.
Il tuo database esistente trova parole; un database vettoriale trova significati
Un database relazionale trova righe i cui valori corrispondono: WHERE customer_id = 4127. Un indice full-text trova documenti che contengono parole: rimborso AND politica. Un database vettoriale trova elementi il cui significato è vicino: la query "come faccio a riavere i miei soldi" restituisce il passaggio intitolato "Resi e rimborsi" anche se le due frasi non condividono nessuna parola.
| Database relazionale | Ricerca full-text | Database vettoriale | |
|---|---|---|---|
| Chiede | Quali righe corrispondono a questo valore? | Quali documenti contengono queste parole? | Quali elementi hanno un significato vicino a questo? |
| Indice | B-tree sulle colonne | Indice invertito sui termini | Grafo o clustering sui vettori (HNSW, IVF) |
| Esatto? | Sì | Sì | Di solito approssimato |
| Bravo con | ID, date, importi, join | Nomi, codici, frasi esatte | Sinonimi, parafrasi, lingue diverse, immagini |
| Debole su | Il significato | Il significato | Stringhe esatte, conteggi, filtri per valore |
| Esempi | Postgres, MySQL, SQLite | Elasticsearch, Lucene | Pinecone, Weaviate, Qdrant, Milvus, Chroma, pgvector |
L'ultima riga mostra quanto sia sfumata la categoria. pgvector aggiunge colonne vettoriali e un indice HNSW al normale Postgres, ed Elasticsearch porta un campo vettoriale fin dalla versione 7.0 del 2019 e la ricerca HNSW dalla 8.0 del 2022. Un "database vettoriale" è spesso una capacità dentro un database che già usi, più che un prodotto nuovo, e i prodotti a sé stanti competono su scala e rifinitura operativa, non sul fare qualcosa che Postgres non può fare.
Il chat con i tuoi documenti è una ricerca vettoriale con un modello alla fine
La generazione aumentata dal recupero, che cos'è il RAG illustra nel dettaglio, ha un passaggio di ricerca e uno di scrittura. Il database vettoriale è il passaggio di ricerca.
- Dividi ogni documento in passaggi di poche centinaia a un migliaio di token.
- Trasforma in embedding ogni passaggio e memorizza i vettori, con il testo del passaggio e la sua fonte, nel database vettoriale.
- Quando arriva una domanda, trasformala in embedding e chiedi al database i passaggi più vicini.
- Consegna quei passaggi al modello linguistico insieme alla domanda, e lascia che scriva la risposta.
I passaggi 1 e 2 avvengono una sola volta, quando i documenti vengono aggiunti. I passaggi 3 e 4 avvengono a ogni domanda. Il modello linguistico non vede mai l'intera raccolta; vede i cinque o dieci passaggi scelti dal database. Ecco perché la risposta vale quanto la ricerca: se il vettore più vicino è il passaggio sbagliato, il modello risponde con sicurezza alla domanda sbagliata, cosa che cos'è un'allucinazione dell'IA classifica come un errore di recupero e non come un'invenzione.
Quando ti serve uno, e quando inviare l'intero file è meglio
La decisione riguarda la dimensione. Un modello può considerare solo la sua finestra di contesto alla volta, e ogni token al suo interno viene pagato a ogni turno. Un database vettoriale esiste per mettere davanti al modello solo la porzione rilevante. Per un unico documento che ci sta, il recupero è un passaggio che puoi saltare; per una raccolta che non ci sta, è l'unica opzione.
Confronta i due approcci su un report di 300.000 token, alcune centinaia di pagine, con dieci domande poste, recuperando cinque passaggi di 1.000 token a domanda. Inviare l'intero file ogni volta significa 3 milioni di token in ingresso. Recuperare cinque passaggi da 1.000 token a domanda significa 50.000. Alle tariffe di listino in ingresso dell'indice dei costi dei modelli di IA, rilevate da OpenRouter il 2026-08-20, il divario è di 60 volte su ogni modello. Il caching dei prompt, dove il fornitore lo offre, addebita una rilettura dello stesso file a un decimo o alla metà del prezzo di listino, il che riduce il divario a circa 6 volte fino a 30 volte. Il recupero vince ancora, ma di meno.
L'approccio con il file intero compra qualcosa con quella spesa quando il file rientra nel budget: un contratto di 60 pagine, circa 40.000 token, permette al modello di rispondere a domande che richiedono l'intero documento in una volta, come "c'è qualcosa qui che contraddice la clausola 14", cosa che il recupero non può fare perché non vede mai la clausola 14 e la contraddizione nello stesso lotto. Ne discende la regola: un documento, o una manciata, va inviato per intero; una libreria passa attraverso un database vettoriale. Nel mezzo, dividi il caricamento per argomento in modo che il modello riceva la sezione di cui ha bisogno.
Whizi invia il testo stesso, fino a un turno di 40.000 token
Whizi non usa un database vettoriale per la tua chat. Quando alleghi un file, il percorso di caricamento documenti estrae il testo e lo invia al modello come testo del prompt, fino a un budget fisso di 40.000 token per turno; un caricamento più lungo viene tagliato, con un toast e un indicatore nel messaggio che lo segnala. I file dei progetti funzionano allo stesso modo: la funzione progetti fissa fino a 10 file e ricostruisce il loro testo nel prompt a ogni messaggio, con un limite di 32.000 caratteri per file e 120.000 per l'intero blocco del progetto.
I limiti sono il confine del design. Un file fissato oltre i 32.000 caratteri viene troncato, un allegato oltre il budget di 40.000 token per turno viene tagliato, e un progetto è una cartella, non una libreria interrogabile. Il compromesso è deliberato: per un contratto o un articolo che rientra nel budget del turno, avere il testo presente batte averlo cercato, e il controllo che conta, chiedere al modello di citare il passaggio che ha usato, funziona perché il passaggio è lì. Per mille documenti, un database vettoriale è lo strumento giusto e un'app di chat è quello sbagliato.
Due abitudini derivano da questo meccanismo. Nomina il file nella tua domanda quando ne sono allegati diversi, perché altrimenti il modello sceglie in silenzio. E su qualsiasi risposta su cui agirai, chiedi la citazione. Un sistema di recupero può restituire il passaggio sbagliato; un sistema a file intero può rispondere a memoria invece che dal file. La citazione coglie entrambi i casi.
- Invia un documento per intero; metti una raccolta dietro a un database vettoriale
- Dividi un caricamento lungo per argomento in modo che il modello riceva la sezione di cui la domanda ha bisogno
- Chiedi al modello di citare il passaggio che ha usato prima di fidarti della risposta
- Usa la ricerca full-text per ID, codici e frasi esatte; la ricerca vettoriale trova significati, non caratteri
- Tratta un errore di recupero come un problema di ricerca: ricrea gli embedding con un modello migliore o passaggi più piccoli prima di dare la colpa al modello che scrive
Domande frequenti
Cos'è un database vettoriale in parole semplici?
Un archivio per le liste di numeri che un modello di IA usa per rappresentare il significato, costruito per trovare velocemente le corrispondenze più vicine. Gli dai l'embedding di una domanda e restituisce gli embedding, e il testo dietro di essi, che hanno un significato simile. È la metà di ricerca del chat con i tuoi documenti ogni volta che la raccolta è troppo grande per essere inviata per intero.
Mi serve un database vettoriale per usare l'IA con i miei documenti?
Solo se i documenti non entrano nella finestra di contesto del modello. Un singolo report o contratto può essere inviato al modello per intero, cosa che Whizi fa con gli allegati e i file di progetto fissati. Una libreria di migliaia di documenti richiede il recupero, e il recupero richiede un indice vettoriale, sia in un prodotto dedicato sia in un'estensione di Postgres come pgvector.
Qual è la differenza tra un database vettoriale e un database normale?
Un database normale trova corrispondenze di valori: questo ID, questa data, questa parola esatta. Un database vettoriale trova corrispondenze di significato, restituendo gli elementi memorizzati i cui embedding sono più vicini a quello della query. Di solito è approssimato, usando un indice come HNSW che controlla poche centinaia di candidati invece di ogni elemento, ed è scarso nella corrispondenza esatta in cui un database normale eccelle.
Quali database vettoriali sono più usati?
Pinecone, Weaviate, Qdrant, Milvus e Chroma sono i prodotti a sé stanti più comuni, e pgvector aggiunge la stessa capacità a Postgres. Anche Elasticsearch e OpenSearch offrono ricerca vettoriale. La scelta è di solito operativa, riguarda scala e hosting, perché tutti implementano la stessa idea di ricerca approssimata del vicino più prossimo.
Quanto fa risparmiare il recupero rispetto all'invio dell'intero file?
Dieci domande su un report di 300.000 token costano $6.00 su Claude Sonnet 5 se il file viene inviato a ogni turno e $0.10 se vengono recuperati cinque passaggi da 1.000 token, alle tariffe di listino di OpenRouter rilevate il 2026-08-20. Su GPT-5.6 Luna la stessa coppia è $0.60 contro $0.01. Il rapporto è di 60 volte su ogni modello perché entrambi gli approcci pagano la stessa tariffa per token.
