Note de transparence : Recherche Azure AI

L’enrichissement par IA est l’application de modèles Machine Learning de Foundry Tools sur le contenu qui n’est pas facilement accessible dans sa forme brute. Grâce à l’enrichissement, l’analyse et l’inférence sont utilisés pour créer du contenu et une structure pouvant faire l’objet d’une recherche, où aucune n’existait précédemment.

L'enrichissement par IA est une extension facultative du pipeline d'indexeur Recherche Azure AI qui se connecte à Foundry Tools dans la même région que le service de recherche d'un client. Un pipeline d’enrichissement a les mêmes composants principaux qu’un indexeur classique (indexeur, source de données, index), ainsi qu’un jeu de compétences qui spécifie les étapes d’enrichissement atomique. Un ensemble de compétences peut être assemblé à l’aide de compétences intégrées basées sur les API Foundry Tools, telles que Vision et Langage, ou des compétences personnalisées qui exécutent du code externe que vous fournissez.

La recherche vectorielle est une méthode de récupération d’informations où les documents et les requêtes sont représentés dans un index sous forme de vecteurs au lieu de texte brut. Dans la recherche vectorielle, les modèles Machine Learning, hébergés en externe à partir de Recherche Azure AI, génèrent les représentations vectorielles des entrées sources, qui peuvent être du texte, des images, du contenu audio ou vidéo. Cette représentation mathématique et normalisée du contenu, appelée incorporation de vecteurs, fournit une base commune pour les scénarios de recherche.

Lorsque tout est un vecteur, une requête peut trouver une correspondance dans l’espace vectoriel, même si le contenu d’origine associé se trouve dans un type de média différent, comme les images par rapport au texte ou la langue de la requête. Le moteur de recherche analyse l’index qui recherche le contenu vectoriel le plus similaire, c’est-à-dire le plus proche, du vecteur dans la requête. La mise en correspondance sur une représentation vectorielle mathématique au lieu de mots clés permet de trouver des correspondances qui partagent une signification sémantique, mais qui sont textuellement distinctes, telles que « voiture » et « auto », par exemple. Cela donne une introduction plus détaillée aux incorporations vectorielles et au fonctionnement de l’algorithme de similarité.

Termes clés

Le ranker sémantique utilise le contexte ou la signification sémantique d’une requête pour calculer un nouveau score de pertinence qui promeut les résultats qui sont sémantiquement plus proches de l’intention de la requête d’origine vers le haut. Le jeu de résultats initial peut provenir d’une recherche par mot clé avec le classement BM25 , la recherche vectorielle ou une recherche hybride qui inclut les deux. Il crée et retourne également des « légendes » en extrayant le contenu détaillé trouvé dans le résultat et les « surbrillances » pour attirer l’attention sur le contenu important dans le résultat. Elle peut également retourner une « réponse » si la requête a les caractéristiques d’une question (« quel est le point de gel de l’eau ») et que le résultat contient le texte présentant les caractéristiques d’une réponse (« l’eau fige à 0 °C ou 32 °F »).

Termes clés

La réécriture des requêtes crée des requêtes synthétiques, qui sont des requêtes créées ou générées artificiellement à partir d’une entrée client réelle pour améliorer le rappel (fraction des documents pertinents récupérés sur le nombre total de documents disponibles) du classement BM25, de la recherche vectorielle ou d’une recherche hybride. La requête d’origine est combinée aux requêtes synthétiques pour fournir un rappel optimal à partir du moteur de recherche.

La compétence d'invite GenAI fait partie du catalogue de compétences de Recherche Azure AI, ce qui permet aux clients d'améliorer leurs index de recherche avec du contenu généré par l'IA en fonction de leurs données. En utilisant les propres données et préférences de l’organisation du client, cette compétence permet de produire des résumés, des réponses ou des insights personnalisés qui s’alignent sur leurs besoins spécifiques.

Cela signifie que lorsque l’utilisateur final recherche le contenu des clients via la recherche IA, le contenu généré par l’IA peut fournir des résultats plus informatifs et contextuels, ce qui facilite la recherche des informations par les utilisateurs.

Termes clés

La récupération agentique est une architecture de traitement des requêtes parallèle qui utilise un modèle de langage volumineux conversationnel (LLM) en tant que « planificateur de requêtes ». Le LLM transforme l’historique des conversations d’un utilisateur en une ou plusieurs sous-requêtes ciblées, selon les besoins. Ces sous-requêtes s’exécutent simultanément sur votre index Recherche Azure AI, et le service fusionne les résultats principaux, en retournant :

• Chaîne de contenu unique qui contient les passages les plus pertinents (données de base).
• Tableau de références (facultatif) qui expose les documents ou blocs sources complets.
• Tableau d’activités qui répertorie chaque opération, le compte des jetons et la latence pour faciliter le suivi des coûts et le débogage.

Termes clés

Comportement du système

Plusieurs compétences intégrées pour l’enrichissement par IA dans Recherche Azure AI tirent parti des outils Foundry. Pour plus d’informations sur l’utilisation d’une compétence intégrée, consultez les notes de transparence pour chaque compétence intégrée ci-dessous :

• Extraction d’expressions clés : Langage - Extraction d’expressions clés
• Compétence de détection de langue : langue - Détection de langue
• Compétence en liaison d’entités : langue - Liaison d’entités
• Compétence de reconnaissance d’entités : langue - Reconnaissance des entités nommées (NER)
• Compétence de détection d’informations personnelles : langue - Détection d’informations personnelles
• Compétence sentiment : langage - Analyse des sentiments
• Compétence Analyse d’image : Vision - Analyse d’image
• Compétence OCR : Vision - OCR
• Compétence mise en page de document : Document Intelligence

Consultez la documentation de chaque compétence pour en savoir plus sur ses fonctionnalités, limitations, performances, évaluations et méthodes d’intégration et d’utilisation responsable. Notez que l’utilisation de ces fonctionnalités en combinaison peut entraîner des effets cumulatifs (par exemple, les erreurs introduites lors de l’utilisation de l’OCR se répercutent lors de l’utilisation de l’extraction de mots-clés).

Cas d’usage

Exemples de cas d’usage

Étant donné que Recherche Azure AI est une solution de recherche en texte intégral, l’objectif de l’enrichissement par IA est d’améliorer l’utilitaire de recherche de contenu non structuré. Voici quelques exemples de scénarios d’enrichissement de contenu pris en charge par les compétences intégrées :

• La détection de traduction et de langue active la recherche multilingue.
• La reconnaissance d’entité extrait des personnes , des emplacements et d’autres entités à partir de blocs de texte volumineux.
• L’extraction d’expressions clés identifie, puis génère des termes importants.
• OCR reconnaît le texte imprimé et manuscrit dans les fichiers binaires.
• L’analyse d’image décrit le contenu de l’image et génère les descriptions en tant que champs de texte pouvant faire l’objet d’une recherche.
• Vectorisation intégrée est une fonctionnalité d’aperçu qui appelle le modèle d'embeddings Azure OpenAI pour vectoriser les données et stocker des embeddings dans Recherche Azure AI pour la recherche de similarité.

Comportement du système

Dans la recherche vectorielle, le moteur de recherche recherche recherche des vecteurs dans l’espace d’incorporation dans l’index pour rechercher ceux proches du vecteur de requête. Cette technique est appelée recherche voisine la plus proche. Cela permet également de quantifier le degré de similarité, ou la distance, entre les éléments. Un degré élevé de similarité vectorielle indique que les données d’origine étaient également similaires. Les deux algorithmes de recherche vectorielle pris en charge par Recherche Azure AI ont des approches différentes pour ce problème, en échangeant différentes caractéristiques telles que la latence, le débit, le rappel et la mémoire.

