Bonnes pratiques pour utiliser les règles de gouvernance sémantique

Une gouvernance efficace repose sur des descriptions précises, claires et complètes des outils et de leurs paramètres. Les systèmes agentiques, y compris les agents eux-mêmes et les couches de gouvernance comme les règles de gouvernance sémantique, nécessitent plus de détails qu'un humain pour comprendre l'applicabilité des outils disponibles.

Optimiser les descriptions des outils

Utilisez des descriptions claires des outils MCP et des paramètres requis par ces outils.

• Description de l'outil insuffisante : "Rechercher des éléments."
• Description efficace de l'outil : "Recherchez dans le catalogue de contenus par mot clé, acteur, genre ou format. Utilisez cette intention lorsque l'utilisateur souhaite connaître les films ou les programmes TV disponibles. Renvoie les 10 premiers éléments triés par pertinence."

Respectez les limites concernant les descriptions

Le système de gouvernance sémantique applique les limites de longueur suivantes pour les descriptions :

Si le runtime de gouvernance sémantique reçoit une description qui dépasse l'une de ces limites, il la tronque à la limite indiquée et enregistre un message.

Quand la règle de gouvernance sémantique intervient

La règle de gouvernance sémantique fonctionne spécifiquement comme un contrôle de sécurité d'exécution sur les appels d'outils proposés. Il n'intercepte, ne bloque ni ne modifie le dialogue conversationnel standard entre l'utilisateur et le LLM de l'agent lors du brainstorming, de la planification ou du raisonnement sur plusieurs tours. Le moteur de règles intercepte et évalue les requêtes uniquement au moment où le modèle propose d'appeler un outil pour exécuter une action.

Scénario 1 : Affinement conversationnel vs exécution d'outil (appel d'outil refusé)

Prenons l'exemple d'un agent qui dispose d'un outil initiate_marketing_campaign et qui est régi par la contrainte suivante :

• Contrainte : "Interdire la création ou le lancement de campagnes marketing sans l'approbation explicite du responsable"

1. Planification conversationnelle : un utilisateur demande à l'agent Aide-moi à concevoir une campagne marketing multicanal pour le lancement de notre nouveau produit d'automne. Le LLM converse librement avec l'utilisateur sur plusieurs tours, en définissant des stratégies, en rédigeant des e-mails et en affinant les données démographiques cibles. Le moteur de règles ne bloque pas ces tours de parole ni ne les refuse, car le modèle s'engage dans un raisonnement conversationnel plutôt que de proposer une action.

2. Invocation de l'outil : une fois la stratégie finalisée, l'utilisateur dit "C'est parfait, lance la campagne marketing maintenant." Le LLM répond en générant un appel d'outil proposé :

   initiate_marketing_campaign(campaign_name="Fall Launch", budget=50000)
   

3. Intervention et refus de la règle : l'Agent Gateway intercepte cet appel d'outil proposé et le transmet au moteur de stratégies. Le moteur de règles évalue l'action par rapport à la contrainte, détermine qu'aucune approbation du responsable n'existe dans l'historique des sessions et émet un verdict DENY. L'appel d'outil est bloqué avant son exécution, et une justification structurée du refus est renvoyée à l'agent.

Scénario 2 : Exécution d'outil conforme (appel d'outil autorisé)

Prenons l'exemple d'un même agent marketing après qu'une autorisation de supervision appropriée a été documentée :

1. Approbation fournie : l'utilisateur précise : "Mon responsable, le vice-président du marketing d'entreprise (jordan@example.com), a examiné le brief et approuvé notre budget de 50 000 $ pour la campagne de lancement d'automne. Veuillez l'initier."

2. Invocation de l'outil : le LLM propose d'invoquer l'action :

   initiate_marketing_campaign(campaign_name="Fall Launch", budget=50000, approval="jordan@example.com")
   

