Caso de uso
Checagem de política de reembolso
Pergunte se um reembolso foi pedido e se a política escrita o ampara.
O problema
Agentes de suporte relêem a mesma política em cada ticket de cobrança duplicada.
O que seu código faz com a resposta
Aprove automaticamente apenas quando ambas as respostas de noul forem altas. Todo o resto vai para revisão.
Duas perguntas sim/não em vez do juízo de um agente
A requisição carrega o ticket, a ordem estruturada (duas cobranças capturadas sob um mesmo número de pedido) e o texto da política de reembolso como state. Duas perguntas de noul: a mensagem pede um reembolso, e a política o ampara dadas as cobranças? Ambas retornam uma probabilidade. Com uma política clara sobre cobrança duplicada, a pergunta de política volta perto de 0.98 — o modelo está lendo o texto real da política que você enviou como state, e é por isso que páginas de política bem redigidas rendem aqui.
A máquina de política
Aprove automaticamente só quando as duas probabilidades cruzam a sua barra na mesma chamada — muitas equipes usam 0.9. Uma alta e uma baixa não é semi-aprovado: vai para revisão com a distribuição anexada, que é exatamente o que um agente de suporte quer ver logo no começo do dia. Nada aqui inventa posições de política: o modelo responde se a política escrita por você cobre este ticket, então um padrão que a sua política exclui aterrissa corretamente na revisão.
Pitfalls específicos de checagens de política
O modo de falha é texto de política escrito para advogados: "uso razoável da janela de reembolso" não se parseia em nada, enquanto "até 30 dias da compra" se parseia limpo. Mantenha a decisão estritamente em âmbito da política escrita — se a política se contradiz (30 dias em uma seção, garantia vitalícia em outra), reescreva-a, porque uma resposta tipada sobre texto contraditório não é uma resolução. E quando os dados do pedido vivem no seu banco de dados, coloque os campos relevantes no state explicitamente, em vez de pedir ao modelo para inferir cobranças a partir de prosa.
O formato da requisição
Esta é a requisição completa que o playground envia para este preset — o mesmo JSON que o seu servidor envia para /v1/systemone com uma chave Bearer.
curl https://jevai.website/api/v1/systemone \
-H "Authorization: Bearer $JEV_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"state": {
"ticket": {
"subject": "Duplicate charge",
"message": "I was charged twice for order A-104. Please refund the duplicate."
},
"order": {
"id": "A-104",
"charges": [
{
"amount_usd": 49,
"status": "captured"
},
{
"amount_usd": 49,
"status": "captured"
}
]
},
"refund_policy": "Duplicate charges are eligible for a full refund of the duplicate amount."
},
"questions": {
"refund_requested": {
"type": "noul",
"instructions": "Does `ticket.message` request a refund?"
},
"policy_supports_refund": {
"type": "noul",
"instructions": "Does `refund_policy` support the refund requested in `ticket.message`, given `order.charges`?"
}
}
}'FAQ sobre este caso de uso
- Posso anexar capturas de tela ou PDFs?
- Nesta chamada, não — o Jev lê texto, então cole o trecho relevante ou os fatos do pedido no state como texto ou JSON. Até 100,000 caracteres cobrem uma conversa longa.
- Como isso difere de uma decisão de modelo de chat?
- O espaço de respostas dele é limitado: ambas as perguntas retornam uma probabilidade sobre a leitura declarada por você da política, não prosa gerada que você precisa interpretar e confiar — e a checagem inteira custa um crédito.
- Nós mudamos de política com frequência — isso quebra?
- Nenhum retreinamento está envolvido: a política é state, então publicar texto novo muda o que o modelo vê. Rode de novo os seus dez tickets de validação sempre que a política mudar de forma significativa.