Para testar conectivos lógicos em modelos de IA, transforme cada regra em uma expressão formal, enumere as combinações possíveis de verdadeiro e falso e compare a resposta do sistema com um gabarito calculado fora dele. Separe a interpretação da frase do cálculo lógico: um modelo pode entender a regra e errar a operação, ou calcular corretamente uma tradução equivocada.
Esse teste serve para homologar assistentes que leem critérios de cadastro, políticas de atendimento e condições operacionais. Ele não demonstra uma capacidade geral de raciocínio. Mostra, dentro de um conjunto documentado de casos, se o sistema preserva relações como “e”, “ou”, “não” e “se… então”. O roteiro abaixo é uma proposta de avaliação que a equipe pode adaptar ao próprio processo.
Resumo rápido
- Defina se o “ou” é inclusivo ou exclusivo antes de montar o gabarito.
- Com duas variáveis booleanas, teste as quatro combinações possíveis.
- Não confunda uma condição suficiente com uma condição necessária.
- Registre separadamente erros de interpretação, cálculo e formato.
- Use regras determinísticas para decidir operações quando a regra já estiver formalizada.
1. Defina o que a avaliação realmente mede
Comece com uma tarefa estreita. “Avaliar lógica” é amplo demais. Uma especificação útil seria: dado um enunciado com duas condições e seus valores, responder se a expressão é verdadeira, usando os conectivos definidos no enunciado. Outra tarefa seria extrair a expressão de um regulamento. Misturar as duas impede descobrir onde ocorreu a falha.
Crie duas trilhas. Na trilha simbólica, o modelo recebe P ∧ Q e os valores de P e Q. Na trilha textual, recebe “o pedido está pago e foi separado”. A primeira verifica aplicação de uma definição explícita; a segunda acrescenta leitura em português. Compare os resultados por trilha, sem atribuir automaticamente um erro textual à incapacidade de calcular.
A pesquisa CheckList organiza testes comportamentais por capacidades e tipos de teste. Essa orientação sustenta uma escolha prática: verificar operações específicas além de olhar uma média de acertos. O conjunto apresentado aqui é uma aplicação editorial dessa ideia, não uma reprodução do experimento do artigo.
Escolha também a saída exigida. Uma resposta como “sim, provavelmente” não equivale a um booleano válido. Peça os campos expressao, valor e motivo_curto. Avalie o valor e a conformidade do formato separadamente. A justificativa curta ajuda a revisar o resultado, mas não substitui o gabarito nem comprova o processo interno do modelo.
2. Construa a tabela antes de escrever os prompts
Na lógica proposicional clássica usada neste roteiro, cada variável recebe exatamente um entre dois valores: verdadeiro ou falso. Para duas variáveis existem quatro atribuições possíveis; para três, oito. Gere todas as linhas de cada expressão pequena. Assim você evita escolher apenas situações intuitivas que escondem os casos difíceis.
| P | Q | P e Q | P ou Q inclusivo | P ou Q exclusivo | Se P, então Q |
|---|---|---|---|---|---|
| V | V | V | V | F | V |
| V | F | F | V | V | F |
| F | V | F | V | V | V |
| F | F | F | F | F | V |
O “ou” inclusivo aceita que ambas as condições sejam verdadeiras. O exclusivo exige exatamente uma. A negação de P troca seu valor. Já a implicação material, indicada por P → Q, só é falsa quando P é verdadeiro e Q é falso. O bicondicional P ↔ Q é verdadeiro quando os valores coincidem.
A implicação merece um aviso na própria instrução do teste. No uso cotidiano, “se chover, levo guarda-chuva” pode carregar expectativas sobre causa, tempo e comportamento. A tabela trata somente da operação formal definida. Se a equipe quer avaliar decisões reais, precisa escrever a regra operacional completa, em vez de importar automaticamente todas as propriedades da implicação material.
Não peça ao mesmo modelo para criar o único gabarito que depois avaliará suas respostas. Para expressões pequenas, uma pessoa pode conferir todas as linhas e uma segunda revisar as definições. Quando houver geração automática, valide o código com casos conhecidos, incluindo as quatro linhas da tabela acima e a dupla negação.
3. Separe ambiguidade linguística de falha lógica
“Libere a retirada se houver pagamento” estabelece pagamento como condição suficiente para a liberação, na leitura formal declarada. “Libere a retirada somente se houver pagamento” faz do pagamento uma condição necessária: a liberação implica pagamento. As frases não são intercambiáveis. Se o regulamento pretende equivalência, escreva “a retirada é liberada se, e somente se, houver pagamento”, acrescentando todas as demais condições necessárias.
Em uma avaliação textual, mantenha um campo de revisão humana para a tradução. Um item ambíguo não deve receber um gabarito rígido por conveniência. Reescreva o enunciado ou aceite uma resposta que peça esclarecimento, conforme o objetivo do teste. O guia sobre preservação de parênteses e exceções ajuda quando a regra envolve agrupamentos e ressalvas.
Use parênteses explícitos nas fórmulas. (P ou Q) e R difere de P ou (Q e R). Teste primeiro cada uma com seus próprios valores e só depois explore frases sem agrupamento. Se o enunciado não declara precedência e permite duas leituras, a discordância pode estar no item, não na resposta do sistema.
O estudo FOLIO associa enunciados a anotações formais e verifica sua consistência com um mecanismo de inferência. Ele trabalha com lógica de primeira ordem, um escopo mais amplo que a tabela proposicional deste guia. A contribuição metodológica relevante é manter a relação entre texto e representação verificável, sem tratar linguagem natural como um gabarito autoexplicativo.
4. Monte pares que exponham trocas de conectivo
Organize os itens em famílias. Uma família mantém P e Q e varia apenas o conectivo. Outra mantém a expressão e troca os nomes das variáveis. Uma terceira reescreve o texto preservando o significado. Essa organização permite observar se o sistema se guia pela relação formal ou por palavras familiares da situação.
Considere P verdadeiro e Q falso. O valor de “P e Q” é falso; o de “P ou Q” inclusivo é verdadeiro. Esse par exige mudança de resposta. Agora compare “P e Q” com “Q e P”: a resposta deve permanecer igual. A avaliação precisa conter tanto mudanças esperadas quanto invariâncias, para não recompensar um sistema que sempre mantém ou sempre altera sua classificação.
Inclua equivalências como não(P e Q) e (não P) ou (não Q), deixando clara a negação de cada termo. Elas testam a mesma função por formas distintas. Para aprofundar esse desenho, consulte o texto sobre testes metamórficos em modelos de linguagem. Aqui o diferencial é que a tabela completa fornece também um gabarito exato.
A pesquisa Transformers as Soft Reasoners over Language investiga inferências sobre fatos e regras escritos em linguagem. Ela oferece contexto para testes com encadeamentos, mas seus resultados não certificam um assistente atual ou uma política da sua empresa. Comece por conectivos isolados antes de adicionar várias regras dependentes.
Congele a versão do conjunto antes de comparar configurações. Registre instrução completa, identificador do sistema, parâmetros disponíveis, data e respostas brutas. Se repetir chamadas para observar variação, defina antecipadamente quantas serão feitas. Não escolha a melhor tentativa de cada item, pois esse procedimento produz uma medida diferente da execução única em produção.
5. Exemplo: retirada de pedidos em uma papelaria de Curitiba
Imagine uma papelaria de Curitiba que quer verificar se um assistente interpreta sua regra de retirada. O exemplo é ilustrativo. A regra interna do piloto diz: “Pode retirar quando o pagamento estiver confirmado e quando houver documento do titular ou autorização registrada”. Defina P como pagamento confirmado, D como documento apresentado e A como autorização registrada. A expressão é P e (D ou A), com “ou” inclusivo.
O conjunto precisa conter as oito combinações. Se P for falso, a retirada não está liberada por essa regra, independentemente dos documentos. Se P for verdadeiro e D e A forem falsos, também não. Quando P é verdadeiro e pelo menos um entre D e A é verdadeiro, a expressão autoriza a retirada. Documento e autorização juntos não devem bloquear a decisão.
Um prompt de teste pode dizer: “Considere somente a regra declarada, com todas as condições conhecidas. Pagamento: confirmado. Documento: ausente. Autorização: registrada. Informe a expressão e se ela permite a retirada”. O gabarito esperado é verdadeiro. Em outra linha, retire a confirmação do pagamento e mantenha os demais campos: o valor esperado passa a falso.
Depois avalie uma entrada com “pagamento não informado”. Ela pertence a um bloco separado: não há valor booleano conhecido para P. O assistente deve pedir a informação ou seguir a política explícita de bloqueio preventivo, conforme a especificação. Não marque o dado ausente como falso silenciosamente. Uma política operacional pode bloquear a retirada por falta de evidência sem afirmar que o pagamento não ocorreu.
Na implantação, um programa pode calcular a expressão a partir dos campos confirmados. O assistente fica responsável por identificar os dados, explicar a pendência e encaminhar dúvidas. Essa divisão permite testar a leitura e a decisão de maneira independente, preservando um registro que o atendente consegue conferir.
6. Erros comuns
Publicar apenas a taxa global. Apresente acertos e total por conectivo, tamanho da expressão e trilha textual ou simbólica. Mostre ainda quantas famílias foram acertadas integralmente. Uma configuração pode acertar quase todas as conjunções e falhar sistematicamente nas implicações.
Tratar informação ausente como falsidade. O teste booleano pressupõe valores conhecidos. Separe “falso”, “desconhecido” e “entrada inválida” na coleta, mesmo que a política final converta alguns casos em bloqueio. O artigo sobre fontes ausentes e contraditórias ajuda a desenhar essa distinção.
Aumentar dificuldade e mudar a redação simultaneamente. Se uma versão acrescenta variáveis, negações e vocabulário jurídico, a queda de acerto não tem causa isolada. Varie um fator por bloco. Inclua exemplos sem contexto comercial para verificar se o problema acompanha a fórmula.
Generalizar um estudo sobre arquitetura. O trabalho On the Ability and Limitations of Transformers to Recognize Formal Languages examina linguagens formais e seus níveis de complexidade. Ele não fornece um selo de confiabilidade para produtos específicos. Use pesquisas para orientar hipóteses de teste e evidências locais para decidir a homologação.
Corrigir o prompt no conjunto de aprovação. Reserve uma parte inédita para a comparação final. Quando um item revelar um defeito, mova-o para a bateria de regressão, sem fingir que continua sendo um caso novo. Documente a correção e procure outras expressões da mesma família.
7. Perguntas frequentes
Tabelas verdade avaliam todo o raciocínio de um modelo?
Não. Elas verificam funções proposicionais dentro das definições fornecidas. Quantificadores, relações temporais, probabilidades, causalidade e interpretação pragmática exigem outros desenhos de avaliação. Um resultado bom aqui permite uma conclusão restrita sobre as expressões testadas.
Posso testar sem programar?
Sim. Uma planilha com as combinações, o gabarito revisado e as respostas já permite um piloto. Mantenha colunas distintas para fórmula esperada, valor esperado, saída recebida e tipo de erro. Automatize depois que as definições estiverem estáveis.
Devo exigir explicações longas?
Não é necessário para corrigir o valor final. Uma justificativa curta pode localizar uma troca de conectivo, mas uma explicação convincente também pode acompanhar uma resposta errada. Use correção independente e revise as divergências sem confiar no tom da resposta.
Qual taxa de acerto libera o uso?
O limite depende das consequências da operação e deve ser definido pela equipe responsável antes do teste. Uma tarefa que libera pedidos pede tratamento diferente de um exercício de treinamento. Para decisões formalizadas, considere manter o cálculo em código e homologar separadamente a extração dos campos.
Como comparar duas configurações com justiça?
Use o mesmo conjunto congelado, a mesma política de repetição e as mesmas regras de correção. Compare os itens em que as respostas divergem, além dos totais. Registre falhas de formato e pedidos de esclarecimento para que esses comportamentos não desapareçam da análise.
