Puedes hacer una pregunta o enviar varias juntas. Cada pregunta de una solicitud ve el mismo estado, se evalúa de forma independiente y devuelve una respuesta tipada bajo el ID que elegiste.
Pide un solo juicio rápido por pregunta
Los modelos System One están hechos para juicios rápidos y enfocados. Pide un juicio que una persona knowledgeable haría en un segundo con el contexto adecuado. “¿Este mensaje transmite urgencia?” es una buena pregunta. “Analiza este mensaje y determina el mejor curso de acción” no lo es. Eso requiere razonamiento lento, y es una señal para dividir la tarea en preguntas pequeñas y componer las respuestas en código. Si el juicio que quieres depende de varios factores independientes, pregunta por cada factor por separado y combina las respuestas con tu propia lógica. En lugar de “califica este pitch de startup”, pregunta por tamaño de mercado, factibilidad técnica y diferenciación, y luego ponles pesos en código según su importancia relativa. Cuando cambien las prioridades, cambia el valor de los pesos en lugar de reescribir un prompt. Hacer varias preguntas juntas muestra cómo hacerlo.Definir una pregunta
Toda pregunta tiene un ID, untype e instructions. Las preguntas Choice y Score también aceptan criteria, que define las opciones para una pregunta Choice o los niveles para un Score. Las preguntas Noul aceptan criteria como una aclaración opcional de qué significan sí y no.
- ID. La clave que tú eliges, como
refund_requested. Identifica la respuesta en la respuesta de la API. type. Uno dechoice,scoreonoul.instructions. La pregunta que haces sobre el estado. Aquí va tu lógica de evaluación. Escríbela como una pregunta clara y específica, o como una afirmación para que el modelo la juzgue. Un string basta para la mayoría de las preguntas. También puede ser un objeto o un array, lo que pone la pregunta en un campo y los datos a los que se refiere en otros; consulta Usar estructura en las preguntas.criteria. Las respuestas posibles: un mapa de opciones para una pregunta Choice, una lista ordenada de niveles para un Score, y una descripción opcional de sí y no para un Noul. La página de cada tipo de pregunta cubre su forma.
Elegir un tipo de pregunta
Elige el tipo que coincida con la forma de la respuesta que necesitas.-
Choice encaja cuando la respuesta es una de un conjunto conocido de opciones sin orden entre ellas: enrutar un ticket a un departamento, clasificar un tipo de documento, detectar un lenguaje de programación. Da la lista completa de opciones, y añade una opción
otheronone of the abovecuando la lista podría no cubrir todas las entradas. - Score encaja cuando la respuesta cae en un espectro y puedes describir qué significa cada punto de ese espectro: severidad de un bug, frustración del cliente, nivel de habilidad. Los niveles los defines tú, y el modelo devuelve una posición a lo largo de ellos.
- Noul encaja para una pregunta limpia de sí/no donde la probabilidad misma es la señal útil: ¿este mensaje contiene información de identificación personal?, ¿el cliente está solicitando un reembolso?, ¿el currículum menciona sistemas distribuidos?
Usa Noul para un juicio de sí/no y Score para medir una posición en un espectro. “¿Este candidato es fuerte en Python?” necesita una definición clara de “fuerte”. Un valor de Noul de 0.5 significa que el modelo da igual probabilidad al sí y al no. No significa que el candidato tenga un nivel medio de habilidad. Una definición poco clara hace que esa probabilidad sea difícil de interpretar.Si quieres medir el nivel de habilidad, usa un Score con niveles definidos, como sin experiencia, cierta familiaridad, uso diario y experiencia profunda. Si necesitas una decisión de sí/no, define la condición con claridad, como “¿El currículum indica que el candidato ha usado Python en el trabajo?”
refund, rebook e information se mapea directo a tres rutas de código. Un Score de frustración del cliente se mapea a un umbral. Un Noul se mapea a un if.
Qué devuelve
Las respuestas también son primitivas. Cada tipo de pregunta devuelve un valor tipado que tu código puede comparar, umbralizar, ordenar, pasar a más lógica o poner en el estado de una solicitud posterior (consulta Cuándo una pregunta depende de otra).
Dos propiedades de estas respuestas las hacen componibles:
- Toda respuesta está restringida a las opciones que suministraste. El modelo devuelve una distribución de probabilidad sobre tus opciones o niveles, nunca un valor fuera de ellas. Tu código nunca tiene que recuperar un valor desde prosa generada.
- Toda respuesta es independiente. La respuesta de una pregunta no es contexto oculto para otra. Puedes añadir o quitar preguntas sin cambiar los resultados de las demás.
confidence a partir de probabilities y cómo usarla para decidir cuándo actuar automáticamente y cuándo derivar el caso a una persona.
Referenciar campos específicos
El contenido que se evalúa, el estado, suele ser un objeto JSON con varias partes: una conversación, un registro, una política. Cuando una pregunta trata sobre una de esas partes, nómbrala en lasinstructions con una ruta de puntos e índices hasta su clave, incluyendo los backticks. Así el modelo sabe qué parte del estado juzgar.
Toma la conversación de soporte de la página de Estado:
Hacer varias preguntas juntas
Envía en una sola solicitud toda pregunta que use el mismo estado. Puedes mezclar tipos de pregunta libremente. Los modelos System One evalúan en paralelo toda pregunta de una solicitud. Añadir preguntas apenas cambia el tiempo de respuesta y solo cuesta los tokens de las preguntas extra, que son baratos. Preguntar algo que quizá no necesitas es casi gratis. Esta solicitud clasifica un mensaje de cliente, verifica la urgencia y califica la frustración todo a la vez: Nuestros SDKs de cliente proporcionan preguntas y respuestas tipadas. En Python, pasa un diccionarioquestions con objetos Choice, Noul y Score a client.system_one(...). Esta solicitud envía un ticket y una política de reembolso una sola vez y obtiene una respuesta tipada por cada pregunta:
Hacer preguntas especulativas
Haz toda pregunta que tu código podría necesitar, incluidas aquellas cuya respuesta solo importa para algunas entradas, y deja que el código decida qué respuestas usar. Si un ticket resulta no ser un reporte de bug, ignora la respuesta de severidad. A esto lo llamamos el patrón Speculative fan-out. El cookbook de preguntas en paralelo muestra cómo agrupar 13 preguntas en una sola llamada es 11.5 veces más barato y 9.6 veces más rápido que 13 llamadas separadas, sin cambios en las respuestas.Dividir un juicio complejo en varias preguntas
Un juicio que depende de varias cosas se divide mejor en una pregunta por cosa. Combina las respuestas en tu código, dándole a cada una un peso según su importancia relativa. Los pesos son tuyos. Cuando el resultado combinado no coincida con lo que tu equipo decidiría, cámbialos en código y ejecuta de nuevo. Añadir preguntas apenas cambia el tiempo de respuesta porque se evalúan en paralelo dentro de una solicitud. La división cuesta unos pocos tokens de pregunta extra. Por ejemplo, la prioridad de un ticket podría construirse con tres preguntas Score: qué tan severo es el bug, qué tan frustrado está el cliente y cuánto material de trabajo le da el reporte a un ingeniero. La página de Score recorre esta solicitud y el código que normaliza y pondera las respuestas en Dividir un juicio complejo en varios Scores. Esta técnica se llama el patrón Composite scoring.Cuándo una pregunta depende de otra
Las preguntas de una misma solicitud son independientes: una respuesta no se convierte en contexto para otra pregunta. Si un juicio posterior depende de una respuesta anterior, haz una segunda solicitud en código. La dependencia es real solo cuando tu código no puede construir la segunda solicitud hasta tener la primera respuesta: necesita la respuesta para obtener más datos para el estado, para decidir de qué está hecho el estado o para elegir las opciones de la siguiente pregunta. De lo contrario, haz las preguntas juntas y combina sus respuestas en código. Dos solicitudes son la excepción, no la regla. Si las preguntas de la segunda solicitud pudieron hacerse contra el estado original, házlas en la primera solicitud y deja que el código ignore las que no necesita. Tres cookbooks hacen una segunda solicitud por una razón real. Skill suggestion rankea 182 skills en una solicitud, luego obtiene el texto completo de las tres primeras y las juzga de nuevo contra esa mejor evidencia. Structure recovery pregunta si cada salto de línea partió una oración, fusiona líneas en bloques a partir de esas respuestas, y luego clasifica los bloques, que no existían hasta que la primera solicitud respondió. Hierarchical classification usa cada respuesta Choice para decidir qué opciones ofrece la siguiente solicitud. Consulta Cómo construir con CosVec para orientación sobre cómo dividir un flujo de trabajo en juicios enfocados.Próximos pasos
Choice
Elige una opción de una lista fija.
Score
Califica el estado a lo largo de niveles ordenados.
Noul
Obtén la probabilidad de que una afirmación sea verdadera.