Créer un index pour la récupération agentique dans Recherche Azure AI

Cet article explique les champs et configurations d’index requis pour la récupération agentique. Aucune de ces exigences n’est nouvelle. Vous pouvez utiliser un index existant qui répond aux critères, même s’il a été créé avec une version antérieure de l’API.

Chaque source de connaissances indexée dépend d’un index sous-jacent. Selon la façon dont vous configurez votre pipeline, l’index peut être l’un des éléments suivants :

• Existant : Un index autonome accessible via une source de connaissances pour l’index de recherche. L’index doit répondre aux critères de cet article.

• Generated: Index créé automatiquement par une source de connaissances indexée. Les index générés répondent à tous les critères par défaut.

Critères de récupération de données par agents

Le tableau suivant organise les éléments d’index qui affectent la récupération agentique par niveau de spécification.

Exemple de définition d’index

L’exemple suivant montre un index qui fonctionne pour la récupération agentique. Il répond aux critères des éléments requis et inclut les champs vectoriels comme meilleure pratique.

{
  "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 index bien conçu pour l’IA générative ou la génération augmentée de récupération (RAG) a les composants suivants :

• Description qu’un LLM ou un agent peut utiliser pour déterminer si un index doit être utilisé ou ignoré.

• Segments de texte lisible par l’homme que vous pouvez transmettre en tant que jetons d’entrée à un LLM pour la formulation de réponses.

• Une configuration de classement sémantique, car la récupération agentique utilise le classement sémantique de niveau 2 (L2) pour identifier les blocs les plus pertinents.

• (Facultatif) Versions équivalentes aux vecteurs des blocs de texte lisibles par l’homme pour la recherche vectorielle complémentaire.

Le texte en bloc est important, car les modules LLM consomment et émettent des chaînes tokenisées de contenu en texte brut lisible par l’homme. Pour cette raison, vous souhaitez des searchable champs qui fournissent des chaînes de texte brut et qui se trouvent retrievable dans la réponse. Dans Recherche Azure AI, vous pouvez créer du texte segmenté à l’aide de solutions intégrées ou tierces.

Une hypothèse intégrée pour le contenu fragmenté est que les documents sources d’origine contiennent de grandes quantités de contenu verbeux. Si votre contenu source est des données structurées, telles qu’une base de données de produit, votre index doit renoncer à la segmentation et inclure plutôt des champs mappés à la source de données d’origine, comme un nom de produit, une catégorie ou une description. L’attribution de searchable et de retrievable s’applique également aux données structurées. searchable rend le contenu pris en compte pour les requêtes, et retrievable l’ajoute aux résultats de recherche (données d’ancrage).

Le contenu vectoriel peut être utile, car il ajoute une recherche de similarité à la récupération des informations. Au moment de la requête, lorsque les champs vectoriels sont présents dans l’index, le moteur de récupération agentique exécute une requête vectorielle en parallèle à la requête de texte. Étant donné que les requêtes vectorielles recherchent du contenu similaire plutôt que des mots correspondants, une requête vectorielle peut trouver un résultat très pertinent qu’une requête de texte peut manquer. L’ajout de vecteurs peut enrichir et améliorer la qualité de vos données d’ancrage, mais n’est pas strictement nécessaire. Recherche Azure AI a une approche intégrée pour la vectorisation.

Les champs vectoriels sont utilisés uniquement pour l’exécution des requêtes sur Recherche Azure AI. Vous n’avez pas besoin du vecteur dans les résultats, car il n’est lisible ni par un humain ni par un LLM. Pour réduire les besoins en espace, nous vous recommandons de définir retrievable et stored à false. Pour plus d’informations, consultez Optimiser le stockage et le traitement vectoriels.

Si vous utilisez des vecteurs, l’utilisation d’un vectoriseur défini dans la configuration de recherche vectorielle est essentielle. Elle détermine si votre champ vectoriel est utilisé pendant l’exécution de la requête. Le vectoriseur encode les sous-requêtes de chaîne en vecteurs au moment de la requête pour la recherche de similarité sur les vecteurs. Le vectoriseur doit être le même modèle d’incorporation que celui utilisé pour créer les vecteurs dans l’index.

Par défaut, tous les searchable champs sont inclus dans l’exécution de la requête et tous les champs sont retournés dans les retrievable résultats. Vous pouvez choisir les champs à utiliser pour chaque action dans la définition de la source de connaissances de l’index de recherche.

Ajouter une description

Un champ d’index description est une chaîne définie par l’utilisateur que vous pouvez utiliser pour fournir des conseils aux serveurs LLMs et MCP (Model Context Protocol) lors de la décision d’utiliser un index spécifique pour une requête. Ce texte lisible par l’homme est inestimable lorsqu’un système doit accéder à plusieurs index et prendre une décision en fonction de la description.

Une description d’index est une mise à jour de schéma et vous pouvez l’ajouter sans avoir à reconstruire l’index entier.

• La longueur de chaîne est de 4 000 caractères maximum.

• Le contenu doit être lisible par l’homme, en Unicode. Votre cas d’usage doit déterminer la langue à utiliser (par exemple, l’anglais ou une autre langue).

Ajouter une configuration sémantique

L’index doit avoir au moins une configuration sémantique. La configuration sémantique doit avoir :

• Configuration nommée.
• Un ensemble prioritizedContentFields défini avec au moins un champ chaîne de caractères qui est à la fois searchable et retrievable.

Il existe deux façons de spécifier une configuration sémantique par nom. Si l’index est défini avec defaultSemanticConfiguration sur une configuration nommée, la récupération l’utilise. Vous pouvez également spécifier la configuration sémantique à l’intérieur de la source de connaissances de l’index de recherche.

Dans cette configuration, prioritizedContentFields est requis. Le titre et les mots clés sont facultatifs. Pour le contenu segmenté, vous n’avez peut-être pas non plus. Toutefois, si vous ajoutez une reconnaissance d’entité ou une extraction d’expressions clés, vous pouvez avoir des mots clés associés à chaque segment pouvant être utiles dans les scénarios de recherche, peut-être dans un profil de scoring.

L’exemple suivant montre une configuration sémantique qui fonctionne pour la récupération agentique.

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

Ajouter un vectoriseur

Si votre index contient des champs vectoriels, le plan de requête inclut ces champs s’ils sont searchable et ont une vectorizer affectation.

Un vectoriseur spécifie un modèle d’incorporation qui fournit des conversions de texte à vecteur au moment de la requête. Il doit pointer vers le même modèle d’incorporation utilisé pour encoder le contenu vectoriel dans votre index. Vous pouvez utiliser n’importe quel modèle d’incorporation pris en charge par Recherche Azure AI. Vous spécifiez des vectoriseurs sur des champs vectoriels par le biais d’un profil vectoriel.

La définition du champ vectoriel dans l’exemple d’index montre les attributs de champ clé : dimensions, qui est le nombre d’incorporations générées par le modèle et 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": []
  }