La recherche de l’ensemble vrai de « k » voisin le plus proche nécessite de comparer le vecteur d’entrée de manière exhaustive à tous les vecteurs du jeu de données. Bien que chaque calcul de similarité vectorielle soit relativement rapide, l’exécution de ces comparaisons exhaustives sur les jeux de données volumineux est coûteuse et lente en raison du nombre plus élevé de comparaisons requises. En outre, plus la dimensionnalité de chaque vecteur est élevée, plus les calculs sont plus complexes et plus lents seront les calculs sur chaque vecteur.

Pour relever ce défi, les méthodes de recherche de voisinage approximatif (ANN) sont utilisées pour faire un compromis entre le rappel et la vitesse. Ces méthodes peuvent trouver efficacement un petit ensemble de vecteurs candidats susceptibles d’être similaires au vecteur de requête, ce qui réduit le nombre total de comparaisons de vecteurs. Recherche Azure AI utilise l’algorithme HNSW (Hierarchical Navigable Small World) pour organiser des points de données à haute dimension dans une structure hiérarchique hiérarchique probabiliste qui permet une recherche de similarité rapide tout en permettant un compromis entre la précision de la recherche et le coût de calcul.

Recherche Azure AI prend également en charge plusieurs métriques de similarité pour déterminer le voisin le plus proche et le score de chaque résultat vectoriel, notamment cosinus, « Euclidean » (également appelé « norme l2 ») et « produit point ». Cosine calcule l’angle entre deux vecteurs. Euclidean calcule la distance euclide entre deux vecteurs, qui est la norme l2 de la différence des deux vecteurs. Le produit par points est affecté par les grandeurs des vecteurs et l’angle entre eux. Pour les espaces incorporés normalisés, le produit dot équivaut à la similarité cosinus, mais est plus efficace.

Cas d’usage

Exemples de cas d’usage

Il existe de nombreux scénarios où la recherche vectorielle est utile et elles sont limitées uniquement par les fonctionnalités du modèle utilisé pour générer des incorporations vectorielles. Voici quelques cas d’usage généraux où la recherche vectorielle peut être utilisée :

• Semantic search : Extrayez la compréhension sémantique du texte à l’aide de modèles tels que les modèles d'embedding du Azure OpenAI Service.
• Recherchez différents types de données (modal) : encodez du contenu provenant d’images, de texte, d’audio et de vidéo, ou d’une combinaison, et effectuez une recherche unique sur tous ces types.
• Recherche multilingue : utilisez un modèle d’incorporation multilingue pour représenter votre document dans plusieurs langues pour rechercher les résultats dans les langues prises en charge.
• Recherche hybride : la recherche vectorielle est implémentée au niveau du champ, ce qui signifie que vous pouvez créer des requêtes qui incluent des champs vectoriels et des champs de texte pouvant faire l’objet d’une recherche. Les requêtes s’exécutent en parallèle et les résultats sont fusionnés en une seule réponse. Les résultats de la recherche hybride avec classement sémantique ont été montrés pour fournir les meilleurs résultats qualitatifs.
• Recherche vectorielle filtrée : une requête peut inclure une requête vectorielle et une expression de filtre. Les filtres appliqués à d’autres types de données sont utiles pour inclure ou exclure des documents en fonction d’autres critères.
• Base de données vectorielle : ce magasin vectoriel pur est destiné à la mémoire à long terme ou à une base de connaissances externe pour les modèles de langage volumineux (LLMs). Par exemple, utilisez Recherche Azure AI en tant qu’index vectoriel dans le flux d'invite d'Azure Machine Learning pour les applications de génération augmentée par récupération (RAG).

Considérations relatives au choix d’un cas d’usage

Il peut y avoir des considérations et des préoccupations associées au modèle spécifique que vous choisissez pour générer des embeddings vectoriels. Chaque modèle peut avoir ses propres problèmes de biais et d’équité et doit être évalué avant d’être utilisé dans votre application. Recherche Azure AI ne fournit aucun modèle pour vectoriser le contenu dans le cadre du service. Consultez la note de transparence Azure OpenAI Service pour obtenir des exemples de ces considérations. D’autres modèles tiers ou OSS ont des considérations propres à examiner.

Comportement du système

Le classement des résultats de la première étape de récupération de couche est un processus hautement gourmand en ressources. Pour terminer le traitement du ranker dans la latence attendue d’une opération de requête, seuls les 50 premiers résultats du moteur de récupération sont envoyés au ranker sémantique en tant qu’entrées. Si trop long, les 50 résultats sont d’abord envoyés à une étape de synthèse qui extrait le contenu le plus pertinent de chaque résultat avant d’exécuter le ranker sémantique.

Dans l’étape de synthèse, le document récupéré est d’abord mis au travers d’un processus de préparation qui concatène les différentes entrées de document en une seule chaîne longue. Si la chaîne est trop longue, un exercice de découpage a lieu, en mettant l’accent sur la conservation du contenu contenu dans les champs ajoutés à la configuration sémantique. Une fois les chaînes préparées, elles sont transmises par le biais de modèles de compréhension automatique et de représentation linguistique pour déterminer les phrases et expressions qui fournissent le meilleur résumé, par rapport à la requête. Cette phase extrait du contenu depuis la chaîne de caractères qui sera transmise à l’étape de classement sémantique et génère éventuellement une légende sémantique ou une réponse sémantique.

La dernière étape, le classement sémantique, détermine la pertinence du contenu extrait à l’étape précédente de la requête de l’utilisateur et génère un score de classement sémantique allant de 4 (hautement pertinent) à 0 (non pertinent). Cette étape est basée sur le texte de requête et sur le texte résumé et implique des calculs plus complexes que ceux de la couche de récupération.

Cas d’usage

Exemples de cas d’usage

L’éditeur de classement sémantique peut être utilisé dans plusieurs scénarios. Les cas d’usage prévus du système sont les suivants :

• Récupération augmentée par génération (RAG) : le classeur sémantique vous permet d'ancrer les réponses de vos applications d'IA générative dans les résultats de recherche pertinents qui répondent au seuil de score de pertinence que vous définissez. Par exemple, le Azure OpenAI Service sur vos données utilise Recherche Azure AI pour augmenter Azure modèles OpenAI avec vos données. Vous pouvez utiliser le ranker sémantique au sein de ce service pour améliorer la pertinence des informations transmises au modèle OpenAI Azure.
• Recherche de contenu : le ranker sémantique vous permet de rechercher du contenu pertinent dans vos données en analysant du texte et des métadonnées. Par exemple, la recherche sur le site web learn.microsoft.com utilise le classement sémantique pour améliorer la pertinence de la recherche pour les développeurs de logiciels qui recherchent la documentation technique de Microsoft.
• Recherche eCommerce : l’éditeur de classement sémantique permet aux entreprises de commerce électronique d’améliorer leur expérience de recherche en fournissant des résultats de produit pertinents en fonction de la pertinence sémantique. Par exemple, les détaillants en ligne utilisent le ranker sémantique pour optimiser leur expérience eCommerce en fournissant des résultats de recherche pertinents pour leurs acheteurs en ligne.
• QnA : Recherche Azure AI permet aux organisations de fournir une expérience conversationnelle à leurs utilisateurs en répondant aux questions en fonction des informations disponibles dans leurs bases de données. Par exemple, un fabricant peut utiliser le ranker sémantique pour augmenter les informations disponibles pour un chatbot. Les ingénieurs peuvent utiliser ce chatbot pour poser des questions et récupérer des documents internes hautement pertinents liés à leurs requêtes et réponses instantanées dans les documents récupérés.

