Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Bonnes pratiques en matière de politique de raisonnement automatisé

Cette page regroupe les meilleures pratiques pour créer et gérer des politiques de raisonnement automatisé. Lisez ceci avant de créer votre première politique et consultez-y à nouveau lorsque vous corrigez des problèmes. Pour les fondements conceptuels de ces pratiques, voirLe raisonnement automatique vérifie les concepts. Pour les instructions de step-by-step création, voirCréation de votre politique de raisonnement automatisé.

Commencez simplement et itérez

L'erreur la plus courante lors de la création d'une politique de raisonnement automatisé consiste à essayer de capturer un document complexe dans son intégralité en un seul passage. Commencez plutôt par un sous-ensemble ciblé de vos règles et développez-les progressivement.

Cette approche présente deux avantages : elle permet d'isoler plus facilement les problèmes (vous savez quelle section a introduit un problème) et elle permet de gérer la politique pendant le développement. Une politique comportant 10 règles éprouvées est plus utile qu'une politique comportant 100 règles non testées.

Pré-traiter les documents avec un LLM

Pour les documents longs, contenant de la prose narrative ou mélangeant des règles à du contenu non lié aux règles (tels que des avertissements juridiques ou des antécédents organisationnels), passez le document par le biais d'un LLM avant de le télécharger vers Automated Reasoning checks. Demandez au LLM d'extraire le contenu selon des règles explicites si c'est le cas. Cette étape de prétraitement améliore considérablement la qualité de la politique extraite, car les contrôles de raisonnement automatisés fonctionnent mieux avec des instructions déclaratives claires plutôt qu'avec du texte non structuré.

Lorsque vous rédigez votre invite de prétraitement, incluez les instructions suivantes pour le LLM :

Pour des modèles d'invite détaillés et un flux de travail step-by-step de prétraitement, voir(Facultatif) Utilisez un LLM pour réécrire les documents sous forme de règles logiques.

Utiliser les implications (=>) pour structurer les règles

Le format if-then (utilisant l'opérateur d'=>implication) est le modèle d'écriture de règles le plus important. Chaque règle qui exprime une relation conditionnelle doit utiliser ce format.

Les assertions simples (règles sans structure « si alors ») créent des axiomes, des affirmations toujours vraies. L'assertion eligibleForParentalLeave indique qu'Automated Reasoning vérifie que l'éligibilité au congé parental est toujours vraie, quelles que soient les conditions. Toute entrée indiquant que l'utilisateur n'est pas éligible serait renvoyée IMPOSSIBLE car elle contredit cet axiome.

Les assertions simples ne sont appropriées que pour les conditions limites qui doivent toujours être valables, telles que :

;; Account balance can never be negative
(>= accountBalance 0)

;; Interest rate is always between 0 and 1
(and (>= interestRate 0) (<= interestRate 1))

Si vous trouvez de simples assertions dans votre politique extraite, réécrivez-les sous forme de conditions ou supprimez-les. Pour plus d'informations sur la révision de votre politique extraite, consultezPassez en revue la politique extraite.

Rédiger des descriptions complètes des variables

Les descriptions des variables sont le principal facteur de précision de la traduction. Lorsque les contrôles de raisonnement automatisés traduisent le langage naturel en logique formelle, ils utilisent des descriptions de variables pour déterminer quelles variables correspondent aux concepts mentionnés dans le texte. Les descriptions vagues ou incomplètes sont la principale cause des TRANSLATION_AMBIGUOUS résultats.

Une bonne description de variable doit répondre à quatre questions :

Exemple : Avant et après

Utiliser des booléens pour les états non exclusifs

Lorsque vous modélisez des états qui peuvent coexister, utilisez des variables booléennes distinctes au lieu d'une seule énumération. Une personne peut être à la fois un vétéran et un enseignant. L'utilisation d'une énumération customerType = {VETERAN, TEACHER} force le choix entre les deux, ce qui crée une contradiction logique lorsque les deux s'appliquent.

Réservez des énumérations pour des catégories réellement incompatibles où une seule valeur peut s'appliquer à la fois, par exemple leaveType = {PARENTAL, MEDICAL, BEREAVEMENT} (un employé ne peut demander qu'un seul type de congé à la fois). Pour plus d'informations sur les types personnalisés, consultezTypes personnalisés (enums).