Les profils vectoriels sont des configurations de vectoriseurs, d’algorithmes et de techniques de compression. Chaque champ vectoriel ne peut utiliser qu’un seul profil, mais votre index peut avoir plusieurs profils uniques pour chaque champ vectoriel.

L’interrogation de vecteurs et l’appel d’un vectoriseur ajoute une latence à la requête globale, mais si vous souhaitez effectuer une recherche de similarité, il peut être utile d’effectuer un compromis.

L’exemple suivant montre un vectoriseur qui fonctionne pour la récupération agentique, tel qu’il apparaît dans une configuration vectorSearch. Il n’y a rien dans la définition de vectoriseur qui doit être modifiée pour fonctionner avec la récupération agentique.

"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": []
}

Ajouter un profil de scoring

Les profils de scoring sont des critères pour l’amélioration de la pertinence. Ils sont appliqués aux champs non vectoriels (texte et nombres) et sont évalués pendant l’exécution de la requête, bien que le comportement précis dépend de la version de l’API utilisée pour créer l’index.

Un profil de scoring est plus susceptible d’ajouter de la valeur à votre solution si votre index est basé sur des données structurées. Les données structurées sont indexées dans plusieurs champs discrets, ce qui signifie que votre profil de scoring peut avoir des critères qui ciblent le contenu ou les caractéristiques d’un champ spécifique.

Si vous créez l’index à l’aide de 2025-05-01-preview ou version ultérieure, le profil de scoring s’exécute en dernier. Si l’index est créé à l’aide d’une version antérieure de l’API, les profils de scoring sont évalués avant la reclassement sémantique. L’ordre réel des résultats classés sémantiquement est déterminé par la propriété rankingOrder dans l’index, qui est soit défini avec boostedRerankerScore (un *scoring profile* a été appliqué) ou rerankerScore (aucun *scoring profile*).

Vous pouvez utiliser n’importe quel profil de scoring qui est logique pour votre index. L’exemple suivant montre un profil de notation qui augmente le score de recherche d’un résultat si celui-ci est trouvé dans un champ spécifique. Les champs sont pondérés à l’aide de multiplicateurs de pondération. Par exemple, si une correspondance est trouvée dans le champ « Catégorie », le score pondéré est multiplié par 5.

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

Ajouter un analyseur

Les analyseurs s’appliquent aux champs de texte et peuvent être des analyseurs linguistiques ou des analyseurs personnalisés qui contrôlent la jetonisation dans l’index, tels que la conservation de caractères spéciaux ou d’espaces blancs.

Les analyseurs sont définis dans un index de recherche et affectés aux champs. L’exemple de collection fields inclut une référence à un analyseur sur les segments de texte. Dans cet exemple, l’analyseur par défaut (Lucene standard) est remplacé par un analyseur de langue Microsoft pour la langue anglaise.

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

Ajouter une carte de synonymes

Les mappages de synonymes développent des requêtes en ajoutant des synonymes pour les termes nommés. Par exemple, vous pouvez avoir des termes scientifiques ou médicaux pour des termes communs.

Les cartes de synonymes sont définies comme une ressource de niveau supérieur sur un index de recherche et attribuées aux champs. L’exemple de collection de champs n’inclut pas de carte de synonymes, mais l’exemple suivant montre comment une carte de synonymes avec des orthographes variant de noms de pays/régions peut être affectée à un champ hypothétique « emplacements ».

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

Ajouter votre index à une source de connaissances

Si vous disposez d’un index autonome qui existe déjà et n’est pas généré par une source de connaissances, créez les objets suivants :

• Source de connaissances de l’index de recherche pour encapsuler votre contenu indexé.
• Base de connaissances qui représente une ou plusieurs sources de connaissances et d’autres instructions pour la récupération agentique.

Contenu connexe

• Recherche agentique dans Recherche Azure AI
• Agentic RAG : Créer un moteur de récupération de raisonnement avec Recherche Azure AI (vidéo YouTube)
• Azure démonstration OpenAI avec récupération agentique