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.

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 unterAutomatisiertes Denken überprüft Konzepte. Anweisungen zur step-by-step Erstellung finden Sie unterErstellen der Automated-Reasoning-Richtlinie.

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.

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:

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

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.

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

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:

Beispiel: Vorher und nachher

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.

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 unterBenutzerdefinierte Typen (Aufzählungen).

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 lautettenureMonths, 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 zugewiesentenureMonths = 24.

Geben Sie immer an:

Beispiele:

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

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.

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:

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 beschriebenVerwenden Sie Implikationen (=>), um Regeln zu strukturieren, 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 undmonthsOfService), 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ückIMPOSSIBLE, 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.

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.