Creare un indice per la ricerca basata su agenti in Azure AI Search

Questo articolo illustra i campi di indice e le configurazioni necessari per il recupero agentico. Nessuno di questi requisiti è nuovo. È possibile usare un indice esistente che soddisfi i criteri, anche se è stato creato con una versione precedente dell'API.

Ogni origine della knowledge base indicizzata dipende da un indice sottostante. A seconda della configurazione della pipeline, l'indice può essere uno dei seguenti:

• Esistente: un indice indipendente esposto tramite una origine dati di conoscenza dell'indice di ricerca. L'indice deve soddisfare i criteri in questo articolo.

• Generato: Un indice creato automaticamente da un'origine conoscitiva indicizzata. Gli indici generati soddisfano tutti i criteri per impostazione predefinita.

Criteri per il recupero agentico

La tabella seguente organizza gli elementi di indice che influiscono sul recupero agentico in base al livello di requisito.

Definizione di indice di esempio

Nell'esempio seguente viene illustrato un indice che funziona per il recupero agentico. Soddisfa i criteri per gli elementi obbligatori e include i campi vettoriali come procedura consigliata.

{
  "name": "earth_at_night",
  "description": "Contains images and descriptions of our planet in darkness as captured from space by Earth-observing satellites and astronauts on the International Space Station over the past 25 years.",
  "fields": [
    {
      "name": "id", "type": "Edm.String",
      "searchable": true, "retrievable": true, "filterable": true, "sortable": true, "facetable": true,
      "key": true,
      "stored": true,
      "synonymMaps": []
    },
    {
      "name": "page_chunk", "type": "Edm.String",
      "searchable": true, "retrievable": true, "filterable": false, "sortable": false, "facetable": false,
      "analyzer": "en.microsoft",
      "stored": true,
      "synonymMaps": []
    },
    {
      "name": "page_chunk_vector_text_3_large", "type": "Collection(Edm.Single)",
      "searchable": true, "retrievable": false, "filterable": false, "sortable": false, "facetable": false,
      "dimensions": 3072,
      "vectorSearchProfile": "hnsw_text_3_large",
      "stored": false,
      "synonymMaps": []
    },
    {
      "name": "page_number", "type": "Edm.Int32",
      "searchable": false, "retrievable": true, "filterable": true, "sortable": true, "facetable": true,
      "stored": true,
      "synonymMaps": []
    },
    {
      "name": "chapter_number", "type": "Edm.Int32",
      "searchable": false, "retrievable": true, "filterable": true, "sortable": true, "facetable": true,
      "stored": true,
      "synonymMaps": []
    }
  ],
  "semantic": {
    "defaultConfiguration": "semantic_config",
    "configurations": [
      {
        "name": "semantic_config",
        "flightingOptIn": false,
        "prioritizedFields": {
          "prioritizedContentFields": [
            {
              "fieldName": "page_chunk"
            }
          ],
          "prioritizedKeywordsFields": []
        }
      }
    ]
  },
  "vectorSearch": {
    "algorithms": [
      {
        "name": "alg",
        "kind": "hnsw",
        "hnswParameters": {
          "metric": "cosine",
          "m": 4,
          "efConstruction": 400,
          "efSearch": 500
        }
      }
    ],
    "profiles": [
      {
        "name": "hnsw_text_3_large",
        "algorithm": "alg",
        "vectorizer": "azure_openai_text_3_large"
      }
    ],
    "vectorizers": [
      {
        "name": "azure_openai_text_3_large",
        "kind": "azureOpenAI",
        "azureOpenAIParameters": {
          "resourceUri": "https://YOUR-AOAI-RESOURCE.openai.azure.com",
          "deploymentId": "text-embedding-3-large",
          "modelName": "text-embedding-3-large"
        }
      }
    ],
    "compressions": []
  }
}

Un indice ben progettato per l'intelligenza artificiale generativa o per la retrieval-augmented generation (RAG) comprende i seguenti componenti:

