Automatisiertes Denken überprüft Konzepte - Amazon Bedrock
RichtlinienFidelity-BerichtRegelnVariablenBenutzerdefinierte Typen (Aufzählungen)Übersetzung: von der natürlichen Sprache zur formalen LogikErgebnisse und ValidierungsergebnisseVertrauensschwellen

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.

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

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

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

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_TIME)
>, <, >=, <= Vergleich (>= creditScore 700)

Bewährte Methoden zum Schreiben effektiver Regeln finden Sie unterBewährte Methoden für Richtlinien zur automatisierten Argumentation.

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

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

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.

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 ValidierungsergebnissenIn 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 undtenureMonths = 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 beispielsweiseeligibleForParentalLeave = 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.
TRANSLATION_AMBIGUOUS

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
TOO_COMPLEX

Enthält keine Atranslation, 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_TRANSLATIONS

Enthält keine Atranslation, Regeln oder Szenarien. Kann zusammen mit anderen Ergebnissen erscheinen, wenn nur ein Teil der Eingaben übersetzt werden könnte.

 Ein NO_TRANSLATIONS 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.

  2. Ü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 (VALIDINVALID, usw.).

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