Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Le migliori pratiche relative alla politica di ragionamento automatico

Questa pagina consolida le migliori pratiche per la creazione e la manutenzione delle politiche di ragionamento automatico. Leggila prima di creare la tua prima policy e consultala quando risolvi problemi di debug. Per i fondamenti concettuali alla base di queste pratiche, vedi. Il ragionamento automatizzato controlla i concetti Per istruzioni sulla step-by-step creazione, vedereCreare una policy di ragionamento automatico.

Inizia in modo semplice e ripeti

L'errore più comune quando si crea una policy di ragionamento automatico è cercare di acquisire un intero documento complesso in un unico passaggio. Invece, inizia con un sottoinsieme mirato delle tue regole e costruiscilo in modo incrementale.

Questo approccio presenta due vantaggi: semplifica l'isolamento dei problemi (sapete quale sezione ha introdotto un problema) e mantiene la politica gestibile durante lo sviluppo. Una politica con 10 regole ben collaudate è più utile di una con 100 regole non testate.

Preelabora i documenti con un LLM

Per documenti lunghi, contenenti prosa narrativa o che combinano regole con contenuti non regolamentari (come esclusioni di responsabilità legali o background organizzativo), esegui il documento tramite un LLM prima di caricarlo su Automated Reasoning Checks. Chiedi al LLM di estrarre il contenuto come regole if-then esplicite. Questa fase di preelaborazione migliora significativamente la qualità della politica estratta perché i controlli di ragionamento automatico funzionano meglio con dichiarazioni chiare e dichiarative piuttosto che con testo non strutturato.

Quando scrivi il prompt di preelaborazione, includi le seguenti istruzioni per il LLM:

Per modelli di prompt dettagliati e un flusso di lavoro di step-by-step preelaborazione, vedere. (Facoltativo) Utilizzate un LLM per riscrivere i documenti come regole logiche

Utilizza le implicazioni (=>) per strutturare le regole

