La ricerca vettoriale sta progressivamente entrando nel cuore dei database relazionali.
Non si tratta semplicemente di aggiungere una nuova funzione SQL: significa poter interrogare
gli stessi dati contemporaneamente nello spazio relazionale,
nello spazio geografico e nello spazio semantico degli embedding.
Con DiskANN, Azure SQL può memorizzare embedding e utilizzare un indice
Approximate Nearest Neighbor direttamente accanto a tabelle, chiavi, transazioni,
metadati, filtri di sicurezza e, potenzialmente, dati spaziali.
Per un architect questo apre una domanda interessante:
abbiamo davvero bisogno di introdurre un vector database separato per ogni applicazione RAG?
In molti scenari la risposta potrebbe essere no.
Cos'è DiskANN
DiskANN significa Disk-based Approximate Nearest Neighbor.
È una famiglia di tecniche sviluppate per eseguire rapidamente ricerche di similarità
su collezioni vettoriali di grandi dimensioni.
Non genera embedding, non interpreta documenti e non è un Large Language Model.
DiskANN interviene dopo che i dati sono già stati trasformati in vettori.
Document
↓
Text extraction
↓
Chunking
↓
Embedding model
↓
Vector
↓
Azure SQL
↓
DiskANN
↓
Nearest neighbors
Il problema che risolve è apparentemente semplice:
dato un vettore q, trovare i vettori del database che gli sono più vicini.
Dallo spazio semantico allo spazio vettoriale
Un embedding model trasforma un oggetto, ad esempio una frase:
ArcGIS Enterprise supports federated GIS servers.
in una sequenza numerica:
[0.0182, -0.0317, 0.0041, ..., 0.0227]
Formalmente possiamo pensare all'embedding come a una funzione:
f : X → ℝᵈ
dove X è lo spazio degli oggetti originali e d
è la dimensionalità del vettore.
La singola coordinata non ha generalmente un significato interpretabile isolatamente.
È la posizione complessiva del vettore nello spazio multidimensionale a rappresentare
le caratteristiche apprese dal modello.
Se due contenuti hanno significato simile, il modello tende a collocarli in regioni
vicine dello spazio vettoriale.
Exact Nearest Neighbor: perché non basta
Il modo più semplice di trovare i vettori più vicini consiste nel confrontare la query
con ogni vettore presente nella tabella.
query
│
├── distance(vector 1)
├── distance(vector 2)
├── distance(vector 3)
├── ...
└── distance(vector N)
Con N vettori e dimensionalità D,
il lavoro cresce approssimativamente come:
O(N × D)
Con poche migliaia di record può essere perfettamente accettabile.
Con:
10.000.000 vectors
×
1.536 dimensions
la scansione esaustiva diventa invece molto più costosa.
È qui che entra in gioco l'Approximate Nearest Neighbor Search.
ANN: sacrificare un po' di perfezione per molta velocità
Un algoritmo ANN non garantisce necessariamente di restituire sempre gli stessi
vicini che otterremmo esaminando esaustivamente l'intero dataset.
Accetta un compromesso:
Exactness
↓ leggermente
Search space
↓ drasticamente
Latency
↓ drasticamente
Supponiamo che i veri dieci nearest neighbors siano:
A B C D E F G H I J
e che ANN restituisca:
A B C D E F G H I K
Il recall@10 sarebbe:
9 / 10 = 0.90
Per molte pipeline RAG questo trade-off è estremamente conveniente:
non abbiamo bisogno di dimostrare matematicamente quale chunk sia il più vicino,
ma di recuperare molto rapidamente un insieme di candidati altamente rilevanti.
DiskANN e grafi di prossimità
DiskANN utilizza un approccio graph-based.
Possiamo immaginare ogni embedding come un nodo collegato ad altri nodi utili
per navigare nello spazio vettoriale.
●──────●
/ \
●───● ●
│ \ /
●─────●──────●
\
●────●
La ricerca non deve quindi fare:
query → confronta tutti i vettori
ma può procedere concettualmente attraverso il grafo:
query
↓
entry point
↓
candidate neighbors
↓
better neighbors
↓
better neighbors
↓
Top-K
Il grafo consente di raggiungere rapidamente regioni promettenti dello spazio
senza valutare ogni riga.
Perché si chiama DiskANN
Uno degli elementi caratteristici del progetto DiskANN è l'attenzione alla possibilità
di lavorare con collezioni vettoriali molto grandi senza dipendere esclusivamente
dalla RAM.
RAM
┌────────────────┐
│ search state │
│ cache │
│ graph metadata │
└───────┬────────┘
│
│ selective access
▼
┌────────────────┐
│ SSD / storage │
│ vector data │
└────────────────┘
Naturalmente, quando utilizziamo DiskANN tramite Azure SQL non dobbiamo confondere
il principio algoritmico con l'implementazione interna del servizio managed:
cache, storage engine, I/O scheduling, quantizzazione e query optimization
sono responsabilità del database engine.
DiskANN è ora production-ready su Azure SQL
Il 29 settembre 2026 Microsoft ha annunciato la General Availability di
DiskANN Vector Index & Search su Azure SQL Database,
su Azure SQL Managed Instance configurato con la policy di aggiornamento
always-up-to-date e su SQL database in Microsoft Fabric.
La versione GA include elementi particolarmente importanti per workload reali:
- Approximate Nearest Neighbor Search basata su DiskANN;
- supporto a INSERT, UPDATE e DELETE;
- manutenzione asincrona dell'indice vettoriale;
- iterative filtering;
- integrazione con il query optimizer;
- possibilità di combinare vector search e predicati relazionali.
Il tipo VECTOR di SQL
Il database può memorizzare direttamente un embedding in una colonna vettoriale.
Un modello dati orientato a RAG potrebbe essere:
CREATE TABLE dbo.Documents
(
Id BIGINT IDENTITY PRIMARY KEY,
TenantId INT NOT NULL,
FileName NVARCHAR(500) NOT NULL,
Title NVARCHAR(500) NULL,
MimeType NVARCHAR(100) NULL,
CreatedAt DATETIME2 NOT NULL
DEFAULT SYSUTCDATETIME()
);
I chunk possono invece essere mantenuti separatamente:
CREATE TABLE dbo.DocumentChunks
(
Id BIGINT IDENTITY PRIMARY KEY,
DocumentId BIGINT NOT NULL,
TenantId INT NOT NULL,
PageNumber INT NULL,
ChunkNumber INT NOT NULL,
Content NVARCHAR(MAX) NOT NULL,
EmbeddingModel NVARCHAR(100) NOT NULL,
ChunkingVersion INT NOT NULL,
Embedding VECTOR(1536) NOT NULL,
CONSTRAINT FK_DocumentChunks_Documents
FOREIGN KEY (DocumentId)
REFERENCES dbo.Documents(Id)
);
1536 è solamente un esempio.
La dimensionalità deve essere coerente con il modello che genera gli embedding.
Versionare embedding e pipeline
Un embedding dovrebbe essere trattato come dato derivato,
non come sorgente primaria.
Conviene quindi conservare almeno:
Original document
Extracted content
Chunk
ChunkingVersion
Embedding
EmbeddingModel
EmbeddingVersion
CreatedAt
Questa informazione diventa fondamentale quando cambiamo modello.
Due modelli differenti possono produrre spazi vettoriali differenti:
non possiamo semplicemente mischiare embedding generati da modelli diversi
e aspettarci che le distanze rimangano semanticamente confrontabili.
Creazione dell'indice DiskANN
Sulla colonna vettoriale possiamo creare un indice:
CREATE VECTOR INDEX IX_DocumentChunks_Embedding
ON dbo.DocumentChunks(Embedding)
WITH
(
METRIC = 'cosine',
TYPE = 'diskann'
);
Le metriche supportate dalla vector search SQL comprendono:
La metrica non va scelta arbitrariamente:
deve essere coerente con il modello di embedding e con il modo in cui è stato addestrato.
Exact search con VECTOR_DISTANCE
Possiamo eseguire una ricerca esatta calcolando la distanza:
DECLARE @query VECTOR(1536) = @QueryEmbedding;
SELECT TOP (10)
Id,
DocumentId,
Content,
VECTOR_DISTANCE(
'cosine',
@query,
Embedding
) AS Distance
FROM dbo.DocumentChunks
ORDER BY Distance;
Questa strategia è utile anche come baseline per misurare la qualità dell'indice ANN.
Possiamo infatti confrontare:
Exact Top-K
vs
DiskANN Top-K
e misurare il recall effettivo sul nostro dataset.
Approximate search con VECTOR_SEARCH
Con gli indici vettoriali di nuova generazione la sintassi corrente utilizza
VECTOR_SEARCH insieme a:
TOP (N) WITH APPROXIMATE
Ad esempio:
DECLARE @query VECTOR(1536) = @QueryEmbedding;
SELECT TOP (10) WITH APPROXIMATE
c.Id,
c.DocumentId,
c.Content,
r.distance
FROM VECTOR_SEARCH(
TABLE = dbo.DocumentChunks AS c,
COLUMN = Embedding,
SIMILAR_TO = @query,
METRIC = 'cosine'
) AS r
ORDER BY r.distance;
La precedente forma basata sul parametro:
TOP_N = 10
appartiene alla generazione precedente dell'indice ed è deprecata per i nuovi indici.
WITH APPROXIMATE non è solo sintassi
Con:
SELECT TOP (10) WITH APPROXIMATE
stiamo dicendo esplicitamente al motore che accettiamo risultati ANN.
Senza WITH APPROXIMATE, VECTOR_SEARCH può eseguire
una ricerca kNN esatta.
VECTOR_SEARCH
│
├── exact kNN
│
└── approximate ANN / DiskANN
La distinzione è molto importante quando facciamo benchmarking.
Il query optimizer entra nella vector search
Uno degli aspetti architetturalmente più interessanti è che la ricerca vettoriale
non viene trattata come una scatola completamente separata dal motore SQL.
Azure SQL può valutare se utilizzare la strategia ANN oppure altre strategie
in funzione della query e della selettività.
Supponiamo di avere:
100.000.000 chunks
ma di applicare:
WHERE TenantId = 42
e che il tenant 42 contenga soltanto 5.000 chunk.
In determinate condizioni un piano differente potrebbe risultare più conveniente
rispetto all'attraversamento del grafo ANN globale.
FORCE_ANN_ONLY
Quando vogliamo imporre l'utilizzo dell'indice Approximate Nearest Neighbor,
Azure SQL mette a disposizione anche l'hint:
FORCE_ANN_ONLY
Concettualmente:
SELECT TOP (10) WITH APPROXIMATE
...
FROM VECTOR_SEARCH(
TABLE = dbo.DocumentChunks AS c,
COLUMN = Embedding,
SIMILAR_TO = @query,
METRIC = 'cosine'
) AS r WITH (FORCE_ANN_ONLY)
ORDER BY r.distance;
È utile soprattutto per test, benchmark o casi in cui sappiamo esattamente
quale strategia vogliamo utilizzare.
Come ogni hint SQL, non dovrebbe diventare automaticamente la scelta predefinita.
Iterative filtering: fondamentale per sistemi reali
Immaginiamo una piattaforma SaaS multi-tenant.
Il retrieval deve rispettare:
TenantId = 42
Una implementazione ANN ingenua potrebbe fare:
DiskANN
↓
10 nearest vectors
↓
WHERE TenantId = 42
↓
2 risultati validi
Gli altri otto vettori potrebbero appartenere ad altri tenant.
Con l'iterative filtering la ricerca può continuare nel grafo
finché non vengono trovati abbastanza risultati che soddisfano il predicato:
DiskANN
↓
candidate set
↓
relational filter
↓
enough results?
│
├── yes → return Top-K
│
└── no
↓
continue graph traversal
↓
more candidates
↓
relational filter
Questa caratteristica è importantissima per:
- multi-tenancy;
- ACL;
- categorie;
- stati applicativi;
- vincoli temporali;
- filtri geografici o amministrativi;
- security policies.
Vector search e security boundary
In un'applicazione RAG enterprise la sicurezza non deve essere applicata
dopo il retrieval.
Il flusso corretto deve essere progettato come:
User
↓
Identity
↓
Tenant / ACL / Security Policy
↓
Vector retrieval
↓
Permitted chunks
↓
LLM
In altre parole:
il retrieval fa parte del security boundary dell'applicazione.
Il vero RAG inizia prima di DiskANN
Una delle semplificazioni più pericolose è pensare che una pipeline RAG sia:
PDF → embedding → vector database
Una pipeline seria assomiglia molto di più a:
PDF
│
┌─────────┴──────────┐
│ │
Native text Scanned PDF
│ │
Text extraction OCR
│ │
└─────────┬──────────┘
↓
normalization
↓
structure analysis
↓
chunking
↓
embedding
↓
Azure SQL
↓
DiskANN
PDF nativi e PDF scansionati
Un PDF può contenere un vero text layer.
In questo caso è possibile estrarre direttamente:
Page
├── Heading
├── Paragraph
├── Paragraph
└── Table
Un PDF scansionato può invece contenere essenzialmente immagini:
PDF
├── page-001 image
├── page-002 image
└── page-003 image
In questo caso serve OCR.
In ambiente Azure una pipeline possibile è:
Azure Blob Storage
↓
Document ingestion service
↓
Azure AI Document Intelligence
↓
OCR + Layout + Tables + Structure
↓
Semantic chunking
↓
Embedding model
↓
Azure SQL
↓
DiskANN
Il punto importante è che non basta recuperare caratteri:
serve preservare il più possibile la struttura semantica del documento.
Chunking: spesso più importante del vector database
Consideriamo un manuale tecnico di 500 pagine.
Creare:
manual.pdf → one embedding
è generalmente poco utile.
È molto più efficace ottenere:
manual.pdf
│
├── chunk 001 → embedding
├── chunk 002 → embedding
├── chunk 003 → embedding
├── ...
└── chunk 850 → embedding
Fixed-size chunking
L'approccio più semplice consiste nel suddividere il testo per numero di token:
chunk 1 → tokens 0 - 499
chunk 2 → tokens 450 - 949
chunk 3 → tokens 900 - 1399
L'overlap aiuta a evitare che un concetto venga spezzato esattamente sul confine
tra due chunk.
Semantic chunking
Per documentazione tecnica possiamo però fare di meglio.
Section
├── paragraph
├── paragraph
├── code sample
├── table
└── note
L'obiettivo è costruire unità informative semanticamente coerenti,
non semplicemente blocchi di lunghezza costante.
Hierarchical chunking
Possiamo mantenere una gerarchia:
Document
↓
Chapter
↓
Section
↓
Chunk
Se DiskANN recupera il chunk 37 possiamo, ad esempio,
recuperare anche:
chunk 36
chunk 37
chunk 38
oppure la sezione padre.
Per questo conviene conservare:
DocumentId
SectionId
ParentChunkId
PageNumber
ChunkNumber
Embedding generation lato applicazione
Una pipeline .NET può essere concettualmente molto semplice:
var chunks = chunker.Split(document);
foreach (var chunk in chunks)
{
var embedding =
await embeddingService.GenerateAsync(chunk.Text);
db.DocumentChunks.Add(
new DocumentChunk
{
DocumentId = documentId,
TenantId = tenantId,
PageNumber = chunk.Page,
ChunkNumber = chunk.Index,
Content = chunk.Text,
EmbeddingModel = embedding.Model,
ChunkingVersion = 1,
Embedding = embedding.Vector
});
}
await db.SaveChangesAsync();
Dal punto di vista architetturale terrei ben separati:
Extraction
Chunking
Embedding
Persistence
Indexing
Retrieval
Generation
Questo rende la pipeline versionabile, osservabile e riprocessabile.
Azure SQL può generare embedding direttamente
Lo stack SQL moderno consente anche di registrare modelli esterni e invocarli
dal database.
Un external model può essere definito concettualmente così:
CREATE EXTERNAL MODEL MyEmbeddingModel
WITH
(
LOCATION = '...',
API_FORMAT = 'Azure OpenAI',
MODEL_TYPE = EMBEDDINGS,
MODEL = '...',
CREDENTIAL = ...
);
e successivamente:
AI_GENERATE_EMBEDDINGS(
N'ArcGIS Server federation'
USE MODEL MyEmbeddingModel
)
Microsoft supporta inoltre scenari in cui
AI_GENERATE_CHUNKS e AI_GENERATE_EMBEDDINGS
vengono combinati direttamente da T-SQL.
Questo rende possibile una pipeline:
SQL row
↓
AI_GENERATE_CHUNKS
↓
AI_GENERATE_EMBEDDINGS
↓
VECTOR
↓
DiskANN
Embedding nel database o nell'applicazione?
Il fatto che qualcosa sia possibile in SQL non significa che debba necessariamente
essere eseguito lì.
Generare embedding nell'application layer offre generalmente maggiore controllo su:
- retry;
- rate limiting;
- batching;
- fallback;
- observability;
- model routing;
- versioning della pipeline.
Generarli direttamente nel database può invece semplificare alcune pipeline
data-centric.
È quindi una decisione architetturale, non semplicemente sintattica.
RAG: Retrieve Wide, Rank Narrow
DiskANN non deve necessariamente restituire direttamente i chunk che finiranno
nel prompt.
Una pipeline più sofisticata può essere:
10.000.000 chunks
│
│ DiskANN
↓
50
│
│ reranker
↓
8
│
│ context builder
↓
LLM
Questo pattern viene spesso sintetizzato come:
Retrieve wide
↓
Rank narrow
Reranking
La prima fase privilegia throughput e recall.
Una seconda fase può utilizzare un modello più costoso per stimare meglio
la rilevanza rispetto alla domanda originale:
Question
+
50 candidate chunks
↓
Reranker
↓
Best 5 - 10
DiskANN e reranker risolvono quindi problemi differenti:
DiskANN:
find plausible candidates quickly
Reranker:
order those candidates accurately
Hybrid Search
Gli embedding non sostituiscono necessariamente la ricerca lessicale.
Una query come:
KB5034123 ArcGIS Server TLS
contiene token precisi, codici e identificativi che possono essere estremamente
significativi.
Una strategia moderna può combinare:
Vector similarity
+
Keyword search
+
Relational filters
+
Reranking
La vector search è quindi un ulteriore retrieval signal,
non necessariamente l'unico.
.NET ed Entity Framework Core
Per chi sviluppa applicazioni .NET è importante distinguere le versioni.
In EF Core 10 Microsoft ha introdotto il supporto alla traduzione
di VectorDistance(), quindi alla distanza vettoriale esatta.
In EF Core 11 Microsoft documenta inoltre le API dedicate
a vector index e VECTOR_SEARCH.
Ad esempio:
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<DocumentChunk>()
.HasVectorIndex(
x => x.Embedding,
"cosine");
}
La ricerca ANN può essere espressa concettualmente come:
var results = await db.DocumentChunks
.VectorSearch(
x => x.Embedding,
queryEmbedding,
"cosine")
.OrderBy(x => x.Distance)
.Take(10)
.WithApproximate()
.ToListAsync();
WithApproximate() corrisponde semanticamente alla richiesta:
TOP (...) WITH APPROXIMATE
È però importante notare che Microsoft documenta attualmente queste API
di EF Core 11 come funzionalità ancora soggette a evoluzione.
Per chi oggi usa .NET 10
In un'applicazione .NET 10 / EF Core 10 possiamo comunque utilizzare pienamente
Azure SQL Vector Search attraverso T-SQL, stored procedure, raw SQL o
VectorDistance() dove appropriato.
Non è quindi necessario aspettare EF Core 11 per costruire una soluzione DiskANN.
.NET 10
↓
EF Core / ADO.NET
↓
VECTOR_SEARCH T-SQL
↓
Azure SQL
↓
DiskANN
Architettura RAG completa su Azure
┌────────────────────┐
│ Azure Blob Storage │
└─────────┬──────────┘
│
▼
┌────────────────────┐
│ .NET Ingestion │
│ Worker / Service │
└─────────┬──────────┘
│
┌──────────────┴──────────────┐
│ │
▼ ▼
Text extraction Document Intelligence
OCR/Layout
│ │
└──────────────┬──────────────┘
▼
Semantic Chunking
│
▼
Embedding Model
│
▼
┌────────────────┐
│ Azure SQL │
│ │
│ relational │
│ metadata │
│ security │
│ chunks │
│ vectors │
│ DiskANN │
└───────┬────────┘
│
▼
Retrieval
│
▼
Reranker
│
▼
Context Builder
│
▼
LLM
│
▼
Response
Vector database dedicato o Azure SQL?
Non esiste una risposta universale.
Un vector database specializzato può essere preferibile quando:
- la vector search domina completamente il workload;
- la scala è estremamente elevata;
- servono feature vector-native molto specializzate;
- l'architettura richiede distribuzione specificamente progettata per ANN.
Azure SQL è invece particolarmente interessante quando:
- i dati applicativi sono già relazionali;
- servono transazioni;
- la sicurezza dipende dal modello relazionale;
- i filtri sui metadati sono importanti;
- vogliamo evitare sincronizzazione tra database;
- vector search integra, ma non sostituisce, il workload applicativo.
La domanda corretta diventa quindi:
Which vector database should I add?
oppure:
Do I actually need another database?
Sono due domande architetturalmente molto diverse.
DiskANN + Spatial SQL: il collegamento con il GIS
Per chi lavora con GIS la parte più interessante inizia probabilmente qui.
Una feature geografica potrebbe avere contemporaneamente:
Feature
├── Id
├── Geometry
├── Attributes
├── Description
├── Category
├── Temporal information
└── Embedding
La stessa entità appartiene quindi a tre spazi differenti.
Relational space
Geographic space
Semantic vector space
Tre tipi diversi di distanza
Consideriamo due aree territoriali.
La distanza geografica può essere:
180 km
ma la loro distanza nello spazio degli embedding può indicare una fortissima similarità:
Semantic similarity = very high
Due territori possono essere lontani fisicamente ma molto simili rispetto a:
- demografia;
- uso del suolo;
- mobilità;
- densità commerciale;
- accessibilità;
- servizi;
- indicatori economici;
- caratteristiche ambientali.
GeoAI: da distanza geometrica a similarità funzionale
Una possibile query concettuale potrebbe essere:
Find areas
within 50 km
AND
land_use = 'industrial'
AND
area > 50000 m²
AND
semantically similar to:
"areas suitable for logistics,
close to major transport infrastructure,
with low residential pressure"
Qui stiamo combinando:
Spatial predicate
+
Relational predicate
+
Vector similarity
Spatial Index e Vector Index sono concetti differenti
Uno spatial index indicizza oggetti come:
POINT
LINESTRING
POLYGON
Un vector index indicizza invece:
[0.018, -0.032, 0.004, ..., 0.071]
Il fatto che entrambi utilizzino la parola "vector" in alcuni contesti
non deve creare confusione.
Sono strutture pensate per risolvere problemi completamente differenti.
Ma possono lavorare insieme.
Un possibile modello GeoAI
CREATE TABLE GeoAssets
(
Id BIGINT PRIMARY KEY,
TenantId INT NOT NULL,
Name NVARCHAR(250),
Category NVARCHAR(100),
Geometry GEOGRAPHY,
Description NVARCHAR(MAX),
Embedding VECTOR(1536)
);
Concettualmente potremmo eseguire:
Relational filtering
↓
Spatial filtering
↓
Vector retrieval
↓
Reranking
↓
GeoAI result
Embedding territoriali
Possiamo andare ancora oltre e generare un embedding non da un semplice testo,
ma da una rappresentazione complessa del territorio.
Territory
│
├── Population
├── Income
├── Land use
├── Mobility
├── POIs
├── Accessibility
├── Satellite features
└── Demographics
│
▼
Encoder
│
▼
Territory embedding
A quel punto possiamo chiedere:
Find areas similar to this area
senza limitarci a una distanza euclidea o geografica.
Passiamo dalla prossimità geometrica alla
similarità funzionale appresa.
Osservabilità
Una pipeline RAG production-grade va misurata end-to-end.
Almeno:
Document extraction latency
OCR latency
Chunking throughput
Embedding latency
Embedding failures
Indexing throughput
ANN latency
Exact KNN latency
Recall@K
Reranking latency
Context size
LLM latency
Token usage
End-to-end latency
Possiamo modellare la latenza totale come:
Ttotal =
Textract
+ Tembed
+ Tretrieve
+ Trerank
+ Tcontext
+ Tllm
Ottimizzare DiskANN di 10 ms ha poco senso se la generazione dell'LLM
richiede diversi secondi.
Valutare scientificamente il retrieval
Un buon sistema RAG non dovrebbe essere valutato soltanto chiedendo:
La risposta sembra buona?
Dobbiamo costruire un dataset di valutazione:
Question
Expected relevant chunks
Expected source documents
e misurare:
- Recall@K;
- Precision@K;
- MRR;
- NDCG;
- latency;
- cost per query.
Possiamo così confrontare in modo ripetibile:
Embedding Model A vs B
Chunk size 300 vs 800
Overlap 50 vs 150
Exact KNN vs DiskANN
Top-10 vs Top-50
With reranker vs without reranker
Vector-only vs Hybrid Search
DiskANN non sostituisce il database design
La presenza di embedding non rende improvvisamente irrilevanti:
- primary key;
- foreign key;
- indici B-tree;
- statistics;
- query plans;
- partitioning;
- security;
- transactions;
- data lifecycle;
- backup e disaster recovery.
La vector search è un'altra modalità di accesso al dato,
non un sostituto del modello relazionale.
La vera convergenza
L'aspetto più interessante di Azure SQL + DiskANN non è poter eseguire
una query con cosine distance.
È poter mantenere nello stesso dominio dati:
Transactions
Business entities
Users
Security
Documents
Metadata
Spatial objects
Embeddings
e interrogarli utilizzando:
Relational Search
Full-Text Search
Spatial Search
Vector Search
L'AI non deve necessariamente possedere una copia parallela del database aziendale.
Può diventare un'altra modalità con cui l'applicazione
interroga gli stessi dati operativi.
Conclusione
DiskANN è interessante dal punto di vista algoritmico perché rende possibile
una Approximate Nearest Neighbor Search efficiente su collezioni vettoriali
di grandi dimensioni.
Ma il cambiamento più importante è probabilmente architetturale.
Azure SQL
│
├── Relational data
├── Transactions
├── Security
├── Documents
├── Spatial data
├── Vectors
└── DiskANN
In una moderna applicazione AI questo può ridurre la necessità di introdurre
un'infrastruttura dati parallela esclusivamente per il retrieval vettoriale.
E nel GIS il concetto diventa ancora più interessante.
Relational space
+
Geographic space
+
Semantic vector space
↓
GeoAI
La domanda GIS tradizionale:
What is near this location?
può evolvere verso:
What is geographically, semantically and functionally similar to this location?
È qui che DiskANN smette di essere semplicemente una tecnologia per
"fare RAG sui PDF" e diventa qualcosa di più generale:
un nuovo strumento per interrogare dati, conoscenza e territorio.
Riferimenti tecnici
