設計の手順
正解と処理を先に決める
架空の依頼：「決済に失敗したが、来月の更新も止めたい」。単一の担当か複数意図かを決め、優先順位と曖昧さの規則を書きます。
三つの量を分ける
選択肢の確率、confidence、反復時の一致率は異なります。Noul に confidence はありません。リスクを問う質問の高い値を実行許可と誤解しません。
同じ入力の変動を調べる
state、質問、モデル版、方針を固定します。言い換えや無関係な項目の変更は別の実験です。分布、失敗、時間、キャッシュ状態を保存します。
追加呼出より先に保留を設計する
曖昧な依頼は人へ回すか補足を聞きます。多数決は共通の偏りを残すことがあります。検証で費用と誤りの改善が確認できた場合だけ、上限付きで追加します。
正解率と処理率を同時に見る
billing、billing、cancel の三回は多数を示すだけです。未使用テストで自動処理の誤り、全体の処理率、人の負担を言語や曖昧さごとに測ります。
具体例 · 本サイトの架空データ
| 観察した事実 | 判断 | コードでの処理 |
|---|---|---|
| 全回 billing、正解規則は cancel | 一致していても誤り | 失敗を保存して設計を調べる |
| billing、billing、cancel | 多数は事実を作らない | 確認へ回す |
| リスクの Noul が高い | 権限ではない | リスク用の処理へ |
コピーできる設計例
独自の例です。JSON はリクエストや入力の形、Python は架空スコアの計算のみを示します。API は実行しません。接続前に公式仕様と処理方針を確認してください。
# Offline example: invented labels, not API results.
from collections import Counter
labels = ["billing", "billing", "cancel"]
majority, count = Counter(labels).most_common(1)[0]
print(majority, count / len(labels))
# Agreement alone does not establish accuracy.
review_required = len(set(labels)) > 1
print("review:", review_required)よくある失敗
- 一致率を正解率と呼ぶ。
- 最大確率を confidence と呼ぶ。
- 望む回答まで再質問する。
TRY / THINK / COMPARE
先に考えてから解説へ
一入力で五回同じなら信頼できますか？
解説を開く
まだ分かりません。人の正解、多様な例、独立テストが必要です。条件と小さな観測範囲を明記します。
提出前の確認
- 正解規則と曖昧さを定義。
- 分布・版・キャッシュ状態を記録。
- 追加呼出に上限。
- テストでしきい値を選ばない。
よくある質問
反復で必ず正確になりますか？
保証しません。実際の誤りが直るか調べます。
保留は失敗ですか？
設計できる結果です。処理率と確認負担も測ります。
参考資料
公式パターンと Datawhale の実践テーマを参考に、説明・例・演習を独自に作成しています。API の実行結果や性能測定ではありません。