Il ragionamento automatico verifica i concetti

Questa pagina descrive gli elementi costitutivi dei controlli di ragionamento automatico. La comprensione di questi concetti ti aiuterà a creare politiche efficaci, interpretare i risultati dei test ed eseguire il debug dei problemi. Per una panoramica di alto livello su cosa fanno i controlli di ragionamento automatico e quando utilizzarli, consulta. Regole

Policy

Una policy di Automated Reasoning è una risorsa nel tuo account AWS che contiene un set di regole logiche formali, uno schema di variabili e tipi personalizzati opzionali. La policy codifica le regole, i regolamenti o le linee guida aziendali in base ai quali desideri convalidare le risposte LLM.

Le policy vengono create a partire da documenti di origine, come manuali sulle risorse umane, manuali di conformità o specifiche di prodotto, che descrivono le regole in linguaggio naturale. Quando si crea una policy, i controlli di ragionamento automatico estraggono le regole e le variabili dal documento e le traducono in una logica formale che può essere verificata matematicamente.

La relazione tra policy, guardrail e applicazione è la seguente:

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)
    

Caratteristiche chiave delle politiche:

• Ogni policy è identificata da un Amazon Resource Name (ARN) ed esiste in una regione AWS specifica.

• Le policy hanno una DRAFT versione (chiamata «Working Draft» nella console) che puoi modificare durante lo sviluppo e versioni immutabili numerate che crei per la distribuzione.

• Un guardrail può fare riferimento alla policy DRAFT o a una specifica versione numerata. L'utilizzo di una versione numerata significa che è possibile aggiornarlo DRAFT senza influire sul guardrail utilizzato.

• Ogni polizza dovrebbe concentrarsi su un dominio specifico (ad esempio, vantaggi in materia di risorse umane, idoneità al prestito, regole sulla restituzione dei prodotti) anziché cercare di coprire più aree non correlate.

Per istruzioni dettagliate sulla creazione di una polizza, consulta. Creare una policy di ragionamento automatico

Rapporto Fidelity

Un rapporto di fedeltà misura l'accuratezza con cui una politica estratta rappresenta i documenti di origine da cui è stata generata. Il report viene generato automaticamente quando si crea una politica da un documento di origine. Fornisce due punteggi chiave insieme a informazioni di base dettagliate che collegano ogni regola e variabile a dichiarazioni specifiche nel contenuto di origine.

Il rapporto di fedeltà è progettato per aiutare gli esperti in materia non tecnica a esplorare e convalidare una politica senza dover comprendere la logica formale. Nella console, la scheda Documento sorgente mostra il rapporto di fedeltà sotto forma di una tabella di dichiarazioni atomiche numerate estratte dal documento, che mostra le regole e le variabili basate su ciascuna dichiarazione. È possibile filtrare in base a regole o variabili specifiche e cercare il contenuto all'interno delle dichiarazioni.

Il rapporto di fedeltà include due punteggi, ciascuno compreso tra 0,0 e 1,0:

• Punteggio di copertura: indica in che misura la politica copre le dichiarazioni contenute nei documenti di origine. Un punteggio più alto indica che una parte maggiore del contenuto di origine è rappresentata nella politica.

• Punteggio di precisione: indica quanto fedelmente le regole delle policy rappresentano il materiale di origine. Un punteggio più alto indica che le regole estratte corrispondono maggiormente all'intento del documento originale.

Oltre ai punteggi aggregati, il rapporto di fedeltà fornisce una base dettagliata per ogni regola e variabile della politica:

• Rapporti sulle regole: per ogni regola, il rapporto identifica le dichiarazioni specifiche tratte dai documenti di origine che la supportano (dichiarazioni di base), spiega in che modo tali affermazioni giustificano la regola (giustificazioni fondamentali) e fornisce un punteggio di precisione individuale con una giustificazione.

• Rapporti sulle variabili: per ogni variabile, il rapporto identifica le dichiarazioni di origine che supportano la definizione della variabile, spiega la giustificazione e fornisce un punteggio di precisione individuale.

• Fonti dei documenti: i documenti di origine sono suddivisi in dichiarazioni atomiche, fatti individuali e indivisibili estratti dal testo. Il contenuto del documento è annotato con numeri di riga in modo da poter far risalire ogni regola e variabile alla posizione esatta nel documento originale.

Regole