• Descrizione che un LLM o un agente può utilizzare per determinare se un indice deve essere utilizzato o ignorato.

• Blocchi di testo leggibile che è possibile passare come token di input a un LLM per la formulazione della risposta.

• Una configurazione di classifica semantica perché il recupero agentico utilizza la classificazione semantica di livello 2 (L2) per identificare i blocchi più pertinenti.

• (Facoltativo) Versioni equivalenti a vettori dei blocchi leggibili del testo per la ricerca vettoriale complementare.

Il testo suddiviso in blocchi è importante perché gli LLM elaborano e producono stringhe tokenizzate di contenuti in testo semplice leggibili dall'uomo. Per questo motivo, è consigliabile usare campi searchable che forniscano stringhe di testo semplice e siano retrievable nella risposta. In Azure AI Search è possibile creare testo in blocchi usando soluzioni predefinite o di terze parti.

Un presupposto implicito per il contenuto segmentato è che i documenti di origine originali abbiano grandi quantità di contenuto verboso. Se il contenuto di origine è costituito da dati strutturati, ad esempio un database di prodotti, l'indice deve rinunciare alla suddivisione in blocchi e includere invece campi mappati all'origine dati originale, ad esempio un nome di prodotto, una categoria o una descrizione. L'attribuzione di searchable e retrievable si applica anche ai dati strutturati. searchable rende il contenuto disponibile per le query e retrievable lo aggiunge ai risultati della ricerca (dati di grounding).

Il contenuto vettoriale può essere utile perché aggiunge una ricerca di somiglianza al recupero delle informazioni. In fase di query, quando i campi vettoriali sono presenti nell'indice, il motore di recupero agentico esegue una query vettoriale in parallelo alla query di testo. Poiché le query vettoriali cercano contenuto simile anziché parole corrispondenti, una query vettoriale può trovare un risultato estremamente rilevante che una query di testo potrebbe non riuscire. L'aggiunta di vettori può arricchire e migliorare la qualità dei dati di grounding, ma non è strettamente necessaria. Azure AI Search ha un approccio built-in per la vettorializzazione.

I campi vettoriali vengono usati solo per l'esecuzione di query in Azure AI Search. Non è necessario includere il vettore nei risultati perché non è leggibile né da esseri umani né da sistemi LLM. Per ridurre al minimo i requisiti di spazio, è consigliabile impostare retrievable e stored su false. Per altre informazioni, vedere Ottimizzare l'archiviazione e l'elaborazione dei vettori.

Se si usano vettori, la presenza di un vettore definito nella configurazione di ricerca vettoriale è fondamentale. Determina se il campo vettoriale viene usato durante l'esecuzione della query. Il vettorizzatore codifica le sottoquery di stringa in vettori al momento della query per la ricerca di somiglianza sui vettori. Il vettorizzatore deve essere lo stesso modello di embedding usato per creare i vettori nell'indice.

Per impostazione predefinita, tutti i searchable campi sono inclusi nell'esecuzione della query e tutti i retrievable campi vengono restituiti nei risultati. È possibile scegliere i campi da usare per ogni azione nella definizione dell'indice di ricerca dell'origine della conoscenza.

Aggiungere una descrizione

Un campo di indice description è una stringa definita dall'utente che è possibile usare per fornire indicazioni ai server LLMs e Model Context Protocol (MCP) quando si decide di usare un indice specifico per una query. Questo testo leggibile è prezioso quando un sistema deve accedere a diversi indici e prendere una decisione in base alla descrizione.

Una descrizione dell'indice è un aggiornamento dello schema ed è possibile aggiungerla senza dover ricompilare l'intero indice.

• La lunghezza della stringa è massima di 4.000 caratteri.

• Il contenuto deve essere leggibile, in Unicode. Il caso d'uso deve determinare quale lingua usare (ad esempio, inglese o un'altra lingua).

Aggiungere una configurazione semantica

L'indice deve avere almeno una configurazione semantica. La configurazione semantica deve avere:

