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

Solucione problemas e refine sua política de raciocínio automatizado

Quando um teste de política de raciocínio automatizado falha — o resultado real não corresponde ao resultado esperado — o problema está na tradução (a linguagem natural foi mapeada para as variáveis ou valores errados) ou nas regras (a lógica da política não corresponde ao seu domínio). Esta página fornece uma abordagem sistemática para diagnosticar e corrigir os dois tipos de problemas.

Antes de começar a solucionar problemas, certifique-se de compreender o processo de validação em duas etapas (traduzir e depois validar) descrito em. Tradução: da linguagem natural à lógica formal Essa distinção é a chave para uma depuração eficiente.

Fluxo de trabalho de depuração

Quando um teste falhar, use o resultado real para identificar o tipo de problema e vá para a seção relevante.

Corrigir problemas de tradução

Problemas de tradução ocorrem quando as verificações de raciocínio automatizado não conseguem mapear de forma confiável a linguagem natural para as variáveis da sua política. O sintoma mais visível é um TRANSLATION_AMBIGUOUS resultado, mas problemas de tradução também podem causar SATISFIABLE resultados incorretos VALID ou quando variáveis ou valores errados são atribuídos. INVALID

Diagnosticar resultados de TRANSLATION_AMBIGUOUS

Uma TRANSLATION_AMBIGUOUS descoberta inclui dois campos principais que ajudam você a entender a discordância:

Examine esses campos para identificar a fonte específica de ambigüidade e, em seguida, aplique a correção apropriada da lista a seguir.

Definições de variáveis sobrepostas

Quando várias variáveis poderiam representar razoavelmente o mesmo conceito, os modelos de tradução discordam sobre qual delas usar.

Sintoma: A options TRANSLATION_AMBIGUOUS descoberta mostra o mesmo conceito atribuído a diferentes variáveis. Por exemplo, uma opção atribui “2 anos de serviço” a, tenureMonths = 24 enquanto a outra atribui a. monthsOfService = 24

Correção: mescle as variáveis sobrepostas em uma única variável com uma descrição abrangente. Atualize todas as regras que fazem referência à variável excluída para usar a restante.

Exemplo:

Descrições incompletas de variáveis

As descrições de variáveis que não têm detalhes sobre como os usuários se referem aos conceitos na linguagem cotidiana dificultam o mapeamento da entrada para a variável correta.

Sintoma: options Mostra a variável correta, mas com valores diferentes, ou a tradução atribui um valor que não corresponde ao que o usuário disse. Por exemplo, “2 anos” é traduzido para tenureMonths = 2 em vez detenureMonths = 24.

Correção: atualize a descrição da variável para incluir regras de conversão de unidades, sinônimos e frases alternativas. Consulte Escreva descrições abrangentes de variáveis para obter orientações detalhadas.

Exemplo:

Formatação de valores inconsistente

A ambiguidade da tradução pode ocorrer quando o sistema não tem certeza de como formatar valores como números, datas ou porcentagens.

Sintoma: options Mostram a mesma variável, mas com formatos de valor diferentes. Por exemplo, uma opção traduz "5%" para interestRate = 5 enquanto a outra traduz para. interestRate = 0.05

Correção: atualize a descrição da variável para especificar o formato esperado e incluir regras de conversão. Consulte Especifique unidades e formatos em descrições de variáveis.

Texto de entrada ambíguo

Às vezes, a entrada em si é genuinamente ambígua — ela contém pronomes vagos, referências pouco claras ou declarações que podem ser interpretadas de várias maneiras.

Sintoma: Eles options mostram interpretações fundamentalmente diferentes do mesmo texto. Por exemplo, “Eles podem se despedir?” pode se referir a qualquer tipo de funcionário.

Correção: se for um teste, reescreva a entrada para ser mais específica. Em tempo de execução, seu aplicativo deve pedir esclarecimentos ao usuário quando receber um TRANSLATION_AMBIGUOUS resultado. Para padrões de integração, consulteIntegre verificações automatizadas de raciocínio em seu aplicativo.

Ajuste o limite de confiança

Se você ver TRANSLATION_AMBIGUOUS resultados de entradas que são quase ambíguas, você pode ajustar o limite de confiança. Reduzir o limite permite que traduções com menos concordância do modelo prossigam com a validação, reduzindo TRANSLATION_AMBIGUOUS os resultados, mas aumentando o risco de traduções incorretas.

