Améliorez la précision en ajoutant des contrôles de raisonnement automatisés dans Amazon Bedrock Guardrails - Amazon Bedrock
Limites et considérationsBonnes pratiquesTarificationInférence interrégionale pour les opérations politiques

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.

Améliorez la précision en ajoutant des contrôles de raisonnement automatisés dans Amazon Bedrock Guardrails

Les contrôles de raisonnement automatisés dans Amazon Bedrock Guardrails vérifient mathématiquement le contenu en langage naturel par rapport à vos politiques définies, garantissant ainsi le strict respect de vos garde-fous. Ces contrôles peuvent aider à bloquer systématiquement le contenu préjudiciable ou non conforme avant qu'il ne parvienne à vos utilisateurs. Contrairement aux approches basées sur la correspondance de modèles, le raisonnement automatisé offre une plus grande précision avec moins de faux positifs, en particulier pour les exigences politiques complexes. Pour les clients qui privilégient la précision, les règles de politique peuvent être personnalisées afin d'améliorer l'efficacité des garde-fous grâce à des énoncés logiques clairs.

L'un des principaux défis des grands modèles linguistiques (LLMs) est de garantir l'exactitude de leurs réponses. Sans validation, cela LLMs peut parfois produire des hallucinations ou des informations inexactes qui minent la confiance.

Les contrôles de raisonnement automatisés dans Amazon Bedrock Guardrails résolvent ce problème en utilisant des techniques mathématiques pour :

  • Détecter les hallucinations dans les réponses LLM

  • Mettre en évidence les hypothèses non énoncées

  • Expliquez pourquoi les déclarations exactes sont correctes

