Validez les résultats des tests de votre politique de raisonnement automatisé - Amazon Bedrock
Résultats de la validation du test

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.

Validez les résultats des tests de votre politique de raisonnement automatisé

À la fin d’un test, vous recevez un ensemble de résultats de validation pour comprendre les performances de votre politique de raisonnement automatisé.

Chaque étape contient les informations suivantes :

  • Requête et contenu : question qu’un utilisateur pourrait poser à votre application GenAI et réponse possible. Vous les définissez si vous créez le test manuellement. Le raisonnement automatisé les définit si vous avez généré des scénarios de test.

  • Seuil de confiance : niveau de confiance minimal pour la validation logique que vous avez défini pour votre test. Ce seuil détermine la manière dont le raisonnement automatisé gère l’incertitude lors de la traduction du langage naturel en logique formelle. Le contenu qui atteint ou dépasse le seuil est considéré comme un résultat à haut niveau de confiance qui peut être validé avec un résultat définitif (VALIDE ou INVALIDE). Le contenu inférieur au seuil est un résultat peu fiable marqué comme TRANSLATION_AMBIGUOUS, indiquant que le système a détecté une ambiguïté et a choisi de ne pas fournir de résultat de validation potentiellement incorrect.

  • Résultats de la validation :

    • Résultat attendu : résultat que vous attendez de l’exécution du test.

    • Résultat réel : résultat de l’exécution du test.

    • Résultat de l’exécution : indique si le test a réussi. Si les résultats attendus et réels correspondent, le test est réussi. Dans le cas contraire, le test a échoué.

  • Résultats : le résultat d’un test de politique de raisonnement automatisé est un ensemble de résultats. Les résultats représentent des demandes factuelles contenues dans la question et la réponse de votre test. Utilisez-les pour vous aider à comprendre pourquoi un test a réussi ou échoué.

    • Type : Les traductions peuvent inclure une combinaison de demandes et de prémisses.

      • Prémisses : fournit le contexte, les hypothèses ou les conditions qui influent sur la façon dont une demande doit être évaluée. Dans les question-and-answer formats, la prémisse est souvent la question elle-même. Les réponses peuvent également contenir des prémisses qui établissent des contraintes ou des conditions. Par exemple, dans la question « Quels nombres sont divisibles par 2 ? » et la réponse, « Nombres pairs », le principe est « nombres divisibles par 2 ». Dans la déclaration, « Quand le feu passe au vert, vous devez y aller », on lit que « le feu de signalisation est vert ».

      • Réclamations : déclarations factuelles dont l’exactitude est évaluée par le raisonnement automatisé. Dans un question-and-answer format, la réclamation est généralement la réponse. Dans une instruction autonome, la demande est le fait affirmé. Par exemple, dans la question « Quels nombres sont divisibles par 2 ? » et la réponse « nombres pairs », la demande est « nombres pairs ».

    • Résultat : indique la validité des demandes d’un résultat. Pour de plus amples informations, veuillez consulter Résultats de la validation du test.

    • Confiance : score de confiance (compris entre 0,0 et 1,0) attribué au raisonnement automatisé lors de la traduction du langage naturel vers la logique formelle, représentant le degré de certitude du système quant à l’interprétation correcte du texte saisi. Des scores plus élevés indiquent une plus grande certitude dans la traduction. Par exemple, si le niveau de confiance d’une traduction est de « 1,0 », cela indique une certitude maximale que le langage naturel a été correctement converti en logique formelle. Des scores de confiance plus faibles indiquent que le système présente une certaine incertitude quant à la traduction que vous souhaitez peut-être réviser.

    • Affectations : affectations de variables issues de votre politique qui prouvent que le résultat est valide ou non. Les traductions comportent des énoncés logiques qui montrent comment le langage naturel a été converti en logique formelle. Elles peuvent être plus complexes lorsqu’il existe une logique imbriquée. Par exemple, hasDogHistoryOfAggression is false.

    • Règles : logique extraite de votre politique qui soutient le résultat. Un test vous fournit suffisamment de règles pertinentes issues de votre police pour vous aider à comprendre le résultat du résultat.

Résultats de la validation du test

La liste suivante détaille les résultats de validation possibles d’un test de politique de raisonnement automatisé :

VALID

Les prémisses et affirmations contenues dans la réponse du modèle sont logiquement cohérentes avec les règles de votre politique, peuvent être mathématiquement prouvées correctes et ne peuvent être réfutées en utilisant aucune des règles de la politique. La réponse suit correctement toutes les contraintes logiques applicables et le raisonnement, des prémisses aux demandes, est solide.

