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 prüft Konzepte
Auf dieser Seite werden die Bausteine von Automated Reasoning-Prüfungen beschrieben. Wenn Sie diese Konzepte verstehen, können Sie effektive Richtlinien erstellen, Testergebnisse interpretieren und Probleme debuggen. Einen allgemeinen Überblick darüber, was Automated Reasoning-Prüfungen bewirken und wann sie eingesetzt werden sollten, finden Sie unterRegeln.
Richtlinien
Eine Automated Reasoning-Richtlinie 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, extrahiert die automatische Argumentationsprüfung die Regeln und Variablen aus Ihrem Dokument und übersetzt sie in formale Logik, die mathematisch überprüft 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
DRAFTVersion (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. -
Ein Leitplanken kann auf die DRAFT-Richtlinie oder eine bestimmte nummerierte Version verweisen. Wenn Sie eine nummerierte Version verwenden, können Sie die aktualisieren,
DRAFTohne dass sich dies auf Ihre verwendete Leitplanke auswirkt. -
Jede Police sollte sich auf einen bestimmten Bereich konzentrieren (z. B. Personalleistungen, Kreditwürdigkeit, Produktrückgabebestimmungen) und nicht versuchen, mehrere Bereiche abzudecken, die nichts miteinander zu tun haben.
Eine schrittweise Anleitung zum Erstellen einer Richtlinie finden Sie unter. Erstellen der Automated-Reasoning-Richtlinie
Bericht von Fidelity
Ein Treuebericht misst, wie genau eine extrahierte Richtlinie die Quelldokumente darstellt, aus denen sie generiert wurde. Der Bericht wird automatisch generiert, wenn Sie eine Richtlinie aus einem Quelldokument erstellen. Er enthält zwei wichtige Ergebnisse sowie detaillierte Basisinformationen, die jede Regel und Variable mit bestimmten Aussagen in Ihrem Quellinhalt verknüpfen.
Der Fidelity-Bericht soll Fachexperten ohne technischen Hintergrund 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 Treuebericht als Tabelle mit nummerierten atomaren Aussagen angezeigt, die aus Ihrem Dokument extrahiert wurden. Sie zeigt, welche Regeln und Variablen die einzelnen Aussagen begründen. Sie können nach bestimmten Regeln oder Variablen filtern und nach Inhalten in den Aussagen suchen.
Der Treuebericht enthält zwei Werte, die jeweils im Bereich von 0,0 bis 1,0 liegen:
-
Deckungsgrad — Gibt an, wie gut die Police die Aussagen in den Quelldokumenten abdeckt. Ein höherer Punktewert bedeutet, dass ein größerer Teil des Quellinhalts in der Police enthalten ist.
-
Genauigkeitsbewertung — Gibt an, wie originalgetreu die Richtlinienregeln das Quellmaterial wiedergeben. Ein höherer Punktewert bedeutet, dass die extrahierten Regeln der Absicht des Originaldokuments besser entsprechen.
Neben den Gesamtwerten bietet der Treuebericht eine detaillierte Grundlage für jede Regel und Variable in der Richtlinie:
-
Regelberichte — Der Bericht identifiziert für jede Regel die spezifischen Aussagen aus den Quelldokumenten, die sie stützen (Grundaussagen), erklärt, wie diese Aussagen die Regel rechtfertigen (begründende Begrü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 gibt eine individuelle Genauigkeitsbewertung.
-
Dokumentquellen — Die Quelldokumente sind in atomare Aussagen unterteilt — einzelne, unteilbare Fakten, die aus dem Text extrahiert wurden. Der Dokumentinhalt ist mit Zeilennummern versehen, sodass Sie jede Regel und Variable bis zur genauen Stelle im Originaldokument zurückverfolgen können.
Regeln
Regeln sind das Herzstück einer Automated Reasoning-Richtlinie. Jede Regel ist ein formaler logischer Ausdruck, der eine Beziehung zwischen Variablen erfasst. Regeln werden mithilfe einer Teilmenge der SMT-LIB
Die meisten Regeln sollten einem (impliziten) Wenn-Dann-Format 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. =>
Well-formed 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 Kontosalden mit positiven Werten zu überprüfen, kann aber auch dazu führen, dass bestimmte Bedingungen logisch unmöglich sind und bei der Validierung zu unerwarteten IMPOSSIBLE Ergebnissen führen. Zum Beispiel (= eligibleForParentalLeave true) bedeutet die bloße Aussage, dass automatische Argumentationsprüfungen es so behandeln, als ob der Nutzer Anspruch auf Elternzeit hat. Jede Eingabe, in der erwähnt wird, dass er nicht berechtigt ist, würde zu einem Validierungsergebnis führenIMPOSSIBLE, da 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 Ihrem Fachgebiet dar, die bei Prüfungen mit automatisiertem Denken verwendet werden, um natürliche Sprache in formale Logik zu übersetzen und Regeln zu evaluieren. 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 |
NUMBER |
Dezimalzahl | interestRate— Jährlicher Zinssatz als Dezimalzahl (0,05 bedeutet 5%) |
| Benutzerdefinierter Typ (Enum) | Ein Wert aus einem definierten Satz | leaveType— Eins von: ELTERLICH, MEDIZINISCH, TRAUERFALL, PERSÖNLICH |
Warnung
Modellieren Sie Ihre Domain nur mit den Variablentypen in der vorherigen Tabelle. Vermeiden Sie es, eine Richtlinie zu entwerfen, die von nicht unterstützten Daten — wie unformatierten Zeichenketten oder Freiformtext — abhängt oder bei der der Übersetzungsschritt zur Berechnung oder Interpretation eines Werts erforderlich ist. Versuchen Sie, die Komplexität der Übersetzung zu minimieren.
Automatisierte Argumentationsprüfungen dienen der Interpretation natürlicher Sprache und sind nicht auf alle Arten der Überprüfung anwendbar. So lässt sich beispielsweise die Überprüfung, ob ein Passwort eine Reihe von Anforderungen erfüllt, besser mit deterministischem, regelbasiertem Code bewerkstelligen, da es darauf ankommt, den Rohwert Zeichen für Zeichen auszuwerten und nicht auf Argumentation statt natürlicher Sprache.
Anmerkung
Innerhalb einer Richtliniendefinition teilen sich Variablennamen, benutzerdefinierte Typnamen und die in benutzerdefinierten Typen definierten Werte einen einzigen Namespace. Jeder dieser Namen muss in allen drei Kategorien eindeutig sein. Sie können nicht denselben Namen für eine Variable und einen Typ verwenden, und derselbe Wert kann nicht in mehr als einem benutzerdefinierten Typ vorkommen. Wenn beispielsweise ein LeaveType Typ einen OTHER Wert definiert, kann kein anderer Typ (wieSeverity) diesen Wert ebenfalls definierenOTHER, und es kann keine Variable benannt werdenOTHER. Wenn Sie einen ähnlichen Wert in mehr als einem Typ benötigen, stellen Sie ihm den Typnamen voran, damit jeder Name eindeutig bleibt und gleichzeitig seine Bedeutung erhalten bleibt — zum Beispiel LeaveType_OTHER undSeverity_OTHER.
Die entscheidende Rolle von Variablenbeschreibungen
Variablenbeschreibungen sind der wichtigste Faktor für die Übersetzungsgenauigkeit. Wenn Automated Reasoning die Übersetzung natürlicher Sprache in formale Logik durchführt, wird anhand von Variablenbeschreibungen ermittelt, welche Variablen den im Text genannten 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 einen Benutzer vor, der fragt: „Ich arbeite seit 2 Jahren hier. Habe ich Anspruch auf Elternzeit?“
| Vage Beschreibung (wird wahrscheinlich scheitern) | Detaillierte Beschreibung (wird wahrscheinlich erfolgreich sein) |
|---|---|
tenureMonths: „Wie lange hat der Mitarbeiter gearbeitet.“ |
tenureMonths: „Die Anzahl der vollständigen Monate, in denen der Mitarbeiter ununterbrochen angestellt war. Wenn Benutzer Dienstjahre angeben, rechnen Sie das in Monate um (z. B. 2 Jahre = 24 Monate). Setzen Sie den Wert für Neueinstellungen auf 0.“ |
Aufgrund der vagen Beschreibung wissen Automated Reasoning Checks möglicherweise nicht, ob „2 Jahre“ in 24 Monate umgerechnet werden sollen, oder sie weisen die Variable gar nicht zu. Mit der detaillierten Beschreibung ist die Übersetzung eindeutig.
Gute Variablenbeschreibungen sollten:
-
Erklären Sie im Klartext, was die Variable darstellt.
-
Geben Sie die Einheit und das Format an (z. B. „in Monaten“, „als Dezimalzahl, wobei 0,15 15% bedeutet“).
-
Fügen Sie nicht offensichtliche Synonyme und alternative Formulierungen hinzu, die Benutzer verwenden könnten (z. B. „Auf wahr setzen, wenn Benutzer angeben, dass sie „Vollzeit“ sind oder volle Stunden 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 einer festen Menge möglicher Werte darstellt.
Beispiele:
| Geben Sie einen Namen ein | Mögliche Werte | Anwendungsfall |
|---|---|---|
LeaveType |
ELTERLICH, MEDIZINISCH, TRAUERND, PERSÖNLICH | Kategorisieren Sie die Art des Urlaubs, den ein Mitarbeiter beantragt |
Severity |
KRITISCH, SCHWERWIEGEND, NEBENBEI | Klassifizieren Sie den Schweregrad eines Problems oder Vorfalls |
Wann sollten Enums im Vergleich zu Booleans verwendet werden:
-
Verwenden Sie Enumerationen, wenn sich die Werte gegenseitig ausschließen — eine Variable kann jeweils nur einen Wert haben.
leaveTypeSie 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 die Wahl zwischen ihnen erzwingen, was zu einem logischen Widerspruch führen würde, wenn beide zutreffen. Verwenden Sie stattdessen zwei boolesche Werte: und.isVeteranisTeacher
Tipp
Wenn es möglich ist, dass eine Variable keinen Wert aus der Enumeration hat, fügen Sie einen OR-Wert einOTHER. 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 Richtlinien mathematisch verifiziert werden können. Das Verständnis dieses Prozesses ist der Schlüssel zum Debuggen von Problemen und zur Erstellung effektiver Richtlinien.
Automatisierte Reasoning-Checks validieren Inhalte in zwei unterschiedlichen Schritten:
-
Übersetzen — Automatisierte Argumentationsprüfungen verwenden Fundamentmodelle (LLMs), um die Eingabe natürlicher Sprache in formale Logik zu übersetzen. In diesem Schritt werden die Konzepte im Text den Variablen Ihrer Richtlinie zugeordnet und die Beziehungen als logische Aussagen ausgedrückt. Da in diesem Schritt LLMs verwendet werden, kann er Fehler enthalten. Bei automatisierten Reasoning-Checks werden mehrere LLMs verwendet, um den Eingabetext zu übersetzen. Anschließend wird anhand der semantischen Äquivalenz der redundanten Übersetzungen ein Konfidenzwert festgelegt. Die Qualität der Übersetzung hängt davon ab, wie gut Ihre Variablenbeschreibungen mit der in der Eingabe verwendeten Sprache übereinstimmen.
-
Validieren — Automatisierte Reasoning-Checks 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 zweistufige Unterscheidung ist für das Debuggen von entscheidender Bedeutung. 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 fundiert, und wenn die Übersetzung die Bedeutung der Eingabe korrekt wiedergibt, ist das Validierungsergebnis korrekt. Konzentrieren Sie sich beim Debuggen darauf, die Variablenbeschreibungen zu verbessern und sicherzustellen, dass bei der Übersetzung die richtigen Variablen mit den richtigen Werten zugewiesen werden.
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 (Validierung) vergleicht diese Zuweisungen mit der Versicherungsregel (=> (and isFullTime (> tenureMonths 12)) eligibleForParentalLeave) und bestätigt, dass der Anspruch erfüllt istVALID.
Um die Genauigkeit der Übersetzung zu verbessern:
-
Schreiben Sie detaillierte Variablenbeschreibungen, die beschreiben, wie Benutzer Begriffe in der Alltagssprache betrachten.
-
Entfernen Sie doppelte oder fast doppelte Variablen, die die Übersetzung verwirren könnten (z. B.
tenureMonthsund).monthsOfService -
Löschen Sie unbenutzte Variablen, auf die keine Regeln verweisen — sie machen den Übersetzungsprozess unnötig unnötig.
-
Verwenden Sie Frage-Antwort-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 Automated Reasoning den Inhalt überprüft, wird eine Reihe von Ergebnissen generiert. Jedes Ergebnis stellt eine tatsächliche Behauptung dar, die aus der Eingabe extrahiert wurde, zusammen mit dem Validierungsergebnis, den verwendeten Variablenzuweisungen und den politischen Regeln, die die Schlussfolgerung stützen. Das (aggregierte) Gesamtergebnis wird bestimmt, indem die Ergebnisse in der Reihenfolge ihres Schweregrads sortiert und das schlechteste Ergebnis ausgewählt wird. Die Reihenfolge des Schweregrads vom schlechtesten zum besten ist:TRANSLATION_AMBIGUOUS,IMPOSSIBLE,INVALID,SATISFIABLE,VALID.
Struktur eines Befundes
Der Ergebnistyp bestimmt, welche Felder im Ergebnis enthalten sind. Im Referenz zu den Ergebnissen der Validierung Abschnitt finden Sie eine ausführliche Beschreibung der einzelnen Befundtypen. Die meisten Suchtypen haben jedoch ein gemeinsames translation Objekt, das die folgenden Komponenten enthält:
premises-
Kontext, Annahmen oder Bedingungen, die aus den Eingaben abgeleitet wurden und beeinflussen, wie ein Anspruch bewertet werden sollte. Bei Frage-und-Antwort-Formaten ist die Prämisse oft die Frage selbst. Antworten können auch Prämissen enthalten, die Einschränkungen begründen. Beispiel: In „Ich bin ein Vollzeitangestellter mit einer Betriebszugehörigkeit von 18 Monaten“ lauten die Prämissen wie folgt:
isFullTime = trueundtenureMonths = 18. claims-
Tatsachenaussagen, die von Automated Reasoning auf ihre Richtigkeit hin überprüft werden. In einem Frage-und-Antwort-Format ist die Behauptung in der Regel die Antwort. In „Ja, Sie haben Anspruch auf Elternzeit“ lautet der Anspruch beispielsweise.
eligibleForParentalLeave = true confidence-
Ein Wert zwischen 0,0 und 1,0, der angibt, wie bei bestimmten Automated Reasoning die Übersetzung von natürlicher Sprache in formale Logik überprüft wird. 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 Eingabetextes, die Prämissen entsprechen, aber nicht in formale Logik übersetzt werden konnten. Diese heben Teile der Eingabe hervor, die Automated Reasoning als relevant erkannte, 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
VALIDErgebnis bezieht sich nur auf die übersetzten Ansprüche — unübersetzte Ansprüche werden nicht validiert.
Referenz zu den Ergebnissen der Validierung
Bei jedem Ergebnis handelt es sich um genau einen 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 Ergebnistypen, die ein translation Feld enthalten, enthalten auch ein logicWarning Feld, das vorhanden ist, wenn die Übersetzung unabhängig von den Richtlinienregeln logische Probleme enthält (z. B. Aussagen, die immer wahr oder immer falsch sind).
| Ergebnis | Nach Feldern suchen | Empfohlene Aktion |
|---|---|---|
VALID |
|
Stellen Sie die Antwort dem Benutzer zur Verfügung. Protokoll supportingRules - und claimsTrueScenario Prüfungszwecke — sie liefern einen mathematisch überprüfbaren Gültigkeitsnachweis. Suchen Sie untranslatedPremises untranslatedClaims nach Teilen der Eingabe, die nicht validiert wurden. |
INVALID |
|
Übermitteln Sie die Antwort nicht. 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 Umschreibschleife die widersprüchlichen Regeln und falschen Behauptungen an das LLM, um eine korrigierte Antwort zu generieren. |
SATISFIABLE |
|
Vergleiche claimsTrueScenario und claimsFalseScenario identifiziere die fehlenden Bedingungen. Schreiben Sie die Antwort so um, dass sie die zusätzlichen Informationen enthält, die für die Erstellung erforderlich sindVALID, bitten Sie den Benutzer um eine Klarstellung der fehlenden Bedingungen oder stellen Sie die Antwort mit dem Vorbehalt vor, dass sie möglicherweise unvollständig ist. |
IMPOSSIBLE |
|
Prüfen Sie, ob die Eingabe widersprüchliche Aussagen enthält (z. B. „Ich bin Vollzeit und auch Teilzeit“). Wenn die Eingabe gültig ist, liegt der Widerspruch wahrscheinlich in Ihrer Police — überprüfen Sie den Qualitätsbericht contradictingRules und überprüfen Sie ihn. Siehe Beheben Sie Fehler und verfeinern Sie Ihre Richtlinie für automatisiertes Denken. |
TRANSLATION_AMBIGUOUS |
Enthält kein
|
Untersuchen Sieoptions, um die Meinungsverschiedenheit zu verstehen. Verbessern Sie die Variablenbeschreibungen, um Mehrdeutigkeiten zu reduzieren, 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. Schwellenwerte für das Vertrauen |
TOO_COMPLEX |
Enthält keine |
Verkürzen Sie die Eingabe, indem Sie sie in kleinere Teile aufteilen, oder vereinfachen Sie die Politik, indem Sie die Anzahl der Variablen reduzieren und komplexe Arithmetik vermeiden (z. B. Exponenten oder irrationale Zahlen). Sie können Ihre Richtlinie in kleinere, zielgerichtetere Richtlinien aufteilen. |
NO_TRANSLATIONS |
Enthält keine |
Ein NO_TRANSLATIONS Ergebnis wird in das Output aufgenommen, wenn eines der anderen Ergebnisse noch nicht übersetzte Prämissen oder Behauptungen beinhaltet. Sehen Sie sich die anderen Ergebnisse an, um zu sehen, 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 erwägen, ihn mithilfe von Themenrichtlinien zu filtern, bevor er in die automatische Argumentationsprüfung aufgenommen wird. |
Anmerkung
Ein VALID Ergebnis deckt nur die Teile des Inputs ab, die anhand der politischen Variablen in den übersetzten Prämissen und Behauptungen erfasst wurden. Aussagen, die nicht in den Geltungsbereich der Variablen Ihrer Richtlinie 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 Police keine Variable enthält, anhand derer erfasst werden kann, ob das Attest gefälscht ist. Automatisierte Begründungsprüfungen werden bei der Feststellung wahrscheinlich auch den Hinweis „falsches ärztliches Attest“ als unübersetzte Prämisse mit einbeziehen. Behandeln Sie unübersetzte Inhalte und NO_TRANSLATIONS Ergebnisse als Warnsignal.
Schwellenwerte für das Vertrauen
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. Liefert weniger Ergebnisse, aber mit höherer Genauigkeit. Weitere Eingaben werden als
TRANSLATION_AMBIGUOUSgekennzeichnet. -
Unterer Schwellenwert (z. B. 0,5): Akzeptiert Übersetzungen mit geringerer Übereinstimmung. Liefert mehr Ergebnisse, aber mit einem höheren Risiko falscher Übersetzungen. Weniger Eingaben werden als
TRANSLATION_AMBIGUOUSgekennzeichnet.
So funktioniert der Schwellenwert:
-
Mehrere Basismodelle übersetzen die Eingabe jeweils unabhängig voneinander.
-
Ü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.). -
Wenn eine oder mehrere Übersetzungen unter den Schwellenwert fallen, ergeben automatische Reasoning-Überprüfungen ein zusätzliches
TRANSLATION_AMBIGUOUSErgebnis. 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 auf der Grundlage 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.
