Desconto sobre o total e desconto sobre o item parecem a mesma coisa e não são. Se um modelo de linguagem recebe “dê 10% de desconto” e uma lista de itens, ele pode aplicar os 10% em cada item e somar, ou aplicar 10% sobre a soma. Com frete e imposto no meio, a ordem em que cada operação entra muda o resultado final em reais. Avaliar essa distinção é testar se o modelo calcula direito e, mais importante, se ele segue a regra que você definiu.
Este guia mostra como montar casos de teste com números conferíveis à mão, como redigir o prompt para o modelo mostrar a conta passo a passo e como validar a resposta por código. O foco é cálculo comercial brasileiro: desconto por item e sobre o total, com e sem frete, descontos cumulativos e a ordem entre desconto, frete e imposto.
Resumo rápido
- Desconto sobre o total e desconto por item dão resultados diferentes quando os itens não são todos iguais ou quando há frete e imposto envolvidos.
- A ordem importa: aplicar desconto antes ou depois do frete e do imposto muda o valor final.
- Descontos cumulativos não se somam. Dois descontos de 10% dão 19%, não 20%.
- Teste sempre com números que você consegue conferir à mão, e um gabarito para cada caso.
- No prompt, exija a conta passo a passo, com o valor de cada etapa.
- Valide por código com aritmética decimal, comparando o resultado do modelo com o seu.
Desconto sobre o total e sobre o item: onde divergem
Com uma compra de um item só, os dois caminhos dão o mesmo número. A diferença aparece em dois cenários.
Cenário um: desconto só em parte dos itens
Se o desconto vale para um produto específico, você aplica no item. “Desconto de 15% no produto A” afeta só aquele item. Já “desconto de 15% na compra” afeta a soma. Um modelo que confunde os dois aplica o desconto onde não devia ou deixa de aplicar onde devia.
Cenário dois: frete e imposto no meio
Quando há frete ou imposto, o desconto sobre o total e o desconto por item param de coincidir. Suponha dois itens de R$ 100,00 e frete de R$ 50,00.
| Regra | Como calcular | Resultado |
|---|---|---|
| Desconto 10% por item, frete depois | (100 + 100) x 0,90 = 180, + 50 de frete | R$ 230,00 |
| Desconto 10% sobre o total com frete | (100 + 100 + 50) x 0,90 | R$ 225,00 |
| Desconto 10% sobre o total, sem frete no cálculo | (100 + 100) x 0,90 = 180, + 50 de frete | R$ 230,00 |
Repare que o frete na conta do desconto derruba o total de R$ 230,00 para R$ 225,00. Mesma porcentagem, mesmo pedido, resultados diferentes. É esse tipo de diferença que o conjunto de teste precisa capturar.
Ordem das operações: desconto, frete e imposto
Antes de testar o modelo, você precisa fixar a regra. Cada empresa decide a ordem, mas ela tem que ser explícita, porque as combinações dão resultados distintos.
Desconto antes ou depois do frete
Desconto antes do frete: aplica o desconto nos itens, depois soma o frete. Desconto depois do frete: soma tudo e aplica o desconto sobre a soma. A primeira quase sempre dá total maior se o desconto não incide sobre o frete.
Desconto antes ou depois do imposto
Aqui o cuidado é tributário. Em geral o imposto incide sobre o valor já com desconto, mas isso depende do tributo e da operação. Não decida por conta própria com base em intuição: confirme na fonte oficial (Receita Federal, portal da NF-e) ou com o contador, e escreva a regra no sistema antes de pedir ao modelo. O trabalho do modelo é seguir a regra, não inventá-la.
O modelo não deve descobrir a ordem das operações sozinho. A ordem é regra de negócio. Você determina; o modelo executa e mostra a conta. Se ele tem que adivinhar a ordem, o teste vai medir adivinhação, não cálculo.
Descontos cumulativos: por que 10% + 10% não é 20%
Descontos aplicados em sequência se multiplicam, não se somam. Um desconto de 10% seguido de outro de 10% sobre o resultado dá 0,9 x 0,9 = 0,81, ou seja, 19% de desconto total, não 20%. Modelos erram isso com frequência porque somam as porcentagens, que dá um número mais “redondo”.
Esse é um caso de teste excelente, porque a resposta certa não é óbvia e o número final é fácil de conferir: R$ 100,00 com dois descontos de 10% dá R$ 81,00, não R$ 80,00. Se o modelo responde 80,00, ele somou em vez de multiplicar.
Montando casos de teste com números conferíveis à mão
Cada caso de teste tem três partes: o pedido (itens, frete, descontos), a regra (ordem das operações) e o gabarito (o número certo, que você calcula antes de rodar o modelo).
Exemplo de caso completo
| Item | Quantidade | Preço unitário | Subtotal |
|---|---|---|---|
| Suporte de parede | 2 | R$ 80,00 | R$ 160,00 |
| Cabo 3 m | 3 | R$ 20,00 | R$ 60,00 |
Pedido: desconto de 10% sobre o total dos itens, frete de R$ 40,00 somado depois, sem imposto. Regra: desconto nos itens, frete depois.
- Subtotal: 160,00 + 60,00 = R$ 220,00
- Desconto 10% sobre o subtotal: 22,00, total com desconto R$ 198,00
- Frete somado depois: 198,00 + 40,00 = R$ 238,00
O gabarito é 238,00. Se você pedir ao modelo a mesma coisa com desconto por item, o resultado coincide neste caso (10% em cada item dá os mesmos 22,00 de desconto), e isso é proposital: mostra que o modelo não pode se apoiar no acaso. Para separar de fato os dois cenários, use descontos diferentes por item ou frete que entra ou não no cálculo do desconto.
Como variar para cobrir os erros
- Desconto por item com taxas diferentes: 10% no item A, 5% no item B, para o resultado divergir do desconto sobre o total.
- Frete antes versus depois do desconto: o mesmo pedido, duas regras, dois totais.
- Com e sem imposto: uma alíquota aplicada antes e outra depois do desconto.
- Cumulatividade: dois descontos em sequência, para pegar quem soma em vez de multiplicar.
- Desconto em valor fixo: R$ 20,00 de abatimento, e não só porcentagem.
Escrevendo o prompt para o modelo mostrar a conta
Pedir só “o total” esconde o erro. Exija a conta aberta, etapa por etapa, com o valor depois de cada operação. Assim, quando o resultado final está errado, você vê em qual passo o modelo se perdeu.
Vou te dar itens, frete e descontos. Siga exatamente a regra que eu informar. Não decida a ordem das operações por conta própria.
Passos obrigatórios, um por linha:
- subtotal dos itens
- desconto aplicado (diga se foi por item ou sobre o total)
- total após desconto
- frete somado
- imposto aplicado, se houver, e sobre qual base
- total final
Para cada passo, mostre o número antes e depois. No final, responda em JSON com os campos: subtotal, total_desconto, total_apos_desconto, frete, imposto, total_final, ordem_aplicada. Use ponto como separador decimal. Não arredonde no meio do caminho; arredonde apenas no total final, com duas casas.
Três pontos do prompt fazem o trabalho pesado. O modelo é proibido de escolher a ordem (ordem_aplicada deve refletir a sua regra, não uma escolha dele). A conta aberta dá rastreabilidade. E o formato de saída em campos fixos permite comparar por código sem ler texto corrido. Esse é o mesmo princípio de saída estruturada usado para extrair dados: veja function calling e structured outputs.
Validando as respostas por código
A validação compara o que o modelo devolveu com o seu gabarito. Três cuidados evitam falso erro e falso acerto.
Use decimal, não ponto flutuante
Dinheiro em ponto flutuante erra centavos. Em Python, 0.1 + 0.2 não dá 0.3, dá 0.30000000000000004. Arredondar 2,675 com a função comum dá 2,67 em vez de 2,68 por causa da representação interna do float. Para comparar valores monetários, use o módulo decimal.
from decimal import Decimal, ROUND_HALF_UP
def d(v): return Decimal(str(v)).quantize(Decimal("0.01"), rounding=ROUND_HALF_UP)
# gabarito calculado à mão
gabarito = d("238.00")
# resposta do modelo, no campo total_final
obtido = d(resposta["total_final"])
assert obtido == gabarito, f"esperado {gabarito}, veio {obtido}"
Confira também o caminho, não só o total
Um total certo por acidente não prova cálculo correto. Compare as etapas intermediárias (subtotal, desconto, total após desconto, frete, imposto) com o gabarito de cada uma. Assim você localiza exatamente onde o modelo divergiu.
etapas = {
"subtotal": d("220.00"),
"total_desconto": d("22.00"),
"total_apos_desconto": d("198.00"),
"frete": d("40.00"),
"total_final": d("238.00"),
}
for campo, esperado in etapas.items():
assert d(resposta[campo]) == esperado, f"{campo}: esperado {esperado}, veio {resposta[campo]}"
Cubra o caso da cumulatividade
Inclua um caso com dois descontos em sequência e verifique que o resultado é o do cálculo multiplicado. Cem reais com 10% e mais 10% dão R$ 81,00. Se o modelo devolver R$ 80,00, ele somou as porcentagens. Esse único teste descarta a classe de erro mais comum em desconto cumulativo.
Exemplo: loja de material de construção em Belo Horizonte
Uma loja de material de construção em Belo Horizonte passou a gerar orçamentos por chat, com o modelo calculando totais a partir de uma lista de itens. A regra comercial da loja era clara: desconto de negociação de 8% incidindo sobre o total dos itens, frete cobrado à parte e somado depois, imposto incidindo sobre o valor já com desconto.
Na primeira versão, o prompt só pedia “o total do orçamento”. O modelo aplicava o desconto sobre o valor com frete incluído, o que reduzia o frete junto com os produtos e dava um total abaixo do devido. Como não havia conta aberta, o erro só aparecia quando o cliente reclamava do valor na nota.
O time montou um conjunto de casos com gabarito, pediu a conta passo a passo com campos fixos e passou a validar por código. A partir daí ficou visível que o erro estava na ordem (desconto depois do frete) e não na porcentagem. Com a regra escrita no prompt e verificada a cada etapa, os totais passaram a bater com o gabarito antes do envio. O ganho concreto foi confiança no orçamento automático e menos retrabalho no atendimento.
Erros comuns
- Não definir a ordem das operações. Se o prompt não diz quando entra o desconto, o modelo escolhe, e a escolha pode não ser a sua regra.
- Somar descontos cumulativos. Dois descontos de 10% dão 19%, não 20%. Somar porcentagens é o erro mais frequente.
- Aplicar desconto sobre o frete sem querer. “Desconto sobre o total” com o frete já somado abate o frete também. Se não era a intenção, o total sai menor.
- Aceitar só o número final. Sem a conta aberta, você não sabe onde o modelo errou nem se acertou por sorte.
- Comparar centavos com float. Arredondamento de ponto flutuante gera falso erro. Use decimal.
- Deixar o modelo decidir imposto. Alíquota e base de cálculo são regra tributária, não decisão do modelo. Confirme na fonte oficial e passe a regra pronta.
- Testar só com um item. Com item único, desconto por item e sobre o total coincidem e o teste não separa os cenários.
Perguntas frequentes
Desconto por item e desconto sobre o total dão sempre o mesmo resultado?
Não. Coincidem quando o desconto tem a mesma porcentagem para todos os itens e não há frete nem imposto no meio. Divergem assim que o desconto varia por item ou quando frete e imposto entram na conta.
Por que 10% mais 10% de desconto não dá 20%?
Porque o segundo desconto incide sobre um valor já reduzido. Os fatores se multiplicam: 0,9 x 0,9 = 0,81, que é 19% de desconto total. Somar as porcentagens ignora a base menor do segundo desconto.
Desconto entra antes ou depois do frete?
Depende da regra da sua empresa. Desconto antes do frete e desconto sobre o total com o frete já somado dão resultados diferentes. Defina a regra, escreva no prompt e teste os dois cenários separadamente.
E o imposto, entra antes ou depois do desconto?
É regra tributária e varia conforme o tributo e a operação. Não decida por intuição: confirme na Receita Federal, no portal da NF-e ou com o contador, e passe a regra já definida para o modelo.
Posso pedir o cálculo direto, sem passo a passo?
Pode, mas você perde a rastreabilidade. Sem a conta aberta, um total errado não indica onde falhou, e um total certo pode ter vindo de um caminho errado. Para avaliar, exija as etapas.
Como sei se a validação por código está correta?
Calcule o gabarito à mão, escreva no teste e compare com aritmética decimal. Se o modelo devolve 81,00 no caso de cumulatividade e seu gabarito é 81,00, o teste está medindo o que importa. Rode vários casos, incluindo o controle sem desconto.
Fontes e leitura recomendada
- Python: módulo decimal, para comparação exata de valores monetários e arredondamento controlado.
- Python: aritmética de ponto flutuante, que mostra por que o float erra centavos.
- OpenAI: structured outputs, para saída em campos fixos como subtotal, frete e total_final.
- Anthropic: visão geral de uso de ferramentas (tool use), sobre devolver dados em estrutura definida.
- Google Gemini API: structured output, para respostas em JSON com esquema.
- Receita Federal, para regras e tributos na fonte oficial.
- Portal Nacional da NF-e, para documentos fiscais eletrônicos e seus campos de valor.
Veja também, aqui no site: como testar um agente de IA e IA para planilhas: fórmulas e análises.
