マルチラベルテキスト分類：1つのChoice、複数のはい/いいえ、それとも2回目のリクエストか

見るのは動作であり、モデルの紹介文ではありません。「二重に請求され、エクスポートが2分かかる」は、請求の問題であり性能の問題でもあります。次の一歩が「返信すべき1つのチームに渡す」なら、主要ラベルが1つ要ります。intent-classification と text-classification-api を参照してください。次の一歩が「当てはまるテーマをすべて付け、週次報告で片方を落とさない」なら、マルチラベルが要ります。Choice を無理に使うと、2つの事実の一方が隠れます。このページがその契約を扱います。単一リクエストの手順の代わりにはならず、Makeの「カテゴリを1つだけ割り当てる」スイッチの書き直しでもありません。その制御は Make 側にあり、make-categorize-text にあります。主要テーマと優先度だけで足りる顧客フィードバックは customer-feedback-classification に残します。

ウェアハウスが保存できる形から選んでください。下表は契約の地図であり、順位表ではありません。どの選択肢も、自社のラベル付き行で誤ったタグを数える作業を省けません。

各Noulは1つの命題にします。「請求の問題があるか？」 criteria.true と criteria.false は短い説明で、それぞれ2〜350文字、instructions は8〜600文字です。質問 id は Choice と同じ規則です。先頭は英字、その後は小文字、数字、アンダースコア、最大40文字。billing と invoice のように同じ事実を指す問いを2つ置かないでください。真が1回なのに2回数えます。誰も読まない受け皿の問いは作らないでください。確率が低いこと自体が棄権の理由です。フィールド noul は「はい」の確率で、0から1です。別の confidence フィールドはありません。0.5付近は不確実です。そのタグは人へ回します。タグごとの偽陽性を測る前に、8問の高い数値を8つの確定タグとみなさないでください。1つのリクエストで Choice（主要ルート）1つと複数の Noul を混ぜられます。合計が1〜8問である限りです。Noulが8つでも実行は1回です。下の例はリクエストの形であり、記録された結果ではありません。しきい値はあなたのラベルから決まり、想像上のサンプル数値からではありません。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."}}}}'

30個のラベルを1つのChoiceに平らに並べないでください。上限は12で、それだけ長い一覧は説明が重なります。1回目：明示的なレビュー選択肢を含む親のChoice。2回目：選ばれた親の子criteriaだけを送り、その親のconfidenceが、測定したしきい値を超えたときだけにします。そうでなければ子は人が選びます。各呼び出しは別々に課金されます。冪等キーはないので、失われた応答を再試行する前に、リクエストを自分の履歴へ書いてください。Noulタグが8を超えるなら、同じstateで質問idが重ならない2つのリクエストに分け、自分で作った行idの下に両方の答えを保存します。2つの呼び出しは互いを見ません。Decision Flow でこの分岐をコンソールに描けますが、Flowの実行は有料プランのみです。サブスクリプションまたはトークンパックを購入してください。Flowは毎日の無料実行を使いません。decision-flows を参照してください。検証後の各リクエストは、質問を含めて8,000文字以内です。

結果を1つの正解率にまとめないでください。真のタグが2つあるコメントは2回数えます。各タグについて、ホールドアウトで偽陽性と偽陰性を数えるか、すでに計算しているならタグごとの適合率と再現率を出します。まれなタグを一度も予測しないモデルは、単一の平均では強く見えても、そのタグを毎週落とします。Console の Batch は行ごとの答えを書き出しますが、これらの件数は計算しません。自分のスクリプトで結合します。代替が JSON 一覧や Hugging Face の multi_label なら、同じ行で採点します。Hugging Face のスコアは NLI の含意信号です。結合の前に、分類体系にない生成名は拒否します。ゼロショットの経路は zero-shot-text-classification。ホールドアウトの分け方と、criteria 変更後に見直す習慣は evaluation にあります。確認済みの無料アカウントは、Playground、Batch の各行、API で UTC日あたり成功 5 回を共有します。2回目のパスは2回目の実行です。

名前を付けていないタグの自由な一覧は返しません。画像、音声、添付は読みません。ダウンロードできる学習済みマルチラベルヘッドではなく、製品はオープンソースでもありません。Choice は1つの質問から勝ちラベルを2つ出しません。別の質問の Noul 確率は1つの分布の一部ではないので、合計を1にする必要はなく、1つの信頼度に平均してもいけません。生成JSONの修復はあなたのコードであり、この応答のフィールドではありません。テキストが生のメールスレッドなら、複数のタグ質問の前に email-classification の手順で整えてください。必要なのが主要な製品テーマだけなら、customer-feedback-classification に戻り、同義語ごとにタグを付けないでください。