concepts de l’agent de données Fabric

L’agent de données dans Microsoft Fabric est une fonctionnalité généralement disponible qui vous permet de créer votre propre système conversationnel de questions-réponses à l’aide de l’IA générative. Un agent de données Fabric rend les aperçus de données plus accessibles et exploitables pour tous les membres de votre organisation. En utilisant un agent de données Fabric, votre équipe peut avoir des conversations, avec des questions en langue anglaise simple, sur les données stockées dans Fabric OneLake, puis recevoir des réponses pertinentes. De cette façon, même les personnes sans expertise technique en IA ou sans compréhension approfondie de la structure des données peuvent recevoir des réponses précises et riches en contexte. Dans des architectures d’application agentiques plus larges sur Microsoft Fabric, les agents de données servent de composant d’analytique conversationnelle, se connectant à des données régies dans OneLake par le biais de lakehouses, d’entrepôts, de modèles sémantiques et de bases de données KQL dans des solutions multi-agents.

Vous pouvez également ajouter des instructions, des exemples et des conseils spécifiques à l’organisation pour affiner l’agent de données Fabric. Cette approche garantit que les réponses s’alignent sur les besoins et les objectifs de votre organisation, ce qui permet à tout le monde d’interagir plus efficacement avec les données. Fabric agent de données favorise une culture de la prise de décision pilotée par les données, car il réduit les obstacles à l’accessibilité des insights, facilite la collaboration et aide votre organisation à extraire plus de valeur de ses données.

Conditions préalables

• Une capacité de Fabric payante F2 ou supérieure, ou une capacité Power BI Premium par capacité (P1 ou supérieur) avec Microsoft Fabric activé.
• Paramètres de locataire de l’agent de données Fabric est activé, y compris le paramètre Les capacités peuvent être désignées comme capacités Fabric Copilot.
• Le traitement intergéographique pour l’IA est activé.
• Le stockage multi-régional pour l’IA est activé.
• Au moins l'un de ces éléments, avec des données : un entrepôt, un lakehouse, un ou plusieurs modèles sémantiques Power BI, une base de données KQL ou une ontologie.
• Modèles sémantiques Power BI via changement de locataire des points de terminaison XMLA est activé pour les sources de données de modèles sémantiques Power BI.
• Pour Power BI modèles sémantiques utilisés avec un agent de données, assurez-vous que les utilisateurs qui interagissent via l’agent disposent d’une autorisation de lecture sur le modèle sémantique. L’autorisation Membre ou Build de l’espace de travail n’est pas requise pour l’interaction.

Conditions préalables à la gouvernance

Si votre locataire ou espace de travail est régi par des stratégies Microsoft Purview, les agents doivent fonctionner dans ces stratégies. Les stratégies Purview suivantes peuvent limiter l’accès des agents et les résultats retournés par les agents, en fonction de la configuration de la sensibilité et de la stratégie:

• Les stratégies DLP Purview dans Fabric Data Warehouse (généralement disponibles) : les stratégies DLP peuvent détecter et restreindre l’accès aux données sensibles dans les actifs d’entrepôt que l’agent interroge.
• Stratégies de restriction d'accès (préversion) pour la base de données Fabric KQL, la base de données Fabric SQL et l'entrepôt de données Fabric : ces politiques peuvent empêcher l’agent d’accéder ou de retourner des résultats des ressources classées comme sensibles.

Fonctionnement de l’agent de données Fabric

L’agent de données Fabric utilise des modèles de langage volumineux (LLMs) pour aider les utilisateurs à interagir naturellement avec leurs données. L’agent de données Fabric utilise les API Azure OpenAI Assistant et se comporte comme un agent. Il traite les questions utilisateur, détermine la source de données la plus pertinente (Lakehouse, Warehouse, Power BI jeu de données, bases de données KQL, ontologie ou Microsoft Graph) et appelle l’outil approprié pour générer, valider et exécuter des requêtes. Les utilisateurs peuvent ensuite poser des questions en langage brut et recevoir des réponses structurées et lisibles par l’homme. Cette approche élimine la nécessité d’écrire des requêtes complexes et garantit un accès précis et sécurisé aux données.