Considérations relatives au choix d’un cas d’usage

Nous encourageons les clients à utiliser le ranker sémantique dans leurs solutions ou applications innovantes. Toutefois, voici quelques considérations à prendre en compte lors du choix d’un cas d’usage :

• Informations sensibles : les modèles Machine Learning qui permettent au ranker sémantique de traiter les données récupérées dans une requête de recherche, y compris les informations sensibles telles que les détails personnels et les informations financières. Envisagez toutes les implications en matière de confidentialité et de sécurité avant d’implémenter le ranker sémantique pour ces cas d’usage.
• Biais et équité : le ranker sémantique est alimenté par des modèles d’apprentissage profond. Ces modèles d’apprentissage profond ont été formés à l’aide de contenu public. Les données client sont notées par les modèles de classement sémantique. Évaluez le résultat du classeur sémantique lorsque vous sélectionnez des cas d’usage, en particulier pour les cas d’usage qui ont des implications pour la justice et l’équité, telles que l’embauche et le recrutement.
• Conformité de la réglementation : certaines industries, telles que les soins de santé et les finances, sont hautement réglementées et peuvent avoir des restrictions sur l’utilisation de l’IA et du Machine Learning. Avant d’utiliser le ranker sémantique dans ces industries, assurez-vous que la solution est conforme aux réglementations et directives pertinentes.

Comportement du système

La requête d’origine est envoyée à un fine-tuned Small Language Model (SLM) hébergé par Recherche Azure AI. Ce modèle a été entraîné à l’aide du contenu public. Le SLM transforme la requête d’origine en un ensemble de requêtes synthétiques. Ces requêtes synthétiques sont sémantiquement proches de l’intention de la requête d’origine, mais incluent un ensemble différent de termes pour améliorer le rappel à partir du moteur de recherche.

Les requêtes synthétiques sont ensuite combinées avec la requête d’origine et envoyées au moteur de recherche. Lorsqu’il effectue le classement BM25, les termes clés des requêtes synthétiques sont combinés à la requête d’origine. Lorsqu’elle effectue une recherche vectorielle, la requête d’origine est concaténée avec les requêtes synthétiques avant l’étape d’incorporation de vecteur .

Cas d’usage

Exemples de cas d’usage

La réécriture des requêtes peut être utilisée dans plusieurs scénarios. La réécriture des requêtes nécessite l’utilisation de l’éditeur de classement sémantique.

• Interaction de conversation avec vos données : la réécriture des requêtes vous permet de baser les réponses de vos applications IA génératives dans les résultats de recherche pertinents qui répondent au seuil de score de pertinence que vous définissez. Par exemple, le Azure OpenAI Service Sur vos données utilise Recherche Azure AI pour augmenter Azure modèles OpenAI avec vos données. Vous pouvez utiliser la réécriture des requêtes au sein de ce service pour améliorer la pertinence des résultats des informations transmises au modèle OpenAI Azure.
• Questions et réponses conversationnelles (QnA) : Recherche Azure AI permet aux organisations de fournir une expérience conversationnelle à leurs utilisateurs en répondant aux questions à partir des informations disponibles dans leurs bases de données. Par exemple, un fabricant peut utiliser le ranker sémantique pour augmenter les informations disponibles pour un chatbot. Les ingénieurs peuvent utiliser ce chatbot pour poser des questions et récupérer des documents internes hautement pertinents liés à leurs requêtes et réponses instantanées dans les documents récupérés.

Considérations relatives au choix d’un cas d’usage

Nous encourageons les clients à utiliser la réécriture des requêtes dans leurs solutions ou applications innovantes. Toutefois, voici quelques considérations à prendre en compte lors du choix d’un cas d’usage :

• Informations sensibles et informations personnelles : le SLM affiné, qui permet la réécriture des requêtes, traite la requête de recherche, qui peut contenir des informations sensibles. Envisagez toutes les implications en matière de confidentialité et de sécurité avant d’implémenter la réécriture des requêtes pour ces cas d’usage.
• Réactez les informations personnelles afin de réduire les préjugés inconscients. Par exemple, pendant le processus de révision des CV d'une entreprise, ils peuvent vouloir bloquer le nom, l'adresse ou le numéro de téléphone d'un candidat pour aider à réduire les biais inconscients ou d'autres préjugés pendant le processus de sélection.
• Considérations juridiques et réglementaires. Les organisations doivent évaluer des obligations légales et réglementaires spécifiques potentielles lors de l’utilisation d’une recherche IA, ce qui peut ne pas convenir à une utilisation dans chaque secteur ou scénario. Les restrictions peuvent varier en fonction des exigences réglementaires régionales ou locales. En outre, la recherche IA n’est pas conçue pour et peut ne pas être utilisée de manière interdite en termes de service applicable et de codes de conduite pertinents.

La fonctionnalité Invite GenAI permet aux clients de transmettre le contenu de leurs documents existant dans leurs sources de données et des invites personnalisées à un modèle de langage dont ils sont propriétaires, hébergé sur Microsoft Foundry. Le modèle de langage traite l’entrée et retourne du contenu enrichi, qui est ensuite ingéré dans l’index de recherche en même temps que le contenu du document d’origine. Ce processus permet l’augmentation des index de recherche avec des résumés générés par l’IA, des légendes d’images et l’extraction d’entités, entre autres, en fonction de critères définis par le client.

Les exemples suivants montrent comment fonctionne la compétence Invite GenAI.

Résumé du ticket zéro coup

Objectif : Permettre aux agents de support de parcourir les fils de messagerie multipage en quelques secondes.

Fonctionnement :

• Lors de l’indexation, chaque conversation de ticket longue est divisée en segments logiques (requête initiale, questions de suivi, journaux de diagnostic, etc.).
• Pour chaque segment, le modèle de langage est invité à « résumer cette section en trois phrases nettes ».
• Les résumés résultants remplacent le texte brut lors de la récupération afin que les agents ( et les pipelines RAG en aval) ne voient que l’essence distillée.

Pourquoi cela aide : les résumés concis au niveau du segment réduisent la taille des invites, accélèrent la génération de réponse et aident les agents à se concentrer sur le problème principal du client.

Extraction d'entités avec peu d'exemples

Objectif : Les requêtes de support telles que « Afficher tous les tickets où Product X s’est écrasé avec l’erreur 500 ».

Fonctionnement

• Le texte complet du ticket est envoyé à la compétence avec un exemple concret qui montre le format de sortie souhaité (une liste d’entités clés telles que le nom du produit, le code d’erreur, le système d’exploitation et le niveau de gravité).
• Le modèle extrait toutes les occurrences de 〈produit, error_code, plateforme, gravité.
• Cette liste structurée est stockée avec le document, ce qui permet d’activer des filtres instantanés mettant en évidence, par exemple, toutes les pannes de gravité élevée sur iOS.

Pourquoi cela aide : les entités précalculées transforment les messages clients libres en données filtrables, permettant aux responsables du support de repérer les motifs et de prioriser les corrections sans analyse manuelle.

Classification du routage des tickets en une seule étape

