Microsoft Copilot Studio : défis et solutions de l'IA hybride

Comment l'architecture IA empêche des analyses plausibles mais erronées

Un réseau d'IA agentique a été conçu pour conseiller les usines de fabrication sur l'amélioration de leurs opérations. Ce système, axé sur les données, permet aux utilisateurs de télécharger des données d'évaluation directement via l'interface de chat. Le premier prototype fonctionnel a été achevé étonnamment rapidement et, à première vue, les résultats semblaient prometteurs.

Il n'y avait qu'un seul problème : la plupart des résultats étaient incorrects ! Pire encore, l'IA a rapidement appris quels intervalles numériques semblaient plausibles et a commencé à générer des résultats convaincants mais fabriqués. Combinés avec la génération de langage éloquent des LLM, ces résultats pouvaient facilement être pris pour des vérités. Et ce comportement n'était pas limité à un seul modèle. Des schémas similaires sont apparus dans tous les systèmes testés : ChatGPT, Gemini Enterprise, DIA Brain et Microsoft Copilot.

Mais des données plausibles ne suffisent pas, les systèmes d'IA d'entreprise nécessitent des données fiables !

Une enquête plus approfondie a révélé des modes de défaillance récurrents. Même avec le mode "Interpréteur de code" activé, les systèmes :

• sautaient des lignes ou des colonnes,
• appliquaient des filtres incorrects,
• retournaient des résultats identiques pour des entrées différentes,
• mélangeaient silencieusement des parties du jeu de données,
• ou s'effondraient simplement sous des tâches analytiques plus complexes.

Cela a conduit à une réalisation cruciale : le raisonnement probabiliste est extrêmement puissant pour l'interprétation et l'interaction, mais l'analyse de données fondamentale nécessite une exécution déterministe.

Le Cas d'Utilisation

Bien que le cas d'utilisation spécifique soit secondaire, il est brièvement décrit ici pour soutenir la compréhension pratique du défi architectural sous-jacent.

La tâche principale de notre agent est de conseiller les usines de fabrication et les chaînes de valeur sur la manière d'améliorer leur maturité opérationnelle : optimiser les processus, améliorer la productivité, réduire les niveaux d'inventaire et, en fin de compte, diminuer les coûts opérationnels. Pour y parvenir, l'agent de consultation fonctionne en deux modes :

• Il fournit des recommandations génériques pour améliorer des sujets opérationnels spécifiques basées sur la récupération de documentation spécialisée "comment faire" et de questionnaires d'évaluation.
• L'agent est destiné à analyser la situation actuelle d'une usine ou d'une chaîne de valeur sur la base des résultats d'évaluation et des recommandations écrites des évaluateurs. Sur la base de cette analyse, il est censé fournir des recommandations très spécifiques pour les prochaines étapes d'amélioration.

Dans les deux modes — comme c'est le cas pour la plupart des modèles d'IA basés sur des LLM — l'utilisateur peut discuter de manière interactive des idées et des recommandations avec l'agent afin de dériver le plan d'action le plus adapté.

Pour le deuxième mode d'opération, il est essentiel que l'agent puisse traiter et analyser de manière fiable les données d'évaluation. Dans notre cas, ces données sont fournies sous forme d'exportation Excel depuis une base de données centrale. Idéalement, l'agent devrait être capable de traiter le fichier sans préparation manuelle préalable.

Cependant, la structure du fichier est complexe. Étant donné que tous les résultats d'évaluation, les calculs intermédiaires, les métadonnées et les questions d'évaluation détaillées sont stockés dans des colonnes séparées, la feuille de calcul contient plus de 800 colonnes. Le nombre de lignes correspond au nombre d'évaluations dans la base de données et peut varier d'une à plusieurs centaines. Les évaluations sont représentées par des entiers allant de 0 à 4. De plus, le fichier contient plus de 160 champs de texte libre avec des observations qualitatives, des forces, des faiblesses et des recommandations des évaluateurs.

L'Architecture Hybride

L'idée principale pour surmonter le défi analytique était de séparer clairement l'analyse de données déterministe du raisonnement et de l'interprétation basés sur des LLM. Le système a été implémenté dans Microsoft Copilot Studio car la plateforme permet de combiner des éléments de flux de travail déterministes, tels que des sujets et des flux, avec des composants de raisonnement basés sur des LLM.

L'agent parent gère toute la communication avec l'utilisateur. Il orchestre les sous-agents et le module d'analyse, délègue des tâches à ceux-ci, reçoit leurs réponses et compose la réponse finale.

Les sous-agents sont des modules spécialisés basés sur des LLM ayant accès à des sources de connaissances spécifiques. Celles-ci incluent des descriptions des attentes en matière de niveaux de maturité pour les chaînes de valeur, des questionnaires avec des questions d'évaluation détaillées, et des directives plus générales pour l'excellence opérationnelle. Les sous-agents sont appelés par l'agent parent selon leurs capacités spécifiques et répondent à l'agent parent plutôt qu'à l'utilisateur directement.

