Embeddings e il vector data type

Un embedding è la rappresentazione numerica di un contenuto (testo, immagine, documento) prodotta da un modello di embedding come quelli di Azure OpenAI: un array di numeri a virgola mobile in cui la vicinanza geometrica riflette la vicinanza semantica. Due frasi dal significato simile generano vettori vicini nello spazio, anche senza condividere alcuna parola: è questa la base della ricerca “per significato” invece che “per parola chiave”.

SQL Server 2025, Azure SQL Database e SQL database in Fabric introducono un vector data type nativo che memorizza questi array in una colonna, con una dimensione fissa dichiarata che deve combaciare con l’output del modello (ad esempio 1536 dimensioni). Rispetto a conservare il vettore come JSON o stringa, il tipo nativo è più compatto, viene validato e risulta ottimizzato per il calcolo della distanza.

Il flusso tipico è: generi l’embedding del contenuto (spesso chiamando un modello esterno, ad esempio via sp_invoke_external_rest_endpoint), lo salvi nella colonna vector accanto ai dati originali, e a query time generi l’embedding della domanda dell’utente per confrontarlo con quelli archiviati.

Distanza, VECTOR_SEARCH e similarità

La similarità si misura con una funzione di distanza: cosine (angolo tra vettori, la più usata per il testo), euclidean (L2) o dot product. È fondamentale usare la stessa metrica con cui il modello lavora, altrimenti i risultati sono incoerenti. Un calcolo esatto confronta la query con ogni riga (full scan): preciso ma costoso e non scalabile su milioni di righe.

La funzione VECTOR_SEARCH esegue la ricerca di similarità restituendo i “top K” vicini, sfruttando l’indice quando disponibile. Concettualmente ordina le righe per distanza dalla query e ne restituisce le più simili: concentrati sul comportamento, non sulla firma esatta dei parametri.

Vector index e ricerca approssimata (ANN)

Un vector index accelera la ricerca su grandi volumi. Microsoft adotta algoritmi tipo DiskANN che organizzano i vettori in una struttura navigabile, così la query esplora solo una porzione dello spazio invece di scansionarlo tutto. Da qui il concetto chiave: la ricerca diventa approximate nearest neighbor (ANN), non esatta. Si scambia un po’ di recall (la percentuale di veri vicini effettivamente trovati) per un forte guadagno di latenza.

Senza indice la ricerca è esatta (KNN) ma lineare; con indice è approssimata ma sub-lineare. Per dataset piccoli la ricerca esatta può bastare; per cataloghi grandi con requisiti di latenza serve l’indice, accettando un recall inferiore al 100% ma tunabile in base al trade-off precisione/velocità.

La ricerca vettoriale pura eccelle nella semantica ma può mancare i match esatti su termini rari, codici prodotto, sigle o nomi propri, dove il keyword matching (full-text search, punteggio tipo BM25) resta superiore. La hybrid search combina i due mondi: esegue in parallelo ricerca vettoriale e ricerca testuale e ne fonde i risultati, tipicamente con Reciprocal Rank Fusion (RRF), che unisce i ranking senza dover normalizzare punteggi eterogenei. È la scelta migliore per scenari RAG realistici, dove l’utente mescola linguaggio naturale e termini precisi.

Trappole tipiche d’esame

  • Dataset enorme con latenza bassa richiesta → vector index (ANN): senza indice hai ricerca esatta ma lineare; l’indice rende la ricerca sub-lineare accettando recall < 100%.
  • Pochi record con risultati esatti garantiti → distanza esatta senza indice: su volumi piccoli il full scan è accettabile e non introduce l’approssimazione dell’ANN.
  • Query con codici, sigle o nomi propri mancati dalla semantica → hybrid search: combina vector e keyword con RRF; la sola ricerca vettoriale li perde.
  • Dimensione o metrica non combaciano col modello → errori o risultati falsati: la colonna vector ha dimensione fissa e la metrica deve essere coerente con l’embedding model.
  • Embeddings salvati come JSON/stringa → usa il vector data type nativo: garantisce validazione, compattezza e calcolo distanza ottimizzato.
  • “Servono external table per gli embeddings in Fabric” → non supportate: in SQL database in Fabric le external table non esistono; usa colonne vector native e, in caso di dubbi sulla sintassi, la documentazione ufficiale.