Nelle soluzioni RAG (Retrieval-Augmented Generation) la qualità della risposta finale dipende in modo diretto dalla qualità dei passaggi recuperati: se il retrieval restituisce chunk poco pertinenti, nemmeno il miglior modello generativo potrà produrre una risposta corretta. Azure AI Search offre tre leve complementari per massimizzare questa pertinenza — hybrid search, semantic ranker e, a valle, la groundedness detection di Azure AI Content Safety.

Hybrid search: fondere keyword e vector

La ricerca keyword classica (algoritmo BM25) eccelle sui match lessicali esatti: codici prodotto, sigle, nomi propri, acronimi. La vector search (indice HNSW su embedding, tipicamente generati da text-embedding-3-large) cattura invece la similarità semantica, trovando contenuti concettualmente affini anche quando le parole non coincidono. Nessuno dei due domina in tutti gli scenari.

La hybrid search esegue entrambe le query in parallelo sullo stesso indice e ne fonde i risultati con RRF (Reciprocal Rank Fusion). RRF non somma i punteggi grezzi (che sono su scale diverse e non confrontabili): assegna a ciascun documento uno score basato sulla sua posizione in ciascuna lista di ranking, secondo 1 / (k + rank). Il risultato è una lista unica robusta che valorizza i documenti ben posizionati in almeno una delle due modalità.

In pratica un’unica richiesta con un campo testuale (search) e uno o più vettori (vectorQueries) attiva la fusione automaticamente. La hybrid search è la baseline consigliata per il RAG perché combina precisione lessicale e comprensione semantica senza costi aggiuntivi rispetto alla vector search pura.

Semantic ranker: il re-ranking L2

RRF produce un buon ordinamento iniziale (stage L1), ma non “comprende” il significato della query rispetto ai documenti. Il semantic ranker aggiunge uno stadio L2: prende i primi circa 50 risultati di L1 e li ri-ordina con modelli linguistici cross-encoder di Microsoft (gli stessi della famiglia usata in Bing), calcolando la reale rilevanza semantica coppia query-documento.

Il semantic ranker fornisce inoltre:

  • @search.rerankerScore: punteggio 0-4 utilizzabile come soglia di qualità per filtrare i chunk da passare al modello.
  • Semantic captions: estratti evidenziati del passaggio più pertinente.
  • Semantic answers: una risposta candidata estratta letteralmente dai documenti.

Va abilitato con una semantic configuration che dichiara quali campi sono titolo, contenuto e keyword. È il complemento naturale della hybrid search: hybrid + semantic ranker supera quasi sempre, in precisione, sia il keyword sia il vector search usati da soli.

Groundedness detection

Anche con un retrieval ottimo, il modello generativo può allucinare, aggiungendo affermazioni non presenti nelle fonti. La groundedness detection di Azure AI Content Safety confronta la risposta generata con i grounding documents forniti e segnala le porzioni non supportate, opzionalmente con un reasoning che spiega il verdetto.

Il punto architetturale chiave: la groundedness detection valuta l’output generato, non la bontà del retrieval. È un controllo post-generazione che risponde alla domanda “quanto detto è ancorato alle fonti?”, non “le fonti recuperate erano quelle giuste?”. Va inserito nella pipeline come guardrail prima di mostrare la risposta all’utente, integrandolo con la strategia di citazioni.

Trappole tipiche d’esame

  • Scenario: cerchi la massima precisione nel retrieval RAG con codici prodotto e sinonimi → hybrid search + semantic ranker, non solo vector search; la combinazione batte le singole modalità.
  • Scenario: il team è preoccupato per i costi e il volume di query è molto alto → ricorda che il semantic ranker è un tier a pagamento con limiti di query (una quota gratuita mensile, poi fatturato): non abilitarlo indiscriminatamente su ogni query.
  • Scenario: devi rilevare che l’LLM ha inventato dettagli assenti nelle fonti → groundedness detection di Content Safety, che valuta l’output generato, non la qualità dei chunk recuperati.
  • Scenario: chiedono come vengono fusi keyword e vector results → RRF, che combina le posizioni di ranking, non la somma dei punteggi grezzi.
  • Scenario: vuoi filtrare i chunk deboli prima di passarli al modello → usa la soglia su @search.rerankerScore (0-4), non lo score BM25 o la cosine similarity grezza.