• Una configurazione denominata.
• Un prioritizedContentFields impostato su almeno un campo stringa che è sia contemporaneamente searchable e retrievable.

Esistono due modi per specificare una configurazione semantica in base al nome. Se l'indice è defaultSemanticConfiguration impostato su una configurazione denominata, il recupero lo usa. In alternativa, è possibile specificare la configurazione semantica all'interno dell'origine della knowledge base dell'indice di ricerca.

All'interno della configurazione, è necessario prioritizedContentFields. Titolo e parole chiave sono facoltativi. Per il contenuto in blocchi, potresti non avere nessuno dei due. Tuttavia, se si aggiunge il riconoscimento delle entità o l'estrazione di frasi chiave, potrebbero essere associate alcune parole chiave a ogni blocco che può essere utile negli scenari di ricerca, ad esempio in un profilo di assegnazione dei punteggi.

L'esempio seguente illustra una configurazione semantica che funziona per il recupero agentico.

"semantic":{
   "defaultConfiguration":"semantic_config",
   "configurations":[
      {
         "name":"semantic_config",
         "flightingOptIn":false,
         "prioritizedFields":{
            "titleField":{
               "fieldName":""
            },
            "prioritizedContentFields":[
               {
                  "fieldName":"page_chunk"
               }
            ],
            "prioritizedKeywordsFields":[
               {
                  "fieldName":"Category"
               },
               {
                  "fieldName":"Tags"
               },
               {
                  "fieldName":"Location"
               }
            ]
         }
      }
   ]
}

Aggiungere un vettore

Se l'indice contiene campi vettoriali, il piano della query include questi campi se sono searchable e hanno un'assegnazione vectorizer.

Un vectorizer specifica un modello di incorporamento che fornisce conversioni da testo a vettore in fase di query. Deve puntare allo stesso modello di incorporamento usato per codificare il contenuto vettoriale nell'indice. È possibile usare qualsiasi modello di incorporamento supportato da Azure AI Search. È possibile specificare vettorizzatori nei campi vettoriali tramite un profilo vettoriale.

La definizione del campo vettore nell'esempio di indice mostra gli attributi del campo chiave: dimensions, ovvero il numero di incorporamenti generati dal modello e vectorSearchProfile.

  {
    "name": "page_chunk_text_3_large", "type": "Collection(Edm.Single)",
    "searchable": true, "retrievable": false, "filterable": false, "sortable": false, "facetable": false,
    "dimensions": 3072,
    "vectorSearchProfile": "hnsw_text_3_large",
    "stored": false,
    "synonymMaps": []
  }

I profili vettoriali sono configurazioni di vettorizzatori, algoritmi e tecniche di compressione. Ogni campo vettore può usare un solo profilo, ma l'indice può avere molti nel caso in cui si vogliano profili univoci per ogni campo vettore.

Interrogare i vettori e chiamare un vettorizzatore aggiunge latenza alla richiesta complessiva, ma se si desidera una ricerca di similarità, potrebbe valere la pena accettare questo compromesso.

Nell'esempio seguente è mostrato un vettorizzatore che funziona per il recupero agentico, come appare in una configurazione vectorSearch. Non c'è nulla nella definizione del vettorizzatore che deve essere modificato per funzionare con il recupero agenziale.

"vectorSearch": {
  "algorithms": [
    {
      "name": "alg",
      "kind": "hnsw",
      "hnswParameters": {
        "metric": "cosine",
        "m": 4,
        "efConstruction": 400,
        "efSearch": 500
      }
    }
  ],
  "profiles": [
    {
      "name": "hnsw_text_3_large",
      "algorithm": "alg",
      "vectorizer": "azure_openai_text_3_large"
    }
  ],
  "vectorizers": [
    {
      "name": "azure_openai_text_3_large",
      "kind": "azureOpenAI",
      "azureOpenAIParameters": {
        "resourceUri": "https://YOUR-AOAI-RESOURCE.openai.azure.com",
        "deploymentId": "text-embedding-3-large",
        "modelName": "text-embedding-3-large"
      }
    }
  ],
  "compressions": []
}