Spécifier les unités et les formats dans les descriptions des variables

L'ambiguïté concernant les unités est une source courante d'erreurs de traduction. Si un utilisateur dit « Je travaille ici depuis 2 ans » et que votre variable est la suivantetenureMonths, la traduction doit être connue pour convertir les années en mois. Si la description de votre variable ne précise pas l'unité, la traduction peut assigner à la tenureMonths = 2 place detenureMonths = 24.

Spécifiez toujours :

Exemples :

Validation de plages pour les valeurs numériques

Pour les variables numériques, ajoutez des règles de limite qui limitent la plage valide. Cela évite les scénarios logiquement impossibles et permet aux contrôles de raisonnement automatisés de produire des résultats plus significatifs.

;; Account balance cannot be negative
(>= accountBalance 0)

;; Interest rate must be between 0 and 1 (0% to 100%)
(and (>= interestRate 0) (<= interestRate 1))

;; Credit score ranges from 300 to 850
(and (>= creditScore 300) (<= creditScore 850))

;; Tenure in months cannot be negative
(>= tenureMonths 0)

Sans ces règles limites, les contrôles de raisonnement automatisés peuvent envisager des scénarios avec des soldes de compte négatifs ou des cotes de crédit supérieures à 1 000, ce qui n'a aucun sens dans votre domaine. Les règles de limites sont l'un des rares cas où des assertions simples (règles non au format if-then) sont appropriées.

Utiliser des variables intermédiaires pour l'abstraction

Lorsque plusieurs règles partagent une condition commune, extrayez cette condition dans une variable booléenne intermédiaire. Cela simplifie vos règles et facilite la mise à jour de la politique.

Exemple : niveaux d'adhésion

Au lieu de répéter la condition d'adhésion dans chaque règle d'avantages :

;; Without intermediate variable (repetitive)
(=> (and (> purchaseTotal 1000) (> accountAge 12)) eligibleForFreeShipping)
(=> (and (> purchaseTotal 1000) (> accountAge 12)) eligibleForPrioritySupport)
(=> (and (> purchaseTotal 1000) (> accountAge 12)) eligibleForEarlyAccess)

Définissez une variable intermédiaire et référencez-la :

;; With intermediate variable (cleaner)
(=> (and (> purchaseTotal 1000) (> accountAge 12)) isPremiumMember)
(=> isPremiumMember eligibleForFreeShipping)
(=> isPremiumMember eligibleForPrioritySupport)
(=> isPremiumMember eligibleForEarlyAccess)

Ce modèle facilite la mise à jour ultérieure des critères d'adhésion : il suffit de modifier une règle au lieu de trois.

Utiliser des énumérations pour la catégorisation

Lorsqu'une variable représente une catégorie avec un ensemble fixe de valeurs mutuellement exclusives, utilisez un type personnalisé (enum) au lieu de plusieurs booléens ou d'une chaîne. Les énumérations limitent les valeurs possibles et clarifient les règles.

Conserver la logique déclarative et non procédurale

Les politiques de raisonnement automatisé décrivent ce qui est vrai, et non comment le calculer. Évitez d'écrire des règles qui ressemblent à du code comportant des étapes séquentielles ou une logique de priorité.

De même, évitez de coder la priorité ou la priorité entre les règles. Dans la logique formelle, toutes les règles s'appliquent simultanément. Si vous devez indiquer qu'une condition en remplace une autre, encodez-la explicitement dans les conditions de la règle :

;; GOOD: Explicit exception handling
;; General rule: full-time employees with 12+ months get parental leave
(=> (and isFullTime (> tenureMonths 12) (not isOnProbation))
    eligibleForParentalLeave)

;; BAD: Trying to encode precedence
;; "Rule 1 takes priority over Rule 2" — this concept doesn't exist
;; in formal logic. Instead, combine the conditions into a single rule.

Convention d'appellation

Une dénomination cohérente facilite la lecture, la maintenance et le débogage des politiques. Respectez les conventions suivantes :

Évitez les abréviations qui peuvent être ambiguës. Utilisez à la tenureMonths place detenMo, et isFullTime au lieu deft. Des noms clairs aident à la fois les réviseurs humains et le processus de traduction.

Anti-modèles courants

