La generazione aumentata dal recupero è il pattern più ricorrente dell’esame perché risolve il problema che rende inutilizzabile un LLM in azienda: il modello ha una data di taglio della conoscenza e non ha mai visto i tuoi documenti. RAG non insegna niente al modello. Mette i pezzi giusti dei tuoi dati dentro il contesto della singola richiesta, e chiede al modello di rispondere solo con quelli. Sembra semplice, e infatti quasi tutte le difficoltà stanno nel recupero, non nella generazione.

Le tre parti del pattern, e dove si rompe davvero

Un flusso RAG ha tre stadi. Il recupero prende la domanda dell’utente e interroga un archivio ricercabile. La costruzione del contesto sceglie quali frammenti passare, in che ordine e con quali metadati (titolo, URL di origine) perché la risposta possa citarli. La generazione produce la risposta con istruzioni che vincolano il modello alle fonti fornite e gli impongono di dichiarare quando non sa.

Quando la risposta è sbagliata, il colpevole è quasi sempre il primo stadio. Le rotture tipiche sono tre. La prima: il frammento giusto non è mai stato recuperato, per chunking troppo grossolano, per una query che non assomiglia lessicalmente al documento, o perché il numero di risultati richiesti è troppo basso. La seconda: i frammenti sono stati recuperati ma sono troppi, e la parte utile si perde in un contesto rumoroso. La terza: il contesto era corretto e il modello ha risposto lo stesso a memoria, il che è un problema di istruzioni e non di ricerca.

Questa distinzione ha un corrispettivo diretto negli evaluator, e sapere quale usare per quale sintomo è materia d’esame: Retrieval e Document Retrieval misurano lo stadio di recupero, Groundedness e Relevance misurano la risposta finale. Se Groundedness è basso ma Retrieval è alto hai un problema di prompt; se sono bassi entrambi hai un problema di indice.

Quale motore di recupero scegliere

Foundry offre tre livelli, e la domanda «quando usare cosa» è più importante della sintassi.

Il file search su un vector store è la via gestita: carichi i file, il servizio li analizza, li spezza, ne calcola gli embedding e li indicizza. È adatto a un corpus documentale contenuto e stabile, quando non vuoi possedere una pipeline di ingestion. Le impostazioni di default sono chunk da 800 token con 400 di sovrapposizione, text-embedding-3-large a 256 dimensioni e al massimo 20 frammenti aggiunti al contesto. L’ingestion è asincrona: finché lo stato non è completed la ricerca non vede i contenuti, quindi si usano gli helper di polling dell’SDK prima di generare risposte. Si può collegare al massimo un vector store per agente e uno per conversazione, e i vector store creati dalle conversazioni hanno una policy di scadenza predefinita di sette giorni dall’ultimo utilizzo: se un’applicazione «funzionava e dopo qualche giorno ha smesso», quella è la causa da controllare per prima.

Un indice Azure AI Search collegato al progetto è la scelta quando l’indice esiste già, quando lo popoli con una tua pipeline o quando ti servono filtri e controllo fine sulla ricerca. I parametri che contano sono index_name, top_k (default 5), filter e soprattutto query_type, che accetta simple, vector, semantic, vector_simple_hybrid e vector_semantic_hybrid, con quest’ultimo come default. La ricerca ibrida combina corrispondenza lessicale e vettoriale ed è la scelta ragionevole quasi sempre: la ricerca puramente vettoriale sbaglia sui codici prodotto e sugli acronimi, quella puramente lessicale sbaglia sulle riformulazioni.

Foundry IQ è il livello più alto: una knowledge base riutilizzabile che aggrega più knowledge source (Azure Blob Storage, SharePoint, OneLake, web) e applica il recupero agentico, che scompone la domanda in sottoquery, le esegue in parallelo e riordina i risultati. Il motivo per sceglierlo raramente è tecnico: applica gli ACL delle sorgenti e le etichette di riservatezza di Microsoft Purview, ed esegue le query sotto l’identità Microsoft Entra del chiamante. Se il requisito dice «ogni utente deve vedere solo i documenti a cui ha diritto», la risposta è questa, non un indice unico condiviso.

Connessioni, SDK e codice dell’applicazione

Le risorse esterne non si configurano nel codice: si dichiarano come connessioni del progetto, e l’applicazione le risolve per nome. Così le credenziali restano fuori dal sorgente e l’ambiente di test punta a un indice diverso senza toccare una riga. Per l’accesso senza chiavi si assegnano alla managed identity del progetto i ruoli Search Index Data Contributor e Search Service Contributor; con una rete virtuale privata l’autenticazione a chiave non è nemmeno supportata, serve la managed identity Microsoft Entra.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import (
    AISearchIndexResource, AzureAISearchTool, AzureAISearchToolResource,
    AzureAISearchQueryType, PromptAgentDefinition,
)
from azure.identity import DefaultAzureCredential

project = AIProjectClient(endpoint=PROJECT_ENDPOINT, credential=DefaultAzureCredential())
connessione = project.connections.get("my-search-connection")

agente = project.agents.create_version(
    agent_name="assistente-policy",
    definition=PromptAgentDefinition(
        model="gpt-4.1-mini",
        instructions=(
            "Rispondi solo con le informazioni restituite dallo strumento di ricerca "
            "e cita sempre la fonte. Se non trovi la risposta, dillo."
        ),
        tools=[AzureAISearchTool(azure_ai_search=AzureAISearchToolResource(indexes=[
            AISearchIndexResource(
                project_connection_id=connessione.id,
                index_name="policy-aziendali",
                query_type=AzureAISearchQueryType.VECTOR_SEMANTIC_HYBRID,
            )
        ]))],
    ),
)

Due accortezze sull’indice: serve almeno un campo di testo recuperabile con il contenuto da citare e un campo con l’URL della fonte, altrimenti le citazioni restano senza link. E le istruzioni devono chiedere esplicitamente la citazione: il grounding tecnico non produce da solo risposte tracciabili.

Da ricordare per l’esame

  • RAG non modifica il modello: costruisce il contesto della singola richiesta. Il fine-tuning insegna uno stile o un formato, non fatti aggiornabili.
  • Quando la risposta è sbagliata, distingui recupero e generazione con gli evaluator: Retrieval e Document Retrieval sul primo stadio, Groundedness e Relevance sul secondo.
  • Il vector store del file search si popola in modo asincrono: attendi lo stato completed, e ricorda la scadenza predefinita di sette giorni per i vector store di conversazione.
  • Con Azure AI Search il query_type predefinito è vector_semantic_hybrid e top_k vale 5; l’ibrido è il compromesso giusto fra codici esatti e riformulazioni.
  • Foundry IQ è la risposta quando servono più sorgenti e permessi per utente: applica ACL, etichette Purview e identità del chiamante.