Jev vs エージェント: ソフトウェアにおける意思決定プリミティブの統合

ここ数週間、洞窟の中で暮らしていたのでなければ、@typesafeai の Jev について目にしたことがあるはずだ。

https://x.com/CompleteSkeptic/status/2099925682726002904

彼らは自社のモデルを次のように説明している：

ソフトウェアが直接使用できる高速かつ構造化された意思決定を行うために構築された AI モデルのクラス。System One モデルは
state を評価し、型付きの回答と確率を返す。

TypeSafe のベンチマークによると、Jev は LLM よりも 20〜200 倍速く、40〜400 倍安価である。

しかし、なぜこれが重要なのか？これまでにも分類器（スマホの自動補正、Gmail のフィルタリングなど）は存在したが、Twitter の情報によれば、Jev は何か特別なものらしい。

この記事では、Jev とは何か、なぜ存在するのか、そしてそれを本番システムにどのように導入できるかを解説する。

Jev とは具体的に何なのか？

「Jev をフロンティア知能関数呼び出しだと考えてほしい。非構造化状態を入力し、型付き確率的意思決定を出力する。」 - TypeSafe

Jev は 3 つの基本要素（プリミティブ）を公開している： Choice、 Score、そして Noul。

Choice は、定義されたセット（最大 255 個）から 1 つのオプションを選択する質問タイプであり、回答には選択されたオプション、各オプションの確率、および信頼度が含まれる。
Score は、順序付けられた記述的なレベルに対してコンテンツを評価するものであり、回答にはスコア、各レベルの確率、および信頼度が含まれる。
Noul は、モデルにはい/いいえの質問を評価させ、答えが「はい」である確率を返させる。

カスタマーサポート用例での入力と出力のサンプルは以下の通りだ：

json

1// Input
2{
3  "model": "jev-latest",
4  "state": "Hi, I was charged twice for my monthly subscription. Could you refund the extra charge? My account is working fine.",
5  "questions": {
6    "department": {
7      "type": "choice",
8      "instructions": "Which team should handle this message?",
9      "criteria": {
10        "billing": "Charges, payments, subscriptions, and refunds",
11        "technical": "Bugs, errors, and broken features",
12        "account": "Login, passwords, and account access"
13      }
14    },
15    "requests_refund": {
16      "type": "noul",
17      "instructions": "Is the customer explicitly requesting a refund?"
18    },
19    "frustration": {
20      "type": "score",
21      "instructions": "How frustrated does the customer sound?",
22      "criteria": [
23        "Calm: politely describes the issue without expressing frustration",
24        "Frustrated: expresses annoyance or dissatisfaction",
25        "Very frustrated: expresses strong anger or threatens to leave"
26      ]
27    }
28  }
29}
30// Output
31{
32  "model": "jev-1.13.0",
33  "answers": {
34    "department": {
35      "type": "choice",
36      "choice": "billing",
37      "confidence": 1,
38      "probabilities": {
39        "technical": 0,
40        "account": 0,
41        "billing": 1
42      }
43    },
44    "requests_refund": {
45      "type": "noul",
46      "noul": 0.99
47    },
48    "frustration": {
49      "type": "score",
50      "score": 0,
51      "legend": {
52        "0": "Calm: politely describes the issue without expressing frustration",
53        "1": "Frustrated: expresses annoyance or dissatisfaction",
54        "2": "Very frustrated: expresses strong anger or threatens to leave"
55      },
56      "confidence": 1,
57      "probabilities": {
58        "0": 1,
59        "1": 0,
60        "2": 0
61      }
62    }
63  },
64  "usage": {
65    "input_tokens": 442,
66    "output_tokens": 72
67  },
68  "request_id": "playground_12bbfa4198be5ca4de9818a45c0906a2055",
69  "evaluation_time_ms": 163.01120699790772
70}

state と questions がどのように連携して出力を生み出すかをより深く理解するために、彼らのダッシュボードオンボーディングを試してみることをおすすめする。

これは単なる分類器ではないのか？

イエスでもありノーでもある。LLM と分類器の間に生まれた子のようなものだと言えるだろう。