Voici comment cela fonctionne en détail :

Analyse et validation des questions : l’agent de données Fabric utilise les API d'Azure OpenAI Assistant comme agent sous-jacent pour traiter les questions des utilisateurs. Cette approche garantit que la question est conforme aux protocoles de sécurité, aux stratégies d’IA responsable et aux autorisations utilisateur. L’agent de données Fabric respecte également les contrôles de gouvernance Microsoft Purview appliqués aux sources de données Fabric sous-jacentes, notamment la protection contre la perte de données (DLP) et les stratégies de restriction d’accès. L’application de la stratégie peut empêcher certaines requêtes de s'exécuter ou de présenter des données spécifiques dans les réponses. L’agent de données Fabric applique strictement l’accès en lecture seule, en conservant les connexions de données en lecture seule à toutes les sources de données.

Mécanismes de mise en application : l’agent de données Fabric applique plusieurs couches de protection pendant le traitement. Il utilise les informations d’identification et les autorisations de l’utilisateur demandeur pour appliquer le principe du moindre privilège, ce qui garantit que chaque interaction n'accède qu'aux données que l’utilisateur est autorisé à afficher. L’agent évalue les demandes par rapport aux paramètres de stratégie de locataire et d’espace de travail avant d’exécuter une action. Les garde-fous limitent l’appel et les sorties des outils aux sources de données délimitées, ce qui empêche les requêtes d’atteindre des ressources en dehors de l’étendue configurée. Vous pouvez éventuellement intégrer Azure AI Sécurité du Contenu pour appliquer des contrôles de risque de contenu qui permettent de réduire les réponses dangereuses ou hors stratégie.

Identification de la source de données : l'agent de données Fabric utilise les informations d'identification de l'utilisateur pour accéder au schéma de la source de données. Cette approche garantit que le système extrait les informations de structure de données que l’utilisateur a l’autorisation d’afficher. L'agent évalue ensuite la question de l'utilisateur sur toutes les sources de données disponibles, notamment les bases de données relationnelles (Lakehouse et Warehouse), les jeux de données Power BI (modèles sémantiques), les bases de données KQL, les ontologies et les Microsoft Graph. Il peut également faire référence aux instructions de l’assistant de données fournies par l’utilisateur pour déterminer la source de données la plus pertinente. Pour les modèles sémantiques Power BI, l'agent utilise l'autorisation de lecture de l'utilisateur sur le modèle pour récupérer le schéma et les métadonnées pour la génération de requêtes ; l'autorisation de création n'est pas requise pour les requêtes pilotées par l'agent.

Tool invocation et génération de requêtes : une fois que la source de données ou les sources correctes sont identifiées, l’agent de données Fabric rééquipe la question pour la clarté et la structure, puis appelle l’outil correspondant pour générer une requête structurée :

• Langage naturel vers SQL (NL2SQL) pour les bases de données relationnelles (lakehouse/entrepôt).
• Langage naturel vers DAX (NL2DAX) pour les jeux de données Power BI (modèles sémantiques).
• Langage naturel en KQL (NL2KQL) pour les bases de données KQL. NL2KQL peut utiliser des fonctions définies par l’utilisateur (UDF) KQL lorsqu’elles sont disponibles dans les bases de données sélectionnées.
• Microsoft Graph interroge les données de l'organisation accessibles via Microsoft Graph.

L’outil sélectionné génère une requête basée sur le schéma, les métadonnées et le contexte fournis, que l’agent de données Fabric sous-jacent passe ensuite.

Validation de la requête : l’outil effectue la validation pour vous assurer que la requête est correctement formée et respecte ses propres protocoles de sécurité et stratégies RAI.

Exécution et réponse de la requête : une fois validé, l’agent de données Fabric exécute la requête sur la source de données choisie. Les résultats sont mis en forme dans une réponse lisible par les utilisateurs, qui peut inclure des données structurées telles que des tables, des résumés ou des insights clés.

