Amélioration de la précision en ajoutant des vérifications du raisonnement automatisé dans les barrières de protection Amazon Bedrock - Amazon Bedrock
Limites et considérationsBonnes pratiquesTarificationInférence entre régions pour les opérations de la stratégieStratégiesRulesVariables

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élioration de la précision en ajoutant des vérifications du raisonnement automatisé dans les barrières de protection Amazon Bedrock

Les vérifications du raisonnement automatisé dans les barrières de protection Amazon Bedrock vérifient mathématiquement le contenu en langage naturel par rapport à vos stratégies définies, garantissant ainsi le strict respect de vos barrières de protection. Ces vérifications peuvent aider à bloquer systématiquement les contenus préjudiciables ou non conformes avant qu’ils n’atteignent vos utilisateurs. Contrairement aux approches de mise en correspondance de modèles, le raisonnement automatisé offre une plus grande précision avec moins de faux positifs, en particulier pour les exigences de stratégie complexes. Pour les clients qui privilégient la précision, les règles de stratégie peuvent être personnalisées afin d’améliorer l’efficacité des barrières de protection grâce à des instructions logiques claires.

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 vérifications du raisonnement automatisé dans les barrières de protection Amazon Bedrock résolvent ce problème en utilisant des techniques mathématiques pour :

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

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

  • Expliquer pourquoi les instructions 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

  • Applications soumises à des règles complexes (approbations d’hypothèques, lois sur le zonage)

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

Les vérifications du raisonnement automatisé dans les barrières de protection Amazon Bedrock ne protègent pas contre les attaques par injection d’invite. Ces vérifications 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 (garbage-in, garbage-out). Pour détecter et bloquer les attaques par injection d’invite, utilisez des filtres de contenu en combinaison avec les vérifications du raisonnement automatisé.

Le raisonnement automatisé analyse et détecte uniquement le texte pertinent par rapport à la politique de raisonnement automatisé. 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 des barrières de protection tels que les stratégie de rubrique.

Note

Les vérifications du raisonnement automatisé dans les barrières de protection Amazon Bedrock sont généralement disponibles dans des régions des États-Unis (Virginie du Nord, Oregon et Ohio) et de l’UE (Francfort, Paris, Irlande).

Note

Les vérifications du raisonnement automatisé dans les barrières de protection Amazon Bedrock complètent les autres fonctionnalités des barrières de protection Amazon Bedrock, telles que les filtres de contenu et les stratégies de rubrique. Pour plus d’informations, consultez Composants des barrières de protection.

Les vérifications du raisonnement automatisé dans les barrières de protection Amazon Bedrock 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 vérifications du raisonnement automatisé, 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 instructions contradictoires peuvent ne pas être correctement extraits dans la logique formelle. La taille des documents d'entrée est limitée à 5 Mo et 50 000 caractères. Vous pouvez diviser des documents plus volumineux et fusionner chaque section dans votre politique. Les images et les tableaux des documents ont également un impact sur le nombre de caractères de saisie.

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

  • Portée de la stratégie : chaque stratégie 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 stratégie.

  • Limites de variable : les stratégies 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 invites utilisateur et les réponses du modèle à être traduit en variables logiques formelles de votre stratégie.

  • Arithmétique non linéaire : les contrôles de raisonnement automatisés peuvent expirer ou renvoyer TOO_COMPLEX si les contraintes impliquent un raisonnement arithmentique non linéaire (par exemple, des nombres irrationnels ou des exposants)

Bonnes pratiques

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

  • Commencez simplement : commencez par une stratégie 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 de périphérie : 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 stratégies : passez en revue et mettez à jour vos stratégies à 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 stratégies et les raisons qui les sous-tendent pour référence future et pour partager les connaissances d’équipe.

Tarification

Les vérifications du raisonnement automatisé dans les barrières de protection Amazon Bedrock sont facturées en fonction du nombre de demandes de validation traitées. Pour obtenir des informations sur la tarification actuelle, consultez la page Tarification Amazon Bedrock.

