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

Melhores práticas da política de raciocínio automatizado

Esta página consolida as melhores práticas para criar e manter políticas de raciocínio automatizado. Leia isso antes de criar sua primeira política e consulte-a ao depurar problemas. Para obter os fundamentos conceituais por trás dessas práticas, consulteO raciocínio automatizado verifica conceitos. Para obter instruções de step-by-step criação, consulteCriar uma política de raciocínio automatizado.

Comece de forma simples e repita

O erro mais comum ao criar uma política de raciocínio automatizado é tentar capturar um documento complexo inteiro em uma única passagem. Em vez disso, comece com um subconjunto focado de suas regras e construa de forma incremental.

Essa abordagem tem duas vantagens: facilita o isolamento dos problemas (você sabe qual seção introduziu um problema) e mantém a política gerenciável durante o desenvolvimento. Uma política com 10 regras bem testadas é mais útil do que uma com 100 regras não testadas.

Pré-processe documentos com um LLM

Para documentos que são longos, contêm prosa narrativa ou combinam regras com conteúdo não normativo (como avisos legais ou histórico organizacional), execute o documento por meio de um LLM antes de enviá-lo para verificações de raciocínio automatizado. Peça ao LLM que extraia o conteúdo como regras explícitas do tipo “se então”. Essa etapa de pré-processamento melhora significativamente a qualidade da política extraída porque as verificações de raciocínio automatizado funcionam melhor com declarações claras e declarativas do que com texto não estruturado.

Ao escrever sua solicitação de pré-processamento, inclua as seguintes instruções para o LLM:

Para obter modelos de solicitação detalhados e um fluxo step-by-step de trabalho de pré-processamento, consulte(Opcional) Use um LLM para reescrever documentos como regras lógicas.

Use implicações (=>) para estruturar regras

O formato if-then (usando o operador de => implicação) é o padrão de redação de regras mais importante. Toda regra que expressa uma relação condicional deve usar esse formato.

Afirmações simples (regras sem uma estrutura if-then) criam axiomas — afirmações que são sempre verdadeiras. A afirmação eligibleForParentalLeave diz que o Automated Reasoning verifica se a elegibilidade da licença parental é sempre verdadeira, independentemente de quaisquer condições. Qualquer entrada que diga que o usuário não é elegível retornaria IMPOSSIBLE porque contradiz esse axioma.

As afirmações simples são apropriadas somente para condições de limite que sempre devem ser válidas, como:

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

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

Se você encontrar afirmações vazias na política extraída, reescreva-as como condicionais ou exclua-as. Para obter mais informações sobre como revisar sua política extraída, consulte. Revise a política extraída

Escreva descrições abrangentes de variáveis

As descrições das variáveis são o principal fator na precisão da tradução. Quando as verificações de raciocínio automatizado traduzem a linguagem natural em lógica formal, elas usam descrições de variáveis para determinar quais variáveis correspondem aos conceitos mencionados no texto. Descrições vagas ou incompletas são a principal causa dos TRANSLATION_AMBIGUOUS resultados.

Uma boa descrição da variável deve responder a quatro perguntas:

Exemplo: antes e depois

Use booleanos para estados não exclusivos

Ao modelar estados que podem coexistir, use variáveis booleanas separadas em vez de uma única enumeração. Uma pessoa pode ser veterana e professora. Usar um enum customerType = {VETERAN, TEACHER} força a escolha entre eles, criando uma contradição lógica quando ambos se aplicam.

Reserve enums para categorias verdadeiramente mutuamente exclusivas, nas quais somente um valor pode ser aplicado por vez, como leaveType = {PARENTAL, MEDICAL, BEREAVEMENT} (um funcionário só pode solicitar um tipo de licença por vez). Para obter mais informações sobre tipos personalizados, consulteTipos personalizados (enums).

Especifique unidades e formatos em descrições de variáveis

A ambigüidade sobre as unidades é uma fonte comum de erros de tradução. Se um usuário disser “Trabalho aqui há 2 anos” e sua variável fortenureMonths, a tradução precisa saber como converter anos em meses. Se a descrição da variável não especificar a unidade, a tradução poderá atribuir tenureMonths = 2 em vez detenureMonths = 24.

Sempre especifique:

Exemplos:

Validar intervalos para valores numéricos

Para variáveis numéricas, adicione regras de limite que restrinjam o intervalo válido. Isso evita cenários logicamente impossíveis e ajuda as verificações automatizadas de raciocínio a produzir resultados mais significativos.

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

Sem essas regras de limite, as verificações de raciocínio automatizado podem considerar cenários com saldos de conta negativos ou pontuações de crédito acima de 1000, que não têm sentido em seu domínio. As regras de limite são um dos poucos casos em que afirmações simples (regras que não estão no formato if-then) são apropriadas.

Use variáveis intermediárias para abstração

Quando várias regras compartilham uma condição comum, extraia essa condição em uma variável booleana intermediária. Isso simplifica suas regras e facilita a manutenção da política.

Exemplo: níveis de associação

Em vez de repetir a condição de associação em todas as regras de benefícios:

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