従来の分類器は、大量データ処理や固定された分類体系を持つタスクに適している。例えば LeNet-5 が画像内の数字を識別するようなものだ。しかし、分類器は通常、極めて専門的でドメイン特化型である。一方、LLM はシーケンス生成に優れている。柔軟で、実行時に定義されるオープンエンドなタスクに向いているが、分類器と比較すると遅く、コストが高く、予測可能性も低い。

Jev は「分類のための基盤モデル（foundation model）」であり、LLM の自然言語の柔軟性と、分類器の制約付き確率的出力を組み合わせている。新しいモデルを訓練することなく幅広いタスクをこなせ、かつ多様なドメイン（コード、テキスト、ログ、UI 状態、イベントなど）における専門性を維持できる。さらに Jev は並列出力を生成できるため、逐次生成に限られる LLM よりも大幅に高速だ。

要するに、非常に賢い汎用性のある分類器なのである。

なぜ Jev は存在するのか？

TypeSafe の CEO 兼共同創業者である Diogo Almeida は、OpenAI で RLHF（人間のフィードバックによる強化学習）や ChatGPT プロダクトの開発に関わった経験を持つ。RLHF により、LLM は指示やプロンプトに従う能力を飛躍的に向上させたが、これはその自己回帰的な性質と一致していた。

その後、彼は OpenAI を離れ、エージェントではなく AI 駆動型ソフトウェアを実現するために異なるクラスのモデルを訓練するため TypeSafe を設立した。Jev は RLCD（較正された意思決定からの強化学習）で訓練されている。これは、回答そのものよりも、信頼度と確率を出力することに特化したモデルを訓練することを意味する研究用語だ。

TypeSafe はソフトウェアは知的であるべきと信じている。エージェントは歴史的なソフトウェアの仕組みに自然に浸透することはなく、人間が介在する（human-in-the-loop）アプローチでは、知能的かつ自律的なソフトウェアの実現は難しい。Jev は、ソフトウェアシステム内で合成可能で信頼できる基本要素としての知能への一歩なのだ。

これは完全に新しいアイデアではない。2017 年の研究者たちは、高い予測精度が信頼できる確率推定を意味しないことを発見しており（つまり、LLM はこの点において完璧な解決策ではない）。

なぜ RLHF ではなく RLCD なのか？

RLHF の問題点は、人間が望むものが必ずしも客観的に正しいとは限らないことにある。特定の形式の回答を人間が好むからといって、モデルがより知的になるわけではなく、単に扱いやすくなるだけだ。

また、モード崩壊（mode collapse）を引き起こす可能性もある。RLHF は LLM を単一の回答に収束させがちだが、実際には複数の軌道が「正解」になり得る場合がある。

「出力が人間にとって魅力的であっても、無人自動化に十分な信頼性があるとは限らない。人間の好みと機械の信頼性は、異なる最適化目標である。」

Jev のドキュメントによるモード崩壊の説明

Jev はエージェント構築のために作られたのではない

タイムラインで見かける内容とは裏腹に、Jev はスタンドアロンのエージェントとしてはあまり適していない。私たちは Jev のみのバージョンや、LLM + Jev の組み合わせなど、いくつかのバリエーションを試みた。

https://x.com/kylejeong/status/2100622054945095934

正直なところ、Jev エージェントはデモとしてはクールだ。Jev を使って超高速でエージェントタスクを実行するデモが大量に出回っている。しかし、最高のデモであっても、本番環境に展開できる段階にはない。

Jev のようなモデルは AI 駆動型ソフトウェア向けのものであり、決定論的なコードで構成された意思決定を支援するためにある。推論機能や生成機能がない状態で、これをスタンドアロンのエージェントとして使用するのは無知の極みだ。

AI 駆動型ソフトウェア

Jev をスタンドアロンのコンピュータ利用エージェントにするのではなく、カスタマーサポートのルーティング、請求書処理、セキュリティアラートのトリアージ、またはエージェントモニタとして活用すべきだ。

数字の話

最初のモデルである Jev 1.13.0 の価格は、入力トークンあたり $42/btok（$0.042/mtok）、出力トークンは無料だ。参考までに、Fable 5.1 は入力が $10/mtok（$10,000 / Btok）かかる。一般的なエンタープライズワークロードでは、入力・出力トークンの比率が 3:1 または 4:1 となるため、Fable の実効コストは約 $20,000/Btok（出力 $50/mtok 含む）となる。

