Azure AI Search non si dimensiona in base a quanti vettori hai. Si dimensiona per tier: il vector index è vincolato dalla memoria riservata alla vector search sul tuo SKU, e nel modello Serverless da un limite rigido di 300 MB per index che fa fallire il job di indexing quando viene superato. Quella singola proprietà, non un confronto di feature, decide se il layer di retrieval dell'azienda appartiene ad Azure AI Search o a un vector database dedicato. La Parte 6 ha reso economiche le domande ripetute. Questa parte gestisce il caso molto più comune, in cui il modello ha bisogno di fatti che non ha mai visto, e la knowledge search retail della Parte 1 viene finalmente costruita.

Dove sta il retrieval rispetto al gateway

Un punto da chiarire prima di qualsiasi confronto, perché è quello che tiene in piedi la premessa della serie: il retrieval non è traffico del gateway. L'applicazione interroga direttamente il search index, assembla un prompt da ciò che torna indietro e invia quel prompt attraverso il gateway come qualsiasi altra completion. Il gateway misura i token che il contesto recuperato aggiunge, che è esattamente la visibilità che vuoi, dato che il retrieval è di solito il punto in cui la dimensione del prompt triplica in silenzio.

L'unica parte che tocca davvero il gateway è l'embedding. Generare gli embeddings di query e documenti è una chiamata a un modello, quindi passa dalla stessa porta di tutto il resto, con la stessa quota e la stessa attribuzione. Questo significa anche che il deployment di embeddings creato nella Parte 6 per il semantic caching è probabilmente lo stesso deployment che serve al retrieval, e la sua capacità ora serve due padroni.

I limiti che decidono davvero

Le checklist di feature fanno sembrare Azure AI Search e un vector store dedicato intercambiabili. I service limit no.

  • La dimensione del vector index è una funzione dello SKU, non dei tuoi dati. Nel modello di pricing Dedicated è vincolata dalla memoria riservata alla vector search sul tier; in Serverless è 300 MB per index, circa il 30 percento dello storage totale dell'index, ed è un limite rigido che fa fallire l'indexing invece di degradarlo.
  • I limiti sui vettori dipendono da quando il servizio è stato creato. Le quote vettoriali più alte si applicano ai servizi creati da aprile 2024 in poi nelle region con la capacità aggiuntiva. Un servizio più vecchio in una region supportata può richiedere un upgrade esplicito per ottenerle, che è una questione di migrazione più che un toggle di configurazione.
  • La capacità è il prodotto di replica e partition. Basic supporta tre partition e tre replica, nove search unit, sui servizi creati dopo il 3 aprile 2024; i servizi Basic più vecchi sono limitati a una partition. Da S1 a S3 si arriva a dodici di ciascuno.
  • Lo SLA è un conteggio di replica. Due o più replica per i carichi di query, tre o più per query e indexing. Il numero di partition non è affatto una considerazione dello SLA, il che sorprende chi ha scalato per lo storage assumendo che l'availability fosse inclusa.
  • Il numero di index è limitato per tier. Cinque o quindici su Basic, cinquanta su S1, duecento su S2 e S3. Una piattaforma che dà a ogni tenant il proprio index incontra quel soffitto molto prima di incontrare lo storage, e index-per-tenant è l'istinto di default.
  • Massimo 4096 dimensioni per vector field, su ogni tier, che è generoso ma vale la pena saperlo prima che qualcuno standardizzi su un embedding model più grande.

Letti insieme, questi limiti dicono qualcosa di specifico: Azure AI Search è prezzato e scalato come un servizio di search che fa anche vettori. Se il corpus vettoriale è il costo dominante e cresce indipendentemente dal volume di query, stai pagando search unit per tenere memoria. Quella è la condizione in cui un vector database dedicato vince, ed è una condizione quantitativa che puoi verificare, non una preferenza architetturale.

Cosa ti dà Azure AI Search che un vector store non dà

Il contrappeso è reale e spesso decisivo per una knowledge base aziendale.

Hybrid search in una sola richiesta. Una singola query porta sia un parametro search sia vectorQueries, esegue full-text e vector retrieval in parallelo e fonde i risultati con Reciprocal Rank Fusion in un unico result set ordinato. Il ranking testuale usa BM25; quello vettoriale usa HNSW o exhaustive KNN. Conta perché la documentazione prodotto è piena di token esatti, numeri di modello, codici di errore, part number, che la ricerca lessicale trova in modo affidabile e gli embeddings sfumano.

{
  "search": "device not connecting after the firmware update",
  "vectorQueries": [
    { "kind": "vector", "vector": [ ... ], "k": 50,
      "fields": "contentVector", "exhaustive": false, "oversampling": 10 }
  ],
  "queryType": "semantic",
  "semanticConfiguration": "kb-semantic",
  "top": 10
}

