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. Utilisez 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. Cette description permet à l’agent d’interpréter correctement les valeurs de données.

• Colonne de temps d’ingestion : l’agent d’opérations utilise par défaut l’heure d’ingestion de la table pour identifier le moment où les enregistrements sont arrivés. L’agent utilise cette valeur lorsqu’il interroge les données les plus récentes et calcule les modifications apportées aux données au fil du temps. Assurez-vous que la date et l’heure d’ingestion sont renseigné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 de 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 ». L’agent utilise les connaissances LLM par défaut pour suggérer des seuils pour les termes courants, tels que les « conditions acides » signifie pH <7.

• 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 LLMs peuvent interpréter les informations différemment en fonction de leur position dans l'invite de commande.

• Suivez les requêtes de l’agent et l’accès aux données : Examinez les sources de données et les requêtes utilisées par l’agent en consultant l’Eventhouse ou la base de données KQL surveillés. Utilisez l’onglet Insights des requêtes pour afficher les requêtes exécutées et valider le KQL généré.

  

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’exploitation ont des limitations fonctionnelles, de plateforme et comportementales que vous devez prendre en compte lors de la conception de règles et de scénarios de supervision.

Limitations de la source de données

• Une seule source de données est prise en charge à la fois.
• Lorsque vous utilisez un Eventhouse comme source de données :
  • Seules les tables Eventhouse classiques sont prises en charge. Les tables de raccourcis, les fonctions et les vues matérialisées ne sont pas prises en charge.
• Lors de l'utilisation d'une Fabric Ontology comme source de données de l'agent :
  • L’ontologie 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.

Limitations des règles de surveillance d’ontologies

• Lors de la surveillance d’une ontologie :
  • Seules les valeurs de base des biens sont prises en charge. Les agrégations telles qu’une valeur moyenne, minimale ou maximale ne sont pas prises en charge.
  • Les règles qui nécessitent des conditions « AND » ne sont pas prises en charge (par exemple, l’indice de freinage d’une piste est supérieur à 0,8 et le temp de surface est < de 40).

Limites du langage et du comportement du modèle

• Les agents d’opérations s’appuient sur un modèle de langage volumineux (LLM). Les sorties sont probabilistes et peuvent être incorrectes, 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.
• Actuellement, les agents d’opérations prennent uniquement en charge la langue anglaise pour les instructions et les objectifs métier.

Limitations du runtime

• L’agent exécute des requêtes toutes les cinq minutes lorsqu’il est actif.
• Les opérations expirent si aucune action n’est effectuée dans les trois jours. Après expiration, les actions ne peuvent plus être approuvées.

Limitations d’accès et d’autorisations

• L’agent fonctionne à l’aide de l’identité déléguée et des autorisations de son créateur. Cela signifie :
  • Les requêtes et les actions utilisent les 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.

Limites de messagerie et de limitation du débit

• Une utilisation intensive peut entraîner une limitation du débit des messages. Dans ces cas, des messages simplifiés non générés par un LLM peuvent être envoyés dans Microsoft Teams.

Limitations régionales et de l’espace de travail

• L’agent Operations est disponible dans les régions Microsoft Fabric du cloud public Azure, à l’exception de Centre-Sud des États-Unis et Est des États-Unis.
• L’agent d’opérations n’est actuellement pas disponible dans les clouds souverains, notamment GCC-High et Bleu.
• L’Agent des opérations n’est actuellement pas pris en charge dans les espaces de travail chiffrés à l’aide de clés gérées par le client pour les espaces de travail Fabric.