Stratégie SanitizeModelResponse

Cette page s'applique à Apigee et à Apigee hybrid.

Consultez la documentation d' Apigee Edge.

La règle SanitizeModelResponse protège les clients d'IA contre les contenus nuisibles ou choquants en nettoyant les réponses des modèles d'IA générative. La règle utilise Model Armor pour évaluer les réponses du modèle en cas de contenu nuisible ou choquant, ce qui permet de protéger de manière native les clients et les charges de travail d'IA à l'aide d'Apigee. Model Armor est un Google Cloud service qui propose des mesures de sécurité et de sûreté de l'IA pour atténuer les risques associés aux grands modèles de langage (LLM).

Cette règle est utilisée conjointement avec la règle SanitizeModelResponse.

Cette règle est une règle extensible et son utilisation peut avoir des conséquences sur le coût ou l'utilisation, en fonction de votre licence Apigee. Pour en savoir plus sur les types de règles et les implications en termes d'utilisation, consultez la section Types de règles.

Avant de commencer

Avant d'utiliser la stratégie SanitizeModelResponse, vous devez effectuer les tâches suivantes :

• Créez un modèle Model Armor. Cette étape doit être effectuée avant de créer une règle SanitizeModelResponse.
• Définissez le point de terminaison de l'API pour le service Model Armor.

Rôles requis

Pour obtenir les autorisations nécessaires pour appliquer et utiliser la stratégie SanitizeModelResponse, demandez à votre administrateur de vous accorder les rôles IAM suivants sur le compte de service que vous utilisez pour déployer des proxys Apigee :

• Utilisateur de modèle Armor (roles/modelarmor.user)
• Lecteur Model Armor (roles/modelarmor.viewer)

Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Vous pouvez également obtenir les autorisations requises avec des rôles personnalisés ou d'autres rôles prédéfinis.

Activer les API

Enable the Model Armor APIs.

Enable the APIs

Élément <SanitizeModelResponse>

Définit une règle SanitizeModelResponse.

L'élément <SanitizeModelResponse> utilise la syntaxe suivante :

<SanitizeModelResponse async="false" continueOnError="false" enabled="true" name="sanitize-response">
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
  <DisplayName>sanitize-response-sample</DisplayName>
  <ModelArmor>
    <TemplateName>projects/{project}/locations/{location}/templates/{template-name}</TemplateName>
  </ModelArmor>
  <UserPromptSource>{jsonPath('$.contents[-1].parts[-1].text',request.content,true)}</UserPromptSource>
  <LLMResponseSource>{jsonPath($.candidates[-1].content.parts,response.content,true)}</LLMResponseSource>
</SanitizeModelResponse>

<SanitizeModelResponse async="false" continueOnError="false" enabled="true" name="sanitize-response">
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
  <DisplayName>sanitize-response-sample</DisplayName>
  <ModelArmor>
    <TemplateName>projects/{project}/locations/{location}/templates/{template-name}</TemplateName>
  </ModelArmor>
  <UserPromptSource>{jsonPath('$.contents[-1].parts[-1].text',request.content,true)}</UserPromptSource>
  <LLMResponseSource>{jsonPath($.candidates[-1].content.parts,response.content,true)}</LLMResponseSource>
</SanitizeModelResponse>

Cet élément possède les attributs suivants qui sont communs à toutes les règles :

Le tableau suivant fournit une description détaillée des éléments enfants de <SanitizeModelResponse> :

projects/{organization.name}/locations/{system.region.name}/templates/{id}

{jsonpath('$.contents[-1].parts[-1].text',request.content,false)}

{jsonpath('$.input.prompt.text',request.content,false)}

Référence d'élément enfant

Cette section décrit les éléments enfants de <SanitizeModelResponse>.

<DisplayName>

Utilisez-le, en plus de l'attribut name, pour appliquer un libellé à la règle dans l'éditeur de proxys de l'interface de gestion en utilisant un nom différent et plus naturel.

L'élément <DisplayName> est commun à toutes les règles.

L'élément <DisplayName> utilise la syntaxe suivante :

<PolicyElement>
  <DisplayName>POLICY_DISPLAY_NAME</DisplayName>
  ...
