Cold-start問題は、
技術的な問題だと思われている。
-
データが足りない
-
モデルが学習できない
-
精度が出ない
だから人は言う。
「データを集めよう」
だが本当にそれだけだろうか。
Cold-startの本質は、
データ不足ではない。
それは、
判断境界が未定義である状態
である。
そしてそれは、
設計の問題だ。
Cold-startとは何か
Cold-startとは、
-
新規ユーザー
-
新規商品
-
新規事業
-
新規市場
-
新制度
つまり、
履歴がない状態だ。
履歴がないということは、
-
統計的安定がない
-
分布が見えない
-
しきい値が定まらない
だがここで重要なのは、
どこで自動化を止めるのか？
という問いである。
なぜCold-startは危険なのか
通常のモデルは、
過去分布に依存している。
しかしCold-startでは、
-
類似度が信用できない
-
スコアが偶然に近い
-
推定の分散が大きい
この状態で自動決定すると、
誤判定は偶然になる。
だが最も危険なのはそこではない。
判断の責任が曖昧になることだ。
なぜなら、
「データがなかったから」
という言い訳が成立してしまうからだ。
Cold-startを契約として扱うとは何か
ここで発想を変える。
Cold-startを
例外状態ではなく、契約状態にする。
つまり：
-
データ不足の定義を明示する
-
自動判断の条件を宣言する
-
停止条件を固定する
Cold-startは事故ではない。
設計された状態であるべきだ。
契約化の第一原理：状態を型にする
まずやるべきことは、
Cold-startを明示的な状態として定義することだ。
例：
-
data_points < N
-
uncertainty > threshold
-
confidence_interval > X
-
coverage_ratio < Y
これをスキーマに固定する。
state: "COLD_START"
reason: "insufficient_history"
auto_decision: false
requires_human_review: true契約化の第二原理：自動化範囲を固定する
Cold-start状態では、
-
自動実行しない
-
推奨のみ出す
-
限定アクションのみ許可する
-
信用上限を下げる
これを契約として宣言する。
重要なのは、
モデルの精度に任せないことだ。
境界は設計で決める。
契約化の第三原理：fail-closedを標準にする
Cold-startでは、
最悪ケースを想定する。
-
スコアが高くても実行しない
-
異常値は保存しない
-
分布外は拒否する
fail-openではなく
fail-closedを標準にする。
なぜなら、
未知は常に危険側に倒すべきだからだ。
Cold-startは責任のテストである
Cold-startは、
システムがどこまで責任を設計しているかのテストだ。
大量データ時代は、
設計の粗さを隠せる。
だがCold-startでは、
-
しきい値の根拠
-
例外処理の設計
-
人間介入条件
が露呈する。
Cold-startは、
倫理の試験紙である。
メタ学習との違い
メタ学習は、
少数データへの適応を改善する。
だがそれは
「型の内側の適応」
である。
Cold-start契約は、
「型そのものの設計」
である。
適応と境界は別問題だ。
Human-as-Authorの出番
Cold-start契約を書くのは、
モデルではない。
人間だ。
-
どこで停止するか
-
どこまで信用するか
-
どのリスクを許容するか
これは統計ではなく、価値判断である。
だからこそ、
Human-as-Authorが必要になる。
実践的な構造
正しいCold-start設計はこうだ：
-
Cold-start状態を明示的に定義
-
状態をDSL / Schemaで固定
-
自動化範囲を契約化
-
人間承認を必須化
-
履歴蓄積で段階的に解除
Cold-startは「一時的な無知」ではない。
段階的に解除される契約状態である。
結論
Cold-startはデータ問題ではない。
設計問題だ。
Cold-startを契約として扱え。
-
状態を型にせよ
-
境界を宣言せよ
-
停止条件を固定せよ
-
fail-closedを標準にせよ
AIは連続を近似する。
だが未知の領域では、
連続は信用できない。
だからこそ、
不連続を守る型が必要になる。
Cold-startは例外ではない。
責任を設計できているかを試す瞬間である。
コメント