Testar uma política de raciocínio automatizado - Amazon Bedrock
Estratégia de teste: cenários versus testes de QnAGere cenários de teste automaticamente no consoleGere cenários de teste automaticamente usando a APICrie um teste de QnA manualmente no consoleCrie um teste de QnA usando a APIExecute testesEntenda os resultados do teste

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Testar uma política de raciocínio automatizado

Os testes confirmam que as regras da sua política estão corretas e que as verificações automatizadas de raciocínio podem traduzir com precisão a linguagem natural em lógica formal. Você testa uma política enviando declarações em linguagem natural para validação e, em seguida, inspecionando o feedback para garantir que a tradução use as variáveis corretas e que as regras produzam os resultados esperados.

Há duas abordagens de teste complementares: cenários gerados e testes question-and-answer (QnA). Cada um tem como alvo uma parte diferente do pipeline de validação. O fluxo de trabalho recomendado é começar com cenários para validar a exatidão das regras e, em seguida, adicionar testes de QnA para validar a precisão da tradução.

Estratégia de teste: cenários versus testes de QnA

As verificações automatizadas de raciocínio validam o conteúdo em duas etapas: primeiro, os modelos básicos traduzem a linguagem natural em lógica formal; depois, as técnicas matemáticas verificam a lógica em relação às regras de sua política. Cada abordagem de teste tem como alvo uma etapa diferente nesse pipeline.

Cenários gerados (exatidão das regras de teste)

Os cenários gerados testam diretamente a semântica codificada em suas regras de política. Eles removem a incerteza da tradução em linguagem natural da equação, isolando se as regras em si estão corretas.

Os cenários são gerados a partir de suas regras de política e representam situações que são logicamente possíveis de acordo com essas regras. Eles são classificados para mostrar primeiro a maioria dos likely-to-be-wrong cenários. Para cada cenário, você revisa as atribuições de variáveis e decide:

  • Polegar para cima — O cenário é realista e, de fato, deveria ser possível. Salve-o como um SATISFIABLE teste.

  • Polegar para baixo — Algo está errado. O cenário não deveria ser possível devido ao seu conhecimento de domínio. Forneça feedback em linguagem natural explicando o motivo, e as verificações automatizadas de raciocínio tentarão deduzir as mudanças necessárias nas regras.

Exemplo: Sua política diz que funcionários em tempo integral com mais de 12 meses de mandato são elegíveis para licença parental. Um cenário gerado pode aparecerisFullTime = true, tenureMonths = 3, eligibleForParentalLeave = true. Se esse cenário não fosse possível (porque 3 meses é menos do que 12), você rejeitaria e explicaria que os funcionários precisam de pelo menos 12 meses de estabilidade. Isso indica uma regra ausente ou incorreta.

Use cenários como sua primeira etapa de teste. Eles ajudam você a detectar problemas de regras antes de investir tempo escrevendo testes de QnA.

Testes de QnA (precisão da tradução do teste)

Os testes de QnA validam todo o pipeline end-to-end: tradução em linguagem natural e validação de regras em conjunto. Eles imitam as interações reais do usuário e detectam problemas de tradução que os cenários não conseguem detectar.

Cada teste de QnA consiste em:

  • Uma entrada (opcional) — A pergunta que um usuário pode fazer ao seu aplicativo.

  • Uma saída — A resposta que seu modelo básico pode gerar.

  • Um resultado esperado — O resultado da validação que você espera (por exemplo, VALID ouINVALID).

Exemplo: Para a mesma política de licença parental, um teste de QnA pode ser: input = “Trabalho aqui há 2 anos em tempo integral. Posso tirar licença parental?” , output = “Sim, você está qualificado para licença parental. “, resultado esperado =VALID. Isso testa se as verificações de raciocínio automatizado traduzem corretamente “2 anos” para tenureMonths = 24 e “tempo integral” para. isFullTime = true

dica