Les modèles suivants posent fréquemment des problèmes dans les politiques de raisonnement automatisé. Si vous obtenez des résultats de test inattendus, vérifiez si votre politique contient l'un de ces anti-modèles.

Des axiomes plutôt que des implications

Comme décrit dansUtiliser les implications (=>) pour structurer les règles, les assertions simples créent des axiomes toujours vrais. C'est l'anti-modèle le plus courant et le plus dommageable : il fait revenir IMPOSSIBLE des catégories entières d'entrées.

Symptôme : Tests qui devraient revenir VALID ou INVALID revenir à la IMPOSSIBLE place.

Correctif : trouvez des assertions simples dans vos règles et réécrivez-les sous forme d'implications, ou supprimez-les si elles ne représentent pas des conditions limites.

Variables qui se chevauchent

Le fait d'avoir deux variables représentant des concepts identiques ou similaires (par exemple, tenureMonths etmonthsOfService) perturbe le processus de traduction. Les contrôles de raisonnement automatisés ne peuvent pas déterminer la variable à utiliser pour un concept donné, ce qui entraîne des traductions et des TRANSLATION_AMBIGUOUS résultats incohérents.

Symptôme : les tests sont renvoyés TRANSLATION_AMBIGUOUS même si le texte saisi est clair et sans ambiguïté.

Correctif : Fusionnez les variables qui se chevauchent en une seule variable avec une description complète. Mettez à jour toutes les règles qui font référence à la variable supprimée.

Politiques trop complexes

Les politiques comportant trop de variables, des conditions profondément imbriquées ou une arithmétique non linéaire peuvent dépasser les limites de traitement et produire des résultats. TOO_COMPLEX

Symptôme : les tests TOO_COMPLEX réapparaissent ou expirent.

Correctif : Simplifiez la politique. Supprimez les variables inutilisées, divisez les règles complexes en règles plus simples à l'aide de variables intermédiaires et évitez l'arithmétique non linéaire (exposants, nombres irrationnels). Si votre domaine est réellement complexe, envisagez de le scinder en plusieurs politiques ciblées.

Des règles contradictoires

Les règles qui se contredisent empêchent les contrôles de raisonnement automatisés de parvenir à une conclusion. Par exemple, une règle indique que les employés à temps plein ont droit à un congé, tandis qu'une autre indique que les employés ne le sont pas au cours de leur première année, sans préciser ce qui arrive aux employés à temps plein au cours de leur première année.

Symptôme : les tests sont IMPOSSIBLE renvoyés pour les entrées impliquant des règles contradictoires.

Correctif : vérifiez que le rapport de qualité ne contient pas de règles contradictoires. Résolvez les conflits en fusionnant les règles en une seule règle assortie de conditions explicites, ou en supprimant l'une des règles en conflit. Pour de plus amples informations, veuillez consulter Passez en revue la politique extraite.

Variables non utilisées

Les variables qui ne sont référencées par aucune règle compliquent le processus de traduction. La traduction peut attribuer des valeurs à des variables inutilisées, gaspillant ainsi la capacité de traitement et pouvant entraîner des TRANSLATION_AMBIGUOUS résultats lorsque la variable inutilisée est en concurrence avec une variable active similaire.

Symptôme : TRANSLATION_AMBIGUOUS résultats inattendus ou traductions qui attribuent des valeurs à des variables qui n'affectent aucune règle.

Correctif : supprimez les variables inutilisées. Dans la console, recherchez les indicateurs d'avertissement à côté des variables. Via l'API, consultez le rapport de qualité à partir GetAutomatedReasoningPolicyBuildWorkflowResultAssets de--asset-type QUALITY_REPORT.

Valeurs d'énumération manquantes

Si votre énumération n'inclut pas de valeur pour chaque catégorie possible que les utilisateurs pourraient mentionner, la traduction peut échouer ou produire des résultats inattendus lorsque l'entrée ne correspond à aucune valeur définie.

Symptôme : les tests renvoient TRANSLATION_AMBIGUOUS ou NO_TRANSLATIONS lorsque l'entrée mentionne une catégorie ne figurant pas dans l'énumération.

Correctif : ajoutez une NONE valeur OTHER ou à votre énumération pour gérer les entrées qui ne correspondent pas aux catégories définies. Mettez à jour les descriptions des valeurs enum pour préciser quand chaque valeur s'applique.