Correction du copilote Power BI : de l'ambiguïté aux résultats DAX déterministes

Partie 1 : Pourquoi le copilote devine : ce n'est pas un bug

Le comportement décrit ci-dessus n'est pas une erreur logicielle. Il s'agit d'une fonctionnalité de base des grands modèles de langage (LLM) qui alimentent Copilot. Ces modèles sont probabilistes ; ils sont conçus pour générer des réponses, et non pour effectuer des calculs exacts comme une calculatrice. Lorsqu’elle reçoit une invite ambiguë, l’IA doit deviner.

Non-déterminisme : le trait fondamental

L'IA générative ne « comprend » pas votre contexte commercial. Il ne voit que l'invite et la structure du modèle de données (son schéma). Lorsqu'un utilisateur demande le « bénéfice brut », l'IA analyse le schéma pour rechercher les noms de colonnes correspondants. S'il trouve les deux[GrossProfit]et[GrossProfitper], il voit deux bonnes options. Sans plus de contexte, son choix est une supposition statistique. Cela signifie que la même invite peut même donner des résultats différents à des moments différents. Les outils de business intelligence exigent des réponses cohérentes et vérifiables. Ce comportement de l’IA entre en conflit avec ce besoin.

L’échec du pipeline NLQ vers DAX

Voici ce qui se passe en arrière-plan lorsque vous tapez une invite :

Visuel : le pipeline NLQ vers DAX

1

Invite de saisie

«bénéfice brut moyen»

2

Mise à la terre (analyse de schéma)

AI finds:[GrossProfit]et[GrossProfitper]

!

Génération (ambiguïté)

Lequel utiliser ? L’IA « devine »[GrossProfitper].

4

Sortie (DAX incorrect)

AVERAGE('Sales'[GrossProfitper])

Lecture suggérée :Comment désactiver Windows Copilot AI – Windows 10 et 11

5

Exécution (mauvais visuel)

Un graphique du «% de profit moyen» s'affiche.

1. Exécution:Power BI exécute cette mauvaise requête et vous montre un visuel dont vous ne vouliez pas.

Un regard plus approfondi : le processus de « mise à la terre »

L’étape « Grounding » est la phase la plus critique. C'est là que Copilot forme son contexte. Il ne s’agit pas seulement de lire les noms des colonnes. Il analyse et hiérarchise activement plusieurs couches de métadonnées de votre modèle :

• Description des champs :Il s’agit d’un élément hautement prioritaire. Une description bien rédigée est une instruction directe adressée à l’IA.
• Synonymes :Les nouvelles fonctionnalités de Power BI vous permettent de définir des synonymes pour les champs. Par exemple, vous pouvez lier « Revenu », « Revenu » et « Chiffre d'affaires » à votre[Total Sales]mesure.
• Types et catégories de données :Il sait[Date]est un rendez-vous,[City]est un emplacement (et peut être cartographié), et[Profit]est un nombre.
• Relations modèles :Il comprend comment les tables sont liées. C'est comme ça qu'il sait se connecter[ProductCategoryName]du tableau « Produits » au[SalesAmount]du tableau « Ventes ».

L'échec se produit lorsque ce processus d'ancrage aboutit encore à une ambiguïté. Si deux champs (comme[GrossProfit]et[GrossProfitper]) les deux semblent être des matchs tout aussi bons, l'IA est obligée de deviner.

L’échec n’est pas dans la logique de l’IA. L'IA a *correctement* signalé l'ambiguïté trouvée dans le modèle de données. Pour corriger la sortie, vous devez d'abord corriger l'entrée. Cela peut être fait par l'utilisateur (en écrivant une meilleure invite) ou par le développeur (en créant un meilleur modèle).

Partie 3 : Le correctif côté développeur : créer un modèle prêt pour l'IA

S'appuyer sur chaque utilisateur pour rédiger des invites parfaites n'est pas une solution évolutive. La meilleure solution à long terme consiste pour les développeurs Power BI à concevoir des modèles de données « prêts pour l’IA ». Cela signifie supprimer toute ambiguïté avant que l'utilisateur ne tape une invite. Microsoft fournit un ensemble d'outils dans Power BI Desktop et Fabric pour ce faire.

Correctif de couche 3 : guide avec instructions IA

Cet outil fournit une zone de texte dans laquelle vous pouvez donner des règles en anglais simple à l'IA. Vous pouvez écrire : «GrossProfitest le montant total en dollars.GrossProfitperest le pourcentage. Si un utilisateur demande simplement le « bénéfice brut », il veut toujours dire le[GrossProfit]mesure." Cette instruction s’ajoute au contexte de l’IA, la guidant vers le bon choix.

