Meilleures pratiques et limitations de l’agent d’opérations

Cet article décrit les meilleures pratiques et limitations lorsque vous utilisez des agents d’opérations dans Real-Time Intelligence.

Meilleures pratiques

Les agents d’opérations aident les organisations à réaliser des objectifs métier clairs en surveillant en permanence les données en temps réel, en évaluant des seuils explicites et en recommandant des actions lorsque des conditions définies sont remplies. Par exemple, les agents d’exploitation vous aident à répondre de manière proactive lorsque la disponibilité de l’inventaire passe à un niveau critique. Nous vous recommandons les meilleures pratiques suivantes pour les agents d’exploitation.

• Tables Eventhouse : si les tables eventhouse contiennent des colonnes imbriquées telles que JSON, aplatir les tables avant de configurer l’agent. Les tables plates avec des noms de colonnes descriptifs améliorent la capacité de l’agent à analyser et à évaluer les données.

• Descriptions des colonnes Eventhouse : si l’objectif d’une colonne n’est pas clair à partir de son nom, ajoutez une description en langage brut à l’aide du champ de description dans votre schéma de table KQL. Cela permet à l’agent d’interpréter correctement les valeurs de données.

• Identification de l’objet métier : si l’agent doit surveiller un objet métier spécifique tel qu’une station, un capteur ou un enregistrement personnel, identifiez la colonne qui identifie de manière unique l’objet (par exemple, « StationID » ou « SensorID »). Si vous utilisez une source de base de données KQL, spécifiez la table à laquelle elle appartient. Si vous utilisez une source d’ontologie, spécifiez l’entité que l’agent doit utiliser.

• Citation des noms de champ : si une règle fait référence à des noms de colonne ou de propriété qui contiennent des caractères spéciaux, tels que des traits de soulignement ou des traits d’union, placez le nom de la colonne entre guillemets (""). Cette pratique garantit que l’agent l’identifie correctement.

• Conditions mesurables : si une règle utilise un langage qualitatif tel que « faible disponibilité » ou « haute température », remplacez-le par un seuil numérique spécifique. Par exemple, utilisez une expression telle que « moins de 3 vélos disponibles » ou « la température dépasse 80 ».

• Séparation des règles : si vous définissez plusieurs règles, décrivez chaque règle sur une ligne ou un point de puce distinct. Ne combinez pas les conditions de différentes règles dans la même phrase.

• Ordre des règles : si l’agent doit hiérarchiser certaines règles, répertoriez d’abord les règles de priorité supérieure. Les modèles de langage de grande taille (LLMs) peuvent interpréter les informations différemment en fonction de leur position dans la demande.

Exemples d’instructions

Voici un exemple de la façon dont vous pouvez présenter vos instructions à l’agent pour qu’il soit clair sur ses règles opérationnelles et les informations sémantiques sur les champs de vos données.

*** Operational Instructions ***
1. Alert me when a trip has high occupancy level.
2. Alert me when a trip has high departure delay.

*** Semantic Instructions ***
1. Information about a trip can be found in 'TripUpdateFlattened' table, each identified by the 'trip_id' column.
2. Information about a vehicle can be found in 'VehiclePositionsFlat' table, each identified the 'vehicle_id' column.
3. A trip is a associated with multiple vehicles via shared trip ID.
4. Occupancy status of a trip is calculated as the latest occupancy status from the vehicle the trip is associated with. The value 'HIGH' means high occupancy level.
5. The departure delay is measured in number of seconds. Higher than 300 seconds of delay is considered significant.

Limites

• Les agents d’opérations s’appuient sur un LLM pour créer le playbook et les règles que l’agent suit, et pour raisonner et générer des messages pour les actions et les recommandations. Étant donné que les services IA basés sur LLM sont probabilistes et peuvent être fallibles, il est important d’examiner attentivement les résultats et les recommandations qu’ils fournissent. Pour plus d’informations, consultez Confidentialité, sécurité et utilisation responsable de Copilot pour Real-Time Intelligence.

  Pour suivre les requêtes et les données que l'agent consulte, vous pouvez examiner les bases de données eventhouse et KQL qu'il surveille. Sous l’onglet Insights des requêtes, vous voyez les requêtes qu’il exécute et pouvez valider le KQL qu’il utilise.

  

• Actuellement, seules les tables Eventhouse standard sont prises en charge. Les tables de raccourcis, les fonctions et les vues matérialisées ne sont pas prises en charge.

• Si vous utilisez une ontologie Fabric pour la source de données de l'agent, elle doit se trouver dans le même espace de travail que l'agent d'opérations.

• Les entités d’ontologie que vous souhaitez que l’agent surveille doit avoir au moins une propriété statique à utiliser comme identificateur pour les entités. Les propriétés timeseries doivent être liées aux champs eventhouse.

• La surveillance de l’ontologie est limitée aux valeurs de propriété de base uniquement. Toute agrégation telle qu’une valeur moyenne, minimale ou maximale n’est pas prise en charge. La surveillance nécessitant une condition « AND » (par exemple, l’indice de freinage d’une piste est supérieur à 0,8 et le temp de surface est < de 40) n’est pas pris en charge.

• Bien que les garde-fous système soient en place, une utilisation intensive peut entraîner une limitation, ce qui limite le nombre de messages que l’agent peut envoyer. Dans ce cas, vous pouvez recevoir des messages simplifiés et non générés par LLM via Microsoft Teams.

• À l’heure actuelle, l’agent et LLM prennent en charge uniquement les instructions et objectifs anglais.

• L’agent fonctionne à l’aide de l’identité déléguée et des autorisations de son créateur. En d’autres termes :

  • Les requêtes, l’accès aux données et les actions s’exécutent en fonction des informations d’identification du créateur.

  • Par défaut, le créateur reçoit des messages de recommandation. La modification du destinataire ne modifie pas les informations d’identification utilisées pour les requêtes et les actions.

• L’agent exécute des requêtes de données toutes les cinq minutes lorsqu’il est actif.

• Lorsque l’agent détecte les données correspondant à ses règles, il suit les actions recommandées et la réponse de l’utilisateur en tant qu’opération. Si l’utilisateur ne répond pas (approuve ou rejette) dans les trois jours, l’opération est automatiquement annulée. Après cette période, vous ne pouvez pas interagir ou approuver l’action.

• L’agent d’opérations est disponible dans les régions Microsoft Fabric, à l’exclusion de la RÉGION USA Centre Sud et USA Est.

• Si votre locataire et votre capacité Fabric se trouvent dans différentes régions, vous risquez d’avoir des erreurs lorsque vous configurez des actions Power Automate. Tant qu’un correctif n’est pas disponible, pour utiliser l’agent d'opérations, assurez-vous que la capacité de votre espace de travail se trouve dans la même région que votre client Fabric.