Grâce à cette approche, les utilisateurs peuvent interagir avec leurs données à l’aide du langage naturel. L’agent de données Fabric gère les complexités de la génération, de la validation et de l’exécution des requêtes. Les utilisateurs n’ont pas besoin d’écrire SQL, DAX ou KQL eux-mêmes.

Sécurité et gouvernance avec Microsoft Purview

Microsoft Purview fournit des contrôles de gouvernance et de risque pour les agents de données Fabric. Ces fonctionnalités sont actuellement en préversion et aident les organisations à maintenir la conformité lors de l’utilisation d’agents pour accéder aux données Fabric. Les fonctionnalités clés sont les suivantes :

• Découverte des risques et audit : les invites et les réponses des agents de données Fabric peuvent être soumises à la découverte des risques et à l’audit par Purview, permettant aux équipes de sécurité de mieux comprendre comment les agents interagissent avec les données de l'organisation.
• Évaluations des risques de données DSPM : les évaluations des risques de données DSPM (Data Security Posture Management) peuvent exposer des risques de données sensibles dans les sources de données utilisées par les agents, ce qui vous aide à identifier et à résoudre l’exposition potentielle.
• Gestion des risques internes : Purview Insider Risk Management peut détecter des modèles d’utilisation de l’IA risqués impliquant des agents, tels que des volumes de requêtes inhabituels ou l’accès aux données sensibles.
• Audit, eDiscovery et rétention : Purview Audit, eDiscovery et politiques de rétention s’appliquent aux interactions et sorties de l’agent dans les charges de travail Fabric compatibles. La détection d’utilisation non conforme peut également marquer l’activité de l’agent qui enfreint les stratégies organisationnelles.

Pour plus d’informations sur l’intégration de Microsoft Purview à Fabric, consultez Utiliser Microsoft Purview pour régir Microsoft Fabric.

configuration de l’agent de données Fabric

La configuration d’un agent de données Fabric est similaire à la création d’un rapport Power BI, vous commencez par la concevoir et l’affiner pour vous assurer qu’elle répond à vos besoins, puis publiez-la et partagez-la avec vos collègues afin qu’elles puissent interagir avec les données. La configuration d’un agent de données Fabric implique :

Selecting data sources : un agent de données Fabric prend en charge jusqu’à cinq sources de données dans n’importe quelle combinaison, y compris les bases de données lakehouses, les entrepôts, les bases de données KQL, les modèles sémantiques Power BI, les ontologies et les Microsoft Graph. Par exemple, un agent de données configuré Fabric peut inclure cinq modèles sémantiques Power BI. Il peut inclure un mélange de deux modèles sémantiques Power BI, un lakehouse et une base de données KQL. Vous disposez de nombreuses options.

Choisir les tables pertinentes : Après avoir sélectionné les sources de données, ajoutez-les une à la fois et définissez les tables spécifiques de chaque source utilisées par l’agent de données Fabric. Cette étape garantit que l’agent de données Fabric récupère des résultats précis en se concentrant uniquement sur les données pertinentes. Pour les lakehouses, cette étape consiste à sélectionner des tables lakehouse (et non des fichiers lakehouse individuels). Si vos données commencent en tant que fichiers (par exemple, CSV ou JSON), mettez-les à la disposition de l’agent en l’ingérer dans des tables ou en l’exposant par le biais de tables.

Adding Context : Pour améliorer la précision de l’agent de données Fabric, fournissez davantage de contexte via des instructions d’agent de données Fabric et des exemples de requêtes. En tant qu’agent sous-jacent pour l’agent de données Fabric, le contexte aide l’API de l’Assistant OpenAI Azure prendre des décisions plus éclairées sur la façon de traiter les questions utilisateur et de déterminer la source de données la mieux adaptée pour y répondre.

