Del playground a producción en una tarde

Paso 0 — elige la decisión correcta

Los buenos primeros candidatos son decisiones que ya tomas mal o a mano: una regex de enrutamiento escrita a mano, un humano releyendo la misma política, una marca de «revisar, por favor» que nadie revisa. Los malos candidatos son decisiones donde equivocarse es caro e inmedible — deja esas derivadas a un humano por ahora, con la decisión tipada como filtro de primera pasada.

Escribe el estado como los datos que ya tienes: el texto del ticket, el payload del formulario, la llamada a herramienta a punto de ejecutarse. No lo presintetices — la lectura la hace el modelo.

Hora 1 — ejecuta diez ejemplos reales en el playground

El playground ejecuta el modelo real, gratis, en el navegador. Pega ejemplos de tu backlog — tickets reales, no hipotéticos — hasta que diez de ellos salgan como decidiría un colega cuidadoso.

• ¿Respuestas mal calibradas? Ajusta los criteria con redacciones concretas de true/false.
• ¿Casos ambiguos recibiendo respuestas confiadas? Tus criteria son demasiado gruesos — añade un nivel a la escala.
• ¿Falta contexto? Mete el dato que falta en el estado en lugar de esperar que el modelo lo sepa.

Hora 2 — copia el JSON a una llamada con clave

El JSON que ves en el playground es el JSON que tu servidor debería enviar. Exactamente tres cosas cambian en producción: la cabecera Authorization, la ruta del endpoint (/api/v1/systemone en lugar del endpoint de navegador del playground) y la cuota (los planes gratuitos ejecutan 20 solicitudes por minuto; Starter empieza en 120/min). Subir de plan eleva tanto la concurrencia como las solicitudes por minuto — 3 concurrentes en Starter, 10 en Pro.

async function decide(state, questions) {
  const resp = await fetch("https://jevai.website/api/v1/systemone", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.JEV_API_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ state, questions }),
  });
  if (resp.status === 429 || resp.status === 502 || resp.status === 529) {
    // exponential backoff here — never retry 401/402/422
  }
  return resp.json();
}

Hora 3 — umbral, flag, lanzar

Decide qué significa un número antes de cablearlo: por debajo de 0,8 de confianza, envía el ítem a una persona en lugar de decidir. Lanza tras un feature flag que mande, digamos, el 5% del tráfico de producción a la decisión tipada el primer día, y registra el request_id junto a tu decisión antigua para poder compararlos.

• Registra request_id, el valor de score o noul, y la acción que tomó tu política.
• Fija un timeout que tolere arranques en frío ocasionales (la primera llamada tras un periodo de inactividad puede tardar ~3 s; el resto se agrupa en 400–600 ms).
• Configura alertas para el 402 (créditos bajos) — es el único fallo que un bucle de reintentos no puede arreglar.

Fallos comunes del primer día y sus arreglos

• Respuestas inconsistentes entre casos similares — las descripciones de los criteria son vagas o contradictorias. Reescríbelas como líneas de política.
• 429 durante un pico — free permite 20 req/min. Pasa a Starter (120/min, 3 concurrentes) o encola tus picos en el cliente.
• Todo se enruta a la opción superior — los textos de los criteria se inclinan hacia el mismo lado. Equilíbralos.
• Se cobra un crédito donde esperabas facturación por pregunta — la facturación es por token de entrada con un mínimo de 1 crédito por solicitud, así que agrupar las preguntas a la vez es más barato que separarlas. Mira el post de créditos para el cálculo.

Elige el umbral a partir de datos, no de instinto

Tras un día con el flag al 5%, la distribución es tuya. Apunta la banda de baja confianza (todo lo que esté por debajo de 0,8, entre 0,8 y 0,9, y por encima de 0,9) en una hoja de cálculo, y típicamente encontrarás decisiones bimodales — un montón claro de respuestas confiadas y una cola de rezagados en 0,5–0,7. Esa cola es donde ocurre la revisión humana. Luego mueve el umbral adonde tu cola pueda absorber la revisión; en una bandeja compartida, una tasa de revisión del 15% puede exceder el presupuesto, y lo correcto es ajustar los criteria — no aceptar el 15% en silencio.

Escalado cuando no estás seguro

• Confianza por debajo del umbral — envía a un humano con el estado y la distribución completa adjuntos.
• Solicitud fallida (429/502/529 tras los reintentos) — recurre por defecto a la vía legada, no a saltarla. Una decisión ausente es un bug, no un riesgo.
• Claves de respuesta ausentes en el mapa answers — trátalo como un fallo y regístralo. (No debería ocurrir; el esquema garantiza una respuesta por nombre de pregunta.)

Patrones de redacción que mueven la precisión

• Criteria como líneas de política, no sinónimos: «true: Explícitamente sensible al tiempo o crítico para el negocio; false: Sin urgencia expresada» gana a «true: urgente; false: no urgente». El modelo lee los criteria, así que escríbelos para un temporal cuidadoso que nunca ha visto tu producto.
• Nombra los campos que referencias: «¿Coincide `proposed_tool_call` con lo que pidió `user_request`?» permite al modelo anclar su juicio; «¿Esto es sospechoso?» lo obliga a adivinar.
• Una decisión por pregunta: no preguntes «¿es urgente Y debo avisar Y no es un duplicado?» — la respuesta a una pregunta compuesta no es interpretable.
• Escalas con línea roja: cuando la acción cambia en un nivel, nombra ese nivel en los criteria de las preguntas relacionadas en lugar de esperar que el score solo lo codifique.