Aggiungere un profilo di assegnazione dei punteggi

I profili di punteggio sono criteri per l'aumento della pertinenza. Vengono applicati a campi non vettoriali (testo e numeri) e vengono valutati durante l'esecuzione della query, anche se il comportamento preciso dipende dalla versione dell'API usata per creare l'indice.

È più probabile che un profilo di punteggio aggiunga valore alla soluzione se l'indice si basa su dati strutturati. I dati strutturati vengono indicizzati in più campi discreti, il che significa che il profilo di punteggio può avere criteri destinati al contenuto o alle caratteristiche di un campo specifico.

Se si crea l'indice usando 2025-05-01-preview o versione successiva, il profilo di assegnazione dei punteggi viene eseguito per ultimo. Se l'indice viene creato usando una versione precedente dell'API, i profili di punteggio vengono valutati prima del riordinamento semantico. L'ordine effettivo dei risultati classificati semanticamente è determinato dalla proprietà rankingOrder nell'indice, che è impostata su boostedRerankerScore (è stato applicato un profilo di punteggio) o rerankerScore (nessun profilo di punteggio).

È possibile usare qualsiasi profilo di punteggio appropriato per l'indice. L'esempio seguente mostra un profilo di scoring che incrementa il punteggio di ricerca di una corrispondenza se questa viene trovata in un campo specifico. I campi vengono ponderati utilizzando moltiplicatori di potenziamento. Ad esempio, se viene trovata una corrispondenza nel campo "Categoria", il punteggio incrementato viene moltiplicato per 5.

"scoringProfiles": [
    {
      "name": "boostSearchTerms",
      "text": {
        "weights": {
          "Location": 2,
          "Category": 5
        }
      }
    }
]

Aggiungere un analizzatore

Gli analizzatori si applicano ai campi di testo e possono essere analizzatori del linguaggio o analizzatori personalizzati che controllano la tokenizzazione nell'indice, ad esempio mantenendo caratteri speciali o spazi vuoti.

Gli analizzatori vengono definiti all'interno di un indice di ricerca e assegnati ai campi. L'esempio di collezione di campi include un riferimento a un analizzatore nei blocchi di testo. In questo esempio, l'analizzatore predefinito (standard Lucene) viene sostituito con un analizzatore della lingua Microsoft per la lingua inglese.

{
  "name": "page_chunk", "type": "Edm.String",
  "searchable": true, "retrievable": true, "filterable": false, "sortable": false, "facetable": false,
  "analyzer": "en.microsoft",
  "stored": true,
  "synonymMaps": []
}

Aggiungere una mappa di sinonimi

Le mappe sinonimiche espandono le query aggiungendo sinonimi per termini denominati. Ad esempio, si potrebbero avere termini scientifici o medici per termini comuni.

Le mappe sinonimie sono definite come una risorsa di primo livello in un indice di ricerca e assegnate ai campi. L'esempio di raccolta campi non include una mappa sinonimica, ma l'esempio seguente mostra come una mappa sinonimica con ortografia varianti dei nomi di paese/area geografica potrebbe essere assegnata a un campo ipotetico "locations".

{
    "name":"locations",
    "type":"Edm.String",
    "searchable":true,
    "synonymMaps":[ "country-region-synonyms" ]
}

Aggiungere l'indice a una fonte di conoscenza

Se si dispone già di un indice autonomo esistente che non è generato da un'origine dati di conoscenza, creare i seguenti oggetti:

• Una sorgente di conoscenza indice di ricerca per incapsulare il contenuto indicizzato.
• Una base di conoscenza che rappresenta una o più fonti di conoscenza e altre istruzioni per il recupero agentico.

Contenuto correlato

• Recupero agentico in Azure AI Search
• Agentic RAG: Creare un motore di recupero di ragionamento con Azure AI Search (video di YouTube)
• Demo Azure OpenAI con recupero agentico