Liste de contrôle des meilleures pratiques d'un développeur

Utilisez cette liste de contrôle pour créer un modèle de données robuste et prêt pour l'IA. Cela fait passer votre modèle d’ambiguïté à déterministe.

• ✓

  Auditer tous les noms

  Tous les noms de champs sont-ils clairs et distincts ? Renommez les colonnes énigmatiques commeCustNo_1àCustomer ID.

• ✓

  Remplir toutes les descriptions

  Rédigez une description claire de chaque mesure et colonne importante. Il s’agit de votre principal outil pour guider l’IA.

• ✓

  Créer des mesures clés

  Ne comptez pas sur l'IA pour deviner les agrégations implicites (commeSUM(Sales[Amount])). Créez des mesures explicites comme[Total Sales]et masquez la colonne de base.

• ✓

  Masquer les champs inutiles

  Si une colonne est utilisée uniquement pour une relation (comme une clé étrangère) ou dans une mesure, masquez-la de la vue du rapport. Si l’IA ne doit pas l’utiliser, cachez-la à l’aide de « Préparer les données pour l’IA ».

• ✓

  Configurer les synonymes

  Accédez à la vue modèle et ajoutez des synonymes pour vos champs les plus importants. Liez les « Revenus », les « Revenus » et le « Chiffre d'affaires » à votre[Total Sales]mesurez pour que l’IA les comprenne tous.

• ✓

  Mettre en œuvre des réponses vérifiées

  Identifiez vos 5 à 10 questions commerciales les plus courantes et créez des « réponses vérifiées » pour elles. Cela fournit une réponse prédéfinie et fiable à 100 %.

Partie 4 : Un cadre stratégique pour l'ambiguïté

Les solutions ci-dessus montrent que les développeurs et les utilisateurs doivent travailler ensemble. Les utilisateurs doivent être précis et les développeurs doivent créer des modèles clairs. Le tableau suivant compare toutes les techniques d'atténuation.

Matrice de comparaison des stratégies d’atténuation

Conceptuel : fiabilité rapide

Ce graphique illustre l'impact de la spécificité de l'invite sur la fiabilité. Une invite vague a de fortes chances de donner lieu à une réponse ambiguë et « devinée ». Une invite spécifique de type commande force une réponse unique et correcte.

Le coût commercial de l’ambiguïté

Il ne s'agit pas seulement d'un problème technique. Les réponses incohérentes ou incorrectes d'un outil d'IA ont des coûts directs pour l'entreprise :

1. Érosion de la confiance

Lorsqu'un responsable obtient un graphique incorrect, il cesse de faire confiance à *l'intégralité* de l'outil. Cela conduit à une faible adoption et à un investissement BI échoué. Les utilisateurs recommenceront à exporter des données vers Excel.

2. Temps et ressources perdus

Les analystes et les développeurs passent des heures à déboguer « pourquoi Copilot a donné la mauvaise réponse » au lieu de trouver de nouvelles informations. Il crée un backlog de tickets de support basé sur un problème de modélisation résoluble.

3. Décisions commerciales incorrectes

C’est le pire des cas. Un dirigeant voit la « moyenne du profit brut » (par exemple 45 %), le prend pour la « moyenne du profit brut » (par exemple 45 000 $) et prend une décision critique basée sur des données erronées.

Partie 5 : Scénarios avancés et synonymes

À mesure que vous maîtriserez l’ambiguïté fondamentale, vous rencontrerez des défis sémantiques plus complexes. La manière dont vous les gérerez déterminera la véritable intelligence de votre modèle de données.

Gestion des synonymes : « Ventes » contre « Revenu » contre « Revenu »

Pour votre entreprise, « Ventes », « Revenus » et « Revenus » peuvent signifier la même chose. Pour l’IA, ce ne sont que des chaînes de texte différentes. Si vous disposez d'une mesure appelée[Total Sales], un utilisateur demandant « Montrez-moi le revenu total » obtiendra une erreur « champ introuvable ».

La solution :Vous devez explicitement mapper ces termes. Dans la vue modèle Power BI, vous pouvez sélectionner le[Total Sales]mesurez et ajoutez « Revenu », « Revenu total » et « Revenu » à sa liste de synonymes. Cela apprend à l’IA que ces mots pointent tous vers la même mesure unique. Désormais, les trois invites renverront le visuel correct.