Objectif : acheminer automatiquement chaque ticket vers la file d’attente appropriée.

Fonctionnement :

• Chaque ticket est analysé avec une invite qui répertorie cinq catégories de support ( Facturation, Problème technique, Accès au compte, Demande de fonctionnalité et Commentaires généraux), ainsi qu’un exemple de référence (« Exemple de ticket → Facturation »).
• Le modèle affecte exactement une étiquette, en fonction des cinq catégories de prise en charge ci-dessus, à chaque ticket qui entre dans le système de recherche IA comme entrée.
• Le système de support technique utilise l’étiquette pour envoyer des requêtes de facturation à des spécialistes financiers, des incidents techniques aux ingénieurs, et ainsi de suite.

Pourquoi cela aide : l’étiquetage rapide et cohérent réduit les tickets mal routés, raccourcit le temps de résolution et améliore la satisfaction des clients.

Suggestion de résolution en chaîne de pensée

Objectif : Fournir aux agents de support la meilleure étape suivante pour résoudre le problème.

Fonctionnement

• L’intégralité du ticket ( ou son message client le plus récent) est transmis au modèle de langage.
• Le message utilisateur indique au modèle après l’invite système : « Réfléchissez pas à pas en interne, mais ne présentez que l’action suivante recommandée. »
• Les conseils retournés peuvent être : « Demandez au client d’effacer le cache et de réinstaller la version 3.2.1 ».
• Les agents peuvent copier directement la suggestion ou l’affiner avant de répondre.

Pourquoi cela aide : les agents reçoivent une recommandation actionnable sans la chaîne de raisonnement privée du modèle, ce qui permet de gagner du temps tout en conservant les étapes de résolution des problèmes concises et pertinentes. Dans certains cas, l’agent de support n’est pas inondé d’informations inutiles.

Cas d’usage

Exemples de cas d’usage

La compétence GenAI Prompt améliore l’enrichissement des données dans Recherche Azure AI, en contribuant à la pertinence des réponses pour les aligner sur l’intention et les attentes des utilisateurs. En intégrant du contenu généré par l’IA dans les index de recherche, cette compétence permet d’obtenir des résultats de recherche plus précis et contextuels. Les applications clés sont les suivantes :

• Génération de résumés concis de documents longs pour faciliter la récupération plus rapide des informations : un cabinet juridique traite des contrats étendus et utilise la compétence GenAI Prompt pour créer de brefs résumés mettant en évidence les clauses clés, ce qui facilite l’examen des informations essentielles sans lire des documents entiers.
• Création de descriptions textuelles pour les images afin d’améliorer la recherche et l’accessibilité : une société multimédia gère une vaste bibliothèque d’images. En appliquant la compétence Invite GenAI, ils génèrent des légendes descriptives pour chaque image, ce qui permet une recherche efficace et une organisation au sein de leur système de gestion des ressources numériques.
• Identification et extraction d’entités ou de faits spécifiques à partir de documents basés sur des critères personnalisés : une institution de recherche analyse les documents scientifiques pour extraire des mentions de composés chimiques et de leurs propriétés. La fonctionnalité de suggestion GenAI automatise cette extraction, remplissant une base de données structurée pour permettre aux chercheurs d’accéder rapidement aux données pertinentes.
• Classification de documents en catégories définies pour une meilleure organisation et récupération : une compagnie d’assurance reçoit de nombreux types de documents quotidiennement. À l’aide de la compétence Invite GenAI, ils classifient automatiquement ces documents en catégories telles que revendications, mises à jour de stratégie et commentaires des clients. Cela simplifie le processus de gestion des documents et facilite la localisation de documents spécifiques si nécessaire.

Bien qu’il s’agit d’applications courantes, la compétence est flexible, ce qui permet aux clients de définir des invites adaptées à leurs besoins uniques.

Considérations relatives au choix d’un cas d’usage

Il est important de noter que le contenu, les invites et les déploiements de modèles de langage sont des ressources entièrement gérées par le client. Foundry prend en charge les filtres de sécurité du contenu pour les déploiements de modèles, et les clients sont responsables de la configuration de ces filtres si nécessaire. Au-delà des configurations disponibles dans Foundry, Recherche Azure AI n’applique pas de filtres supplémentaires de sécurité de contenu dans la fonctionnalité GenAI Prompt.

Lors de l’implémentation de la compétence de message GenAI, tenez compte des éléments suivants :

• Implémentez des processus pour l’examen humain du contenu généré par l’IA, en particulier lors de l’application de transformations d’invite susceptibles d’avoir un impact sur la fiabilité des informations. Utilisez l'outil de sessions de Recherche Azure AI debug sessions pour tester les invites sur des exemples de documents avant le déploiement à grande échelle.
• Évitez les scénarios où l’utilisation ou l’utilisation abusive du système pourrait entraîner des blessures physiques ou psychologiques importantes à un individu. Par exemple, les scénarios qui diagnostiquent les patients ou prescrivent des médicaments peuvent causer des dommages importants. L’incorporation d’une révision et d’une surveillance humaines significatives dans le scénario peut contribuer à réduire le risque de résultats nocifs.
• Examinez soigneusement tous les cas d’usage génératifs. Les scénarios de génération de contenu peuvent être plus susceptibles de produire des sorties inattendues et ces scénarios nécessitent une considération et des atténuations minutieuses.
• Considérations juridiques et réglementaires. Les organisations doivent évaluer des obligations légales et réglementaires spécifiques potentielles lors de l’utilisation d’une recherche IA, ce qui peut ne pas convenir à une utilisation dans chaque secteur ou scénario. Les restrictions peuvent varier en fonction des exigences réglementaires régionales ou locales. En outre, la recherche IA n’est pas conçue pour et peut ne pas être utilisée de manière interdite en termes de service applicable et de codes de conduite pertinents.

Comportement du système

La requête de conversation ou de recherche d’origine est envoyée au modèle OpenAI appartenant à un client Azure pour exécuter les étapes de planification des requêtes. La planification des requêtes décompose la conversation en une série de sous-requêtes optimisées qui reflètent l’intention sous-jacente de l’utilisateur avec l’orthographe corrigée et les synonymes développés. Recherche Azure AI traite ensuite toutes les sous-requêtes à la fois dans le système de récupération de recherche complet. Les sous-requêtes sont d’abord traitées par une combinaison hybride de recherche de mots clés et de recherche vectorielle. La recherche de mots clés recherche les documents dans l’index de recherche avec des mots clés similaires aux sous-requêtes. La recherche vectorielle recherche des documents dans l’index de recherche qui peuvent avoir des mots clés différents, mais une signification sous-jacente similaire aux sous-requêtes. Les résultats de cette recherche hybride sont ensuite reclassés par le ranker sémantique pour rechercher les documents avec la meilleure correspondance à l’intention de la sous-requête. Le service fusionne et supprime ensuite les doublons des résultats classés, en appliquant des limites de réponse comme la longueur maximale de sortie avant de renvoyer la réponse finale.

Cas d’usage

Exemples de cas d’usage

