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

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é.

Un test inclut les informations suivantes :

  • Requête et contenu : une question qu'un utilisateur pourrait poser à votre application GenAI et une 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_AMBIGUI, 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 validation :

    • Résultat attendu : le 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 concordent, 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 affirmations factuelles contenues dans la question et la réponse de votre test. Utilisez-les pour comprendre pourquoi un test a réussi ou échoué.

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

      • Prémisses : fournit le contexte, les hypothèses ou les conditions qui influent sur la façon dont une réclamation 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 répondez, « 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 Automated Reasoning. Dans un question-and-answer format, la réclamation est généralement la réponse. Dans une déclaration indépendante, la réclamation est le fait affirmé. Par exemple, dans la question « Quels nombres sont divisibles par 2 ? » et répondez « nombres pairs », l'affirmation est « nombres pairs ».

    • Résultat : indique la validité des affirmations d'une constatation. Pour de plus amples informations, veuillez consulter Résultats de validation des tests.

    • Confiance : le 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 validation des tests

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

VALID

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

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 puisque vous travaillez ici depuis 18 mois », cela sera VALIDE car 18 mois dépassent l'exigence d'un an.

INVALID

Les affirmations 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 réclamations 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 SATISFIABLE car la réponse répond correctement aux exigences de service mais ne mentionne pas l'exigence de forme (sans la contredire).

IMPOSSIBLE

Automated Reasoning ne peut pas faire de déclaration au sujet des réclamations. Cela peut se produire si les prémisses sont logiquement incorrectes 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 « Quels sont les avantages dont bénéficient les employés s'ils travaillent des heures négatives ? » , 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 TRANSLATION_AMBIGUU 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 qu'Automated Reasoning 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 TOO_COMPLEX car l'analyse logique dépasserait les délais de traitement.

NO_TRANSLATIONS

Identifie qu'une partie ou la totalité de l'invite de saisie 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 NO_TRANSLATIONS résultat 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 NO_TRANSLATIONS car le contenu n'est absolument pas lié au domaine et aux variables de votre politique.