Filtering, faceting, sorting e scoring profile si applicano alla stessa richiesta, quindi l'autorizzazione a livello di documento (questo tenant, questa linea di prodotto, questa lingua) è un filtro invece di un index separato. L'integrated vectorization tramite gli indexer legge da Blob Storage, Cosmos DB, Azure SQL o OneLake e calcola gli embeddings in fase di ingest, il che elimina un'intera pipeline che il platform team dovrebbe altrimenti mantenere. E l'index può essere collegato come knowledge source per gli scenari agent in Microsoft Foundry.

Un dettaglio di capacità si nasconde dentro la storia della qualità del ranking. Il semantic ranker è throttlato da una coda, con un massimo di richieste concorrenti per search unit che è 2 su Basic, 3 su S1 e 4 da S2 in su, più una coda limitata dietro. Superata la coda, le richieste vengono rifiutate e vanno ritentate. Il modo per alzare il limite è avere più search unit, o aprire una richiesta di supporto. Un layer di retrieval che attiva il semantic ranking su ogni query ha quindi appena reso il proprio soffitto di concorrenza una funzione del tier di search, e quel soffitto è piccolo su Basic.

La decisione, formulata come test

Non una preferenza. Tre verifiche, in ordine:

  • Il corpus ha bisogno di retrieval lessicale e vettoriale insieme? Se gli identificatori esatti contano, e per la documentazione prodotto contano sempre, hybrid più semantic ranking in un unico servizio vale molto, e reimplementarlo sopra un vector store puro significa far girare anche un inverted index.
  • Il footprint vettoriale cresce indipendentemente dal volume di query? Se sì, modella le search unit necessarie a contenerlo e confrontale con un vector database dimensionato sullo storage. È aritmetica, ed è di solito il punto in cui la risposta si ribalta.
  • Quanti corpora logici ci sono? Index-per-tenant raggiunge in fretta il soffitto di index per tier. L'alternativa è un solo index con un tenant filter, che è un controllo di sicurezza da applicare nel query layer, non nel client.

Per questa piattaforma la risposta è Azure AI Search, perché la knowledge base retail è qualche decina di gigabyte di documentazione prodotto in cui i numeri di modello esatti contano, e perché il costo operativo di un managed service in più è inferiore al costo di un vector store autogestito sullo stesso cluster AKS. La risposta per un memory store di agent con centinaia di milioni di vettori e nessun requisito lessicale sarebbe l'opposto, e la serie sbaglierebbe a fingere il contrario.

Tenancy, e il filtro che è un controllo di sicurezza

Un solo index con un tenant filter è il default corretto sotto il soffitto sul numero di index, e mette una decisione di autorizzazione dentro la query. La regola è la stessa del vary-by della Parte 6: il valore del filtro viene dal token validato, mai da un parametro della richiesta. Un'applicazione che passa il proprio tenant ID è a un bug di distanza dal passare quello di qualcun altro.

Poiché il retrieval non passa da API Management, il punto di enforcement è l'applicazione o il control plane, non una policy del gateway. È una lacuna genuina nel modello one-door, ed è meglio nominarla che nasconderla: il gateway governa l'accesso ai modelli, il search service governa l'accesso ai documenti, e sono due control plane diversi che devono concordare su chi sia il tenant. Derivare entrambi dallo stesso claim di Entra ID è ciò che impedisce loro di divergere.

Modalità di fallimento da tenere d'occhio

  • Indexing che fallisce a un limite di dimensione invece di degradare. Superare il cap vettoriale per index su Serverless fa fallire l'operazione. La capacità del vector index è un input di pianificazione, non qualcosa da scoprire durante un bulk load.
  • Un search service vecchio con quote vettoriali vecchie. Creato prima di aprile 2024, in una region che ora offre di più, e silenziosamente limitato finché qualcuno non lo aggiorna.
  • Scalare le partition aspettandosi availability. Le partition sono storage. Lo SLA conta le replica, due per le query e tre quando l'indexing gira in parallelo.
  • Semantic ranker che throttla sotto carico. La concorrenza è per search unit ed è piccola sui tier bassi. Il sintomo sono query rifiutate al picco, non query lente.
  • Index-per-tenant contro un soffitto di tier. Funziona benissimo per la prima dozzina di tenant e poi si ferma, e a quel punto la migrazione verso un index filtrato è un progetto dati.
  • Contesto recuperato che gonfia la dimensione del prompt. Il gateway lo misura, quindi compare nei numeri della Parte 5 come un aumento di token senza alcuna modifica al codice che lo spieghi. Metti un alert sui token per richiesta per tenant, non solo sulla spesa totale.

Cosa eredita la Parte 8

Un layer di retrieval che le applicazioni chiamano direttamente, un deployment di embeddings condiviso con la cache, e prompt ora considerevolmente più grandi di prima. Il che solleva la domanda di cui parla la prossima parte: quando un'applicazione ha bisogno di retrieval, tool calling e più hop tra modelli, un framework di orchestrazione appartiene sopra questo gateway, o il framework inizia a combatterlo.

Leggi questo dopo

Per il lato infrastruttura e piattaforma di come far girare tutto questo su scala, gli appunti tecnici sono su ercan.cloud, e l'hub è su ercanermis.com.

Riferimenti