3. Évaluation et approbation des règles : le moteur de règles intercepte l'appel d'outil, vérifie dans l'historique des tours de conversation que l'approbation du responsable est documentée et émet un verdict ALLOW. L'Agent Gateway transfère l'appel au point de terminaison de l'outil sous-jacent, ce qui permet à l'action de se dérouler normalement.

Exemples de contraintes efficaces

Une bonne contrainte élimine l'ambiguïté, spécifie des limites exactes (financières, temporelles ou géographiques) et utilise un langage adapté aux outils utilisés par l'agent.

Infrastructure cloud informatique (sécurité et contrôle des coûts)

• Scénario : Environnements de test.
• Outil : provision_cloud_server (paramètres : region, instance_type, duration_hours).
• Description de l'outil : envoie une requête pour provisionner un serveur cloud dans une région spécifique, en utilisant un type d'instance spécifique, pour une durée donnée.
• Contrainte effective : "Autoriser le provisionnement de serveurs cloud uniquement dans les régions "us-east" ou "eu-west". Refusez toute demande de provisionnement des types d'instances "gpu-large" ou "gpu-xlarge". Limitez le paramètre duration_hours à 72 heures maximum."
• Pourquoi ça marche : le langage utilisé correspond à la description de l'outil et fait spécifiquement référence aux paramètres acceptés par l'outil.

Service client d'e-commerce (garde-fous financiers)

• Scénario : émettre des avoirs sur le compte.
• Outil : apply_account_credit (paramètres : account_id, credit_amount, reason_category).
• Contrainte effective : "Limitez les avoirs du compte à 50 $ maximum par interaction. N'applique aucun avoir si la catégorie de motif est "shipping_delay" (retard de livraison) et que la date de la commande d'origine est antérieure de moins de cinq jours."
• Pourquoi ça marche : définit un seuil strict en dollars et le combine à une condition logique basée sur le temps et la catégorie.

Exemples de contraintes inefficaces

Une contrainte de mauvaise qualité est généralement vague, utilise un langage subjectif ou ne correspond pas directement aux descriptions des outils ou des paramètres d'outil.

Infrastructure cloud informatique (subjectif)

• Contrainte inefficace : "Veille à ne pas créer de serveurs trop chers. Veillez à ce que la durée soit raisonnable."
• Pourquoi ça ne marche pas : un LLM est plus performant avec des chiffres précis (par exemple, "limite de 50 $") qu'avec des concepts abstraits comme "raisonnable" ou "cher".

Service client (terminologie non conforme)

• Contrainte inefficace : "Ne rembourse pas les clients mécontents en dehors des horaires d'ouverture."
• Pourquoi la réponse échoue-t-elle ? "Rembourser" ne correspond pas aux paramètres de l'outil (refund_amount). "Clients mécontents" est subjectif, et "heures d'ouverture" n'est pas défini sans fuseau horaire.

Conseils sur la langue

Lorsque vous créez des contraintes, suivez ces consignes :

• Utilisez un langage humain simple : utilisez des phrases complètes au sens déclaratif ou impératif (par exemple, "Vous ne devez pas autoriser…" ou "Refusez…").
• Évitez les formulations faibles : évitez les expressions "Je pense qu'il est préférable de…" ou "Essayez d'éviter…". La formulation est importante pour le juge LLM.
• Soyez précis : spécifiez les contraintes avec des limites clairement indiquées (par exemple, "1 000 $", "de 8h à 16h EST"). Utilisez des termes qui correspondent aux descriptions des outils et des paramètres.
• Évitez les contradictions : assurez-vous que les contraintes au niveau de l'agent et de l'outil ne sont pas en conflit (par exemple, des seuils monétaires différents).

Tester les contraintes : vous pouvez tester vos contraintes en langage naturel à l'aide du mode simulation, qui évalue les règles sans les appliquer.

Étapes suivantes

• Découvrez comment régir les compétences des agents dans Régir les compétences des agents.
• Découvrez comment associer des règles à la sortie de la passerelle dans Déléguer l'autorisation aux règles de gouvernance sémantique.
• Configurez les règles dans Configurer les règles de gouvernance sémantique.