Cette fonctionnalité est particulièrement utile lorsque vous devez démontrer le fondement factuel de la réponse d'un LLM dans :

  • Secteurs réglementés tels que les soins de santé et les ressources humaines

  • Demandes soumises à des règles complexes (approbations d'hypothèques, lois de zonage)

  • Scénarios de conformité nécessitant des réponses d'IA auditables

Les contrôles de raisonnement automatisés dans Amazon Bedrock Guardrails ne protègent pas contre les attaques par injection rapide. Ces contrôles valident exactement ce que vous leur envoyez. Si du contenu malveillant ou manipulé est fourni en entrée, la validation sera effectuée sur ce contenu tel quel (poubelle, sortie des déchets). Pour détecter et bloquer les attaques par injection rapide, utilisez des filtres de contenu en combinaison avec des contrôles de raisonnement automatisés.

Le raisonnement automatique analyse et détecte uniquement le texte pertinent par rapport à la politique de raisonnement automatique. Il ignorera le reste du contenu et ne pourra pas dire aux développeurs si la réponse est hors sujet ou non. Si vous devez détecter des réponses hors sujet, utilisez d'autres composants de protection tels que des politiques thématiques.

Note

Les contrôles de raisonnement automatisés dans Amazon Bedrock Guardrails sont généralement disponibles dans les régions des États-Unis (Virginie du Nord, Oregon et Ohio) et de l'UE (Francfort, Paris, Irlande).

Note

Les contrôles de raisonnement automatisés dans Amazon Bedrock Guardrails complètent les autres fonctionnalités d'Amazon Bedrock Guardrails, telles que les filtres de contenu et les politiques thématiques. Pour plus d'informations, consultez la section Composants du garde-corps.

CloudFormation n'est actuellement pas pris en charge. CloudFormation le support sera bientôt disponible.

Les contrôles de raisonnement automatisés dans Amazon Bedrock Guardrails ne sont actuellement disponibles qu'en anglais (États-Unis).

Les contrôles de raisonnement automatisés dans Amazon Bedrock Guardrails ne prennent pas en charge le streaming. APIs

Limites et considérations

Avant de mettre en œuvre des contrôles de raisonnement automatisés, soyez conscient de ces limites importantes :

  • Complexité du document : les documents sources doivent être bien structurés avec des règles claires et sans ambiguïté. Les documents très complexes comportant des conditions imbriquées ou des déclarations contradictoires peuvent ne pas être correctement extraits dans la logique formelle.

  • Temps de traitement : la validation automatique du raisonnement ajoute de la latence aux réponses de votre application. Prévoyez un délai de traitement supplémentaire, en particulier pour les politiques complexes comportant de nombreuses règles.

  • Champ d'application de la politique : chaque politique doit se concentrer sur un domaine spécifique (par exemple, les ressources humaines, les finances, le droit) plutôt que d'essayer de couvrir plusieurs domaines indépendants dans une seule politique.

  • Limites de variables : les politiques comportant un nombre excessif de variables ou des interactions entre règles trop complexes peuvent atteindre les limites de traitement ou renvoyer des résultats TOO_COMPLEX.

  • Dépendance au langage naturel : La précision de la validation dépend en grande partie de la capacité du langage naturel utilisé dans les instructions des utilisateurs et les réponses du modèle à être traduit en variables logiques formelles de votre politique.

Bonnes pratiques

Suivez ces bonnes pratiques pour optimiser l'efficacité de vos politiques de raisonnement automatisé :

  • Commencez simplement : commencez par une politique ciblée couvrant les règles fondamentales, puis ajoutez progressivement de la complexité. Effectuez des tests approfondis à chaque étape.

  • Rédigez des descriptions complètes des variables : indiquez comment les utilisateurs peuvent naturellement faire référence aux concepts, et pas seulement aux définitions techniques de votre document source.

  • Testez les cas extrêmes : créez des tests qui ciblent spécifiquement les conditions limites, les exceptions et les scénarios inhabituels auxquels vos utilisateurs pourraient être confrontés.

  • Surveillez les seuils de confiance : commencez par des seuils de confiance plus élevés (0,8-0,9) et ajustez-les en fonction de votre tolérance aux faux positifs par rapport aux faux négatifs.

  • Maintenance régulière des politiques : passez en revue et mettez à jour vos politiques à mesure que les règles commerciales changent ou que vous identifiez des lacunes grâce aux tests et à l'utilisation en production.

  • Documentez vos annotations : suivez les modifications des politiques et les raisons qui les sous-tendent pour référence future et pour partager les connaissances de l'équipe.

Tarification

Les contrôles de raisonnement automatisés dans Amazon Bedrock Guardrails sont facturés en fonction du nombre de demandes de validation traitées. Pour obtenir des informations sur les prix actuels, consultez la page de tarification d'Amazon Bedrock.

Des frais sont facturés pour chaque demande de validation, quel que soit le résultat (par exemple, VALID, INVALID, TRANSLATION_AMBIGUI). Pour optimiser les coûts :

  • Utilisez des seuils de confiance appropriés pour équilibrer la précision avec les exigences de traitement

  • Envisagez de mettre en cache les résultats de validation pour des requêtes identiques ou similaires, le cas échéant, selon votre cas d'utilisation

  • Surveillez les modèles d'utilisation et ajustez les politiques pour réduire les demandes de validation inutiles

Inférence interrégionale pour les opérations politiques

Le raisonnement automatisé utilise l'inférence entre régions pour optimiser les performances et la disponibilité des opérations de création et de test des politiques. Des opérations d'API spécifiques répartissent automatiquement le traitement entre les régions AWS situées à l'intérieur de votre zone géographique afin de garantir une prestation de service fiable.

Les opérations de l'API de raisonnement automatisé suivantes utilisent l'inférence entre régions :

  • StartAutomatedReasoningPolicyBuildWorkflow- Invoqué lors de la création et de la compilation des politiques à partir de documents sources

  • StartAutomatedReasoningPolicyTestWorkflow- Invoqué lors des procédures de validation et de test des politiques

Ces opérations font appel à de grands modèles linguistiques pour extraire des règles logiques formelles des documents sources et traduire les constructions du langage naturel en représentations logiques structurées. Pour garantir des performances et une disponibilité optimales, le traitement des demandes est réparti selon le routage géographique suivant :

  • Régions des États-Unis : les demandes d'API provenant de l'est des États-Unis (Virginie du Nord), de l'ouest des États-Unis (Oregon) ou de l'est des États-Unis (Ohio) peuvent être traitées dans toutes les régions des États-Unis prises en charge.

  • Régions de l'Union européenne : les demandes d'API provenant de l'UE (Francfort), de l'UE (Paris) ou de l'UE (Irlande) peuvent être traitées dans n'importe quelle région de l'UE prise en charge.

Important

Les données des clients restent dans la limite géographique d'origine (États-Unis d'Amérique ou Union européenne) et sont traitées conformément aux engagements d'AWS en matière de résidence des données. L'inférence interrégionale achemine les demandes exclusivement au sein de la même région géographique afin d'optimiser les performances et la disponibilité des services.

L'inférence entre régions fonctionne de manière transparente sans nécessiter de configuration client. Les fonctionnalités de l'API restent cohérentes quelle que soit la région spécifique qui traite la demande.

Pour utiliser les contrôles de raisonnement automatisés dans Amazon Bedrock Guardrails, procédez comme suit :

  1. Téléchargez un document source contenant les règles que vous souhaitez appliquer

  2. Passez en revue la politique extraite avec des concepts et des règles identifiés automatiquement

  3. Testez et affinez la politique pour vous assurer qu'elle fonctionne correctement

  4. Déployez la politique pour valider les réponses de votre modèle de base

Le flux de travail peut être visualisé comme suit :


