Testare una policy di ragionamento automatico - Amazon Bedrock
Strategia di test: scenari e test QnAGenera automaticamente scenari di test nella consoleGenera scenari di test automaticamente utilizzando l'APICrea un test QnA manualmente nella consoleCrea un test QnA utilizzando l'APIEsegui dei testComprendi i risultati dei test

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

Testare una policy di ragionamento automatico

I test convalidano che le regole della policy siano corrette e che i controlli di ragionamento automatico possano tradurre accuratamente il linguaggio naturale in logica formale. Si verifica una politica inviando istruzioni in linguaggio naturale per la convalida, quindi esaminando il feedback per assicurarsi che la traduzione utilizzi le variabili corrette e che le regole producano i risultati previsti.

Esistono due approcci di test complementari: scenari generati e test question-and-answer (QnA). Ciascuno si rivolge a una parte diversa della pipeline di convalida. Il flusso di lavoro consigliato è iniziare con scenari per convalidare la correttezza delle regole, quindi aggiungere test QnA per convalidare l'accuratezza della traduzione.

Strategia di test: scenari e test QnA

I controlli di ragionamento automatico convalidano i contenuti in due fasi: in primo luogo, i modelli di base traducono il linguaggio naturale in logica formale; quindi, le tecniche matematiche verificano la logica rispetto alle regole delle policy. Ogni approccio di test riguarda una fase diversa di questa pipeline.

Scenari generati (correttezza delle regole di test)

Gli scenari generati testano direttamente la semantica codificata nelle regole delle policy. Eliminano l'incertezza della traduzione in linguaggio naturale dall'equazione, isolando se le regole stesse sono corrette.

Gli scenari vengono generati dalle regole delle politiche e rappresentano situazioni logicamente possibili in base a tali regole. Vengono ordinati in modo da far emergere per primi la maggior parte degli likely-to-be-wrong scenari. Per ogni scenario, esaminate le assegnazioni delle variabili e decidete:

  • Pollice in su: lo scenario è realistico e dovrebbe effettivamente essere possibile. Salvalo come SATISFIABLE test.

  • Pollice in giù: qualcosa non va. Lo scenario non dovrebbe essere possibile data la tua conoscenza del dominio. Fornisci un feedback in linguaggio naturale che spieghi il motivo e i controlli di ragionamento automatico cercheranno di dedurre le modifiche necessarie alle regole.

Esempio: la tua politica prevede che i dipendenti a tempo pieno con più di 12 mesi di mandato abbiano diritto al congedo parentale. Potrebbe essere visualizzato uno scenario generato. isFullTime = true, tenureMonths = 3, eligibleForParentalLeave = true Se questo scenario non dovesse essere possibile (perché 3 mesi sono meno di 12), esprimeresti il pollice in giù e spiegheresti che i dipendenti hanno bisogno di almeno 12 mesi di mandato. Ciò indica una regola mancante o errata.

Usa gli scenari come prima fase di test. Ti aiutano a individuare i problemi relativi alle regole prima di dedicare tempo alla stesura di test QnA.

Test QnA (precisione della traduzione dei test)

I test QnA convalidano l'intera pipeline end-to-end: traduzione in linguaggio naturale e convalida delle regole insieme. Imitano le interazioni degli utenti reali e rilevano problemi di traduzione che gli scenari non sono in grado di rilevare.

Ogni test QnA è composto da:

  • Un input (opzionale): la domanda che un utente potrebbe porre all'applicazione.

  • Un output: la risposta che il modello di base potrebbe generare.

  • Un risultato previsto: il risultato di convalida previsto (ad esempio, VALID oINVALID).

Esempio: per la stessa politica sul congedo parentale, un test QnA potrebbe essere: input = «Lavoro qui da 2 anni a tempo pieno. Posso usufruire del congedo parentale?» , output = «Sì, hai diritto al congedo parentale. «, risultato atteso =VALID. Questo verifica se Automated Reasoning Checks traduce correttamente «2 anni» in tenureMonths = 24 e «tempo pieno» in. isFullTime = true