Crie testes que cubram cenários válidos e inválidos. Por exemplo, se sua política declarar “Os funcionários precisam de 1 ano de serviço para obter licença parental”, crie testes para respostas que indiquem corretamente essa regra e testes para respostas que indiquem incorretamente um requisito diferente.

  1. Gere e analise cenários. Comece aqui para validar se suas regras estão corretas. Corrija qualquer problema de regra antes de continuar.

  2. Escreva testes de QnA para os principais casos de uso. Concentre-se nas perguntas que seus usuários têm maior probabilidade de fazer e nas respostas que seu LLM provavelmente gerará. Inclua casos extremos e condições limite.

  3. Execute todos os testes. Verifique se os cenários e os testes de QnA foram aprovados.

  4. Iterar. Se os testes falharem, determine se o problema está nas regras (corrija a política) ou na tradução (melhore as descrições das variáveis). Para obter mais informações, consulte Solucione problemas e refine sua política de raciocínio automatizado.

Gere cenários de teste automaticamente no console

  1. Acesse a política de raciocínio automatizado que você deseja testar (por exemplo, MyHrPolicy).

  2. Escolha Visualizar testes e selecione Gerar.

  3. Na caixa de diálogo Gerar cenários, revise o cenário gerado e as regras relacionadas. Cada cenário mostra um conjunto de atribuições de variáveis que são logicamente possíveis de acordo com suas regras de política. Avalie se o cenário é realista em seu domínio:

    • Se o cenário puder acontecer em seu domínio (é satisfatório), selecione o ícone de polegar para cima. Isso salva o cenário como um teste que espera um SATISFIABLE resultado.

    • Se o cenário não for possível, selecione o ícone de polegar para baixo. Forneça uma anotação explicando o motivo — por exemplo, “Os funcionários precisam de pelo menos 12 meses de estabilidade para obter a licença parental, mas esse cenário mostra 3 meses com elegibilidade”. As verificações automatizadas de raciocínio usam seu feedback para deduzir mudanças nas regras que evitariam esse cenário.

    • Se você quiser um cenário diferente, escolha Regenerar cenário.

    dica

    Para inspecionar a versão lógica formal do cenário, ative Mostrar SMT-LIB. Isso é útil para entender exatamente quais regras e atribuições de variáveis estão envolvidas.

  4. Selecione Salvar e fechar para salvar o teste ou Salvar e adicionar outro para continuar revisando os cenários.

  5. Se você forneceu anotações (feedback com polegar para baixo) em qualquer cenário, escolha Aplicar anotações. As verificações automatizadas de raciocínio iniciarão um fluxo de trabalho de criação para aplicar as alterações em sua política com base em seus comentários.

  6. Na tela Revisar alterações na política, revise as alterações propostas nas regras, variáveis e tipos de variáveis da sua política. Em seguida, selecione Aceitar alterações.

Gere cenários de teste automaticamente usando a API

Use a GetAutomatedReasoningPolicyNextScenario API para buscar cenários de teste gerados com base nas regras da sua política.

policyArn(obrigatório)

O ARN da política de raciocínio automatizado.

buildWorkflowId(obrigatório)

O identificador do fluxo de trabalho de criação para os cenários gerados. Recupere o fluxo de trabalho de compilação mais recente usando a ListAutomatedReasoningPolicyBuildWorkflows API.

Exemplo:

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

A resposta inclui um cenário gerado com atribuições de variáveis e as regras de política relacionadas. Analise o cenário e use a CreateAutomatedReasoningPolicyTestCase API para salvá-lo como um teste ou use a anotação APIs para fornecer feedback se o cenário revelar um problema de regra.

Crie um teste de QnA manualmente no console

  1. Acesse a política de raciocínio automatizado que você deseja testar (por exemplo, MyHrPolicy).

  2. Escolha Visualizar testes e selecione Adicionar.

  3. Na caixa de diálogo Adicionar testes, faça o seguinte:

    1. Em Entrada (opcional), insira a pergunta que um usuário pode fazer. Em Saída, insira a resposta que seu modelo básico pode fornecer. Juntos, eles formam um par de QnA que testa como sua política valida as interações reais do usuário.

    2. Escolha o resultado que você espera do teste (como Válido ou Inválido).

    3. (Opcional) Selecione um limite de confiança, que é o nível mínimo de confiança para validação lógica. As verificações automatizadas de raciocínio usam várias LLMs para traduzir a linguagem natural em descobertas. Ele retorna apenas descobertas apoiadas por uma porcentagem significativa das traduções do LLM. O limite de confiança define a porcentagem mínima de respaldo necessária para que uma interpretação se torne uma descoberta com um resultado válido. As descobertas abaixo do limite são apresentadas como. TRANSLATION_AMBIGUOUS

  4. Selecione Salvar para criar o teste.

