この2日間、テクノロジーサークルや開発者コミュニティを頻繁にブラシをかけると、大きな可能性があります。 ジェブ 名前はスクリーンに刻まれた。
奇妙なことに、私たちがよく知っている“ビッグモデル”とは全く違います。
あなたとチャットしたり、記事を書いたり、ライブでコードを書かせるのには適していません。ChatGPTやClaudeのような製品として理解するのは難しいでしょう。
しかし、このような“何も書かない”モデルは、最近開発者コミュニティの注目を集めています。
理由は簡単です：
Jevは答えを書くのではなく、プログラムの判断をするのです。
従来のビッグモデルが“生成”に優れているとすれば、Jevが解決しようとしているのはソフトウェアシステムにおける膨大で見落とされがちな問題です。
次のステップは何ですか？
これは小さな変化のように見えるかもしれませんが、実際にはAIエージェントアーキテクチャの非常に重要な方向性に対応しています。
Jevとは何ですか？
最初に最も混乱しやすいいくつかの質問をしてください。
サンフランシスコのAIスタートアップ出身のJev TypeSafeこれはクローズドソースモデルです。
ChatGPTやClaudeの製品ポジショニングとは異なり、従来のチャットモデルをAPIラッパーに置き換えるだけではありません。
Jevは当初から非常に狭いタスク領域に焦点を当てていました。
モデルをすばやく分類、選択、判断、スコア化します。
したがって、通常のLLMを使用するようにしません：
“AIについての記事を書くのを手伝って”
本当に良いのは：
“このユーザーメッセージは払い戻し、物流、または他の問題ですか？”
または：
“このページのどのボタンが現在のタスクに最適ですか？”
または、
“この輸出は監査を受けるべきか？”
言い換えれば、
従来のビッグモデルは話す専門家のようなものですが、Jevは高速な意思決定モジュールのようなものです。
Jevは主にAPI経由でサービスを提供しており、モデル重みは公開されていない。したがって、GitHubで見られる関連プロジェクトのほとんどは、Jevモデル自体のオープンソースウェイトではなく、Jev APIを中心に構築された開発者のアプリケーションやツールです。
最も重要な違いは、“書く”ことではありません。
Jevを理解する最も簡単な方法は、従来のLLMとJevを比較することです。
プログラムがカスタマーサービスメッセージを受け取ったとします。
“いつ払い戻しをしてくれるの？1週間待ちました!>>
ChatGPTまたはClaudeを使用する場合、通常はモデルに指示します。
- ユーザーの意図の分析
- 感情の判断
- 出力分類の分類
- 指定したJSON形式で返す
最後に、プログラムはモデルによって生成されたテキストから結果を抽出する。
問題は：
プログラムが本当に知りたいことは1つだけです
refund
または：
true
さらに：
0.93
これまでの長い分析は、プログラムの追加コストです。
ジェフの考えは正反対です。
プログラムは最終的に1つの判断しか必要としないので、モデルに余分なテキストを生成させないでください。
これはまた、Jevの最大の懸念事項です。
主に3つの問題を解決する
JevをチャットボットではなくAPIと考えると、その機能は3つのタイプの質問に簡単に理解できます。
1.質問：イエスかノーか
1つ目はブール判断です。
例えば：
“このコメントにはカスタマーサービスへの攻撃が含まれていますか？”
モデルは理由を説明したり、分析を書く必要はありません。
これは、例えば、確率を直接与えます。
true: 0.94
false: 0.06
結果が出たら、自分で決めることができます。
confidence > 0.8
その後、対応するフローをトリガーする。
これは、コンテンツ監査、スパムフィルタリング、自動転送などのタスクに特に便利です。
2.選択：固定オプションから選択します。
2番目のカテゴリーは、従来の分類タスクに近い。
例えば、事前に設定されたカスタマーサービスシステム：
0 = 账单问题
1 = 物流问题
2 = 退款问题
3 = 其他
モデルの仕事は、自分でカテゴリを作成することではなく、
これらのオプションの中から選択してください。
これはエンジニアリングシステムにとって重要です。
従来のLLMはしばしばプロンプト要件を満たす必要があります。
“JSON形式で出力してください。
しかし、モデルはテキストを生成するので、理論的にはまだ可能です。
- もう一つの説明。
- JSON形式エラー
- 存在しないカテゴリーを作成する。
- スペルの異なるラベルを出力する
固定オプションモデルは、出力空間を開発者が指定した候補セットに直接制限することができます。
プログラムでは、これは大きな違いを意味します。
AIはもはや“結果を書く”のではなく、“結果を選ぶ”のです。
3.評価：オブジェクトの評価を評価する
3番目はスコアです。
例えば、顧客メッセージの感情的な強さを測定したいとします。
1 = 非常平静
2 = 有些不满
3 = 明显不满
4 = 愤怒
5 = 极度愤怒
モデルはセンチメント分析の一部ではなく、スコア分布全体を返します。
プログラムは独自の戦略を設定できます：
- 1~2：自動処理
- 3：普通の人が引き継ぐ
- 4 - 5：マネージャーの昇進
AIが判断する。
ビジネスルールは手続き上のままです。
これは非常に重要なエンジニアリングアイデアです。
4、本当に興味深いのは、一度に多くの質問に答えることができることです。
Jevのもう一つの特徴は、同じ入力を中心に複数の意思決定を同時に行うことです。
例えば、顧客リストでは、次のことを同時に気にするかもしれません。
- どのビジネスクラスに属しますか？
- 緊急性は？
- 顧客の気分は？
- 手動レビューは必要ですか？
従来のシナリオでは、モデルを複数回呼び出す必要があります。
この特定の意思決定指向モデルは、これらの問題を組み合わせることができます。
入力はもはやありません：
もう一度読む→答えを生成する→もう一度読む→答えを生成する
もっと似ています
一度読んで複数の判断を同時に完了する。
多くのイベントを処理するシステムにとって、この設計は単にモデルが“より良く書かれるかどうか”を追求するよりも重要かもしれません。
5なぜそんなに速いのか？
ここでは、Jevと従来の大規模な生成モデルの推論方法の根本的な違いがある。
GPTやClaudeなどのおなじみのモデルは、本質的に自己回帰生成に大きく依存しています。
簡単に理解する：
モデルは最初のトークンを生成し、前のものに基づいて次のトークンを生成し、生成を続けます。
文を書くように言われると、トークンごとにトークンをデコードする必要があります。
しかし、多くの手続き上の決定では、数十、数百、数千のトークンを生成する必要はありません。
仮定問題は以下の通り
“このページには30個のボタンがありますが、どれをクリックすればいいですか？”
プログラムが本当に望む結果は以下の通りです。
button_17
ではなぜモデルに考え言語を整理し説明を出力させるのでしょう？
そこでジェフが入ろうとしている。
AIの出力空間を限られた意思決定空間に制限します。
エンジニアリングの観点からは、これは以下のようになります。
“応答を生成する”
になる：
“有限の候補の中から確率を計算し、選択する”。
タスクは単純で、出力は短く、推論リンクは自然に大幅に圧縮されます。
したがって、Jevが公式に強調したコア指標は、“どれくらい書けるか”ではなく、
1回の意思決定に必要な遅延、計算量、お金。
本当のキラーは“速さ”ではなく“確率”かもしれない。
Jevに特徴が1つしかない場合：
“分類モデルは速い。
それほど驚くべきことではなかった。
本当に興味深いのは、別の長年の問題を解決しようとしていることです。
モデルの信頼性は低いのか？
伝統的な分類モデルにはしばしば問題がある。
モデルは正しいと確信しています
しかし実際には間違っているかもしれません
例えば：
预测：退款问题
置信度：99%
手動検査の結果：
ユーザーは物流を求めています
このモデルを自動化システムに組み込むと、問題は厄介です。
エンジニアはこう書くかもしれない。
confidence > 95%
→ 自动执行
信頼度が較正されていない場合、このしきい値はあまり意味をなさない。
Jevが強調していることの一つは、確率的較正。
理想的な状態では
モデルが80%確信していると言うなら、長期的には80%の精度があるはずです。
このようにして、モデル出力の確率は真に工学的価値があります。
AIはプログラムに指示するだけではありません
“答えはAだと思います。
また、手続きについても述べた。
“どれだけAを確信しているか”。
両者の間には大きな違いがあります
これがAIエージェントと何の関係があるのでしょうか？
これが、最近Jevが開発者から注目されている本当の理由かもしれません。
AIエージェントについて話すとき、私たちはしばしば“脳”に焦点を当てました。
- 推論力が高い。
- より大きな文脈で
- より長い思考プロセス。
- より複雑なツールの使用
しかし、実際に機能するエージェントは、非常に些細な決定をたくさんする必要があります。
例えば：
検索したいですか？
どの楽器を動かす？
現在のタスクは完了しましたか？
この結果は信頼できるか？
サイクルを続けますか？
このユーザリクエストはどのワークフローに属しますか？
これらの問題は複雑ではない。
しかし、エージェントは1分間に数十回、数百回行うことができます。
重いLLMが毎回呼び出されると、遅延とコストはすぐに蓄積されます。
この時点で、Jevのようなモデルには独自の場所があります。
大きなモデルは複雑な推論を担当し、小さなモデルは高頻度の意思決定を担当する。
これは、“1つのモデルですべてを解決する”という考え方よりも、実際のソフトウェアアーキテクチャに近いかもしれません。
開発者はどのように使い始めたのか？
現在、コミュニティではいくつかの代表的な試みが行われている。
1.ブラウザエージェント：AIに“ポイント”を任せる
ブラウザの自動化は典型的なシナリオです。
エージェントがウェブページを開くと、しばしば数十から数百のDOM要素に直面します。
本当の問題は、実は：
“現在のタスクでどの要素を選択すればよいですか？”
それは自然な選択です。
ブラウザ使用コミュニティはすでに存在します。 ジェブ·ウルトラファスト の項目は，Jevをブラウザエージェントの意思決定セッションに使用する.
browser-use/jev-ultrafast GitHubプロジェクト
Jevにブラウザエージェント全体をホストさせるのではなく、非常に特定のレイヤーをホストさせるという考え方です。
次のアクションを素早く選択します。
複雑なテキスト生成は従来のモデルに任せることができる。
この構造は非常に代表的です：
エージェントは必ずしも最初からモデルを必要としません。
2.ゲームエージェント：高い頻度で意思決定
ゲームは、このモデルに非常に適した別のシーンです。
AIがDoomをプレイすると、あらゆる瞬間に判断する必要があります。
- 左か右か。
- 発砲した？
- 武器を変えるべきか？
- 隠れている？
- 前進しますか？
これらの行動は必ずしも長い推論を必要としない。
より似ている：
現在のステータスを入力→次のアクションを選択します。
モデルがこのような決定を非常に低遅延で繰り返すことができれば、従来のLLMではカバーすることが困難だったリアルタイムのシナリオに新たな可能性が生まれます。
3.エージェントルーティング：次に誰を呼ぶかを決定する
マルチエージェントシステムでは、この機能は特に簡単です。
システムには以下がある。
搜索 Agent
代码 Agent
数据库 Agent
客服 Agent
人工审核
ユーザーが到着すると、システムは以下を判断します。
このリクエストは誰に渡すべきか？
これは分類問題です。
さらに、もう少し：
現在のエージェントは検索ツールを呼び出すべきですか？それともデータベースツールを呼び出すべきですか？
もう一つの選択肢です
すべてのルーティングが大規模な言語モデルで行われると、エージェントは“次に何をすべきかを決定する”ことに多くの時間を費やすことになります。
ルーティングに特化した高速モデルは、この層を分離することができます。
これは、将来のAIシステムがますます“階層化”することを意味します。
議論が好きな人：
“どのモデルが最強ですか？”
しかし、実際の生産システムでは、問題は徐々に次のようになります。
“どのモデルがどの仕事を担当するのか？”
より典型的なAIシステムは次のようになります
用户请求
↓
高速决策模型
↓
┌────────┬────────┬────────┐
↓ ↓ ↓ ↓
搜索工具 数据库 Agent 人工审核
↓
复杂任务
↓
大型推理模型
↓
最终结果
この枠組みの中で
ビッグモデルはもはやすべてを引き受けません。
それは本当に推論、創造、生成を必要とする部分を担当します。
高速モデルは、多数の断片化された制御フローを担当します。
ソフトウェア工学の観点からは、これは非常に自然です。
コンピュータプログラムは自然言語で駆動されません。
多くのビジネスロジックは最終的に要約できます：
if
else
switch
route
score
filter
Jevがやっていることは本質的にその一部を作ろうとしています if / switch より“賢く”なる。
10.しかし、それは絶対に万能ではない。
ここでは特に注意が必要です。
Jevの価値は、その特異性に由来し、特異性は限界を意味します。
ChatGPTやClaudeの代替品ではありません。
タスクが必要な場合：
- 長い執筆。
- 複雑なコード生成
- 複数の対話ラウンド
- オープンエンドの知識質問
- 長い連鎖推論。
- 正確な数学計算
このような意思決定指向モデルは、すべての作業を直接行うのに適していません。
さらに、言語カバレッジ、複雑な推論、数学と算術、日付関係などのタスクは、モデル資料だけではなく、独自のテストセットで検証する必要があります。
見落とされがちな問題もあります。
モデルは間違う。
モデルが高い信頼度を与えても、次のことを意味しません。
“手続きは無条件に実行できる”。
特に関連する：
- 払い戻しは
- 支払いは
- データの削除
- アクセス権の変更
- データベース操作
これらのリスクの高いアクションは、従来のソフトウェア権限制御、ルールチェック、手動バックストップを維持する必要があります。
AIが判断できます。
しかし、最終的な安全保障境界は手続きの手に委ねられるべきです。
Jevの本当に面白いところは何ですか？
Jevのみを理解する場合：
“より速い分類モデル”。
過小評価するのは簡単です。
これが本当に興味深いのは非常に単純な質問をしていることです
すべての手続き判断に参加する長い文章を書くモデルが本当に必要なのでしょうか？
多くの場合、答えはノーです。
成熟したAIエージェントシステムでは、実際にコストがかかるのは、必ずしも最も複雑な推論タスクではありません。
多くの小さな決断が必要です。
要不要搜索？
选哪个工具？
是不是垃圾信息？
属于哪个类别？
要不要继续？
需要不需要人工？
個々に見ると、それぞれのトピックは非常に簡単です。
しかし、それらを何百万もの呼び出しで掛け合わせると、コストとレイテンシは本当のエンジニアリング問題になります。
これはJevのようなモデルの最も興味深い点でもあります：
より大きな“脳”になろうとするのではなく、AIシステムの神経末端になろうとしています。
最後に書く。
過去2年間、AI業界はますます大きなモデルを追求してきました。
より多くのパラメータ、より長いコンテキスト、より複雑な推論、より強力なコード能力。
しかし、AIが実際にソフトウェアシステムに組み込まれると、次のようなことがわかります。
コンピュータ間の相互作用の多くは自然言語を必要としません
プログラムには論文を書くモデルは必要ありません
必要なものは：
true
または：
refund
または：
tool_7
または、
confidence = 0.91
これは、Jevが表す方向性の最も興味深い部分です。
ChatGPTを置き換えるものではなく、誰よりもClaudeと書くものでもありません。
彼がやろうとしていることは別のことです
AIを“話す人”から“意思決定を行うプログラムコンポーネント”に変えましょう。
この考え方が続けば、将来のAIアプリケーションは“スーパーモデル”ではなくなるかもしれません。
そしておそらく、より：
一人は思考、一人は生成、一人は判断、一人はルーティング、一人は監査を担当します。
大きなモデルは複雑な問題を扱う。
小型モデルは高頻度の意思決定を担当する。
伝統的なコードは最終制約を担当する。
これら3つを組み合わせることで、真に長期的に実行できるAIソフトウェアシステムが生まれます。
だから、Jevを一言で覚える必要がある場合：
ChatGPTは人に答えを与え、Jevはプログラムに選択を与えます。
それが最近開発者の注目を集めた本当の理由かもしれません。