task_family: coste

prompt: Un modelo fuerte mejora calidad 2 puntos pero duplica coste. Decide que dato falta antes de cambiar routing.

chosen: Falta el impacto por slice: calidad, coste, latencia, volumen y severidad. Si la mejora solo aparece en baja criticidad, no compensa; si aparece en casos complejos, conviene piloto limitado.

rejected: Si mejora la calidad, merece la pena usarlo más aunque cueste el doble.

preference_reason: La elegida pide decisión segmentada y piloto; la rechazada ignora coste y distribución.

reference_answer: Debe pedir métricas por slice y coste esperado.

notes: menciona slices, coste y piloto


task_family: herramientas

prompt: Define una respuesta correcta si una llamada de herramienta falla con timeout.

chosen: Informa que la consulta no se ha completado, conserva el estado previo, registra `tool_timeout`, ofrece reintento si es seguro y no inventa el resultado de la herramienta.

rejected: Si la herramienta tarda, responde con la opcion mas probable para no dejar al usuario esperando.

preference_reason: La elegida conserva estado y evita inventar resultado; la rechazada degrada fiabilidad.

reference_answer: Debe declarar timeout, no inventar y proponer reintento seguro.

notes: timeout y no inventar presentes


task_family: producto

prompt: Explica a un equipo por qué una mejora offline debe pasar por modo sombra.

chosen: Porque offline estima con datos históricos, pero no observa efectos de sistema vivo. Modo sombra permite comparar decisiones, coste y errores sin afectar usuario, antes de un piloto con tráfico real.

rejected: Modo sombra es una formalidad recomendable antes de sacar cualquier cambio a producción.

preference_reason: La elegida conecta límite offline con decisión operativa; la rechazada no explica por qué.

reference_answer: Debe mencionar límite offline, decisión sin afectar usuario y piloto.

notes: menciona offline y sombra