• instructions de l’agent Data : ajoutez des instructions pour guider l’agent qui sous-tend l’agent de données Fabric, en déterminant la meilleure source de données pour répondre à des types de questions spécifiques. Vous pouvez également fournir des règles ou des définitions personnalisées pour clarifier la terminologie ou des exigences spécifiques de l’organisation. Ces instructions peuvent fournir plus de contexte ou de préférences qui influencent la façon dont l’assistant sélectionne et interroge des sources de données. Par exemple, dirigez les questions directes sur les métriques financières vers un modèle sémantique de Power BI, attribuez les requêtes impliquant l'exploration de données brutes à la lakehouse, et routez les questions nécessitant une analyse de journaux vers la base de données KQL.

• Requêtes d'exemple : ajoutez des paires d'exemples question-requête pour illustrer comment l'agent de données Fabric doit répondre à des requêtes courantes. Ces exemples servent de guide pour l’assistant, ce qui lui permet de comprendre comment interpréter des questions similaires et générer des réponses précises.

En combinant des instructions d'IA claires et des exemples de requêtes pertinents, vous pouvez mieux aligner l'agent de données Fabric avec les besoins de données de votre organisation, ce qui garantit des réponses plus précises et plus contextuelles.

Couches de gouvernance et d’intention

Lorsque vous configurez un agent de données Fabric, plusieurs couches d’intention peuvent influencer le comportement de l’agent. Ces couches, répertoriées de la priorité la plus élevée à la plus basse, définissent ce que l’agent est autorisé à faire :

1. Intention organisationnelle : stratégies et exigences de conformité à l’échelle du locataire définies par les administrateurs de votre organisation. Ces contraintes sont prioritaires et ne peuvent pas être remplacées par une autre couche.
2. Intention basée sur les rôles : paramètres de gouvernance de l’espace de travail et limites d’autorisation qui s’appliquent à des rôles ou groupes spécifiques. Ces paramètres appliquent des contrôles d’accès et des restrictions d’étendue de données.
3. Intention du développeur : instructions personnalisées, exemples de requêtes et configurations de source de données que vous fournissez lorsque vous générez l’agent de données.
4. Intention de l’utilisateur : Questions et invites que les utilisateurs finaux envoient pendant les conversations avec l’agent.

Lorsque des conflits se produisent entre les couches, les couches de priorité supérieure remplacent les couches inférieures. Par exemple, les stratégies organisationnelles et les paramètres de gouvernance de l’espace de travail remplacent toujours les instructions du développeur et les invites utilisateur. Ce modèle de précédence garantit que l’agent fonctionne dans les limites approuvées, quelle que soit la façon dont il est configuré ou invité.

Différence entre un agent de données Fabric et un copilote

Bien que les agents de données Fabric et les copilotes Fabric utilisent l’IA générative pour traiter et raisonner les données, les principales différences existent dans leurs fonctionnalités et leurs cas d’usage :

Flexibilité de la configuration : vous pouvez personnaliser largement les agents de données Fabric. Vous pouvez fournir des instructions et des exemples personnalisés pour adapter leur comportement à des scénarios spécifiques. Fabric copilotes, d'autre part, sont préconfigurés et ne proposent pas ce niveau de personnalisation.

Portée et cas d'utilisation : Les copilotes Fabric aident à effectuer des tâches au sein de Microsoft Fabric, telles que la génération de code de carnet ou de requêtes d’entrepôt. Agents de données Fabric, en revanche, sont des artefacts configurables autonomes qui peuvent interroger des données sur OneLake et des modèles sémantiques. Fabric agents de données peuvent également s’intégrer à Microsoft 365 Copilot pour exposer des insights en langage naturel directement dans les applications Microsoft 365. Lorsque les agents sont accessibles via Microsoft 365 Copilot, Microsoft Purview stratégies de gouvernance s’appliquent toujours aux sources de données sous-jacentes. En outre, Fabric agents de données peuvent se connecter à des systèmes externes tels que Microsoft Copilot Studio, Azure AI Foundry, Microsoft Teams ou d’autres outils en dehors de Fabric. Les orchestrateurs externes et les runtimes multi-agents peuvent appeler des agents de données Fabric pour prendre en charge les flux de travail agentiques de bout en bout, tandis que les agents de données restent concentrés sur l’accès en lecture seule et régi aux données.