Il formato if-then (che utilizza l'operatore di => implicazione) è il modello di scrittura delle regole più importante. Ogni regola che esprime una relazione condizionale deve utilizzare questo formato.

Le semplici asserzioni (regole senza una struttura if-then) creano assiomi, affermazioni che sono sempre vere. L'affermazione eligibleForParentalLeave indica ai controlli di Automated Reasoning che l'idoneità al congedo parentale è sempre vera, indipendentemente da qualsiasi condizione. Qualsiasi input che indichi che l'utente non è idoneo verrà restituito IMPOSSIBLE perché contraddice questo assioma.

Le semplici asserzioni sono appropriate solo per condizioni limite che dovrebbero sempre valere, come:

;; Account balance can never be negative
(>= accountBalance 0)

;; Interest rate is always between 0 and 1
(and (>= interestRate 0) (<= interestRate 1))

Se trovi semplici asserzioni nella politica estratta, riscrivile come condizionali o eliminale. Per ulteriori informazioni sulla revisione della politica estratta, consulta. Rivedi la politica estratta

Scrivi descrizioni complete delle variabili

Le descrizioni delle variabili sono il fattore principale per l'accuratezza della traduzione. Quando i controlli di ragionamento automatico traducono il linguaggio naturale in logica formale, utilizzano descrizioni delle variabili per determinare quali variabili corrispondono ai concetti menzionati nel testo. Le descrizioni vaghe o incomplete sono la causa principale dei TRANSLATION_AMBIGUOUS risultati.

Una buona descrizione delle variabili dovrebbe rispondere a quattro domande:

Esempio: prima e dopo

Usa i valori booleani per stati non esclusivi

Quando modellate stati che possono coesistere, utilizzate variabili booleane separate anziché un singolo enum. Una persona può essere sia un veterano che un insegnante. L'uso di un enum customerType = {VETERAN, TEACHER} impone una scelta tra di loro, creando una contraddizione logica quando entrambi si applicano.

Riserva le enumerazioni per categorie che si escludono a vicenda in cui è possibile applicare un solo valore alla volta, ad esempio leaveType = {PARENTAL, MEDICAL, BEREAVEMENT} (un dipendente può richiedere solo un tipo di ferie alla volta). Per ulteriori informazioni sui tipi personalizzati, vedere. Tipi personalizzati (enumerazioni)

Specificare unità e formati nelle descrizioni delle variabili

L'ambiguità sulle unità è una fonte comune di errori di traduzione. Se un utente dice «Lavoro qui da 2 anni» e la variabile ètenureMonths: la traduzione deve essere in grado di convertire gli anni in mesi. Se la descrizione della variabile non specifica l'unità, la traduzione può assegnare tenureMonths = 2 invece ditenureMonths = 24.

Specificate sempre:

Esempi:

Convalidare gli intervalli per i valori numerici

Per le variabili numeriche, aggiungi regole limite che limitino l'intervallo valido. In questo modo si evitano scenari logicamente impossibili e si aiutano i controlli di ragionamento automatico a produrre risultati più significativi.

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

Senza queste regole limite, i controlli di ragionamento automatico potrebbero prendere in considerazione scenari con saldi contabili negativi o punteggi di credito superiori a 1000, che sono privi di significato nel tuo dominio. Le regole limite sono uno dei pochi casi in cui le semplici asserzioni (regole non in formato if-then) sono appropriate.

Usa variabili intermedie per l'astrazione

Quando più regole condividono una condizione comune, estrai quella condizione in una variabile booleana intermedia. Ciò semplifica le regole e facilita la gestione della politica.

Esempio: livelli di iscrizione

Invece di ripetere la condizione di iscrizione in ogni regola sui benefit:

;; Without intermediate variable (repetitive)
(=> (and (> purchaseTotal 1000) (> accountAge 12)) eligibleForFreeShipping)
(=> (and (> purchaseTotal 1000) (> accountAge 12)) eligibleForPrioritySupport)
(=> (and (> purchaseTotal 1000) (> accountAge 12)) eligibleForEarlyAccess)

Definisci una variabile intermedia e fai riferimento ad essa:

;; With intermediate variable (cleaner)
(=> (and (> purchaseTotal 1000) (> accountAge 12)) isPremiumMember)
(=> isPremiumMember eligibleForFreeShipping)
(=> isPremiumMember eligibleForPrioritySupport)
(=> isPremiumMember eligibleForEarlyAccess)

Questo modello semplifica l'aggiornamento dei criteri di iscrizione in un secondo momento: è sufficiente modificare una sola regola anziché tre.

Usa le enumerazioni per la categorizzazione

Quando una variabile rappresenta una categoria con un insieme fisso di valori che si escludono a vicenda, utilizzate un tipo personalizzato (enum) anziché più valori booleani o una stringa. Le enumerazioni limitano i valori possibili e rendono le regole più chiare.

Mantieni la logica dichiarativa, non procedurale

Le politiche di ragionamento automatizzato descrivono ciò che è vero, non come calcolarlo. Evita di scrivere regole che assomigliano a codice con passaggi sequenziali o logica di precedenza.

Analogamente, evitate di codificare la precedenza o la priorità tra le regole. Nella logica formale, tutte le regole si applicano contemporaneamente. Se devi esprimere che una condizione prevale su un'altra, codificala esplicitamente nelle condizioni della regola:

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

Convenzioni di denominazione

La denominazione coerente semplifica la lettura, la gestione e il debug delle politiche. Segui queste convenzioni:

Evita le abbreviazioni che potrebbero essere ambigue. Usa tenureMonths invece ditenMo, e isFullTime invece di. ft I nomi chiari aiutano sia i revisori umani che il processo di traduzione.

Anti-pattern comuni

I seguenti schemi causano spesso problemi nelle politiche di ragionamento automatico. Se riscontri risultati inaspettati dei test, controlla se la tua policy contiene questi anti-pattern.

Assiomi anziché implicazioni

Come descritto inUtilizza le implicazioni (=>) per strutturare le regole, le semplici asserzioni creano assiomi che sono sempre veri. Questa è l'anti-pattern più comune e la più dannosa: restituisce intere categorie di input. IMPOSSIBLE

Sintomo: test che dovrebbero restituire VALID o INVALID restituire invece. IMPOSSIBLE

Correzione: trova semplici asserzioni nelle tue regole e riscrivile come implicazioni, oppure eliminale se non rappresentano condizioni limite.

Variabili sovrapposte

La presenza di due variabili che rappresentano concetti uguali o simili (ad esempio, tenureMonths emonthsOfService) confonde il processo di traduzione. I controlli di ragionamento automatizzato non sono in grado di determinare quale variabile utilizzare per un determinato concetto, con conseguenti traduzioni e risultati incoerenti. TRANSLATION_AMBIGUOUS

Sintomo: i test restituiscono risultati TRANSLATION_AMBIGUOUS anche con un testo di input chiaro e inequivocabile.

Correzione: unisci le variabili sovrapposte in un'unica variabile con una descrizione completa. Aggiorna tutte le regole che fanno riferimento alla variabile eliminata.

Politiche eccessivamente complesse

Le politiche con troppe variabili, condizioni profondamente annidate o aritmetiche non lineari possono superare i limiti di elaborazione e restituire risultati. TOO_COMPLEX

Sintomo: i test vengono restituiti o scaduti. TOO_COMPLEX

Correzione: semplifica la politica. Rimuovi le variabili inutilizzate, suddividi le regole complesse in regole più semplici utilizzando variabili intermedie ed evita l'aritmetica non lineare (esponenti, numeri irrazionali). Se il tuo dominio è davvero complesso, valuta la possibilità di suddividerlo in più policy mirate.

Regole contraddittorie

Le regole che si contraddicono a vicenda impediscono ai controlli di ragionamento automatico di giungere a una conclusione. Ad esempio, una regola afferma che i dipendenti a tempo pieno hanno diritto alle ferie, mentre un'altra afferma che i dipendenti del primo anno non lo sono, senza specificare cosa succede ai dipendenti a tempo pieno nel primo anno.

Sintomo: i test vengono restituiti IMPOSSIBLE per gli input che coinvolgono regole in conflitto.

Correzione: controlla il rapporto sulla qualità per verificare la presenza di regole in conflitto. Risolvi i conflitti unendo le regole in un'unica regola con condizioni esplicite o eliminando una delle regole in conflitto. Per ulteriori informazioni, consulta Rivedi la politica estratta.

Variabili non utilizzate

Le variabili che non sono referenziate da alcuna regola aggiungono disturbo al processo di traduzione. La traduzione può assegnare valori a variabili non utilizzate, sprecando la capacità di elaborazione e potenzialmente causando TRANSLATION_AMBIGUOUS risultati quando la variabile inutilizzata compete con una variabile attiva simile.

Sintomo: TRANSLATION_AMBIGUOUS risultati imprevisti o traduzioni che assegnano valori a variabili che non influiscono su alcuna regola.

Correzione: elimina le variabili non utilizzate. Nella console, cerca gli indicatori di avviso accanto alle variabili. Tramite l'API, controlla il rapporto sulla qualità di GetAutomatedReasoningPolicyBuildWorkflowResultAssets con--asset-type QUALITY_REPORT.

Valori enum mancanti

Se il tuo enum non include un valore per ogni possibile categoria che gli utenti potrebbero menzionare, la traduzione potrebbe non riuscire o produrre risultati imprevisti quando l'input non corrisponde a nessun valore definito.

Sintomo: i test restituiscono TRANSLATION_AMBIGUOUS o NO_TRANSLATIONS quando l'input menziona una categoria non presente nell'enum.

Correzione: aggiungi un NONE valore OTHER or al tuo enum per gestire gli input che non corrispondono alle categorie definite. Aggiorna le descrizioni dei valori enum per chiarire quando si applica ogni valore.