Norme di SanitizeModelResponse

Questa pagina si applica ad Apigee e Apigee hybrid.

Visualizza la documentazione di Apigee Edge.

Il criterio SanitizeModelResponse protegge i client di AI da contenuti dannosi o offensivi mediante la sanitizzazione delle risposte dei modelli di AI generativa. La norma utilizza Model Armor per valutare le risposte del modello per contenuti dannosi o offensivi, attivando la protezione nativa per i client e i carichi di lavoro di AI che utilizzano Apigee. Model Armor è un Google Cloud servizio che offre misure di sicurezza e protezione dell'IA per mitigare i rischi associati ai modelli linguistici di grandi dimensioni (LLM).

Questo criterio viene utilizzato in combinazione con il criterio SanitizeModelResponse.

Questo criterio è un criterio estensibile e il suo utilizzo potrebbe comportare implicazioni in termini di costi o utilizzo, a seconda della licenza Apigee. Per informazioni sui tipi di criteri e sulle implicazioni per l'utilizzo, consulta Tipi di criteri.

Prima di iniziare

Prima di utilizzare il criterio SanitizeModelResponse, devi completare le seguenti attività:

• Crea un modello Model Armor. Questo passaggio deve essere completato prima di creare una norma SanitizeModelResponse.
• Imposta l'endpoint API per il servizio Model Armor.

Ruoli obbligatori

Per ottenere le autorizzazioni necessarie per applicare e utilizzare il criterio SanitizeModelResponse, chiedi all'amministratore di concederti i seguenti ruoli IAM nell'account di servizio che utilizzi per eseguire il deployment dei proxy Apigee:

• Model Armor User (roles/modelarmor.user)
• Model Armor Viewer (roles/modelarmor.viewer)

Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.

Potresti anche riuscire a ottenere le autorizzazioni richieste tramite i ruoli personalizzati o altri ruoli predefiniti.

Abilita API

Enable the Model Armor APIs.

Enable the APIs

Elemento <SanitizeModelResponse>

Definisce un criterio SanitizeModelResponse.

L'elemento <SanitizeModelResponse> utilizza la seguente sintassi:

<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>

Questo elemento ha i seguenti attributi comuni a tutti i criteri:

La tabella seguente fornisce una descrizione generale degli elementi secondari di <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)}

Riferimento all'elemento secondario

Questa sezione descrive gli elementi secondari di <SanitizeModelResponse>.

<DisplayName>

Da utilizzare insieme all'attributo name per etichettare il criterio nell'editor proxy dell'interfaccia utente di gestione con un nome diverso e più naturale.

L'elemento <DisplayName> è comune a tutti i criteri.

La sintassi dell'elemento <DisplayName> è la seguente:

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

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

L'elemento <DisplayName> non ha attributi o elementi secondari.

<IgnoreUnresolvedVariables>

Determina se l'elaborazione si interrompe quando una variabile non è risolta. Imposta su true per ignorare le variabili non risolte e continuare l'elaborazione.

<TemplateName>

Il modello Model Armor.

La sintassi dell'elemento <TemplateName> è la seguente:

<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>

La posizione del payload per il testo della richiesta all'utente da estrarre. Sono supportati solo i valori di testo stringa.

Questo campo supporta la sintassi del modello di messaggio Apigee, incluso l'utilizzo di variabili o funzioni di percorso JSON. Ad esempio:

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

<LLMResponseSource>

La posizione del payload per la risposta LLM da estrarre. Sono supportati solo i valori di testo stringa.

Questo campo supporta la sintassi del modello di messaggio Apigee, incluso l'utilizzo di variabili o funzioni di percorso JSON. Ad esempio:

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

Variabili di flusso

Le variabili di flusso possono essere utilizzate per configurare il comportamento di runtime dinamico per criteri e flussi, in base alle intestazioni HTTP o ai contenuti dei messaggi o al contesto disponibile nel flusso. Per ulteriori informazioni sulle variabili di flusso, consulta la sezione Riferimento alle variabili di flusso.

Il criterio può impostare queste variabili di sola lettura durante l'esecuzione.

Messaggi di errore

Questa sezione descrive i codici di errore e i messaggi di errore restituiti e le variabili di errore impostate da Apigee specifiche per il criterio <SanitizeModelResponse>. Queste informazioni sono importanti se stai sviluppando regole di errore per gestire gli errori. Per saperne di più, consulta Informazioni importanti sugli errori relativi alle norme e Gestione degli errori.

Errori di runtime

Errori di deployment

Questi errori possono verificarsi quando esegui il deployment di un proxy contenente questo criterio.

Variabili di errore

Queste variabili vengono impostate quando questo criterio attiva un errore in fase di esecuzione. Per ulteriori informazioni, consulta Informazioni importanti sugli errori relativi alle norme.

Esempio di risposta di errore

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

Esempio di regola di errore

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

Codice di errore e messaggi di errore del modello Model Armor

Il modello Model Armor supporta l'override dei codici di errore e dei messaggi di errore generati dalle richieste API del criterio SanitizeModelResponse. Se l'utente imposta le sostituzioni, i codici e i messaggi di errore di Model Armor completeranno le variabili di flusso.

Ad esempio, una risposta con codici e messaggi di errore di Model Armor potrebbe essere simile alla seguente:

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

Schemi

Ogni tipo di norma è definito da uno schema XML (.xsd). Come riferimento, gli schemi delle norme sono disponibili su GitHub.