Clasificación de texto multietiqueta: un Choice, varias preguntas sí/no o una segunda pasada

Mira la acción, no el folleto del modelo. “Me cobraron dos veces y la exportación ahora tarda dos minutos” es a la vez un problema de facturación y de rendimiento. Si el paso siguiente es “entrégalo al único equipo que debe responder”, quieres un label principal: ver intent-classification y text-classification-api. Si el paso siguiente es “etiqueta cada tema aplicable para que el informe semanal no pierda uno”, quieres multietiqueta. Forzar un Choice esconde uno de los dos hechos. Esta página cubre ese contrato. No sustituye la guía de una sola petición y no reescribe el interruptor de Make “asignar solo una categoría”: ese control vive en Make, descrito en make-categorize-text. El feedback de clientes que solo necesita el tema principal y una prioridad se queda en customer-feedback-classification.

Elige la forma que tu almacén puede guardar. La tabla es un mapa de contratos, no un ranking. Ninguna opción quita la necesidad de contar etiquetas falsas en tus propias filas etiquetadas.

Escribe cada Noul como una proposición: “¿Hay un problema de facturación?” Da criteria.true y criteria.false como descripciones cortas, de 2 a 350 caracteres cada una, e instructions de 8 a 600 caracteres. Los ids siguen la regla de Choice: una letra inicial y luego minúsculas, dígitos y guiones bajos, 40 caracteres como máximo. No hagas dos preguntas que signifiquen el mismo hecho, como billing e invoice, o un verdadero se contará dos veces. No añadas una pregunta comodín si nadie la va a leer; una probabilidad baja ya es motivo para abstenerse. El campo noul es la probabilidad de sí, de 0 a 1. No hay un campo confidence aparte. Un valor cerca de 0,5 es incierto: envía esa etiqueta a una persona. No trates un valor alto en ocho preguntas como ocho etiquetas confirmadas hasta medir los falsos positivos por etiqueta. Una petición puede mezclar un Choice (la ruta principal) y varios Noul, siempre que el total sea de 1 a 8 preguntas. Ocho Noul siguen siendo una ejecución. El ejemplo de abajo es una forma de petición, no un resultado registrado. Los umbrales salen de tus labels, no de números de muestra que imagines. Ver question-types y confidence-and-abstention.

curl --fail-with-body https://jevmodel.app/api/v1/systemone \
  -H "Authorization: Bearer $JEVMODEL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"state":"I was charged twice and exporting a report now takes two minutes.","questions":{"billing":{"type":"noul","instructions":"Is a billing or charge issue present in this text?","criteria":{"true":"The text mentions charges, invoices, refunds, or payment.","false":"The text does not mention a billing issue."}},"performance":{"type":"noul","instructions":"Is a performance or speed problem present in this text?","criteria":{"true":"The text describes slowness, timeouts, or a speed regression.","false":"The text does not describe a performance problem."}}}}'

No aplanes treinta labels en un Choice. El máximo es doce, y una lista plana tan larga hace que las descripciones se solapen. Primera petición: un Choice padre que incluya una opción explícita de revisión. Segunda petición: solo los criteria hijos del padre elegido, y solo cuando la confidence de ese padre supere un umbral que hayas medido. Si no, una persona elige el hijo. Cada llamada se cobra aparte. No hay clave de idempotencia, así que escribe la petición en tu historial antes de reintentar una respuesta perdida. Si necesitas más de ocho etiquetas Noul, divídelas en dos peticiones con el mismo state e ids de pregunta disjuntos, y guarda ambas respuestas bajo un id de fila que generes tú. Las dos llamadas no se ven. Un Decision Flow puede dibujar esa rama en la consola, pero ejecutar un flow es solo para planes de pago: suscríbete o compra un paquete de tokens. Los flows no usan las ejecuciones gratis del día. Ver decision-flows. Cada petición validada, preguntas incluidas, debe caber en 8.000 caracteres.

No reduzcas el resultado a un solo número de exactitud. Un comentario con dos etiquetas verdaderas cuenta dos veces. Para cada etiqueta, cuenta falsos positivos y falsos negativos en un conjunto reservado, o informa precisión y recall por etiqueta si ya los calculas. Un modelo que nunca predice una etiqueta rara puede verse fuerte en un promedio único y aun así perder esa etiqueta cada semana. Batch en Console exporta respuestas por fila y no calcula estos recuentos; únelos en tu propio script. Puntúa una lista JSON y una corrida multi_label de Hugging Face en las mismas filas si esas son las alternativas. Las puntuaciones de Hugging Face son señales de implicación NLI; rechaza cualquier nombre generado que no esté en tu taxonomía antes de la unión. La ruta zero-shot es zero-shot-text-classification. La división del conjunto reservado y el hábito de revisar tras un cambio de criteria son evaluation. Las cuentas gratuitas verificadas comparten 5 ejecuciones exitosas por día UTC entre Playground, cada fila de Batch y la API. Una segunda pasada es una segunda ejecución.

No devolverá una lista abierta de etiquetas que no nombraste. No lee imágenes, audio ni adjuntos. No es una cabeza multietiqueta entrenada que puedas descargar, y el producto no es open source. Choice no emitirá dos labels ganadores desde una pregunta. Las probabilidades Noul de preguntas distintas no son partes de una distribución, así que no tienen que sumar 1 y tampoco deben promediarse en una sola confianza. Reparar un JSON generativo es tu código, no un campo de esta respuesta. Si el texto es un hilo de email en bruto, límpialo con los pasos de email-classification antes de hacer varias preguntas de etiqueta. Si solo necesitabas el tema principal de producto, vuelve a customer-feedback-classification en lugar de etiquetar cada sinónimo.