Le regole sono il fulcro di una politica di ragionamento automatico. Ogni regola è un'espressione logica formale che cattura una relazione tra variabili. Le regole sono espresse utilizzando un sottoinsieme di SMT-LIB sintassi, un formato standard per la logica formale che i controlli del ragionamento automatico utilizzano per la verifica matematica. Per informazioni, consultare Autorizzazioni KMS per le policy di ragionamento automatico.

La maggior parte delle regole dovrebbe seguire un formato if-then (implicativo). Ciò significa che le regole dovrebbero avere una condizione (la parte «se») e una conclusione (la parte «allora»), collegate dall'operatore di implicazione. =>

Well-formed regole (formato if-then):

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

Le semplici asserzioni (regole senza una struttura if-then) creano assiomi, affermazioni che sono sempre vere. Ciò è utile per verificare condizioni limite, ad esempio i saldi dei conti con valori positivi, ma può anche rendere logicamente impossibili determinate condizioni e portare a IMPOSSIBLE risultati imprevisti durante la convalida. Ad esempio, la semplice affermazione (= eligibleForParentalLeave true) significa che i controlli di ragionamento automatico considerano l'utente come un dato di fatto che l'utente ha diritto al congedo parentale. Qualsiasi input che indichi la non idoneità produrrebbe un risultato di convalida IMPOSSIBLE perché contraddice questo assioma.

;; GOOD: Useful to check impossible conditions such as 
;; negative account balance
(>= accountBalance 0)

;; BAD: This asserts eligibility as always true, regardless of conditions.
eligibleForParentalLeave

Le regole supportano i seguenti operatori logici:

Operatore	Significato	Esempio
=>	Implicazione (if-then)	(=> isFullTime eligibleForBenefits)
and	AND logico	(and isFullTime (> tenure 12))
or	OR logico	(or isVeteran isTeacher)
not	NOT logico	(not isTerminated)
=	Parità	(= employmentType FULL_TIME)
>, <, >=, <=	Confronto	(>= creditScore 700)

Per le migliori pratiche sulla stesura di regole efficaci, vedereLe migliori pratiche relative alla politica di ragionamento automatizzato.

Variabili

Le variabili rappresentano i concetti del tuo dominio che i controlli di ragionamento automatico utilizzano per tradurre il linguaggio naturale in logica formale e valutare le regole. Ogni variabile ha un nome, un tipo e una descrizione.

I controlli di ragionamento automatico supportano i seguenti tipi di variabili:

Tipo	Description	Esempio
BOOL	Valore true o false	isFullTime— Se il dipendente lavora a tempo pieno
INT	Numero intero	tenureMonths— Numero di mesi in cui il dipendente ha lavorato
NUMBER	Numero decimale	interestRate— Tasso di interesse annuo espresso in decimali (0,05 significa 5%)
Tipo personalizzato (enum)	Un valore da un set definito	leaveType— Uno tra: PARENTALE, MEDICO, LUTTO, PERSONALE

avvertimento

Modella il tuo dominio utilizzando solo i tipi di variabili nella tabella precedente. Evita di progettare una policy che dipenda da dati non supportati, come stringhe non elaborate o testo in formato libero, o che richieda la fase di traduzione per calcolare o interpretare un valore. Cerca di ridurre al minimo la complessità della traduzione.

I controlli di ragionamento automatico sono progettati per interpretare il linguaggio naturale e non sono applicabili a tutte le forme di verifica. Ad esempio, la convalida che una password soddisfi una serie di requisiti è gestita meglio da un codice deterministico basato su regole, poiché dipende dalla valutazione del valore grezzo carattere per carattere piuttosto che dal ragionamento in base al linguaggio naturale.

Nota

All'interno di una definizione di policy, i nomi delle variabili, i nomi dei tipi personalizzati e i valori definiti all'interno dei tipi personalizzati condividono tutti un unico namespace. Ognuno di questi nomi deve essere univoco in tutte e tre le categorie. Non è possibile utilizzare lo stesso nome per una variabile e un tipo e lo stesso valore non può apparire in più di un tipo personalizzato. Ad esempio, se un LeaveType tipo definisce un OTHER valore, nessun altro tipo (ad esempioSeverity) può definirlo OTHER e nessuna variabile può essere denominataOTHER. Quando è necessario un valore simile in più di un tipo, aggiungete il prefisso del nome del tipo per mantenere ogni nome univoco preservandone il significato, LeaveType_OTHER ad esempio e. Severity_OTHER