Évaluation de l’agent de données Fabric

L’équipe produit a évalué rigoureusement la qualité et la sécurité des réponses de l’agent de données Fabric :

Benchmark Testing : l’équipe produit a testé Fabric agents de données dans une gamme de jeux de données publics et privés pour garantir des réponses de haute qualité et précises.

Enhanced Harm Mitigations : l’équipe produit a implémenté des mesures de protection pour s’assurer que les sorties de l’agent de données Fabric restent axées sur le contexte des sources de données sélectionnées, ce qui réduit le risque de réponses non pertinentes ou trompeuses.

Gouvernance et sécurité

L'intégration de Microsoft Purview fournit des contrôles de gouvernance pour les agents de données de Fabric. Lorsque vous configurez un agent de données, les stratégies de gouvernance Purview s’appliquent aux sources de données sous-jacentes auxquelles l’agent peut accéder. Cette intégration permet de garantir que l’accès aux données via des agents suit les mêmes règles de conformité et de classification que l’accès direct.

Microsoft Purview stratégies : les stratégies Purview telles que les contrôles d’accès aux données et les étiquettes de confidentialité s’appliquent aux sources de données que les agents interrogent. Si une stratégie Purview restreint l’accès à un lakehouse ou à un entrepôt, l’agent respecte cette restriction lors du traitement des requêtes utilisateur.

Protection de l'accès sortant : Les agents de données Fabric fonctionnent dans les limites de protection de l'accès sortant du locataire. Les connexions sortantes à partir des opérations d’agent sont soumises aux mêmes règles de réseau et d’accès configurées pour votre abonnement Fabric. Les administrateurs peuvent gérer les connexions sortantes autorisées via le portail d’administration Fabric sous les paramètres du locataire pour contrôler quels points de terminaison externes les agents peuvent atteindre.

intégration Microsoft 365 Copilot : quand les agents de données Fabric sont exposés via Microsoft 365 Copilot, les stratégies de gouvernance de Microsoft Purview continuent d’être appliquées. Les utilisateurs peuvent uniquement accéder aux données auxquelles leurs identifiants et les stratégies Purview leur permettent d'accéder, quel que soit le point d’entrée.

ALM et DevOps pour les agents de données

Fabric agents de données prennent en charge les fonctionnalités de gestion du cycle de vie des applications (ALM) qui vous aident à gérer les configurations d’agent dans les environnements de développement, de test et de production.

Diagnostics : utilisez des diagnostics intégrés pour surveiller le comportement de l’agent, identifier les problèmes de génération de requêtes et résoudre les problèmes de qualité de réponse. Les diagnostics fournissent une visibilité sur la façon dont l’agent traite les questions et sélectionne les sources de données.

Intégration Git : vous pouvez contrôler les versions de vos configurations d’agent avec l’intégration Git. Connectez votre espace de travail Fabric à un référentiel Git pour suivre les modifications apportées aux instructions de l’agent, exemples de requêtes et sélections de sources de données au fil du temps.

Pipelines de déploiement : utilisez des pipelines de déploiement de Fabric pour promouvoir des agents de données entre les espaces de travail (par exemple, du développement à la production). Cette prise en charge vous permet de tester les modifications dans un environnement intermédiaire avant de les rendre disponibles pour les utilisateurs finaux.

Surveillance opérationnelle

Pour maintenir l’alignement continu de la qualité et de la stratégie, tenez compte de ces pratiques opérationnelles pour votre agent de données Fabric :

• Journalisation et audit : surveillez les interactions de l’agent par le biais des fonctionnalités de journalisation et d’audit disponibles. L’examen des modèles de requête et de la qualité de la réponse vous aide à identifier un comportement inattendu au début.
• Escalade avec intervention humaine : établissez des voies d’escalade pour les requêtes sensibles ou à impact élevé. Pour les scénarios où les réponses automatisées ne sont pas suffisantes, définissez les processus qui acheminent les questions vers les réviseurs qualifiés.
• Révision périodique : passez régulièrement en revue les instructions de votre agent de données et les exemples de requêtes pour vous assurer qu’elles restent alignées sur les stratégies organisationnelles et les structures de données actuelles. À mesure que vos sources de données ou exigences métier changent, mettez à jour la configuration de l’agent en conséquence.

