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 n’importe quel fragment 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 ancré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 ancré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 Invoke APIs ou ApplyGuardrail directement. Converse APIs

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

Non ancré, mais pertinent

Ancré, mais non pertinent

Non ancré et non pertinent

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

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

Pour marquer la source d’encrage et la requête dans l’entrée, nous fournissons deux 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 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 conjointement avec les balises guardContent. Si aucune balise guardContent n’est utilisée, la barrière de protection appliquera par défaut toutes les politiques configurées sur l’ensemble de l’entrée, y compris la source d’ancrage et la requête. Si les balises guardContent sont utilisées, la politique de contrôle d’ancrage contextuel étudie uniquement la source d’ancrage, la requête et la réponse, tandis que les politiques restantes étudient le contenu au sein des balises guardContent.

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

Pour marquer la source de base et la rechercher Converse APIs, utilisez le champ des qualificatifs dans chaque bloc de contenu de garde. 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.

Si aucun des blocs de contenu n’est marqué avec le qualificatif guard_content, la politique de contrôle d’ancrage contextuel étudie uniquement la source d’ancrage, la requête et la réponse. Les autres politiques suivent le comportement d’enquête par défaut : l’invite système n’est pas soumise à une enquête, tandis que les messages le sont. Cependant, si un bloc de contenu est marqué du qualificatif guard_content, la politique de contrôle d’ancrage contextuel étudie uniquement la source d’ancrage, la requête et la réponse, tandis que les politiques restantes étudient le contenu marqué des 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 mise à la terre avec ApplyGuardrail est similaire à son utilisation avec le. Converse APIs 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é par guard_content et est équivalent à la réponse du modèle dans Invoke* ou Converse*. APIs 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.

Si aucun des blocs de contenu n’est marqué avec le qualificatif guard_content, la politique de contrôle d’ancrage contextuel étudie uniquement la source d’ancrage, la requête et la réponse. Les autres politiques suivent le comportement d’enquête par défaut : l’invite système n’est pas soumise à une enquête, tandis que les messages le sont. Cependant, si un bloc de contenu est marqué du qualificatif guard_content, la politique de contrôle d’ancrage contextuel étudie uniquement la source d’ancrage, la requête et la réponse, tandis que les politiques restantes étudient le contenu marqué des balises guardContent.