Il ruolo fondamentale delle descrizioni delle variabili

Le descrizioni delle variabili sono il fattore più importante per l'accuratezza della traduzione. Quando i controlli di ragionamento automatico traducono il linguaggio naturale in logica formale, utilizzano le descrizioni delle variabili per determinare quali variabili corrispondono ai concetti menzionati nel testo. Descrizioni vaghe o incomplete portano a TRANSLATION_AMBIGUOUS risultati o assegnazioni di variabili errate.

Esempio: in che modo le descrizioni influiscono sulla traduzione

Considerate un utente che chiede: «Lavoro qui da 2 anni. Ho diritto al congedo parentale?»

Descrizione vaga (probabilmente fallirà)	Descrizione dettagliata (probabile esito positivo)
tenureMonths: «Da quanto tempo lavora il dipendente».	tenureMonths: «Il numero di mesi completi in cui il dipendente è stato impiegato ininterrottamente. Quando gli utenti menzionano anni di servizio, convertiteli in mesi (ad esempio, 2 anni = 24 mesi). Impostato su 0 per i nuovi assunti.»

Con una descrizione vaga, i controlli di ragionamento automatico potrebbero non essere in grado di convertire «2 anni» in 24 mesi o potrebbero non assegnare affatto la variabile. Con la descrizione dettagliata, la traduzione è inequivocabile.

Una buona descrizione delle variabili dovrebbe:

• Spiega cosa rappresenta la variabile in un linguaggio semplice.

• Specifica l'unità e il formato (ad esempio, «in mesi», «come decimale dove 0,15 significa 15% «).

• Includi sinonimi non ovvi e frasi alternative che gli utenti potrebbero utilizzare (ad esempio, «Imposta su true quando gli utenti dicono di essere «a tempo pieno» o di lavorare a tempo pieno»).

• Descrivi le condizioni limite (ad esempio, «Imposta a 0 per i nuovi assunti»).

Tipi personalizzati (enumerazioni)

I tipi personalizzati definiscono un insieme di valori denominati che una variabile può assumere. Sono equivalenti alle enumerazioni (enumerazioni) nei linguaggi di programmazione. Usa tipi personalizzati quando una variabile rappresenta una categoria con un insieme fisso di valori possibili.

Esempi:

Nome del tipo	Valori possibili	Caso d’uso
LeaveType	PARENTALE, MEDICO, IN CASO DI LUTTO, PERSONALE	Classifica il tipo di congedo richiesto da un dipendente
Severity	CRITICO, MAGGIORE, MINORE	Classificare la gravità di un problema o incidente

Quando usare le enumerazioni rispetto ai booleani:

• Usa le enumerazioni quando i valori si escludono a vicenda: una variabile può essere solo un valore alla volta. Ad esempio, leaveType può essere PARENTAL o MEDICAL, ma non entrambi contemporaneamente.

• Utilizzate variabili booleane separate quando gli stati possono coesistere. Ad esempio, una persona può essere sia un veterano che un insegnante. L'uso di un enum customerType = {VETERAN, TEACHER} forzerebbe una scelta tra di loro, creando una contraddizione logica quando entrambi si applicano. Usa invece due booleani: e. isVeteran isTeacher

Suggerimento

Se è possibile che una variabile non abbia alcun valore dall'enum, includi un OTHER valore or. NONE Ciò previene problemi di traduzione quando l'input non corrisponde a nessuno dei valori definiti.

Traduzione: dal linguaggio naturale alla logica formale

La traduzione è il processo mediante il quale i controlli di ragionamento automatico convertono il linguaggio naturale (domande degli utenti e risposte LLM) in espressioni logiche formali che possono essere verificate matematicamente rispetto alle regole delle politiche. Comprendere questo processo è fondamentale per risolvere i problemi e creare politiche efficaci.

I controlli di ragionamento automatico convalidano i contenuti in due fasi distinte:

1. Traduzione: i controlli di ragionamento automatico utilizzano modelli di base (LLM) per tradurre l'input del linguaggio naturale in logica formale. Questo passaggio associa i concetti contenuti nel testo alle variabili della policy ed esprime le relazioni come affermazioni logiche. Poiché questo passaggio utilizza gli LLM, può contenere errori. Automated Reasoning checks utilizza più LLM per tradurre il testo di input, quindi utilizza l'equivalenza semantica delle traduzioni ridondanti per impostare un punteggio di confidenza. La qualità della traduzione dipende dalla corrispondenza delle descrizioni delle variabili con la lingua utilizzata nell'input.

2. Convalida: i controlli di ragionamento automatico utilizzano tecniche matematiche (tramite risolutori SMT) per verificare se la logica tradotta è coerente con le regole delle politiche. Questo passaggio è matematicamente valido: se la traduzione è corretta, il risultato della convalida sarà coerente.

Importante

Questa distinzione in due fasi è fondamentale per il debugging. Se siete certi che le regole della policy siano corrette, quando un test fallisce o restituisce risultati imprevisti, il problema è molto probabilmente nella fase 1 (traduzione), non nella fase 2 (convalida). La convalida matematica è valida e se la traduzione cattura correttamente il significato dell'input, il risultato della convalida sarà corretto. Concentra i tuoi sforzi di debug sul miglioramento delle descrizioni delle variabili e sulla garanzia che la traduzione assegni le variabili giuste con i valori giusti.

Esempio: traduzione in azione

Data una policy con variabili isFullTime (BOOL), tenureMonths (INT) e eligibleForParentalLeave (BOOL) e l'input:

• Domanda: «Sono un impiegato a tempo pieno e sono qui da 18 mesi. Posso usufruire del congedo parentale?»

• Risposta: «Sì, hai diritto al congedo parentale».

La fase 1 (traduzione) produce:

Premises: isFullTime = true, tenureMonths = 18
Claims: eligibleForParentalLeave = true

La fase 2 (convalida) verifica queste assegnazioni rispetto alla regola della politica (=> (and isFullTime (> tenureMonths 12)) eligibleForParentalLeave) e conferma che il reclamo è valido. VALID

Per migliorare l'accuratezza della traduzione:

• Scrivi descrizioni dettagliate delle variabili che illustrino il modo in cui gli utenti si riferiscono ai concetti nel linguaggio quotidiano.

• Rimuovi le variabili duplicate o quasi duplicate che potrebbero confondere la traduzione (ad esempio e). tenureMonths monthsOfService

• Elimina le variabili inutilizzate a cui non fa riferimento alcuna regola: aggiungono rumore al processo di traduzione.

• Utilizza i test di domande e risposte per convalidare l'accuratezza della traduzione con input realistici da parte dell'utente. Per ulteriori informazioni, consulta Testare una policy di ragionamento automatico.

Conclusioni e risultati di convalida

Quando i controlli di ragionamento automatico convalidano il contenuto, produce una serie di risultati. Ogni risultato rappresenta un'affermazione fattuale estratta dall'input, insieme al risultato della convalida, alle assegnazioni delle variabili utilizzate e alle regole politiche che supportano la conclusione. Il risultato complessivo (aggregato) viene determinato ordinando i risultati in ordine di gravità e selezionando il risultato peggiore. L'ordine di gravità dal peggiore al migliore è:TRANSLATION_AMBIGUOUS,,, IMPOSSIBLEINVALID,SATISFIABLE. VALID

Struttura di un risultato

Il tipo di risultato determina quali campi sono presenti nel risultato. Consulta la Riferimento ai risultati della convalida sezione per una descrizione approfondita di ciascun tipo di risultato. Tuttavia, la maggior parte dei tipi di ricerca condivide un translation oggetto comune che contiene i seguenti componenti:

premises

Contesto, ipotesi o condizioni estratte dall'input che influiscono sul modo in cui una richiesta deve essere valutata. Nei formati di domanda e risposta, la premessa è spesso la domanda stessa. Le risposte possono anche contenere premesse che stabiliscono dei vincoli. Ad esempio, in «Sono un dipendente a tempo pieno con 18 mesi di servizio», le premesse sono isFullTime = true e. tenureMonths = 18

claims

Dichiarazioni fattuali che i controlli di ragionamento automatico valutano per verificarne l'accuratezza. In un formato di domanda e risposta, l’affermazione è in genere la risposta. Ad esempio, in «Sì, hai diritto al congedo parentale», il reclamo è. eligibleForParentalLeave = true

confidence