Suggerimento

Crea test che coprano scenari validi e non validi. Ad esempio, se la tua politica afferma che «I dipendenti hanno bisogno di 1 anno di servizio per il congedo parentale», crea test per le risposte che stabiliscono correttamente questa regola e test per le risposte che indicano erroneamente un requisito diverso.

  1. Genera e rivedi scenari. Inizia da qui per verificare che le tue regole siano corrette. Risolvi eventuali problemi relativi alle regole prima di procedere.

  2. Scrivi test QnA per i casi d'uso principali. Concentrati sulle domande che i tuoi utenti sono più propensi a porre e sulle risposte che il tuo LLM è più probabile che generi. Includi casi limite e condizioni limite.

  3. Esegui tutti i test. Verifica che sia gli scenari che i test QnA abbiano esito positivo.

  4. Iterare. Se i test falliscono, stabilisci se il problema è nelle regole (correggi la politica) o nella traduzione (migliora le descrizioni delle variabili). Per ulteriori informazioni, consulta Risolvi i problemi e perfeziona la tua politica di ragionamento automatico.

Genera automaticamente scenari di test nella console

  1. Vai alla policy di ragionamento automatico che desideri testare (ad esempio, MyHrPolicy).

  2. Scegli Visualizza test, poi seleziona Aggiungi.

  3. Nella finestra di dialogo Genera scenari, esamina lo scenario generato e le relative regole. Ogni scenario mostra una serie di assegnazioni di variabili che sono logicamente possibili in base alle regole della politica. Valuta se lo scenario è realistico nel tuo dominio:

    • Se lo scenario può verificarsi nel tuo dominio (è soddisfacente), seleziona l'icona con il pollice rivolto verso l'alto. Questo salva lo scenario come test che prevede un risultato. SATISFIABLE

    • Se lo scenario non dovrebbe essere possibile, seleziona l'icona con il pollice rivolto verso il basso. Fornisci un'annotazione che spieghi perché, ad esempio, «I dipendenti hanno bisogno di almeno 12 mesi di mandato per il congedo parentale, ma questo scenario mostra 3 mesi di idoneità». Automated Reasoning Checks utilizza il feedback dell'utente per dedurre le modifiche alle regole che potrebbero impedire questo scenario.

    • Se desideri uno scenario diverso, scegli Rigenera scenario.

    Suggerimento

    Per esaminare la versione logica formale dello scenario, abilitate Show SMT-LIB. Ciò è utile per comprendere esattamente quali regole e assegnazioni di variabili sono coinvolte.

  4. Seleziona Salva e chiudi per salvare il test oppure Salva e aggiungine un altro per continuare a esaminare gli scenari.

  5. Se hai fornito annotazioni (feedback con il pollice in giù) a qualsiasi scenario, scegli Applica annotazioni. I controlli automatici di ragionamento avvieranno un flusso di lavoro di compilazione per applicare le modifiche alla politica in base al feedback ricevuto.

  6. Nella schermata Rivedi le modifiche alla politica, esamina le modifiche proposte alle regole, alle variabili e ai tipi di variabili della politica. Poi seleziona Accetta modifiche.

Genera scenari di test automaticamente utilizzando l'API

Utilizza l'GetAutomatedReasoningPolicyNextScenarioAPI per recuperare gli scenari di test generati in base alle regole della tua politica.

policyArn(richiesto)

L'ARN della politica di ragionamento automatico.

buildWorkflowId(richiesto)

L'identificatore del flusso di lavoro di compilazione per gli scenari generati. Recupera il flusso di lavoro di compilazione più recente utilizzando l'ListAutomatedReasoningPolicyBuildWorkflowsAPI.

Esempio:

aws bedrock get-automated-reasoning-policy-next-scenario \
  --policy-arn "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk" \
  --build-workflow-id d40fa7fc-351e-47d8-a338-53e4b3b1c690