Defina uma variável intermediária e faça referência a ela:

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

Esse padrão facilita a atualização posterior dos critérios de associação — você só precisa alterar uma regra em vez de três.

Use enums para categorização

Quando uma variável representa uma categoria com um conjunto fixo de valores mutuamente exclusivos, use um tipo personalizado (enum) em vez de vários booleanos ou uma string. Os enums restringem os valores possíveis e tornam as regras mais claras.

Mantenha a lógica declarativa, não processual

As políticas de raciocínio automatizado descrevem o que é verdade, não como computá-la. Evite escrever regras que pareçam código com etapas sequenciais ou lógica de precedência.

Da mesma forma, evite codificar precedência ou prioridade entre as regras. Na lógica formal, todas as regras se aplicam simultaneamente. Se você precisar expressar que uma condição substitui outra, codifique-a explicitamente nas condições da regra:

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

Convenções de nomenclatura

A nomenclatura consistente facilita a leitura, a manutenção e a depuração das políticas. Siga estas convenções:

Evite abreviações que possam ser ambíguas. Use tenureMonths em vez tenMo de e isFullTime em vez deft. Nomes claros ajudam tanto os revisores humanos quanto o processo de tradução.

Antipadrões comuns

Os padrões a seguir frequentemente causam problemas nas políticas de raciocínio automatizado. Se você encontrar resultados de teste inesperados, verifique se sua política contém algum desses antipadrões.

Axiomas em vez de implicações

Conforme descrito emUse implicações (=>) para estruturar regras, afirmações simples criam axiomas que são sempre verdadeiros. Esse é o antipadrão mais comum e o mais prejudicial — ele faz com que categorias inteiras de entradas retornem. IMPOSSIBLE

Sintoma: testes que deveriam retornar VALID ou INVALID retornar IMPOSSIBLE em vez disso.

Correção: encontre afirmações simples em suas regras e reescreva-as como implicações ou exclua-as se elas não representarem condições de limite.

Variáveis sobrepostas

Ter duas variáveis que representam conceitos iguais ou similares (por exemplo, tenureMonths emonthsOfService) confunde o processo de tradução. As verificações automatizadas de raciocínio não podem determinar qual variável usar para um determinado conceito, levando a traduções e TRANSLATION_AMBIGUOUS resultados inconsistentes.

Sintoma: os testes retornam TRANSLATION_AMBIGUOUS mesmo com texto de entrada claro e inequívoco.

Correção: mescle 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.

Políticas excessivamente complexas

Políticas com muitas variáveis, condições profundamente aninhadas ou aritmética não linear podem exceder os limites de processamento e retornar resultados. TOO_COMPLEX

Sintoma: os testes retornam TOO_COMPLEX ou expiram.

Correção: simplifique a política. Remova variáveis não utilizadas, divida regras complexas em regras mais simples usando variáveis intermediárias e evite aritmética não linear (expoentes, números irracionais). Se seu domínio for realmente complexo, considere dividi-lo em várias políticas focadas.

Regras contraditórias

Regras que se contradizem impossibilitam que as verificações automatizadas de raciocínio cheguem a uma conclusão. Por exemplo, uma regra diz que funcionários em tempo integral são elegíveis para licença, enquanto outra diz que funcionários no primeiro ano não são elegíveis, sem especificar o que acontece com funcionários em tempo integral no primeiro ano.

Sintoma: Os testes retornam IMPOSSIBLE para entradas que envolvem regras conflitantes.

Correção: verifique se há regras conflitantes no relatório de qualidade. Resolva conflitos mesclando as regras em uma única regra com condições explícitas ou excluindo uma das regras conflitantes. Para obter mais informações, consulte Revise a política extraída.

Variáveis não utilizadas

Variáveis que não são referenciadas por nenhuma regra adicionam ruído ao processo de tradução. A tradução pode atribuir valores a variáveis não utilizadas, desperdiçando capacidade de processamento e potencialmente causando TRANSLATION_AMBIGUOUS resultados quando a variável não utilizada compete com uma variável ativa similar.

Sintoma: TRANSLATION_AMBIGUOUS resultados inesperados ou traduções que atribuem valores a variáveis que não afetam nenhuma regra.

Correção: exclua variáveis não utilizadas. No console, procure indicadores de aviso ao lado das variáveis. Por meio da API, verifique o relatório de qualidade em GetAutomatedReasoningPolicyBuildWorkflowResultAssets com--asset-type QUALITY_REPORT.

Valores de enumeração ausentes

Se sua enumeração não incluir um valor para cada categoria possível que os usuários possam mencionar, a tradução poderá falhar ou produzir resultados inesperados quando a entrada não corresponder a nenhum valor definido.

Sintoma: Os testes retornam TRANSLATION_AMBIGUOUS ou NO_TRANSLATIONS quando a entrada menciona uma categoria que não está na enumeração.

Correção: adicione um NONE valor OTHER ou à sua enumeração para lidar com entradas que não correspondem às categorias definidas. Atualize as descrições dos valores de enumeração para esclarecer quando cada valor se aplica.