Classificação de texto multilabel: um Choice, várias perguntas sim/não ou uma segunda passagem

Olhe a ação, não o folheto do modelo. “Fui cobrado duas vezes e a exportação agora leva dois minutos” é ao mesmo tempo um problema de cobrança e de desempenho. Se o passo seguinte é “entregar ao único time que deve responder”, você quer um rótulo principal: veja intent-classification e text-classification-api. Se o passo seguinte é “marcar cada tema aplicável para o relatório semanal não perder um deles”, você quer multilabel. Forçar um Choice esconde um dos dois fatos. Esta página trata desse contrato. Ela não substitui o guia de um único pedido e não reescreve o interruptor do Make “atribuir só uma categoria”: esse controle vive no Make, descrito em make-categorize-text. O feedback de clientes que só precisa do tema principal e de uma prioridade fica em customer-feedback-classification.

Escolha a forma que o seu armazém consegue guardar. A tabela é um mapa de contratos, não um ranking. Nenhuma opção elimina a necessidade de contar tags falsas nas suas próprias linhas rotuladas.

Escreva cada Noul como uma proposição: “Há um problema de cobrança?” Dê criteria.true e criteria.false como descrições curtas, de 2 a 350 caracteres cada, e instructions de 8 a 600 caracteres. Os ids seguem a regra do Choice: uma letra inicial e depois minúsculas, dígitos e sublinhados, no máximo 40 caracteres. Não faça duas perguntas que signifiquem o mesmo fato, como billing e invoice, ou um verdadeiro será contado duas vezes. Não acrescente uma pergunta genérica se ninguém for lê-la; uma probabilidade baixa já é motivo para se abster. O campo noul é a probabilidade de sim, de 0 a 1. Não há um campo confidence separado. Um valor perto de 0,5 é incerto: envie essa tag a uma pessoa. Não trate um valor alto em oito perguntas como oito tags confirmadas antes de medir os falsos positivos por tag. Um pedido pode misturar um Choice (a rota principal) e vários Noul, desde que o total seja de 1 a 8 perguntas. Oito Noul continuam sendo uma execução. O exemplo abaixo é uma forma de pedido, não um resultado registrado. Os limiares vêm dos seus rótulos, não de números de amostra imaginados. Veja question-types e 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."}}}}'

Não espalhe trinta rótulos num único Choice. O máximo é doze, e uma lista plana tão longa faz as descrições se sobreporem. Primeiro pedido: um Choice pai que inclua uma opção explícita de revisão. Segundo pedido: só os criteria filhos do pai escolhido, e só quando a confidence desse pai passar um limiar que você mediu. Caso contrário, uma pessoa escolhe o filho. Cada chamada é cobrada à parte. Não há chave de idempotência, então grave o pedido no seu histórico antes de tentar de novo uma resposta perdida. Se precisar de mais de oito tags Noul, divida em dois pedidos com o mesmo state e ids de pergunta sem sobreposição, e guarde as duas respostas sob um id de linha que você gerar. As duas chamadas não se veem. Um Decision Flow pode desenhar esse ramo no console, mas executar um flow é só para planos pagos: assine ou compre um pacote de tokens. Flows não usam as execuções grátis do dia. Veja decision-flows. Cada pedido validado, incluindo as perguntas, precisa caber em 8.000 caracteres.

Não reduza o resultado a um único número de acurácia. Um comentário com duas tags verdadeiras conta duas vezes. Para cada tag, conte falsos positivos e falsos negativos num conjunto reservado, ou informe precisão e recall por tag se você já calcula isso. Um modelo que nunca prevê uma tag rara pode parecer forte numa média única e ainda perder essa tag toda semana. O Batch no Console exporta respostas por linha e não calcula essas contagens; una-as no seu próprio script. Pontue uma lista JSON e uma execução multi_label da Hugging Face nas mesmas linhas se essas forem as alternativas. Os scores da Hugging Face são sinais de entailment NLI; rejeite qualquer nome gerado que não esteja na sua taxonomia antes da união. O caminho zero-shot é zero-shot-text-classification. A divisão do conjunto reservado e o hábito de rever após uma mudança de criteria são evaluation. Contas gratuitas verificadas compartilham 5 execuções bem-sucedidas por dia UTC entre Playground, cada linha do Batch e a API. Uma segunda passagem é uma segunda execução.

Ela não devolve uma lista aberta de tags que você não nomeou. Ela não lê imagens, áudio nem anexos. Não é uma cabeça multilabel treinada para download, e o produto não é open source. Choice não emite dois rótulos vencedores a partir de uma pergunta. As probabilidades Noul de perguntas diferentes não são partes de uma distribuição, então não precisam somar 1 e também não devem ser médias numa única confiança. Reparar um JSON generativo é o seu código, não um campo desta resposta. Se o texto ainda é um fio de e-mail bruto, limpe-o com os passos de email-classification antes de fazer várias perguntas de tag. Se você só precisava do tema principal de produto, volte a customer-feedback-classification em vez de marcar cada sinônimo.