Vérification contextuelle de la mise à la terre - 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.

Vérification contextuelle de la mise à la terre

Guardrails for Amazon Bedrock prend en charge la vérification contextuelle de base afin de détecter et de filtrer les hallucinations dans les réponses des modèles lorsqu'une source de référence et une requête utilisateur sont fournies. Les cas d'utilisation pris en charge concernent la génération augmentée par extraction (RAG), la synthèse, la paraphrase ou les agents conversationnels qui s'appuient sur une source de référence telle que les passes récupérées dans RAG ou l'historique des conversations pour que les agents puissent fonder les conversations.

La vérification contextuelle des fondements permet d'évaluer les hallucinations selon deux paradigmes :

  • Mise à la terre — Cela vérifie si la réponse du modèle est factuellement précise en fonction de la source et si elle est fondée sur la source. Toute nouvelle information introduite dans la réponse sera considérée comme non fondée.

  • Pertinence : permet de vérifier si la réponse du modèle correspond à la requête de l'utilisateur.

Prenons un exemple où la source de référence contient « Londres est la capitale du Royaume-Uni. Tokyo est la capitale du Japon » et la question de l'utilisateur est « Quelle est la capitale du Japon ? ». Une réponse telle que « Londres est la capitale du Japon » sera considérée comme non fondée et factuellement incorrecte, tandis qu'une réponse telle que « Londres est la capitale du Royaume-Uni » sera considérée comme non pertinente, même si elle est correcte et fondée sur la source.

Scores et seuils de confiance

La vérification contextuelle de la base génère des scores de confiance correspondant à la base et à la pertinence pour chaque réponse du modèle traitée en fonction de la source et de la requête utilisateur fournies. Vous pouvez configurer des seuils pour filtrer les réponses du modèle en fonction des scores générés. Le seuil de filtrage détermine le score de confiance minimum autorisé pour que la réponse du modèle soit considérée comme fondée et pertinente dans votre application d'IA générative. Par exemple, si votre seuil de base et votre seuil de pertinence sont chacun fixés à 0,7, toutes les réponses du modèle dont le score de base ou de pertinence est inférieur à 0,7 seront détectées comme des hallucinations et bloquées dans votre application. À mesure que le seuil de filtrage augmente, la probabilité de bloquer le contenu non fondé et non pertinent augmente, et la probabilité de voir du contenu halluciné dans votre application diminue. Vous pouvez configurer des valeurs seuils de base et de pertinence comprises entre 0 et 0,99. Un seuil de 1 n'est pas valide car cela bloquera tout le contenu.

La vérification contextuelle de la mise à la terre nécessite 3 composants pour effectuer la vérification : la source de mise à la terre, la requête et le contenu à protéger (ou la réponse du modèle). Elles sont configurées différemment selon que vous utilisez les API Invoke, les API Converse ou ApplyGuardrail directement.

  • Source de base : informations contextuelles nécessaires pour répondre à toutes les requêtes des utilisateurs. Par exemple, « Londres est la capitale du Royaume-Uni. Tokyo est la capitale du Japon ».

  • Requête : question qu'un utilisateur peut poser. Par exemple, « Quelle est la capitale du Japon ? ».

  • Contenu à protéger : texte qui doit être protégé par rapport à la source et à la requête de base. Pour les API Invoke et Converse, il s'agit du modèle de réponse. Par exemple, cela peut être « La capitale du Japon est Tokyo ».

Exemple non fondé

  • Source de base - « Londres est la capitale du Royaume-Uni. Tokyo est la capitale du Japon. »

  • Question - « Quelle est la capitale du Japon ? »

  • Contente de garder : « La capitale du Japon est Londres. »

Dans cet exemple, le contenu à protéger est pertinent pour la requête mais n'est pas fondé car il n'utilise pas correctement la source de base. Cela aurait un faible score de base.

Exemple non pertinent

  • Source de base - « Londres est la capitale du Royaume-Uni. Tokyo est la capitale du Japon. »

  • Question - « Quelle est la capitale du Japon ? »

  • Contente de garder : « La capitale du Royaume-Uni est Londres ».

Dans cet exemple, le contenu à protéger est fondé mais n'est pas pertinent. Il utilise les informations de la source de base mais ne répond pas à la requête. Cela aurait un faible score de pertinence.

Exemple non fondé et non pertinent

  • Source de base - « Londres est la capitale du Royaume-Uni. Tokyo est la capitale du Japon. »

  • Question - « Quelle est la capitale du Japon ? »

  • Contente de garder : « Il pleut dehors. »

Dans cet exemple, le contenu à protéger n'est pas fondé et n'est pas pertinent. Il n'utilise pas les informations de la source de base et ne répond pas à la requête. Cela aurait un faible score de base et de pertinence.

Plus d'exemples

Envisagez une application bancaire conçue pour répondre aux questions relatives aux frais et aux charges.

La source :

  • Il n'y a aucun frais associé à l'ouverture d'un compte courant.

  • Les frais mensuels pour le maintien d'un compte courant sont de 10$.

  • Des frais de transaction de 1 % sont facturés pour les virements internationaux.

  • Aucuns frais ne sont associés aux transferts nationaux.

  • Les frais associés aux retards de paiement d'une facture de carte de crédit s'élèvent à 23,99 %.

Sur la base de la source ci-dessus, il peut y avoir quatre scénarios en fonction de la requête de l'utilisateur.