Un punteggio da 0,0 a 1,0 che rappresenta l'importanza di alcuni controlli di ragionamento automatico sulla traduzione dal linguaggio naturale alla logica formale. I punteggi più alti indicano una maggiore certezza. Una confidenza di 1,0 significa che tutti i modelli di traduzione concordano sulla stessa interpretazione.

untranslatedPremises

Riferimenti a parti del testo di input originale che corrispondono alle premesse ma che non è stato possibile tradurre in logica formale. Questi evidenziano parti dell'input che Automated Reasoning ha riconosciuto come pertinenti ma che non è stato possibile associare alle variabili politiche.

untranslatedClaims

Riferimenti a parti del testo di input originale che corrispondono alle affermazioni ma che non è stato possibile tradurre in logica formale. Un VALID risultato copre solo le affermazioni tradotte: le affermazioni non tradotte non sono convalidate.

Riferimento ai risultati della convalida

Ogni risultato è esattamente uno dei seguenti tipi. Il tipo determina il significato del risultato, i campi disponibili nel risultato e l'azione consigliata per l'applicazione. Tutti i tipi di ricerca che includono un translation logicWarning campo includono anche un campo presente quando la traduzione contiene problemi logici indipendenti dalle regole della politica (ad esempio, affermazioni sempre vere o sempre false).

Risultato	Ricerca di campi	Azione consigliata
VALID	translation— Le premesse tradotte, le affermazioni, il punteggio di affidabilità e qualsiasi riferimento non tradotto. supportingRules— Le regole politiche che dimostrano che le affermazioni sono corrette. Ogni regola include il suo identificatore e la versione della politica ARN. claimsTrueScenario— Uno scenario (set di assegnazioni di variabili) che dimostra come le affermazioni siano logicamente vere.	Fornisci la risposta all'utente. Registro supportingRules e a claimsTrueScenario scopo di controllo: forniscono una prova di validità verificabile matematicamente. Verifica la presenza untranslatedPremises untranslatedClaims di parti dell'input che non sono state convalidate.
INVALID	translation— Le premesse tradotte, le affermazioni, il punteggio di affidabilità e tutti i riferimenti non tradotti. contradictingRules— Le regole politiche che i reclami violano. Ogni regola include il suo identificatore e la versione della policy ARN.	Non fornire la risposta. Usa translation (per vedere cosa è stato rivendicato) e contradictingRules (per vedere quali regole sono state violate) per riscrivere la risposta o bloccarla. In un ciclo di riscrittura, trasmetti le regole contraddittorie e le affermazioni errate al LLM per generare una risposta corretta.
SATISFIABLE	translation— Le premesse tradotte, le affermazioni, il punteggio di affidabilità e tutti i riferimenti non tradotti. claimsTrueScenario— Uno scenario che dimostra come le affermazioni potrebbero essere logicamente vere. claimsFalseScenario— Uno scenario che dimostra come le affermazioni potrebbero essere logicamente false in condizioni diverse.	Confronta claimsTrueScenario e identifica claimsFalseScenario le condizioni mancanti. Riscrivi la risposta per includere le informazioni aggiuntive necessarie per realizzarlaVALID, chiedi all'utente chiarimenti sulle condizioni mancanti o fornisci la risposta avvertendo che potrebbe essere incompleta.
IMPOSSIBLE	translation— Le premesse tradotte, le affermazioni, il punteggio di affidabilità e qualsiasi riferimento non tradotto. Ispeziona i locali per identificare le contraddizioni. contradictingRules— Le regole politiche che sono in conflitto con i locali o tra loro. Se popolata, la contraddizione potrebbe risiedere nella politica stessa.	Verifica se l'input contiene affermazioni contraddittorie (ad esempio, «Sono a tempo pieno e anche a tempo parziale»). Se l'input è valido, è probabile che ci sia una contraddizione nella tua politica: controlla contradictingRules e rivedi il rapporto sulla qualità. Per informazioni, consulta Risolvi i problemi e perfeziona la tua politica di ragionamento automatico.
TRANSLATION_AMBIGUOUS	Non contiene un translation oggetto. Fornisce invece: options— Le interpretazioni logiche concorrenti (fino a 2). Ogni opzione contiene le proprie translations premesse, affermazioni e fiducia. Confronta le opzioni per vedere dove i modelli non sono d'accordo. differenceScenarios— Scenari (fino a 2) che illustrano come le diverse interpretazioni differiscano nel significato, con assegnazioni di variabili che evidenziano l'impatto pratico dell'ambiguità.	Ispeziona per comprendere il disaccordooptions. Migliora le descrizioni delle variabili per ridurre l'ambiguità, unisci o rimuovi le variabili sovrapposte o chiedi chiarimenti all'utente. Puoi anche modificare la soglia di confidenza: vedi. Soglie di confidenza
TOO_COMPLEX	Non contiene atranslation, regole o scenari. L'input ha superato la capacità di elaborazione a causa del volume o della complessità.	Riduci l'input suddividendolo in parti più piccole o semplifica le politiche riducendo il numero di variabili ed evita operazioni aritmetiche complesse (ad esempio, esponenti o numeri irrazionali). Puoi suddividere la tua politica in politiche più piccole e più mirate.
NO_TRANSLATIONS	Non contiene regole o scenari. translation Può apparire insieme ad altri risultati se solo una parte dell'input potesse essere tradotta.	Un NO_TRANSLATIONS risultato è incluso nell'output ogni volta che uno degli altri risultati include premesse o affermazioni non tradotte. Esamina gli altri risultati per vedere quali parti dell'input non sono state tradotte. Se il contenuto deve essere pertinente, aggiungete delle variabili alla vostra policy per comprendere i concetti mancanti. Se il contenuto è fuori tema, valuta la possibilità di utilizzare politiche tematiche per filtrarlo prima che arrivi ai controlli di ragionamento automatico.

