Jevは、ソフトウェアの中へ小さな判断を置く方法として面白い。
でも、便利そうだからとアプリの判断を全部Jevへ渡すと、あとで苦しくなる気もしている。
型どおりの答えが返ることと、判断そのものが正しいことは別だ。外部サービスへ依存すれば、価格、仕様、遅延も変わる。
だから本番へ入れる前に、入口より出口を作っておきたい。
「hallucinationしない」は「間違えない」ではない
Jevの公式サイトには「No hallucinations」とある。
その説明では、自由な文字列を生成せず、あらかじめ決めた型の値だけを返すため、出力空間にない情報を作らないという意味で使われている。Jev公式サイト
これは「判断を間違えない」という意味ではない。
決めた選択肢以外の変な文章を返さないことと、正しい選択肢を選ぶことは別だ。
たとえば「安全」「危険」の二択しか返さないとしても、本当は危険なのに「安全」を選ぶ可能性はある。
だから、ラベルだけでなく確率を見る必要がある。そして、その確率が自分のデータでも信頼できるかを確かめる必要がある。
低い確率を、人間へ戻すために使う
確率は、正しさを飾る数字ではない。
次に何をするかを決めるための数字だ。
result = judge(state)
if result.probability < 0.60:
ask_human()
elif result.choice == "stop":
stop()
else:
continue_process()確率が低ければ人間へ戻す。高い影響がある操作なら、確率に関係なく確認する。Jevへ到達できなければ、安全な既定値へ戻す。
重要なのは、確率のしきい値を雰囲気で決めないことだ。
過去の判断と正解を集め、「0.8以上なら実際にどの程度正しかったか」を見る。用途によって、誤って止める損失と、誤って通す損失も違う。
`judge()`の中身を交換できるようにする
依存を小さくするため、自分ならJevをアプリのあちこちから直接呼ばない。
state
↓
judge()
↓
choice / score / probability
↓
実行・停止・人間への確認アプリ側から見える入口をjudge()へ揃える。
その中身はJevでも、別のモデルでも、Random Forestでも、単純なルールでもいい。
返す値には、選択、点数、確率だけでなく、使用した判断器とバージョンも含める。
こうしておけば、結果が変わったときに原因を追える。価格や仕様が変わったときにも、アプリ全体を書き直さずに比較できる。
判断データが貯まったら、単純な仕組みへ移す
みんなの使い方を見ていて特に面白かったのが、「Jevの出力が1万件ほど貯まったらRandom Forestへ移す」というアイデアだった。
Jevを永久に使う必要はない。
最初はAIに判断させる。そのとき、入力した状態、返ってきた判断、確率、実際の結果、人間による修正を保存する。
判断データが貯まったら、その仕事が本当にJevを必要としているのかを見直す。
毎回ほぼ同じ条件で同じ答えになるなら、普通のルールにできるかもしれない。特徴量が決まってきたら、小さな分類器へ移せるかもしれない。
ただし、Jevの出力だけを正解として学習すると、Jevの間違いまで次のモデルが覚える。
必要なのは件数だけではない。
- 人間が採用したか
- 実行後に成功したか
- 後から判断を修正したか
- どのモデルとバージョンを使ったか
- そのときの確率はいくつだったか
ここまで残して、初めて移行に使える記録になる。
Jevを使い続けることをゴールにしない
本番で試す最小構成は、次の形がよさそうだ。
- 影響の小さい判断を一つ選ぶ
judge()の共通境界を作る- 低確率時の停止条件を決める
- 判断、確率、結果、人間の修正を記録する
- 一定期間後にルールや小さなモデルと比較する
Jevを導入することが目的ではない。
曖昧だった判断を観察できる形にし、より小さく、速く、扱いやすい仕組みへ変えていく。
その途中でJevが一番合うなら使い続ければいい。単純なコードで足りると分かったら、コードへ戻せばいい。
いつでも交換できる状態で使う。そのほうが、新しいAIを怖がらずに試せる。
第1回：「曖昧な世界を扱えるif文」なのかもしれない
第2回：JevはゲームとAgentの「反射神経」になれるか