La risposta include uno scenario generato con assegnazioni variabili e le relative regole politiche. Esamina lo scenario e utilizza l'CreateAutomatedReasoningPolicyTestCaseAPI per salvarlo come test oppure usa l'annotazione APIs per fornire un feedback se lo scenario rivela un problema relativo alla regola.

Crea un test QnA manualmente nella console

  1. Vai alla politica di ragionamento automatico che desideri testare (ad esempio, MyHrPolicy).

  2. Scegli Visualizza test, poi seleziona Aggiungi.

  3. Nella finestra di dialogo Aggiungi test, procedi come segue:

    1. In Input (opzionale), inserisci la domanda che un utente potrebbe porre. In Output, inserisci la risposta che il tuo modello di base potrebbe fornire. Insieme, formano una coppia QnA che verifica il modo in cui la tua politica convalida le interazioni reali con gli utenti.

    2. Scegli il risultato che ti aspetti dal test (ad esempio Valido o Non valido).

    3. (Facoltativo) Seleziona una soglia di confidenza, che è il livello di confidenza minimo per la convalida logica. I controlli di ragionamento automatizzati utilizzano più metodi LLMs per tradurre il linguaggio naturale in risultati. Restituisce solo i risultati supportati da una percentuale significativa delle traduzioni LLM. La soglia di affidabilità definisce la percentuale minima di supporto necessaria affinché una traduzione diventi un esito valido. I risultati al di sotto della soglia vengono visualizzati come. TRANSLATION_AMBIGUOUS

  4. Seleziona Salva per creare il test.

Crea un test QnA utilizzando l'API

Usa l'CreateAutomatedReasoningPolicyTestCaseAPI per creare un test a livello di codice.

policyArn(richiesto)

L'ARN della politica di ragionamento automatico.

queryContent (facoltativo)

La query o il prompt di input che ha generato il contenuto, ad esempio la domanda dell'utente. Fornisce il contesto per la convalida.

guardContent(obbligatorio)

Il contenuto di output da convalidare: la risposta del modello di base di cui verrà verificata l'accuratezza.

expectedAggregatedFindingsResult (facoltativo)

Il risultato di convalida previsto (ad esempio, VALID oINVALID). Il risultato effettivo viene determinato ordinando i risultati in ordine di gravità e selezionando il risultato peggiore. L'ordine di gravità dal peggiore al migliore è:TRANSLATION_AMBIGUOUS,,IMPOSSIBLE, INVALIDSATISFIABLE,VALID.

confidenceThreshold (facoltativo)

Il livello minimo di affidabilità per la convalida logica.

Esempio:

aws bedrock create-automated-reasoning-policy-test-case \
  --policy-arn "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk" \
  --query-content "Can I take a leave of absence if I'm a part-time employee?" \
  --guard-content "No, only full-time employees are eligible for leave of absence." \
  --expected-aggregated-findings-result "VALID" \
  --confidence-threshold 0.8

Risposta di esempio:

{
  "testCaseId": "test-12345abcde",
  "policyArn": "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk"
}

Esegui dei test

Eseguire test nella console

  1. Vai alla politica di ragionamento automatico che desideri convalidare (ad esempio, MyHrPolicy).

  2. Scegli Visualizza test.

  3. Esegui una delle seguenti operazioni:

    • Per eseguire tutti i test, scegli Convalida tutti i test.

    • Per eseguire un singolo test, seleziona il pulsante Azione accanto al test e scegli Convalida.

Eseguire i test utilizzando l’API

Usa l'StartAutomatedReasoningPolicyTestWorkflowAPI per eseguire i test e l'GetAutomatedReasoningPolicyTestResultAPI per recuperare i risultati.

policyArn(richiesto)

L'ARN della politica di ragionamento automatico.

buildWorkflowId(richiesto)