コンテキストウィンドウはリクエストあたり 64k トークンで、state と最も長い question を合わせて 32k トークン以内に収める必要がある。

ただし、社内ベンチマークでは、OpenAI、Anthropic、Deepseek（Fireworks 経由での推論）の全モデルに対し、精度/コスト比および精度/速度比で上回っている。

精度/コスト

話はこれくらいにして、どうやって使うのか？

ここまで読めば、Jev についての理解は深まり、現在取り組んでいるプロジェクトに対するいくつかのユースケースが思い浮かんだはずだ。（もし思いつかなければ、TypeSafe が推奨するユースケースリストを見てほしい。）

使い方の創造性を制限するのではなく、私たちのフレームワーク Stagehand に Jev をどのように組み込んだかを紹介しよう。

過去 2 年間、Stagehand は AI とエージェントがリモートブラウザを制御するためのフレームワークとして進化してきた。エージェントが十分に高性能になる以前から、開発者がウェブを自動化するための自己修復型スクリプトを書けるよう、Act（アクション完了）、Extract（構造化データの抽出）、Observe（ページ上の潜在アクション発見）という AI プリミティブを作成してきた。

Playwright（或其他レガシーフレームワーク）を使って手動で DOM を解析し、アクション用のセレクタを提供する代わりに、Stagehand の A/E/O では自然言語を用いて自動化を構築できる。

typescript

1// Playwright
2await page.click('button[type="submit"]');
3
4// Stagehand
5stagehand.act("click the submit button")

これはスクリプトを初めて書く際に有用だ（開発スピードが大幅に向上する）。特にスクリプトのメンテナンスにおいて強力だ。ウェブサイトが変更され DOM セレクタが更新されると、Playwright スクリプトは新しいページに合わせて書き直す必要がある。一方、Stagehand は実行時にセレクタとアクションを選択するため、「自己修復的」である。

ここでどこへ向かおうとしているか、お分かりいただけるだろう。Jev はこれらのプリミティブに極めてよく適合する。当初は、ページの見た目とゴールに関するコンテキストを与えた LLM を使って何をすべきかを決定していた。Jev を使えば、Choice を用いてどのセレクタと相互作用するかを決定できる。

具体的なフローを理解するために Act を例にとろう。通常、LLM にはハイブリッドなアクセシビリティツリーを用いたページの簡潔な表現を与える。Jev を使う場合はまず、アクセシビリティツリーのノードをインタラクティブ可能（リッチテキストエディタを含む）かどうかでマークする。

stagehand.act が呼び出された際：

Jev は指示をアクション（クリック、入力、スクロールなど）に分類する
Stagehand は引数を解析し、そのアクション用の候補リスト（近くのページコンテキストを含む）を構築する
Jev は「どの候補が最適か」「候補が存在するか」を答え、許容閾値 0.7 で判定する
候補アクションが承認されれば、Stagehand が実行を処理する
承認されなければ、Stagehand は LLM にフォールバックする

Act フロー

初期テストでは、Act の中央値レイテンシが 1.97 秒から 0.46 秒に低下し、約 4.3 倍高速化（時間にして 77% 短縮）された。完全な PR スタックはこちら。

コンピュータ利用において、Jev はパズルの一部であり、スタンドアロンのソリューションではない。私たちは今、エージェントが使用できるより決定論的なソフトウェアツールを構築できるようになった。

Jev を使うタイミング

現実世界への AI の普及

Jev は本番グレードのコンピュータ利用エージェントを構築できるか？いいえ。それはパズルにおいて有用なピースか？私はそうなると思う。

Jev の登場以前には理にかなっていなかったアイデアが溢れている気がする。人々は瞬時の検索、スマートなコピー＆ペースト、その他シンプルだが極めて役立つツールを開発しているのを見かけた。

AI はチャットインターフェースの何らかのバージョン（同期または非同期）に限定されるべきではない。Jev のようなモデルを使えば、チャット入力ボックスなしで予測モデルを組み込んだソフトウェアを構築できる。分類器は長年存在してきたが、これほど有用だと感じたことはかつてないかもしれない。私たちに必要だったのは、ただのインスピレーションだったのかも知れない。

-> Kyle