O problema que a AWS resolveu
Quem já trabalhou com políticas de Automated Reasoning checks (Verificações de Raciocínio Automatizado) no Amazon Bedrock Guardrails sabe que o maior atrito no processo não é criar a política — é afinar ela. O ciclo de diagnosticar falhas, editar regras manualmente, retestar e repetir consumia tempo considerável de especialistas. A AWS anunciou o refinamento automático de políticas, que automatiza justamente a parte de diagnóstico e correção desse ciclo.
Vale lembrar o que são os Automated Reasoning checks: eles traduzem linguagem natural para lógica formal e aplicam técnicas de verificação automatizada para produzir um resultado — VALID, INVALID, SATISFIABLE, IMPOSSIBLE ou TRANSLATION_AMBIGUOUS. Em traduções sem ambiguidade, o recurso entrega até 99% de precisão de verificação, conforme reportado no anúncio de disponibilidade geral.
O pipeline de dois passos que explica tudo
Para entender o refinamento, é preciso ter clareza sobre como uma política funciona internamente. O processo tem dois passos sequenciais:
- Passo de tradução: o texto em linguagem natural (entrada e saída) é mapeado para atribuições de variáveis, usando as descrições de variáveis definidas na política.
- Passo de validação: as regras formais da política são aplicadas sobre essas atribuições para chegar a um resultado final.
Quando um teste falha, o problema está em um desses dois passos. É exatamente por isso que o refinamento automático oferece dois modos distintos, cada um mirando uma etapa diferente do pipeline.
Os dois tipos de falha — e como identificá-los
Falha tipo 1: problema nas regras (a lógica está errada)
Nesse cenário, a tradução funcionou corretamente — as variáveis certas receberam os valores certos — mas o resultado da validação não corresponde ao esperado. O problema está nas regras: alguma está permissiva demais, restritiva demais ou simplesmente ausente. O modelo entendeu a pergunta perfeitamente, mas aplicou a lógica errada.
Falha tipo 2: tradução ambígua (a linguagem está errada)
Quando um teste retorna TRANSLATION_AMBIGUOUS, significa que o motor de validação chegou a resultados diferentes dependendo de qual interpretação seguiu. As causas mais comuns incluem variáveis com definições sobrepostas (por exemplo, “tempo de serviço” e “meses de emprego” descrevendo o mesmo conceito), descrições vagas, formatos de valor inconsistentes (5 versus 0,05 para representar “5%”) e nomes de variáveis que já embutem negações, o que confunde os modelos de tradução.
Modo 1: Refinamento Iterativo — corrigindo as regras
O Refinamento Iterativo (ITERATIVELY_REFINE_POLICY) é indicado quando a tradução está correta, mas o resultado da validação não bate com o esperado. Antes desse recurso, corrigir uma política com 10 a 30 regras exigia que um especialista rastreasse cada regra manualmente, formulasse hipóteses e editasse lógica formal SMT-LIB à mão. Esse trabalho agora se resume a uma etapa de revisão e aprovação.
Como funciona
O motor recebe três entradas: a definição atual da política (regras, variáveis e tipos), um documento-fonte com o texto autoritativo em linguagem natural, e — opcionalmente — um feedback em linguagem natural descrevendo explicitamente o que deve mudar. Por exemplo: “Atualize o requisito de tempo de serviço para licença parental de 12 para 6 meses, conforme a seção 3 do documento revisado.”
Internamente, o motor gera uma proposta de mudança, simula o efeito sobre os testes salvos, verifica se os testes que falhavam agora passam e ajusta caso necessário. Esse ciclo acontece de forma transparente — o que o usuário recebe é o resultado convergido: um diff mostrando exatamente quais regras e variáveis foram alteradas e como cada teste é afetado.
Fluxo via API (Boto3)
O refinamento é executado como um fluxo assíncrono. O processo tem quatro etapas: exportar a definição atual da política, iniciar o fluxo, aguardar a conclusão e recuperar as mudanças propostas.
import boto3
bedrock = boto3.client("bedrock")
# Export the current policy definition (required input to the workflow).
policy_definition = bedrock.export_automated_reasoning_policy_version(
policyArn=policy_arn,
)["policyDefinition"]
with open("hr-leave-policy.pdf", "rb") as f:
source_document = f.read()
response = bedrock.start_automated_reasoning_policy_build_workflow(
policyArn=policy_arn,
buildWorkflowType="ITERATIVELY_REFINE_POLICY",
sourceContent={
"policyDefinition": policy_definition,
"workflowContent": {
"iterativeRefinementContent": {
"documents": [
{
"document": source_document,
"documentName": "hr-leave-policy.pdf",
"documentContentType": "pdf",
}
],
"feedback": "Update the tenure requirement from 12 to 6 months per section 3.",
}
},
},
)
build_workflow_id = response["buildWorkflowId"]A chamada retorna imediatamente com um buildWorkflowId. O fluxo passa pelos estados SCHEDULED → BUILDING até atingir COMPLETED, FAILED ou CANCELLED. A convergência leva tipicamente de um a alguns minutos, dependendo do tamanho da política.
import time
while True:
workflow = bedrock.get_automated_reasoning_policy_build_workflow(
policyArn=policy_arn,
buildWorkflowId=build_workflow_id,
)
status = workflow["status"]
if status in ("COMPLETED", "FAILED", "CANCELLED"):
break
time.sleep(10)
if status == "COMPLETED":
assets = bedrock.get_automated_reasoning_policy_build_workflow_result_assets(
policyArn=policy_arn,
buildWorkflowId=build_workflow_id,
assetType="POLICY_DEFINITION",
)
proposed_definition = assets["buildWorkflowAssets"]["policyDefinition"]A definição retornada é o DRAFT proposto. Para confirmar as mudanças, basta chamar update_automated_reasoning_policy com essa definição. Para ver o que mudou, compare com a definição exportada antes de iniciar o fluxo.
Modo 2: Refinamento de Variáveis Ambíguas — corrigindo a linguagem
Quando os testes retornam TRANSLATION_AMBIGUOUS, nenhuma quantidade de edição de regras vai resolver o problema — a raiz está na linguagem usada para descrever as variáveis. O Refinamento de Variáveis Ambíguas (RESOLVE_POLICY_AMBIGUITIES) identifica quais descrições de variáveis causam interpretações conflitantes e propõe definições mais precisas.
O que ele corrige
O modo detecta padrões como variáveis sobrepostas (duas variáveis descrevendo o mesmo conceito), descrições incompletas ou vagas, formatos de valor inconsistentes e nomes de variáveis que embutem negações. Quando variáveis sobrepostas são detectadas, pode ser proposta uma fusão: uma variável é eliminada e as regras que a referenciavam são atualizadas para usar a variável sobrevivente.
Um exemplo típico de proposta antes/depois:
- Antes:
tenureMonths: “How long the employee has worked in months.” - Depois (proposto):
tenureMonths: “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). This variable captures references to employment duration, length of service, time at the company, or seniority.”
Fluxo via API
O padrão assíncrono é o mesmo do Refinamento Iterativo. A diferença é que esse modo analisa as variáveis da política diretamente e não exige documento-fonte nem testes anexados — apenas a definição atual da política em sourceContent.
response = bedrock.start_automated_reasoning_policy_build_workflow(
policyArn=policy_arn,
buildWorkflowType="RESOLVE_POLICY_AMBIGUITIES",
sourceContent={
"policyDefinition": policy_definition,
},
)
build_workflow_id = response["buildWorkflowId"]O polling e a recuperação dos resultados seguem exatamente o mesmo padrão mostrado para o Refinamento Iterativo, usando assetType="POLICY_DEFINITION".
O princípio inegociável: aprovação humana em todas as mudanças
Os dois modos compartilham uma propriedade fundamental: nenhuma alteração entra em vigor sem aprovação explícita. O motor de refinamento tem autoridade para sugerir. O usuário tem autoridade para confirmar. Nenhuma mudança chega à política DRAFT — muito menos à produção — sem que o responsável aceite a proposta.
A tela de revisão mostra simultaneamente o diff das mudanças propostas (regras adicionadas, editadas ou removidas; variáveis alteradas; tipos de variáveis customizados modificados) e o impacto de cada mudança sobre todos os testes salvos. Se os testes que falhavam agora passam e os que passavam continuam passando, a proposta pode ser aceita com confiança.
Walkthrough A: corrigindo um problema de regra
Considere uma política de elegibilidade de licença parental de RH com um teste falhando. O assistente informa que um funcionário em regime de meio período com 8 meses de tempo de serviço é elegível para licença parental. O teste espera INVALID, mas a política retorna VALID.
Ao inspecionar o resultado do teste, as variáveis estão corretamente capturadas: monthsOfContinuousService = 8 e employmentStatus = PART_TIME. O resultado é VALID porque a única regra de suporte concede elegibilidade após 6 meses de serviço contínuo, sem nenhuma regra que exclua funcionários de meio período. A tradução está correta — o problema é de lógica.
Ao acionar o Refinamento Iterativo com o documento-fonte e o feedback “Add a rule that explicitly makes part-time employees ineligible for parental leave”, o motor propõe duas mudanças: remove a regra que concedia elegibilidade apenas por tempo de serviço e adiciona uma regra que exclui funcionários de meio período. O teste que falhava passa a ser aprovado, sem regressões nos demais.
Walkthrough B: corrigindo um problema de linguagem
Na mesma política de RH, um teste retorna TRANSLATION_AMBIGUOUS. O resultado mostra duas interpretações: uma mapeou “2 anos de serviço” para tenureMonths = 24 e outra para monthsOfService = 24. Duas variáveis descrevem o mesmo conceito — essa sobreposição é a raiz da ambiguidade.
O Refinamento de Variáveis Ambíguas não exige documento-fonte. Ao ser acionado, ele propõe eliminar monthsOfService, atualizar as regras que a referenciavam para usar tenureMonths e expandir a descrição dessa variável para incluir instruções explícitas de conversão e sinônimos. Após aceitar a proposta, o teste que retornava TRANSLATION_AMBIGUOUS passa a produzir um resultado definitivo.
Validando com o Relatório de Fidelidade
Após aplicar qualquer refinamento, a AWS recomenda gerar um Relatório de Fidelidade (GENERATE_FIDELITY_REPORT) para verificar se a política atualizada ainda representa fielmente o documento-fonte. O relatório fornece três métricas: pontuação de cobertura (0,0–1,0), pontuação de precisão (0,0–1,0) e ancoragem por regra, que vincula cada regra às declarações específicas do documento que a sustentam. Comparar os relatórios antes e depois do refinamento é a forma mais confiável de detectar se uma correção fez a política se desviar da intenção original.
Boas práticas
- Inspecione a tradução antes de escolher o modo. Abra o resultado do teste falhando e verifique as atribuições de variáveis. Se as variáveis certas têm os valores certos mas o resultado está errado, use Refinamento Iterativo. Se as atribuições estão erradas ou o resultado é TRANSLATION_AMBIGUOUS, use Refinamento de Variáveis Ambíguas.
- Delimite os inputs para limitar o escopo da mudança. Um documento-fonte focado em uma parte específica da política, combinado com feedback objetivo em formato “se-então”, produz propostas mais precisas e revisáveis do que apontar o motor para um manual de 40 páginas com instruções vagas.
- Confie no painel de resultados de testes, não apenas no diff. Um diff aparentemente limpo que causa regressão em testes que passavam não é uma correção válida.
- Compare Relatórios de Fidelidade antes de versionar. O refinamento otimiza para fazer testes passarem — essa otimização pode distanciar uma regra do que o documento-fonte realmente diz.
Casos de uso em setores regulados
A AWS destaca aplicações práticas em múltiplos setores: em RH, manuais de benefícios atualizados anualmente podem ser ingeridos pelo Refinamento Iterativo para propor atualizações de regras sem que o time precise tocar em lógica formal. Em serviços financeiros, variáveis sobrepostas como debtToIncomeRatio e DTI são consolidadas pelo Refinamento de Variáveis Ambíguas para suportar validação determinística. Em saúde e manufatura, equipes de conformidade podem refinar políticas iterativamente mantendo trilha de auditoria completa por meio de snapshots versionados e Relatórios de Fidelidade.
Recursos adicionais
- Documentação: documentação de Automated Reasoning checks
- Guia prático: Como minimizar alucinações de IA generativa com Automated Reasoning checks
- Chatbot com reescrita iterativa: implementação de referência do chatbot com Automated Reasoning checks e código de exemplo no GitHub
- Agente de formalização de políticas: exemplo open-source de agente que guia especialistas pelo processo em linguagem natural
- Exemplos de código: exemplos de Automated Reasoning checks no GitHub
- Resultados de clientes: caso Amazon Logistics | caso PitCrew | caso PwC Responsible AI in Education | recursos de IA Responsável da AWS
- Funcionalidades relacionadas: Amazon Bedrock Guardrails | Amazon Bedrock AgentCore
- Orientações de IA responsável: AWS Well-Architected Responsible AI Lens
Fonte
Automated Reasoning policy refinement in Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/automated-reasoning-policy-refinement-in-amazon-bedrock/)
Leave a Reply