L'identificatore del flusso di lavoro di compilazione rispetto al quale eseguire i test. Recupera il flusso di lavoro di compilazione più recente utilizzando l'ListAutomatedReasoningPolicyBuildWorkflowsAPI.

testCaseIds (facoltativo)

Un elenco di identificatori di test da eseguire. Se non viene fornito, vengono eseguiti tutti i test per la policy.

Esempio:

# Run tests
aws bedrock start-automated-reasoning-policy-test-workflow \
  --policy-arn "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk" \
  --build-workflow-id d40fa7fc-351e-47d8-a338-53e4b3b1c690

# Get results for a specific test
aws bedrock get-automated-reasoning-policy-test-result \
  --policy-arn "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk" \
  --build-workflow-id d40fa7fc-351e-47d8-a338-53e4b3b1c690 \
  --test-case-id test-12345abcde

La risposta include risultati dettagliati dei test con risultati di convalida e stato di esecuzione. Per elencare tutti i risultati dei test per un flusso di lavoro di compilazione, utilizza l'ListAutomatedReasoningPolicyTestResultsAPI.

Comprendi i risultati dei test

Al termine di un test, ricevi una serie di risultati. Ogni risultato rappresenta un'affermazione fattuale estratta dall'input del test, insieme al risultato della convalida, alle assegnazioni delle variabili utilizzate e alle regole politiche che supportano la conclusione. Per una descrizione dettagliata della struttura dei risultati e di tutti i tipi di risultati di convalida, vedere. Conclusioni e risultati di convalida

Anatomia del risultato di un test

Ogni risultato del test include:

  • Risultato previsto: il risultato impostato durante la creazione del test.

  • Risultato effettivo: il risultato aggregato dell'esecuzione del test. Questo viene determinato ordinando i risultati in ordine di gravità e selezionando il risultato peggiore. L'ordine di gravità dal peggiore al migliore è:TRANSLATION_AMBIGUOUS,,IMPOSSIBLE, INVALIDSATISFIABLE,VALID. Ad esempio, un test con due VALID risultati e un IMPOSSIBLE risultato ha un risultato aggregato diIMPOSSIBLE.

  • Risultato dell'esecuzione: se il test è stato superato (i risultati previsti e quelli effettivi corrispondono) o non è riuscito.

  • Risultati: i risultati individuali della convalida. Ogni risultato contiene le premesse e le affermazioni tradotte, un punteggio di confidenza, le assegnazioni delle variabili e le regole politiche che supportano la conclusione.

Interpretazione pratica dei risultati

La tabella seguente riassume il significato pratico di ciascun risultato di convalida e le azioni da intraprendere quando lo si vede in un test. Per il riferimento completo, compresi i campi di ricerca e le descrizioni dettagliate, vedere. Riferimento ai risultati della convalida

