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.

Utilisation du contrôle d’ancrage contextuel pour filtrer les hallucinations dans les réponses

Les barrières de protection Amazon Bedrock prennent en charge les contrôles d’ancrage contextuel pour détecter et filtrer les hallucinations dans les réponses du modèle lorsqu’une source de référence et une requête utilisateur sont fournies. Les cas d'utilisation pris en charge incluent la synthèse, la paraphrase et la réponse aux questions telles que définies dans la discipline informatique. (Les cas d'utilisation de l'assurance qualité conversationnelle/chatbot ne sont pas pris en charge.)

Les contrôles d’ancrage contextuel vérifient la pertinence de chaque fragment traité. Si un élément est jugé pertinent, l'ensemble de la réponse est considéré comme pertinent car il contient la réponse à la requête de l'utilisateur. Pour l’API de streaming, cela peut entraîner un scénario dans lequel une réponse non pertinente est renvoyée à l’utilisateur et n’est marquée comme non pertinente qu’une fois la réponse complète diffusée.

La mise à la base contextuelle vérifie les paradigmes suivants :

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.

Seuils et scores de confiance

Les contrôle d’ancrage contextuel génèrent des scores de confiance correspondant à l’ancrage 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 ancrée et pertinente dans votre application d’IA générative. Par exemple, si votre seuil d’ancrage et votre seuil de pertinence sont chacun fixés à 0,7, toutes les réponses du modèle dont le score d’ancrage 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 ancré et non pertinent augmente, et la probabilité de voir du contenu halluciné dans votre application diminue. Vous pouvez configurer des valeurs de seuils d’ancrage et de pertinence comprises entre 0 et 0,99. Un seuil de 1 n’est pas valide, car cela bloquera tout le contenu.

Les contrôles d’ancrage contextuel nécessitent trois composants pour effectuer la vérification : la source d’ancrage, la requête et le contenu à surveiller (ou la réponse du modèle). Ils sont configurés différemment selon que vous utilisez les API Invoke, Converse ou ApplyGuardrail directement.

Exemple non ancré

Dans cet exemple, le contenu à surveiller est pertinent pour la requête, mais n’est pas ancré, car il n’utilise pas correctement la source d’ancrage. Il en résulterait un faible score d’ancrage.

Exemple non pertinent

Dans cet exemple, le contenu à surveiller est ancré, mais n’est pas pertinent. Il utilise les informations de la source d’ancrage, mais ne répond pas à la requête. Il en résulterait un faible score de pertinence.

Exemple non ancré et non pertinent

Dans cet exemple, le contenu à surveiller n’est pas ancré et n’est pas pertinent. Il n’utilise pas les informations de la source d’ancrage ni ne répond à la requête. Il en résulterait un faible score d’ancrage et de pertinence.

Exemples supplémentaires

Imaginez une application bancaire conçue pour répondre aux questions relatives aux frais.

Source :

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

Ancré et pertinent

Un-grounded mais pertinent

Ancré, mais non pertinent

Un-grounded et non pertinent

Ajout de contrôles d’ancrage contextuel via la console

Appel d’un contrôle d’ancrage contextuel avec les API Invoke

Pour marquer la source et la requête de base dans l'entrée, utilisez les balises suivantes qui fonctionnent de la même manière que les balises d'entrée. Ces balises sont amazon-bedrock-guardrails-groundingSource_xyz etamazon-bedrock-guardrails-query_xyz, où se xyz trouve le suffixe de balise. 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 les contrôles d’ancrage contextuel. Ceux-ci ne seront donc effectués qu’en sortie et non à l’invite.

Ces balises peuvent être utilisées en même temps que les guardContent balises. Le contenu contenu groundingSource et les query balises sont exclus des évaluations des politiques autres que celles liées au contexte (filtres de mots, filtres de sujets, filtres de contenu, détection d'informations sensibles).

Le comportement des autres politiques varie selon que vous utilisez ou non des guardContent balises :

Pour que le contenu de la source ou de la requête soit également évalué par les politiques restantes, imbriquez la balise contextuelle de base dans une balise : guardContent

<amazon-bedrock-guardrails-guardContent_xyz><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-guardContent_xyz>

<amazon-bedrock-guardrails-query_xyz>What is the capital of Japan?</amazon-bedrock-guardrails-query_xyz>
        

Dans cet exemple, le contenu de la source de base est à la fois utilisé comme source de référence contextuelle et évalué par d'autres politiques, car il est également encapsulé dans une balise. guardContent

Appeler une vérification contextuelle de mise à la terre avec Converse API

Pour marquer la source d’ancrage et la requête pour les API Converse, utilisez le champ des qualificatifs dans chaque bloc de contenu à surveiller. 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 les contrôles d’ancrage contextuel. Ceux-ci ne seront donc effectués qu’en sortie et non à l’invite.

Le comportement des politiques autres que l'ancrage contextuel dépend des qualificatifs assignés à chaque bloc : guardContent

Si vous souhaitez que le contenu de votre source ou de votre requête soit également évalué par d'autres règles de sauvegarde, ajoutez-les guard_content à la liste des qualificatifs à côté du qualificatif de base contextuel.

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

L’utilisation du contrôle d’ancrage contextuel avec ApplyGuardrail est similaire à son utilisation avec les API Converse. Pour marquer la source d’ancrage et la requête pour ApplyGuardrail, utilisez le champ des qualificatifs dans chaque bloc de contenu. Cependant, comme aucun modèle n’est invoqué avec ApplyGuardrail, vous devez également fournir un bloc de contenu supplémentaire incluant le contenu à surveiller. Ce bloc de contenu peut être éventuellement qualifié avec 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 les contrôles d’ancrage contextuel. Ceux-ci ne seront donc effectués qu’en sortie et non à l’invite.

Comment les qualificatifs influent sur l'évaluation des politiques

Les blocs de contenu avec grounding_source ou query qualificatifs sont évalués uniquement par le biais de la vérification contextuelle de base. Ces blocs sont exclus de toutes les autres évaluations des politiques de protection (filtres de mots, filtres de sujets, filtres de contenu, détection des informations sensibles et détection rapide des attaques).

Pour qu'un bloc de contenu soit évalué à la fois par la vérification contextuelle de base et par d'autres politiques de protection, utilisez les deux qualificatifs ensemble. Par exemple, spécifiez ["grounding_source", "guard_content"] de marquer un bloc de contenu comme source de base également soumise à toutes les autres politiques configurées.

Pour que des politiques autres que le fondement contextuel évaluent le contenu, au moins un bloc de contenu doit être non qualifié ou explicitement qualifié avec. guard_content Un bloc de contenu n'est pas qualifié lorsqu'il ne comporte aucun qualifiers champ.

Le tableau suivant résume l'impact de chaque combinaison de qualificatifs sur l'évaluation des politiques.