• Données de base pour les chatbots personnalisés Liez le chatbot aux politiques rh officielles de l’entreprise et au manuel des employés afin que lorsque quelqu’un demande : « Combien de jours de vacances dois-je obtenir ? » le chatbot extrait la réponse directement à partir de ces documents plutôt que de deviner.
• Équipez les assistants de connaissances d’entreprise pour respecter le contexte utilisateur, les filtres et l’historique des conversations. Par exemple, lorsqu’un employé demande les objectifs d’une période spécifique, l’Assistant utilise son rôle, les filtres actuels (par exemple, région : ÉTATS-Unis) et la conversation en cours (par exemple, la dernière rubrique était « Pipeline Q2 ») pour générer une réponse personnalisée.
• Traitez les tâches complexes de recherche d’informations où une requête de mot clé unique a un rappel faible. Ces tâches peuvent inclure des guides de dépannage, des recherches médicales ou des comparaisons de produits. Par exemple, si un technicien recherche simplement « erreur d’appareil » et reçoit des résultats génériques, un récupérateur agentique peut prendre en compte l’ensemble de l’historique des conversations qui peut inclure le modèle d’appareil, la version logicielle, l’historique de maintenance et l’état réseau pour faire apparaître des articles précis et pertinents.
• Assurez-vous une transparence totale sur ce qui a été récupéré, pourquoi et à quel coût. Par exemple, lors de la synthèse des documents réglementaires et des résultats d’audit passés, il est essentiel de connaître les sources exactes (par exemple, « Dépôt SEC à partir du Q2 2023 »), de la logique de sélection (par exemple, « mots clés mis en correspondance : divulgation de risques, dérivés ») et des coûts associés (par exemple, utilisation des jetons).

Considérations relatives au choix d’un cas d’usage

• Latence : l’ajout d’un deuxième appel LLM pour la planification des requêtes étend inévitablement le temps d’aller-retour de la requête. Même avec des modèles rapides, vous devez évaluer le délai supplémentaire en cas de pic de trafic et vérifier que l’expérience globale reste acceptable pour vos utilisateurs. Lorsque la latence est critique, envisagez de mettre en cache des requêtes fréquentes ou d’utiliser des modèles de planification plus petits et plus rapides.
• Coût : les frais s’accumulent sur deux dimensions : jetons de modèle OpenAI et jetons de classement de recherche. L’appel du planificateur de requêtes est facturé par Azure OpenAI pour les jetons d’entrée et de sortie, tandis que chaque sous-requête est facturée par Recherche Azure AI pour les jetons qu’il doit classer. Les jetons de classement sont gratuits dans la phase initiale de l'aperçu public. Estimez à l'avance le nombre de tokens pour le modèle et le classement de votre charge de travail.
• Entrées sensibles : l’ensemble de l’historique des conversations est transféré au modèle planificateur, ce qui signifie que toutes les données personnellement identifiables ou sensibles à l’entreprise quittent votre limite de confiance immédiate. Supprimez, masquez ou réactez ces données avant d’appeler le LLM et documentez cette atténuation dans votre posture de protection des données.
• Limites de région et d’aperçu : la récupération agentique n’est disponible que dans les régions où le ranker sémantique est disponible. Un agent individuel peut pointer vers un seul index de recherche. Vérifiez que la région hébergeant vos données et votre modèle prend en charge la récupération agentique et planifiez des agents distincts si vous devez étendre plusieurs index ou zones géographiques.
• Conformité : Vérifiez que l’utilisation d’un planificateur de requêtes piloté par LLM est conforme aux exigences sectorielles ou régionales (par exemple, résidence des données, confidentialité ou règles de décision automatisée dans les soins de santé ou les finances). Assurer une surveillance et un contrôle humains adéquats. Envisagez d’inclure des contrôles pour aider les développeurs à vérifier, examiner et/ou approuver des actions en temps opportun, ce qui peut inclure l’examen des tâches planifiées ou des appels à des sources de données externes.
• Considérations juridiques et réglementaires : les utilisateurs doivent évaluer des obligations légales et réglementaires spécifiques potentielles lors de l’utilisation d’outils et de solutions foundry, ce qui peut ne pas convenir à une utilisation dans chaque secteur ou scénario. En outre, les outils ou solutions Foundry ne sont pas conçus pour et ne peuvent pas être utilisés de manière interdite en termes de service applicables et les codes de conduite pertinents.

L’enrichissement par IA dans Recherche Azure AI utilise les fonctionnalités d’indexeur et de source de données du service pour appeler Foundry Tools pour effectuer l’enrichissement du contenu. Les limitations des indexeurs et des sources de données utilisées dans ce processus s’appliquent. Pour plus d’informations sur ces limitations connexes, consultez la documentation de l’indexeur et de la source de données. Les limitations de chaque outil Foundry utilisé par le pipeline d’enrichissement par IA dans Recherche Azure AI s’appliquent également. Pour plus d’informations sur ces limitations, consultez les notes de transparence de chaque service .

Limitations techniques, facteurs opérationnels et plages

Tous les vecteurs chargés vers Recherche Azure AI doivent être générés en externe à partir du service à l’aide d’un modèle de votre choix. Il vous incombe de prendre en compte les limitations techniques et les facteurs d’exploitation de chaque modèle, et de déterminer si les incorporations qu’elle crée sont optimisées ou même appropriées pour votre cas d’usage. Cela inclut les inférences de signification extraites du contenu et la dimensionnalité de l’espace d’incorporation de vecteur.

Le modèle de vectorisation crée un espace d’incorporation qui définit l’expérience de recherche des utilisateurs finaux résultante d’une application. Il peut y avoir des inconvénients pour un modèle qui affecte négativement les fonctionnalités et les performances si un modèle ne s’aligne pas correctement avec un cas d’usage souhaité ou que les incorporations générées sont mal optimisées.

Bien que de nombreuses limitations de la recherche vectorielle proviennent du modèle utilisé pour générer des incorporations, vous devez envisager certaines options supplémentaires au moment de la requête. Vous pouvez choisir parmi deux algorithmes pour déterminer la pertinence des résultats de la recherche vectorielle : des voisins k-proches complets (KNN) ou un petit monde navigable hiérarchique. L'algorithme des K plus proches voisins (KNN) effectue une recherche exhaustive par force brute dans l'espace vectoriel pour trouver les correspondances les plus similaires à la requête, en calculant les distances entre toutes les paires de points de données et en détectant les k voisins les plus proches exacts d'un point de requête. Bien que plus précis, cet algorithme peut être lent. Si la faible latence est l’objectif principal, envisagez d’utiliser l’algorithme HNSW (Hierarchical Navigable Small World). HNSW effectue une recherche de voisin approximatif la plus proche (ANN) dans des espaces d'intégration de haute dimension. Pour plus d’informations sur ces options, consultez la documentation de recherche vectorielle .

Meilleures pratiques pour améliorer les performances du système

• Passez du temps à tester votre application avec les différents types de contenu et de requête que vous attendez de la prise en charge de votre application. Déterminez l’expérience de requête qui convient le mieux à vos besoins.
• Passez du temps à tester vos modèles avec une gamme complète de contenu d’entrée pour comprendre comment il se comporte dans de nombreuses situations. Ce contenu peut inclure des entrées potentiellement sensibles pour comprendre s’il existe un biais inhérent au modèle. La vue d’ensemble Azure OpenAI Responsible AI fournit des conseils sur l’utilisation responsable de l’IA.
• Envisagez d’ajouter Azure AI Sécurité du Contenu à votre architecture d’application. Il inclut une API permettant de détecter les textes ou images générés par l’utilisateur et générés par l’IA nocifs dans les applications et les services.

Évaluation et intégration de la recherche de vecteurs pour votre utilisation