Des frais sont facturés pour chaque demande de validation, quel que soit le résultat (par exemple, VALID, INVALID, TRANSLATION_AMBIGUOUS). Afin d’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 stratégies pour réduire les demandes de validation inutiles

Inférence entre régions pour les opérations de la stratégie

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 de la stratégie. 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 services fiable.

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

  • StartAutomatedReasoningPolicyBuildWorkflow : invoqué lors de la création et de la compilation des stratégies à partir de documents sources

  • StartAutomatedReasoningPolicyTestWorkflow : invoqué lors des procédures de validation et de test des stratégies

Ces opérations invoquent de grands modèles de langage pour extraire des règles logiques formelles des documents sources et traduire les constructions de 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 USA Est (Virginie du Nord), USA Ouest (Oregon) ou USA Est (Ohio) peuvent être traitées dans n’importe quelle région des États-Unis prise en charge.

  • Régions de l’Union européenne : les demandes d’API provenant de UE (Francfort), UE (Paris) ou 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 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 entre régions 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 vérifications du raisonnement automatisé dans les barrières de protection Amazon Bedrock, procédez comme suit :

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

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

  3. Testez et affinez la stratégie pour vous assurer qu’elle fonctionne correctement

  4. Déployez la stratégie pour valider les réponses de votre modèle de fondation

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


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

Stratégies

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 stratégies servent de représentation mathématique de vos règles commerciales, permettant au système de valider systématiquement si les réponses du modèle de fondation sont conformes aux contraintes que vous avez définies. Pour effectuer des vérifications du raisonnement automatisé dans votre application, vous devez configurer votre barrière de protection de manière à utiliser une stratégie qui correspond à votre domaine et à vos exigences de validation spécifiques.

Rules

Les règles sont une logique que le raisonnement automatisé extrait de votre document source. Elles peuvent être écrites sous forme d’instructions « if-then ». Voici quelques exemples de format de règle :

<claim> is true if <premise>

Note

Important : les règles qui ne sont pas au format « if-then » peuvent avoir des conséquences imprévues en énonçant des axiomes sur le monde. Par exemple, si une règle indique simplement accountBalance > 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. Les règles de votre stratégie 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 stratégie concernant les avantages sociaux peut comporter une variable portant le nom « employee_age », le type « integer » 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 variable is_full_time 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 en logique formelle dépend fortement de la qualité des descriptions de variables. Bien que le processus de raisonnement soit solide une fois la traduction terminée, des descriptions de variables claires et complètes garantissent que les invites utilisateur sont correctement interprétées. Sans descriptions complètes des variables, le raisonnement automatisé peut renvoyer NO_DATA, 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 true ou temps partiel pour la définir sur false. »

Types de variables prédéfinies

Le tableau ci-dessous décrit les types de variables prédéfinies que votre stratégie peut comporter.

Type Description

BOOL

Les variables booléennes peuvent être true ou false. Par exemple, dans une stratégie de congé, vous utiliseriez une variable BOOL pour déterminer si le congé est autorisé ou non.

INT

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

NOMBRE

NUMBERles variables peuvent stocker des nombres positifs ou négatifs qui nécessitent une précision décimale. Par exemple, dans une stratégie de congé, vous utiliseriez une variable NUMBER pour enregistrer le montant du paiement en euros pour les jours de vacances non utilisés.

enum

Les variables Enum sont des types définis par l'utilisateur qui peuvent stocker une valeur unique sélectionnée parmi un ensemble d'options fixes définies dans un type personnalisé. Par exemple, dans une politique de congé, vous pouvez utiliser une variable enum pour stocker LeaveType : (1) les vacances payées ; (2) le temps personnel ; (3) les congés. Ces types personnalisés vous permettent de définir des ensembles de valeurs spécifiques correspondant au domaine de votre stratégie. Les noms de type Enum ne doivent pas entrer en conflit avec les types par défaut tels que INT ouBOOL.
Rubriques