Il modello di embedding decide che cosa «assomiglia» a che cosa: è la funzione che traduce il contenuto in vettori e, di conseguenza, definisce quali chunk verranno considerati vicini a una domanda. Se il vocabolario del dominio è pieno di sigle interne, codici e tassonomie proprietarie, un modello generico può collocare vicini due testi che per l’azienda non c’entrano nulla. Cambiare il modo in cui il contenuto è rappresentato è quindi una leva reale — ma è anche la più costosa da azionare, e l’unica che non ha senso azionare senza una misura prima e dopo.

Scegliere il modello, e sapere cosa costa cambiarlo

La regola non negoziabile è documentata a chiare lettere: bisogna usare lo stesso modello di embedding per indicizzare e per interrogare. Ne discende il vincolo operativo più importante: sostituire il modello significa rigenerare i vettori di tutto il corpus e ricostruire l’indice. Non è un flag di configurazione, è una migrazione, e come tale va pianificata con indice affiancato e confronto prima del passaggio. Vale anche una regola minore ma insidiosa: se una query colpisce più campi vettoriali, tutti quei campi devono contenere embedding prodotti dallo stesso modello.

Nel wizard di creazione dell’indice del portale Microsoft Foundry i modelli supportati per vettorializzare testo semplice sono text-embedding-3-small, text-embedding-3-large, text-embedding-ada-002, Cohere-embed-v3-english e Cohere-embed-v3-multilingual; il modello deve essere già distribuito e serve il permesso per accedervi. I criteri di scelta sono pochi e concreti: la lingua (l’approccio vettoriale trova corrispondenze multilingua senza analizzatori né traduzione), la modalità (testo, immagini, multimodale), il limite di token in input — che detta la dimensione dei chunk — e il costo. Su quest’ultimo la documentazione è esplicita: la ricerca vettoriale è onerosa e soggetta a limiti, quindi conviene vettorializzare solo i campi che portano significato e ridurre la dimensione dei vettori per conservarne di più a parità di spesa. Infine, normalizzare la lunghezza dei vettori migliora accuratezza e prestazioni della ricerca per similarità, anche se la maggior parte dei modelli preaddestrati è già normalizzata; con i modelli di embedding di Azure OpenAI la metrica raccomandata è cosine.

Specializzare il modello sul dominio

Fra i consigli per l’integrazione dei modelli di embedding, la documentazione di Azure AI Search elenca esplicitamente il fine-tuning: se serve, si specializza il modello sui dati di dominio per migliorarne prestazioni e rilevanza rispetto alla propria applicazione di ricerca. In pratica però la prima domanda è se quel modello sia specializzabile: nel catalogo di Microsoft Foundry solo alcuni modelli supportano il fine-tuning e, per quelli, la personalizzazione avviene su managed compute oppure su serverless deployment. Si filtra il catalogo per inference task (per esempio embeddings) e per opzione di deployment, e si legge la scheda del modello prima di promettere qualcosa al business.

La conseguenza più sottovalutata riguarda l’esercizio. Se la strada praticabile è il managed compute, si passa da un endpoint a consumo a GPU dedicate: si dimensionano, si monitorano, si spengono, hanno una quota separata da quella serverless e una fatturazione a ore per SKU. Il modello specializzato diventa un asset con versioni, ambiente di esecuzione e ciclo di vita propri — esattamente come un modello di Azure Machine Learning.

Per questo l’ordine degli interventi conta. Prima si sistemano chunking, ricerca ibrida e semantic ranker, che non richiedono alcun riaddestramento; il modello di embedding specializzato è la risposta giusta quando è dimostrato che è la rappresentazione a fallire, non il ranking. E in ogni caso specializzare l’embedding implica reindicizzare l’intero corpus: va trattato come un rilascio, non come un esperimento in produzione.

Le metriche di rilevanza: due famiglie