</PolicyElement>

<PolicyElement>
  <DisplayName>My Validation Policy</DisplayName>
</PolicyElement>

L'élément <DisplayName> ne comporte aucun attribut ni élément enfant.

<IgnoreUnresolvedVariables>

Détermine si le traitement s'arrête lorsqu'une variable n'est pas résolue. Définissez la valeur sur true pour ignorer les variables non résolues et poursuivre le traitement.

<TemplateName>

Modèle Model Armor.

L'élément <TemplateName> utilise la syntaxe suivante :

<ModelArmor>
  <TemplateName>projects/{project}/locations/{location}/templates/{template-name}</TemplateName>
</ModelArmor>

<ModelArmor>
  <TemplateName>projects/{organization.name}/locations/{system.region.name}/templates/{id}</TemplateName>
</ModelArmor>

<UserPromptSource>

Emplacement de la charge utile pour le texte de l'invite utilisateur à extraire. Seules les valeurs de texte de chaîne sont acceptées.

Ce champ accepte la syntaxe du modèle de message Apigee, y compris l'utilisation de variables ou de fonctions de chemin JSON. Exemple :

{jsonpath('$.input.prompt.text',request.content,false)}

<LLMResponseSource>

Emplacement de la charge utile à extraire de la réponse LLM. Seules les valeurs de texte de chaîne sont acceptées.

Ce champ accepte la syntaxe du modèle de message Apigee, y compris l'utilisation de variables ou de fonctions de chemin JSON. Exemple :

{jsonpath('$.input.prompt.text',request.content,false)}

Variables de flux

Les variables de flux peuvent être utilisées pour configurer le comportement d'exécution dynamique des règles et des flux en fonction des en-têtes HTTP, du contenu des messages ou du contexte disponible dans le flux. Pour en savoir plus sur les variables de flux, consultez la documentation de référence sur les variables de flux.

La règle peut définir ces variables en lecture seule lors de l'exécution.

Informations de référence sur les erreurs

Cette section décrit les codes d'erreur et les messages d'erreur renvoyés, ainsi que les variables d'erreur définies par Apigee spécifiques à la règle <SanitizeModelResponse>. Ces informations sont importantes si vous développez des règles de défaillance afin de gérer les pannes. Pour en savoir plus, consultez les pages Ce que vous devez savoir à propos des erreurs liées aux règles et Gérer les pannes.

Erreurs d'exécution

Erreurs de déploiement

Ces erreurs peuvent se produire lorsque vous déployez un proxy contenant cette règle.

Variables de panne

Ces variables sont définies lorsque cette règle déclenche une erreur au moment de l'exécution. Pour en savoir plus, consultez la section Ce que vous devez savoir sur les erreurs liées aux règles.

Exemple de réponse d'erreur

{
  "fault": {
    "faultstring": "SanitizeModelResponse[sanitize-response]: unable to resolve variable [variable_name]",
    "detail": {
      "errorcode": "steps.sanitizemodelresponse.UnresolvedVariable"
    }
  }
}

Exemple de règle de défaillance

<FaultRule name="SanitizeModelResponse Faults">
    <Step>
        <Name>SMR-CustomSetVariableErrorResponse</Name>
        <Condition>(fault.name = "SetVariableFailed")</Condition>
    </Step>
    <Condition>(sanitizemodelresponse.failed = true)</Condition>
</FaultRule>

Codes et messages d'erreur du modèle Model Armor

Le modèle Model Armor permet de remplacer les codes et les messages d'erreur générés par les requêtes API de la règle SanitizeModelResponse. Si l'utilisateur définit les forçages, les codes et messages d'erreur Model Armor renseignent les variables de flux.

Par exemple, une réponse avec des codes et des messages d'erreur Model Armor peut ressembler à ce qui suit :

{
"sanitizationResult": {
  "filterMatchState": "MATCH_FOUND",
  "filterResults": {...},
  "sanitizationMetadata": {
    "errorCode": "890",
    "errorMessage": "get out"
  },
  "invocationResult": "SUCCESS"
  }
}

Schémas

Chaque type de règle est défini par un schéma XML (.xsd). Pour référence, des schémas de règles sont disponibles sur GitHub.