Jev の confidence

Confidenceは確率から導出されます

Choiceでは、分布は各選択肢に対する確率です。Scoreでは、各レベルに対する分布です。分布が平坦なほどconfidenceは低くなります。Choiceでconfidenceが低い場合、どの選択肢も明確な勝者ではないことがよくあります。Scoreでconfidenceが低い場合、レベルが曖昧、多次元的、またはstateに判断材料が足りないことがよくあります。

TypeSafeはconfidenceを便利なデフォルトとして提示しますが、それに固定するものではありません。判断内容によっては、別の方法で分布を要約した方が適する場合があります。ドキュメントではそうしたレシピを別のクックブックにまとめつつ、1つの式に縛られないよう、すべてのChoiceとScoreの回答で確率も返します。

Noulの回答には[0, 1]のnoulだけが含まれます。Noulへコピーできるconfidenceフィールドはありません。0.5に近い値は、モデルがその二択質問を決めきれないという意味です。0.5を「返金度が中程度」と解釈しないでください。Choiceのconfidenceしきい値をnoulに流用せず、別々の2問におけるP(noul) + P(not noul)が1になるとも考えないでください。

コード内の3つの経路

出発点として有用なのは3段階です。confidenceが高い場合は自動実行。confidenceが中程度なら慎重に進め、ユーザーに確認する、レビュー対象にする、またはstateを追加収集します。confidenceが低い場合は実行せず、担当者へ回す、確認質問をする、または別のシステムへフォールバックします。境界をどこに置くかはリスクの大きさ次第です。

confidenceのしきい値は、製品全体で共通の1つの数値ではありません。意図を誤認して残高画面を表示しても復旧できますが、出金の承認はそうではありません。TypeSafeの例では、真に不確かな領域の下限を0.5で分け、送金の確認・実行には>0.9を要求する一方、残高確認の意図にはより低い基準を認めています。コードにリスク許容度を組み込みます。Jevが報告するのは分布だけです。

知的システムが不確実性を正直に表せないなら、そのシステムは信頼できません。ConfidenceはChoiceとScoreにおける、そのためのシグナルです。字面どおりの文言、計算はコードで行う、生成には使わない、というjaggednessの制約と組み合わせてください。書き方の悪い指示に対する高confidenceのChoiceも、間違った問いへの自信ある回答にすぎません。

同じチケットでのNoulとChoiceの比較

常識的な不変条件についてのTypeSafeのjaggedness記録では、「フィット感に満足していません。どのような選択肢がありますか？」というチケットを扱っています。Noul「顧客は返金を求めているか？」の結果は0.22でした。同じ文面に対するはい／いいえ形式のChoiceでは、確率がはい0.01／いいえ0.99、confidenceが0.97でした。比較対象となる数値はnoulとprobabilities["yes"]であり、相互に置き換えることはできません。

2件目のチケットでは、返金と非返金に対する2つのNoulsの合計が1.19になりました。別々の質問間で、モデルに算術的恒等式を求めないでください。選択肢に対するChoiceは相対的な値で、どの選択肢かを示します。各Noulは絶対値であり、すべての選択肢で低くなる場合があります。スキル提案クックブックでは両方を使い、Choiceでスキルを選び、Noulsでそもそも提案するかを決めます。

ゲートを実装するときは、しきい値表にプリミティブ名を記載してください。「0.8」だけでは、departmentに対する0.8のChoice confidenceなのか、urgencyに対する0.8のNoulなのか分からず、意味がありません。プリミティブ、キー、生の確率、バージョン付きモデルID jev-1.13.0を記録し、後のエイリアス変更で本番ゲートが気付かないうちに再調整されないようにします。

ゲートの運用

argmaxとconfidenceスカラーだけでなく、完全な確率を保存してください。Choiceがおかしい場合、2位の選択肢がデバッグの手掛かりになることがよくあります。Scoreがレベル間で行き詰まって見える場合、分布を見れば、基準説明が曖昧なのか、stateが空なのか判断できます。

モデルIDを変更したら必ず再調整してください。jev-latestは移動する可能性があります。jev-1.13.0のしきい値0.9が、次の公式リリースでも同じ意味になる保証はありません。本番エイリアスを切り替える前に、新しいIDならどう動作したかを1週間シャドーログに記録してください。

高リスクの操作では、ラベルとconfidenceの下限を両方満たしたうえで、製品側でも確認を求めるべきです。TypeSafeの送金例では、不確かさの下限に0.5、実行前に0.9を使います。真似るべきは構成であり、数値そのものとは限りません。返金ポリシーとゲーム内BANポリシーで同じしきい値は使えません。運用手順書では、プリミティブ名の横に数値を記載してください。

オンコール担当者に確率を隠さないでください。緑/赤のconfidenceしか表示しないダッシュボードでは、confidenceが高いままyesとnoが入れ替わったことが分かりません。分布そのものが成果物であり、スカラーはその上でTypeSafeが算出する便宜的な値です。

Noulが0.5付近なら、二択に対する正直な「分からない」を意味します。そこに付与するconfidenceフィールドはありません。第2の軸が必要なら、別の質問をするか、明示的な基準を持つyes/no/not-sureのChoiceを追加し、noulとは異なる統計量であることを受け入れてください。

質問キーごとにconfidenceを毎週プロットしてください。0.5へ緩やかに近づくなら、基準がチケットに合わなくなっています。ノイズの多いキューで1.0方向へ急上昇するなら、世界が単純になったのではなく、選択肢が実質的に1つへ潰れています。

エイリアスの変更が週次グラフに埋もれないよう、すべてのしきい値と並べてjev-1.13.0を記録してください。