Pour garantir des performances optimales, effectuez vos propres évaluations des solutions que vous prévoyez d’implémenter à l’aide de la recherche vectorielle. Suivez un processus d’évaluation qui : (1) utilise certaines parties prenantes internes pour évaluer les résultats, (2) utilise l’expérimentation A/B pour déployer la recherche vectorielle aux utilisateurs, (3) intègre les indicateurs de performance clés (KPI) et la surveillance des métriques lorsque le service est déployé dans des expériences pour la première fois, et (4) teste et (4) ajuste la configuration de l’éditeur sémantique et/ou la définition d’index, y compris les expériences environnantes telles que le placement d’interface utilisateur ou les processus métier.

Microsoft a évalué rigoureusement la recherche vectorielle en termes de latence et de rappel et de pertinence à l’aide de jeux de données variés pour mesurer la vitesse, la scalabilité et la précision des résultats retournés. L’objectif principal de vos efforts d’évaluation doit être de sélectionner le modèle approprié pour votre cas d’usage spécifique, de comprendre les limitations et les biais du modèle, et de tester rigoureusement l’expérience de recherche vectorielle de bout en bout.

Limitations techniques, facteurs opérationnels et plages

Il peut arriver que les résultats sémantiques, les légendes et les réponses ne semblent pas corrects. Les modèles utilisés par le ranker sémantique sont formés sur différentes sources de données (y compris les open source et les sélections du corpus de Microsoft Bing). Le ranker sémantique prend en charge un large éventail de langues et tente de faire correspondre les requêtes utilisateur au contenu de vos résultats de recherche. Le ranker sémantique est une fonctionnalité haut de gamme également offerte à un coût supplémentaire, qui doit être pris en compte lors de l'estimation du coût global de votre solution de bout en bout.

Le classificateur sémantique est plus susceptible d’améliorer la pertinence du contenu sémantiquement riche, tel que les articles et les descriptions. Il recherche le contexte et la relation entre les termes, mettant en avant les correspondances qui ont plus de sens en fonction de la requête. La compréhension du langage « trouve » des résumés ou des légendes et des réponses au sein de votre contenu, mais contrairement aux modèles génératifs tels que Azure OpenAI Service modèles GPT-3.5 ou GPT-4, il ne les crée pas. Seul le texte détaillé des documents sources est inclus dans la réponse, qui peut ensuite être rendu sur une page de résultats de recherche pour une expérience de recherche plus productive.

Les modèles à la pointe de la technologie, préentraînés, sont utilisés pour la synthèse et le classement. Pour maintenir les performances rapides que les utilisateurs attendent de la recherche, la synthèse sémantique et le classement sont appliqués aux 50 premiers résultats, comme indiqué par l’algorithme de scoring par défaut. Les entrées sont dérivées du contenu dans le résultat de la recherche. Il ne peut pas revenir à l’index de recherche pour accéder à d’autres champs du document de recherche qui n’ont pas été retournés dans la réponse de requête. Les entrées sont soumises à une longueur de jeton de 8 960. Ces limites sont nécessaires pour maintenir les temps de réponse en millisecondes.

L’algorithme de scoring par défaut provient de Bing et Microsoft Research et est intégré à l’infrastructure Recherche Azure AI en tant que fonctionnalité d’extension. Les modèles sont utilisés en interne, ne sont pas exposés au développeur et ne sont pas configurables. Pour plus d'informations sur la recherche et les investissements en IA qui soutiennent le classeur sémantique, consultez Comment l'IA de Bing alimente la recherche Azure AI (Blog de Microsoft Research).

Le ranker sémantique offre également des réponses, des légendes et une mise en surbrillance dans la réponse. Par exemple, si le modèle classifie une requête en tant que question et est de 70% confiant dans la réponse, le modèle retourne une réponse sémantique. En outre, les légendes sémantiques fournissent le contenu le plus pertinent dans les résultats et fournissent un bref extrait de code mettant en évidence les mots ou expressions les plus pertinents dans cet extrait de code.

Les résultats du ranker sémantique sont basés sur les données de l’index de recherche sous-jacent, et les modèles fournissent le classement, les réponses et les légendes de pertinence en fonction des informations récupérées à partir de l’index. Avant d’utiliser le ranker sémantique dans un environnement de production, il est important d’effectuer des tests supplémentaires et de s’assurer que le jeu de données est exact et approprié pour le cas d’usage prévu. Pour plus d’informations et des exemples d’évaluation du classement sémantique, consultez le contenu et l’annexe ici.

Performances du système

Dans de nombreux systèmes IA, les performances sont souvent définies par rapport à la précision, c’est-à-dire la fréquence à laquelle le système IA offre une prédiction ou une sortie correctes. Avec des modèles de langage naturel à grande échelle, deux utilisateurs différents peuvent examiner la même sortie et avoir des opinions différentes sur la façon dont il est utile ou pertinent, ce qui signifie que les performances de ces systèmes doivent être définies de manière plus flexible. Ici, nous considérons globalement les performances à savoir que l’application s’exécute comme vous et vos utilisateurs l’attendent, sans générer de sorties dangereuses.

L’éditeur de classement sémantique a été formé sur le contenu public. Par conséquent, la pertinence sémantique varie en fonction des documents de l’index et des requêtes émises sur celui-ci. Il est important d’utiliser votre propre jugement et votre propre recherche lorsque vous utilisez ce contenu pour la prise de décision.

Meilleures pratiques pour améliorer les performances du système

• Passez du temps à tester A/B votre application avec différents types de requêtes, comme les mots-clés par rapport à un classement hybride et sémantique. Déterminez l’expérience de requête qui convient le mieux à vos besoins.
• Effectuez un effort raisonnable pour configurer votre configuration sémantique conformément à la documentation des fonctionnalités.
• Ne faites pas confiance aux réponses sémantiques si vous n’avez pas confiance en la précision des informations dans l’index de recherche.
• N’approuvez pas toujours les légendes sémantiques, car elles sont extraites du contenu client via une série de modèles qui prédit les réponses les plus pertinentes dans un bref extrait de code.

Évaluation du ranker sémantique

Méthodes d’évaluation

Le ranker sémantique a été évalué par le biais de tests internes, y compris le jugement automatisé et humain sur plusieurs jeux de données, ainsi que les commentaires des clients internes. Les tests incluent le classement des documents en les notant comme pertinents ou non pertinents, ainsi que leur classement en fonction de leur pertinence. De même, les légendes et les fonctionnalités de réponses ont également été classées par le biais de tests internes.

Résultats de l’évaluation

Nous nous efforçons d’expédier toutes les mises à jour de modèle sans régression (autrement dit, le modèle mis à jour ne doit améliorer que le modèle de production actuel). Chaque candidat est comparé directement au modèle de production actuel à l’aide de métriques adaptées à la fonctionnalité évaluée (par exemple, Gain cumulatif réduit normalisé pour le classement et la précision/rappel pour les réponses). Les modèles de classement sémantique sont formés, paramétrés et évalués à l’aide d’un large éventail de données d’apprentissage qui représentent des documents qui ont des propriétés différentes (langue, longueur, mise en forme, styles et tonalités) pour prendre en charge le plus large tableau de scénarios de recherche. Nos données d’entraînement et de test sont tirées des points suivants :

Sources de documents :

• Benchmarks universitaires et industriels
• Données client (test uniquement, effectuées avec l’autorisation du client)
• Données synthétiques

Sources de requêtes :

• Jeux de requêtes de benchmark
• Ensembles de requêtes fournis par le client (test uniquement, exécutés avec l’autorisation du client)
• Jeux de requêtes synthétiques
• Jeux de requêtes générés par l’homme

