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.
# Was sind automatische Argumentationsprüfungen in Amazon Bedrock Guardrails?
## Was bewirken automatische Argumentationsprüfungen
Eine zentrale Herausforderung bei großen Sprachmodellen (LLMs) besteht darin, die Genauigkeit ihrer Antworten sicherzustellen. Ohne Validierung LLMs kann es zu Halluzinationen oder ungenauen Informationen kommen, die das Vertrauen untergraben. Automatisierte Prüfungen zur Argumentation in Amazon Bedrock Guardrails helfen bei der Lösung dieses Problems, indem mathematische Techniken verwendet werden, um Inhalte in natürlicher Sprache anhand der von Ihnen definierten Richtlinien zu validieren.
Im Gegensatz zu herkömmlichen Guardrail-Komponenten, die Inhalte auf der Grundlage von Mustervergleichen blockieren oder filtern, verwendet Automated Reasoning Checks formale Logik, um strukturiertes Feedback darüber zu geben, *warum* eine Antwort richtig oder falsch ist. Dieses Feedback kann verwendet werden, um ein LLM dazu zu bewegen, Inhalte zu generieren, die nachweislich Ihren Richtlinien entsprechen. Insbesondere können automatisierte Argumentationsprüfungen:
+ **Erkennen Sie sachlich falsche Aussagen** in LLM-Antworten, indem Sie mathematisch nachweisen, dass generierte Inhalte Ihren Richtlinien widersprechen.
+ **Heben Sie unausgesprochene Annahmen hervor**, wenn eine Antwort Ihrer Richtlinie entspricht, aber nicht alle relevanten Regeln berücksichtigt, was darauf hindeutet, dass die Antwort möglicherweise unvollständig ist.
+ **Geben Sie mathematisch überprüfbare Erklärungen dafür** an, warum genaue Aussagen richtig sind, und geben Sie dabei die spezifischen politischen Regeln und Variablenzuweisungen an, die die Schlussfolgerung stützen.
Diese Funktionen unterscheiden Automated Reasoning Checks von anderen Amazon Bedrock Guardrails-Komponenten. Inhaltsfilter und Themenrichtlinien wirken wie binäre Tore — sie blockieren oder lassen Inhalte zu. Automatisierte Prüfungen zur Argumentation dienen als Überprüfungsebene, die detailliertes, umsetzbares Feedback liefert, mit dem Sie Ihre Antworten programmatisch verbessern können.
## Wann sollten automatische Argumentationsüberprüfungen eingesetzt werden
Automatisierte Argumentationsprüfungen sind am wertvollsten, wenn Sie die sachliche Grundlage für die Antwort eines LLM nachweisen müssen. Erwägen Sie, sie zu verwenden, wenn Ihre Bewerbung Folgendes beinhaltet:
+ **Regulierte Branchen** wie Gesundheitswesen, Personalwesen und Finanzdienstleistungen, in denen falsche Informationen rechtliche oder Compliance-Konsequenzen haben können.
+ **Komplexe Regelwerke** wie Hypothekengenehmigungen, Zonengesetze, Versicherungsvoraussetzungen oder Leistungen an Arbeitnehmer, bei denen mehrere Bedingungen zusammenwirken, um das Ergebnis zu bestimmen.
+ **Compliance-Szenarien**, die überprüfbare KI-Antworten mit mathematisch verifizierbarem Nachweis erfordern, dass die Reaktion Ihren Richtlinien entspricht.
+ **Kundenorientierte Anwendungen**, bei denen falsche Anleitungen das Vertrauen untergraben könnten, z. B. Chatbots, die Fragen zu Unternehmensrichtlinien, Produktberechtigungen oder Servicebedingungen beantworten.
## Was Automated Reasoning Checks nicht leisten
Um die richtigen Erwartungen zu wecken, sollten Sie sich der folgenden Einschränkungen bewusst sein:
+ **Kein sofortiger Injektionsschutz.** Automatisierte Reasoning-Checks validieren genau das, was Sie ihnen schicken. Wenn bösartige oder manipulierte Inhalte als Eingabe bereitgestellt werden, wird die Überprüfung für diesen Inhalt unverändert durchgeführt. Verwenden Sie [Inhaltsfilter](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html#guardrails-content-filters) in Kombination mit Automated-Reasoning-Prüfungen, um Promptinjektionsangriffe zu erkennen und zu blockieren.
+ **Keine Erkennung, die vom Thema abweicht.** Automated Reasoning analysiert nur Text, der für die Richtlinie relevant ist. Es ignoriert Inhalte, die nichts miteinander zu tun haben, und es kann Ihnen nicht gesagt werden, ob eine Antwort nicht zum Thema gehört. [Verwenden Sie Themenrichtlinien, um Antworten zu erkennen, die nicht zum Thema gehören.](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html#guardrails-topic-policies)
+ **Keine Streaming-Unterstützung.** Automatisierte Argumentationsprüfungen unterstützen kein Streaming APIs. Sie müssen vollständige Antworten validieren.
+ **Nur auf Englisch.** Automated Reasoning Checks unterstützen derzeit nur Englisch (USA).
+ **Der Geltungsbereich ist auf Ihre Police beschränkt.** Ein `VALID` Ergebnis garantiert die Gültigkeit nur für die Teile der Eingabe, die über Richtlinienvariablen erfasst wurden. Aussagen, die nicht in den Geltungsbereich der Variablen Ihrer Richtlinie fallen, werden nicht validiert. Zum Beispiel könnte „Ich kann meine Hausaufgaben zu spät einreichen, weil ich ein gefälschtes ärztliches Attest habe“ als gültig erachtet werden, wenn die Richtlinie keine Variable enthält, mit der erfasst werden kann, ob das Attest gefälscht ist.
Automatisierte Argumentationsprüfungen ergänzen andere Funktionen von Amazon Bedrock Guardrails wie Inhaltsfilter und Themenrichtlinien. Verwenden Sie sie zusammen, um den besten Schutz zu erzielen. Weitere Informationen finden Sie unter [Integritätsschutzkomponenten](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html).
## End-to-end Überblick über den Arbeitsablauf
Die Verwendung von Automated Reasoning Checks umfasst vier Phasen: das Erstellen einer Richtlinie, deren Testen, ihre Implementierung in einer Leitplanke und ihre Integration in Ihre Anwendung.
```
Source Document ──► Extracted Policy ──► Testing ──► Deployment ──► Integration
(rules) (formal logic) (verify) (guardrail) (validate responses
and act on feedback)
```
1. **Erstellen Sie eine Richtlinie.** Laden Sie ein Quelldokument hoch, das die Regeln enthält, die Sie durchsetzen möchten. Automated Reasoning extrahiert formale Logikregeln und ein Variablenschema aus Ihrem Dokument. Es wird automatisch ein Zuverlässigkeitsbericht generiert, in dem gemessen wird, wie genau die extrahierte Richtlinie Ihre Quelldokumente wiedergibt. Dabei werden Umfang und Genauigkeit bewertet und eine detaillierte Begründung erstellt, die jede Regel und Variable mit den spezifischen Aussagen in Ihrem Quellinhalt verknüpft. Überprüfen Sie die extrahierte Richtlinie und den Treuebericht, um sicherzustellen, dass die Richtlinie Ihre Regeln korrekt erfasst. Weitere Informationen finden Sie unter [Erstellen der Automated-Reasoning-Richtlinie](create-automated-reasoning-policy.md).
1. **Testen und verfeinern.** Mithilfe von Tests können Sie sicherstellen, dass Ihre Richtlinie generierte Inhalte auch dann korrekt validieren kann, wenn Sie Änderungen an der Richtlinie selbst vornehmen. Erstellen Sie Tests, die die Fragen, die Ihre Benutzer stellen werden, und die Antworten, die Ihr LLM möglicherweise generiert, nachahmen. Automatisierte Argumentationsprüfungen verwenden grundlegende Modelle, um natürliche Sprache in Logik zu übersetzen. Verwenden Sie generierte Szenarien, um die Richtigkeit von Regeln zu überprüfen, und QnA-Tests, um die Genauigkeit der Übersetzung zwischen natürlicher Sprache und Logik zu überprüfen. Verfeinern Sie Ihre Richtlinie auf der Grundlage der Testergebnisse. Weitere Informationen finden Sie unter [Testen einer Automated-Reasoning-Richtlinie](test-automated-reasoning-policy.md).
1. **Bereitstellen.** Speichern Sie eine unveränderliche Version Ihrer getesteten Richtlinie und hängen Sie sie an eine Leitplanke an. Sie können die Bereitstellung mithilfe CloudFormation unserer CI/CD-Pipelines automatisieren. Weitere Informationen finden Sie unter [Implementieren der Automated-Reasoning-Richtlinie in die Anwendung](deploy-automated-reasoning-policy.md).
1. **Integrieren.** Zur Laufzeit werden die Ergebnisse von Automated Reasoning über eine Version zurückgegeben APIs , die eine Amazon Bedrock Guardrails-Konfiguration unterstützt: `Converse``InvokeModel`,`InvokeAgent`, und`RetrieveAndGenerate`, sowie die eigenständige API. `ApplyGuardrail` Untersuchen Sie die Ergebnisse, um zu entscheiden, ob Sie die Antwort bereitstellen, sie anhand des Feedbacks neu schreiben oder den Benutzer um eine Klarstellung bitten möchten. Automatisierte Begründungsprüfungen funktionieren nur im *Erkennungsmodus* — sie geben Ergebnisse und Feedback zurück, anstatt Inhalte zu blockieren. Weitere Informationen darüber, wie Sie automatische Prüfungen zum Begründeverfahren in Ihre Anwendung integrieren können, finden Sie unter. [Integrieren Sie automatisierte Argumentationsprüfungen in Ihre Anwendung](integrate-automated-reasoning-checks.md) Weitere Informationen zu den Berechtigungen, die für die Aktivierung von Automated Reasoning Checks erforderlich sind, finden Sie unter. [Berechtigungen für Richtlinien für automatisiertes Denken mit ApplyGuardrail](guardrail-automated-reasoning-permissions.md)
## Verfügbarkeit und Sprachunterstützung
Automated Reasoning Checks in Amazon Bedrock Guardrails ist in den folgenden Regionen allgemein verfügbar:
+ USA Ost (Nord-Virginia)
+ USA West (Oregon)
+ USA Ost (Ohio)
+ EU (Frankfurt)
+ EU (Paris)
+ EU (Irland)
Automated Reasoning Checks unterstützen derzeit nur Englisch (USA).
## Einschränkungen und Überlegungen
Beachten Sie vor der Implementierung von Automated Reasoning Checks die folgenden technischen Einschränkungen:
+ **Komplexität des Dokuments.** Quelldokumente sollten gut strukturiert sein und klare, eindeutige Regeln enthalten. Hochkomplexe Dokumente mit verschachtelten Bedingungen oder widersprüchlichen Aussagen lassen sich möglicherweise nicht sauber in die formale Logik integrieren. Eingabedokumente sind auf eine Größe von 5 MB und 50.000 Zeichen begrenzt. Sie können größere Dokumente aufteilen und jeden Abschnitt in Ihrer Richtlinie zusammenführen. Bilder und Tabellen in Dokumenten wirken sich auch auf die Anzahl der eingegebenen Zeichen aus.
+ **Bearbeitungszeit.** Die Validierung von Automated Reasoning Checks erhöht die Latenz Ihrer Bewerbungsantworten. Planen Sie zusätzliche Verarbeitungszeit ein, insbesondere für komplexe Richtlinien mit vielen Variablen. Die Anzahl der Variablen in einer Richtlinie trägt direkt zur Erhöhung der Validierungslatenz bei.
+ **Geltungsbereich der Richtlinie.** Um Richtlinien zu entwickeln, die einfacher zu verwalten sind, sollte sich jede Richtlinie auf einen bestimmten Bereich (z. B. Personal, Finanzen, Recht) konzentrieren, anstatt zu versuchen, mehrere Bereiche, die nichts miteinander zu tun haben, in einer einzigen Richtlinie abzudecken.
+ **Grenzwerte für Variablen und Regeln.** Richtlinien mit einer übermäßigen Anzahl von Variablen oder zu komplexen Regelinteraktionen können auf Verarbeitungslimits stoßen oder TOO\$1COMPLEX-Ergebnisse zurückgeben. Weitere Informationen finden Sie in der [Dokumentation zu Amazon Bedrock Limits](https://docs.aws.amazon.com/hgeneral/latest/gr/bedrock.html#limits_bedrock) und[Referenz zu den Validierungsergebnissen](automated-reasoning-checks-concepts.md#ar-concept-validation-results).
+ **Abhängigkeit von natürlicher Sprache.** Die Genauigkeit der Validierung hängt davon ab, wie gut natürliche Sprache in Benutzeraufforderungen und Modellantworten in die formalen Logikvariablen Ihrer Richtlinie übersetzt werden kann. Automatisierte Argumentationsprüfungen verwenden grundlegende Modelle, um natürliche Sprache in logische Repräsentationen zu übersetzen. Variablenbeschreibungen beeinflussen die Qualität dieser Übersetzung.
+ **Nichtlineare Arithmetik.** Automatisierte Prüfungen des logischen Denkens können zu einer Zeitüberschreitung führen oder TOO\$1COMPLEX zurückgeben, wenn Einschränkungen das Argumentieren mit nichtlinearer Arithmetik beinhalten (z. B. irrationale Zahlen oder Exponenten).
## Preisgestaltung
Automated-Reasoning-Prüfungen im Integritätsschutz für Amazon Bedrock werden auf Grundlage der Anzahl der bearbeiteten Bewertungsanfragen in Rechnung gestellt. Weitere Informationen finden Sie auf der Seite [Amazon Bedrock – Preise](https://aws.amazon.com/bedrock/pricing/).
Für jede Überprüfungsanfrage fallen Gebühren an, unabhängig vom Ergebnis (z. B. VALID, INVALID, TRANSLATION\$1AMBIGUOUS). So senken Sie die Kosten:
+ Verwenden Sie geeignete Konfidenzschwellen, um die Genauigkeit mit den Verarbeitungsanforderungen in Einklang zu bringen.
+ Erwägen Sie, die Validierungsergebnisse für identische oder ähnliche Abfragen zwischenzuspeichern, wenn dies für Ihren Anwendungsfall angemessen ist.
+ Überwachen Sie die Nutzungsmuster und passen Sie die Richtlinien an, um unnötige Überprüfungsanfragen zu reduzieren.
## Regionsübergreifende Inferenz für Richtlinienmaßnahmen
Automated Reasoning nutzt regionsübergreifende Inferenzen, um die Leistung und Verfügbarkeit von Maßnahmen zur Erstellung und Erprobung von Richtlinien zu optimieren. Spezifische API-Operationen verteilen die Verarbeitung automatisch auf die AWS-Regionen innerhalb Ihrer geografischen Grenzen, um eine zuverlässige Servicebereitstellung zu gewährleisten.
Die folgenden API-Operationen für Automated Reasoning verwenden regionsübergreifende Inferenzen:
+ `StartAutomatedReasoningPolicyBuildWorkflow`— Wird bei der Erstellung und Zusammenstellung von Richtlinien aus Quelldokumenten aufgerufen.
+ `StartAutomatedReasoningPolicyTestWorkflow`— Wird während der Validierungs- und Testverfahren für Richtlinien aufgerufen.
Bei diesen Vorgängen werden große Sprachmodelle (LLMs) aufgerufen, um formale Logikregeln aus Quelldokumenten zu extrahieren und Konstrukte natürlicher Sprache in strukturierte logische Repräsentationen zu übersetzen. Die Anforderungsverarbeitung wird gemäß dem folgenden geografischen Routing verteilt, um optimale Leistung und Verfügbarkeit zu gewährleisten:
+ **Regionen in den Vereinigten Staaten:** API-Anfragen, die aus USA Ost (Nord-Virginia), USA West (Oregon) oder USA Ost (Ohio) stammen, können in jeder unterstützten Region der USA bearbeitet werden.
+ **Regionen der Europäischen Union:** API-Anfragen aus EU (Frankfurt), EU (Paris) oder EU (Irland) können in jeder unterstützten EU-Region bearbeitet werden.
**Wichtig**
Kundendaten verbleiben innerhalb der ursprünglichen geografischen Grenze (Vereinigte Staaten oder Europäische Union) und werden gemäß den AWS-Datenresidenzverpflichtungen verarbeitet. Regionsübergreifende Inferenzen leiten Anfragen ausschließlich innerhalb derselben geografischen Region weiter, um die Leistung und Serviceverfügbarkeit zu optimieren.
Die regionsübergreifende Inferenz funktioniert transparent, ohne dass eine Kundenkonfiguration erforderlich ist. Die API-Funktionalität bleibt unabhängig von der spezifischen Region, in der die Anfrage bearbeitet wird, konsistent.
**Topics**
+ [Was bewirken automatische Argumentationsprüfungen](#automated-reasoning-what-it-does)
+ [Wann sollten automatische Argumentationsüberprüfungen eingesetzt werden](#automated-reasoning-when-to-use)
+ [Was Automated Reasoning Checks nicht leisten](#automated-reasoning-what-it-doesnt-do)
+ [End-to-end Überblick über den Arbeitsablauf](#automated-reasoning-workflow-overview)
+ [Verfügbarkeit und Sprachunterstützung](#automated-reasoning-availability)
+ [Einschränkungen und Überlegungen](#automated-reasoning-limitations)
+ [Preisgestaltung](#automated-reasoning-pricing)
+ [Regionsübergreifende Inferenz für Richtlinienmaßnahmen](#automated-reasoning-cross-region-inference)
+ [Automatisiertes Denken überprüft Konzepte](automated-reasoning-checks-concepts.md)
+ [Erstellen der Automated-Reasoning-Richtlinie](create-automated-reasoning-policy.md)
+ [Bewährte Methoden für Richtlinien zur automatisierten Argumentation](automated-reasoning-policy-best-practices.md)
+ [Testen einer Automated-Reasoning-Richtlinie](test-automated-reasoning-policy.md)
+ [Beheben Sie Fehler und verfeinern Sie Ihre Richtlinie für automatisiertes Denken](address-failed-automated-reasoning-tests.md)
+ [Verwenden Sie Kiro CLI mit einer Automated Reasoning-Richtlinie](kiro-cli-automated-reasoning-policy.md)
+ [Implementieren der Automated-Reasoning-Richtlinie in die Anwendung](deploy-automated-reasoning-policy.md)
+ [Integrieren Sie automatisierte Argumentationsprüfungen in Ihre Anwendung](integrate-automated-reasoning-checks.md)
# Automatisiertes Denken überprüft Konzepte
Auf dieser Seite werden die Bausteine von Automated Reasoning Checks beschrieben. Wenn Sie diese Konzepte verstehen, können Sie effektive Richtlinien erstellen, Testergebnisse interpretieren und Probleme beheben. Einen allgemeinen Überblick darüber, was Automated Reasoning Checks bewirken und wann sie eingesetzt werden sollten, finden Sie unter. [Regeln](#ar-concept-rules)
## Richtlinien
Eine *Richtlinie für* automatisiertes Denken ist eine Ressource in Ihrem AWS-Konto, die eine Reihe formaler Logikregeln, ein Variablenschema und optionale benutzerdefinierte Typen enthält. Die Richtlinie kodiert die Geschäftsregeln, Vorschriften oder Richtlinien, anhand derer Sie LLM-Antworten validieren möchten.
Richtlinien werden anhand von Quelldokumenten — wie Personalhandbüchern, Compliance-Handbüchern oder Produktspezifikationen — erstellt, in denen die Regeln in natürlicher Sprache beschrieben werden. Wenn Sie eine Richtlinie erstellen, extrahieren automatische Argumentationsprüfungen die Regeln und Variablen aus Ihrem Dokument und übersetzen sie in eine formale Logik, die mathematisch verifiziert werden kann.
Die Beziehung zwischen Richtlinien, Leitplanken und Ihrer Anwendung ist wie folgt:
```
Source Document ──► Automated Reasoning Policy ──► Guardrail ──► Your Application
(natural (rules + variables + (references (calls guardrail
language) custom types) a policy APIs to validate
version) LLM responses)
```
Hauptmerkmale von Richtlinien:
+ Jede Richtlinie wird durch einen Amazon-Ressourcennamen (ARN) identifiziert und ist in einer bestimmten AWS-Region vorhanden.
+ Richtlinien haben eine `DRAFT` Version (in der Konsole „Working Draft“ genannt), die Sie während der Entwicklung bearbeiten, und nummerierte unveränderliche Versionen, die Sie für die Bereitstellung erstellen.
+ Eine Leitplanke kann auf die DRAFT-Richtlinie oder auf eine bestimmte nummerierte Version verweisen. Wenn Sie eine nummerierte Version verwenden, können Sie die aktualisieren, `DRAFT` ohne dass sich dies auf Ihre installierte Leitplanke auswirkt.
+ Jede Police sollte sich auf einen bestimmten Bereich konzentrieren (z. B. Leistungen im Personalwesen, Kreditwürdigkeit, Regeln für Produktrückgaben), anstatt zu versuchen, mehrere Bereiche abzudecken, die nichts miteinander zu tun haben.
step-by-stepAnweisungen zur Erstellung einer Richtlinie finden Sie unter. [Erstellen der Automated-Reasoning-Richtlinie](create-automated-reasoning-policy.md)
## Fidelity-Bericht
In einem *Fidelity-Bericht* wird gemessen, wie genau eine extrahierte Richtlinie den Quelldokumenten entspricht, aus denen sie generiert wurde. Der Bericht wird automatisch generiert, wenn Sie eine Richtlinie aus einem Quelldokument erstellen. Er enthält zwei wichtige Werte sowie detaillierte Basisinformationen, die jede Regel und Variable mit bestimmten Aussagen in Ihrem Quellinhalt verknüpfen.
Der Zuverlässigkeitsbericht soll Experten ohne technische Kenntnisse dabei helfen, eine Richtlinie zu untersuchen und zu validieren, ohne die formale Logik verstehen zu müssen. In der Konsole wird auf der Registerkarte **Quelldokument** der Zuverlässigkeitsbericht als Tabelle mit nummerierten atomaren Aussagen angezeigt, die aus Ihrem Dokument extrahiert wurden. Dabei wird angegeben, welche Regeln und Variablen jede Aussage begründet. Sie können nach bestimmten Regeln oder Variablen filtern und nach Inhalten innerhalb der Aussagen suchen.
Der Treuebericht umfasst zwei Werte, die jeweils zwischen 0,0 und 1,0 liegen:
+ **Deckungsgrad** — Gibt an, wie gut die Police die Aussagen in den Quelldokumenten abdeckt. Ein höherer Wert bedeutet, dass ein größerer Teil des Quellinhalts in der Richtlinie enthalten ist.
+ **Genauigkeitsbewertung** — Gibt an, wie originalgetreu die Richtlinienregeln das Quellmaterial wiedergeben. Ein höherer Wert bedeutet, dass die extrahierten Regeln der Absicht des Originaldokuments besser entsprechen.
Neben den Gesamtwerten bietet der Zuverlässigkeitsbericht eine detaillierte Begründung für jede Regel und Variable in der Richtlinie:
+ **Regelberichte** — Für jede Regel identifiziert der Bericht die spezifischen Aussagen aus den Quelldokumenten, die die Regel belegen (Grundaussagen), erklärt, wie diese Aussagen die Regel rechtfertigen (Begründungsbegründungen), und liefert eine individuelle Genauigkeitsbewertung mit einer Begründung.
+ **Variablenberichte** — Für jede Variable identifiziert der Bericht die Quellaussagen, die die Variablendefinition unterstützen, erklärt die Begründung und liefert eine individuelle Genauigkeitsbewertung.
+ **Dokumentenquellen** — Die Quelldokumente sind in atomare Aussagen unterteilt, d. h. einzelne, unteilbare Fakten, die aus dem Text extrahiert werden. Der Inhalt des Dokuments ist mit Zeilennummern versehen, sodass Sie jede Regel und Variable bis zur exakten Position im Originaldokument zurückverfolgen können.
## Regeln
Regeln sind der Kern einer Richtlinie für automatisiertes Denken. Jede Regel ist ein formaler Logikausdruck, der eine Beziehung zwischen Variablen erfasst. Regeln werden mithilfe einer Teilmenge der [SMT-LIB-Syntax](https://smtlib.cs.uiowa.edu/) ausgedrückt, einem Standardformat für formale Logik, das bei automatisierten Argumentationsprüfungen zur mathematischen Überprüfung verwendet wird. Siehe [KMS-Berechtigungen für Automated-Reasoning-Richtlinien](create-automated-reasoning-policy.md#automated-reasoning-policy-kms-permissions)
Die meisten Regeln sollten einem *Wenn-Dann-Format (implizit*) folgen. Das bedeutet, dass Regeln eine Bedingung (den „Wenn“ -Teil) und eine Schlussfolgerung (den „Dann“ -Teil) haben sollten, die durch den Implikationsoperator miteinander verbunden sind. `=>`
**Wohlgeformte Regeln (Wenn-Dann-Format):**
```
;; If the employee is full-time AND has worked for more than 12 months,
;; then they are eligible for parental leave.
(=> (and isFullTime (> tenureMonths 12)) eligibleForParentalLeave)
;; If the loan amount is greater than 500,000, then a co-signer is required.
(=> (> loanAmount 500000) requiresCosigner)
```
**Bloße Behauptungen (Regeln ohne Wenn-Dann-Struktur) erzeugen Axiome — Aussagen, die immer wahr sind.** Dies ist nützlich, um Randbedingungen wie Kontensalden mit positiven Werten zu überprüfen, kann aber auch bestimmte Bedingungen logisch unmöglich machen und zu unerwarteten Ergebnissen bei der Validierung führen. `IMPOSSIBLE` Beispielsweise `(= eligibleForParentalLeave true)` bedeutet die bloße Behauptung, dass bei Prüfungen mit automatischem Denken die Tatsache berücksichtigt wird, dass der Nutzer Anspruch auf Elternurlaub hat. Jede Eingabe, die angibt, nicht berechtigt zu sein, würde zu einem Validierungsergebnis führen, `IMPOSSIBLE` weil sie diesem Axiom widerspricht.
```
;; GOOD: Useful to check impossible conditions such as
;; negative account balance
(>= accountBalance 0)
;; BAD: This asserts eligibility as always true, regardless of conditions.
eligibleForParentalLeave
```
Regeln unterstützen die folgenden logischen Operatoren:
| Operator | Bedeutung | Beispiel |
| --- | --- | --- |
| => | Implikation (wenn-dann) | (=> isFullTime eligibleForBenefits) |
| and | Logisches UND | (and isFullTime (> tenure 12)) |
| or | Logisches ODER | (or isVeteran isTeacher) |
| not | Logisch NICHT | (not isTerminated) |
| = | Gleichheit | (= employmentType FULL\$1TIME) |
| >, <, >=, <= | Vergleich | (>= creditScore 700) |
Bewährte Methoden zum Schreiben effektiver Regeln finden Sie unter[Bewährte Methoden für Richtlinien zur automatisierten Argumentation](automated-reasoning-policy-best-practices.md).
## Variablen
Variablen stellen die Konzepte in Ihrer Domäne dar, die bei Prüfungen zum automatisierten Denken verwendet werden, um natürliche Sprache in formale Logik zu übersetzen und Regeln auszuwerten. Jede Variable hat einen Namen, einen Typ und eine Beschreibung.
Automatisierte Reasoning-Checks unterstützen die folgenden Variablentypen:
| Typ | Description | Beispiel |
| --- | --- | --- |
| bool | True oder false | isFullTime— Ob der Mitarbeiter Vollzeit arbeitet |
| int | Ganze Zahl | tenureMonths— Anzahl der Monate, in denen der Mitarbeiter gearbeitet hat |
| real | Dezimalzahl | interestRate— Jährlicher Zinssatz als Dezimalzahl (0,05 bedeutet 5%) |
| Benutzerdefinierter Typ (Enum) | Ein Wert aus einer definierten Menge | leaveType— Einer der folgenden Werte: ELTERLICH, MEDIZINISCH, TRAUERFALL, PERSÖNLICH |
### Die entscheidende Rolle von Variablenbeschreibungen
Variablenbeschreibungen sind der wichtigste Faktor für die Genauigkeit von Übersetzungen. Wenn automatische Argumentationsprüfungen natürliche Sprache in formale Logik übersetzen, wird anhand von Variablenbeschreibungen bestimmt, welche Variablen den im Text erwähnten Konzepten entsprechen. Vage oder unvollständige Beschreibungen führen zu `TRANSLATION_AMBIGUOUS` Ergebnissen oder falschen Variablenzuweisungen.
**Beispiel: Wie sich Beschreibungen auf die Übersetzung auswirken**
Stellen Sie sich vor, ein Benutzer fragt: „Ich arbeite hier seit 2 Jahren. Habe ich Anspruch auf Elternzeit?“
| Vage Beschreibung (wird wahrscheinlich fehlschlagen) | Ausführliche Beschreibung (wahrscheinlich erfolgreich) |
| --- | --- |
| tenureMonths: „Wie lange der Mitarbeiter gearbeitet hat.“ | tenureMonths: „Die Anzahl der vollen Monate, in denen der Mitarbeiter ununterbrochen beschäftigt war. Wenn Benutzer Dienstjahre angeben, rechnen Sie diese in Monate um (z. B. 2 Jahre = 24 Monate). Bei Neueinstellungen auf 0 setzen.“ |
Aufgrund der vagen Beschreibung wissen automatische Argumentationsprüfungen möglicherweise nicht, ob „2 Jahre“ in 24 Monate umgerechnet werden sollen, oder sie weisen die Variable möglicherweise gar nicht zu. Bei der ausführlichen Beschreibung ist die Übersetzung eindeutig.
Gute Variablenbeschreibungen sollten:
+ Erklären Sie im Klartext, wofür die Variable steht.
+ Geben Sie die Einheit und das Format an (z. B. „in Monaten“, „als Dezimalzahl, wobei 0,15 15% bedeutet“).
+ Geben Sie nicht offensichtliche Synonyme und alternative Formulierungen an, die Benutzer verwenden könnten (z. B. „Auf true setzen, wenn Benutzer angeben, Vollzeit zu arbeiten oder volle Stunden zu arbeiten“).
+ Beschreiben Sie die Randbedingungen (z. B. „Bei Neueinstellungen auf 0 setzen“).
## Benutzerdefinierte Typen (Aufzählungen)
Benutzerdefinierte Typen definieren eine Reihe benannter Werte, die eine Variable annehmen kann. Sie entsprechen Aufzählungen (Enums) in Programmiersprachen. Verwenden Sie benutzerdefinierte Typen, wenn eine Variable eine Kategorie mit einem festen Satz möglicher Werte darstellt.
**Beispiele:**
| Geben Sie den Namen ein | Mögliche Werte | Anwendungsfall |
| --- | --- | --- |
| LeaveType | ELTERLICH, MEDIZINISCH, TRAUERND, PERSÖNLICH | Kategorisieren Sie die Art des Urlaubs, den ein Mitarbeiter beantragt |
| Severity | KRITISCH, GROSS, UNBEDEUTEND | Klassifizieren Sie den Schweregrad eines Problems oder Vorfalls |
**Wann sollten Enumerationen im Vergleich zu Booleschen Werten verwendet werden:**
+ Verwenden Sie Aufzählungen, wenn sich die Werte *gegenseitig ausschließen* — eine Variable kann jeweils nur ein Wert sein. `leaveType`Kann beispielsweise PARENTAL oder MEDICAL sein, aber nicht beide gleichzeitig.
+ *Verwenden Sie separate boolesche Variablen, wenn Staaten nebeneinander existieren können.* Beispielsweise kann eine Person sowohl ein Veteran als auch ein Lehrer sein. Die Verwendung einer Aufzählung `customerType = {VETERAN, TEACHER}` würde eine Wahl zwischen ihnen erzwingen, was zu einem logischen Widerspruch führen würde, wenn beide zutreffen. Verwenden Sie stattdessen zwei boolesche Werte: und. `isVeteran` `isTeacher`
**Tipp**
Wenn es möglich ist, dass eine Variable keinen Wert aus der Enumeration hat, fügen Sie einen `OTHER` Oder-Wert hinzu. `NONE` Dadurch werden Übersetzungsprobleme vermieden, wenn die Eingabe keinem der definierten Werte entspricht.
## Übersetzung: von der natürlichen Sprache zur formalen Logik
Übersetzung ist der Prozess, bei dem automatische Argumentationsprüfungen natürliche Sprache (Benutzerfragen und LLM-Antworten) in formale logische Ausdrücke umwandeln, die anhand Ihrer Richtlinienregeln mathematisch verifiziert werden können. Um Probleme zu beheben und effektive Richtlinien zu entwickeln, ist es wichtig, diesen Prozess zu verstehen.
Automatisierte Reasoning-Checks validieren Inhalte in zwei verschiedenen Schritten:
1. **Translate** — Automatisierte Argumentationsprüfungen verwenden Fundamentmodelle (LLMs), um die Eingabe in natürlicher Sprache in formale Logik zu übersetzen. In diesem Schritt werden die im Text enthaltenen Konzepte den Variablen Ihrer Richtlinie zugeordnet und die Beziehungen als logische Aussagen ausgedrückt. Da dieser Schritt verwendet LLMs, kann er *Fehler enthalten*. Automatisierte Argumentationsprüfungen verwenden mehrere LLMs , um den eingegebenen Text zu übersetzen, und verwendet dann die semantische Äquivalenz der redundanten Übersetzungen, um einen Konfidenzwert festzulegen. Die Qualität der Übersetzung hängt davon ab, wie gut Ihre Variablenbeschreibungen mit der in der Eingabe verwendeten Sprache übereinstimmen.
1. **Validieren** — Automatisierte Prüfungen zur Argumentation verwenden mathematische Techniken (mithilfe von SMT-Solvern), um zu überprüfen, ob die übersetzte Logik Ihren Richtlinienregeln entspricht. Dieser Schritt *ist mathematisch fundiert* — wenn die Übersetzung korrekt ist, ist das Validierungsergebnis konsistent.
**Wichtig**
Diese Unterscheidung in zwei Schritten ist entscheidend für das Debuggen. Wenn Sie sicher sind, dass die Regeln in der Richtlinie korrekt sind und ein Test fehlschlägt oder unerwartete Ergebnisse liefert, liegt das Problem höchstwahrscheinlich in Schritt 1 (Übersetzung) und nicht in Schritt 2 (Validierung) vor. Die mathematische Validierung ist solide, und wenn die Übersetzung die Bedeutung der Eingabe korrekt wiedergibt, ist das Validierungsergebnis korrekt. Konzentrieren Sie Ihre Debugging-Bemühungen darauf, die Variablenbeschreibungen zu verbessern und sicherzustellen, dass die Übersetzung den richtigen Variablen die richtigen Werte zuweist.
**Beispiel: Übersetzung in Aktion**
Bei einer Richtlinie mit den Variablen `isFullTime` (bool), `tenureMonths` (int) und `eligibleForParentalLeave` (bool) und der Eingabe:
+ **Frage:** „Ich bin ein Vollzeitangestellter und seit 18 Monaten hier. Kann ich Elternzeit nehmen?“
+ **Antwort:** „Ja, Sie haben Anspruch auf Elternzeit.“
Schritt 1 (Übersetzen) ergibt:
```
Premises: isFullTime = true, tenureMonths = 18
Claims: eligibleForParentalLeave = true
```
Schritt 2 (validieren) überprüft diese Zuweisungen anhand der Richtlinienregel `(=> (and isFullTime (> tenureMonths 12)) eligibleForParentalLeave)` und bestätigt, dass der Anspruch erfüllt ist`VALID`.
Um die Genauigkeit der Übersetzungen zu verbessern:
+ Schreiben Sie detaillierte Variablenbeschreibungen, aus denen hervorgeht, wie sich Benutzer auf Konzepte in der Alltagssprache beziehen.
+ Entfernen Sie doppelte oder fast doppelte Variablen, die die Übersetzung verwirren könnten (z. B. `tenureMonths` und). `monthsOfService`
+ Löschen Sie ungenutzte Variablen, auf die keine Regeln verweisen — sie machen den Übersetzungsprozess unübersichtlich.
+ Verwenden Sie question-and-answer Tests, um die Genauigkeit der Übersetzung anhand realistischer Benutzereingaben zu überprüfen. Weitere Informationen finden Sie unter [Testen einer Automated-Reasoning-Richtlinie](test-automated-reasoning-policy.md).
## Ergebnisse und Validierungsergebnisse
Wenn automatisierte Argumentationsprüfungen Inhalte validieren, führt dies zu einer Reihe von *Ergebnissen*. Jedes Ergebnis stellt eine aus der Eingabe gewonnene Tatsachenaussage zusammen mit dem Überprüfungsergebnis, den verwendeten Variablenzuweisungen und den politischen Regeln dar, die diese Schlussfolgerung stützen. Das (aggregierte) Gesamtergebnis wird bestimmt, indem die Ergebnisse nach ihrem Schweregrad sortiert und das schlechteste Ergebnis ausgewählt wird. Die Reihenfolge des Schweregrads vom schlechtesten zum besten lautet:`TRANSLATION_AMBIGUOUS`,`IMPOSSIBLE`,`INVALID`,`SATISFIABLE`,`VALID`.
### Struktur eines Befundes
Der Ergebnistyp bestimmt, welche Felder im Ergebnis enthalten sind. [Referenz zu den Validierungsergebnissen](#ar-concept-validation-results)In diesem Abschnitt finden Sie eine ausführliche Beschreibung der einzelnen Ergebnisarten. Die meisten Findingtypen haben jedoch ein gemeinsames `translation` Objekt, das die folgenden Komponenten enthält:
`premises`
Aus der Eingabe extrahierter Kontext, Annahmen oder Bedingungen, die sich darauf auswirken, wie ein Anspruch bewertet werden sollte. Bei question-and-answer Formaten ist die Prämisse oft die Frage selbst. Antworten können auch Prämissen enthalten, die Einschränkungen festlegen. In „Ich bin ein Vollzeitbeschäftigter mit 18 Monaten Betriebszugehörigkeit“ sind die Prämissen beispielsweise `isFullTime = true` und`tenureMonths = 18`.
`claims`
Sachaussagen, die von Automated Reasoning auf ihre Richtigkeit hin überprüft werden. In einem question-and-answer Format ist die Behauptung in der Regel die Antwort. In „Ja, Sie haben Anspruch auf Elternzeit“ lautet der Antrag beispielsweise`eligibleForParentalLeave = true`.
`confidence`
Ein Wert von 0,0 bis 1,0, der angibt, wie es bei bestimmten Automated Reasoning-Prüfungen um die Übersetzung von natürlicher Sprache in formale Logik geht. Höhere Werte bedeuten eine größere Sicherheit. Ein Konfidenzwert von 1,0 bedeutet, dass sich alle Übersetzungsmodelle auf dieselbe Interpretation geeinigt haben.
`untranslatedPremises`
Verweise auf Teile des ursprünglichen Eingangstextes, die Prämissen entsprechen, aber nicht in formale Logik übersetzt werden konnten. Diese heben Teile der Eingaben hervor, die Automated Reasoning als relevant erkannt hat, die aber nicht den politischen Variablen zugeordnet werden konnten.
`untranslatedClaims`
Verweise auf Teile des ursprünglichen Eingabetextes, die Behauptungen entsprechen, aber nicht in formale Logik übersetzt werden konnten. Ein `VALID` Ergebnis deckt nur die übersetzten Ansprüche ab — nicht übersetzte Ansprüche werden nicht validiert.
### Referenz zu den Validierungsergebnissen
Jeder Befund ist genau einer der folgenden Typen. Der Typ bestimmt die Bedeutung des Ergebnisses, die im Ergebnis verfügbaren Felder und die empfohlene Aktion für Ihre Anwendung. Alle Ergebnisarten, die ein `translation` Feld enthalten, enthalten auch ein `logicWarning` Feld, das vorhanden ist, wenn die Übersetzung logische Probleme enthält, die von den Richtlinienregeln unabhängig sind (z. B. Aussagen, die immer wahr oder immer falsch sind).
| Ergebnis | Felder suchen | Empfohlene Aktion |
| --- | --- | --- |
| VALID | `translation`— Die übersetzten Prämissen, Behauptungen, Konfidenzwerte und alle nicht übersetzten Referenzen. `supportingRules`— Die Versicherungsregeln, die beweisen, dass die Behauptungen korrekt sind. Jede Regel enthält ihren Bezeichner und den ARN der Richtlinienversion. `claimsTrueScenario`— Ein Szenario (Satz von Variablenzuweisungen), das zeigt, dass die Behauptungen logisch wahr sind. | Bereitstellen der Antwort an den Benutzer. Sie dienen der Protokollierung supportingRules und dienen zu claimsTrueScenario Prüfungszwecken als mathematisch überprüfbarer Gültigkeitsnachweis. Suchen Sie untranslatedPremises untranslatedClaims nach Teilen der Eingabe, die nicht validiert wurden. |
| INVALID | `translation`— Die übersetzten Prämissen, Behauptungen, Konfidenzwerte und alle nicht übersetzten Referenzen. `contradictingRules`— Die Versicherungsbestimmungen, gegen die die Ansprüche verstoßen. Jede Regel enthält ihren Bezeichner und den ARN der Richtlinienversion. | Senden Sie die Antwort nicht zu. Verwenden Sie translation (um zu sehen, was behauptet wurde) und contradictingRules (um zu sehen, gegen welche Regeln verstoßen wurde), um die Antwort umzuschreiben oder zu blockieren. Übergeben Sie in einer Umschreibungsschleife die widersprüchlichen Regeln und falschen Behauptungen an das LLM, um eine korrigierte Antwort zu generieren. |
| SATISFIABLE | `translation`— Die übersetzten Prämissen, Behauptungen, Vertrauensbewertung und alle nicht übersetzten Referenzen. `claimsTrueScenario`— Ein Szenario, das zeigt, wie die Behauptungen logischerweise wahr sein könnten. `claimsFalseScenario`— Ein Szenario, das zeigt, dass die Behauptungen unter verschiedenen Bedingungen logisch falsch sein könnten. | Vergleiche claimsTrueScenario und claimsFalseScenario identifiziere die fehlenden Bedingungen. Schreiben Sie die Antwort um, sodass sie die zusätzlichen Informationen enthält, die für die Erstellung erforderlich sindVALID, bitten Sie den Benutzer um Erläuterung der fehlenden Bedingungen oder geben Sie die Antwort mit dem Vorbehalt, dass sie unvollständig sein könnte. |
| IMPOSSIBLE | `translation`— Die übersetzten Prämissen, Behauptungen, Vertrauensbewertung und alle nicht übersetzten Verweise. Untersuchen Sie die Prämissen, um Widersprüche zu erkennen. `contradictingRules`— Die politischen Regeln, die mit den Räumlichkeiten oder miteinander in Konflikt stehen. Wenn sie ausgefüllt sind, kann der Widerspruch in der Richtlinie selbst liegen. | Prüfen Sie, ob die Eingabe widersprüchliche Aussagen enthält (z. B. „Ich arbeite in Vollzeit und auch in Teilzeit“). Wenn die Eingabe gültig ist, liegt der Widerspruch wahrscheinlich in Ihrer Richtlinie vor — überprüfen contradictingRules und überprüfen Sie den Qualitätsbericht. Siehe [Beheben Sie Fehler und verfeinern Sie Ihre Richtlinie für automatisiertes Denken](address-failed-automated-reasoning-tests.md). |
| TRANSLATION\$1AMBIGUOUS | Enthält kein `translation` Objekt. Stellt stattdessen Folgendes bereit: `options`— Die konkurrierenden logischen Interpretationen (bis zu 2). Jede Option beinhaltet ihre eigenen `translations` Prämissen, Behauptungen und Vertrauen. Vergleichen Sie die Optionen, um festzustellen, wo sich die Modelle nicht einig sind. `differenceScenarios`— Szenarien (bis zu 2), die veranschaulichen, wie sich die verschiedenen Interpretationen in ihrer Bedeutung unterscheiden, wobei variable Zuweisungen die praktischen Auswirkungen der Mehrdeutigkeit hervorheben. | Untersuchen Sieoptions, um die Meinungsverschiedenheit zu verstehen. Verbessern Sie die Variablenbeschreibungen, um Mehrdeutigkeiten zu vermeiden, führen Sie überlappende Variablen zusammen oder entfernen Sie sie, oder bitten Sie den Benutzer um Klarstellung. Sie können auch den Konfidenzschwellenwert anpassen — siehe. [Vertrauensschwellen](#ar-concept-confidence-thresholds) |
| TOO\$1COMPLEX | Enthält keine A`translation`, Regeln oder Szenarien. Die Eingabe hat aufgrund des Volumens oder der Komplexität die Verarbeitungskapazität überschritten. | Verkürzen Sie die Eingabe, indem Sie sie in kleinere Teile aufteilen, oder vereinfachen Sie die Vorgehensweise, indem Sie die Anzahl der Variablen reduzieren, und vermeiden Sie komplexe Arithmetik (z. B. Exponenten oder irrationale Zahlen). Sie können Ihre Richtlinie in kleinere, zielgerichtetere Richtlinien aufteilen. |
| NO\$1TRANSLATIONS | Enthält keine A`translation`, Regeln oder Szenarien. Kann zusammen mit anderen Ergebnissen erscheinen, wenn nur ein Teil der Eingaben übersetzt werden könnte. | Ein NO\$1TRANSLATIONS Ergebnis wird immer dann in die Ausgabe aufgenommen, wenn eines der anderen Ergebnisse Prämissen oder Behauptungen enthält, die nicht übersetzt wurden. Sehen Sie sich die anderen Ergebnisse an, um festzustellen, welche Teile der Eingabe nicht übersetzt wurden. Wenn der Inhalt relevant sein sollte, fügen Sie Ihrer Richtlinie Variablen hinzu, um die fehlenden Konzepte zu erfassen. Wenn der Inhalt nicht zum Thema gehört, sollten Sie in Erwägung ziehen, ihn mithilfe von Themenrichtlinien zu filtern, bevor er die automatische Argumentationsprüfung erreicht. |
**Anmerkung**
Ein `VALID` Ergebnis deckt nur die Teile des Inputs ab, die anhand von politischen Variablen in den übersetzten Prämissen und Behauptungen erfasst wurden. Aussagen, die nicht in den Geltungsbereich der Variablen Ihrer Police fallen, werden nicht validiert. Beispielsweise könnte „Ich kann meine Hausaufgaben zu spät einreichen, weil ich ein falsches ärztliches Attest habe“ als gültig erachtet werden, wenn die Richtlinie keine Variable enthält, mit der erfasst werden kann, ob das Attest gefälscht ist. Automatisierte Argumentationsprüfungen werden wahrscheinlich auch „gefälschte ärztliche Bescheinigungen“ als unübersetzte Prämisse in ihre Feststellung mit einbeziehen. Behandeln Sie unübersetzte Inhalte und `NO_TRANSLATIONS` Ergebnisse als Warnsignal.
## Vertrauensschwellen
Automatisierte Argumentationsprüfungen verwenden mehrere Basismodelle, um natürliche Sprache in formale Logik zu übersetzen. Jedes Modell erstellt unabhängig seine eigene Übersetzung. Der *Konfidenzwert* gibt den Grad der Übereinstimmung zwischen diesen Übersetzungen an — insbesondere den Prozentsatz der Modelle, die semantisch äquivalente Interpretationen lieferten.
Der *Konfidenzschwellenwert* ist ein von Ihnen festgelegter Wert (von 0,0 bis 1,0), der das Mindestmaß an Übereinstimmung bestimmt, das erforderlich ist, damit eine Übersetzung als zuverlässig genug angesehen wird, um validiert zu werden. Er steuert den Kompromiss zwischen Reichweite und Genauigkeit:
+ **Höherer Schwellenwert** (z. B. 0,9): Erfordert eine starke Übereinstimmung zwischen den Übersetzungsmodellen. Führt zu weniger Ergebnissen, aber mit höherer Genauigkeit. Mehr Eingaben werden als `TRANSLATION_AMBIGUOUS` gekennzeichnet.
+ **Niedrigerer Schwellenwert** (z. B. 0,5): Akzeptiert Übersetzungen mit geringerer Zustimmung. Führt zu mehr Ergebnissen, aber mit einem höheren Risiko falscher Übersetzungen. Weniger Eingaben werden als `TRANSLATION_AMBIGUOUS` gekennzeichnet.
**So funktioniert der Schwellenwert:**
1. Mehrere Basismodelle übersetzen die Eingabe jeweils unabhängig voneinander.
1. Übersetzungen, die durch einen Prozentsatz von Modellen gestützt werden, der dem Schwellenwert entspricht oder darüber liegt, werden zu Ergebnissen mit hoher Zuverlässigkeit und einem definitiven Ergebnis (`VALID``INVALID`, usw.).
1. Wenn eine oder mehrere Übersetzungen unter den Schwellenwert fallen, wird bei der Prüfung mit automatisierter Argumentation ein zusätzliches `TRANSLATION_AMBIGUOUS` Ergebnis ermittelt. Dieses Ergebnis enthält Einzelheiten zu den Unstimmigkeiten zwischen den Modellen, anhand derer Sie Ihre Variablenbeschreibungen verbessern oder den Benutzer um Klarstellung bitten können.
**Tipp**
Beginnen Sie mit dem Standardschwellenwert und passen Sie ihn anhand Ihrer Testergebnisse an. Wenn Sie zu viele `TRANSLATION_AMBIGUOUS` Ergebnisse für Eingaben sehen, die eindeutig sein sollten, konzentrieren Sie sich darauf, Ihre Variablenbeschreibungen zu verbessern, anstatt den Schwellenwert zu senken. Eine Senkung des Schwellenwerts kann zwar zu einer Verringerung der `TRANSLATION_AMBIGUOUS` Ergebnisse führen, erhöht jedoch das Risiko falscher Validierungen.
# Erstellen der Automated-Reasoning-Richtlinie
Wenn Sie eine Richtlinie für automatisiertes Denken erstellen, wird Ihr Quelldokument in eine Reihe formaler Logikregeln und ein Schema von Variablen und Typen übersetzt. Auf dieser Seite erfahren Sie, wie Sie Ihr Dokument vorbereiten, die Richtlinie erstellen und die Ergebnisse überprüfen.
Amazon Bedrock verschlüsselt Ihre Automated-Reasoning-Richtlinie mittels AWS Key Management Service (KMS). Standardmäßig verwendet Amazon Bedrock einen diensteigenen Schlüssel. Sie können optional einen vom Kunden verwalteten KMS-Schlüssel angeben, um die Verschlüsselung Ihrer Richtliniendaten weiter kontrollieren zu können.
Stellen Sie sicher, dass Sie über die [entsprechenden Berechtigungen](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrail-automated-reasoning-permissions.html) verfügen, um Ihre Richtlinie für automatisiertes Denken zu testen und zu verwenden.
## Bereiten Sie Ihr Quelldokument vor
Bevor Sie die Konsole öffnen oder die API aufrufen, bereiten Sie das Dokument vor, das Automated Reasoning zum Extrahieren von Regeln und Variablen verwenden wird. Die Qualität Ihrer Richtlinie hängt direkt von der Qualität dieser Informationen ab.
### Struktur und Klarheit der Dokumente
Automatisierte Prüfungen zur Argumentation funktionieren am besten bei Dokumenten, die klare, unmissverständliche Regeln enthalten. Jede Regel sollte eine Bedingung und ein Ergebnis angeben. Vermeiden Sie vage Formulierungen, subjektive Kriterien oder Regeln, die von einem externen Kontext abhängen, der im Dokument nicht enthalten ist.
**Beispiel: Klare oder vage Regeln**
| Klar (gut für die Extraktion) | Vage (schlecht für die Extraktion) |
| --- | --- |
| „Vollzeitbeschäftigte mit mindestens 12 Monaten ununterbrochener Betriebszugehörigkeit haben Anspruch auf Elternzeit.“ | „Anspruchsberechtigte Arbeitnehmer können mit Zustimmung des Vorgesetzten Elternurlaub beantragen.“ |
| „Rückerstattungsanträge müssen innerhalb von 30 Tagen nach dem Kauf eingereicht werden. Die Artikel müssen in der Originalverpackung sein.“ | „Rückerstattungen werden auf einer bestimmten case-by-case Grundlage abgewickelt.“ |
### Größenbeschränkungen und Aufteilung großer Dokumente
Quelldokumente sind auf eine Größe von 5 MB und 50.000 Zeichen begrenzt. Bilder und Tabellen in Dokumenten werden ebenfalls auf die Zeichenbeschränkung angerechnet.
Wenn Ihr Dokument diese Grenzwerte überschreitet oder wenn es mehrere Bereiche abdeckt, die nichts miteinander zu tun haben, teilen Sie es in spezielle Abschnitte auf. Teilen Sie beispielsweise ein Mitarbeiterhandbuch in separate Dokumente auf, in denen die Urlaubsregelungen, die Inanspruchnahme von Leistungen und die Kostenerstattung behandelt werden. Erstellen Sie Ihre Richtlinie mit dem ersten Abschnitt und führen Sie dann die iterative Richtlinienerstellung (später auf dieser Seite beschrieben) durch, um weitere Abschnitte zu derselben Richtlinie zusammenzuführen.
### Verarbeiten Sie komplexe Dokumente vorab
Dokumente, die viele Textbausteine, Haftungsausschlüsse oder Inhalte enthalten, die nichts mit den Regeln zu tun haben, die Sie durchsetzen möchten, führen zu überflüssigen Richtlinien mit unnötigen Variablen und Regeln. Beachten Sie vor dem Hochladen Folgendes:
+ Entfernen von Kopf- und Fußzeilen, Inhaltsverzeichnissen und Anhängen, die keine Regeln enthalten.
+ Es werden nur die Abschnitte extrahiert, die die Regeln enthalten, die für Ihren Anwendungsfall relevant sind.
+ Vereinfachen Sie komplexe Tabellen nach Möglichkeit in Klartextanweisungen.
**Tipp**
Beginnen Sie mit einer bestimmten Teilmenge Ihrer Regeln. Erstellen und testen Sie die Richtlinie gründlich und fügen Sie dann in nachfolgenden Iterationen schrittweise weitere Inhalte hinzu. Dieser Ansatz hilft Ihnen, Probleme frühzeitig zu erkennen und zu lösen, und erleichtert die Fehlerbehebung.
### (Optional) Verwenden Sie ein LLM, um Dokumente als logische Regeln umzuschreiben
Bei Dokumenten, die erzählerische Prosa, juristische Sprache oder komplexe Formatierung enthalten, sollten Sie in Erwägung ziehen, ein Frontier-Modell mit erweiterten Argumentationsfunktionen zu verwenden, um den Inhalt in klare, logische Regeln umzuschreiben, bevor Sie ihn in die automatische Argumentationsprüfung hochladen. Dieser einmalige Vorverarbeitungsschritt wandelt Text in ein Format um, aus dem automatische Argumentationsprüfungen genauer extrahieren können. Das Ergebnis sind qualitativ hochwertigere Richtlinien mit weniger ungenutzten Variablen und bloßen Aussagen.
**Anmerkung**
Vergleichen Sie immer die Ergebnisse des LLM mit Ihrem Originaldokument, bevor Sie es als Quelltext verwenden.
Es gibt zwei Ansätze für die LLM-Vorverarbeitung, abhängig von der Komplexität Ihres Dokuments und davon, wie viel Kontrolle Sie über die Extraktion haben möchten.
#### Ansatz 1: Extraktion von Regeln für Klartext
Bitten Sie das LLM, das Dokument in eine nummerierte Liste von Wenn-Dann-Regeln umzuschreiben. Dieser Ansatz ist unkompliziert und eignet sich gut für kurze, fokussierte Dokumente, bei denen die Regeln in der Quelle relativ klar sind.
**Beispiel für eine Aufforderung:**
```
You are a logical reasoning expert. Your task is to analyze the provided
source text and rewrite it as a set of clear, logical rules using if-then
statements.
Instructions:
1. Extract the key relationships, conditions, and outcomes from the source text.
2. Convert these into logical implications using "if-then" format.
3. Use clear, precise language that captures the original meaning.
4. Number each rule for easy reference.
5. Ensure rules are mutually consistent and non-contradictory.
Format:
- Rule [N]: If [condition], then [consequence].
- Use "and" to combine multiple conditions.
- Use "or" for alternative conditions.
- Include negations when relevant: If not [condition], then [consequence].
Example:
Source: "Students who complete all assignments and attend at least 80% of
classes will pass the course."
Rule 1: If a student completes all assignments and attends at least 80% of
classes, then they will pass the course.
Source Text:
[Paste your document here]
```
#### Ansatz 2: Strukturierte Regelextraktion
Bitten Sie das LLM bei komplexen oder langen Dokumenten, Regeln als strukturiertes JSON mit Metadaten für jede Regel zu extrahieren. Dieser Ansatz liefert umfangreichere Ergebnisse, anhand derer Sie überprüfen können, aus welchen Teilen des Dokuments jede Regel stammt, wie zuverlässig die Extraktion ist und welche Regeln abgeleitet und nicht direkt angegeben werden. Außerdem wird das LLM aufgefordert, vernünftige Regeln zu erstellen — vernünftige Grenzbeschränkungen wie „Alter darf nicht negativ sein“ —, die sich direkt in den Grenzregeln niederschlagen, die in den Richtlinien für automatisiertes Denken verwendet werden. Weitere Informationen zu Grenzregeln finden Sie unter. [Überprüfen von Bereichen für numerische Werte](automated-reasoning-policy-best-practices.md#bp-validate-ranges)
**Beispiel für eine Aufforderung:**
```
You are a logical reasoning expert. Extract formal logical rules from the
provided text.
Output Format:
For each rule, provide:
- Rule ID: [unique identifier]
- Conditions: [ALL preconditions — preserve compound conditions with AND/OR/NOT]
- Consequence: [the outcome/action]
- Confidence: [high/medium/low based on text clarity]
- Source Reference: [quote or paraphrase from source]
- Rule Type: [explicit/implicit/sanity]
Critical Guidelines:
1. PRESERVE ALL CONDITIONS: Do not drop or simplify conditions.
2. PRESERVE LOGICAL OPERATORS: Maintain AND, OR, NOT relationships exactly.
3. PRESERVE QUANTIFIERS: Keep "all", "any", "at least", numeric thresholds.
4. PRESERVE EXCEPTIONS: Include "unless", "except when" clauses.
5. Make implicit conditions explicit only when clearly implied by context.
6. Use consistent terminology across rules.
7. Flag ambiguities such as unclear, incomplete, or contradictory statements.
8. Add sanity rules for common-sense constraints:
- Numeric ranges (e.g., "age must be between 0 and 150")
- Temporal constraints (e.g., "start date must be before end date")
- Physical limits (e.g., "quantity cannot be negative")
- Mutual exclusivity (e.g., "status cannot be both active and inactive")
Output Requirements:
- Produce final JSON only (no text or markdown).
- Use the following JSON keys:
- "rules" for the rules array
- "ambiguities" for the ambiguities array
Source Text:
[Paste your document here]
```
Nachdem Sie die strukturierte Extraktion ausgeführt haben, überprüfen Sie die JSON-Ausgabe. Achten Sie besonders auf:
+ Regeln mit `confidence: low` — diese müssen möglicherweise manuell anhand des Quelldokuments überprüft werden.
+ Regeln mit `ruleType: implicit` — diese wurden eher abgeleitet als direkt angegeben. Stellen Sie sicher, dass sie die Absicht der Quelle genau widerspiegeln.
+ Das `ambiguities` Array — Diese heben Bereiche hervor, in denen das Quelldokument unklar ist und die vor dem Extrahieren möglicherweise neu geschrieben werden müssen.
Wandeln Sie die überprüften JSON-Regeln in Klartext-Wenn-Dann-Aussagen um, die Sie bei der Erstellung der Richtlinie für automatisiertes Denken als Quelldokument verwenden können.
## Schreiben Sie effektive Anweisungen
Bei der Erstellung einer Richtlinie können Sie optionale Anweisungen angeben, die angeben, wie Automated Reasoning Ihr Quelldokument verarbeitet. Gute Anweisungen sind zwar optional, verbessern aber die Qualität der extrahierten Regeln und Variablen erheblich.
Effektive Anweisungen sollten drei Dinge umfassen:
1. **Beschreiben Sie den Anwendungsfall.** Erläutern Sie, was Ihre Anwendung tut und welche Art von Inhalten die Richtlinie validieren wird. Beispiel: „Mit dieser Richtlinie wird ein HR-Chatbot validiert, der Fragen von Mitarbeitern zur Beurlaubung beantwortet.“
1. **Beschreiben Sie die Arten von Fragen, die Benutzer stellen werden.** Nennen Sie Beispiele für realistische Benutzerfragen. Zum Beispiel: „Nutzer werden Fragen stellen wie: Habe ich Anspruch auf Elternzeit, wenn ich 9 Monate hier gearbeitet habe?“ oder ‚Wie viele Tage Trauerurlaub kann ich nehmen? '“
1. **Konzentrieren Sie sich auf die Extraktion.** Wenn Ihr Dokument mehrere Themen behandelt, lassen Sie Automated Reasoning prüfen, auf welche Teile Sie sich konzentrieren und welche ignorieren sollen. Beispiel: „Konzentrieren Sie sich auf die Abschnitte 3 bis 5, die sich mit den Urlaubsregelungen befassen. Ignorieren Sie die allgemeine Unternehmensübersicht in Abschnitt 1 und das Organigramm in Abschnitt 2.“
**Beispiel für eine Anweisung:**
```
This policy will validate HR questions about leave eligibility. The document
has sections on different leave types (parental, medical, bereavement, personal).
Users will ask questions like "Am I eligible for parental leave if I've worked
here for 9 months?" or "Can part-time employees take bereavement leave?"
Focus on the eligibility criteria for each leave type. Capture variables that
help determine whether an employee is eligible for a specific type of leave.
```
## Erstellen Sie eine Richtlinie in der Konsole
1. Wählen Sie im linken Navigationsbereich die Option **Automated Reasoning** und anschließend **Richtlinie erstellen** aus.
1. Füllen Sie das Feld **Name** für die Richtlinie aus.
1. (Optional) Geben Sie eine **Beschreibung** für die Richtlinie ein.
1. Geben Sie als **Quelle** das Dokument an, das die Regeln und Richtlinien Ihrer Wissensdomäne beschreibt. Gehen Sie wie folgt vor:
1. Führen Sie für die **Erfassungsmethode** einen der folgenden Schritte aus:
1. Wählen Sie **Dokument hochladen** und anschließend **Datei auswählen** aus. Laden Sie ein PDF-Dokument mit dem Quellinhalt hoch.
1. Wählen Sie **Text eingeben** aus. Fügen Sie Ihren Quellinhalt ein oder geben Sie ihn ein.
1. (Empfohlen) **Anweisungen finden** Sie in der Anleitung zur Verarbeitung Ihres Quelldokuments. Sehen Sie [Schreiben Sie effektive Anweisungen](#write-effective-instructions) nach, was Sie einschließen sollten.
1. (Optional) Wählen Sie unter **Tags** die Option **Neues Tag hinzufügen** aus, um Ihre Richtlinie zu kennzeichnen.
1. (Optional) Wählen Sie unter **Verschlüsselung** einen KMS-Schlüssel aus, mit dem Sie Ihre Richtlinie verschlüsseln möchten. Sie können den standardmäßigen Schlüssel verwenden, der dem Dienst gehört, oder einen vom Kunden verwalteten Schlüssel auswählen.
1. Wählen Sie **Richtlinie erstellen** aus.
**Tipp**
Wenn Ihre Anwendung einen bestimmten Satz von Variablen erwartet, können Sie das Schema vor dem Import von Inhalten vordefinieren. Verwenden Sie die `CreateAutomatedReasoningPolicy` API oder CloudFormation um eine Richtlinie mit einer zu erstellen`policyDefinition`, die Ihre gewünschten Variablen und Typen, aber keine Regeln enthält. Verwenden Sie dann[Iterative Politikgestaltung](#iterative-policy-building), um Ihr Quelldokument zu importieren. Automated Reasoning verwendet Ihr vordefiniertes Schema als Ausgangspunkt und fügt Regeln hinzu, die auf Ihre Variablen verweisen.
## Erstellen Sie mithilfe der API eine Richtlinie
Eine Richtlinie für automatisiertes Denken ist eine Ressource in Ihrem AWS-Konto, die durch einen Amazon-Ressourcennamen (ARN) identifiziert wird. Das Erstellen einer Richtlinie über die API erfolgt in zwei Schritten: Erstellen Sie zuerst die Richtlinienressource und starten Sie dann einen Build-Workflow, um Regeln aus Ihrem Dokument zu extrahieren.
### Schritt 1: Erstellen Sie die Richtlinienressource
Verwenden Sie die `CreateAutomatedReasoningPolicy` API, um die Richtlinienressource zu erstellen.
`name` (Erforderlich)
Der Name der -Richtlinie. Muss innerhalb Ihres AWS-Kontos und Ihrer Region eindeutig sein.
`description` (optional)
Eine Beschreibung des Zwecks der Richtlinie.
`policyDefinition` (optional)
Eine erste Richtliniendefinition mit Regeln, Variablen und benutzerdefinierten Typen. Verwenden Sie dies, wenn Sie bereits über ein Schema verfügen, mit dem Sie beginnen möchten.
`kmsKeyId` (optional)
Die KMS-Schlüssel-ID für die Verschlüsselung der Richtlinie. Falls nicht angegeben, verwendet Amazon Bedrock einen diensteigenen Schlüssel.
`tags` (optional)
Tags, die mit der Richtlinie verknüpft werden sollen.
`clientRequestToken` (optional)
Ein Idempotenz-Token, das sicherstellt, dass der Vorgang nicht mehr als einmal abgeschlossen wird.
**Beispiel:**
```
aws bedrock create-automated-reasoning-policy \
--name "MyHRPolicy" \
--description "Validates HR chatbot responses about leave eligibility" \
--kms-key-id arn:aws:kms:us-east-1:111122223333:key/12345678-1234-1234-1234-123456789012
```
Beispielantwort:
```
{
"createdAt": "2025-07-21T14:43:52.692Z",
"definitionHash": "f16ba1ceca36e1d21adce559481add6a...",
"name": "MyHRPolicy",
"policyArn": "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk",
"updatedAt": "2025-07-21T14:43:52.692Z",
"version": "DRAFT"
}
```
### Schritt 2: Starten Sie einen Build-Workflow zum Extrahieren von Regeln
Verwenden Sie die `StartAutomatedReasoningPolicyBuildWorkflow` API mit dem Richtlinien-ARN aus Schritt 1, um Regeln und Variablen aus Ihrem Quelldokument zu extrahieren.
`policyArn` (Erforderlich)
Der ARN der in Schritt 1 erstellten Richtlinienressource.
`buildWorkflowType` (Erforderlich)
Stellen Sie auf ein`INGEST_CONTENT`, um Regeln aus einem Dokument zu extrahieren.
`sourceContent` (Erforderlich)
Enthält das zu verarbeitende Dokument und eine optionale Definition der Startrichtlinie.
**Beispiel:**
```
# Encode your PDF to base64
PDF_BASE64=$(base64 -i your-policy.pdf | tr -d '\n')
# Start the build workflow
aws bedrock start-automated-reasoning-policy-build-workflow \
--policy-arn arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk \
--build-workflow-type INGEST_CONTENT \
--source-content "{
\"policyDefinition\": {
\"version\": \"1.0\",
\"types\": [],
\"rules\": [],
\"variables\": []
},
\"workflowContent\": {
\"documents\": [
{
\"document\": \"$PDF_BASE64\",
\"documentContentType\": \"pdf\",
\"documentName\": \"HR Leave Policy\",
\"documentDescription\": \"Validates HR chatbot responses about leave eligibility. Users ask questions like 'Am I eligible for parental leave?'\"
}
]
}
}"
```
Beispielantwort:
```
{
"policyArn": "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk",
"buildWorkflowId": "d40fa7fc-351e-47d8-a338-53e4b3b1c690"
}
```
Überprüfen Sie den Build-Status mit`ListAutomatedReasoningPolicyBuildWorkflows`:
```
aws bedrock list-automated-reasoning-policy-build-workflows \
--policy-arn arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk
```
## Überprüfen Sie die extrahierte Richtlinie
Überprüfen Sie nach Abschluss eines Builds die extrahierte Richtliniendefinition, bevor Sie mit dem Testen beginnen. Das Erkennen von Problemen in dieser Phase spart Zeit im Vergleich zu deren Entdeckung durch fehlgeschlagene Tests zu einem späteren Zeitpunkt.
Öffnen Sie in der Konsole Ihre Richtlinie und rufen Sie die **Definitionsseite** auf. Verwenden Sie `GetAutomatedReasoningPolicyBuildWorkflowResultAssets` with über die API, `--asset-type POLICY_DEFINITION` um die extrahierte Definition und `--asset-type QUALITY_REPORT` den Qualitätsbericht abzurufen. Mithilfe des `--asset-type ASSET_MANIFEST` Parameters können Sie sich eine vollständige Liste der während des Workflows erstellten Assets anzeigen lassen, z. B. den Genauigkeitsbericht.
Überprüfen Sie, ob folgende Probleme auftreten:
1. **Unbenutzte Variablen.** Suchen Sie in der Konsole nach Warnindikatoren neben Variablen. Diese kennzeichnen Variablen, auf die keine Regeln verweisen. Löschen Sie ungenutzte Variablen — sie stören den Übersetzungsprozess und können zu `TRANSLATION_AMBIGUOUS` Ergebnissen führen. In der API werden ungenutzte Variablen im `QUALITY_REPORT` Asset aufgeführt.
1. **Doppelte oder fast doppelte Variablen.** Durchsuchen Sie die Variablenliste nach Variablen mit sich überschneidenden Bedeutungen, wie z. B. und. `tenureMonths` `monthsOfService` Doppelte Variablen verwirren den Übersetzungsprozess, da bei automatisierten Argumentationsprüfungen nicht bestimmt werden kann, welche für ein bestimmtes Konzept verwendet werden soll. Duplikate zusammenführen oder löschen.
1. **Bloße Behauptungen (Regeln nicht im Wenn-Dann-Format).** Überfliegen Sie die Regeln und suchen Sie nach Regeln, die nicht im Wenn-Dann-Format vorliegen, wie z. `(= eligibleForParentalLeave true)` Bloße Behauptungen erzeugen Axiome — Aussagen, die immer wahr sind —, die bestimmte Bedingungen logisch unmöglich machen und bei der Validierung zu unerwarteten Ergebnissen führen. `IMPOSSIBLE` Schreiben Sie sie als Bedingungen um (zum Beispiel) oder löschen Sie sie. `(=> (and isFullTime (> tenureMonths 12)) eligibleForParentalLeave)` Bloße Behauptungen eignen sich nur für Randbedingungen wie. `(>= accountBalance 0)`
1. **Widersprüchliche Regeln.** Der Qualitätsbericht weist auf Regeln hin, die einander widersprechen. Widersprüchliche Regeln führen dazu, dass Ihre Richtlinie bei allen Überprüfungsanfragen, `IMPOSSIBLE` die die widersprüchlichen Regeln beinhalten, zurückgesendet wird. Lösen Sie Konflikte, indem Sie die Regeln zusammenführen oder eine davon löschen.
1. **Fehlende Regeln oder Variablen.** Vergleichen Sie die extrahierte Richtlinie mit Ihrem Quelldokument. Wenn wichtige Regeln oder Konzepte fehlen, können Sie sie manuell hinzufügen oder die Richtlinie mit besseren Anweisungen neu erstellen.
**Tipp**
Der Qualitätsbericht identifiziert auch unzusammenhängende Regelsätze — Gruppen von Regeln, die keine Variablen gemeinsam haben. Unzusammenhängende Regelsätze stellen nicht unbedingt ein Problem dar (Ihre Richtlinie deckt möglicherweise unabhängige Themen ab), sie können jedoch darauf hinweisen, dass bei Variablen Verbindungen zwischen verwandten Regeln fehlen.
## Lesen Sie den Fidelity-Bericht
Wenn Sie eine Richtlinie aus einem Quelldokument erstellen, wird zusammen mit der extrahierten Richtlinie automatisch ein Zuverlässigkeitsbericht generiert. Der Zuverlässigkeitsbericht misst, wie genau die Richtlinie Ihren Quellinhalt wiedergibt, und bietet eine detaillierte Begründung, die jede Regel und Variable mit bestimmten Aussagen im Dokument verknüpft. Weitere Informationen zu den Konzepten von Fidelity-Berichten finden Sie unter[Fidelity-Bericht](automated-reasoning-checks-concepts.md#ar-concept-fidelity-report).
### Sehen Sie sich den Fidelity-Bericht in der Konsole an
Öffnen Sie in der Konsole Ihre Richtlinie und wählen Sie den Tab **Quelldokument** (neben **Definitionen**). In der Ansicht „**Quellinhalt**“ wird jede aus Ihrem Dokument extrahierte atomare Aussage als nummerierte Zeile in einer Tabelle angezeigt. Jede Zeile zeigt:
+ Die Nummer der Anweisung und der extrahierte Text.
+ Das **Quelldokument**, aus dem die Aussage stammt.
+ Die Anzahl der **Regeln**, die auf dieser Aussage beruhen.
+ Die Anzahl der **Variablen**, die auf dieser Anweisung basieren.
Verwenden Sie die Dropdownfilter **Regeln** und **Variablen** oben in der Tabelle, um sich auf Aussagen zu konzentrieren, die einer bestimmten Regel oder Variablen zugrunde liegen. Verwenden Sie die Suchleiste, um bestimmte Inhalte in den extrahierten Anweisungen zu finden.
Wenn Sie die Richtlinie nach der ersten Extraktion bearbeiten, z. B. indem Sie Regeln ändern oder Variablen hinzufügen, wählen Sie die Schaltfläche „Erneut **generieren**“, um den Zuverlässigkeitsbericht so zu aktualisieren, dass er Ihre aktuelle Richtliniendefinition widerspiegelt.
### Überprüfen Sie den Treuebericht mithilfe der API
Verwenden Sie `GetAutomatedReasoningPolicyBuildWorkflowResultAssets` with`--asset-type FIDELITY_REPORT`, um den Treuebericht abzurufen. Um den Bericht nach Richtlinienänderungen erneut zu generieren, verwenden Sie ihn `StartAutomatedReasoningPolicyBuildWorkflow` zusammen mit dem Workflowtyp Build `GENERATE_FIDELITY_REPORT` und geben Sie die Quelldokumente in das `generateFidelityReportContent` Feld ein. Der Workflow analysiert die Dokumente erneut anhand der aktuellen Richtliniendefinition und erstellt einen neuen Zuverlässigkeitsbericht. Sie können auch die ursprünglichen Quelldokumente aus einem früheren Build-Workflow abrufen, indem Sie den `--asset-id` Parameter verwenden `--asset-type SOURCE_DOCUMENT` (die Asset-ID aus dem Asset-Manifest abrufen).
### Worauf zu achten ist
Achten Sie bei der Lektüre des APIs Kundenbindungsberichts von auf Folgendes:
+ **Niedriger Deckungsgrad.** Ein niedriger Deckungsgrad weist darauf hin, dass erhebliche Teile Ihres Quelldokuments nicht in der Richtlinie erfasst wurden. Suchen Sie in der Ansicht des Quellinhalts nach Aussagen mit 0 Regeln und 0 Variablen, um festzustellen, welche Teile des Dokuments übersehen wurden, und erwägen Sie, die fehlenden Inhalte durch iteratives Erstellen von Richtlinien hinzuzufügen. Siehe [Iterative Politikgestaltung](#iterative-policy-building).
+ **Niedriger Genauigkeitswert für einzelne Regeln.** Jede Regel hat ihren eigenen Genauigkeitswert und ihre eigene Begründung. Regeln mit niedrigen Genauigkeitswerten geben das Ausgangsmaterial möglicherweise nicht originalgetreu wieder. Verwenden Sie den Filter **Regeln**, um die Grundaussagen für eine bestimmte Regel zu isolieren und sie mit der formalen Logik der Regel zu vergleichen, um Fehlinterpretationen zu identifizieren.
+ **Ungerundete Regeln oder Variablen.** Regeln oder Variablen, denen grundlegende Aussagen fehlen, wurden möglicherweise abgeleitet und nicht direkt aus dem Dokument extrahiert. Vergewissern Sie sich, dass diese korrekt sind, oder entfernen Sie sie, wenn sie nicht Ihrer Absicht entsprechen.
**Tipp**
Der Fidelity-Bericht ist besonders nützlich für die Zusammenarbeit mit Fachexperten, die das Quelldokument verfasst haben. Teilen Sie ihnen die Ansicht des **Quelldokuments** mit, damit sie überprüfen können, ob die Richtlinie ihre Absicht korrekt wiedergibt, ohne die formalen Logikregeln direkt lesen zu müssen.
## Iterative Politikgestaltung
Bei komplexen Domänen sollten Sie Ihre Richtlinie schrittweise erstellen, anstatt zu versuchen, alles in einem einzigen Upload zu erfassen. Beginnen Sie mit einer bestimmten Teilmenge Ihrer Regeln, erstellen und testen Sie die Richtlinie und fügen Sie dann in nachfolgenden Iterationen weitere Inhalte hinzu.
### Fügen Sie Inhalte in der Konsole hinzu
1. Öffnen Sie Ihre Richtlinie für automatisiertes Denken in der Konsole.
1. Wählen Sie auf der **Definitionsseite** die Option **Importieren** aus.
1. Wählen Sie die Option, um den neuen Inhalt mit der vorhandenen Richtliniendefinition zusammenzuführen.
1. Laden Sie den zusätzlichen Quellinhalt hoch oder fügen Sie ihn ein.
1. Überprüfen Sie die aktualisierte Richtliniendefinition und lösen Sie alle neuen Konflikte oder Duplikate.
### Fügen Sie Inhalte mithilfe der API hinzu
Rufen Sie `StartAutomatedReasoningPolicyBuildWorkflow` mit an `INGEST_CONTENT` und übergeben Sie die vollständige aktuelle Richtliniendefinition zusammen mit dem neuen Dokument. Sie müssen die vollständige bestehende Definition — Regeln, Variablen und Typen — angeben, damit der neue Inhalt mit der vorhandenen Richtlinie zusammengeführt wird, anstatt sie zu ersetzen.
```
# First, retrieve the current policy definition
aws bedrock get-automated-reasoning-policy \
--policy-arn arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk
# Encode the new document
PDF_BASE64=$(base64 -i additional-rules.pdf | tr -d '\n')
# Start a build workflow with the existing definition + new document
aws bedrock start-automated-reasoning-policy-build-workflow \
--policy-arn arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk \
--build-workflow-type INGEST_CONTENT \
--source-content "{
\"policyDefinition\": EXISTING_POLICY_DEFINITION_JSON,
\"workflowContent\": {
\"documents\": [
{
\"document\": \"$PDF_BASE64\",
\"documentContentType\": \"pdf\",
\"documentName\": \"Additional Benefits Rules\",
\"documentDescription\": \"Additional rules covering medical and bereavement leave eligibility.\"
}
]
}
}"
```
**Wichtig**
Die API unterstützt maximal 2 Build-Workflows pro Richtlinie, wobei `IN_PROGRESS` jeweils nur einer zulässig ist. Wenn Sie einen neuen Build starten müssen und bereits über 2 Workflows verfügen, löschen Sie zuerst einen alten mit`DeleteAutomatedReasoningPolicyBuildWorkflow`.
## KMS-Berechtigungen für Automated-Reasoning-Richtlinien
Wenn Sie einen vom Kunden verwalteten KMS-Schlüssel zur Verschlüsselung Ihrer Automated-Reasoning-Richtlinie angeben, müssen Sie Berechtigungen konfigurieren, mit denen Amazon Bedrock den Schlüssel in Ihrem Namen verwenden kann.
### Berechtigungen für Schlüsselrichtlinien
Fügen Sie Ihrer KMS-Schlüsselrichtlinie die folgende Anweisung hinzu, sodass Amazon Bedrock den Schlüssel für Automated-Reasoning-Richtlinien verwenden kann:
```
{
"Sid": "PermissionsForAutomatedReasoningPolicy",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:user/role"
},
"Action": [
"kms:Decrypt",
"kms:DescribeKey",
"kms:GenerateDataKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:EncryptionContext:aws:bedrock:automated-reasoning-policy": [
"arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/policy-id",
"arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/policy-id:*"
],
"kms:ViaService": "bedrock.us-east-1.amazonaws.com"
}
}
}
```
### IAM-Berechtigungen
Ihr IAM-Prinzipal muss über die folgenden Berechtigungen verfügen, um einen vom Kunden verwalteten KMS-Schlüssel mit Automated-Reasoning-Richtlinien verwenden zu können:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowKMSForAutomatedReasoningPolicy",
"Effect": "Allow",
"Action": [
"kms:Decrypt",
"kms:DescribeKey",
"kms:GenerateDataKey"
],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/key-id",
"Condition": {
"StringEquals": {
"kms:EncryptionContext:aws:bedrock:automated-reasoning-policy": [
"arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/policy-id",
"arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/policy-id:*"
],
"kms:ViaService": "bedrock.us-east-1.amazonaws.com"
}
}
}
]
}
```
### Verschlüsselungskontext
Amazon Bedrock verwendet den Verschlüsselungskontext, um zusätzliche Sicherheit für Ihre Automated-Reasoning-Richtlinien zu bieten. Der Verschlüsselungskontext besteht aus einer Reihe von Schlüssel-Wert-Paaren, die als zusätzliche authentifizierte Daten beim Verschlüsseln und Entschlüsseln Ihrer Richtlinie verwendet werden.
Für Automated-Reasoning-Richtlinien verwendet Amazon Bedrock den folgenden Verschlüsselungskontext:
+ **Schlüssel**: `aws:bedrock:automated-reasoning-policy`
+ **Wert:** Der Amazon-Ressourcenname (ARN) Ihrer Automated Reasoning-Richtlinie
# Bewährte Methoden für Richtlinien zur automatisierten Argumentation
Auf dieser Seite werden bewährte Verfahren für die Erstellung und Pflege von Richtlinien für automatisiertes Denken zusammengefasst. Lesen Sie dies, bevor Sie Ihre erste Richtlinie erstellen, und greifen Sie beim Debuggen von Problemen darauf zurück. Die konzeptionellen Grundlagen dieser Verfahren finden Sie unter[Automatisiertes Denken überprüft Konzepte](automated-reasoning-checks-concepts.md). Anweisungen zur step-by-step Erstellung finden Sie unter[Erstellen der Automated-Reasoning-Richtlinie](create-automated-reasoning-policy.md).
## Fangen Sie einfach an und wiederholen Sie
Der häufigste Fehler bei der Erstellung einer Richtlinie für automatisiertes Denken ist der Versuch, ein ganzes komplexes Dokument in einem einzigen Durchgang zu erfassen. Beginnen Sie stattdessen mit einer bestimmten Teilmenge Ihrer Regeln und bauen Sie diese schrittweise auf.
1. Wählen Sie einen einzelnen, klar definierten Abschnitt Ihres Quelldokuments aus (z. B. den Anspruch auf Elternzeit aus einem Personalhandbuch).
1. Erstellen Sie eine Richtlinie aus diesem Abschnitt und überprüfen Sie die extrahierten Regeln und Variablen.
1. Schreiben Sie Tests, die die wichtigsten Szenarien für diesen Abschnitt abdecken.
1. Beheben Sie alle Probleme, bevor Sie weitere Inhalte hinzufügen.
1. Verwenden Sie die iterative Richtlinienerstellung, um weitere Abschnitte nacheinander zusammenzuführen. Weitere Informationen finden Sie unter [Iterative Politikgestaltung](create-automated-reasoning-policy.md#iterative-policy-building).
Dieser Ansatz hat zwei Vorteile: Er erleichtert die Isolierung von Problemen (Sie wissen, in welchem Abschnitt ein Problem aufgetreten ist), und die Richtlinie bleibt während der Entwicklung überschaubar. Eine Richtlinie mit 10 gut getesteten Regeln ist nützlicher als eine mit 100 ungetesteten Regeln.
## Dokumente mit einem LLM vorverarbeiten
Bei Dokumenten, die umfangreich sind, erzählende Texte enthalten oder Regeln mit Inhalten kombinieren, die nicht den Regeln entsprechen (wie z. B. Haftungsausschlüsse oder organisatorischer Hintergrund), sollten Sie das Dokument zunächst einem LLM unterziehen, bevor Sie es zur automatischen Prüfung von Argumenten hochladen. Bitten Sie den LLM, den Inhalt als explizite Wenn-Dann-Regeln zu extrahieren. Dieser Vorverarbeitungsschritt verbessert die Qualität der extrahierten Richtlinie erheblich, da automatische Argumentationsprüfungen am besten mit klaren, deklarativen Aussagen und nicht mit unstrukturiertem Text funktionieren.
Fügen Sie beim Schreiben Ihrer Aufforderung zur Vorverarbeitung die folgenden Anweisungen für das LLM bei:
+ Extrahieren Sie Regeln im Wenn-Dann-Format mit klaren Bedingungen und Konsequenzen.
+ Behalten Sie alle Bedingungen, logischen Operatoren (UND, ODER, NICHT), Quantifizierer („mindestens“, „höchstens“) und Ausnahmeklauseln („außer“, „außer wenn“) bei.
+ Fügen Sie vernünftige Regeln für vernünftige Einschränkungen hinzu — wie „Kontostand darf nicht negativ sein“ oder „Kredit-Score muss zwischen 300 und 850 liegen“ —, die in Ihrer Police zu Grenzregeln führen (siehe). [Überprüfen von Bereichen für numerische Werte](#bp-validate-ranges)
**Wichtig**
Vergleichen Sie immer die Ergebnisse des LLM mit Ihrem Originaldokument, bevor Sie es als Quelltext verwenden. LLMs kann Regeln, die in der Quelle nicht vorhanden sind, halluzinieren, Bedingungen falsch interpretieren oder wichtige Ausnahmen weglassen. Der Schritt der Vorverarbeitung ist ein Ausgangspunkt und kein Ersatz für eine Überprüfung durch einen Menschen.
Ausführliche Vorlagen für Eingabeaufforderungen und einen Arbeitsablauf für die step-by-step Vorverarbeitung finden Sie unter. [(Optional) Verwenden Sie ein LLM, um Dokumente als logische Regeln umzuschreiben](create-automated-reasoning-policy.md#preprocess-with-llm)
## Verwenden Sie Implikationen (=>), um Regeln zu strukturieren
Das Wenn-Dann-Format (unter Verwendung des `=>` Implikationsoperators) ist das wichtigste Muster beim Schreiben von Regeln. Jede Regel, die eine bedingte Beziehung ausdrückt, sollte dieses Format verwenden.
| Gut: Implikation | Schlecht: Bloße Behauptung |
| --- | --- |
| (=> (and isFullTime (> tenureMonths 12)) eligibleForParentalLeave) | eligibleForParentalLeave |
| (=> (> loanAmount 500000) requiresCosigner) | requiresCosigner |
Bloße Behauptungen (Regeln ohne Wenn-Dann-Struktur) erzeugen Axiome — Aussagen, die immer wahr sind. Anhand dieser Behauptung `eligibleForParentalLeave` überprüft Automated Reasoning, ob die Inanspruchnahme des Elternurlaubs immer zutrifft, unabhängig von etwaigen Bedingungen. Jede Eingabe, die besagt, dass der Benutzer *nicht* berechtigt ist, würde zurückgegeben, `IMPOSSIBLE` weil sie diesem Axiom widerspricht.
Bloße Behauptungen eignen sich nur für Randbedingungen, die immer gelten sollten, wie zum Beispiel:
```
;; Account balance can never be negative
(>= accountBalance 0)
;; Interest rate is always between 0 and 1
(and (>= interestRate 0) (<= interestRate 1))
```
Wenn Sie in Ihrer extrahierten Richtlinie bloße Assertionen finden, schreiben Sie sie als Bedingungen um oder löschen Sie sie. Weitere Informationen zur Überprüfung Ihrer extrahierten Richtlinie finden Sie unter. [Überprüfen Sie die extrahierte Richtlinie](create-automated-reasoning-policy.md#review-extracted-policy)
## Verfassen Sie umfassende Variablenbeschreibungen
Variablenbeschreibungen sind der Hauptfaktor für die Genauigkeit der Übersetzung. Wenn automatische Argumentationsprüfungen natürliche Sprache in formale Logik übersetzen, wird anhand von Variablenbeschreibungen bestimmt, welche Variablen den im Text erwähnten Konzepten entsprechen. Vage oder unvollständige Beschreibungen sind die häufigste Ursache für Ergebnisse. `TRANSLATION_AMBIGUOUS`
Eine gute Variablenbeschreibung sollte vier Fragen beantworten:
1. **Was bedeutet diese Variable?** Erklären Sie das Konzept im Klartext.
1. **Welche Einheit oder welches Format verwendet es?** Geben Sie Einheiten (Monate, Dollar, Prozentsatz als Dezimalzahl) und alle Umrechnungsregeln an.
1. **Wie könnten sich Benutzer auf dieses Konzept beziehen?** Fügen Sie Synonyme, alternative Formulierungen und übliche Ausdrucksweisen hinzu, mit denen Benutzer dieses Konzept in der Alltagssprache ausdrücken.
1. **Was sind die Randbedingungen?** Beschreiben Sie Grenzfälle, Standardwerte und was die Variable bedeutet, wenn sie auf bestimmte Werte gesetzt wird.
**Beispiel: Vorher und nachher**
| Vage (verursacht Übersetzungsfehler) | Detailliert (übersetzt zuverlässig) |
| --- | --- |
| tenureMonths: „Wie lange der Mitarbeiter gearbeitet hat.“ | tenureMonths: „Die Anzahl der vollen Monate, in denen der Mitarbeiter ununterbrochen beschäftigt war. Wenn Benutzer Dienstjahre angeben, rechnen Sie diese in Monate um (z. B. 2 Jahre = 24 Monate). Bei Neueinstellungen, die ihren ersten Monat noch nicht abgeschlossen haben, auf 0 setzen.“ |
| isFullTime: „Vollzeitstatus“. | isFullTime: „Ob der Mitarbeiter Vollzeit (richtig) oder Teilzeit (falsch) arbeitet. Wird auf „true“ gesetzt, wenn Benutzer angeben, „Vollzeit“ zu arbeiten, „volle Stunden“ zu arbeiten oder mehr als 40 Stunden pro Woche zu arbeiten. Wird auf „Falsch“ gesetzt, wenn Benutzer angeben, dass sie „Teilzeit“, „reduzierte Arbeitszeiten“ oder weniger als 40 Stunden pro Woche arbeiten.“ |
| interestRate: „Der Zinssatz.“ | interestRate: „Der als Dezimalwert ausgedrückte jährliche Zinssatz, wobei 0,05 5% und 0,15 15% bedeuten. Wenn Benutzer einen Prozentsatz wie '5%' angeben, rechnen Sie ihn in die Dezimalform (0,05) um.“ |
## Verwenden Sie Boolesche Werte für nicht ausschließliche Staaten
Verwenden Sie bei der Modellierung von Staaten, die koexistieren können, separate boolesche Variablen anstelle einer einzelnen Aufzählung. Eine Person kann sowohl ein Veteran als auch ein Lehrer sein. Die Verwendung einer Aufzählung `customerType = {VETERAN, TEACHER}` erzwingt die Wahl zwischen ihnen, was zu einem logischen Widerspruch führt, wenn beide zutreffen.
| Gut: Separate Boolesche Werte | Schlecht: Enum für nicht ausschließliche Staaten |
| --- | --- |
| `isVeteran`(bool): „Ob der Kunde ein Militärveteran ist.“ `isTeacher`(bool): „Ob der Kunde ein Lehrer ist.“ | `customerType`(enum: VETERAN, TEACHER, STUDENT): „Der Kundentyp.“ Problem: Ein Kunde, der sowohl ein Veteran als auch ein Lehrer ist, kann nicht vertreten werden. |
Reservieren Sie Enumerationen für Kategorien, die sich wirklich gegenseitig ausschließen und für die jeweils nur ein Wert gelten kann, z. B. `leaveType = {PARENTAL, MEDICAL, BEREAVEMENT}` (ein Mitarbeiter kann jeweils nur eine Art von Urlaub beantragen). Weitere Informationen zu benutzerdefinierten Typen finden Sie unter[Benutzerdefinierte Typen (Aufzählungen)](automated-reasoning-checks-concepts.md#ar-concept-custom-types).
## Geben Sie Einheiten und Formate in Variablenbeschreibungen an
Unklarheiten in Bezug auf Einheiten sind eine häufige Ursache für Übersetzungsfehler. Wenn ein Benutzer sagt: „Ich arbeite seit 2 Jahren hier“ und Ihre Variable lautet`tenureMonths`, muss die Übersetzung wissen, dass Jahre in Monate umgerechnet werden können. Wenn Ihre Variablenbeschreibung die Einheit nicht spezifiziert, wird in der Übersetzung möglicherweise `tenureMonths = 2` anstelle von zugewiesen`tenureMonths = 24`.
Geben Sie immer an:
+ Die Maßeinheit (Monate, Tage, Dollar, Prozent).
+ Das Format (Dezimalzahl oder Prozentzahl, Datumsformat, Währung).
+ Konvertierungsregeln für gängige alternative Ausdrücke (z. B. „2 Jahre = 24 Monate“).
**Beispiele:**
+ `loanAmount`: „Der gesamte Kreditbetrag in US-Dollar. Wenn Benutzer Beträge in Tausend angeben (z. B. „500.000“), rechnen Sie sie in die vollständige Zahl um (500.000).“
+ `submissionDate`: „Die Anzahl der Tage nach dem Fälligkeitsdatum, an denen die Einreichung erfolgt ist. Ein Wert von 0 bedeutet, dass die Einreichung pünktlich war. Positive Werte deuten auf verspätete Einsendungen hin.“
## Überprüfen von Bereichen für numerische Werte
Fügen Sie für numerische Variablen Grenzregeln hinzu, die den gültigen Bereich einschränken. Dies verhindert logisch unmögliche Szenarien und trägt dazu bei, dass Prüfungen mit automatisiertem Denken aussagekräftigere Ergebnisse liefern.
```
;; Account balance cannot be negative
(>= accountBalance 0)
;; Interest rate must be between 0 and 1 (0% to 100%)
(and (>= interestRate 0) (<= interestRate 1))
;; Credit score ranges from 300 to 850
(and (>= creditScore 300) (<= creditScore 850))
;; Tenure in months cannot be negative
(>= tenureMonths 0)
```
Ohne diese Grenzregeln könnten bei Prüfungen mit automatisierter Argumentation Szenarien mit negativen Kontoständen oder Kredit-Scores über 1000 berücksichtigt werden, die in Ihrem Bereich bedeutungslos sind. Grenzregeln sind einer der wenigen Fälle, in denen bloße Behauptungen (Regeln nicht im Wenn-Dann-Format) angemessen sind.
## Verwenden Sie Zwischenvariablen für die Abstraktion
Wenn mehrere Regeln eine gemeinsame Bedingung haben, extrahieren Sie diese Bedingung in eine boolesche Zwischenvariable. Dadurch werden Ihre Regeln vereinfacht und die Richtlinie lässt sich leichter verwalten.
**Beispiel: Mitgliedschaftsstufen**
Anstatt die Mitgliedschaftsbedingung in jeder Leistungsregel zu wiederholen:
```
;; Without intermediate variable (repetitive)
(=> (and (> purchaseTotal 1000) (> accountAge 12)) eligibleForFreeShipping)
(=> (and (> purchaseTotal 1000) (> accountAge 12)) eligibleForPrioritySupport)
(=> (and (> purchaseTotal 1000) (> accountAge 12)) eligibleForEarlyAccess)
```
Definieren Sie eine Zwischenvariable und verweisen Sie darauf:
```
;; With intermediate variable (cleaner)
(=> (and (> purchaseTotal 1000) (> accountAge 12)) isPremiumMember)
(=> isPremiumMember eligibleForFreeShipping)
(=> isPremiumMember eligibleForPrioritySupport)
(=> isPremiumMember eligibleForEarlyAccess)
```
Dieses Muster macht es einfacher, die Mitgliedschaftskriterien später zu aktualisieren — Sie müssen nur eine Regel statt drei ändern.
## Verwenden Sie Aufzählungen für die Kategorisierung
Wenn eine Variable eine Kategorie mit einem festen Satz sich gegenseitig ausschließender Werte darstellt, verwenden Sie einen benutzerdefinierten Typ (Enum) anstelle mehrerer boolescher Werte oder einer Zeichenfolge. Aufzählungen schränken die möglichen Werte ein und machen die Regeln klarer.
| Gut: Enum | Vermeiden Sie: Mehrere boolesche Werte für exklusive Staaten |
| --- | --- |
| Typ: `LeaveType = {PARENTAL, MEDICAL, BEREAVEMENT, PERSONAL}` Variable: `leaveType` () LeaveType Regel: `(=> (= leaveType PARENTAL) (>= leaveDays 60))` | `isParentalLeave` (bool) `isMedicalLeave` (bool) `isBereavementLeave` (bool) Problem: Nichts verhindert, dass mehrere boolesche Werte gleichzeitig wahr sind. |
**Tipp**
Nehmen Sie einen `OTHER` `NONE` Oder-Wert in Ihre Enumeration auf, wenn es möglich ist, dass die Eingabe keiner der definierten Kategorien entspricht. Dadurch werden Übersetzungsprobleme vermieden, wenn die Eingabe nicht genau in einen der definierten Werte passt.
## Halten Sie die Logik deklarativ und nicht prozedural
Richtlinien für automatisiertes Denken beschreiben, *was wahr ist*, und nicht, *wie man es berechnet*. Vermeiden Sie es, Regeln zu schreiben, die wie Code mit sequentiellen Schritten oder Rangfolgerlogik aussehen.
| Gut: Deklarativ | Vermeiden Sie: Prozedurales Denken |
| --- | --- |
| „Wenn der Arbeitnehmer in Vollzeit arbeitet und mehr als 12 Monate angestellt ist, hat er Anspruch auf Elternzeit.“ Dies besagt eine Tatsache über den Zusammenhang zwischen Bedingungen und Ergebnissen. | „Prüfen Sie zunächst, ob der Mitarbeiter Vollzeit beschäftigt ist. Falls ja, überprüfen Sie die Beschäftigungsdauer. Wenn die Amtszeit mehr als 12 Monate beträgt, setzen Sie die Eignung auf „true“. Dies beschreibt ein Verfahren, keine logische Beziehung. |
Vermeiden Sie in ähnlicher Weise den Vorrang der Kodierung oder die Priorität zwischen Regeln. In der formalen Logik gelten alle Regeln gleichzeitig. Wenn Sie ausdrücken müssen, dass eine Bedingung eine andere überschreibt, kodieren Sie sie explizit in den Regelbedingungen:
```
;; GOOD: Explicit exception handling
;; General rule: full-time employees with 12+ months get parental leave
(=> (and isFullTime (> tenureMonths 12) (not isOnProbation))
eligibleForParentalLeave)
;; BAD: Trying to encode precedence
;; "Rule 1 takes priority over Rule 2" — this concept doesn't exist
;; in formal logic. Instead, combine the conditions into a single rule.
```
## Namenskonventionen
Eine konsistente Benennung erleichtert das Lesen, Verwalten und Debuggen von Richtlinien. Halten Sie sich an diese Konventionen:
+ **Boolesche Variablen:** Verwenden Sie das Präfix `is` oder`has`. Zum Beispiel: `isFullTime`, `hasDirectDeposit`, `isEligibleForLeave`.
+ **Numerische Variablen: Nehmen** Sie die Einheit in den Namen auf. Zum Beispiel: `tenureMonths`, `loanAmountUSD`, `creditScore`.
+ **Aufzählungstypen: Wird** PascalCase für Typnamen und UPPER\$1SNAKE\$1CASE für Werte verwendet. Beispiel: `LeaveType = {PARENTAL, MEDICAL, BEREAVEMENT}`.
+ **Variablen:** Verwenden Sie CamelCase. Zum Beispiel: `tenureMonths`, `isFullTime`, `leaveType`.
Vermeiden Sie Abkürzungen, die mehrdeutig sein könnten. Verwenden Sie `tenureMonths` statt `tenMo` und `isFullTime` anstelle von. `ft` Klare Namen helfen sowohl menschlichen Prüfern als auch dem Übersetzungsprozess.
## Gängige Anti-Muster
Die folgenden Muster führen häufig zu Problemen mit Richtlinien für automatisiertes Denken. Wenn Sie auf unerwartete Testergebnisse stoßen, überprüfen Sie, ob Ihre Richtlinie eines dieser Anti-Muster enthält.
### Axiome statt Implikationen
Wie unter beschrieben[Verwenden Sie Implikationen (=>), um Regeln zu strukturieren](#bp-use-implications), führen bloße Behauptungen zu Axiomen, die immer wahr sind. Dies ist das gängigste Anti-Pattern und das schädlichste — es führt dazu, dass ganze Kategorien von Eingaben zurückkehren. `IMPOSSIBLE`
**Symptom:** Tests, die `IMPOSSIBLE` stattdessen zurückkehren `VALID` oder `INVALID` zurückkehren sollten.
**Lösung:** Suchen Sie in Ihren Regeln nach bloßen Behauptungen und schreiben Sie sie als Implikationen um, oder löschen Sie sie, wenn sie keine Randbedingungen darstellen.
### Überlappende Variablen
Zwei Variablen, die für dieselben oder ähnliche Konzepte stehen (z. B. `tenureMonths` und`monthsOfService`), verwirren den Übersetzungsprozess. Automatisierte Argumentationsprüfungen können nicht bestimmen, welche Variable für ein bestimmtes Konzept verwendet werden soll, was zu inkonsistenten Übersetzungen und Ergebnissen führt. `TRANSLATION_AMBIGUOUS`
**Symptom:** Tests werden `TRANSLATION_AMBIGUOUS` auch bei klarem, eindeutigem Eingabetext zurückgegeben.
**Behebung:** Fügt überlappende Variablen zu einer einzigen Variablen mit einer umfassenden Beschreibung zusammen. Aktualisieren Sie alle Regeln, die auf die gelöschte Variable verweisen.
### Zu komplexe Richtlinien
Richtlinien mit zu vielen Variablen, tief verschachtelten Bedingungen oder nichtlinearer Arithmetik können die Verarbeitungsgrenzen überschreiten und Ergebnisse zurückgeben. `TOO_COMPLEX`
**Symptom:** Tests kehren zurück `TOO_COMPLEX` oder es kommt zu einem Timeout.
**Behebung:** Vereinfachen Sie die Richtlinie. Entfernen Sie ungenutzte Variablen, zerlegen Sie komplexe Regeln mithilfe von Zwischenvariablen in einfachere Regeln und vermeiden Sie nichtlineare Arithmetik (Exponenten, irrationale Zahlen). Wenn Ihre Domain wirklich komplex ist, sollten Sie erwägen, sie in mehrere fokussierte Richtlinien aufzuteilen.
### Widersprüchliche Regeln
Widersprüchliche Regeln machen es Automated Reasoning Checks unmöglich, zu einem Ergebnis zu gelangen. Eine Regel besagt beispielsweise, dass Vollzeitbeschäftigte Anspruch auf Urlaub haben, während eine andere besagt, dass Mitarbeiter in ihrem ersten Jahr keinen Anspruch darauf haben — ohne zu spezifizieren, was mit Vollzeitbeschäftigten im ersten Jahr passiert.
**Symptom:** Tests geben zurück`IMPOSSIBLE`, ob Eingaben vorliegen, die widersprüchliche Regeln beinhalten.
**Behebung:** Überprüfen Sie den Qualitätsbericht auf widersprüchliche Regeln. Lösen Sie Konflikte, indem Sie die Regeln zu einer einzigen Regel mit expliziten Bedingungen zusammenführen oder indem Sie eine der widersprüchlichen Regeln löschen. Weitere Informationen finden Sie unter [Überprüfen Sie die extrahierte Richtlinie](create-automated-reasoning-policy.md#review-extracted-policy).
### Unbenutzte Variablen
Variablen, auf die keine Regeln verweisen, stören den Übersetzungsprozess. Bei der Übersetzung können ungenutzten Variablen Werte zugewiesen werden, wodurch Verarbeitungskapazität verschwendet wird und möglicherweise `TRANSLATION_AMBIGUOUS` Ergebnisse erzielt werden, wenn die ungenutzte Variable mit einer ähnlichen aktiven Variablen konkurriert.
**Symptom:** Unerwartete `TRANSLATION_AMBIGUOUS` Ergebnisse oder Übersetzungen, bei denen Variablen Werte zugewiesen werden, die keine Regeln beeinflussen.
**Behebung:** Löschen Sie nicht verwendete Variablen. Suchen Sie in der Konsole nach Warnindikatoren neben Variablen. Überprüfen Sie über die API den Qualitätsbericht von `GetAutomatedReasoningPolicyBuildWorkflowResultAssets` mit`--asset-type QUALITY_REPORT`.
### Fehlende Enum-Werte
Wenn Ihre Aufzählung nicht für jede mögliche Kategorie, die Benutzer möglicherweise erwähnen, einen Wert enthält, schlägt die Übersetzung möglicherweise fehl oder führt zu unerwarteten Ergebnissen, wenn die Eingabe keinem definierten Wert entspricht.
**Symptom:** Tests geben `TRANSLATION_AMBIGUOUS` oder zurück, `NO_TRANSLATIONS` wenn in der Eingabe eine Kategorie erwähnt wird, die nicht in der Aufzählung enthalten ist.
**Lösung:** Fügen Sie Ihrer Aufzählung einen `NONE` Wert `OTHER` oder hinzu, um Eingaben zu verarbeiten, die nicht den definierten Kategorien entsprechen. Aktualisieren Sie die Beschreibungen der Aufzählungswerte, um zu verdeutlichen, wann die einzelnen Werte zutreffen.
# Testen einer Automated-Reasoning-Richtlinie
Durch Tests wird bestätigt, dass die Regeln Ihrer Richtlinie korrekt sind und dass automatische Argumentationsprüfungen natürliche Sprache korrekt in formale Logik übersetzen können. Sie testen eine Richtlinie, indem Sie Aussagen in natürlicher Sprache zur Bestätigung senden und anschließend das Feedback überprüfen, um sicherzustellen, dass die Übersetzung die richtigen Variablen verwendet und dass die Regeln zu den erwarteten Ergebnissen führen.
Es gibt zwei sich ergänzende Testansätze: generierte Szenarien und question-and-answer (QnA-) Tests. Jeder zielt auf einen anderen Teil der Validierungspipeline ab. Der empfohlene Arbeitsablauf besteht darin, mit Szenarien zur Überprüfung der Regelkorrektheit zu beginnen und dann QnA-Tests hinzuzufügen, um die Genauigkeit der Übersetzung zu überprüfen.
## Teststrategie: Szenarien im Vergleich zu QnA-Tests
Automatisierte Reasoning-Checks validieren Inhalte in zwei Schritten: Zunächst übersetzen Grundmodelle natürliche Sprache in formale Logik; anschließend verifizieren mathematische Techniken die Logik anhand Ihrer Richtlinienregeln. Jeder Testansatz zielt auf einen anderen Schritt in dieser Pipeline ab.
### Generierte Szenarien (Richtigkeit der Testregeln)
Generierte Szenarien testen die *Semantik, die in Ihren Richtlinienregeln kodiert* ist, direkt. Sie entfernen die Unsicherheit der Übersetzung in natürlicher Sprache aus der Gleichung und isolieren so, ob die Regeln selbst korrekt sind.
Szenarien werden anhand Ihrer Richtlinienregeln generiert und stellen Situationen dar, die aufgrund dieser Regeln logisch möglich sind. Sie werden so sortiert, dass die meisten likely-to-be-wrong Szenarien zuerst angezeigt werden. Für jedes Szenario überprüfen Sie die Variablenzuweisungen und entscheiden:
+ **Daumen hoch** — Das Szenario ist realistisch und sollte tatsächlich möglich sein. Speichern Sie es als `SATISFIABLE` Test.
+ **Daumen runter** — Etwas stimmt nicht. Das Szenario sollte angesichts Ihrer Fachkenntnisse nicht möglich sein. Geben Sie Feedback in natürlicher Sprache, um zu erklären, warum. Automatisierte Argumentationsprüfungen werden dann versuchen, die notwendigen Regeländerungen abzuleiten.
**Beispiel:** Laut Ihrer Versicherungspolice haben Vollzeitbeschäftigte mit einer Betriebszugehörigkeit von mehr als 12 Monaten Anspruch auf Elternzeit. Ein generiertes Szenario könnte angezeigt werden. `isFullTime = true, tenureMonths = 3, eligibleForParentalLeave = true` Wenn dieses Szenario nicht möglich sein sollte (weil 3 Monate weniger als 12 sind), würden Sie es mit einem Daumen nach unten bewerten und erklären, dass Mitarbeiter mindestens 12 Monate Anstellung benötigen. Dies deutet auf eine fehlende oder falsche Regel hin.
Verwenden Sie Szenarien als *ersten* Testschritt. Sie helfen Ihnen, Regelprobleme zu erkennen, bevor Sie Zeit mit dem Schreiben von QnA-Tests verbringen.
### QnA-Tests (Genauigkeit der Übersetzung testen)
QnA-Tests validieren die *gesamte Pipeline end-to-end*: Übersetzung in natürlicher Sprache und Regelvalidierung zusammen. Sie ahmen echte Benutzerinteraktionen nach und catch Übersetzungsprobleme, die Szenarien nicht erkennen können.
Jeder QnA-Test besteht aus:
+ Eine **Eingabe** (optional) — Die Frage, die ein Benutzer Ihrer Anwendung stellen könnte.
+ Eine **Ausgabe** — Die Antwort, die Ihr Foundation-Modell möglicherweise generiert.
+ Ein **erwartetes Ergebnis** — Das von Ihnen erwartete Überprüfungsergebnis (z. B. `VALID` oder`INVALID`).
**Beispiel:** Für dieselbe Elternurlaubsrichtlinie könnte ein QnA-Test wie folgt lauten: input = „Ich arbeite hier seit 2 Jahren in Vollzeit. Kann ich Elternzeit nehmen?“ , output = „Ja, Sie haben Anspruch auf Elternzeit. „, erwartetes Ergebnis =`VALID`. Dies testet, ob Automated Reasoning die korrekte Übersetzung von „2 Jahren“ in `tenureMonths = 24` und „Vollzeit“ in korrekt überprüft. `isFullTime = true`
**Tipp**
Erstellen Sie Tests, die sowohl gültige als auch ungültige Szenarien abdecken. Wenn in Ihrer Richtlinie beispielsweise angegeben ist, dass Mitarbeiter während des Elternurlaubs ein Jahr Betriebszugehörigkeit benötigen, erstellen Sie Tests für Antworten, die diese Regel korrekt angeben, *und* Tests für Antworten, die fälschlicherweise eine andere Anforderung angeben.
### Empfohlener Test-Workflow
1. **Generieren und überprüfen Sie Szenarien.** Beginnen Sie hier, um zu überprüfen, ob Ihre Regeln korrekt sind. Beheben Sie alle Regelprobleme, bevor Sie fortfahren.
1. **Schreiben Sie QnA-Tests für wichtige Anwendungsfälle.** Konzentrieren Sie sich auf die Fragen, die Ihre Benutzer am wahrscheinlichsten stellen werden, und auf die Antworten, die Ihr LLM am wahrscheinlichsten generiert. Schließen Sie Randfälle und Randbedingungen mit ein.
1. **Führen Sie alle Tests aus.** Stellen Sie sicher, dass sowohl die Szenarien als auch die QnA-Tests erfolgreich sind.
1. **Iterieren Sie.** Wenn Tests fehlschlagen, stellen Sie fest, ob das Problem in den Regeln (korrigieren Sie die Richtlinie) oder in der Übersetzung (Verbesserung der Variablenbeschreibungen) liegt. Weitere Informationen finden Sie unter [Beheben Sie Fehler und verfeinern Sie Ihre Richtlinie für automatisiertes Denken](address-failed-automated-reasoning-tests.md).
## Generieren Sie Testszenarien automatisch in der Konsole
1. Gehen Sie zu der Automated Reasoning-Richtlinie, die Sie testen möchten (z. B. **MyHrPolicy**).
1. Wählen Sie **Tests anzeigen** und anschließend **Generieren** aus.
1. Überprüfen **Sie im Dialogfeld „Szenarien generieren**“ das generierte Szenario und die zugehörigen Regeln. Jedes Szenario zeigt eine Reihe von Variablenzuweisungen, die aufgrund Ihrer Richtlinienregeln logisch möglich sind. Prüfen Sie, ob das Szenario in Ihrem Bereich realistisch ist:
+ Wenn das Szenario in Ihrer Domain passieren könnte (es ist *zufriedenstellend*), wählen Sie das Daumen-hoch-Symbol aus. Dadurch wird das Szenario als Test gespeichert, der ein Ergebnis erwartet. `SATISFIABLE`
+ Wenn das Szenario nicht möglich sein sollte, wählen Sie das Symbol mit dem Daumen nach unten. Erläutern Sie in einer Anmerkung, warum das so ist — zum Beispiel: „Mitarbeiter müssen mindestens 12 Monate für Elternzeit angestellt sein, aber in diesem Szenario sind 3 Monate angegeben, für die ein Anspruch besteht.“ Automatisierte Prüfungen zur Argumentation verwenden Ihr Feedback, um Regeländerungen abzuleiten, die dieses Szenario verhindern würden.
+ Wenn Sie ein anderes Szenario wünschen, wählen Sie Szenario **neu** generieren.
**Tipp**
Um die formale Logikversion des Szenarios zu überprüfen, aktivieren Sie **Show SMT-LIB**. Dies ist nützlich, um genau zu verstehen, um welche Regeln und Variablenzuweisungen es sich handelt.
1. Wählen Sie **Speichern und schließen** aus, um den Test zu speichern, oder **Speichern und weitere hinzufügen**, um die Überprüfung der Szenarien fortzusetzen.
1. Wenn Sie Anmerkungen (Feedback mit dem Daumen nach unten) zu einem Szenario bereitgestellt haben, wählen Sie Anmerkungen **anwenden** aus. Automatisierte Prüfungen zur Argumentation starten einen Build-Workflow, um die Änderungen auf der Grundlage Ihres Feedbacks auf Ihre Richtlinie anzuwenden.
1. Prüfen Sie auf dem Bildschirm **„Richtlinienänderungen** überprüfen“ die vorgeschlagenen Änderungen an den Regeln, Variablen und Variablentypen Ihrer Richtlinie. Wählen Sie dann **Änderungen akzeptieren** aus.
## Generieren Sie mithilfe der API automatisch Testszenarien
Verwenden Sie die `GetAutomatedReasoningPolicyNextScenario` API, um generierte Testszenarien auf der Grundlage der Regeln Ihrer Richtlinie abzurufen.
`policyArn` (Erforderlich)
Der ARN der Automated Reasoning-Richtlinie.
`buildWorkflowId` (Erforderlich)
Die Kennung des Build-Workflows für die generierten Szenarien. Rufen Sie den neuesten Build-Workflow mithilfe der `ListAutomatedReasoningPolicyBuildWorkflows` API ab.
**Beispiel:**
```
aws bedrock get-automated-reasoning-policy-next-scenario \
--policy-arn "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk" \
--build-workflow-id d40fa7fc-351e-47d8-a338-53e4b3b1c690
```
Die Antwort umfasst ein generiertes Szenario mit Variablenzuweisungen und den zugehörigen Richtlinienregeln. Überprüfen Sie das Szenario und verwenden Sie die `CreateAutomatedReasoningPolicyTestCase` API, um es als Test zu speichern, oder verwenden Sie die Anmerkung, APIs um Feedback zu geben, falls das Szenario ein Regelproblem aufdeckt.
## Erstellen Sie einen QnA-Test manuell in der Konsole
1. Gehen Sie zu der Automated Reasoning-Richtlinie, die Sie testen möchten (z. B. **MyHrPolicy**).
1. Wählen Sie **Tests anzeigen** und anschließend **Hinzufügen** aus.
1. Gehen Sie im Dialogfeld **Tests hinzufügen** wie folgt vor:
1. Geben Sie **unter Eingabe** (optional) die Frage ein, die ein Benutzer stellen könnte. Geben Sie **unter Ausgabe** die Antwort ein, die Ihr Basismodell möglicherweise liefern könnte. Zusammen bilden sie ein QnA-Paar, das testet, wie Ihre Richtlinie echte Benutzerinteraktionen validiert.
1. Wählen Sie das Ergebnis aus, das Sie vom Test erwarten (z. B. **Gültig** oder **Ungültig**).
1. (Optional) Wählen Sie einen **Konfidenzschwellenwert** aus, der das Mindestkonfidenzniveau für die Logikvalidierung darstellt. Bei automatisierten Prüfungen zum logischen Denken werden mehrere Methoden verwendet LLMs , um natürliche Sprache in Ergebnisse zu übersetzen. Es werden nur Ergebnisse zurückgegeben, die durch einen signifikanten Prozentsatz der LLM-Übersetzungen gestützt werden. Der Konfidenzschwellenwert definiert den Mindestprozentsatz an Unterstützung, der erforderlich ist, damit eine Übersetzung zu einem validem Ergebnis wird. Ergebnisse unter dem Schwellenwert werden als angezeigt. `TRANSLATION_AMBIGUOUS`
1. Wählen Sie **Speichern** aus, um den Test zu erstellen.
## Erstellen Sie mithilfe der API einen QnA-Test
Verwenden Sie die `CreateAutomatedReasoningPolicyTestCase` API, um einen Test programmgesteuert zu erstellen.
`policyArn` (Erforderlich)
Der ARN der Automated Reasoning-Richtlinie.
`queryContent` (optional)
Die Eingabeabfrage oder Aufforderung, die den Inhalt generiert hat, z. B. die Benutzerfrage. Dies bietet den Kontext für die Validierung.
`guardContent` (Erforderlich)
Der zu validierende Ausgabeinhalt — die Antwort des Foundation-Modells, deren Richtigkeit überprüft wird.
`expectedAggregatedFindingsResult` (optional)
Das erwartete Überprüfungsergebnis (z. B. `VALID` oder`INVALID`). Das tatsächliche Ergebnis wird bestimmt, indem die Ergebnisse nach Schweregrad sortiert und das schlechteste Ergebnis ausgewählt wird. Die Reihenfolge des Schweregrads vom schlechtesten zum besten lautet: `TRANSLATION_AMBIGUOUS``IMPOSSIBLE`,`INVALID`,,`SATISFIABLE`,`VALID`.
`confidenceThreshold` (optional)
Das Mindestkonfidenzniveau für die Logikvalidierung.
**Beispiel:**
```
aws bedrock create-automated-reasoning-policy-test-case \
--policy-arn "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk" \
--query-content "Can I take a leave of absence if I'm a part-time employee?" \
--guard-content "No, only full-time employees are eligible for leave of absence." \
--expected-aggregated-findings-result "VALID" \
--confidence-threshold 0.8
```
Beispielantwort:
```
{
"testCaseId": "test-12345abcde",
"policyArn": "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk"
}
```
## Tests ausführen
### Ausführen von Tests in der Konsole
1. Gehen Sie zu der Richtlinie für automatisiertes Denken, die Sie validieren möchten (z. B. **MyHrPolicy**).
1. Wählen Sie **Tests anzeigen** aus.
1. Führen Sie eine der folgenden Aktionen aus:
+ Um alle Tests auszuführen, wählen Sie **Alle Tests validieren** aus.
+ Um einen einzelnen Test auszuführen, klicken Sie auf die **Aktionsschaltfläche** neben dem Test und wählen Sie **Validieren** aus.
### Ausführen von Tests über die API
Verwenden Sie die `StartAutomatedReasoningPolicyTestWorkflow` API, um Tests auszuführen, und die `GetAutomatedReasoningPolicyTestResult` API, um Ergebnisse abzurufen.
`policyArn` (Erforderlich)
Der ARN der Automated Reasoning-Richtlinie.
`buildWorkflowId` (Erforderlich)
Die Kennung des Build-Workflows, anhand dessen die Tests ausgeführt werden sollen. Rufen Sie den neuesten Build-Workflow mithilfe der `ListAutomatedReasoningPolicyBuildWorkflows` API ab.
`testCaseIds` (optional)
Eine Liste der auszuführenden Testkennungen. Wenn nicht angegeben, werden alle Tests für die Richtlinie ausgeführt.
**Beispiel:**
```
# Run tests
aws bedrock start-automated-reasoning-policy-test-workflow \
--policy-arn "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk" \
--build-workflow-id d40fa7fc-351e-47d8-a338-53e4b3b1c690
# Get results for a specific test
aws bedrock get-automated-reasoning-policy-test-result \
--policy-arn "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk" \
--build-workflow-id d40fa7fc-351e-47d8-a338-53e4b3b1c690 \
--test-case-id test-12345abcde
```
Die Antwort umfasst detaillierte Testergebnisse mit Validierungsergebnissen und Ausführungsstatus. Verwenden Sie die `ListAutomatedReasoningPolicyTestResults` API, um alle Testergebnisse für einen Build-Workflow aufzulisten.
## Verstehen Sie die Testergebnisse
Wenn ein Test abgeschlossen ist, erhalten Sie eine Reihe von *Ergebnissen*. Jedes Ergebnis stellt eine aus Ihren Testeingaben gewonnene Tatsachenaussage zusammen mit dem Überprüfungsergebnis, den verwendeten Variablenzuweisungen und den Richtlinienregeln dar, die diese Schlussfolgerung stützen. Eine ausführliche Beschreibung der Ergebnisstruktur und aller Typen von Validierungsergebnissen finden Sie unter[Ergebnisse und Validierungsergebnisse](automated-reasoning-checks-concepts.md#ar-concept-findings).
### Aufbau eines Testergebnisses
Jedes Testergebnis beinhaltet:
+ **Erwartetes Ergebnis** — Das Ergebnis, das Sie bei der Erstellung des Tests festgelegt haben.
+ **Tatsächliches Ergebnis** — Das aggregierte Ergebnis der Ausführung des Tests. Dies wird bestimmt, indem die Ergebnisse nach Schweregrad sortiert und das schlechteste Ergebnis ausgewählt wird. Die Reihenfolge des Schweregrads vom schlechtesten zum besten lautet: `TRANSLATION_AMBIGUOUS``IMPOSSIBLE`,`INVALID`,,`SATISFIABLE`,`VALID`. Ein Test mit zwei `VALID` Ergebnissen und einem `IMPOSSIBLE` Ergebnis hat beispielsweise ein aggregiertes Ergebnis von`IMPOSSIBLE`.
+ **Ausführungsergebnis** — Ob der Test bestanden wurde (erwartete und tatsächliche Ergebnisse stimmen überein) oder ob er fehlgeschlagen ist.
+ **Ergebnisse** — Die individuellen Validierungsergebnisse. Jedes Ergebnis enthält die übersetzten Prämissen und Behauptungen, einen Vertrauenswert, variable Zuweisungen und die politischen Regeln, die die Schlussfolgerung stützen.
### Praktische Interpretation der Ergebnisse
In der folgenden Tabelle wird zusammengefasst, was jedes Validierungsergebnis in der Praxis bedeutet und welche Maßnahmen zu ergreifen sind, wenn Sie es in einem Test sehen. Die vollständige Referenz, einschließlich der Suchfelder und ausführlicher Beschreibungen, finden Sie unter[Referenz zu den Validierungsergebnissen](automated-reasoning-checks-concepts.md#ar-concept-validation-results).
| Ergebnis | Bedeutung | Vorgehensweise |
| --- | --- | --- |
| VALID | Die Behauptungen in der Antwort sind mathematisch bewiesen, dass sie unter Berücksichtigung der Prämissen und Ihrer Versicherungsbedingungen korrekt sind. Zu den Feststellungen gehören der Nachweis der Behauptungen und der claimsTrueScenario Nachweis, supportingRules dass die Behauptungen wahr sind. | Wenn dies das erwartete Ergebnis ist, ist der Test erfolgreich. Prüfen Sie untranslatedPremises und untranslatedClaims auf Teile der Eingabe, die nicht validiert wurden — ein VALID Ergebnis deckt nur die übersetzten Behauptungen ab. |
| INVALID | Die Ansprüche widersprechen Ihren Versicherungsregeln. Das Ergebnis beinhaltet den contradictingRules Nachweis, gegen welche Regeln verstoßen wurde. | Wenn dies das erwartete Ergebnis ist, ist der Test erfolgreich. Falls unerwartet, überprüfen Sie, ob die Regeln korrekt sind oder ob bei der Übersetzung die falschen Variablen zugewiesen wurden. Sehen Sie sich die contradictingRules an, um zu erfahren, welche Regeln das Ergebnis verursacht haben. |
| SATISFIABLE | Die Behauptungen stimmen mit Ihren Richtlinien überein, beziehen sich jedoch nicht auf alle relevanten Regeln. Die Antwort ist unter einigen Bedingungen korrekt, aber nicht unter allen. Das Ergebnis umfasst claimsTrueScenario sowohl a als auch a, aus denen claimsFalseScenario hervorgeht, unter welchen Bedingungen die Behauptungen wahr und falsch sind. | Vergleichen Sie die beiden Szenarien, um die fehlenden Bedingungen zu ermitteln. Das bedeutet in der Regel, dass die Antwort unvollständig ist — sie ist nicht falsch, aber sie erwähnt nicht alle Anforderungen. Überlegen Sie, ob Ihr Test erwarten sollte, SATISFIABLE oder ob die Antwort vollständiger sein sollte. |
| IMPOSSIBLE | Automatisierte Prüfungen zur Argumentation können die Behauptungen nicht bewerten, weil die Prämissen widersprüchlich sind oder die Richtlinie selbst widersprüchliche Regeln enthält. | Prüfen Sie, ob die Testeingaben widersprüchliche Aussagen enthalten (z. B. „Ich arbeite in Vollzeit und auch in Teilzeit“). Wenn die Eingabe gültig ist, liegt der Widerspruch wahrscheinlich in Ihrer Richtlinie — überprüfen Sie den Qualitätsbericht auf widersprüchliche Regeln. Siehe [Beheben Sie Fehler und verfeinern Sie Ihre Richtlinie für automatisiertes Denken](address-failed-automated-reasoning-tests.md). |
| TRANSLATION\$1AMBIGUOUS | Die Übersetzung von der natürlichen Sprache zur formalen Logik war mehrdeutig. Bei den für die Übersetzung LLMs verwendeten Multiplikatoren herrschte Uneinigkeit darüber, wie die Eingabe zu interpretieren sei. Das Ergebnis beinhaltet alternative Interpretationen, um Ihnen das Verständnis der Meinungsverschiedenheit zu erleichtern. | In der Regel handelt es sich dabei um ein Problem mit der Variablenbeschreibung. Überprüfen Sie die alternativen Interpretationen, um zu verstehen, wo die Meinungsverschiedenheit besteht, und verbessern Sie dann die entsprechenden Variablenbeschreibungen. Häufige Ursachen: sich überschneidende Variablen, vage Beschreibungen oder mehrdeutiger Eingabetext. Siehe [Beheben Sie Fehler und verfeinern Sie Ihre Richtlinie für automatisiertes Denken](address-failed-automated-reasoning-tests.md). |
| TOO\$1COMPLEX | Die Eingabe enthält zu viele Informationen, als dass automatische Argumentationsprüfungen sie innerhalb der Latenzgrenzen verarbeiten könnten. | Vereinfachen Sie die Testeingabe. Wenn das Problem weiterhin besteht, ist Ihre Richtlinie möglicherweise zu komplex. Erwägen Sie, sie in mehrere fokussierte Richtlinien aufzuteilen oder Regeln zu vereinfachen, die nichtlineare Arithmetik beinhalten. |
| NO\$1TRANSLATIONS | Die Eingabe konnte nicht in formale Logik übersetzt werden. Dies bedeutet in der Regel, dass die Eingabe für den Bereich Ihrer Richtlinie nicht relevant ist oder dass die Richtlinie keine Variablen zur Modellierung der Konzepte in der Eingabe enthält. | Wenn die Eingabe für Ihre Richtlinie relevant sein sollte, fügen Sie die fehlenden Variablen hinzu und aktualisieren Sie Ihre Regeln. Wenn die Eingabe tatsächlich nicht zum Thema gehört, ist dieses Ergebnis zu erwarten — Ihre Anwendung sollte themenfremde Inhalte separat behandeln (z. B. mithilfe von Themenrichtlinien). |
### Tipps zum Debuggen von fehlgeschlagenen Tests
Wenn ein Test fehlschlägt (das tatsächliche Ergebnis entspricht nicht dem erwarteten Ergebnis), verwenden Sie den folgenden Ansatz, um das Problem zu diagnostizieren:
1. **Überprüfen Sie zuerst die Übersetzung.** Schauen Sie sich die Prämissen und Behauptungen in der Feststellung an. Sind die richtigen Variablen zugewiesen? Sind die Werte korrekt? Wenn die Übersetzung falsch ist, liegt das Problem in Ihren Variablenbeschreibungen, nicht in Ihren Regeln. Wenn beispielsweise „2 Jahre“ `tenureMonths = 2` anstelle von übersetzt wurde`tenureMonths = 24`, muss in der Variablenbeschreibung die Umrechnung der Einheiten angegeben werden.
1. **Überprüfe die Regeln.** Wenn die Übersetzung korrekt aussieht, liegt das Problem in Ihren Versicherungsregeln. Sehen Sie sich das `supportingRules` oder `contradictingRules` im Ergebnis an, um festzustellen, um welche Regeln es sich handelt. Vergleichen Sie sie mit Ihrem Quelldokument.
1. **Suchen Sie nach unübersetzten Inhalten.** Schau dir `untranslatedPremises` und an. `untranslatedClaims` Wenn wichtige Teile der Eingabe nicht übersetzt wurden, müssen Sie möglicherweise Variablen hinzufügen, um diese Konzepte zu erfassen.
1. **Überprüfen Sie den Konfidenzwert.** Ein niedriger Konfidenzwert bedeutet, dass sich die Übersetzungsmodelle nicht einig waren. Dies deutet darauf hin, dass die Variablenbeschreibungen für diese Art von Eingabe mehrdeutig sind.
Eine ausführliche Anleitung zur Fehlerbehebung finden Sie unter[Beheben Sie Fehler und verfeinern Sie Ihre Richtlinie für automatisiertes Denken](address-failed-automated-reasoning-tests.md).
# Beheben Sie Fehler und verfeinern Sie Ihre Richtlinie für automatisiertes Denken
Wenn ein Richtlinientest für automatisiertes Denken fehlschlägt und das tatsächliche Ergebnis nicht mit dem erwarteten Ergebnis übereinstimmt, liegt das Problem entweder an der Übersetzung (natürliche Sprache wurde den falschen Variablen oder Werten zugeordnet) oder an den Regeln (die Richtlinienlogik entspricht nicht Ihrer Domäne). Diese Seite bietet einen systematischen Ansatz zur Diagnose und Behebung beider Arten von Problemen.
Bevor Sie mit der Problembehandlung beginnen, stellen Sie sicher, dass Sie den unter beschriebenen zweistufigen Validierungsprozess (übersetzen, dann validieren) verstanden haben. [Übersetzung: von der natürlichen Sprache zur formalen Logik](automated-reasoning-checks-concepts.md#ar-concept-translation) Diese Unterscheidung ist der Schlüssel zu effizientem Debugging.
**Anmerkung**
**Tutorial-Video:** Eine step-by-step Anleitung zur Verfeinerung und Problembehebung einer Richtlinie für automatisiertes Denken finden Sie im folgenden Tutorial:
[Tutorial-Demo 3 – Verfeinern der Automated-Reasoning-Richtlinie](https://youtu.be/YmohVGWr_PA)
## Arbeitsablauf beim Debuggen
Wenn ein Test fehlschlägt, verwenden Sie das tatsächliche Ergebnis, um die Art des Problems zu identifizieren, und springen Sie zum entsprechenden Abschnitt.
| Tatsächliches Ergebnis | Wahrscheinliche Ursache | Wo soll ich suchen |
| --- | --- | --- |
| TRANSLATION\$1AMBIGUOUS | Die Übersetzungsmodelle waren sich nicht einig, wie die Eingabe zu interpretieren sei. Dies wird normalerweise durch überlappende Variablen, vage Beschreibungen oder mehrdeutigen Eingabetext verursacht. | [Übersetzungsprobleme beheben](#fix-translation-issues) |
| NO\$1TRANSLATIONS | Die Eingabe konnte keinen Richtlinienvariablen zugeordnet werden. Entweder handelt es sich bei der Eingabe nicht um ein Thema, oder in der Richtlinie fehlen Variablen für die genannten Konzepte. | [Übersetzungsprobleme beheben](#fix-translation-issues) |
| TOO\$1COMPLEX | Die Eingabe oder Richtlinie überschreitet die Verarbeitungsgrenzen. Wird häufig durch nichtlineare Arithmetik oder Richtlinien mit zu vielen interagierenden Regeln verursacht. | [Einschränkungen und Überlegungen](guardrails-automated-reasoning-checks.md#automated-reasoning-limitations) |
| IMPOSSIBLE | Die Prämissen widersprechen einander, oder die Richtlinie selbst enthält widersprüchliche Regeln. | [Korrigieren Sie unmögliche Ergebnisse](#fix-impossible-results) |
| VALID,INVALID, oder SATISFIABLE (aber nicht das, was Sie erwartet haben) | Überprüfe zuerst die Übersetzung im Ergebnis. Wenn den richtigen Variablen die richtigen Werte zugewiesen werden, liegt das Problem in Ihren Regeln. Wenn die Übersetzung falsch ist, liegt das Problem in Ihren Variablenbeschreibungen. | Falsche Übersetzung:[Übersetzungsprobleme beheben](#fix-translation-issues). Falsche Regeln:[Regelprobleme beheben](#fix-rule-issues). |
**Tipp**
Überprüfen Sie immer zuerst die Übersetzung. In den meisten Fällen ist die mathematische Validierung (Schritt 2) korrekt — das Problem liegt darin, wie die natürliche Sprache in die formale Logik übersetzt wurde (Schritt 1). Das Korrigieren von Variablenbeschreibungen ist schneller und weniger riskant als das Ändern von Regeln.
## Übersetzungsprobleme beheben
Übersetzungsprobleme treten auf, wenn automatische Argumentationsprüfungen den Variablen Ihrer Richtlinie nicht zuverlässig natürliche Sprache zuordnen können. Das sichtbarste Symptom ist ein `TRANSLATION_AMBIGUOUS` Ergebnis, aber Übersetzungsprobleme können auch zu falschen oder `SATISFIABLE` Ergebnissen führen `VALID``INVALID`, wenn die falschen Variablen oder Werte zugewiesen werden.
### Diagnostizieren Sie Ergebnisse mit TRANSLATION\$1AMBIGULAR
Ein `TRANSLATION_AMBIGUOUS` Ergebnis umfasst zwei wichtige Felder, anhand derer Sie die Meinungsverschiedenheit besser verstehen können:
+ `options`— Die konkurrierenden logischen Interpretationen (bis zu 2). Jede Option enthält ihre eigene Übersetzung mit Prämissen, Behauptungen und Vertrauen. Vergleichen Sie die Optionen, um festzustellen, wo die Übersetzungsmodelle nicht übereinstimmten.
+ `differenceScenarios`— Szenarien (bis zu 2), die veranschaulichen, wie sich die verschiedenen Interpretationen in ihrer Bedeutung unterscheiden, wobei die Variablenzuweisungen die praktischen Auswirkungen der Mehrdeutigkeit hervorheben.
Untersuchen Sie diese Felder, um die spezifische Ursache der Mehrdeutigkeit zu ermitteln, und wenden Sie dann die entsprechende Lösung aus der folgenden Liste an.
### Überlappende Variablendefinitionen
Wenn mehrere Variablen dasselbe Konzept vernünftigerweise repräsentieren könnten, sind sich die Übersetzungsmodelle nicht einig, welches verwendet werden soll.
**Symptom:** Die `options` Ergebnisse zeigen`TRANSLATION_AMBIGUOUS`, dass dasselbe Konzept verschiedenen Variablen zugewiesen wurde. Bei einer Option wird beispielsweise „2 Jahre Betriebszugehörigkeit“ zugewiesen, `tenureMonths = 24` während bei der anderen Option der Wert zugewiesen wird. `monthsOfService = 24`
**Lösung:** Führen Sie die überlappenden Variablen zu einer einzigen Variablen mit einer umfassenden Beschreibung zusammen. Aktualisieren Sie alle Regeln, die auf die gelöschte Variable verweisen, um die verbleibende zu verwenden.
**Beispiel:**
| Vorher (überlappend) | Danach (zusammengeführt) |
| --- | --- |
| `tenureMonths`: „Wie lange der Mitarbeiter in Monaten gearbeitet hat.“ `monthsOfService`: „Die Dienstmonate des Mitarbeiters.“ | `tenureMonths`: „Die Anzahl der vollen Monate, in denen der Mitarbeiter ununterbrochen beschäftigt war. Wenn Benutzer Dienstjahre angeben, rechnen Sie diese in Monate um (z. B. 2 Jahre = 24 Monate). Diese Variable erfasst alle Verweise auf Beschäftigungsdauer, Betriebszugehörigkeit, Betriebszugehörigkeit oder Betriebszugehörigkeit.“ (Regeln löschen `monthsOfService` und aktualisieren.) |
### Unvollständige Variablenbeschreibungen
Variablenbeschreibungen, denen es an Einzelheiten darüber mangelt, wie sich Benutzer auf Konzepte in der Alltagssprache beziehen, erschweren es, Eingaben der richtigen Variablen zuzuordnen.
**Symptom:** Sie `options` zeigen die richtige Variable, aber mit unterschiedlichen Werten, oder die Übersetzung weist einen Wert zu, der nicht mit den Angaben des Benutzers übereinstimmt. Beispielsweise wird „2 Jahre“ `tenureMonths = 2` anstelle von `tenureMonths = 24` in übersetzt.
**Lösung:** Aktualisieren Sie die Variablenbeschreibung, sodass sie Regeln für die Umrechnung von Einheiten, Synonyme und alternative Formulierungen enthält. Eine ausführliche Anleitung [Verfassen Sie umfassende Variablenbeschreibungen](automated-reasoning-policy-best-practices.md#bp-variable-descriptions) finden Sie unter.
**Beispiel:**
| Vorher (unvollständig) | Nachher (umfassend) |
| --- | --- |
| isFullTime: „Vollzeitstatus.“ | isFullTime: „Ob der Mitarbeiter Vollzeit (richtig) oder Teilzeit (falsch) arbeitet. Wird auf „true“ gesetzt, wenn Benutzer angeben, „Vollzeit“ zu arbeiten, „volle Stunden“ zu arbeiten oder mehr als 40 Stunden pro Woche zu arbeiten. Wird auf „Falsch“ gesetzt, wenn Benutzer angeben, dass sie „Teilzeit“, „reduzierte Arbeitszeiten“ oder weniger als 40 Stunden pro Woche arbeiten.“ |
### Inkonsistente Wertformatierung
Eine mehrdeutige Übersetzung kann auftreten, wenn das System sich nicht sicher ist, wie Werte wie Zahlen, Datumsangaben oder Prozentsätze formatiert werden sollen.
**Symptom:** Sie `options` zeigen dieselbe Variable, jedoch mit unterschiedlichen Wertformaten. Eine Option übersetzt beispielsweise "5%" in, die `interestRate = 5` andere wiederum in. `interestRate = 0.05`
**Lösung:** Aktualisieren Sie die Variablenbeschreibung, um das erwartete Format anzugeben und Konvertierungsregeln einzubeziehen. Siehe [Geben Sie Einheiten und Formate in Variablenbeschreibungen an](automated-reasoning-policy-best-practices.md#bp-units-formats).
### Mehrdeutiger Eingabetext
Manchmal ist die Eingabe selbst wirklich mehrdeutig — sie enthält vage Pronomen, unklare Verweise oder Aussagen, die auf unterschiedliche Weise interpretiert werden können.
**Symptom:** Sie `options` zeigen grundlegend unterschiedliche Interpretationen desselben Textes. Zum Beispiel: „Können sie Urlaub nehmen?“ könnte sich auf jeden Mitarbeitertyp beziehen.
**Behebung:** Wenn es sich um einen Test handelt, schreiben Sie die Eingabe um, sodass sie spezifischer ist. Zur Laufzeit sollte Ihre Anwendung den Benutzer um eine Klarstellung bitten, wenn sie ein `TRANSLATION_AMBIGUOUS` Ergebnis erhält. Informationen zu Integrationsmustern finden Sie unter[Integrieren Sie automatisierte Argumentationsprüfungen in Ihre Anwendung](integrate-automated-reasoning-checks.md).
### Passen Sie den Vertrauensschwellenwert an
Wenn Sie `TRANSLATION_AMBIGUOUS` Ergebnisse für Eingaben sehen, die nahezu mehrdeutig sind, können Sie den Konfidenzschwellenwert anpassen. Durch eine Senkung des Schwellenwerts können Übersetzungen mit weniger Mustervereinbarung validiert werden, wodurch die `TRANSLATION_AMBIGUOUS` Ergebnisse reduziert werden, aber das Risiko falscher Übersetzungen steigt.
**Wichtig**
Eine Anpassung des Schwellenwerts sollte das letzte Mittel sein. In den meisten Fällen ist es besser, die Variablenbeschreibungen zu verbessern oder sich überschneidende Variablen zu entfernen, da so die eigentliche Ursache behoben wird. Weitere Informationen zur Funktionsweise von Schwellenwerten finden Sie unter. [Vertrauensschwellen](automated-reasoning-checks-concepts.md#ar-concept-confidence-thresholds)
## Regelprobleme beheben
Regelprobleme treten auf, wenn die Übersetzung korrekt ist, die Richtlinienlogik jedoch nicht mit Ihrer Domain übereinstimmt. Sie haben bestätigt, dass den richtigen Variablen die richtigen Werte zugewiesen wurden, aber das Überprüfungsergebnis ist immer noch falsch.
### Sie erhalten VALID, obwohl Sie UNGÜLTIG erwartet haben
Die Richtlinie enthält keine Regel, die den Anspruch verbietet. Die Antwort widerspricht Ihrem Fachwissen, aber die Richtlinie erlaubt es.
**Diagnose:** Schauen Sie sich das `supportingRules` im Befund an. Dies sind die Regeln, die belegen, dass der Anspruch gültig ist. Prüfen Sie, ob diese Regeln korrekt sind oder ob eine Regel fehlt.
**Häufige Ursachen und Lösungen:**
+ **Fehlende Regel.** In Ihrer Police gibt es keine Regel, die diese Bedingung abdeckt. Fügen Sie eine neue Regel hinzu, die die Einschränkung erfasst. Wenn die Versicherungspolice beispielsweise Elternzeit für alle Vollzeitbeschäftigten vorsieht, aber eine Anstellung von 12 Monaten vorsehen sollte, fügen Sie hinzu: `(=> (and isFullTime (<= tenureMonths 12)) (not eligibleForParentalLeave))`
+ **Die Regel ist zu freizügig.** Eine bestehende Regel erlaubt mehr als sie sollte. Bearbeiten Sie die Regel, um die fehlende Bedingung hinzuzufügen. Ändern Sie beispielsweise `(=> isFullTime eligibleForParentalLeave)` zu `(=> (and isFullTime (> tenureMonths 12)) eligibleForParentalLeave)`
+ **Fehlende Variable.** Die Richtlinie hat keine Variable, um ein relevantes Konzept zu erfassen. Fügen Sie die Variable hinzu, schreiben Sie eine klare Beschreibung und erstellen Sie Regeln, die darauf verweisen.
### Wird UNGÜLTIG angezeigt, obwohl Sie VALID erwartet hatten
Die Richtlinie enthält eine Regel, die fälschlicherweise den Anspruch verbietet.
**Diagnose:** Schauen Sie sich das `contradictingRules` im Befund an. Dies sind die Regeln, die die Behauptung widerlegen. Prüfen Sie, ob diese Regeln korrekt sind.
**Häufige Ursachen und Lösungen:**
+ **Die Regel ist zu restriktiv.** Eine bestehende Regel blockiert ein gültiges Szenario. Bearbeiten Sie die Regel, um die Bedingung zu lockern oder eine Ausnahme hinzuzufügen. Wenn die Regel beispielsweise eine Laufzeit von 24 Monaten vorsieht, die Richtlinie jedoch nur 12 Monate vorsehen sollte, aktualisieren Sie den Schwellenwert.
+ **Die Regel wurde falsch extrahiert.** Automatisierte Prüfungen zur Argumentation haben Ihr Quelldokument falsch interpretiert. Bearbeiten Sie die Regel so, dass sie der beabsichtigten Logik entspricht, oder löschen Sie sie und fügen Sie manuell eine korrekte Regel hinzu.
### Befriedigend, obwohl Sie es erwartet hatten, dass es GÜLTIG ist
Die Antwort ist unter einigen Bedingungen korrekt, aber nicht unter allen. Die Richtlinie enthält zusätzliche Regeln, auf die in der Antwort nicht eingegangen wird.
**Diagnose:** Vergleichen Sie das `claimsTrueScenario` und `claimsFalseScenario` im Befund. Der Unterschied zwischen ihnen zeigt die Bedingungen, die in der Antwort nicht erwähnt werden.
**Häufige Ursachen und Lösungen:**
+ **Die Antwort ist unvollständig.** In der Testausgabe werden nicht alle von der Richtlinie geforderten Bedingungen erwähnt. Aktualisieren Sie die Testausgabe, sodass sie die fehlenden Bedingungen enthält, oder ändern Sie das erwartete Ergebnis dahingehend, `SATISFIABLE` ob unvollständige Antworten für Ihren Anwendungsfall akzeptabel sind.
+ **Die Richtlinie enthält unnötige Regeln.** Die Richtlinie erfordert Bedingungen, die für dieses Szenario nicht relevant sind. Prüfen Sie, ob die zusätzlichen Regeln gelten sollten, und entfernen Sie sie, falls dies nicht der Fall ist.
## Korrigieren Sie unmögliche Ergebnisse
Das bedeutet`IMPOSSIBLE`, dass automatische Argumentationsprüfungen die Ansprüche nicht bewerten können, weil die Prämissen widersprüchlich sind oder die Richtlinie selbst widersprüchliche Regeln enthält. Es gibt zwei unterschiedliche Ursachen.
### Widersprüche in der Eingabe
Die Testeingabe enthält Aussagen, die sich widersprechen. Zum Beispiel wird „Ich bin ein Vollzeitbeschäftigter und auch Teilzeit“ festgelegt `isFullTime = true` und `isFullTime = false` gleichzeitig, was logischerweise unmöglich ist.
**Diagnose:** Untersuchen Sie die `translation` Räumlichkeiten im Befund. Suchen Sie nach Variablen, denen widersprüchliche Werte zugewiesen sind.
**Behebung:** Wenn es sich um einen Test handelt, schreiben Sie die Eingabe neu, um den Widerspruch zu beseitigen. Zur Laufzeit sollte Ihre Anwendung die `IMPOSSIBLE` Ergebnisse verarbeiten, indem sie den Benutzer auffordert, seine Eingabe zu klären.
### Konflikte in der Richtlinie
Die Richtlinie enthält Regeln, die sich gegenseitig widersprechen, sodass automatische Argumentationsprüfungen keine Schlussfolgerungen für Eingaben ziehen können, die widersprüchliche Regeln beinhalten.
**Diagnose:** Wenn die Eingabe gültig ist (keine widersprüchlichen Prämissen), liegt das Problem in der Richtlinie. Überprüfen Sie das `contradictingRules` Feld im Ergebnis, um festzustellen, welche Regeln miteinander in Konflikt stehen. Prüfen Sie auch den Qualitätsbericht (siehe[Verwenden Sie den Qualitätsbericht](#use-quality-report)) — er kennzeichnet automatisch widersprüchliche Regeln.
**Häufige Ursachen und Lösungen:**
+ **Widersprüchliche Regeln.** Zwei Regeln führen für dieselben Bedingungen zu entgegengesetzten Ergebnissen. Eine Regel besagt beispielsweise, dass Vollzeitbeschäftigte Anspruch auf Urlaub haben, während eine andere besagt, dass Arbeitnehmer im ersten Jahr keinen Anspruch darauf haben, ohne zu spezifizieren, was mit Vollzeitbeschäftigten im ersten Jahr passiert. Führen Sie die Regeln zu einer einzigen Regel mit ausdrücklichen Bedingungen zusammen: `(=> (and isFullTime (> tenureMonths 12)) eligibleForLeave)`
+ **Bloße Behauptungen.** Eine bloße Behauptung wie `(= eligibleForLeave true)` macht es unmöglich, zu behaupten, dass der Benutzer *nicht* berechtigt ist. Schreiben Sie bloße Behauptungen als Implikationen um. Siehe [Verwenden Sie Implikationen (=>), um Regeln zu strukturieren](automated-reasoning-policy-best-practices.md#bp-use-implications).
+ **Zirkuläre Abhängigkeiten.** Regeln, die so voneinander abhängen, dass logische Schleifen entstehen. Vereinfachen Sie die Regeln, um den Kreislauf zu durchbrechen, oder verwenden Sie Zwischenvariablen, um die Logik explizit zu machen.
## Verwenden Sie Anmerkungen, um Ihre Richtlinie zu reparieren
Anmerkungen sind gezielte Korrekturen, die Sie an Ihrer Richtlinie vornehmen, wenn Tests fehlschlagen. Anstatt Regeln und Variablen manuell zu bearbeiten, können Sie Anmerkungen verwenden, um die gewünschte Änderung zu beschreiben und sie von Automated Reasoning überprüfen zu lassen. Anmerkungen sind sowohl über die Konsole als auch über die API verfügbar.
### Fügen Sie Anmerkungen in der Konsole hinzu
1. Öffnen Sie den fehlgeschlagenen Test und überprüfen Sie die Ergebnisse, um das Problem zu verstehen.
1. Ändern Sie die Testbedingungen (fügen Sie beispielsweise eine Prämisse hinzu oder ändern Sie das erwartete Ergebnis) und führen Sie den Test erneut aus. Wenn der modifizierte Test das erwartete Ergebnis liefert, können Sie diese Änderung als Anmerkung übernehmen.
1. Wählen Sie **Anmerkungen anwenden** aus. Automatisierte Prüfungen zur Argumentation starten einen Build-Workflow, um die Änderungen auf der Grundlage Ihres Feedbacks auf Ihre Richtlinie anzuwenden.
1. **Prüfen Sie auf dem Bildschirm „Richtlinienänderungen** überprüfen“ die vorgeschlagenen Änderungen an den Regeln, Variablen und Typen Ihrer Richtlinie. Wählen Sie dann **Änderungen akzeptieren** aus.
### Fügen Sie Anmerkungen mithilfe der API hinzu
Verwenden Sie die `StartAutomatedReasoningPolicyBuildWorkflow` API mit`REFINE_POLICY`, um Anmerkungen programmgesteuert anzuwenden. Übergeben Sie die vollständige aktuelle Richtliniendefinition zusammen mit den Anmerkungen.
Zu den Arten von Anmerkungen gehören:
+ **Anmerkungen zu Variablen:**`addVariable`,`updateVariable`, `deleteVariable` — Fügen Sie fehlende Variablen hinzu, verbessern Sie Beschreibungen oder entfernen Sie Duplikate.
+ **Regelanmerkungen:**`addRule`,, `updateRule``deleteRule`, `addRuleFromNaturalLanguage` — Korrigieren Sie falsche Regeln, fügen Sie fehlende Regeln hinzu oder entfernen Sie widersprüchliche Regeln. Wird verwendet`addRuleFromNaturalLanguage`, um eine Regel in einfachem Englisch zu beschreiben und sie mithilfe von automatisierten Argumentationsprüfungen in formale Logik umwandeln zu lassen.
+ **Geben Sie Anmerkungen ein:**`addType`,`updateType`, `deleteType` — Verwaltet benutzerdefinierte Typen (Enums).
+ **Feedback-Anmerkungen:**`updateFromRulesFeedback`, `updateFromScenarioFeedback` — Geben Sie Feedback in natürlicher Sprache zu bestimmten Regeln oder Szenarien und lassen Sie sich von Automated Reasoning die notwendigen Änderungen ableiten.
**Beispiel: Fügen Sie mithilfe von Anmerkungen eine fehlende Variable und Regel hinzu**
```
aws bedrock start-automated-reasoning-policy-build-workflow \
--policy-arn "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk" \
--build-workflow-type REFINE_POLICY \
--source-content "{
\"policyDefinition\": EXISTING_POLICY_DEFINITION_JSON,
\"workflowContent\": {
\"policyRepairAssets\": {
\"annotations\": [
{
\"addVariable\": {
\"name\": \"tenureMonths\",
\"type\": \"int\",
\"description\": \"The number of complete months the employee has been continuously employed. When users mention years of service, convert to months (for example, 2 years = 24 months).\"
}
},
{
\"addRuleFromNaturalLanguage\": {
\"naturalLanguage\": \"If an employee is full-time and has more than 12 months of tenure, then they are eligible for parental leave.\"
}
}
]
}
}
}"
```
### Beispiele für Anmerkungen
**Beispiel 1: Korrigieren Sie ein fehlendes Beschäftigungsverhältnis**
Problem: Die Richtlinie genehmigt Elternzeit für alle Vollzeitbeschäftigten, aber das Ausgangsdokument sieht eine Anstellung von mehr als 12 Monaten vor.
| Vor | Nach der Anmerkung |
| --- | --- |
| Regel: `(=> isFullTime eligibleForParentalLeave)` Keine `tenureMonths` Variable. | Neue Variable: `tenureMonths` (int) — „Die Anzahl der kompletten Monate, in denen der Mitarbeiter ununterbrochen beschäftigt war.“ Aktualisierte Regel: `(=> (and isFullTime (> tenureMonths 12)) eligibleForParentalLeave)` |
**Beispiel 2: Korrigieren Sie überlappende Variablen, die TRANSLATION\$1AMBIGUOUS verursachen**
Problem: Zwei Variablen (`tenureMonths`und`monthsOfService`) stehen für dasselbe Konzept, was zu inkonsistenten Übersetzungen führt.
Anmerkungen:
1. `deleteVariable`für`monthsOfService`.
1. `updateVariable`für `tenureMonths` mit einer verbesserten Beschreibung, die alle Arten abdeckt, wie Benutzer die Beschäftigungsdauer bezeichnen könnten.
1. `updateRule`für alle Regeln, auf die verwiesen `monthsOfService` wurde, und deren Verwendung zu ändern`tenureMonths`.
**Beispiel 3: Korrigieren Sie eine bloße Behauptung, die zu UNMÖGLICHEN Ergebnissen führt**
Problem: Bei der Regel `(= eligibleForParentalLeave true)` handelt es sich um eine bloße Behauptung, die es unmöglich macht, zu behaupten, dass der Benutzer nicht berechtigt ist.
Anmerkungen:
1. `deleteRule`für die bloße Behauptung.
1. `addRuleFromNaturalLanguage`: „Wenn ein Arbeitnehmer Vollzeit arbeitet und mehr als 12 Monate angestellt ist, hat er Anspruch auf Elternurlaub.“
## Verwenden Sie den Qualitätsbericht
Der Qualitätsbericht wird nach jedem Build-Workflow generiert und identifiziert strukturelle Probleme in Ihrer Richtlinie, die zu Testfehlern führen können. In der Konsole werden Probleme mit Qualitätsberichten als Warnungen auf der **Definitionsseite** angezeigt. Verwenden Sie über die API `GetAutomatedReasoningPolicyBuildWorkflowResultAssets` mit`--asset-type QUALITY_REPORT`.
Der Qualitätsbericht weist auf die folgenden Probleme hin:
### Widersprüchliche Regeln
Zwei oder mehr Regeln führen zu widersprüchlichen Schlussfolgerungen für dieselben Bedingungen. Widersprüchliche Regeln führen dazu, dass Ihre Richtlinie `IMPOSSIBLE` für alle Überprüfungsanfragen, die die widersprüchlichen Regeln beinhalten, zurückgegeben wird.
**Beispiel:** Regel A sagt `(=> isFullTime eligibleForLeave)` und Regel B sagt. `(=> (<= tenureMonths 6) (not eligibleForLeave))` Für einen Vollzeitbeschäftigten mit einer Betriebszugehörigkeit von 3 Monaten heißt es in Regel A „förderfähig“ und in Regel B „nicht förderfähig“ — ein Widerspruch.
**Lösung:** Führen Sie die Regeln zu einer einzigen Regel mit expliziten Bedingungen zusammen:. `(=> (and isFullTime (> tenureMonths 6)) eligibleForLeave)` Oder löschen Sie eine der widersprüchlichen Regeln, wenn sie falsch extrahiert wurde.
### Unbenutzte Variablen
Variablen, auf die keine Regeln verweisen. Unbenutzte Variablen stören den Übersetzungsprozess und können zu `TRANSLATION_AMBIGUOUS` Ergebnissen führen, wenn sie mit ähnlichen aktiven Variablen um dasselbe Konzept konkurrieren.
**Behebung:** Löschen Sie unbenutzte Variablen, es sei denn, Sie planen, in einer future Iteration Regeln hinzuzufügen, die auf sie verweisen.
### Unbenutzte Typwerte
Werte in einem benutzerdefinierten Typ (Enum), auf die keine Regeln verweisen. Wenn Ihre `LeaveType` Enumeration beispielsweise die Werte PARENTAL, MEDICAL, BEREAVEMENT und PERSONAL hat, aber keine Regel auf PERSONAL verweist, wird sie als unbenutzt gekennzeichnet.
**Lösung:** Fügen Sie entweder Regeln hinzu, die auf den ungenutzten Wert verweisen, oder entfernen Sie ihn aus der Aufzählung. Unbenutzte Werte können zu Übersetzungsproblemen führen, wenn in der Eingabe das Konzept erwähnt wird, aber keine Regel es behandelt.
### Unzusammenhängende Regelsätze
Gruppen von Regeln, die keine gemeinsamen Variablen haben. Unzusammenhängende Regelsätze sind nicht unbedingt ein Problem — Ihre Police deckt möglicherweise bewusst unabhängige Themen ab (z. B. Urlaubsberechtigung und Kostenerstattung). Sie können jedoch darauf hinweisen, dass bei Variablen Verbindungen zwischen verwandten Regeln fehlen.
**Wann zu handeln ist:** Wenn die unzusammenhängenden Regelsätze miteinander verknüpft sein sollen (z. B. beziehen sich beide auf Leistungen an Arbeitnehmer, verwenden aber unterschiedliche Variablennamen für dasselbe Konzept), führen Sie die sich überschneidenden Variablen zusammen, um sie miteinander zu verbinden. Wenn die Regelsätze wirklich unabhängig sind, sind keine Maßnahmen erforderlich.
## Verwenden Sie Kiro CLI zur Verfeinerung von Richtlinien
Kiro CLI bietet eine interaktive Chat-Oberfläche zur Diagnose und Behebung von Richtlinienproblemen. Es kann Ihre Richtliniendefinition und Ihren Qualitätsbericht laden, erklären, warum Tests fehlschlagen, Änderungen vorschlagen und Anmerkungen hinzufügen — alles in natürlicher Sprache.
Kiro CLI ist besonders nützlich für:
+ **Fehler verstehen.** Bitten Sie Kiro CLI, einen fehlgeschlagenen Test zu laden und zu erklären, warum er nicht das erwartete Ergebnis zurückgibt. Kiro CLI analysiert die Richtliniendefinition, die Testergebnisse und den Qualitätsbericht, um die Grundursache zu ermitteln.
+ **Lösung von Problemen mit dem Qualitätsbericht.** Bitten Sie Kiro CLI, den Qualitätsbericht zusammenzufassen und Lösungen für widersprüchliche Regeln, unbenutzte Variablen und sich überschneidende Variablenbeschreibungen vorzuschlagen.
+ **Regeländerungen vorschlagen.** Beschreiben Sie das erwartete Verhalten und bitten Sie Kiro CLI, die erforderlichen Variablen- und Regeländerungen vorzuschlagen. Prüfen Sie die Vorschläge und weisen Sie Kiro CLI an, sie als Anmerkungen zu verwenden.
**Beispiel für einen Arbeitsablauf:**
```
You: The test with ID test-12345 is not returning the expected result.
Can you load the test definition and findings, look at the policy
definition, and explain why this test is failing?
Kiro: [analyzes the test and policy] The test expects VALID but gets
INVALID because rule R3 requires 24 months of tenure, while the
test input specifies 18 months. The source document says 12 months.
Rule R3 appears to have been misextracted.
You: Can you suggest changes to fix this?
Kiro: I suggest updating rule R3 to change the tenure threshold from 24
to 12 months. Here's the updated rule: ...
You: Looks good. Can you use the annotation APIs to submit these changes?
Kiro: [applies annotations via the API]
```
Vollständige Anweisungen zur Einrichtung und Verwendung von Kiro CLI with Automated Reasoning-Richtlinien finden Sie unter. [Verwenden Sie Kiro CLI mit einer Automated Reasoning-Richtlinie](kiro-cli-automated-reasoning-policy.md)
# Verwenden Sie Kiro CLI mit einer Automated Reasoning-Richtlinie
Sie können Kiro CLI verwenden, um Fragen zu Ihren Automated Reasoning-Richtlinien zu stellen, das Verhalten der verschiedenen Regeln zu verstehen und Änderungen zu beantragen, um fehlgeschlagene Tests oder Unklarheiten in der Richtlinie selbst zu beheben. Kiro CLI ist besonders nützlich für den unter beschriebenen iterativen Optimierungsablauf, [Beheben Sie Fehler und verfeinern Sie Ihre Richtlinie für automatisiertes Denken](address-failed-automated-reasoning-tests.md) da es Ihre Richtliniendefinition laden, Testergebnisse analysieren und Anmerkungen in natürlicher Sprache anwenden kann.
## Voraussetzungen
Um Kiro CLI mit Ihren Automated Reasoning-Richtlinien zu verwenden, müssen Sie zunächst die folgenden Schritte ausführen:
+ Installieren Sie die neueste Version von [Kiro CLI](https://kiro.dev/cli/).
+ Installieren Sie die neueste Version der AWS CLI.
+ Erstellen Sie mithilfe eines Dokuments über die Konsole oder eine Richtlinie für automatisiertes Denken. APIs Verwenden Sie für einen schnellen Einstieg die integrierte Beispielrichtlinie für Hausaufgaben in der Konsole. Weitere Informationen finden Sie unter [Erstellen der Automated-Reasoning-Richtlinie](create-automated-reasoning-policy.md).
+ Machen Sie sich mit den Konzepten von Automated Reasoning Checks vertraut, insbesondere mit Richtlinien, Regeln, Variablen und Ergebnissen. Weitere Informationen finden Sie unter [Automatisiertes Denken überprüft Konzepte](automated-reasoning-checks-concepts.md).
+ Kopieren Sie den Inhalt der kontextbezogenen Eingabeaufforderung in [Kontext-Aufforderung zur automatischen Argumentationsrichtlinie](#kiro-cli-context-prompt) und speichern Sie ihn in einer Markdown-Datei in Ihrem Projektordner. Diese Aufforderung hilft Kiro CLI, die Automated Reasoning-Richtlinienkontrollebene zu verwenden und die API korrekt zu testen.
**Anmerkung**
Für die folgenden Beispiele für Eingabeaufforderungen verwenden wir die Beispielrichtlinie für Hausaufgaben. Die Eingabeaufforderungen sollten genauso gut mit anderen Richtlinien funktionieren. Ändern Sie einfach das hervorgehobene Thema.
**Anmerkung**
Automatisierte Argumentationsrichtlinien können komplex sein und erfordern, dass Kiro CLI komplexe logische Konstrukte durchdenkt. Für eine optimale Leistung empfehlen wir die Verwendung größerer Formate LLMs wie Anthropic Sonnet 4.5. Verwenden Sie den `/model` Befehl, um das Modell in Kiro CLI zu ändern.
## Erste Schritte
Sie benötigen den ARN der von Ihnen erstellten Automated Reasoning-Richtlinie, um den Workflow mit Kiro CLI zu starten.
1. Öffnen Sie in der Konsole Ihre Richtlinie für automatisiertes Denken und öffnen Sie auf der Seite mit der **Richtlinienübersicht** den Tab **Richtliniendetails**.
1. Suchen Sie auf der Registerkarte **Richtliniendetails** den Richtlinien-ARN und kopieren Sie ihn in Ihre Zwischenablage.
1. Starten Sie über das Terminal eine Kiro CLI-Sitzung mit dem folgenden Befehl:
```
kiro-cli
```
1. Bitten Sie Kiro bei Ihrer ersten Aufforderung, nach der Markdown-Datei mit Anweisungen zu suchen, die Sie als Teil der Voraussetzungen von dieser Seite kopiert haben. Beispiel:
```
We will be using Automated Reasoning checks control plane APIs. I have saved an instructions file called your_file_name.md in this folder. Read this file as it will give you the context you need to work with the APIs.
```
1. Nachdem Kiro CLI die automatischen Argumentationsüberprüfungen geladen und verstanden hat APIs, bitten Sie es, die neueste Version Ihrer Richtlinie zu laden und mit der Erkundung zu beginnen. Verwenden Sie eine Variante der folgenden Eingabeaufforderung mit dem von Ihnen kopierten ARN:
```
Load the policy assets for the latest build of the policy with ARN YOUR_POLICY_ARN. Make sure you understand the policy with all its rules and variables. Give a high-level description of the policy and the type of content it is capable of validating.
```
An dieser Stelle sollte Kiro CLI Ihnen eine kurze Beschreibung der Regeln und Variablen der Richtlinie geben. Kiro CLI sollte auch den Bericht zur Richtlinienqualität laden und Probleme wie ungenutzte Typen und Variablen zusammenfassen.
## Lösung politischer Probleme
Sie können Kiro CLI verwenden, um die im Richtlinienbericht gemeldeten Richtlinienprobleme zu lösen. Bitten Sie Kiro zunächst, Ihnen eine Zusammenfassung des Qualitätsberichts zu geben:
```
Can you give me a summary of the quality report for this policy?
```
Der Qualitätsbericht enthält eine Liste der ungenutzten Variablen, widersprüchlichen Regeln und unzusammenhängenden Regeln sowie anderer potenzieller Probleme mit der Richtlinie. Weitere Informationen zur Interpretation des Qualitätsberichts finden Sie unter. [Verwenden Sie den Qualitätsbericht](address-failed-automated-reasoning-tests.md#use-quality-report)
Widersprüchliche Regeln führen dazu, dass Ihre Richtlinie auf alle Überprüfungsanfragen reagiert. `IMPOSSIBLE` Weitere Informationen zu widersprüchlichen Regeln und deren Behebung finden Sie unter. [Konflikte in der Richtlinie](address-failed-automated-reasoning-tests.md#fix-impossible-policy-conflicts) Sie können Kiro CLI bitten, den Konflikt zu erklären und eine Lösung vorzuschlagen:
```
Can you look at the conflicting rules, explain how they are used in the policy, why they conflict, and suggest a change such as deleting one of the rules or merging the logic from the two into a single rule?
```
Unbenutzte Variablen können dazu führen, dass Validierungsergebnisse `TRANSLATION_AMBIGUOUS` Ergebnisse zurückgeben. Weitere Hinweise dazu, warum ungenutzte Variablen Probleme verursachen, finden Sie unter[Unbenutzte Variablen](automated-reasoning-policy-best-practices.md#bp-anti-unused-variables). Sie können Kiro CLI bitten, Ihnen bei diesem Problem zu helfen:
```
I see the quality report lists some unused variables, can you get rid of them?
```
In ähnlicher Weise können mehrdeutige Variablen, die sich semantisch ähneln, dazu führen, dass Validierungsergebnisse Ergebnisse zurückgeben`TRANSLATION_AMBIGUOUS`. Weitere Informationen zu überlappenden Variablen und deren Behebung finden Sie unter [Überlappende Variablen](automated-reasoning-policy-best-practices.md#bp-anti-overlapping-variables) und. [Überlappende Variablendefinitionen](address-failed-automated-reasoning-tests.md#fix-overlapping-variables) Sie können Kiro CLI bitten, Ihnen bei diesem Problem zu helfen:
```
Automated Reasoning checks translate input natural language into logical statements that use the schema of variables from the policy. Variables that are semantically similar - ambiguous - can cause issues with inconsistent translations. Can you take a look at the schema of variables and help me identify variables that have potentially overlapping meanings? If you find any, suggest changes like removing one of them or merging them. Variable changes are also likely to require corresponding rule changes.
```
**Anmerkung**
Nach der Bearbeitung einiger Änderungen bittet Kiro CLI um Bestätigung, damit sie übernommen werden können. Zu diesem Zeitpunkt können Sie die Benutzeroberfläche der Bedrock Console verwenden, um die vorgeschlagenen Änderungen auf einem Vergleichsbildschirm zu überprüfen. Wenn Sie die Konsole verwenden, um die Änderungen zu überprüfen und zu genehmigen, vergessen Sie nicht, Kiro CLI anzuweisen, die neueste Version der Richtliniendefinition neu zu laden.
## Interaktion mit einer Richtlinie
Sie können Kiro CLI verwenden, um Ihre Richtlinie zu erkunden. Sie könnten Kiro CLI beispielsweise bitten, die Richtlinienregeln für einen bestimmten Bereich zusammenzufassen. Anhand der Beispielrichtlinie für Hausaufgaben könnten Sie Kiro CLI bitten, Sie über die Regeln zu informieren, die speziell Mathe-Hausaufgaben einschränken:
```
Can you tell me about the rules that constrain math homework? Explain the rules themselves and how they fit in the broader policy.
```
Sie können die Kiro CLI auch verwenden, um der Richtlinie Funktionen hinzuzufügen. Richtlinien für automatisiertes Denken umgehen häufig einige wichtige Ausgabevariablen, die die Absicht des Benutzers erfassen. Beispielsweise verwendet die Beispielrichtlinie zur Einreichung von Hausaufgaben eine `isSubmissionAcceptable` Variable als Ergebnis ihrer Regeln. Sie können Kiro CLI verwenden, um die Richtlinie so zu ändern, dass andere mögliche Benutzerfragen erfasst werden. Beachten Sie beim Hinzufügen neuer Regeln insbesondere [Verwenden Sie Implikationen (=>), um Regeln zu strukturieren](automated-reasoning-policy-best-practices.md#bp-use-implications) die unter beschriebenen Best Practices. [Bewährte Methoden für Richtlinien zur automatisierten Argumentation](automated-reasoning-policy-best-practices.md)
## Bearbeitung oder Überarbeitung Ihrer Richtlinie
Sie können Kiro CLI fragen, ob die Richtlinie bestimmte Fragen Ihrer Benutzer validieren kann. Zum Beispiel konzentriert sich die Hausaufgabenrichtlinie darauf, festzustellen, ob die Einreichung von Hausaufgaben zulässig ist. Sie können eine positive Antwort von Kiro CLI mit dieser Frage erwarten:
```
Can this policy validate answers about whether homework submissions are acceptable?
```
Wenn Sie in der Musterrichtlinie für Hausaufgaben nach einer Verzögerung bei der Einreichung von Hausaufgaben fragen, erklärt Kiro CLI, dass die Richtlinie diese Fragen nicht beantworten kann:
```
Can this policy validate answers about permissible delays in homework submissions?
```
Kiro CLI erklärt, was die Richtlinie kann und was nicht:
```
> Yes, but with limitations. The policy can validate whether a late submission is acceptable, but it cannot answer general questions about permissible delays.
What it CAN validate:
- Whether a specific late submission is acceptable given the circumstances
- Example: "Student submitted 2 days late with a doctor's note because they were sick before the deadline" → The policy will determine if this is acceptable (it would be)
What it CANNOT validate:
- General questions like "How many days late can a student submit homework?"
- Questions about delay policies without specific submission details
- Hypothetical scenarios without concrete variable values
The late submission logic:
The policy allows late submissions (submissionDate > 0) ONLY if:
1. The student has a valid doctor's note (hasDoctorNote = true), AND
2. The student was sick before the original deadline (wasSickPriorToDeadline = true)
Without both conditions met, any submission after the due date (submissionDate > 0) is automatically rejected.
So it's designed to validate specific submission instances against the rules, not to answer policy interpretation questions.
```
Wenn Sie etwas entdecken, das die Richtlinie nicht kann, können Sie Kiro CLI bitten, die Richtlinie zu aktualisieren, um diese Informationen zu erfassen, indem Sie die folgende Aufforderung verwenden:
```
I would like the policy to also validate answers about by how many days homework submissions can be delayed. Homework submissions accompanied by a doctor note can be up to 7 days late. Suggest the necessary variables and rules to capture these new questions.
```
Als Antwort auf diese Aufforderung schlägt Kiro CLI eine Reihe von Variablen und Regeln vor, die der Richtlinie hinzugefügt werden können, um die neue Art von Fragen zu validieren. Überprüfe die Vorschläge und wenn sie mit deiner Absicht übereinstimmen, kannst du Kiro CLI anweisen, die Anmerkung von Automated Reasoning Checks zu verwenden, APIs um die folgenden Änderungen an der Richtlinie vorzunehmen:
```
Looks good. Can you use the annotation APIs to submit these changes to the policy.
```
Sobald Kiro CLI bestätigt hat, dass die Anmerkungen bereit sind, können Sie Ihre Richtlinie in der Konsole öffnen, um die Anmerkungen zu überprüfen. **Wenn die Anmerkungen korrekt sind, wählen Sie Apply Annotations.**
Nachdem Sie die Anmerkungen übernommen haben, bitten Sie Kiro CLI, die neueste Version der Richtlinie neu zu laden, um sicherzustellen, dass Kiro CLI mit einer aktuellen Kopie funktioniert:
```
I applied the annotations. Reload the latest build of the policy.
```
## Behebung fehlgeschlagener Tests
Eine gute Methode, um zu testen, ob Ihre Richtlinie für automatisiertes Denken die von Ihrer Anwendung generierte natürliche Sprache validieren kann, ist die Verwendung von Tests. Nachdem Sie Fragen und Antworten zu Tests mit den erwarteten Ergebnissen erstellt haben, können Sie Kiro CLI verwenden, um zu verstehen, warum ein Test nicht das erwartete Ergebnis zurückgegeben hat, und die Richtlinie anpassen. Weitere Informationen zum Erstellen und Ausführen von Tests finden Sie unter. [Testen einer Automated-Reasoning-Richtlinie](test-automated-reasoning-policy.md) Einen systematischen Ansatz zur Diagnose von Testfehlern ohne Kiro CLI finden Sie unter. [Beheben Sie Fehler und verfeinern Sie Ihre Richtlinie für automatisiertes Denken](address-failed-automated-reasoning-tests.md)
1. Bitten Sie Kiro CLI als ersten Schritt, den fehlgeschlagenen Test zu laden und zu erklären, warum er nicht das erwartete Ergebnis auf der Grundlage der Richtliniendefinition zurückgibt. Verwenden Sie die Konsole oder kopieren APIs Sie die Test-ID für Ihren fehlgeschlagenen Test. In der Konsole ist die Test-ID sowohl in der Tabelle mit den Tests als auch auf der Detailseite für jeden Test verfügbar.
```
The test with ID YOUR_TEST_ID is not returning the expected result. Can you load the test definition and findings, look at the policy definition, and explain why this test is failing.
```
1. Die Erklärung von Kiro CLI gibt Ihnen Hinweise darauf, ob die Richtlinie das Richtige tut (und Sie sollten das erwartete Ergebnis für den Test ändern) oder ob die Richtlinie falsch ist. Sie können Kiro CLI bitten, Änderungen an der Richtlinie vorzuschlagen, um sicherzustellen, dass der Test das erwartete Ergebnis liefert:
```
Can you suggest changes to the policy to ensure this test returns the expected result? Explain why you are suggesting these changes. Only create rules in if/then format.
```
**Anmerkung**
Wenn Kiro CLI Regeländerungen vorschlägt, versucht Kiro CLI möglicherweise, sich zu stark an das spezifische Beispiel anzupassen und Regeln zu erstellen, die in anderen Anwendungsfällen nicht nützlich sind. Überprüfen Sie die Testausgabe und geben Sie Kiro CLI Anweisungen, damit es sich auf das richtige Problem konzentriert. Anleitungen zum Schreiben effektiver Regeln finden Sie unter[Bewährte Methoden für Richtlinien zur automatisierten Argumentation](automated-reasoning-policy-best-practices.md).
Wenn Sie Kiro beispielsweise bitten, die Musterrichtlinie für Hausaufgaben so zu ändern, dass der `SATISFIABLE` Test zurückgegeben wird`VALID`, schlägt Kiro möglicherweise vor, der Richtlinie Axiome hinzuzufügen, die dafür sorgen, dass der Test immer bestanden wird, z. B. die Erstellung einer Regel, die besagt. `(false isHomeworkSubmissionAcceptable)` Dadurch würde sichergestellt, dass der Wert immer falsch ist. Dies behebt zwar technisch den problematischen Test, wirkt sich jedoch nachteilig auf die allgemeine Richtlinienfunktionalität aus. Wenn Sie die vom `SATISFIABLE` Testergebnis zurückgegebenen Szenarien analysieren, können Sie feststellen, dass Kiro CLI bessere Hinweise gibt, entweder eine neue Regel zu erstellen, die nur die im Test angegebenen Einschränkungen abdeckt, oder die vorhandenen Regeln zu aktualisieren, um nur die Testeinschränkungen zu überprüfen:
1. Wenn Sie mit den vorgeschlagenen Änderungen zufrieden sind, bitten Sie Kiro CLI, die Anmerkungen einzureichen und sie über die Benutzeroberfläche der Konsole zu überprüfen:
```
Looks good. Can you start a build workflow to apply these changes to the policy.
```
1. Nachdem Sie die Änderungen übernommen und mit dem nächsten fehlgeschlagenen Test fortgefahren sind, bitten Sie Kiro CLI, die neueste Version der Richtlinie neu zu laden:
```
I applied the changes. Reload the latest build of the policy.
```
## Nächste Schritte
Sobald Sie mit der Automated Reasoning-Richtlinie zufrieden sind, können Sie sie für die Verwendung in Amazon Bedrock Guardrails bereitstellen. Weitere Informationen finden Sie unter [Implementieren der Automated-Reasoning-Richtlinie in die Anwendung](deploy-automated-reasoning-policy.md).
Nach der Implementierung Ihrer Richtlinie finden Sie unter Anleitungen [Integrieren Sie automatisierte Argumentationsprüfungen in Ihre Anwendung](integrate-automated-reasoning-checks.md) zur Verwendung von Automated Reasoning Checks zur Laufzeit, um LLM-Antworten zu validieren und auf das Feedback zu reagieren.
## Kontext-Aufforderung zur automatischen Argumentationsrichtlinie
Kopieren Sie den folgenden Inhalt und speichern Sie ihn in einer Markdown-Datei in Ihrem Projektordner für Kiro CLI. Diese Aufforderung bietet Kiro CLI den Kontext, den es benötigt, um mit der Automated Reasoning-Richtlinie APIs korrekt zu arbeiten.
```
# Automated Reasoning Policy APIs and Workflows
## Table of Contents
### Core APIs
- Policy Management
- Policy Versions
- Build Workflows
- Test Management
- Annotations & Scenarios
### Build Workflow Types
- INGEST_CONTENT Workflow
- REFINE_POLICY Workflow
- IMPORT_POLICY Workflow
- GENERATE_FIDELITY_REPORT Workflow
### Annotation Type Reference
- Type Management Annotations
- Variable Management Annotations
- Rule Management Annotations
- Natural Language Rule Creation
- Feedback-Based Updates
### Common Workflows
1. Getting Started (New Policy)
2. Building Policy from Document
3. Policy Development Cycle
4. REFINE_POLICY Workflow (Annotation-Based)
### Testing Workflow
1. Primary Approach: Scenarios API (Recommended)
2. Secondary Approach: Test Cases (User Experience)
3. Test Result Analysis and Troubleshooting
### Build Workflow Monitoring
- Check Build Status
- List Build History
- Best Practice: Clean Build Management
- Troubleshooting Build Failures
### Build Workflow Assets
- Asset Types
- Understanding Conflicting Rules
- Understanding Disjoint Rule Sets
- Advanced Quality Report Analysis
### Additional Topics
- Policy Version Export
- Key Concepts
- Important Format Requirements
- Policy Modeling Best Practices
- ARN Formats
## Core APIs
### Policy Management
- `create-automated-reasoning-policy` - Create initial policy (returns policy ARN). Supports optional `--description`, `--kms-key-id` (for encryption with a customer managed AWS KMS key), `--tags` (up to 200 tags), and `--client-request-token` (idempotency token).
- `get-automated-reasoning-policy` - Retrieve policy (DRAFT version by default with unversioned ARN). Returns `policyId`, `definitionHash`, and `kmsKeyArn` (if a KMS key was provided at creation).
- `update-automated-reasoning-policy` - Update DRAFT policy with new definition. Accepts optional `--name` and `--description` updates alongside `--policy-definition` (required).
- `delete-automated-reasoning-policy` - Delete policy. Supports optional `--force` flag: when true, deletes the policy and all its artifacts (versions, test cases, test results) without validation; when false (default), validates that all artifacts have been deleted first.
- `list-automated-reasoning-policies` - List all policies. Supports optional `--policy-arn` filter to list only versions of a specific policy.
### Policy Versions
- `create-automated-reasoning-policy-version` - Snapshot DRAFT into numbered version. Requires `--last-updated-definition-hash` (concurrency token from get/create/update response). Supports optional `--tags` (up to 200 tags) and `--client-request-token`.
- `export-automated-reasoning-policy-version` - Export specific policy version definition including rules, variables, and types.
### Build Workflows
- `start-automated-reasoning-policy-build-workflow` - Start build process. Valid `--build-workflow-type` values: `INGEST_CONTENT`, `REFINE_POLICY`, `IMPORT_POLICY`, `GENERATE_FIDELITY_REPORT`. Supports optional `--client-request-token` (idempotency token, passed as header).
- `get-automated-reasoning-policy-build-workflow` - Get build workflow status. Status values: `SCHEDULED`, `CANCEL_REQUESTED`, `PREPROCESSING`, `BUILDING`, `TESTING`, `COMPLETED`, `FAILED`, `CANCELLED`.
- `cancel-automated-reasoning-policy-build-workflow` - Cancel running build
- `delete-automated-reasoning-policy-build-workflow` - Delete build workflow. Requires `--last-updated-at` (concurrency token timestamp).
- `list-automated-reasoning-policy-build-workflows` - List build workflows
- `get-automated-reasoning-policy-build-workflow-result-assets` - Get compiled policy assets. Requires `--asset-type`. Valid asset types: `BUILD_LOG`, `QUALITY_REPORT`, `POLICY_DEFINITION`, `GENERATED_TEST_CASES`, `POLICY_SCENARIOS`, `FIDELITY_REPORT`, `ASSET_MANIFEST`, `SOURCE_DOCUMENT`. Supports optional `--asset-id` (required when retrieving `SOURCE_DOCUMENT` assets if multiple source documents were used; obtain from the `ASSET_MANIFEST`).
### Test Management
- `create-automated-reasoning-policy-test-case` - Create test case. Requires `--guard-content` and `--expected-aggregated-findings-result`. Supports optional `--query-content`, `--confidence-threshold` (Double, 0 to 1, minimum confidence level for logic validation), and `--client-request-token`.
- `get-automated-reasoning-policy-test-case` - Get test case details (includes `confidenceThreshold` if set)
- `update-automated-reasoning-policy-test-case` - Update test case. Requires `--guard-content`, `--expected-aggregated-findings-result`, and `--last-updated-at` (concurrency token). Supports optional `--query-content`, `--confidence-threshold`, and `--client-request-token`.
- `delete-automated-reasoning-policy-test-case` - Delete test case. Requires `--last-updated-at` (concurrency token).
- `list-automated-reasoning-policy-test-cases` - List test cases
- `start-automated-reasoning-policy-test-workflow` - Run tests against a completed build. Requires `--build-workflow-id` (the build workflow must show COMPLETED status). Supports optional `--test-case-ids` (array of test case IDs to run; if not provided, all tests for the policy are run) and `--client-request-token`.
- `get-automated-reasoning-policy-test-result` - Get test result for a specific test case. Requires `--build-workflow-id` and `--test-case-id`.
- `list-automated-reasoning-policy-test-results` - List test results. Requires `--build-workflow-id`.
### Annotations & Scenarios
- `get-automated-reasoning-policy-annotations` - Get policy annotations for a build workflow. Requires `--build-workflow-id`. Returns `annotations`, `annotationSetHash` (concurrency token), `buildWorkflowId`, `name`, `policyArn`, and `updatedAt`.
- `update-automated-reasoning-policy-annotations` - Update annotations for a build workflow. Requires `--build-workflow-id`, `--annotations` (array of annotation objects, max 10), and `--last-updated-annotation-set-hash` (concurrency token from get-annotations response). Returns updated `annotationSetHash`.
- `get-automated-reasoning-policy-next-scenario` - Get next test scenario
**Important**: Do NOT use `get-automated-reasoning-policy-annotations` or
`update-automated-reasoning-policy-annotations` for the `REFINE_POLICY` workflow. Annotations are passed directly in the `start-automated-reasoning-policy-build-workflow` call.
## Build Workflow Types
1. **INGEST_CONTENT** - Process documents to create/extract policy rules
2. **REFINE_POLICY** - Refine and improve existing policies using annotations
3. **IMPORT_POLICY** - Import policies from external sources
4. **GENERATE_FIDELITY_REPORT** - Generate a fidelity report for the policy
### INGEST_CONTENT Workflow
- **Purpose**: Extract policy rules from documents (PDF/TXT)
- **Input**: Documents + optional existing policy definition
- **Use Cases**: Document-to-policy conversion, incremental policy building
- **Content Structure**: `workflowContent.documents[]`
**CRITICAL: Complete Policy Definition for Incremental Building**
When adding documents to an existing policy, you must include the complete current policy definition:
```json
// CORRECT - Incremental policy building
{
"policyDefinition": {
"version": "1.0",
"types": [/* ALL existing types */],
"rules": [/* ALL existing rules */],
"variables": [/* ALL existing variables */]
},
"workflowContent": {
"documents": [/* New documents to process */]
}
}
```
### REFINE_POLICY Workflow
- **Purpose**: Iteratively improve policies with targeted modifications
- **Input**: Policy definition + annotations for specific changes
- **Use Cases**: Kiro CLI suggestions, test-driven improvements, feedback-based refinement
- **Content Structure**: `workflowContent.policyRepairAssets.annotations[]`
**CRITICAL: Complete Policy Definition Required**
ALL build workflows require the COMPLETE existing policy definition in the `policyDefinition` section, not just the changes you want to make.
**REFINE_POLICY Annotation Types:**
**Top-Level Annotations:**
- **Type Management**: `addType`, `updateType`, `deleteType`
- **Variable Management**: `addVariable`, `updateVariable`, `deleteVariable`
- **Rule Management**: `addRule`, `updateRule`, `deleteRule`
- **Natural Language Rules**: `addRuleFromNaturalLanguage`
- **Feedback-Based Updates**: `updateFromRulesFeedback`, `updateFromScenarioFeedback`
**Sub-Operations (only within `updateType`):**
- `addTypeValue`, `updateTypeValue`, `deleteTypeValue` - Used to modify values within an existing custom type
**important**: Only create rules in if/then format.
## Annotation Type Reference
### Type Management Annotations
#### `addType` - Create New Custom Type
```json
{
"addType": {
"name": "ApprovalStatus",
"description": "Status values for approval requests",
"values": [
{
"value": "PENDING",
"description": "Request is awaiting approval"
},
{
"value": "APPROVED",
"description": "Request has been approved"
},
{
"value": "REJECTED",
"description": "Request has been rejected"
}
]
}
}
```
#### `updateType` - Modify Existing Custom Type
```json
{
"updateType": {
"name": "ApprovalStatus",
"newName": "RequestStatus",
"description": "Updated status values for all request types",
"values": [
{
"addTypeValue": {
"value": "ESCALATED",
"description": "Request escalated to higher authority"
}
},
{
"updateTypeValue": {
"value": "PENDING",
"newValue": "WAITING",
"description": "Request is waiting for review"
}
},
{
"deleteTypeValue": {
"value": "REJECTED"
}
}
]
}
}
```
#### `deleteType` - Remove Custom Type
```json
{
"deleteType": {
"name": "ObsoleteType"
}
}
```
### Variable Management Annotations
#### `addVariable` - Create New Variable
```json
{
"addVariable": {
"name": "requestAmount",
"type": "real",
"description": "The monetary amount of the approval request in USD"
}
}
```
#### `updateVariable` - Modify Existing Variable
```json
{
"updateVariable": {
"name": "requestAmount",
"newName": "approvalAmount",
"description": "The monetary amount requiring approval in USD (updated description)"
}
}
```
#### `deleteVariable` - Remove Variable
```json
{
"deleteVariable": {
"name": "obsoleteVariable"
}
}
```
### Rule Management Annotations
#### `addRule` - Create New Rule (SMT-LIB)
```json
{
"addRule": {
"expression": "(=> (and (= userRole MANAGER) (< requestAmount 10000)) (not approvalRequired))"
}
}
```
#### `updateRule` - Modify Existing Rule
```json
{
"updateRule": {
"ruleId": "A1B2C3D4E5F6",
"expression": "(=> (and (= userRole MANAGER) (< requestAmount 5000)) (not approvalRequired))"
}
}
```
#### `deleteRule` - Remove Rule
```json
{
"deleteRule": {
"ruleId": "G7H8I9J0K1L2"
}
}
```
### Natural Language Rule Creation
#### `addRuleFromNaturalLanguage` - Convert Natural Language to Rule
```json
{
"addRuleFromNaturalLanguage": {
"naturalLanguage": "Managers can approve expense requests up to $5,000 without additional authorization. Senior managers can approve up to $25,000."
}
}
```
### Feedback-Based Updates
#### `updateFromRulesFeedback` - Improve Rules Based on Performance
```json
{
"updateFromRulesFeedback": {
"ruleIds": ["A1B2C3D4E5F6", "G7H8I9J0K1L2"],
"feedback": "These rules are too restrictive for emergency scenarios. Add exception handling for urgent requests with proper escalation paths."
}
}
```
#### `updateFromScenarioFeedback` - Improve Based on Test Scenarios
```json
{
"updateFromScenarioFeedback": {
"ruleIds": ["A1B2C3D4E5F6"],
"scenarioExpression": "(and (= requestType EMERGENCY) (= userRole MANAGER) (> requestAmount 10000))",
"feedback": "Emergency requests should have different approval thresholds. Current rule blocks legitimate emergency expenses."
}
}
```
**Important**: Do NOT use `get-automated-reasoning-policy-annotations` or `update-automated-reasoning-policy-annotations` for the `REFINE_POLICY` workflow. Annotations are passed directly in the `start-automated-reasoning-policy-build-workflow` call.
## Common Workflows
### 1. Getting Started (New Policy)
**CRITICAL: Always Create Policy First**
You must create a policy before starting any build workflows.
```bash
# Step 1: Create initial policy (REQUIRED FIRST STEP)
aws bedrock create-automated-reasoning-policy \
--region us-west-2 \
--name "YourPolicyName"
# Step 2: Extract the policyArn from the response above, then start build workflow
aws bedrock start-automated-reasoning-policy-build-workflow \
--region us-west-2 \
--policy-arn "arn:aws:bedrock:us-west-2:123456789012:automated-reasoning-policy/abcd1234efgh" \
--build-workflow-type INGEST_CONTENT \
--source-content
# Step 3: Get build results
aws bedrock get-automated-reasoning-policy-build-workflow-result-assets \
--region us-west-2 \
--policy-arn "arn:aws:bedrock:us-west-2:123456789012:automated-reasoning-policy/abcd1234efgh" \
--build-workflow-id
```
### 2. Building Policy from Document
**RECOMMENDED: Using CLI Input JSON File**
```bash
# Step 1: Encode PDF to base64 and create JSON file with base64 content
PDF_BASE64=$(base64 -i your-policy.pdf | tr -d '\n')
cat > ingest-policy.json << EOF
{
"policyArn": "arn:aws:bedrock:us-west-2:123456789012:automated-reasoning-policy/your-actual-policy-id",
"buildWorkflowType": "INGEST_CONTENT",
"sourceContent": {
"policyDefinition": {
"version": "1.0",
"types": [],
"rules": [],
"variables": []
},
"workflowContent": {
"documents": [
{
"document": "$PDF_BASE64",
"documentContentType": "pdf",
"documentName": "Company Policy Document",
"documentDescription": "Main policy document containing business rules and organizational guidelines."
}
]
}
}
}
EOF
# Step 2: Use the JSON file
aws bedrock start-automated-reasoning-policy-build-workflow \
--region us-west-2 \
--cli-input-json file://ingest-policy.json
```
### 3. Policy Development Cycle
```bash
# 1. Import/process policy definition
aws bedrock start-automated-reasoning-policy-build-workflow \
--build-workflow-type IMPORT_POLICY
# 2. Update DRAFT with processed definition
aws bedrock update-automated-reasoning-policy \
--policy-arn \
--policy-definition
# 3. Create versioned snapshot of DRAFT (definitionHash from step 2 response)
aws bedrock create-automated-reasoning-policy-version \
--policy-arn \
--last-updated-definition-hash
```
## Testing Workflow
### Primary Approach: Scenarios API (Recommended)
Use `get-automated-reasoning-policy-next-scenario` for comprehensive policy validation.
The Scenarios API is superior for testing because it:
- Tests formal logic directly - Validates policy rules work correctly
- AI-generated scenarios - Comprehensive coverage of edge cases and rule interactions
- Targets specific rules - Tests individual rules and combinations
- Always works - No natural language translation issues
- Intelligent test generation - AI understands policy logic deeply
```bash
# Generate intelligent test scenarios automatically
aws bedrock get-automated-reasoning-policy-next-scenario \
--policy-arn "arn:aws:bedrock:region:account:automated-reasoning-policy/policy-id" \
--build-workflow-id "workflow-123"
```
### Secondary Approach: Test Cases (User Experience)
Use manual test cases to validate natural language translation.
```bash
# Create test cases for natural language validation
aws bedrock create-automated-reasoning-policy-test-case \
--policy-arn "arn:aws:bedrock:region:account:automated-reasoning-policy/policy-id" \
--guard-content "It is 2:30 PM on a clear day" \
--query-content "What color should the sky be?" \
--expected-aggregated-findings-result "VALID" \
--confidence-threshold 0.8
```
### Test Result Analysis and Troubleshooting
**Understanding Test Results:**
**Scenarios API Results:**
- `expectedResult: SATISFIABLE` - Policy logic works correctly
- API errors or logic conflicts - Policy needs fixing with REFINE_POLICY
**Common Test Case Failure Modes:**
1. **TRANSLATION_AMBIGUOUS**
- Problem: AI can't map natural language to policy variables
- Solution: Improve variable descriptions with more natural language synonyms
2. **SATISFIABLE when expecting VALID**
- Problem: Your expected result label is likely WRONG, not the policy
- SATISFIABLE = "This scenario is logically consistent with the policy rules"
- VALID = "This is the correct/expected answer according to the policy"
- Solution: Change `expectedAggregatedFindingsResult` from `VALID` to `SATISFIABLE`
3. **Empty testFindings arrays**
- Problem: Translation issues, not rule violations
- Solution: Focus on improving natural language descriptions, not policy logic
**Valid values for `expectedAggregatedFindingsResult`:**
- `VALID` - The claims are true, implied by the premises and the policy
- `INVALID` - The claims are false, not implied by the premises and policy
- `SATISFIABLE` - The claims can be true or false depending on assumptions
- `IMPOSSIBLE` - Automated Reasoning can't make a statement (e.g., conflicting policy rules)
- `TRANSLATION_AMBIGUOUS` - Ambiguity in translation prevented validity checking
- `TOO_COMPLEX` - Input too complex for Automated Reasoning to process within latency limits
- `NO_TRANSLATION` - Some or all of the input wasn't translated into logic
### Running Tests Against a Build
After creating test cases, run them against a completed build workflow:
```bash
# Run all tests against a completed build
aws bedrock start-automated-reasoning-policy-test-workflow \
--policy-arn "arn:aws:bedrock:region:account:automated-reasoning-policy/policy-id" \
--build-workflow-id "workflow-123"
# Run specific tests only
aws bedrock start-automated-reasoning-policy-test-workflow \
--policy-arn "arn:aws:bedrock:region:account:automated-reasoning-policy/policy-id" \
--build-workflow-id "workflow-123" \
--test-case-ids '["A1B2C3D4E5F6"]'
# Get result for a specific test case
aws bedrock get-automated-reasoning-policy-test-result \
--policy-arn "arn:aws:bedrock:region:account:automated-reasoning-policy/policy-id" \
--build-workflow-id "workflow-123" \
--test-case-id "A1B2C3D4E5F6"
# List all test results for a build
aws bedrock list-automated-reasoning-policy-test-results \
--policy-arn "arn:aws:bedrock:region:account:automated-reasoning-policy/policy-id" \
--build-workflow-id "workflow-123"
```
## Build Workflow Monitoring
**Critical Build Limits**: The API supports maximum 2 total build workflows per policy, with only 1 allowed to be IN_PROGRESS at any time. When a build workflow completes, you can instruct the user to review the output using the console.
### Check Build Status
```bash
aws bedrock get-automated-reasoning-policy-build-workflow \
--policy-arn "arn:aws:bedrock:region:account:automated-reasoning-policy/policy-id" \
--build-workflow-id "workflow-123"
```
### List Build History
```bash
aws bedrock list-automated-reasoning-policy-build-workflows \
--policy-arn "arn:aws:bedrock:region:account:automated-reasoning-policy/policy-id" \
--max-results 50
```
### Best Practice: Clean Build Management
```bash
# 1. Check existing builds before starting new ones
aws bedrock list-automated-reasoning-policy-build-workflows \
--policy-arn \
--max-results 10
# 2. Delete old/completed builds if you have 2 already
aws bedrock delete-automated-reasoning-policy-build-workflow \
--policy-arn \
--build-workflow-id "old-workflow-id" \
--last-updated-at "2025-11-15T00:41:18.608000+00:00"
# 3. Now start your new build
aws bedrock start-automated-reasoning-policy-build-workflow \
--policy-arn \
--build-workflow-type INGEST_CONTENT \
--source-content
```
## Build Workflow Assets
After a build workflow completes successfully, you can retrieve various assets. After you complete a build workflow, you can ask the user to check the build diff using the Automated Reasoning checks console.
### Asset Types
#### 1. ASSET_MANIFEST - Index of All Assets
```bash
aws bedrock get-automated-reasoning-policy-build-workflow-result-assets \
--policy-arn "arn:aws:bedrock:region:account:automated-reasoning-policy/policy-id" \
--build-workflow-id "workflow-123" \
--asset-type "ASSET_MANIFEST"
```
**What it contains:**
- A manifest listing all available assets and their IDs for the build workflow
- Use this to discover asset IDs needed for retrieving assets
#### 2. POLICY_DEFINITION - The Main Output
```bash
aws bedrock get-automated-reasoning-policy-build-workflow-result-assets \
--policy-arn "arn:aws:bedrock:region:account:automated-reasoning-policy/policy-id" \
--build-workflow-id "workflow-123" \
--asset-type "POLICY_DEFINITION"
```
**What it contains:**
- Compiled policy with extracted/refined rules, variables, and types
- SMT-LIB expressions for all rules
- Complete policy structure ready for deployment
#### 3. BUILD_LOG - Build Process Details
```bash
aws bedrock get-automated-reasoning-policy-build-workflow-result-assets \
--policy-arn "arn:aws:bedrock:region:account:automated-reasoning-policy/policy-id" \
--build-workflow-id "workflow-123" \
--asset-type "BUILD_LOG"
```
**What it shows:**
- Document processing steps - What content was analyzed
- Extraction results - What rules, variables, and types were found
- Processing warnings - Content that couldn't be interpreted
- Success/failure status for each extraction step
#### 4. QUALITY_REPORT - Policy Quality Analysis
```bash
aws bedrock get-automated-reasoning-policy-build-workflow-result-assets \
--policy-arn "arn:aws:bedrock:region:account:automated-reasoning-policy/policy-id" \
--build-workflow-id "workflow-123" \
--asset-type "QUALITY_REPORT"
```
**What it contains:**
- Conflicting rules - Rules that contradict each other
- Unused variables - Variables not referenced by any rules
- Unused type values - Enum values not used in rules
- Disjoint rule sets - Groups of rules that don't interact
#### 5. GENERATED_TEST_CASES - Auto-Generated Tests
```bash
aws bedrock get-automated-reasoning-policy-build-workflow-result-assets \
--policy-arn "arn:aws:bedrock:region:account:automated-reasoning-policy/policy-id" \
--build-workflow-id "workflow-123" \
--asset-type "GENERATED_TEST_CASES"
```
**What it contains:**
- Automatically generated test cases based on the policy rules
#### 6. POLICY_SCENARIOS - Policy Test Scenarios
```bash
aws bedrock get-automated-reasoning-policy-build-workflow-result-assets \
--policy-arn "arn:aws:bedrock:region:account:automated-reasoning-policy/policy-id" \
--build-workflow-id "workflow-123" \
--asset-type "POLICY_SCENARIOS"
```
**What it contains:**
- AI-generated scenarios for comprehensive policy validation
#### 7. FIDELITY_REPORT - Policy Fidelity Analysis
```bash
aws bedrock get-automated-reasoning-policy-build-workflow-result-assets \
--policy-arn "arn:aws:bedrock:region:account:automated-reasoning-policy/policy-id" \
--build-workflow-id "workflow-123" \
--asset-type "FIDELITY_REPORT"
```
**What it contains:**
- Fidelity analysis results from a GENERATE_FIDELITY_REPORT build workflow
#### 8. SOURCE_DOCUMENT - Original Source Documents
```bash
# Requires --asset-id obtained from the ASSET_MANIFEST
aws bedrock get-automated-reasoning-policy-build-workflow-result-assets \
--policy-arn "arn:aws:bedrock:region:account:automated-reasoning-policy/policy-id" \
--build-workflow-id "workflow-123" \
--asset-type "SOURCE_DOCUMENT" \
--asset-id "a1b2c3d4-e5f6-4a7b-8c9d-e0f1a2b3c4d5"
```
**What it contains:**
- The original source document used in the build workflow
- The `--asset-id` parameter is required because multiple source documents may have been used
```
# Implementieren der Automated-Reasoning-Richtlinie in die Anwendung
Wenn Sie die Automated-Reasoning-Richtlinie getestet haben und mit ihrer Leistung zufrieden sind, können Sie sie für die Verwendung in der Anwendung mit Integritätsschutz für Amazon Bedrock bereitstellen. Auf dieser Seite wird der gesamte Bereitstellungsablauf behandelt: Speichern einer unveränderlichen Version, Anhängen dieser Version an eine Leitplanke, Automatisieren der Bereitstellung mit Pipelines und Integration in Pipelines. CloudFormation CI/CD
## Speichern einer Version der Automated-Reasoning-Richtlinie
Wenn Sie mit dem Testen Ihrer Richtlinie fertig sind, erstellen Sie eine unveränderliche Version. Unveränderliche Versionen stellen sicher, dass sich die mit Ihrer Leitplanke verknüpfte Richtlinie nicht unerwartet ändert, wenn Sie den ENTWURF weiter bearbeiten. Jede Version wird durch eine numerische Versionsnummer (1, 2, 3,...) identifiziert und kann nach der Erstellung nicht mehr geändert werden.
### Verwenden der Konsole
1. Wählen Sie im linken Navigationsbereich **Automated Reasoning** aus.
1. Wählen Sie die Richtlinie für Automated Reasoning aus, die Sie mit der Anwendung verwenden möchten.
1. Wählen Sie **Als neue Version speichern** aus. Sie können diese Richtlinienversion zusammen mit dem Integritätsschutz verwenden.
### Verwenden der API
Verwenden Sie die `CreateAutomatedReasoningPolicyVersion` API, um eine unveränderliche Version Ihrer Automated Reasoning-Richtlinie zu erstellen.
#### Anforderungsparameter
`policyArn` (Erforderlich)
Der Amazon-Ressourcenname (ARN) der Automated-Reasoning-Richtlinie, für die eine Version erstellt werden soll.
`lastUpdatedDefinitionHash` (Erforderlich)
Der Hash der Richtliniendefinition für die neue Version. Rufen Sie diesen Hash von der `GetAutomatedReasoningPolicy` API ab. Dadurch wird sichergestellt, dass Sie genau die Richtliniendefinition versionieren, die Sie getestet haben.
#### Beispiel
```
# Get the current definition hash
aws bedrock get-automated-reasoning-policy \
--policy-arn "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk" \
--query "definitionHash" --output text
# Create the version
aws bedrock create-automated-reasoning-policy-version \
--policy-arn "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk" \
--last-updated-definition-hash "583463f067a8a4f49fc1206b4642fd40..."
```
Beispielantwort:
```
{
"policyArn": "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk",
"version": "1",
"name": "MyHRPolicy"
}
```
## Hinzufügen der Automated-Reasoning-Richtlinie zum Integritätsschutz
Sobald Sie eine gespeicherte Version Ihrer Automated Reasoning-Richtlinie haben, fügen Sie sie einer Leitplanke hinzu. Die Guardrail ist die Laufzeitkomponente, die Ihre Anwendung zur Validierung von LLM-Antworten aufruft. Sie können einer neuen oder vorhandenen Guardrail eine Richtlinie für automatisiertes Denken hinzufügen.
### Verwenden der Konsole
1. **Wählen Sie in der linken Navigationsleiste „**Leitplanken“ und anschließend „Leitplanke** **erstellen“ aus (oder wählen Sie eine bestehende Leitplanke** und anschließend „Bearbeiten“).**
1. Wenn Sie zum Bildschirm **Prüfung durch Automated Reasoning hinzufügen** gelangen, wählen Sie **Richtlinie für Automated Reasoning aktivieren** aus.
1. Wählen Sie als **Richtlinienname** eine gespeicherte Version einer Automated-Reasoning-Richtlinie aus und klicken Sie dann auf **Weiter**.
1. Beenden Sie die Erstellung oder Aktualisierung Ihrer Leitplanke.
### Verwenden der API
Verwenden Sie die `UpdateGuardrail` API `CreateGuardrail` oder, um Ihrer Leitplanke eine Richtlinie für automatisiertes Denken hinzuzufügen. Nehmen Sie den `automatedReasoningConfig` Parameter in den ARN der versionierten Richtlinie auf.
#### Anforderungsparameter
`automatedReasoningConfig`
Die Konfiguration für Automated-Reasoning-Prüfungen im Integritätsschutz für Amazon Bedrock.
`policyArn` (Erforderlich)
Der ARN der Version der Automated Reasoning-Richtlinie, die Sie mit Ihrer Leitplanke verwenden möchten. Verwenden Sie den versionierten ARN (endet auf `:1``:2`, usw.), nicht den unversionierten ARN.
#### Beispiel
```
aws bedrock create-guardrail \
--name "HR-Policy-Guardrail" \
--description "Guardrail for HR policy validation" \
--automated-reasoning-policy-config policies="arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk:1" \
--cross-region-config '{"guardrailProfileIdentifier": "us.guardrail.v1:0"}' \
--blocked-input-messaging "I cannot process this request." \
--blocked-outputs-messaging "I cannot provide this response."
```
**Wichtig**
Verwenden Sie den versionierten Richtlinien-ARN (z. B.`arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk:1`). Wenn Sie den unversionierten ARN verwenden, gibt die API einen Fehler zurück. Erstellen Sie zuerst eine Version mit. `CreateAutomatedReasoningPolicyVersion`
**Wichtig**
Leitplanken, die automatische Argumentationsprüfungen verwenden, erfordern ein regionsübergreifendes Inferenzprofil. Fügen Sie dem `--cross-region-config` Parameter ein`guardrailProfileIdentifier`, das Ihrem Regionspräfix entspricht (z. B. für US-Regionen oder `us.guardrail.v1:0` `eu.guardrail.v1:0` für EU-Regionen). Wenn Sie diesen Parameter weglassen, gibt die API a `ValidationException` zurück.
## Exportieren Sie eine Richtlinienversion für die Bereitstellung
Um eine Richtlinie über CloudFormation oder eine CI/CD Pipeline bereitzustellen, benötigen Sie die JSON-Richtliniendefinition. Verwenden Sie die `ExportAutomatedReasoningPolicyVersion` API, um die vollständige Richtliniendefinition — einschließlich aller Regeln, Variablen und benutzerdefinierten Typen — aus einer gespeicherten Version zu exportieren.
Die exportierte Definition hat dasselbe Format, das von der `PolicyDefinition` Eigenschaft der CloudFormation `AWS::Bedrock::AutomatedReasoningPolicy` Ressource akzeptiert wird. Dies macht es einfach, eine Richtlinie vom interaktiven Konsolen-Workflow zur automatisierten Bereitstellung zu übertragen.
```
# Export the policy definition from version 1
aws bedrock export-automated-reasoning-policy-version \
--policy-arn "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk:1" \
--query "policyDefinition" \
--output json > policy-definition.json
```
Das exportierte JSON enthält die folgende Struktur:
```
{
"version": "1.0",
"variables": [
{
"name": "isFullTime",
"type": "BOOL",
"description": "Whether the employee works full-time (true) or part-time (false)."
},
{
"name": "tenureMonths",
"type": "INT",
"description": "The number of complete months the employee has been continuously employed."
}
],
"rules": [
{
"id": "A1B2C3D4E5F6",
"expression": "(=> (and isFullTime (> tenureMonths 12)) eligibleForParentalLeave)"
}
],
"types": []
}
```
Speichern Sie diese Datei zusammen mit Ihren CloudFormation Vorlagen in der Versionskontrolle. Wenn Sie Ihre Richtlinie aktualisieren, exportieren Sie die neue Version und aktualisieren Sie die Datei, um eine Bereitstellung auszulösen.
## Automatisieren Sie die Bereitstellung mit CloudFormation
Verwenden Sie CloudFormation es, um Ihre Automated Reasoning-Richtlinie und Ihre Guardrail als Infrastruktur als Code bereitzustellen. Die `AWS::Bedrock::AutomatedReasoningPolicy` Ressource erstellt eine Richtlinie mit einer Richtliniendefinition, die Sie aus der API oder Konsole exportieren. In Kombination mit `AWS::Bedrock::Guardrail` können Sie den gesamten Validierungsstapel in einer einzigen Vorlage bereitstellen.
**Anmerkung**
CloudFormation erstellt die Richtlinienressource mit der von Ihnen angegebenen Richtliniendefinition. Es führt keinen Build-Workflow aus und extrahiert auch keine Regeln aus Quelldokumenten. Sie müssen Ihre Richtlinie zuerst interaktiv (mithilfe der Konsole, der API oder der Kiro CLI) erstellen und testen und dann die getestete Richtliniendefinition zur Verwendung in Ihrer Vorlage exportieren. Weitere Informationen finden Sie unter [Exportieren Sie eine Richtlinienversion für die Bereitstellung](#export-policy-version).
Die vollständige Eigenschaftsreferenz der Richtlinienressource finden Sie unter [AWS::Bedrock::AutomatedReasoningRichtlinie](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-bedrock-automatedreasoningpolicy.html) in der *CloudFormation Vorlagenreferenz*.
### Beispiel: Stellen Sie eine Richtlinie und eine Leitplanke bereit
Die folgende CloudFormation Vorlage erstellt eine Richtlinie für automatisiertes Denken mit einer Richtliniendefinition und einer Leitplanke, die darauf verweist. Ersetzen Sie die Richtliniendefinition durch die JSON-Datei, die aus Ihrer getesteten Richtlinie exportiert wurde.
```
AWSTemplateFormatVersion: '2010-09-09'
Description: Deploy an Automated Reasoning policy and guardrail
Parameters:
PolicyName:
Type: String
Default: MyHRPolicy
Description: Name of the Automated Reasoning policy
GuardrailName:
Type: String
Default: HR-Policy-Guardrail
Description: Name of the guardrail
Resources:
AutomatedReasoningPolicy:
Type: AWS::Bedrock::AutomatedReasoningPolicy
Properties:
Name: !Ref PolicyName
Description: Validates HR chatbot responses about leave eligibility
PolicyDefinition:
Version: '1.0'
Variables:
- Name: isFullTime
Type: BOOL
Description: >-
Whether the employee works full-time (true) or part-time (false).
Set to true when users mention being full-time or working 40+ hours
per week.
- Name: tenureMonths
Type: INT
Description: >-
The number of complete months the employee has been continuously
employed. When users mention years of service, convert to months
(for example, 2 years = 24 months).
- Name: eligibleForParentalLeave
Type: BOOL
Description: >-
Whether the employee is eligible for parental leave based on
employment status and tenure.
Rules:
- Id: A1B2C3D4E5F6
Expression: >-
(=> (and isFullTime (> tenureMonths 12))
eligibleForParentalLeave)
- Id: G7H8I9J0K1L2
Expression: >-
(=> (or (not isFullTime) (<= tenureMonths 12))
(not eligibleForParentalLeave))
Types: []
Tags:
- Key: Environment
Value: Production
- Key: Team
Value: HR
Guardrail:
Type: AWS::Bedrock::Guardrail
Properties:
Name: !Ref GuardrailName
Description: Guardrail with Automated Reasoning checks for HR policy
BlockedInputMessaging: I cannot process this request.
BlockedOutputsMessaging: I cannot provide this response.
AutomatedReasoningPolicyConfig:
Policies:
- !GetAtt AutomatedReasoningPolicy.PolicyArn
CrossRegionConfig:
GuardrailProfileArn: !Sub "arn:aws:bedrock:${AWS::Region}:${AWS::AccountId}:guardrail-profile/us.guardrail.v1:0"
Outputs:
PolicyArn:
Description: ARN of the Automated Reasoning policy
Value: !GetAtt AutomatedReasoningPolicy.PolicyArn
PolicyId:
Description: ID of the Automated Reasoning policy
Value: !GetAtt AutomatedReasoningPolicy.PolicyId
GuardrailId:
Description: ID of the guardrail
Value: !Ref Guardrail
```
**Tipp**
Bewahren Sie bei Produktionsbereitstellungen die Richtliniendefinition in einer separaten JSON-Datei auf und verweisen Sie darauf, indem Sie sie als Vorlagenparameter laden `Fn::Include` oder verwenden. Dadurch bleibt Ihre Vorlage sauber und es ist einfacher, die Richtliniendefinition unabhängig zu aktualisieren.
**Wichtig**
Leitplanken, die automatische Argumentationsprüfungen verwenden, erfordern ein regionsübergreifendes Inferenzprofil. Die `CrossRegionConfig` Immobilie gibt den ARN des Leitplankenprofils für Ihre Region an. Ersetzen Sie das Regionspräfix (`us`) durch das entsprechende Präfix für Ihre Einsatzregion (z. B. `eu` für EU-Regionen). Wenn Sie diese Eigenschaft weglassen, schlägt die Erstellung der Leitplanke fehl.
### Beispiel: Bereitstellung mit einem vom Kunden verwalteten KMS-Schlüssel
Um Ihre Richtlinie mit einem vom Kunden verwalteten KMS-Schlüssel zu verschlüsseln, fügen Sie die `KmsKeyId` Eigenschaft hinzu. Sie müssen auch die Schlüsselrichtlinie so konfigurieren, dass Amazon Bedrock den Schlüssel verwenden kann. Informationen zu den erforderlichen Schlüsselrichtlinienberechtigungen finden Sie unter[KMS-Berechtigungen für Automated-Reasoning-Richtlinien](create-automated-reasoning-policy.md#automated-reasoning-policy-kms-permissions).
```
AutomatedReasoningPolicy:
Type: AWS::Bedrock::AutomatedReasoningPolicy
Properties:
Name: !Ref PolicyName
Description: Validates HR chatbot responses about leave eligibility
KmsKeyId: !GetAtt PolicyEncryptionKey.Arn
PolicyDefinition:
# ... policy definition ...
Tags:
- Key: Environment
Value: Production
```
**Wichtig**
Um die `KmsKeyId` Eigenschaft zu ändern, muss die Ressource ersetzt werden. CloudFormation löscht die bestehende Richtlinie und erstellt eine neue mit einem neuen ARN. Aktualisieren Sie alle Leitplanken, die auf den alten Richtlinien-ARN verweisen.
## Nächste Schritte
Integrieren Sie nach der Implementierung Ihrer Richtlinie und Ihrer Guardrail automatische Argumentationsprüfungen in Ihre Anwendung, um LLM-Antworten zur Laufzeit zu validieren. Weitere Informationen finden Sie unter [Integrieren Sie automatisierte Argumentationsprüfungen in Ihre Anwendung](integrate-automated-reasoning-checks.md).
# Integrieren Sie automatisierte Argumentationsprüfungen in Ihre Anwendung
Nachdem Sie Ihre Richtlinie für automatisiertes Denken in einer Leitplanke implementiert haben (siehe[Implementieren der Automated-Reasoning-Richtlinie in die Anwendung](deploy-automated-reasoning-policy.md)), können Sie sie zur Laufzeit verwenden, um LLM-Antworten zu validieren und auf das Feedback zu reagieren. Auf dieser Seite wird erklärt, wie Sie die Validierungs-API aufrufen, die Ergebnisse programmgesteuert interpretieren und gängige Integrationsmuster wie das Umschreiben ungültiger Antworten und das Stellen klärender Fragen implementieren.
Automatisierte Prüfungen zur Argumentation funktionieren nur im *Erkennungsmodus* — sie geben Ergebnisse und Feedback zurück, anstatt Inhalte zu blockieren. Ihre Anwendung ist dafür verantwortlich, zu entscheiden, was mit den Ergebnissen geschehen soll: die Antwort zuzustellen, sie neu zu schreiben, um Klarstellung zu bitten oder auf ein Standardverhalten zurückzugreifen.
## Übersicht über die Integration
Zur Laufzeit folgt die Integration diesem Ablauf:
```
User question ──► LLM generates response ──► ApplyGuardrail validates response
│
┌─────────┴─────────┐
│ │
VALID Not VALID
│ │
▼ ▼
Serve response Inspect findings
to user │
┌────────┴────────┐
│ │
OTHER FINDING TRANSLATION_
TYPES AMBIGUOUS / SATISFIABLE
│ │
▼ ▼
Rewrite using Ask user for
AR feedback clarification
│ │
▼ ▼
Validate again Validate with
clarified input
```
Ergebnisse von Automated Reasoning werden über jede API zurückgegeben, die eine Amazon Bedrock Guardrails-Konfiguration unterstützt:
+ `ApplyGuardrail`— Eigenständige Validierungs-API. Verwenden Sie diese Option, wenn Sie Inhalte unabhängig vom LLM-Aufruf validieren möchten. Dies ist der empfohlene Ansatz für automatische Argumentationsprüfungen, da Sie damit die volle Kontrolle darüber haben, welcher Inhalt wann validiert wird.
+ `Converse`und `InvokeModel` — LLM-Aufruf APIs mit Guardrail-Konfiguration. Die Ergebnisse der automatisierten Argumentation werden im Antwortfeld zurückgegeben. `trace`
+ `InvokeAgent`und `RetrieveAndGenerate` — Agent und Wissensdatenbank APIs mit Guardrail-Konfiguration.
Diese Seite konzentriert sich auf die `ApplyGuardrail` API, da sie die größte Flexibilität bei der Implementierung der unten beschriebenen Umschreib- und Klarstellungsmuster bietet. Informationen zur Verwendung von Leitplanken zusammen mit anderen APIs finden Sie unter [Verwenden](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-use.html) einer Leitplanke.
## Beispiel für einen Open-Source-Chatbot zum Umschreiben
Eine vollständige Implementierung der auf dieser Seite beschriebenen Muster im Produktionsstil finden Sie unter [Automated Reasoning](https://github.com/aws-samples/amazon-bedrock-samples/tree/main/responsible_ai/automated-reasoning-rewriting-chatbot) checks rewriting chatbot. GitHub Diese Beispielanwendung demonstriert:
+ Eine iterative Umschreibschleife, in der ungültige Antworten auf der Grundlage von AR-Feedback automatisch korrigiert werden.
+ Folgefragen, wenn das LLM zusätzlichen Kontext vom Benutzer benötigt, um es korrekt umzuschreiben.
+ Ein Timeout-Mechanismus, der die Verarbeitung automatisch wieder aufnimmt, wenn Benutzer auf Fragen zur Klärung nicht antworten.
+ Das Einfügen von Richtlinienkontexten in LLM-Eingabeaufforderungen ermöglicht es dem LLM, beim Umschreiben auf die vollständigen Richtlinienregeln zu verweisen.
+ JSON-Auditprotokollierung jeder Validierungsiteration zur Einhaltung von Vorschriften und zum Debuggen.
Das Beispiel verwendet ein Python/Flask Backend mit einem React-Frontend und kommuniziert mit Amazon Bedrock für LLM-Inferenz und Amazon Bedrock Guardrails zur Validierung über die API. `ApplyGuardrail`
**Anmerkung**
Die Beispielanwendung bezieht den Richtlinieninhalt direkt in die Eingabeaufforderungen zur LLM-Generierung ein, um alle Richtlinien für automatisiertes Denken zu unterstützen, ohne dass Dokumente hochgeladen werden müssen. In einer Produktionsbereitstellung würden Sie in der Regel RAG-Inhalte verwenden oder dem LLM das Originaldokument in natürlicher Sprache anstelle des Quellcodes der Richtlinie für automatisiertes Denken zuleiten.
## Rufen Sie an, ApplyGuardrail bei dem Automated Reasoning geprüft wird
Verwenden Sie die `ApplyGuardrail` API, um Inhalte anhand Ihrer Leitplanke zu validieren. Die API akzeptiert einen oder mehrere Inhaltsblöcke und gibt eine Bewertung zurück, die Ergebnisse von Automated Reasoning beinhaltet.
### Struktur der Anfrage
`guardrailIdentifier` (Erforderlich)
Die Leitplanken-ID oder ARN. Verwenden Sie die Leitplanke, der Ihre Richtlinie für automatisiertes Denken beigefügt ist.
`guardrailVersion` (Erforderlich)
Die Versionsnummer der Leitplanke (z. B.). `1` Verwenden Sie eine nummerierte Version für Produktionsworkloads, nicht. `DRAFT`
`source` (Erforderlich)
`OUTPUT`Wird bei der Validierung von LLM-Antworten auf eingestellt. `INPUT`Wird bei der Validierung von Benutzeraufforderungen auf eingestellt. Bei automatisierten Argumentationsprüfungen validieren Sie in der Regel die LLM-Ausgabe.
`content` (Erforderlich)
Eine Reihe von Inhaltsblöcken, die validiert werden müssen. Jeder Block enthält ein `text` Feld mit dem zu prüfenden Inhalt. Sie können die Benutzerfrage und die LLM-Antwort als separate Inhaltsblöcke übergeben oder sie zu einem einzigen Block kombinieren.
### Beispiel: Validieren Sie eine LLM-Antwort mit dem AWS CLI
```
aws bedrock-runtime apply-guardrail \
--guardrail-identifier "your-guardrail-id" \
--guardrail-version "1" \
--source OUTPUT \
--content '[
{
"text": {
"text": "User: Am I eligible for parental leave if I have been working here for 2 years full-time?\nAssistant: Yes, you are eligible for parental leave."
}
}
]'
```
### Beispiel: Validieren Sie eine LLM-Antwort mit Python (boto3)
```
import boto3
import json
bedrock_runtime = boto3.client("bedrock-runtime", region_name="us-east-1")
response = bedrock_runtime.apply_guardrail(
guardrailIdentifier="your-guardrail-id",
guardrailVersion="1",
source="OUTPUT",
content=[
{
"text": {
"text": (
"User: Am I eligible for parental leave if I have been "
"working here for 2 years full-time?\n"
"Assistant: Yes, you are eligible for parental leave."
)
}
}
],
)
# The AR findings are in the assessments
for assessment in response.get("assessments", []):
ar_assessment = assessment.get("automatedReasoningPolicy", {})
findings = ar_assessment.get("findings", [])
for finding in findings:
# Each finding is a union — exactly one key is present
# Possible keys: valid, invalid, satisfiable, impossible,
# translationAmbiguous, tooComplex, noTranslations
print(json.dumps(finding, indent=2, default=str))
```
### Struktur der Antwort
Die `ApplyGuardrail` Antwort umfasst ein `assessments` Array. Jede Bewertung enthält ein `automatedReasoningPolicy` Objekt mit einem `findings` Array. Bei jedem Ergebnis handelt es sich um einen Kombinationstyp — genau einer der folgenden Schlüssel ist vorhanden:
+ `valid`
+ `invalid`
+ `satisfiable`
+ `impossible`
+ `translationAmbiguous`
+ `tooComplex`
+ `noTranslations`
Eine ausführliche Beschreibung der einzelnen Ergebnisarten und ihrer Felder finden Sie unter[Ergebnisse und Validierungsergebnisse](automated-reasoning-checks-concepts.md#ar-concept-findings).
## Interpretieren Sie AR-Ergebnisse zur Laufzeit
Um programmatisch auf die Ergebnisse von Automated Reasoning reagieren zu können, muss Ihre Anwendung den Befundtyp, die Übersetzungsdetails und die unterstützenden oder widersprüchlichen Regeln extrahieren. In den folgenden Abschnitten wird erklärt, wie die einzelnen Teile eines Ergebnisses analysiert werden.
### Ermitteln Sie den Befundtyp
Jeder Befund ist eine Vereinigung — genau ein Schlüssel ist vorhanden. Prüfen Sie, welcher Schlüssel existiert, um den Befundtyp zu bestimmen:
```
def get_finding_type(finding):
"""Return the finding type and its data from an AR finding union."""
for finding_type in [
"valid", "invalid", "satisfiable", "impossible",
"translationAmbiguous", "tooComplex", "noTranslations"
]:
if finding_type in finding:
return finding_type, finding[finding_type]
return None, None
```
### Lesen Sie die Übersetzung
Die meisten Befundtypen enthalten ein `translation` Objekt, das zeigt, wie automatische Argumentationsprüfungen die Eingabe in natürlicher Sprache in formale Logik übersetzt haben. Die Übersetzung enthält:
+ `premises`— Die aus der Eingabe extrahierten Bedingungen (z. B.`isFullTime = true`,`tenureMonths = 24`).
+ `claims`— Die zu validierenden Behauptungen (zum Beispiel`eligibleForParentalLeave = true`).
+ `untranslatedPremises`— Teile der Eingabe, die nicht den Richtlinienvariablen zugeordnet werden konnten. Diese Teile wurden nicht validiert.
+ `untranslatedClaims`— Behauptungen, die nicht politischen Variablen zugeordnet werden konnten.
Prüfen `untranslatedPremises` und `untranslatedClaims` verstehen Sie den Umfang der Validierung. Ein `VALID` Ergebnis deckt nur die übersetzten Ansprüche ab — unübersetzte Inhalte werden nicht verifiziert.
### Lesen Sie die unterstützenden oder widersprüchlichen Regeln
Je nach Art des Ergebnisses enthält das Ergebnis Regeln, die das Ergebnis erklären:
+ `valid`Zu den Ergebnissen gehören `supportingRules` — die Versicherungsregeln, die belegen, dass die Behauptungen korrekt sind.
+ `invalid`Zu den Ergebnissen gehören `contradictingRules` — die politischen Regeln, gegen die die Ansprüche verstoßen.
+ `satisfiable`Zu den Ergebnissen gehören `claimsTrueScenario` sowohl a als auch a `claimsFalseScenario` — es wird dargelegt, unter welchen Bedingungen die Behauptungen wahr und falsch sind.
Diese Regeln und Szenarien sind die wichtigsten Inputs für das unter beschriebene Umschreibmuster. [Schreiben Sie ungültige Antworten mithilfe von AR-Feedback um](#rewrite-invalid-responses)
### Ermitteln Sie das Gesamtergebnis
Eine einzelne Überprüfungsanfrage kann mehrere Ergebnisse zurückgeben. Um das Gesamtergebnis zu ermitteln, sortieren Sie die Ergebnisse nach Schweregrad und wählen Sie das schlechteste aus. Die Reihenfolge des Schweregrads vom schlechtesten zum besten lautet: `TRANSLATION_AMBIGUOUS``IMPOSSIBLE`,`INVALID`,,`SATISFIABLE`,`VALID`.
```
SEVERITY_ORDER = {
"tooComplex": 0,
"translationAmbiguous": 0,
"impossible": 1,
"invalid": 2,
"satisfiable": 3,
"valid": 4,
"noTranslations": 5,
}
def get_aggregate_result(findings):
"""Return the worst finding type from a list of findings."""
worst = None
worst_severity = float("inf")
for finding in findings:
finding_type, _ = get_finding_type(finding)
severity = SEVERITY_ORDER.get(finding_type, 0)
if severity < worst_severity:
worst_severity = severity
worst = finding_type
return worst
```
## Behandeln Sie die Validierungsergebnisse in Ihrer Anwendung
Verwenden Sie das Gesamtergebnis, um zu entscheiden, was Ihre Anwendung als Nächstes tun soll. In der folgenden Tabelle sind die empfohlenen Maßnahmen für jeden Ergebnistyp zusammengefasst.
| Ergebnis | Bedeutung | Empfohlene Aktion |
| --- | --- | --- |
| valid | Die Antwort ist mathematisch bewiesen, dass sie unter Berücksichtigung der Prämissen und Ihrer Versicherungsregeln korrekt ist. | Senden Sie die Antwort an den Benutzer weiter. Protokollieren Sie das Ergebnis zu Prüfungszwecken (siehe[Erstellen Sie einen Prüfpfad](#build-audit-trail)). |
| invalid | Die Antwort widerspricht Ihren Richtlinienregeln. Das contradictingRules Feld gibt an, gegen welche Regeln verstoßen wurde. | Schreiben Sie die Antwort mithilfe des AR-Feedbacks neu (siehe[Schreiben Sie ungültige Antworten mithilfe von AR-Feedback um](#rewrite-invalid-responses)). Wenn das Umschreiben nach mehreren Versuchen fehlschlägt, blockieren Sie die Antwort und geben Sie eine Fallback-Nachricht zurück. |
| satisfiable | Die Antwort ist unter einigen Bedingungen korrekt, aber nicht unter allen. Sie ist nicht falsch, aber sie ist unvollständig — sie erwähnt nicht alle Anforderungen. | Schreiben Sie die Antwort um, sodass sie die fehlenden Bedingungen enthält. Verwenden Sie dieclaimsFalseScenario, um zu ermitteln, was fehlt. Alternativ können Sie Ihr LLM dem Benutzer klärende Fragen stellen lassen. |
| impossible | Die Prämissen sind widersprüchlich oder die Richtlinie enthält widersprüchliche Regeln. | Bitten Sie den Benutzer, seine Eingabe zu erläutern (siehe). [Stellen Sie klärende Fragen](#ask-clarifying-questions) Wenn das Problem weiterhin besteht, deutet dies möglicherweise auf ein politisches Problem hin. Lesen Sie den Qualitätsbericht. |
| translationAmbiguous | Die Eingabe hat mehrere gültige Interpretationen. Die Übersetzungsmodelle waren sich nicht einig darüber, wie die natürliche Sprache politischen Variablen zugeordnet werden sollte. | Bitten Sie den Benutzer um Klarstellung, um die Unklarheit zu lösen. Verwenden Sie die differenceScenarios Felder options und, um gezielte Fragen zur Klärung zu stellen. |
| tooComplex | Die Eingabe überschreitet die Verarbeitungsgrenzen für logische Analysen. | Vereinfachen Sie die Eingabe, indem Sie sie in kleinere Teile aufteilen, oder geben Sie eine Ausweichmeldung zurück, in der erklärt wird, dass die Antwort nicht verifiziert werden konnte. |
| noTranslations | Die Eingabe ist für den Bereich Ihrer Richtlinie nicht relevant. Es konnten keine Richtlinienvariablen zugeordnet werden. | Der Inhalt dieser Richtlinie ist nicht zum Thema gehörend. Stellen Sie die Antwort ohne AR-Validierung bereit oder verwenden Sie andere Leitplankenkomponenten (z. B. Themenrichtlinien), um themenfremde Inhalte zu behandeln. |
## Schreiben Sie ungültige Antworten mithilfe von AR-Feedback um
Das leistungsstärkste Integrationsmuster für automatische Argumentationsprüfungen ist die *Umschreibschleife*: Wenn eine Antwort `invalid` oder lautet, erstellt Ihre Anwendung eine Aufforderung`satisfiable`, die die ursprüngliche Antwort, die spezifischen Ergebnisse und die Richtlinienregeln enthält, und fordert dann den LLM auf, die Antwort neu zu schreiben, damit sie mit der Richtlinie konsistent ist. Die umgeschriebene Antwort wird erneut validiert, und die Schleife wird fortgesetzt, bis die Antwort vorliegt `valid` oder eine maximale Anzahl von Iterationen erreicht ist.
### Der Schleifenfluss wird neu geschrieben
```
LLM generates initial response
│
▼
Validate with ApplyGuardrail ◄──────────────────┐
│ │
▼ │
┌─────┴─────┐ │
│ │ │
VALID Not VALID │
│ │ │
▼ ▼ │
Done Construct rewriting prompt │
with findings + rules │
│ │
▼ │
LLM rewrites response │
│ │
▼ │
Max iterations? ──── No ────────────────┘
│
Yes
│
▼
Return best response
with warning
```
### Konstruieren Sie die Aufforderung zum Umschreiben
Die Aufforderung zum Umschreiben sollte drei Informationen aus den AR-Ergebnissen enthalten:
1. Die ursprüngliche Antwort, bei der die Überprüfung fehlgeschlagen ist.
1. Das konkrete Ergebnis — einschließlich der übersetzten Prämissen, Behauptungen und der widersprüchlichen oder unterstützenden Regeln.
1. Eine Anweisung, die Antwort so umzuschreiben, dass sie den politischen Regeln entspricht.
**Beispiel für eine Vorlage für eine Aufforderung zum Umschreiben:**
```
The following response was checked against our policy and found to be
{finding_type}.
Original response:
{original_response}
The validation found the following issue:
- Premises (what was understood from the input): {premises}
- Claims (what was asserted): {claims}
- Contradicting rules: {contradicting_rules}
Please rewrite the response so that it is consistent with the policy document.
Keep the same helpful tone and answer the user's question
accurately based on the rules. If you cannot provide an accurate answer
without more information, explain what additional information is needed.
```
**Tipp**
Nehmen Sie den Inhalt von Retrieval Augmented Generation (RAG) immer in Ihre Umschreibanfragen oder die Richtlinienregeln auf, damit das LLM über den gesamten Kontext verfügt, den es beim Umschreiben benötigt. Die Vorlage für die Umschreibaufforderung enthält die spezifischen Ergebnisdetails, während die Systemaufforderung den umfassenderen politischen Kontext darstellt. Dieser Ansatz mit zwei Kontexten wird im Beispiel für einen [Open-Source-Chatbot zum Umschreiben](https://github.com/aws-samples/amazon-bedrock-samples/tree/main/responsible_ai/automated-reasoning-rewriting-chatbot) demonstriert.
### Bewährte Methoden zum Umschreiben
+ **Legen Sie eine maximale Anzahl von Iterationen fest.** Die Umschreibschleife sollte eine feste Grenze haben (normalerweise 2—5 Iterationen), um Endlosschleifen zu vermeiden. Wenn die Antwort immer noch nicht `valid` die maximale Anzahl von Iterationen erreicht hat, geben Sie die beste Antwort mit einer Warnung zurück oder greifen Sie auf eine Standardnachricht zurück.
+ **Verarbeiten Sie die Ergebnisse in der Reihenfolge ihrer Priorität.** Wenn mehrere Ergebnisse zurückgegeben werden, gehen Sie zuerst auf das schwerwiegendste Ergebnis ein. Die Reihenfolge des Schweregrads ist: `translationAmbiguous``impossible`,`invalid`,,`satisfiable`,`valid`.
+ **Nehmen Sie den Richtlinienkontext in die Systemaufforderung auf.** Das LLM benötigt entweder Zugriff auf das Quelldokument oder auf die vollständigen Richtlinienregeln, um es korrekt neu schreiben zu können. Sie können eine [Wissensdatenbank](https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html) verwenden, um Ihre Dokumente in die Generierungsanfrage aufzunehmen, oder die `ExportAutomatedReasoningPolicyVersion` API verwenden, um die Richtliniendefinition abzurufen und für das LLM zu formatieren.
+ **Protokollieren Sie jede Iteration.** Notieren Sie die ursprüngliche Antwort, die Ergebnisse, die Aufforderung zum Umschreiben und die neu geschriebene Antwort für jede Iteration. Dieser Prüfpfad ist nützlich für das Debuggen und die Einhaltung von Vorschriften (siehe). [Erstellen Sie einen Prüfpfad](#build-audit-trail)
## Stellen Sie klärende Fragen
Wenn Automated Reasoning `impossible` Ergebnisse oder Ergebnisse überprüft `translationAmbiguous``satisfiable`, verfügt das LLM möglicherweise nicht über genügend Informationen, um die Antwort korrekt neu zu formulieren. In diesen Fällen kann Ihre Anwendung den Benutzer um eine Klarstellung bitten und die Antworten dann in den nächsten Validierungsversuch einfließen lassen.
### Wann sollten Sie um eine Klarstellung bitten
+ **`translationAmbiguous`**— Die Eingabe hat mehrere gültige Interpretationen. Das `options` Feld zeigt die konkurrierenden Interpretationen, und das `differenceScenarios` Feld zeigt, wie sie sich in der Praxis unterscheiden. Verwenden Sie diese, um gezielte Fragen zur spezifischen Ambiguität zu stellen.
+ **`satisfiable`**— Die Antwort ist unter einigen Bedingungen korrekt, aber nicht unter allen. Das `claimsFalseScenario` zeigt die Bedingungen, unter denen die Antwort falsch wäre. Fragen Sie den Benutzer nach diesen spezifischen Bedingungen.
+ **`impossible`**— Die Eingabe enthält widersprüchliche Aussagen. Bitten Sie den Benutzer, den Widerspruch zu klären.
+ Das **Umschreiben schlägt fehl** — Wenn das LLM die Antwort nicht so umschreiben kann, dass sie `valid` nach mehreren Versuchen erscheint, benötigt es möglicherweise zusätzlichen Kontext vom Benutzer. Bitten Sie das LLM, auf der Grundlage der Ergebnisse klärende Fragen zu stellen.
### Muster der Klärung
Der Klärungsablauf funktioniert wie folgt:
1. Extrahieren Sie die mehrdeutigen Variablen oder fehlenden Bedingungen aus den AR-Ergebnissen.
1. Generieren Sie klärende Fragen — entweder programmatisch anhand der Ergebnisfelder oder indem Sie den LLM bitten, Fragen auf der Grundlage der Ergebnisse zu formulieren.
1. Präsentieren Sie die Fragen dem Benutzer und sammeln Sie Antworten.
1. Integrieren Sie die Antworten in den Kontext und generieren Sie eine neue Antwort.
1. Bestätigen Sie die neue Antwort mit`ApplyGuardrail`.
**Beispiel: Generieren Sie anhand eines Ergebnisses klärende `satisfiable` Fragen**
```
def generate_clarifying_questions(finding_data, user_question):
"""Ask the LLM to generate clarifying questions from a SATISFIABLE finding."""
claims_true = json.dumps(
finding_data.get("claimsTrueScenario", {}), indent=2, default=str
)
claims_false = json.dumps(
finding_data.get("claimsFalseScenario", {}), indent=2, default=str
)
prompt = (
f"A user asked: {user_question}\n\n"
f"The answer is correct when these conditions hold:\n{claims_true}\n\n"
f"But incorrect when these conditions hold:\n{claims_false}\n\n"
f"Generate 1-3 short, specific questions to ask the user to determine "
f"which conditions apply to their situation. Format each question on "
f"its own line."
)
return generate_response(prompt, "You are a helpful assistant.")
```
## Erstellen Sie einen Prüfpfad
Die Ergebnisse von Automated Reasoning liefern einen mathematisch überprüfbaren Validitätsnachweis. Für regulierte Branchen und Compliance-Szenarien ist dieser Nachweis ein wichtiges Unterscheidungsmerkmal. Sie können nachweisen, dass eine KI-Reaktion anhand bestimmter politischer Regeln mit spezifischen Variablenzuweisungen verifiziert und nicht nur anhand von Mustern oder Wahrscheinlichkeiten bewertet wurde.
Um einen effektiven Prüfpfad zu erstellen, protokollieren Sie die folgenden Informationen für jede Überprüfungsanfrage:
+ **Zeitstempel und Anfrage-ID.** Wann die Validierung stattgefunden hat und eine eindeutige Kennung für die Anfrage.
+ **Inhalt eingeben.** Die Benutzerfrage und die LLM-Antwort, die validiert wurden.
+ **Typ und Details werden gefunden.** Das Validierungsergebnis (`valid``invalid`, usw.), die übersetzten Prämissen und Behauptungen sowie die unterstützenden oder widersprüchlichen Regeln.
+ **Die ergriffenen Maßnahmen.** Was hat Ihre Bewerbung mit dem Ergebnis gemacht — die Antwort zugestellt, sie umgeschrieben, um Klarstellung gebeten oder sie blockiert.
+ **Verlauf neu schreiben.** Wenn die Antwort neu geschrieben wurde, protokollieren Sie jede Iteration: die ursprüngliche Antwort, die Aufforderung zum Umschreiben, die neu geschriebene Antwort und das Überprüfungsergebnis für jede Iteration.
+ **Version der Richtlinie.** Die Guardrail-Version und die Richtlinienversion, die für die Validierung verwendet wurden. Dadurch wird sichergestellt, dass Sie das Überprüfungsergebnis später reproduzieren können.
**Beispiel: Struktur der Audit-Logeinträge**
```
{
"timestamp": "2025-07-21T14:30:00Z",
"request_id": "req-abc123",
"guardrail_id": "your-guardrail-id",
"guardrail_version": "1",
"user_question": "Am I eligible for parental leave?",
"llm_response": "Yes, you are eligible for parental leave.",
"validation_result": "valid",
"findings": [
{
"type": "valid",
"premises": "isFullTime = true, tenureMonths = 24",
"claims": "eligibleForParentalLeave = true",
"supporting_rules": ["A1B2C3D4E5F6"]
}
],
"action_taken": "served_response",
"rewrite_iterations": 0
}
```
**Tipp**
Speichern Sie Auditprotokolle in einem dauerhaften, manipulationssicheren Speicher wie Amazon CloudWatch Logs oder Amazon S3 mit aktivierter Objektsperre. Für Compliance-Szenarien sollten Sie in Erwägung ziehen, Lake zur Abfrage von Auditprotokollen in Ihrem gesamten Unternehmen zu verwenden.