Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Les vecteurs sont des incorporations à haute dimension qui représentent du texte, des images et d’autres contenus mathématiquement. Recherche Azure AI stocke des vecteurs au niveau du champ, ce qui permet au contenu vectoriel et non-vecteur de coexister dans le même index de recherche.
Un index de recherche devient un index vectoriel lorsque vous définissez des champs vectoriels et une configuration vectorielle. Pour remplir des champs vectoriels, vous pouvez envoyer (push) des incorporations précomputées dans celles-ci ou utiliser la vectorisation intégrée, une fonctionnalité intégrée de recherche d’IA Azure qui génère des incorporations pendant l’indexation.
Au moment de la requête, les champs vectoriels de votre index permettent la recherche de similarité, où le système récupère des documents dont les vecteurs sont les plus similaires à la requête vectorielle. Vous pouvez utiliser la recherche de vecteurs pour la correspondance de similarité seule ou la recherche hybride pour une combinaison de similarité et de correspondance de mots clés.
Cet article décrit les concepts clés de création et de gestion d’un index vectoriel, notamment :
- Modèles de récupération de vecteurs
- Contenu (champs vectoriels et configuration)
- Structure de données physiques
- Opérations de base
Conseil / Astuce
Vous voulez commencer immédiatement ? Consultez Créer un index vectoriel.
Modèles de récupération de vecteurs
Recherche Azure AI prend en charge deux modèles pour la récupération de vecteurs :
Recherche classique. Ce modèle utilise une barre de recherche, une entrée de requête et des résultats rendus. Pendant l’exécution de la requête, le moteur de recherche ou le code de votre application vectorise l’entrée utilisateur. Le moteur de recherche effectue ensuite une recherche vectorielle sur les champs vectoriels de votre index et formule une réponse que vous affichez dans une application cliente.
Dans Azure AI Search, les résultats sont retournés sous la forme d’un ensemble de lignes aplaties, et vous pouvez choisir les champs à inclure dans la réponse. Bien que le moteur de recherche corresponde sur des vecteurs, votre index doit avoir du contenu non lisible par l’homme pour remplir les résultats de la recherche. La recherche classique prend en charge les requêtes vectorielles et les requêtes hybrides.
Recherche générative. Les modèles de langage utilisent des données d’Azure AI Search pour répondre aux requêtes utilisateur. Une couche d’orchestration coordonne généralement les invites et gère le contexte, en alimentant les résultats de la recherche dans des modèles de conversation tels que GPT. Ce modèle est basé sur l’architecture de génération augmentée de récupération (RAG), où l’index de recherche fournit des données de base.
Schéma d’un index vectoriel
Le schéma d’un index vectoriel nécessite les éléments suivants :
- Nom
- Champ clé (chaîne)
- Un ou plusieurs champs vectoriels
- Configuration vectorielle
Les champs non-vecteurs ne sont pas obligatoires, mais nous vous recommandons de les inclure pour les requêtes hybrides ou pour retourner du contenu détaillé qui ne passe pas par un modèle de langage. Pour plus d’informations, consultez Créer un index vectoriel.
Votre schéma d’index doit refléter votre modèle de récupération vectorielle. Cette section traite principalement de la composition de champs pour la recherche classique, mais elle fournit également des instructions de schéma pour la recherche générative.
Configuration de base du champ vectoriel
Les champs vectoriels ont des types de données et des propriétés uniques. Voici à quoi ressemble un champ vectoriel dans une collection de champs :
{
"name": "content_vector",
"type": "Collection(Edm.Single)",
"searchable": true,
"retrievable": true,
"dimensions": 1536,
"vectorSearchProfile": "my-vector-profile"
}
Seuls certains types de données sont pris en charge pour les champs vectoriels. Le type le plus courant est Collection(Edm.Single), mais l'utilisation de types étroits peut réduire l'utilisation de stockage.
Les champs vectoriels doivent être pouvant faire l’objet d’une recherche et être récupérables, mais ils ne peuvent pas être filtrables, facetables ou triables. Ils ne peuvent pas non plus avoir d'analyseurs, de normalisateurs ou d'attributions de cartes de synonymes.
La dimensions propriété doit être définie sur le nombre d’incorporations générées par le modèle d’incorporation. Par exemple, text-embedding-ada-002 génère 1 536 incorporations pour chaque bloc de texte.
Les champs vectoriels sont indexés à l’aide d’algorithmes spécifiés dans un profil de recherche vectorielle, qui est défini ailleurs dans l’index et non indiqué dans cet exemple. Pour plus d’informations, consultez Ajouter une configuration de recherche vectorielle.
Collection de champs pour les charges de travail vectorielles de base
Les index vectoriels nécessitent plus que des champs vectoriels. Par exemple, tous les index doivent avoir un champ clé, qui se trouve id dans l’exemple suivant :
"name": "example-basic-vector-idx",
"fields": [
{ "name": "id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "key": true },
{ "name": "content_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": null },
{ "name": "content", "type": "Edm.String", "searchable": true, "retrievable": true, "analyzer": null },
{ "name": "metadata", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "sortable": true, "facetable": true }
]
D’autres champs, tels que le content champ, fournissent l’équivalent lisible par l’homme du content_vector champ. Si vous utilisez exclusivement des modèles de langage pour la formulation de réponse, vous pouvez omettre les champs de contenu non-vecteur, mais les solutions qui envoie (push) les résultats de recherche directement aux applications clientes doivent avoir du contenu non-vecteur.
Les champs de métadonnées sont utiles pour les filtres, en particulier s’ils incluent des informations d’origine sur le document source. Bien que vous ne puissiez pas filtrer directement sur un champ vectoriel, vous pouvez définir des modes de préfiltre, de post-filtre ou de post-filtre strict (aperçu) pour filtrer avant ou après l'exécution de la requête vectorielle.
Schéma généré par l’Assistant d'importation
Nous vous recommandons l’Assistant Importation de données (nouveau) pour l’évaluation et les tests de preuve de concept. L’assistant génère l’exemple de schéma présenté dans cette section.
L’Assistant segmente votre contenu en documents de recherche plus petits, ce qui bénéficie aux applications RAG qui utilisent des modèles de langage pour formuler des réponses. La segmentation vous permet de rester dans les limites d’entrée des modèles de langage et les limites de jetons du classeur sémantique. Il améliore également la précision de la recherche de similarité en faisant correspondre des requêtes sur des blocs extraits de plusieurs documents parents. Pour plus d’informations, consultez Segmenter les documents volumineux pour les solutions de recherche vectorielle.
Pour chaque document de recherche dans l’exemple suivant, il existe un ID de bloc, un ID parent, un bloc, un titre et un champ vectoriel. L’Assistant :
Remplit les champs
chunk_idetparent_idavec des métadonnées d’objet blob codées en base64 (chemin d’accès).Extrait les champs
chunkettitleà partir du contenu de l'objet blob et du nom de l'objet blob, respectivement.Crée le
vectorchamp en appelant un modèle d’incorporation Azure OpenAI que vous fournissez pour vectoriser lechunkchamp. Seul le champ vectoriel est entièrement généré pendant ce processus.
"name": "example-index-from-import-wizard",
"fields": [
{ "name": "chunk_id", "type": "Edm.String", "key": true, "searchable": true, "filterable": true, "retrievable": true, "sortable": true, "facetable": true, "analyzer": "keyword"},
{ "name": "parent_id", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "sortable": true},
{ "name": "chunk", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true, "sortable": false},
{ "name": "title", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "sortable": false},
{ "name": "vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": "vector-1707768500058-profile"}
]
Schéma pour la recherche générative
Si vous concevez un stockage vectoriel pour les applications RAG et de type conversation, vous pouvez créer deux index :
- Un pour le contenu statique que vous avez indexé et vectorisé.
- Pour les conversations utilisables dans les enchaînements de requêtes.
À des fins d’illustration, cette section utilise l’accélérateur chat-with-your-data-solution pour créer les index chat-index et conversations.
Les champs suivants de chat-index soutiennent les expériences de recherche générative :
"name": "example-index-from-accelerator",
"fields": [
{ "name": "id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true },
{ "name": "content", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
{ "name": "content_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": "my-vector-profile"},
{ "name": "metadata", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
{ "name": "title", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "facetable": true },
{ "name": "source", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true },
{ "name": "chunk", "type": "Edm.Int32", "searchable": false, "filterable": true, "retrievable": true },
{ "name": "offset", "type": "Edm.Int32", "searchable": false, "filterable": true, "retrievable": true }
]
Les champs suivants de conversations prennent en charge l’orchestration et l’historique de conversation :
"fields": [
{ "name": "id", "type": "Edm.String", "key": true, "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": false },
{ "name": "conversation_id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
{ "name": "content", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
{ "name": "content_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": "default-profile" },
{ "name": "metadata", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
{ "name": "type", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
{ "name": "user_id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
{ "name": "sources", "type": "Collection(Edm.String)", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
{ "name": "created_at", "type": "Edm.DateTimeOffset", "searchable": false, "filterable": true, "retrievable": true },
{ "name": "updated_at", "type": "Edm.DateTimeOffset", "searchable": false, "filterable": true, "retrievable": true }
]
La capture d’écran suivante montre les résultats de recherche dans conversationsl’Explorateur de recherche :
Dans notre exemple, le score de recherche est de 1,00, car la recherche n’est pas qualifiée. Plusieurs champs prennent en charge l’orchestration et les enchaînements de requêtes :
-
conversation_ididentifie chaque session de conversation. -
typeindique si le contenu provient de l’utilisateur ou de l’Assistant. -
created_atetupdated_atsuppriment les conversations de l’historique.
Structure et taille physiques
Dans la recherche Azure AI, la structure physique d’un index est en grande partie une implémentation interne. Vous pouvez accéder à son schéma, charger et interroger son contenu, surveiller sa taille et gérer sa capacité. Toutefois, Microsoft gère les structures d’infrastructure et de données physiques stockées avec votre service de recherche.
La taille et la substance d’un index sont déterminées par les points suivants :
Quantité et composition de vos documents.
Les attributs sur des champs individuels. Par exemple, davantage de stockage est nécessaire pour les champs filtrables.
Configuration d’index, y compris la configuration vectorielle qui spécifie la façon dont les structures de navigation interne sont créées. Vous pouvez choisir HNSW ou knN exhaustif pour la recherche de similarité.
Azure AI Search impose des limites sur le stockage vectoriel, ce qui permet de maintenir un système équilibré et stable pour toutes les charges de travail. Pour vous aider à rester dans les limites, l’utilisation des vecteurs est suivie et signalée séparément dans le portail Azure et par programmation via les statistiques de service et d’index.
La capture d’écran suivante montre un service S1 configuré avec une partition et un réplica. Ce service a 24 petits index, chacun avec une moyenne d’un champ vectoriel composé de 1 536 incorporations. La deuxième vignette affiche le quota et l’utilisation des index vectoriels. Étant donné qu’un index vectoriel est une structure de données interne créée pour chaque champ vectoriel, le stockage pour les index vectoriels est toujours une fraction du stockage global utilisé par l’index. Les champs non-vecteurs et d’autres structures de données consomment le reste.
Les limites et estimations d’index vectoriel sont abordées dans un autre article, mais deux points à souligner sont que le stockage maximal dépend de la date de création et du niveau tarifaire de votre service de recherche. Les services de même niveau plus récents ont beaucoup plus de capacité pour les index vectoriels. Pour ces raisons, vous devez :
Vérifiez la date de création de votre service de recherche. S’il a été créé avant le 3 avril 2024, vous pourrez peut-être mettre à niveau votre service pour une plus grande capacité.
Choisissez un niveau évolutif si vous prévoyez des fluctuations dans les exigences de stockage vectoriel. Pour les services de recherche plus anciens, le niveau De base est fixe à une seule partition. Envisagez standard 1 (S1) et plus haut pour une plus grande flexibilité et des performances plus rapides. Vous pouvez également basculer entre les niveaux De base et Standard (S1, S2 et S3).
Opérations de base et interaction
Cette section présente les opérations d’exécution de vecteurs, notamment la connexion et la sécurisation d’un seul index.
Remarque
Il n'existe aucune prise en charge via le portail ou l'API pour déplacer ou copier un index. En règle générale, vous pointez le déploiement de votre application vers un autre service de recherche (en utilisant le même nom d'index) ou vous modifiez le nom pour créer une copie sur votre service de recherche actuel, puis le construisez.
Isolation d’index
Dans Recherche IA Azure, vous utilisez un index à la fois. Toutes les opérations liées à l’index ciblent un seul index. Il n’existe aucun concept d’index associé ou de jointure d’index indépendants pour l’indexation et l’interrogation.
Disponible en continu
Un index est immédiatement disponible pour les requêtes dès que le premier document est indexé, mais il n’est pas entièrement opérationnel tant que tous les documents ne sont pas indexés. En interne, un index est distribué entre les partitions et s’exécute sur des réplicas. L’index physique est géré en interne. Vous gérez l’index logique.
Un index est disponible en continu et ne peut pas être suspendu ou mis hors connexion. Comme il est conçu pour une opération continue, des mises à jour de son contenu et des ajouts à l’index lui-même se produisent en temps réel. Si une demande coïncide avec une mise à jour de document, les requêtes peuvent retourner temporairement des résultats incomplets.
La continuité des requêtes existe pour les opérations de document, telles que l’actualisation ou la suppression, et pour les modifications qui n’affectent pas la structure ou l’intégrité existantes d’un index, telles que l’ajout de nouveaux champs. Les mises à jour structurelles, telles que la modification de champs existants, sont généralement gérées à l’aide d’un flux de travail de suppression et de reconstruction dans un environnement de développement ou en créant une nouvelle version de l’index sur le service de production.
Pour éviter une reconstruction d’index, certains clients qui effectuent de petites modifications versionnent un champ en créant un nouveau champ qui coexiste avec une version précédente. Au fil du temps, cela conduit à du contenu orphelin par le biais de champs obsolètes et de définitions d’analyseur personnalisées obsolètes, en particulier dans un index de production coûteux à répliquer. Vous pouvez résoudre ces problèmes pendant les mises à jour planifiées de l’index dans le cadre de la gestion du cycle de vie des index.
Connexion de point de terminaison
Toutes les demandes d’indexation et de requête vectorielles ciblent un index. Les points de terminaison sont généralement l’un des suivants :
| Point de terminaison | Connexion et contrôle d’accès |
|---|---|
<your-service>.search.windows.net/indexes |
Cible la collection d’index. Utilisé lors de la création, de la liste ou de la suppression d’un index. Les droits d’administrateur sont requis pour ces opérations et disponibles via des clés API d’administration ou un rôle Contributeur de recherche. |
<your-service>.search.windows.net/indexes/<your-index>/docs |
Cible la collection documents d’un index unique. Utilisé lors de l’interrogation d’un index ou de l’actualisation des données. Pour les requêtes, les droits de lecture sont suffisants et disponibles via des clés API de requête ou un rôle de lecteur de données. Pour l’actualisation des données, des droits d’administrateur sont nécessaires. |
Comment se connecter à Recherche Azure AI
Vérifiez que vous disposez des autorisations ou d’une clé d’accès API . Sauf si vous interrogez un index existant, vous avez besoin de droits d’administrateur ou d’une attribution de rôle Contributeur pour gérer et afficher du contenu sur un service de recherche.
Démarrez avec le portail Azure. La personne qui a créé le service de recherche peut l’afficher et la gérer, y compris accorder l’accès à d’autres personnes sur la page contrôle d’accès (IAM).
Passez à d’autres clients pour l’accès par programmation. Pour les premières étapes, nous vous recommandons de démarrer rapidement : recherche vectorielle à l’aide de REST et du référentiel azure-search-vector-samples .
Gérer les magasins vectoriels
Azure fournit une plateforme de monitoring qui inclut la journalisation et les alertes de diagnostic. Nous vous recommandons :
- Activez la journalisation des diagnostics.
- Configurer des alertes.
- Analysez les performances des requêtes et des index.
Accès sécurisé aux données vectorielles
Azure AI Search implémente le chiffrement des données, les connexions privées pour les scénarios sans Internet et les attributions de rôles pour un accès sécurisé via Microsoft Entra ID. Pour plus d’informations sur les fonctionnalités de sécurité d’entreprise, consultez Security in Azure AI Search.