Corrigir problemas de regras

Problemas de regras ocorrem quando a tradução está correta, mas a lógica da política não corresponde ao seu domínio. Você confirmou que as variáveis certas foram atribuídas com os valores corretos, mas o resultado da validação ainda está errado.

Obtendo VALID quando você esperava INVALID

A política não tem uma regra que proíba a reclamação. A resposta contradiz seu conhecimento de domínio, mas a política permite isso.

Diagnóstico: veja a supportingRules descoberta. Essas são as regras que provam que a alegação é válida. Verifique se essas regras estão corretas ou se uma regra está ausente.

Causas e correções comuns:

Ficando INVÁLIDO quando você esperava VÁLIDO

A política tem uma regra que proíbe incorretamente a reclamação.

Diagnóstico: veja a contradictingRules descoberta. Essas são as regras que refutam a alegação. Verifique se essas regras estão corretas.

Causas e correções comuns:

Ficando SATISFÁVEL quando você esperava VÁLIDO

A resposta está correta em algumas condições, mas não em todas. A política tem regras adicionais que a resposta não aborda.

Diagnóstico: compare a claimsTrueScenario e claimsFalseScenario na descoberta. A diferença entre eles mostra as condições que a resposta não menciona.

Causas e correções comuns:

Corrija resultados impossíveis

Um IMPOSSIBLE resultado significa que 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. Há duas causas distintas.

Contradições na entrada

A entrada do teste contém declarações que se contradizem. Por exemplo, “Sou funcionário em tempo integral e também em tempo parcial” define isFullTime = true e isFullTime = false simultaneamente, o que é logicamente impossível.

Diagnóstico: Inspecione as translation instalações da descoberta. Procure variáveis às quais sejam atribuídos valores contraditórios.

Correção: se for um teste, reescreva a entrada para remover a contradição. Em tempo de execução, seu aplicativo deve lidar com IMPOSSIBLE os resultados solicitando que o usuário esclareça suas informações.

Conflitos na política

A política contém regras que se contradizem, impossibilitando que as verificações de raciocínio automatizado cheguem a uma conclusão sobre entradas que envolvam regras conflitantes.

Diagnóstico: Se a entrada for válida (sem premissas contraditórias), o problema está na política. Verifique o contradictingRules campo na descoberta para identificar quais regras estão em conflito. Verifique também o relatório de qualidade (consulteUse o relatório de qualidade) — ele sinaliza regras conflitantes automaticamente.

Causas e correções comuns:

Use anotações para reparar sua apólice

As anotações são correções direcionadas que você aplica à sua política quando os testes falham. Em vez de editar regras e variáveis manualmente, você pode usar anotações para descrever a alteração desejada e permitir que as verificações de raciocínio automatizado a apliquem. As anotações estão disponíveis por meio do console e da API.

Aplique anotações no console

Aplique anotações usando a API

Use a StartAutomatedReasoningPolicyBuildWorkflow API com REFINE_POLICY para aplicar anotações programaticamente. Passe a definição completa da política atual junto com as anotações.

Os tipos de anotação incluem:

Exemplo: adicione uma variável e uma regra ausentes usando anotações

aws bedrock start-automated-reasoning-policy-build-workflow \
  --policy-arn "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk" \
  --build-workflow-type REFINE_POLICY \
  --source-content "{
    \"policyDefinition\": EXISTING_POLICY_DEFINITION_JSON,
    \"workflowContent\": {
      \"policyRepairAssets\": {
        \"annotations\": [
          {
            \"addVariable\": {
              \"name\": \"tenureMonths\",
              \"type\": \"int\",
              \"description\": \"The number of complete months the employee has been continuously employed. When users mention years of service, convert to months (for example, 2 years = 24 months).\"
            }
          },
          {
            \"addRuleFromNaturalLanguage\": {
              \"naturalLanguage\": \"If an employee is full-time and has more than 12 months of tenure, then they are eligible for parental leave.\"
            }
          }
        ]
      }
    }
  }"

Exemplos de anotações

Exemplo 1: Corrigir um requisito de posse ausente

Problema: a política aprova a licença parental para todos os funcionários em tempo integral, mas o documento fonte exige mais de 12 meses de permanência.

Exemplo 2: Corrigir variáveis sobrepostas que causam TRANSLATION_AMBIGUOUS

Problema: Duas variáveis (tenureMonthsemonthsOfService) representam o mesmo conceito, causando traduções inconsistentes.