Le module d'analyse est le principal sujet de cet article. Il effectue l'analyse de données déterministe et est conçu pour fournir des résultats analytiques reproductibles et fiables. Il reçoit une instruction d'analyse en langage naturel de l'agent parent, appelée Parent_Instruction. Le module d'analyse lui-même se compose de sujets, de flux et de modules d'IA, appelés "prompts" dans Copilot Studio.

Le sujet T_receive_Excel_File gère le téléchargement et le stockage des fichiers d'évaluation. Il est déclenché lorsqu'un fichier est téléchargé dans la fenêtre de chat, indiqué par la variable System.Activity.Attachments ayant une valeur. Le sujet vérifie si le fichier téléchargé est un fichier Excel et, si c'est le cas, le stocke dans la variable globale Assessment_File.

Le sujet T_analyze_assessments est activement appelé par l'agent parent s'il a une tâche d'analyse à réaliser et reçoit Parent_Instruction comme entrée. Une seconde entrée est les données d'évaluation stockées dans la variable globale Assessment_File. Le sujet contient les deux composants analytiques principaux : Analysis_Planner et Analysis_Engine. Les deux sont intégrés dans des flux agentiques, F_Call_Analysis_Planner et F_Call_Analysis_Engine. Ces flux servent de connecteurs entre le sujet T_analyze_assessments et les prompts d'IA P_Analysis_Planner et P_Analysis_Engine.

Le Planificateur d'Analyse

Le P_Analysis_Planner est la partie intelligente du pipeline d'analyse de données et génère l'instruction d'analyse, appelée Selection_Rule. Cette instruction est une traduction de la Parent_Instruction en langage naturel et est généralement unique pour chaque demande. Afin de minimiser la variation probabiliste, le processus de traduction est contraint par des règles strictes.

Le Planificateur d'Analyse ne traite pas les données d'évaluation lui-même. Sa seule responsabilité est de traduire la Parent_Instruction probabiliste en une spécification d'analyse déterministe.

Dans ce qui suit, nous examinerons des parties sélectionnées de l'instruction plus en détail. Vous pouvez télécharger l'instruction complète ici.

Vous êtes Analysis_Planner, un assistant expert pour traduire les demandes d'analyse d'évaluation en langage naturel en Selection_Rules structurées.

Votre tâche est de créer un objet JSON Selection_Rule pour l'Analysis_Engine.

Vous ne recevez qu'une seule entrée :

1. Parent_Instruction : Une demande d'analyse en langage naturel de l'agent parent (orchestrateur).

Vous devez analyser Parent_Instruction et déterminer :

• quel type d'analyse est requis,
• quelles catégories de contenu d'évaluation sont pertinentes,
• si la maturité/les constatations conceptuelles ou d'exécution sont demandées,
• si des chapitres spécifiques sont demandés,
• et si des filtres de ligne sont nécessaires.

La Selection_Rule que vous générez sera utilisée plus tard par l'Analysis_Engine avec :

• le fichier de données d'évaluation réel,
• et le Mapping_File pour exécuter l'analyse de manière déterministe.

Le code ci-dessus montre l'instruction initiale pour P_Analysis_Planner. Il définit clairement le but et le champ d'application et sépare explicitement la planification de l'exécution. Le planificateur traduit la demande, tandis que l'exécution réelle est déléguée à P_Analysis_Engine.

Ensuite, une section plus longue décrit la sémantique des données d'évaluation. Bien sûr, cette partie est hautement spécifique au cas d'utilisation et au jeu de données individuels. Elle définit les catégories sémantiques utilisées pour le filtrage des lignes et les catégories utilisées pour sélectionner les cibles d'analyse réelles (TARGET CONTENT CATEGORIES et TARGET SELECTION ATTRIBUTES).

SÉMANTIQUE DES DONNÉES D'ÉVALUATION

Les données d'évaluation peuvent être abordées à travers les catégories sémantiques suivantes.

CATÉGORIES DE FILTRE DE LIGNE

Utilisez ces catégories uniquement pour row_filters :

• Identifiant unique de la chaîne de valeur.

  • Utilisé lors du filtrage par numéro de chaîne de valeur.

• Nom de la chaîne de valeur.

  • Utilisé lors du filtrage par nom de chaîne de valeur.

CATÉGORIES DE CONTENU CIBLE

Utilisez ces catégories uniquement dans target_selection_rules.data_category :

• chapter_score :

  • Score de maturité numérique.
  • Utilisé pour les calculs de maturité, l'analyse des scores et l'analyse de la maturité moyenne.

• Déclarations des évaluateurs décrivant les forces.