Le défi multilingue

Que se passe-t-il lorsque votre modèle est en anglais, mais que vos utilisateurs sont internationaux ? Un utilisateur en France peut demander des « ventes par catégorie ». Copilot peut échouer si votre modèle contient uniquement « Ventes » et « Catégorie ».

La solution :Cela nécessite une configuration plus avancée. Vous pouvez utiliser des traductions et ajouter des synonymes multilingues à votre modèle. Vous ajouteriez « ventes » comme synonyme de[Total Sales]et "catégorie" pour[ProductCategoryName]. Cela rend le modèle accessible à une base d'utilisateurs mondiale sans modifier la structure de données sous-jacente.

Quand l’ambiguïté est (brièvement) utile

Il existe une situation où l’ambiguïté ne pose pas de problème : l’exploration pure. Une invite utilisateur telle que « Montrez-moi ce qui est intéressant dans mes données de vente » est intentionnellement vague. Cela invite l'IA à être « créative » et à générer plusieurs graphiques (par exemple, ventes au fil du temps, ventes par région, ventes par produit) pour trouver un modèle intéressant.

Cependant, il s’agit d’une *analyse exploratoire*, et non d’un *reporting*. Dès qu’un utilisateur a besoin d’une réponse spécifique à une question spécifique (« Quel a été notre bénéfice au dernier trimestre ? »), l’ambiguïté devient un handicap. Votre objectif en tant que développeur doit être d'éliminer toute ambiguïté pour toutes les questions commerciales connues, tout en permettant une exploration plus large.

Partie 6 : Outil de création d'invites interactives

Cet outil vous aide à traduire la requête DAX souhaitée en une invite Copilot fiable et sans ambiguïté. En réfléchissant à la requête DAX exacte dont vous avez besoin, vous pouvez apprendre à rédiger des invites qui suppriment toute conjecture pour l'IA. Écrivez le DAX que vous souhaitez et voyez l'invite parfaite pour l'obtenir.

1. Votre invite simple/ambiguë

2. Le DAX sans ambiguïté que vous souhaitez

Générer une invite fiable

Invite sans ambiguïté recommandée :

Cette invite est générée à partir des noms de champs exacts trouvés dans votre DAX. Cela lève toute ambiguïté.

Veuillez saisir une requête DAX contenant des noms de champs tels que'Table'[Column]ou[Measure].

Foire aux questions (FAQ)

La « devinette » de Copilot est-elle un bug qui sera corrigé ?

Non, ce n'est pas considéré comme un bug. Il s’agit d’un élément fondamental du fonctionnement des modèles d’IA génératifs. Ils sont conçus pour être probabilistes et « générer » la réponse la plus probable en fonction des informations saisies. Étant donné que l'entrée (invite vague + modèle ambigu) est ambiguë, la sortie est une supposition. La solution n'est pas de changer l'IA, mais de supprimer l'ambiguïté de l'invite et du modèle de données.

Pourquoi Copilot a-t-il choisi le champ de pourcentage au lieu du montant en dollars ?

Il n’y a pas une seule raison. Ça pourrait être ça[GrossProfitper]était par ordre alphabétique en premier dans le schéma, ou il a été ajouté plus récemment, ou les données d'entraînement de l'IA lui ont simplement donné une probabilité légèrement plus élevée. L’essentiel est que c’était une supposition. La seule façon d'éviter toute supposition est de supprimer le choix, soit en écrivant une invite spécifique ([GrossProfit]) ou en cachant l'autre champ à l'IA.

Quelle est la meilleure façon de résoudre ce problème ?

Pour unutilisateur final, la meilleure solution consiste à toujours utiliser des noms de champs entre crochets comme[ColumnName]dans vos invites.

Pour unpromoteur, la solution la plus robuste consiste à utiliser les outils « Prep data for AI ». Utilisez « Réponses vérifiées » pour vos 5 à 10 principales questions et « Schémas de données IA » pour masquer toutes les colonnes déroutantes ou inutiles de l'IA.

Dois-je toujours utiliser un bon nommage si j'utilise les outils « Préparer les données pour l'IA » ?

Oui. Une dénomination claire et correcte (par exemple :Gross Profit Percentage) constitue la base d'un modèle de données sain. Ces noms aident les analystes humains tout autant qu’ils aident l’IA. Les outils « Prep data for AI » constituent une deuxième couche de contrôle puissante, mais ils doivent être utilisés avec un modèle bien conçu, et non comme un correctif pour un modèle mal conçu.