Sources d’étiquettes pour les paires de requêtes et de documents de notation :

• Étiquettes de référence académiques et industrielles
• Étiquettes client (test uniquement, effectuées avec l’autorisation du client)
• Étiquettes de données synthétiques
• Étiquettes notées par des humains

Évaluation et intégration du classeur sémantique pour votre usage

Les performances du ranker sémantique varient en fonction des utilisations et conditions réelles dans lesquelles les utilisateurs l’utilisent. La qualité de la pertinence fournie par le biais des modèles d’apprentissage profond qui alimentent les fonctionnalités de classement sémantique est directement corrélée à la qualité des données de votre index de recherche. Par exemple, les modèles ont actuellement des limitations de jeton qui ne tiennent compte que des 8 960 premiers jetons pour les réponses sémantiques. Par conséquent, si la réponse sémantique à une requête de recherche est trouvée vers la fin d’un document long (au-delà de la limite de 8 960 jetons), la réponse n’est pas fournie. La même règle s’applique aux légendes. En outre, la configuration sémantique répertorie les champs de recherche pertinents dans l’ordre de priorité. Vous pouvez réorganiser les champs de cette liste pour vous aider à adapter la pertinence en fonction de vos besoins.

Pour garantir des performances optimales dans leurs scénarios, les clients doivent effectuer leurs propres évaluations des solutions qu’ils implémentent à l’aide du ranker sémantique. Les clients doivent généralement suivre un processus d’évaluation qui : (1) utilise certaines parties prenantes internes pour évaluer les résultats, (2) utilise l’expérimentation A/B pour déployer le ranker sémantique aux utilisateurs, (3) intègre les indicateurs de performance clés et la surveillance des métriques lorsque le service est déployé dans des expériences pour la première fois, et (4) teste et (4) modifie la configuration du classement sémantique et/ou la définition d’index, y compris les expériences environnantes telles que le placement d’interface utilisateur ou les processus métier.

Si vous développez une application dans un domaine ou une industrie à enjeux élevés, tels que les soins de santé, les ressources humaines, l’éducation ou le domaine juridique, évaluez le fonctionnement de l’application dans votre scénario, implémentez une supervision humaine forte, évaluez comment les utilisateurs comprennent les limitations de l’application et respectent toutes les lois pertinentes. Envisagez d’autres atténuations en fonction de votre scénario.

Limitations techniques, facteurs opérationnels et plages

Il peut y avoir des cas où les requêtes synthétiques sont incorrectes, sont fournies avec trop de restrictions ou sont trop coûteuses. La réécriture des requêtes prend en charge un large éventail de langues et tente de réécrire des requêtes utilisateur pour optimiser le rappel, il est nécessaire de spécifier le langage de requête comme entrée. La réécriture des requêtes fait partie du ranker sémantique (Recherche Azure AI fonctionnalité pour améliorer la pertinence de la recherche), qui est une fonctionnalité Premium avec un coût supplémentaire. Cela doit être pris en compte lorsque vous projetez les dépenses globales de votre solution de bout en bout. La réécriture des requêtes ne peut être utilisée que si vous avez activé le ranker sémantique.

Avant d’utiliser la réécriture des requêtes dans un environnement de production (version dynamique de votre application), il est important d’effectuer des tests supplémentaires et de s’assurer que les requêtes synthétiques sont appropriées pour le cas d’usage prévu. Pour plus d’informations et des exemples d’évaluation de la réécriture des requêtes, consultez le contenu et l’annexe ici.

Performances du système

Avec des modèles de langage naturel à grande échelle, deux utilisateurs différents peuvent examiner la même sortie et avoir des opinions différentes sur la façon dont il est utile ou pertinent, ce qui signifie que les performances de ces systèmes doivent être définies de manière plus flexible. Ici, nous considérons globalement les performances à savoir que l’application s’exécute comme vous et vos utilisateurs l’attendent, sans générer de sorties dangereuses.

Les performances de la réécriture des requêtes varient en fonction des conditions et des utilisations réelles dans lesquelles les utilisateurs l’utilisent. La qualité des requêtes synthétiques fournies par le modèle de réécriture de requête est directement corrélée à la requête de recherche d’origine.

Pour garantir des performances optimales dans leurs scénarios, les clients doivent effectuer leurs propres évaluations des solutions qu’ils implémentent à l’aide de la réécriture des requêtes. Les clients doivent généralement suivre un processus d’évaluation qui :

1. utilise certaines parties prenantes internes pour évaluer les résultats,
2. utilise l’expérimentation A/B pour déployer la réécriture des requêtes pour les utilisateurs et
3. intègre les indicateurs de performance clés et la surveillance des métriques lorsque le service est déployé dans des expériences pour la première fois

Meilleures pratiques pour améliorer les performances du système

• Effectuez des tests A/B pour votre application avec différents types de requêtes (texte intégral, vecteur, hybride ou autre type de requêtes). Déterminez l’expérience de requête qui convient le mieux à vos besoins.
• Ne supposez pas toujours que chaque requête synthétique générée par la réécriture de requête reflète l’intention exacte de la requête d’origine. Les requêtes synthétiques sont générées par une SLM affinée, qui génère des requêtes sémantiquement similaires à l’intention de la requête d’origine, mais peuvent ne pas correspondre à l’intention exacte.

Évaluation de la réécriture des requêtes

Méthodes d’évaluation

La réécriture des requêtes a été évaluée par le biais de tests internes, notamment le jugement automatisé et humain sur plusieurs jeux de données, ainsi que les commentaires des clients internes. Les tests comprenaient l’évaluation de la pertinence des résultats du classement sémantique combiné à la réécriture des requêtes par rapport à la pertinence des résultats avec le classement sémantique uniquement.

Résultats de l’évaluation

Chaque modèle candidat est comparé directement au modèle actuellement déployé à l’aide de métriques adaptées à la fonctionnalité évaluée. Les modèles de réécriture des requêtes sont paramétrés et évalués à l’aide d’un large éventail de données publiques qui sont représentatives des requêtes qui ont des propriétés différentes (langage, longueur, mise en forme, styles et tonalités) pour prendre en charge le plus large éventail de scénarios de recherche. Nos données d’entraînement et de test sont tirées des points suivants :

Sources de documents :

• Benchmarks universitaires et industriels
• Données client (test uniquement, effectuées avec l’autorisation du client)

Sources de requêtes :

• Jeux de requêtes de benchmark
• Ensembles de requêtes fournis par le client (test uniquement, exécutés avec l’autorisation du client)
• Jeux de requêtes synthétiques
• Jeux de requêtes générés par l’homme

Sources d’étiquettes pour les paires de requêtes et de documents de notation :

• Étiquettes de référence académiques et industrielles
• Étiquettes client (test uniquement, effectuées avec l’autorisation du client)
• Étiquettes de données synthétiques
• Étiquettes notées par des humains

Évaluation et intégration de la réécriture des requêtes pour votre utilisation

Comme la réécriture des requêtes a été entraînée sur du contenu public, les requêtes synthétiques varient en fonction des requêtes émises. Il est donc important d’utiliser votre propre jugement et votre propre recherche lorsque vous utilisez ce contenu pour la prise de décision.

Limitations techniques, facteurs opérationnels et plages

Bien que la fonctionnalité de suggestion GenAI offre des capacités puissantes, il est essentiel de reconnaître certaines limitations :

