Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Konzepte: Nachrichten, Inhaltsblocktypen und Schecks
<a name="guardrails-use-invoke-guardrail-checks-concepts"></a>

Die folgenden Konzepte beschreiben die Struktur von Anfragen an die `InvokeGuardrailChecks` API.

## Nachrichten
<a name="guardrails-use-invoke-guardrail-checks-messages"></a>

Eine Nachricht ist die grundlegende Inhaltseinheit, die Sie zur Bewertung einreichen. Jede Nachricht hat zwei Felder: eine Rolle, die identifiziert, wer den Inhalt erstellt hat, und ein Inhaltsarray, das den eigentlichen Text als einen oder mehrere eingegebene Inhaltsblöcke enthält.

```
{
  "role": "user",
  "content": [{ "text": "Hello world" }]
}
```

Dies spiegelt die Struktur von Rollen plus Inhaltsblöcken wider, die an anderer Stelle in Amazon Bedrock verwendet wird, sodass die Konversation, die Sie bereits für ein Modell erstellt haben, ohne oder mit nur wenigen Änderungen weitergegeben werden kann. `InvokeGuardrailChecks` Das `messages` Feld einer Anfrage ist ein Array, sodass Sie eine einzelne Nachricht oder eine Sequenz einreichen können, die einen Multi-Turn-Austausch darstellt (z. B. eine Systemanweisung, gefolgt von einer Benutzerrunde). Nachrichten werden in der Reihenfolge ausgewertet, in der Sie sie angeben, und ihre Position ist wichtig: Einige Ergebnisse verweisen auf eine Nachricht mit ihrer Nullbasis `messageIndex` und auf einen Block innerhalb dieser Nachricht nach ihrer `contentIndex` (siehe Ergebnisse für vertrauliche Informationen).

Die Rolle kennzeichnet den Ursprung des Inhalts. Die folgenden Rollen werden unterstützt:
+ `system`— Anweisungen, die das Verhalten des Modells konfigurieren.
+ `user`— Eingaben des Endbenutzers.
+ `assistant`— Vom Modell erzeugte Ausgabe.

## Typen von Inhaltsblöcken
<a name="guardrails-use-invoke-guardrail-checks-content"></a>

Das `content` Feld ist eher ein Array von typisierten Blöcken als eine einfache Zeichenfolge. Ein typisierter Block ist ein kleines Objekt, dessen Schlüssel seinen Typ benennt. Durch dieses Design kann das Nachrichtenformat in future andere Arten von Inhalten (wie Bilder oder Dokumente) enthalten, ohne die allgemeine Nachrichtenform zu ändern. Derzeit ist der einzige unterstützte Blocktyp`text`, dessen Wert eine bloße Zeichenfolge ist:

```
{ "text": "Hello world" }
```

Eine Nachricht kann maximal zehn Inhaltsblöcke enthalten. Ein Inhaltsblock kann höchstens einen `text` Block enthalten. Da dies derzeit der einzige unterstützte Typ `text` ist, bedeutet dies effektiv einen Textblock pro Inhaltsblock. Um mehrere unterschiedliche Textteile innerhalb einer Rolle auszuwerten, senden Sie sie als separate Inhaltsblöcke im `content` Array. Um mehrere unterschiedliche Textteile in mehreren Rollen auszuwerten, senden Sie sie als separate Nachrichten im `messages` Array.

## Schecks
<a name="guardrails-use-invoke-guardrail-checks-checks"></a>

Der Begriff *Schecks* ist austauschbar mit dem Begriff *Schutzmaßnahmen, der von Amazon Bedrock* Guardrails angeboten wird. Das `checks` Objekt ist ein Konfigurationsobjekt mit einem optionalen Feld pro Prüftyp, und Sie geben nur die Prüfungen an, die Sie ausführen möchten. Sie setzen kein separates enable/disable Kennzeichen: Eine Prüfung wird nur dann ausgeführt, wenn das zugehörige Feld vorhanden ist, und ausgelassene Prüfungen führen zu keinem Ergebnis und haben keinen Nutzen. Sie müssen mindestens ein Prüffeld setzen.

```
"checks": {
  "contentFilter":         { ... },
  "promptAttack":          { ... },
  "sensitiveInformation":  { ... }
}
```

Da die Konfiguration pro Anfrage inline ist, können Sie Ihr Sicherheitsniveau von Anruf zu Anruf variieren, ohne eine gespeicherte Guardrail-Ressource verwalten zu müssen. Verschiedene Schritte in einer Agentenschleife können unterschiedliche Kombinationen von Prüfungen für dieselben oder unterschiedliche Nachrichten erfordern.

Jede Prüfung hat ihre eigene Konfigurationsform. Der Feldname wählt die Prüfung aus; das Objekt darin listet auf, wonach diese Prüfung sucht:
+ `contentFilter`— Nimmt eine `categories` Liste auf (HASS, BELEIDIGUNGEN, SEXUELLES VERHALTEN, GEWALT, FEHLVERHALTEN).
+ `promptAttack`— Nimmt eine `categories` Liste auf (JAILBREAK, PROMPT\_INJECTION, PROMPT\_LEAKAGE).
+ `sensitiveInformation`— Nimmt eine `entities` Liste auf (31 unterstützte PII-Entitäten).

**Anfrage und Antwort sind symmetrisch** — Die Schlüssel, die Sie unter eingeben, `checks` sind dieselben Schlüssel, die unter `results` und wiedergegeben werden. `usage` Wenn Sie „`contentFilter`und“ anfordern`sensitiveInformation`, erscheinen nur diese beiden in der Antwort; `promptAttack` fehlt, weil sie nie ausgeführt wurde. Auf diese Weise ist es einfach, einen Befund dem Scheck zuzuordnen, der ihn hervorgebracht hat.

**Detect-only bei jeder Prüfung** — Kein Check blockiert, maskiert oder schreibt Inhalte um. Jede Methode gibt Punkte zurück (eine `severityScore` für Inhaltsfilter und Prompt-Attacke, `confidenceScore` plus Standort-Offsets für vertrauliche Informationen), und Sie entscheiden anhand bestimmter Anforderungen, wie Ihre Anwendung darauf reagiert.