多标签文本分类：一次 Choice、多道是否题，还是第二轮请求

看的是动作，不是模型宣传页。“我被扣了两次款，而且导出现在要两分钟”既是账单问题也是性能问题。下一步如果是“交给唯一该回复的团队”，你要的是一个主要标签：见 intent-classification 和 text-classification-api。下一步如果是“打上每一个适用主题，免得周报丢掉其中一个”，你要的是多标签。硬用 Choice 会藏起两个事实中的一个。本页负责这个契约。它不替代单次请求的操作说明，也不重写 Make 的“只指定一个类别”开关——那个控件在 Make 里，见 make-categorize-text。只需要主要主题加优先级的用户反馈，留在 customer-feedback-classification。

先选仓库能存下的形状。下表是契约地图，不是排行。任何一种做法都不能省掉：在你自己的标注行上数错误标记。

每道 Noul 写成一个命题：“是否存在账单问题？” criteria.true 和 criteria.false 各写一段短说明，每段 2 到 350 字符，instructions 为 8 到 600 字符。问题 id 与 Choice 相同：字母开头，其后为小写字母、数字和下划线，最多 40 字符。不要问两个意思相同的问题，例如 billing 和 invoice，否则一次为真会被数成两次。没有人会读的兜底问题就不要问；概率偏低本身就是弃权的理由。字段 noul 是“是”的概率，从 0 到 1。没有单独的 confidence 字段。接近 0.5 表示不确定：把这个标记交给人。在按标记测过假阳性之前，不要把八道问题上的高数值当成八个已确认标记。一次请求可以混合一个 Choice（主要路由）和多道 Noul，只要问题总数在 1 到 8。八道 Noul 仍是一次运行。下面的示例是请求形状，不是一次真实记录。阈值来自你的标签，不是来自你想象的样例数字。见 question-types 和 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."}}}}'

不要把三十个标签摊进一个 Choice。上限是十二个，而且这么长的平铺列表会让描述重叠。第一次请求：父级 Choice，带一个明确的复核选项。第二次请求：只包含被选中父级的子级 criteria，并且只在该父级的 confidence 超过你测过的阈值时才发。否则由人来选子级。每次调用单独计费。没有幂等键，所以响应丢失时，重试前先把请求写入你的历史。如果 Noul 标记超过八个，拆成两次请求：state 相同，问题 id 互不重叠，两次答案都存在你自己生成的行 id 下面。这两次调用互相看不见。Decision Flow 可以在控制台画出这个分支，但运行 Flow 仅限付费方案：订阅或购买 Token 包。Flow 不使用每日免费次数。见 decision-flows。每一次校验后的请求，包括问题在内，都必须放进 8,000 字符。

不要把结果收成一个准确率数字。一条带两个真实标记的评论要数两次。对每个标记，在留出集上数假阳性和假阴性；如果你本来就会算，也可以按标记报告精确率和召回率。一个从不预测罕见标记的模型，在单一平均值上可以显得很强，却每周都丢掉那个标记。Console 的 Batch 导出逐行答案，不算这些计数；在你自己的脚本里对齐。如果备选方案是 JSON 列表或 Hugging Face 的 multi_label，就在同一批行上打分。Hugging Face 的分数是 NLI 蕴含信号；对齐之前，拒绝任何不在你分类法里的生成名字。零样本路径见 zero-shot-text-classification。留出集的划分，以及 criteria 变更后重新检查的习惯，见 evaluation。已验证的免费账号在 Playground、Batch 的每一行和 API 之间共用每 UTC 日 5 次成功运行。第二轮就是第二次运行。

它不会返回你没有命名的开放标签列表。它不读取图片、音频或附件。它不是可以下载的、训练好的多标签模型头，产品也不是开源的。Choice 不会从一道题里给出两个获胜标签。不同问题上的 Noul 概率不属于同一个分布，所以不必加总为 1，也不可以平均成一个置信度。修补生成式 JSON 是你的代码，不是这个响应上的字段。如果文本仍是原始邮件线程，先按 email-classification 的步骤清理，再问多道标记题。如果你只需要主要的产品主题，回到 customer-feedback-classification，不要给每个同义词都打标记。