Caso de uso
Comprobación de política de reembolsos
Pregunta si se solicitó un reembolso y si la política escrita lo respalda.
El problema
Los agentes de soporte releyeron la misma política en cada ticket de cargo duplicado.
Qué hace tu código con la respuesta
Aprueba automáticamente solo cuando ambas respuestas noul sean altas. Todo lo demás va a revisión.
Dos preguntas sí/no en lugar de la llamada de juicio de un agente
La solicitud lleva el ticket, el pedido estructurado (dos cargos capturados bajo un mismo número de pedido) y el texto de la política de reembolsos como estado. Dos preguntas noul: si el mensaje solicita un reembolso y si la política lo respalda dados los cargos. Ambas devuelven una probabilidad. Con una política clara de cargos duplicados, la pregunta de política vuelve cerca de 0,98 — el modelo está leyendo el texto real de la política que enviaste como estado, y por eso las páginas de política bien redactadas rinden aquí.
La máquina de la política
Aprueba automáticamente solo cuando ambas probabilidades superan tu barra en la misma llamada — muchos equipos usan 0,9. Una alta y una baja no es medio aprobado: va a revisión con la distribución adjunta, que es exactamente lo primero que un agente de soporte quiere ver por la mañana. Nada aquí inventa posturas de política: el modelo responde si tu política escrita cubre este ticket, así que un patrón que tu política excluye aterriza correctamente en revisión.
Riesgos propios de las comprobaciones de política
El modo de fallo es texto de política escrito para abogados: «uso razonable del plazo de reembolso» no parsea como nada, mientras que «dentro de los 30 días posteriores a la compra» parsea limpio. Mantén la decisión estrictamente acotada a la política escrita — si la política se contradice (30 días en una sección, garantía de por vida en otra), reescríbela, porque una respuesta tipada sobre texto contradictorio no es una resolución. Y cuando los datos del pedido viven en tu base de datos, mete los campos relevantes en el estado explícitamente en lugar de pedirle al modelo que infiera los cargos de la prosa.
La forma de la solicitud
Esta es la solicitud completa que el playground envía para este preset — el mismo JSON que tu servidor envía a /v1/systemone con una clave 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`?"
}
}
}'Preguntas frecuentes sobre este caso de uso
- ¿Puedo adjuntar capturas de pantalla o PDFs?
- No en esta llamada — Jev lee texto, así que pega la transcripción relevante o los datos del pedido en el estado como texto o JSON. Hasta 100.000 caracteres cubren un hilo largo.
- ¿En qué se diferencia esto de una decisión de un modelo de chat?
- Su espacio de respuestas está acotado: ambas preguntas devuelven una probabilidad sobre tu lectura declarada de la política, no prosa generada que haya que parsear y en la que fiarse — y toda la comprobación es un crédito.
- Cambiamos de política a menudo — ¿eso lo rompe?
- No hay reentrenamiento involucrado: la política es estado, así que publicar texto nuevo cambia lo que el modelo ve. Reejecuta tus diez tickets de validación siempre que la política cambie de forma significativa.