Fondé et pertinent

  • Q : Quels sont les frais associés au compte courant ?

  • R : Les frais mensuels pour le maintien d'un compte courant sont de 10$. Aucuns frais ne sont associés aux transferts nationaux. Toutefois, des frais de transaction de 1 % s'appliquent aux virements internationaux. Il n'y a aucun frais associé à l'ouverture d'un compte courant.

Non fondé mais pertinent

  • Q : Quels sont les frais de transaction associés à la carte de crédit ?

  • R : Les frais de transaction associés à la carte de crédit sont de 23,99 %.

Fondé mais hors de propos

  • Q : Quels sont les frais d'utilisation d'un compte bancaire courant ?

  • R : Sur la base des informations fournies, les frais de retard pour paiement par carte de crédit sont de 23,99 %.

Non fondé et hors de propos

  • Q : Quels sont les frais d'utilisation d'un compte bancaire courant ?

  • R : Les frais du compte de courtage sont de 0,5$ par transaction de négociation.

Appel d'une vérification contextuelle de mise à la base avec les API Invoke

Pour marquer la source et la requête de base dans l'entrée, nous fournissons 2 balises qui fonctionnent de la même manière que les balises d'entrée. Ces balises sont amazon-bedrock-guardrails-groundingSource_xyz et amazon-bedrock-guardrails-query_xyz en supposant que le suffixe de balise est xyz. Par exemple :

{ "text": """ <amazon-bedrock-guardrails-groundingSource_xyz>London is the capital of UK. Tokyo is the capital of Japan. </amazon-bedrock-guardrails-groundingSource_xyz> <amazon-bedrock-guardrails-query_xyz>What is the capital of Japan?</amazon-bedrock-guardrails-query_xyz> """, "amazon-bedrock-guardrailConfig": { "tagSuffix": "xyz", }, }

Notez que la réponse du modèle est requise pour effectuer la vérification contextuelle de mise à la terre. La vérification ne sera donc effectuée qu'en sortie et non à l'invite.

Ces balises peuvent être utilisées conjointement avec les balises GuardContent. Si aucune balise GuardContent n'est utilisée, le garde-corps appliquera par défaut toutes les politiques configurées sur l'ensemble de l'entrée, y compris la source et la requête de base. Si les balises GuardContent sont utilisées, la politique de vérification contextuelle du fondement étudiera uniquement la source, la requête et la réponse, tandis que les politiques restantes étudieront le contenu des balises GuardContent.

Appel à une vérification contextuelle de la base avec les API Converse

Pour marquer la source de base et la requête des API Converse, utilisez le champ des qualificatifs dans chaque bloc de contenu de protection. Par exemple :

[ { "role": "user", "content": [ { "guardContent": { "text": { "text": "London is the capital of UK. Tokyo is the capital of Japan", "qualifiers": ["grounding_source"], } } }, { "guardContent": { "text": { "text": "What is the capital of Japan?", "qualifiers": ["query"], } } }, ], } ]

Notez que la réponse du modèle est requise pour effectuer la vérification contextuelle de mise à la terre. La vérification ne sera donc effectuée qu'en sortie et non à l'invite.

Si aucun des blocs de contenu n'est marqué avec le qualificatif guard_content, la politique de vérification contextuelle étudiera uniquement la source, la requête et la réponse de base. Les autres politiques suivront le comportement d'investigation par défaut : le système indique par défaut de ne pas faire l'objet d'une enquête et les messages indiquent par défaut qu'il fait l'objet d'une enquête. Si, toutefois, un bloc de contenu est marqué avec le qualificatif guard_content, la politique de vérification contextuelle étudiera uniquement la source, la requête et la réponse, tandis que les politiques restantes étudieront le contenu marqué par les balises GuardContent.

Appel d'une vérification contextuelle de mise à la base avec l'API ApplyGuardrail

L'utilisation de la vérification contextuelle de la base avec ApplyGuardrail est similaire à son utilisation avec les API Converse. Pour marquer la source de base et la rechercher ApplyGuardrail, utilisez le champ des qualificatifs dans chaque bloc de contenu. Cependant, étant donné qu'aucun modèle n'est invoqué avec ApplyGuardrail, vous devez également fournir un bloc de contenu supplémentaire contenant le contenu à protéger. Ce bloc de contenu peut être éventuellement qualifié par guard_content et est équivalent à la réponse du modèle dans les API Invoke* ou Converse*. Par exemple :

[ { "text": { "text": "London is the capital of UK. Tokyo is the capital of Japan", "qualifiers": [ "grounding_source" ] } }, { "text": { "text": "What is the capital of Japan?", "qualifiers": [ "query" ] } }, { "text": { "text": "The capital of Japan is Tokyo." } } ]

Notez que la réponse du modèle est requise pour effectuer la vérification contextuelle de mise à la terre. La vérification ne sera donc effectuée qu'en sortie et non à l'invite.

Si aucun des blocs de contenu n'est marqué avec le qualificatif guard_content, la politique de vérification contextuelle étudiera uniquement la source, la requête et la réponse de base. Les autres politiques suivront le comportement d'investigation par défaut : le système indique par défaut de ne pas faire l'objet d'une enquête et les messages indiquent par défaut qu'il fait l'objet d'une enquête. Si, toutefois, un bloc de contenu est marqué avec le qualificatif guard_content, la politique de vérification contextuelle étudiera uniquement la source, la requête et la réponse, tandis que les politiques restantes étudieront le contenu marqué par les balises GuardContent.

Pour plus d'informations sur la vérification contextuelle de mise à la terre, voir Utiliser la vérification de mise à la terre contextuelle.