• La compétence s’appuie sur les filtres de contenu configurés par le client dans Foundry. Recherche Azure AI ne fournit pas de mécanismes de sécurité de contenu supplémentaires pour cette compétence.
• La qualité du contenu généré par l’IA dépend de l’efficacité des invites et du modèle de langage sous-jacent. Des tests approfondis sont nécessaires pour garantir que la sortie répond aux normes souhaitées.
• Le traitement de gros volumes de données avec des invites complexes peut nécessiter des ressources de calcul importantes et peut entraîner une latence. Planifiez et allouez des ressources judicieusement pour non seulement maintenir les performances et l’efficacité des coûts, mais également pour éviter les retards possibles dans le traitement des données.

Performances du système

Meilleures pratiques pour améliorer les performances du système

Pour optimiser les performances de la compétence d’invite GenAI :

• Utilisez l'outil debug sessions d'Recherche Azure AI pour tester des requêtes sur des exemples de documents, afin de garantir que le contenu généré par l'IA répond aux attentes avant le déploiement complet.
• Créez des invites claires et détaillées pour guider efficacement le modèle de langage, ce qui réduit la probabilité de sorties non pertinentes ou incorrectes.
• Surveillez les performances du système et ajustez les ressources si nécessaire pour gérer les exigences de calcul du traitement IA.
• Encouragez la surveillance humaine des sorties avant la publication ou la diffusion. Avec l’IA générative, il est possible de générer du contenu susceptible d’être offensant ou non pertinent pour la tâche à portée de main.

Évaluation de la compétence de l'invite GenAI

Évaluation et intégration de la fonctionnalité d'invite GenAI pour votre usage

Pour optimiser les avantages de la compétence d’invite GenAI dans votre contexte spécifique, procédez comme suit :

• Déterminez les objectifs d’enrichissement spécifiques, tels que la génération de résumés concis, l’extraction d’entités clés ou la création de métadonnées descriptives, pour aligner l’application de la compétence avec vos besoins métier.
• Commencez par un sous-ensemble de vos données pour évaluer les performances de la compétence et effectuer les ajustements nécessaires. Cette approche permet de contrôler l’expérimentation et l’affinement avant le déploiement à grande échelle.
• Établissez des mécanismes pour surveiller la qualité et l’impact du contenu généré par l’IA. Demandez des commentaires des utilisateurs finaux afin d’identifier les domaines d’amélioration et de garantir que les données enrichies répondent aux attentes des utilisateurs.

Limitations techniques, facteurs opérationnels et plages

Il peut arriver que les sous-requêtes générées par le LLM ne soient pas pertinentes, trop restrictives, ou qu'elles augmentent les coûts des jetons. La récupération agentique prend en charge toutes les langues gérées par la famille GPT-4o, mais la qualité du plan de requête généré dépend toujours de la clarté de l’entrée utilisateur. Étant donné que la récupération agentique s’appuie sur le ranker sémantique pour chaque sous-requête, vous devez avoir activé le ranker sémantique sur l’index. Le ranker sémantique est une fonctionnalité premium basée sur un jeton ; bien que les frais de classement soient annulés pendant la phase initiale de la préversion publique, ils s’appliqueront ultérieurement et devraient être pris en compte dans le coût total de possession.

Avant de déplacer la récupération agentique dans un environnement de production, effectuez des tests supplémentaires pour vérifier que les sous-requêtes et les passages retournés sont appropriés pour le cas d’usage prévu, que la latence et le coût répondent à vos objectifs de niveau de service et que les données de base n’exposent pas de contenu sensible ou non conforme.

Performances du système

Comme avec n’importe quel système de modèle de langage à grande échelle, différents utilisateurs peuvent atteindre différents jugements sur l’utilité ou la pertinence des passages retournés, de sorte que les performances doivent être définies de manière flexible. Pour la récupération agentique, nous considérons de bonnes performances pour signifier que l’application de bout en bout fournit le contenu attendu par vos utilisateurs, sans latence, coût ou sorties dangereuses inacceptables.

L’efficacité de la récupération agentique dépend de nombreux facteurs réels :

• Longueur de l'invite / de l'historique du chat
• Nombre de sous-requêtes générées par LLM
• Taille et schéma d’index (mot clé, vecteur, hybride)
• Choix du modèle de planification (GPT-4o vs. GPT-4o-mini)
• Configuration de la recherche sémantique et seuils de score

Meilleures pratiques pour améliorer les performances du système

• Résumez ou supprimez les tours de conversation plus anciens pour réduire l’utilisation des jetons.
• Ajuster le seuil du classificateur afin que seuls les passages très pertinents soient retournés
• Utiliser des filtres si possible

Évaluation de la récupération agentique

La récupération agentique a été évaluée par le biais de tests internes, y compris le jugement automatisé et humain sur plusieurs jeux de données. Les tests comprenaient l’évaluation de la pertinence des résultats de la récupération agentique par rapport aux résultats avec le classement sémantique uniquement.

Méthodes d’évaluation

Chaque configuration candidate de récupération agentique, définie par son prompt de planification, sa variante de modèle, son nombre de sous-requêtes et ses seuils de classement, est évaluée en comparaison directe avec la référence de production. Nous appliquons une suite de mesures de pertinence, de sécurité, de latence et de coût choisies spécifiquement pour les scénarios de récupération à plusieurs requêtes. Pour garantir la fiabilité dans les cas d’usage réels, le réglage et les tests sont effectués sur un large éventail de jeux de données publics et approuvés par le client qui varient en langage, longueur de requête, mise en forme, style et tonalité conversationnelle. Le matériau de test est issu des éléments suivants :

Sources de documents :

• Benchmarks universitaires et industriels
• Données client (test uniquement, effectuées avec l’autorisation du client)
• Sources de requêtes :
• Jeux de requêtes de benchmark
• Ensembles de requêtes fournis par le client (test uniquement, exécutés avec l’autorisation du client)
• Jeux de requêtes synthétiques
• Jeux de requêtes générés par l’homme

Sources d’étiquettes pour les paires de requêtes et de documents de notation :

• Étiquettes de référence académiques et industrielles
• Étiquettes client (test uniquement, effectuées avec l’autorisation du client)
• Étiquettes de données synthétiques
• Étiquettes notées par des humains

Évaluation et intégration de la récupération agentique pour votre utilisation

Étant donné que le planificateur de récupération agentique est formé en grande partie sur les données publiques, la qualité et la pertinence de ses sous-requêtes générées varient avec votre domaine et les invites utilisateur spécifiques. Pour optimiser les avantages de la récupération agentique dans votre contexte spécifique, procédez comme suit :

• Validez la sortie avant de l’utiliser pour prendre des décisions critiques pour l’entreprise : inspectez manuellement un exemple de sous-requêtes générées et de documents retournés pour confirmer qu’ils s’alignent sur la terminologie du domaine, la précision et les exigences de conformité.
• Fournissez des informations spécifiques au domaine au planificateur. Fournissez des mappages de synonymes et un historique de conversation complet afin que le LLM puisse paraphrase et décomposer des requêtes en langage qui correspondent à votre contenu, améliorant ainsi le rappel et la précision.
• Implémenter une logique de secours ou de garde-fou : si le planificateur produit des sous-requêtes de faible confiance ou hors portée, routez la requête vers un mot clé ou une recherche vectorielle plus simple, ou faites apparaître une invite de clarification à l’utilisateur, empêchant la propagation des réponses non fiables en aval.