Exemple : Si votre police contient une seule règle stipulant que « Les employés ayant plus d'un an de service bénéficient d'un congé parental » et que le modèle répond « Vous êtes éligible au congé parental puisque vous travaillez ici depuis 18 mois », cette règle sera VALIDE car 18 mois dépassent l'exigence d'un an.

Note

VALIDgarantit la validité uniquement de certaines parties des données saisies par le biais de variables politiques dans les prémisses et les affirmations du VALID résultat. Par exemple, la déclaration « Je peux soumettre mes devoirs en retard parce que j'ai une fausse note du médecin » peut être considérée comme valide car la politique ne contient aucune variable permettant de déterminer si la note du médecin est fausse ou non. Dans certains cas, les contrôles de raisonnement automatisés peuvent être en mesure de signaler ces déclarations comme des prémisses non traduites ou des affirmations figurant dans le résultat.

INVALID

Les demandes contenues dans la réponse du modèle contredisent ou enfreignent les règles de votre politique. La réponse contient des instructions dont il est mathématiquement prouvé qu’elles sont incorrectes sur la base des contraintes logiques formelles de votre politique.

Exemple : si votre politique stipule que « Les employés ayant plus d’un an de service bénéficient d’un congé parental » et que le modèle répond « Vous êtes éligible au congé parental même si vous ne travaillez ici que depuis 3 mois », cela ne sera pas valide, car 3 mois ne répondent pas à l’exigence d’un an.

SATISFIABLE

Les demandes sont conformes à au moins une interprétation possible des règles de votre police, mais elles peuvent ne pas couvrir toutes les règles pertinentes. Cela signifie que la réponse ne contredit pas votre politique, mais elle risque de ne pas répondre pleinement à toutes les contraintes applicables.

Exemple : si votre politique stipule que « les employés ont besoin d’au moins un an de service pour le congé parental ET doivent soumettre le formulaire HR-101 » et que le modèle répond « Vous êtes éligible au congé parental puisque vous travaillez ici depuis 2 ans », cela serait SATISFAISANT, car la réponse répond correctement aux exigences de service mais ne mentionne pas l’exigence de forme (sans la contredire).

IMPOSSIBLE

Le raisonnement automatisé ne peut pas créer d’instruction concernant des demandes. Cela peut se produire si les prémisses sont en conflit les unes avec les autres, ou s'il existe un conflit au sein de la politique de raisonnement automatisé elle-même.

Exemple : si votre politique contient des règles contradictoires telles que « Tous les employés ont des jours de vacances » et « Aucun employé n'a de jours de vacances », ou si la question du test contient des prémisses impossibles telles que « Je suis un employé à plein temps et également à temps partiel, à quels avantages suis-je éligible ? » , le résultat serait IMPOSSIBLE car le fondement logique est imparfait.

TRANSLATION_AMBIGUOUS

La détection d’une ambiguïté dans la traduction signifiait qu’il ne serait pas judicieux de poursuivre le contrôle de validité. Des questions contextuelles ou de suivi supplémentaires peuvent être nécessaires pour que la traduction soit une réussite.

Exemple : si votre question de test est « Peuvent-ils prendre un congé ? » sans spécifier à qui « ils » font référence, ou si la réponse du modèle utilise des pronoms ambigus tels que « Cela dépend de leur situation » sans référents clairs, le résultat serait TRADUCTION_AMBIGUE, car le système ne peut pas traduire de manière fiable le langage vague en logique formelle.

TOO_COMPLEX

L’entrée contient trop d’informations pour que raisonnement automatisé puisse les traiter dans ses limites de latence.

Exemple : si votre test inclut une réponse de modèle extrêmement longue contenant des centaines de réclamations interconnectées concernant les avantages sociaux, les politiques de vacances, l’assurance maladie, les plans de retraite et les évaluations de performance dans une seule réponse, le résultat peut être TROP_COMPLEXE, car l’analyse logique dépasserait les délais de traitement.

NO_TRANSLATIONS

Identifie qu’une partie ou la totalité de l’invite d’entrée n’a pas été traduite en logique. Cela peut se produire si l’entrée n’est pas pertinente pour la politique de raisonnement automatisé, ou si la politique ne contient pas de variables pour modéliser les entrées pertinentes. Si le raisonnement automatisé ne peut rien traduire, vous obtenez un résultat NO_TRANSLATIONS unique. Vous pouvez également voir un NO_TRANSLATIONS (ainsi que d’autres résultats) si une partie de la validation n’est pas traduite.

Exemple : si votre politique RH est conçue pour valider les avantages sociaux des employés, mais que votre question test demande « Quel temps fait-il aujourd’hui ? » ou « Comment faire cuire les pâtes ? », le résultat serait AUCUNE_TRADUCTION, car le contenu n’est absolument pas lié au domaine et aux variables de votre politique.