Anotações:

Exemplo 3: Corrigir uma afirmação simples que causa resultados IMPOSSÍVEIS

Problema: a regra (= eligibleForParentalLeave true) é uma afirmação simples que impossibilita que qualquer entrada afirme que o usuário não é elegível.

Anotações:

Use o relatório de qualidade

O relatório de qualidade é gerado após cada fluxo de trabalho de construção e identifica problemas estruturais em sua política que podem causar falhas no teste. No console, os problemas do relatório de qualidade aparecem como avisos na página Definições. Por meio da API, use GetAutomatedReasoningPolicyBuildWorkflowResultAssets com--asset-type QUALITY_REPORT.

O relatório de qualidade sinaliza os seguintes problemas:

Regras conflitantes

Duas ou mais regras chegam a conclusões contraditórias para o mesmo conjunto de condições. Regras conflitantes fazem com que sua política retorne IMPOSSIBLE para todas as solicitações de validação que envolvam as regras conflitantes.

Exemplo: a regra A diz (=> isFullTime eligibleForLeave) e a regra B diz(=> (<= tenureMonths 6) (not eligibleForLeave)). Para um funcionário em tempo integral com 3 meses de mandato, a Regra A diz elegível e a Regra B diz que não é elegível — uma contradição.

Correção: mescle as regras em uma única regra com condições explícitas:. (=> (and isFullTime (> tenureMonths 6)) eligibleForLeave) Ou exclua uma das regras conflitantes se ela tiver sido extraída incorretamente.

Variáveis não utilizadas

Variáveis que não são referenciadas por nenhuma regra. Variáveis não utilizadas adicionam ruído ao processo de tradução e podem causar TRANSLATION_AMBIGUOUS resultados quando competem com variáveis ativas semelhantes pelo mesmo conceito.

Correção: exclua variáveis não utilizadas, a menos que você planeje adicionar regras que façam referência a elas em uma iteração futura.

Valores de tipo não utilizados

Valores em um tipo personalizado (enum) que não são referenciados por nenhuma regra. Por exemplo, se sua LeaveType enumeração tiver valores PARENTAL, MEDICAL, BEREAVEMENT e PERSONAL, mas nenhuma regra fizer referência a PERSONAL, ela será marcada como não usada.

Correção: adicione regras que façam referência ao valor não utilizado ou remova-o da enumeração. Valores não utilizados podem causar problemas de tradução se a entrada mencionar o conceito, mas nenhuma regra o tratar.

Conjuntos de regras disjuntos

Grupos de regras que não compartilham nenhuma variável. Conjuntos de regras não são necessariamente um problema — sua apólice pode abranger intencionalmente tópicos independentes (por exemplo, elegibilidade de licença e reembolso de despesas). No entanto, eles podem indicar que as variáveis não têm conexões entre regras relacionadas.

Quando agir: Se os conjuntos de regras separados precisarem estar relacionados (por exemplo, ambos tratam dos benefícios dos funcionários, mas usam nomes de variáveis diferentes para o mesmo conceito), mescle as variáveis sobrepostas para conectá-las. Se os conjuntos de regras forem genuinamente independentes, nenhuma ação será necessária.

Use o Kiro CLI para refinamento de políticas

O Kiro CLI fornece uma interface de bate-papo interativa para diagnosticar e corrigir problemas de política. Ele pode carregar sua definição de política e relatório de qualidade, explicar por que os testes estão falhando, sugerir alterações e aplicar anotações — tudo por meio de conversas em linguagem natural.

O Kiro CLI é particularmente útil para:

Exemplo de fluxo de trabalho:

You: The test with ID test-12345 is not returning the expected result.
     Can you load the test definition and findings, look at the policy
     definition, and explain why this test is failing?

Kiro: [analyzes the test and policy] The test expects VALID but gets
      INVALID because rule R3 requires 24 months of tenure, while the
      test input specifies 18 months. The source document says 12 months.
      Rule R3 appears to have been misextracted.

You: Can you suggest changes to fix this?

Kiro: I suggest updating rule R3 to change the tenure threshold from 24
      to 12 months. Here's the updated rule: ...

You: Looks good. Can you use the annotation APIs to submit these changes?

Kiro: [applies annotations via the API]

Para obter instruções completas sobre como configurar e usar a CLI do Kiro com políticas de raciocínio automatizado, consulte. Use o Kiro CLI com uma política de raciocínio automatizado