Source Document → Extracted Policy → Testing → Deployment → Runtime Validation
    (rules)        (formal logic)    (verify)   (activate)    (check responses)

Politiques

Les politiques de raisonnement automatisé sont à la base de la validation de la précision. Elles contiennent des règles logiques et des variables qui sont automatiquement extraites de votre document source. Ces politiques servent de représentation mathématique de vos règles métier, permettant au système de valider systématiquement si les réponses du modèle de base sont conformes aux contraintes que vous avez définies. Pour effectuer des contrôles de raisonnement automatisés dans votre application, vous devez configurer votre garde-corps de manière à utiliser une politique qui correspond à votre domaine et à vos exigences de validation spécifiques.

Règles

Les règles sont une logique qu'Automated Reasoning extrait de votre document source. Elles peuvent être écrites sous forme de déclarations « if-then ». Voici quelques exemples de format de règle :

if <premise>, then <claim>

<premise> is true

Note

Important : les règles qui ne sont pas au format « si alors » peuvent avoir des conséquences imprévues en énonçant des axiomes sur le monde. Par exemple, si une règle indique simplementaccountBalance > 5, il devient impossible que le solde d'un compte soit inférieur ou égal à 5, indépendamment de ce que dit le contenu à valider. La règle a rendu logiquement impossible l'existence de cette condition. Cela peut entraîner des résultats de validation inattendus lorsque le contenu est incorrectement marqué comme non conforme car il contredit l'axiome établi par la règle. Pour éviter cela, structurez les règles sous forme d'instructions conditionnelles (format if-then) qui décrivent les relations plutôt que des contraintes absolues.

Variables

Les variables représentent des concepts de votre politique de raisonnement automatisé auxquels des valeurs peuvent être attribuées lors de la traduction du langage naturel en logique formelle. Vos règles de politique définissent les contraintes relatives aux valeurs valides ou non valides pour ces variables.

Les variables ont un nom, un type et une description. Par exemple, une politique concernant les avantages sociaux peut comporter une variable portant le nom « employee_age », le type « entier » et la description « L'âge de l'employé en années ». Une valeur telle que 25 peut être attribuée à cette variable en langage naturel dans une invite envoyée à une application.

Par exemple, une is_full_time variable d'une politique RH peut avoir une description indiquant « Employés travaillant plus de 20 heures par semaine », qui est une citation directe du document source. Lorsqu'ils utilisent un chatbot, les utilisateurs sont plus susceptibles de dire « je travaille à plein temps » et non « je travaille plus de 20 heures par semaine ».

La précision de la traduction du langage naturel vers la logique formelle dépend fortement de la qualité des descriptions variables. Bien que le processus de raisonnement soit valable une fois la traduction terminée, des descriptions de variables claires et complètes garantissent que les instructions de l'utilisateur sont correctement interprétées. Sans descriptions complètes des variables, le raisonnement automatisé peut NO_DATA réapparaître car il ne peut pas traduire le langage naturel d'entrée en sa représentation logique formelle.

Il est important qu'une description de variable tienne compte de tels scénarios. Une description complète des variables peut indiquer : « Les employés qui travaillent plus de 20 heures par semaine travaillent à plein temps. Les utilisateurs diront « plein temps » pour définir cette valeur sur « vrai », ou « temps partiel » pour la définir sur « faux ».

Types de variables prédéfinis

Le tableau suivant décrit les types prédéfinis de variables que votre politique peut avoir.

Type Description

bool

Les variables booléennes peuvent être vraies ou fausses. Par exemple, dans une politique de congé, vous utiliseriez une bool variable pour déterminer si le congé est autorisé ou non.

int

intLes variables numériques peuvent stocker des nombres entiers positifs ou négatifs. Par exemple, dans une politique de congé, vous utiliseriez une int variable pour stocker les jours de vacances accumulés si les fractions de jours ne sont pas autorisées.

real

realLes variables numériques peuvent stocker des nombres positifs ou négatifs qui nécessitent une précision décimale. Par exemple, dans une politique de congé, vous utiliseriez une real variable pour enregistrer le montant du paiement en dollars pour les jours de vacances non utilisés.

enum

Les variables Enum peuvent stocker une valeur unique sélectionnée parmi un ensemble d'options fixes. Par exemple, dans une politique de congé, vous pouvez utiliser une variable enum pour stocker le type de congé : (1) Vacances payées ; (2) Temps personnel ; (3) Congé

Vous pouvez également créer des types d'énumération personnalisés définis par l'utilisateur qui fournissent un contexte supplémentaire au-delà des types de variables prédéfinis. Ces types personnalisés vous permettent de définir des ensembles de valeurs spécifiques correspondant à votre domaine de politique.
Rubriques