実例で学ぶ：未着の荷物を Jev でどう振り分けるか

担当者が最初に決めることは何か

1. 顧客：「昨日配達済みと表示されますが、荷物がありません。今日必要です。すぐ返金できますか。」
2. この判断は最初の担当先を配送、請求、技術、人による確認から選ぶことです。返金は別の権限付き処理です。
3. アプリが注文の所有者と配送済みの記録を確認しました。署名者は不明です。渡していない事実を Jev は知りません。

01 · 動作の境界を決める

事実がそろい、自分の事例で検証した条件を満たすときだけ、取り消せる担当先の割り当てを自動化します。情報不足、複数の要件、不確実な結果、API エラーは人へ渡します。返金は本人、注文、規則の確認が必要です。

02 · state を作る

今回の文面と確認済みの配送記録を使い、顧客の主張と配送会社の記録を分けます。不要な氏名、住所、電話、決済情報を除きます。注文が見つからない場合は先に情報を集めます。

03 · 三つの質問に分ける

Choice は最初の担当先を選び、Noul は時間的な緊急性を確認し、Score は定義済みの尺度で文面を評価します。答えは独立しています。緊急度は順番に使えても、返金の権限にはなりません。

04 · 説明用の返り値を読む

Choice が shipping、confidence が 0.84、Noul が 0.91、Score が中程度と仮定します。自分の事例で定めたしきい値が 0.88 なら、人の確認へ送ります。数値は実測値でも推奨値でもありません。

05 · 壊れる例を調べる

返金だけの文は候補の不足を示し、配送記録がなければ先に取得します。配送と二重請求が重なるなら分割または人へ。「急いでいない」の否定や多言語の文も回帰試験に残します。

出所を示した最小の state

customer_claim: 配達済み表示だが未着; today_needed: true
verified_order_owner: true; carrier_status: delivered
signature: unknown; refund_authorized: not_checked

一つの state に三つの質問

公式 API の形式を参考にした架空例です。実際に送る前に最新の制約と利用権限を確認してください。

{
  "state": "customer_claim: 配達済み表示だが未着; today_needed: true\nverified_order_owner: true; carrier_status: delivered\nsignature: unknown; refund_authorized: not_checked",
  "model": "jev-latest",
  "questions": {
    "team": {
      "type": "choice",
      "instructions": "Which team should handle this ticket first?",
      "criteria": {
        "shipping": "Delivery, tracking, missing parcel",
        "billing": "Charges, payment, subscription",
        "technical": "Product bug or integration",
        "review": "More than one intent or insufficient information"
      }
    },
    "urgent": {
      "type": "noul",
      "instructions": "This message expresses time sensitivity."
    },
    "tone": {
      "type": "score",
      "instructions": "How distressed does the customer appear?",
      "criteria": [
        "Calm, factual",
        "Concerned but civil",
        "Strong distress or anger"
      ]
    }
  }
}

説明用の数値を実測と混同しない

数値は当サイトが説明のために作成しました。Choice と Score の confidence と probabilities は別項目です。Noul は noul を返します。ID、型、必須項目を確認してから動作を決めます。

{
  "answers": {
    "team": {
      "type": "choice",
      "choice": "shipping",
      "confidence": 0.84,
      "probabilities": {
        "shipping": 0.81,
        "billing": 0.1,
        "technical": 0.02,
        "review": 0.07
      }
    },
    "urgent": {
      "type": "noul",
      "noul": 0.91
    },
    "tone": {
      "type": "score",
      "score": 1.0,
      "confidence": 0.78,
      "probabilities": {
        "0": 0.08,
        "1": 0.82,
        "2": 0.1
      }
    }
  }
}

モデル実行前に正解を付ける六つの例

公開に必要な確認

1. 対象業務から個人情報を除いた例を集め、担当先と自動振り分けの可否を人が付けます。よくある例と重大なまれな例を分けます。
2. 一部の例で条件を調整し、別の例で検証します。重大な誤配分、人の確認率、処理全体の時間、千件当たりの費用を測ります。
3. まず少量の流量と取り消せる処理で試し、版、要求 ID、人による修正を記録します。モデルや候補の変更後は再評価します。