Nota

Un VALID risultato copre solo le parti dell'input acquisite tramite le variabili politiche nelle premesse e nelle affermazioni tradotte. Le dichiarazioni che non rientrano nell'ambito delle variabili della polizza non vengono convalidate. Ad esempio, «Posso presentare i miei compiti in ritardo perché ho un certificato medico falso» potrebbe essere considerato valido se la polizza non prevede variabili per stabilire se la nota medica è falsa. I controlli di ragionamento automatico probabilmente includeranno «certificato medico falso» come premessa non tradotta nella loro conclusione. Considera i contenuti e i NO_TRANSLATIONS risultati non tradotti come un segnale di avvertimento.

Soglie di confidenza

I controlli di ragionamento automatico utilizzano diversi modelli di base per tradurre il linguaggio naturale in logica formale. Ogni modello produce la propria traduzione in modo indipendente. Il punteggio di confidenza rappresenta il livello di accordo tra queste traduzioni, in particolare, la percentuale di modelli che hanno prodotto interpretazioni semanticamente equivalenti.

La soglia di confidenza è un valore impostato (da 0,0 a 1,0) che determina il livello minimo di accordo richiesto affinché una traduzione sia considerata sufficientemente affidabile da essere convalidata. Controlla il compromesso tra copertura e precisione:

• Soglia più alta (ad esempio 0,9): richiede un forte accordo tra i modelli di traduzione. Produce meno risultati ma con una maggiore precisione. Altri input verranno contrassegnati come. TRANSLATION_AMBIGUOUS

• Soglia inferiore (ad esempio 0,5): accetta traduzioni con meno accordi. Produce più risultati ma con un rischio maggiore di traduzioni errate. Un numero inferiore di input verrà contrassegnato come. TRANSLATION_AMBIGUOUS

Come funziona la soglia:

1. Diversi modelli di base traducono ciascuno l'input in modo indipendente.

2. Le traduzioni supportate da una percentuale di modelli pari o superiore alla soglia diventano risultati ad alta affidabilità con un risultato definitivo (VALID,INVALID, ecc.).

3. Se una o più traduzioni scendono al di sotto della soglia, i controlli di ragionamento automatico forniscono un ulteriore risultato. TRANSLATION_AMBIGUOUS Questo risultato include dettagli sui disaccordi tra i modelli, che puoi utilizzare per migliorare le descrizioni delle variabili o chiedere chiarimenti all'utente.

Suggerimento

Inizia con la soglia predefinita e aggiusta in base ai risultati dei test. Se vedi troppi TRANSLATION_AMBIGUOUS risultati per input che dovrebbero essere univoci, concentrati sul miglioramento delle descrizioni delle variabili piuttosto che sull'abbassamento della soglia. L'abbassamento della soglia può ridurre i TRANSLATION_AMBIGUOUS risultati ma aumenta il rischio di convalide errate.