JEV パターン

すべての JEV パターンに共通する骨格

TypeSafe 自身のドキュメントはこの構成を一本の縦線として描いている。構造化されていない状態が型のついた質問に流れ、型のついた質問が Jev に流れ、Jev が分布つきの choice・score・noul を返し、コード内の決定的な組み合わせが結果を二方向に分ける —— 片方は可逆な動作、もう片方は再確認か代替経路。

この図でいちばん効いている語は「可逆」だ。以下のどの Jev パターンも、Jev の答えが引き起こすことは取り消せる・やり直せる・上位に上げられる、という前提に立っている。Jev は速くて安くて較正の取れた推測器で、速くて安い推測器を置くべき場所はどこか —— たまに外しても耐えられる判断の手前であって、耐えられない判断の後ろでは絶対にない。

TypeSafe は境界をはっきり書いている。Jev が答えるべきなのは「このリクエストは既知のどのルートか」「この問題はこの基準で見てどれくらい重いか」「このメッセージは返金を求めているか」「この引用はこの主張を支えているか」といったものだ。「このアカウントを消すか」「この送金を実行するか」のような影響の大きい決定の唯一の決定者に Jev を据えてはいけない。

なぜ JEV パターンが要るのか

質問型が三つしかなく、テキストも出さないモデルなら、ドキュメントなど要らなそうに聞こえる。実際は逆だ。この制約が、設計の仕事をまるごと一か所に押し込むからで、その一か所とは多くの人が普段考え慣れていない場所 —— 質問そのものの形 —— にある。

チャットモデルなら曖昧なまま投げて、モデルに汲み取らせることができる。Jev ではできない。選択肢には一つずつ名前が要るし、段階には説明が要るし、しきい値はプロンプトで匂わせるのではなく自分で決めることになる。これを上手くやるのは技術であり、ここにある Jev パターンは、最初の一週間でみんなが繰り返し間違えた問いに対する、いま時点での答えだ。

もう一つの理由は組み合わせにある。Jev の質問が一つだけで面白くなることはまずない。Jev を入れる価値を生むのは、同じ状態について一回のリクエストで六つ聞き、六つの確率を一つの動作に変換する 20 行のルーティングを書く部分だ。Jev パターンが主に語っているのはその後半 —— つまり Jev が肩代わりしてくれない部分だ。

どの JEV パターンを選ぶか

自分のプログラムがすでに知っていることから出発する。行き先の集合が固定されていて、そこから一つ選ぶ必要があるなら、要るのはルーティング型の Jev パターンで、本当の設計作業は行き先に十分精密で重ならない名前をつけることだけだ。対象が一つあって、それがどれくらい悪いかを知る必要があるなら、説明つきの段階を持つ採点型の Jev パターン。実行したい動作があって、その許可がほしいなら、Noul で組んだガードレール型の Jev パターン。

自分がどれなのか判別できないなら、その判断はまだ Jev に渡せるほど輪郭がはっきりしていない、というのがたいていの答えだ。受け入れられる答えをすべて書き出してみる。その一覧が開いているなら Jev は誤った道具で、テキストモデルが正しい。一覧が閉じているなら、いま Jev の質問をひとつ設計し終えたことになる。

もう一つ役に立つふるいは量だ。ここにある Jev パターンはどれも、その判断が十分な頻度で走るときにだけエンジニアリングの投資に見合う。1 日に 2 回しか起きない判断は、すでに料金を払っているモデルに任せておけばいい。Jev の理屈は 1 回目ではなく 1000 回目の呼び出しの上に立っている。

JEV パターンの質問の作り方

いちばん効く習慣は、選択肢にラベルを貼るのではなく説明を書くことだ。「バグ・請求・その他」という Jev の Choice は、一つずつに一文がついているものに明確に劣る —— 「製品の欠陥、サービス停止、または連携の失敗」「課金、返金、請求書、サブスクリプションに関すること」「上のどれにも明確には当てはまらない」。モデルが読むのはこちらの説明なので、説明が曖昧なら判断も曖昧になる。

二つ目の習慣は、Jev に逃げ道を残すこと。ほぼすべての Choice に「どれでもない」を明示的に入れるべきだ。正解の入っていない一覧から選べと強いれば、自信たっぷりの誤答が返ってくるに決まっている。コード側の確信度の下限と組み合わせれば、曖昧なものは無理に当てずに自分で再確認へ流れていく。

三つ目は、一つの Jev の質問に一つのことだけを聞かせること。書いた選択肢の集合の中で、二つの選択肢が無関係な二つの軸で分かれていることに気づいたら、それは質問が二つある。分ける。Jev は並列に解くので分けてもほぼタダだし、たいてい両方の答えが良くなる。

最後に、状態の中の本当に関係する部分を Jev に指し示すこと。playbook の例はどれもフィールドを明示して参照している —— オブジェクト全体ではなく ticket.messages[0].text を渡す —— 状態が大きいとき、この精密さが答えをはっきり引き締める。

JEV パターンのしきい値をどこに置くか

コードの中。常にコードの中で、しかも見つけられて書き換えられる定数として置く。確信度のしきい値をヘルパー関数の奥に埋めてしまったり、さらに悪いことに Jev への instructions に書き込もうとしたりするのはよくある話だが、どちらも本番では持たない。本当にほしい数字は、事前に推論して出すものではなく、実際のトラフィックを眺めて見つかるものだからだ。

うまくいくのは、小さくて明示的な階段だ。上のしきい値より上なら自動実行。二つのしきい値のあいだなら実行しつつ印をつけて抜き取り検査。下のしきい値より下なら実行しない —— 人に回すか、そもそも避けたかった高いモデルに戻す。

Jev は較正を目標に訓練されているので、これらの数字には意味がある。Jev が 0.9 と言うならおおむね 10 回中 9 回当たっているはずで、残りの 1 割についてコストの見積もりが立てられる。当てずっぽうではなく。この性質こそが本当の製品で、速度や価格より重い。

何度でも言う価値のある注意がある。較正は大量の呼び出しについての統計的な約束であって、個々の 1 回についての保証ではない。Jev が特定のケースで自信満々に外すことは普通にありえるし、説明はしてくれない。抜き取り検査は初日からつないでおく。

最初に手をつける JEV パターン

まず一つだけ実装するなら、ガードレールの Jev パターンを選ぶ。いちばん小さく、Noul 一つで済み、それ自体は何も止めないので、重要なものを Jev に預ける前に、実トラフィックでしきい値を較正できる。

そこからの自然な次の一歩はルーティングだ。金が動くのはそこだからで、高いモデルの手前に Jev の呼び出しを一つ置き、リクエストごとに高いモデルがどれだけ必要かを決める。ここで浮くのは安い業者に乗り換えて得られる 2 割ではなく、その呼び出しを丸ごとやめることで得られる 9 割だ。

このページのどの Jev パターンもコミュニティの playbook からの翻案で、それぞれのページに state・型のついた質問・ルーティング方針が書き出してある。眺めるためではなく、読んで写すために置いてある。