信頼度

confidence は確率分布から導出される統計量です。probabilities との関係、およびリスクに応じてしきい値をどのようにスケーリングするかを理解してください。

本文はzh-CNからの機械翻訳です。校正は未実施で、参考情報としてのみご利用ください。

2つのフィールドの関係

すべての Choice および Score 回答には、各選択肢（Choice）または各スコアレベル（Score）における確率分布を示す probabilities プロパティが含まれています。

この分布の形状は、モデルがどの程度確信を持っているかを示します：ある結果に集中している場合は確信が高く、広く分散している場合は不確実性が高いことを意味します。

confidence プロパティは、この形状を 0 から 1 の間の数値に圧縮し、自分で計算を行わずに直接しきい値を設定できるようにします。

注意：Noul 回答には confidence が含まれていません。Noul はそのものが 0 から 1 の確率値です。

分布形状の意味

Choice の信頼度が低い場合、通常はどの選択肢も他の選択肢よりも明確に優れているわけではないことを意味します。
Score の信頼度が低い場合、通常はスコアレベルの定義に曖昧さがある、多次元的である、または state 内の情報が判断に不十分であることを意味します。

「わからない」というのは有用なシグナルです

人間であれ機械であれ、不確実性を正直に表現できないインテリジェントなシステムは信頼できません。

信頼度は、モデルに「これは不確実です」と言うための組み込みメカニズムを提供します。これにより、コードは異なる確信度レベルに対して異なる動作を実装でき、これは真に信頼性の高いシステムを構築する基盤となります。

3つのブランチ

実用的な出発点として、信頼度を3つのセグメントに分割し、それぞれに異なるシステム動作を対応させることができます：

高信頼度：自動実行。モデルが明確な判断を下しており、人間の介入は不要です。
中信頼度：慎重に進める。モデルは妥当な回答を提供していますが、確信は持てません。文脈に応じて、ユーザーの確認を求める、レビュー待ちとしてマークする、または追加情報を収集します。
低信頼度：実行しない。人間に転送するか、明確化を要求するか、他のシステムにフォールバックします。モデルは情報が不足している、またはこの問題が自身に適していないことを伝えています。

境界線はどこに引くか？それはリスクの大きさ次第です。

リスクに応じたしきい値のスケーリング

これが最も重要な実践原則です：信頼度のしきい値は単一の数値ではありません。

同じシステム内でも、異なるアクションは「誤った場合の結末」に応じて異なるしきい値で設定されるべきです。

response = client.system_one(
    state=user_message,
    questions={
        "action": Choice(
            instructions="What is the user trying to do?",
            criteria={
                "check_balance": "View account balance",
                "approve_transfer": "Approve the pending withdrawal request",
                "support": "Get help with an issue",
            },
        ),
    },
)

action = response.answers["action"]
confidence = action.confidence

if confidence < 0.5:
    # モデルは確かに不確実です。推測しないでください。
    route_to_human(user_message)

elif action.choice == "check_balance":
    # リスクが低い。表示ミスは回復可能です。
    show_balance(account_id)

elif action.choice == "approve_transfer":
    if confidence > 0.9:
        # リスクが高い + 信頼度が高い。確認付きで実行します。
        confirm_then_execute(account_id)
    else:
        # リスクが高い + 中程度の信頼度。まず検証します。
        ask_user_to_confirm(account_id)

このコードには、それぞれ異なるリスクレベルに対応する3つの異なるしきい値があります：

アクション	リスク	しきい値
0.5 未満は一律ブロック	—	硬下限。モデル自身が不確実であると認識している場合を捉えます
`check_balance`	低い。読み取り専用で回復可能	0.5 以上であれば自動実行可能
`approve_transfer`	高い。資金に関わる	> 0.9 が必要であり、依然としてユーザー確認が必要

0.5 という下限は、モデルが報告する「確かに不確実である」ケースをブロックします。それ以上では、破壊的な操作を実行するために必要なしきい値は、読み取り専用操作よりもはるかに高くなります。あなたのコードは、あなたのリスク許容度をエンコーディングしています。

注意：適切なしきい値の値は、あなたのドメインと、あなたのユースケースにおけるモデルの実際のパフォーマンスに依存します。保守的なしきい値から始め、独自のデータでテストし、観察結果に基づいて調整してください。

独自のメトリクスを定義できる

公式に提供される confidence は、ほとんどのユースケースに適した便利なメトリクスですが、その定義に縛られる必要はありません。何を評価するかによって、他のメトリクスの方が適している場合があります——まさにそれが probabilities も同時に返される理由です：完全な分布が手に入るため、自分で計算できます。

例えば、2つの候補選択肢間の確率差（マージン）は、集中度よりも「自動実行すべきかどうか」を反映する上で、特定のシナリオではより適している場合があります。あるいは、トップ1の確率のみを見て、他を無視することもできます。選択はあなた次第です。