Testen einer Automated-Reasoning-Richtlinie - Amazon Bedrock
Teststrategie: Szenarien im Vergleich zu QnA-TestsGenerieren Sie Testszenarien automatisch in der KonsoleGenerieren Sie mithilfe der API automatisch TestszenarienErstellen Sie einen QnA-Test manuell in der KonsoleErstellen Sie mithilfe der API einen QnA-TestTests ausführenVerstehen Sie die Testergebnisse

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.

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 oderINVALID).

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.

  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.

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

  3. Führen Sie alle Tests aus. Stellen Sie sicher, dass sowohl die Szenarien als auch die QnA-Tests erfolgreich sind.

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

Generieren Sie Testszenarien automatisch in der Konsole

  1. Gehen Sie zu der Automated Reasoning-Richtlinie, die Sie testen möchten (z. B. MyHrPolicy).

  2. Wählen Sie Tests anzeigen und anschließend Generieren aus.

  3. Ü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.

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

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

  6. 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).

  2. Wählen Sie Tests anzeigen und anschließend Hinzufügen aus.

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

    2. Wählen Sie das Ergebnis aus, das Sie vom Test erwarten (z. B. Gültig oder Ungültig).

    3. (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

  4. 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 oderINVALID). 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_AMBIGUOUSIMPOSSIBLE,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).

  2. Wählen Sie Tests anzeigen aus.

  3. 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 unterErgebnisse und Validierungsergebnisse.

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_AMBIGUOUSIMPOSSIBLE,INVALID,,SATISFIABLE,VALID. Ein Test mit zwei VALID Ergebnissen und einem IMPOSSIBLE Ergebnis hat beispielsweise ein aggregiertes Ergebnis vonIMPOSSIBLE.

  • 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 unterReferenz zu den Validierungsergebnissen.

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.
TRANSLATION_AMBIGUOUS 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.
TOO_COMPLEX 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_TRANSLATIONS 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 wurdetenureMonths = 24, muss in der Variablenbeschreibung die Umrechnung der Einheiten angegeben werden.

  2. Ü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.

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

  4. Ü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 unterBeheben Sie Fehler und verfeinern Sie Ihre Richtlinie für automatisiertes Denken.