Microsoft Foundry divide gli evaluator per RAG in due gruppi, e la distinzione è materiale d’esame. La process evaluation misura il passo di recupero: Retrieval giudica con un LLM quanto i chunk recuperati siano pertinenti alla query e non richiede ground truth (scala da 1 a 5, soglia di passaggio predefinita 3); Document Retrieval richiede invece etichette umane di rilevanza e restituisce metriche di ricerca vere e proprie — fidelity, NDCG, XDCG, max relevance e holes, con output come ndcg@3, xdcg@3, top1_relevance, top3_max_relevance, holes e holes_ratio. Holes conta i documenti privi di giudizio: se è alto, il set di etichette è incompleto e le altre metriche vanno lette con prudenza.

La system evaluation misura la risposta finale: Groundedness guarda la precisione (non contiene contenuto fuori dal contesto fornito), Response Completeness guarda il richiamo rispetto al ground truth, Relevance guarda quanto la risposta indirizzi davvero la domanda. Se il recupero è il collo di bottiglia, document_retrieval è lo strumento indicato per il parameter sweep: si generano i risultati di recupero per diverse combinazioni di algoritmo di ricerca, top_k e dimensione dei chunk, e si sceglie la combinazione con la qualità di recupero più alta.

testing_criteria = [
    {
        "type": "azure_ai_evaluator",
        "name": "document_retrieval",
        "evaluator_name": "builtin.document_retrieval",
        "data_mapping": {
            "retrieval_ground_truth": "{{item.retrieval_ground_truth}}",
            "retrieved_documents": "{{item.retrieved_documents}}",
        },
    },
]

Il confronto A/B fatto bene

La documentazione descrive l’ottimizzazione come una salita a tentoni: si parte da una baseline, si misura ciò che conta, si cambia una leva e si tiene la modifica solo se avvicina il carico ai requisiti. Tradotto in regole: la baseline deve essere la configurazione che serve oggi il traffico; i criteri di accettazione su qualità, costo, latenza e policy si decidono prima di guardare i risultati; la configurazione applicativa resta identica fra le due varianti — stessi prompt, stesse istruzioni di sistema, stessi limiti di output — altrimenti una differenza di configurazione sembrerà un effetto del cambiamento.

Il dataset deve rappresentare il mix reale (casi comuni, casi limite, input lunghi, richieste ad alto impatto) e va raggruppato per categoria, perché un aggregato favorevole può nascondere una regressione su una singola categoria. I punteggi automatici sono stime: i casi ad alto impatto o regolamentati vanno rivisti da persone qualificate, e i campioni piccoli o sbilanciati vanno trattati con cautela. Si cambia una leva alla volta rilanciando lo stesso set di prompt, si registra il contesto di ogni run (baseline, configurazione, dataset, criteri) per renderla riproducibile, e prima dell’adozione si valida con traffico simile a quello di produzione, osservando latenza mediana e di coda, errori e costi effettivi. Il vincitore diventa la nuova baseline e la valutazione si ripete quando cambiano il traffico, l’applicazione o i modelli. In CI questo vive dentro una GitHub Action di valutazione, con il confronto fra run leggibile nel portale Foundry.

Da ricordare per l esame

  • Stesso modello di embedding per indicizzazione e query, e stesso modello su tutti i campi vettoriali colpiti dalla stessa query: cambiarlo impone di rigenerare i vettori e reindicizzare.
  • Retrieval misura il recupero con un LLM giudice senza ground truth; Document Retrieval richiede etichette umane e restituisce fidelity, NDCG, XDCG, max relevance e holes.
  • Groundedness è la precisione della risposta, Response Completeness è il richiamo rispetto al ground truth: sono complementari, non alternative.
  • Solo alcuni modelli del catalogo Microsoft Foundry sono specializzabili, tramite fine-tuning su managed compute o su serverless deployment; il managed compute porta con sé GPU dedicate, quota separata e costo orario.
  • Un confronto A/B valido tiene fissa tutta la configurazione tranne una leva, usa un dataset rappresentativo diviso per categoria e legge insieme qualità, costo e latenza contro criteri decisi in anticipo.