Crie um teste de QnA usando a API

Use a CreateAutomatedReasoningPolicyTestCase API para criar um teste programaticamente.

policyArn(obrigatório)

O ARN da política de raciocínio automatizado.

queryContent (opcional)

A consulta ou solicitação de entrada que gerou o conteúdo, como a pergunta do usuário. Isso fornece contexto para a validação.

guardContent(obrigatório)

O conteúdo de saída a ser validado — a resposta do modelo básico que será verificada quanto à precisão.

expectedAggregatedFindingsResult (opcional)

O resultado esperado da validação (por exemplo, VALID ouINVALID). O resultado real é determinado classificando as descobertas em ordem de severidade e selecionando o pior resultado. A ordem de severidade do pior para o melhor é: TRANSLATION_AMBIGUOUSIMPOSSIBLE,INVALID,,SATISFIABLE,VALID.

confidenceThreshold (opcional)

O nível mínimo de confiança para validação lógica.

Exemplo:

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

Exemplo de resposta:

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

Execute testes

Executar testes no console

  1. Acesse a política de raciocínio automatizado que você deseja validar (por exemplo, MyHrPolicy).

  2. Selecione Visualizar itens.

  3. Execute um destes procedimentos:

    • Para executar todos os testes, escolha Validar todos os testes.

    • Para executar um único teste, selecione o botão Ação ao lado do teste e escolha Validar.

Executar testes usando a API

Use a StartAutomatedReasoningPolicyTestWorkflow API para executar testes e a GetAutomatedReasoningPolicyTestResult API para recuperar resultados.

policyArn(obrigatório)

O ARN da política de raciocínio automatizado.

buildWorkflowId(obrigatório)

O identificador do fluxo de trabalho de compilação no qual executar os testes. Recupere o fluxo de trabalho de compilação mais recente usando a ListAutomatedReasoningPolicyBuildWorkflows API.

testCaseIds (opcional)

Uma lista de identificadores de teste a serem executados. Se não for fornecido, todos os testes da política serão executados.

Exemplo:

# 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

A resposta inclui resultados de testes detalhados com resultados de validação e status de execução. Para listar todos os resultados dos testes de um fluxo de trabalho de compilação, use a ListAutomatedReasoningPolicyTestResults API.

Entenda os resultados do teste

Quando um teste termina, você recebe um conjunto de descobertas. Cada descoberta representa uma afirmação factual extraída da entrada do teste, junto com o resultado da validação, as atribuições de variáveis usadas e as regras de política que apoiam a conclusão. Para obter uma descrição detalhada da estrutura de descoberta e de todos os tipos de resultados de validação, consulteDescobertas e resultados de validação.

Anatomia do resultado de um teste

Cada resultado do teste inclui:

  • Resultado esperado — O resultado que você definiu ao criar o teste.

  • Resultado real — O resultado agregado da execução do teste. Isso é determinado classificando os resultados em ordem de gravidade e selecionando o pior resultado. A ordem de severidade do pior para o melhor é: TRANSLATION_AMBIGUOUSIMPOSSIBLE,INVALID,,SATISFIABLE,VALID. Por exemplo, um teste com duas VALID descobertas e uma IMPOSSIBLE descoberta tem um resultado agregado deIMPOSSIBLE.

  • Resultado da execução — Se o teste foi aprovado (os resultados esperados e reais coincidem) ou falhou.

  • Conclusões — Os resultados da validação individual. Cada descoberta contém as premissas e afirmações traduzidas, uma pontuação de confiança, atribuições de variáveis e as regras de política que apoiam a conclusão.

Interpretação prática dos resultados

A tabela a seguir resume o que cada resultado de validação significa na prática e qual ação tomar ao vê-lo em um teste. Para obter a referência completa, incluindo campos de busca e descrições detalhadas, consulteReferência de resultados de validação.