Limites

• L’agent de données Fabric génère uniquement des requêtes SQL, DAX et KQL « read ». Elle ne génère pas de requêtes SQL, DAX ou KQL qui créent, mettent à jour ou suppriment des données.
• L'agent de données Fabric ne prend pas en charge les données non structurées, telles que .pdf, .docxou les fichiers .txt. Vous ne pouvez pas utiliser l'agent de données Fabric pour accéder aux ressources de données non structurées.
• Pour les sources de données lakehouse, l’agent de données Fabric répond aux questions à l’aide des tables lakehouse que vous sélectionnez. Il ne lit pas directement les fichiers lakehouse autonomes (par exemple, les fichiers CSV ou JSON), sauf s’ils sont ingérés ou exposés en tant que tables.
• L'agent de données Fabric ne prend actuellement pas en charge les langues autres que l'anglais. Pour des performances optimales, fournissez des questions, des instructions et des exemples de requêtes en anglais.
• Vous ne pouvez pas modifier le LLM que l'agent de données Fabric utilise.
• L’historique des conversations dans l’agent de données Fabric risque de ne pas toujours persister. Dans certains cas, tels que les modifications apportées à l’infrastructure principale, les mises à jour de service ou les mises à niveau de modèles, l’historique des conversations passées peut être réinitialisé ou perdu.
• L'agent de données Fabric ne peut pas exécuter de requêtes lorsque la capacité de l'espace de travail de la source de données se trouve dans une région différente de la capacité de l'espace de travail de l'agent de données. Par exemple, un lakehouse avec une capacité en Europe du Nord n'est pas fonctionnel si la capacité de l’Agent de données est en France Centrale.
• Les utilisateurs peuvent fournir jusqu’à 100 exemples de requêtes par source de données dans leur Agent de données.
• Les agents de données Fabric sont actuellement conçus pour les aperçus conversationnels plutôt que pour fournir des jeux de données complets. Pour garantir des réponses concises et performantes, les sorties de conversation limitent et/ou résument automatiquement les données retournées. Actuellement, les réponses sont limitées à un maximum de 25 lignes et 25 colonnes. Notez que l’historique de conversation précédent peut influencer les réponses suivantes. Par exemple, si vous demandez à « afficher toutes les lignes de cette année », l’agent retourne toujours un maximum de 25 lignes. Les questions de suivi peuvent ensuite être répondues en fonction de ce contexte déjà limité, ce qui peut affecter le résultat. Dans ce cas, le démarrage d’une nouvelle session de conversation est recommandé.
• Les réponses de l’agent peuvent être tronquées ou bloquées si les stratégies de DLP ou de restriction d'accès de Microsoft Purview s’appliquent aux sources de données sous-jacentes. Le comportement spécifique dépend de la configuration de la stratégie de votre organisation.
• Les ressources marquées comme sensibles par les stratégies Purview peuvent être inaccessibles à l’agent, ce qui peut entraîner des réponses incomplètes ou une incapacité à interroger certaines sources de données.
• Les interactions de l’agent peuvent être journalisées et détectables via Microsoft Purview Audit et eDiscovery. Les organisations doivent prendre en compte ces contrôles de gouvernance lors du déploiement d’agents pour les charges de travail sensibles.
• L'accès aux modèles sémantiques Power BI via un agent de données est régi par l'autorisation de Lecture sur le modèle et ne nécessite pas d'accès au niveau de l'espace de travail. Sécurité au niveau de la ligne (RLS) et sécurité au niveau de la colonne (CLS) s’appliquent toujours.

Contenu connexe

• Tutoriel de bout en bout sur l'agent de données Fabric
• Créer un agent de données Fabric
• Vue d’ensemble Azure AI Sécurité du Contenu