Risultato Significato Cosa fare
VALID Le affermazioni contenute nella risposta si sono dimostrate matematicamente corrette, date le premesse e le regole della politica. La conclusione include supportingRules la dimostrazione delle affermazioni e la claimsTrueScenario dimostrazione della veridicità delle affermazioni. Se questo è il risultato previsto, il test viene superato. Verifica untranslatedPremises la presenza untranslatedClaims di parti dell'input che non sono state convalidate: un VALID risultato copre solo le affermazioni tradotte.
INVALID Le affermazioni contraddicono le regole della tua politica. La scoperta include la contradictingRules visualizzazione di quali regole sono state violate. Se questo è il risultato previsto, il test viene superato. Se inaspettato, controlla se le regole sono corrette o se la traduzione ha assegnato le variabili sbagliate. Esamina il contradictingRules per capire quali regole hanno causato il risultato.
SATISFIABLE Le affermazioni sono coerenti con la tua politica ma non riguardano tutte le regole pertinenti. La risposta è corretta in alcune condizioni, ma non in tutte. La scoperta include claimsTrueScenario sia a che a che che claimsFalseScenario mostrano le condizioni in base alle quali le affermazioni sono vere e false. Confrontate i due scenari per identificare le condizioni mancanti. Ciò significa in genere che la risposta è incompleta: non è sbagliata, ma non menziona tutti i requisiti. Valuta se il test deve aspettarsi SATISFIABLE o se la risposta deve essere più completa.
IMPOSSIBLE I controlli automatici di ragionamento non possono valutare le affermazioni perché le premesse sono contraddittorie o la politica stessa contiene regole contrastanti. Controlla se l'input del test contiene affermazioni contraddittorie (ad esempio, «Lavoro a tempo pieno e anche a tempo parziale»). Se l'input è valido, è probabile che vi sia una contraddizione nella vostra politica: controllate il rapporto sulla qualità per verificare se ci sono regole contrastanti. Per informazioni, consulta Risolvi i problemi e perfeziona la tua politica di ragionamento automatico.
TRANSLATION_AMBIGUOUS La traduzione dal linguaggio naturale alla logica formale era ambigua. I multipli LLMs usati per la traduzione erano in disaccordo su come interpretare l'input. La scoperta include interpretazioni alternative per aiutarvi a comprendere il disaccordo. Di solito si tratta di un problema di descrizione variabile. Esamina le interpretazioni alternative per capire dove si trova il disaccordo, quindi migliora le descrizioni delle variabili pertinenti. Cause comuni: variabili sovrapposte, descrizioni vaghe o testo di input ambiguo. Per informazioni, consulta Risolvi i problemi e perfeziona la tua politica di ragionamento automatico.
TOO_COMPLEX L'input contiene troppe informazioni per consentire l'elaborazione dei controlli di ragionamento automatico entro i limiti di latenza. Semplifica l'input del test. Se il problema persiste, la tua politica potrebbe essere troppo complessa: valuta la possibilità di suddividerla in più politiche mirate o di semplificare le regole che implicano l'aritmetica non lineare.
NO_TRANSLATIONS L'input non può essere tradotto in logica formale. Ciò significa in genere che l'input non è rilevante per il dominio della policy o che la policy non ha variabili per modellare i concetti contenuti nell'input. Se l'input deve essere pertinente alla tua politica, aggiungi le variabili mancanti e aggiorna le regole. Se l'input è realmente fuori tema, questo risultato è previsto: l'applicazione dovrebbe gestire i contenuti fuori tema separatamente (ad esempio, utilizzando le politiche relative agli argomenti).

Suggerimenti per il debug in caso di test non riusciti

Quando un test fallisce (il risultato effettivo non corrisponde al risultato previsto), utilizza il seguente approccio per diagnosticare il problema:

  1. Controlla prima la traduzione. Guarda le premesse e le affermazioni contenute nel ritrovamento. Sono state assegnate le variabili giuste? I valori sono corretti? Se la traduzione è sbagliata, il problema è nelle descrizioni delle variabili, non nelle regole. Ad esempio, se «2 anni» è stato tradotto in tenureMonths = 2 anziché intenureMonths = 24, la descrizione della variabile deve specificare la conversione dell'unità.

  2. Controlla le regole. Se la traduzione sembra corretta, il problema è nelle regole della tua politica. Date un'occhiata a «supportingRulesor» contradictingRules nei risultati per identificare quali regole sono coinvolte. Confrontali con il documento sorgente.

  3. Verifica la presenza di contenuti non tradotti. Guarda untranslatedPremises e. untranslatedClaims Se parti importanti dell'input non sono state tradotte, potrebbe essere necessario aggiungere variabili per acquisire quei concetti.

  4. Controlla il punteggio di confidenza. Un punteggio di confidenza basso indica che i modelli di traduzione non sono d'accordo. Ciò suggerisce che le descrizioni delle variabili sono ambigue per questo tipo di input.

Per una guida dettagliata alla risoluzione dei problemi, vedereRisolvi i problemi e perfeziona la tua politica di ragionamento automatico.