Resultado O que significa O que fazer
VALID As afirmações na resposta são matematicamente comprovadas como corretas, dadas as premissas e as regras de sua política. A descoberta inclui supportingRules a prova das alegações e a claimsTrueScenario demonstração de como as alegações são verdadeiras. Se esse for o resultado esperado, o teste será aprovado. Verifique se untranslatedClaims há untranslatedPremises partes da entrada que não foram validadas — um VALID resultado abrange apenas as declarações traduzidas.
INVALID As reivindicações contradizem suas regras de apólice. A descoberta inclui contradictingRules mostrar quais regras foram violadas. Se esse for o resultado esperado, o teste será aprovado. Se for inesperado, verifique se as regras estão corretas ou se a tradução atribuiu as variáveis erradas. Analise o contradictingRules para entender quais regras causaram o resultado.
SATISFIABLE As reivindicações são consistentes com sua política, mas não abordam todas as regras relevantes. A resposta está correta em algumas condições, mas não em todas. A descoberta inclui a claimsTrueScenario e a claimsFalseScenario mostrando as condições sob as quais as alegações são verdadeiras e falsas. Compare os dois cenários para identificar as condições ausentes. Isso normalmente significa que a resposta está incompleta — não está errada, mas não menciona todos os requisitos. Considere se seu teste deve ser esperado SATISFIABLE ou se a resposta deve ser mais completa.
IMPOSSIBLE As verificações automatizadas de raciocínio não podem avaliar as reivindicações porque as premissas são contraditórias ou a própria política contém regras conflitantes. Verifique se a entrada do teste contém declarações contraditórias (por exemplo, “Trabalho em período integral e também em tempo parcial”). Se a entrada for válida, é provável que haja contradição em sua política — verifique se há regras conflitantes no relatório de qualidade. Consulte Solucione problemas e refine sua política de raciocínio automatizado.
TRANSLATION_AMBIGUOUS A tradução da linguagem natural para a lógica formal foi ambígua. O múltiplo LLMs usado para tradução discordou sobre como interpretar a entrada. A descoberta inclui interpretações alternativas para ajudá-lo a entender a discordância. Geralmente, esse é um problema de descrição de variável. Analise as interpretações alternativas para entender onde está a discordância e, em seguida, melhore as descrições das variáveis relevantes. Causas comuns: variáveis sobrepostas, descrições vagas ou texto de entrada ambíguo. Consulte Solucione problemas e refine sua política de raciocínio automatizado.
TOO_COMPLEX A entrada contém muitas informações para que as verificações de raciocínio automatizado processem dentro de seus limites de latência. Simplifique a entrada do teste. Se o problema persistir, sua política pode ser muito complexa. Considere dividi-la em várias políticas focadas ou simplificar regras que envolvam aritmética não linear.
NO_TRANSLATIONS A entrada não pôde ser traduzida em lógica formal. Isso normalmente significa que a entrada não é relevante para o domínio da sua política ou que a política não tem variáveis para modelar os conceitos na entrada. Se a entrada for relevante para sua política, adicione as variáveis ausentes e atualize suas regras. Se a entrada estiver realmente fora do tópico, esse resultado é esperado — seu aplicativo deve lidar com o conteúdo fora do tópico separadamente (por exemplo, usando políticas de tópico).

Dicas de depuração para testes que falharam

Quando um teste falhar (o resultado real não corresponde ao resultado esperado), use a seguinte abordagem para diagnosticar o problema:

  1. Verifique primeiro a tradução. Veja as premissas e as reivindicações da descoberta. As variáveis corretas estão atribuídas? Os valores estão corretos? Se a tradução estiver errada, o problema está nas descrições das variáveis, não nas regras. Por exemplo, se “2 anos” foi traduzido para tenureMonths = 2 em vez detenureMonths = 24, a descrição da variável precisa especificar a conversão da unidade.

  2. Confira as regras. Se a tradução parecer correta, o problema está nas regras da sua política. Examine a supportingRules ou contradictingRules na descoberta para identificar quais regras estão envolvidas. Compare-os com seu documento de origem.

  3. Verifique se há conteúdo não traduzido. Veja untranslatedPremises untranslatedClaims e. Se partes importantes da entrada não tiverem sido traduzidas, talvez seja necessário adicionar variáveis para capturar esses conceitos.

  4. Verifique a pontuação de confiança. Uma pontuação de confiança baixa indica que os modelos de tradução discordaram. Isso sugere que as descrições das variáveis são ambíguas para esse tipo de entrada.

Para obter orientações detalhadas sobre solução de problemas, consulteSolucione problemas e refine sua política de raciocínio automatizado.