Jev AIモデルは文章ではなく意思決定のために作られている

JevはTypeSafe AIによって、新しいtransformerベースのモデルだと説明されていますが、大規模言語モデルではありません。テキストtokenを生成する代わりに、開発者が事前に定義した出力に対する確率を返します。TechCrunchによると、TypeSafeはこれらの出力を「キャリブレーション済みの意思決定」と呼んでいます。

この設計には、報道によれば3つの即時的な結果があります。

第一に、このモデルは分類のような作業に汎用LLMを使うよりも安く速いものとして位置づけられています。TechCrunchは、Jevの出力tokenは無料で、入力tokenは100万単位ではなく10億単位で課金されると報じています。

第二に、出力空間が制約されています。開発者が可能な出力を事前に定義しておけば、モデルは流暢だが予期しない段落で応答することができません。TechCrunchによると、TypeSafeはこれをハルシネーションを避ける方法として提示しています。実務的に言えば、より限定的です。Jevが間違うことはあり得ますが、既知の選択肢の範囲内で、確率付きで間違うはずだということです。

第三に、その確率は後付けではなくプロダクトの一部です。EarendilのCTOであるArmin RonacherはTechCrunchに対し、Jevは「ハルシネーションの問題を少しユーザー側に委ねる」と述べました。結果が50%で返ってきたなら、アプリケーションはそれを無視するかもしれません。95%で返ってきたなら、アプリケーションは行動を起こすかもしれません。

この違いは重要です。多くのAI自動化が壊れるのは、モデルがまったく役に立たないからではなく、ソフトウェアがモデルの単なる推測を見分けられないからです。開発者はしばしば、LLMに自己説明させたり、自己投票させたり、構造化されたJSONを出力させたりして、信頼度を取り戻そうとします。Jevは、信頼度スコアそのものが要点であるモデルとして売り込まれています。

TechCrunchによると、開発者の関心は非常に高く、TypeSafe AIは一時的にAPI経由でユーザーにサービス提供できなくなりました。同記事は、Jevの初期の魅力をソフトウェア自動化、つまりチャットインターフェイスではなくコード内で知能を使うことを中心に位置づけています。

報道内の2つの例が、その需要の形を示しています。

VercelのソフトウェアエンジニアであるPranit SharmaはTechCrunchに対し、Vercelではコマンドの安全性をレビューする分類器を動かすためにOpenAIモデルを使っていたと述べました。VercelがOpenAIのLunaをJevに置き換えたところ、Sharmaによれば、結果は5〜18倍速く、精度も高くなりました。

TechCrunchによると、Bryo AIのCTOであるNikhil Mudholkarは、ビジネスメールの分類でJevをGeminiと比較してテストしました。そのテストでは、Geminiの方がわずかに高精度でしたが、コストは10〜20倍高くなりました。MudholkarはJevの信頼度スコアを強調し、「本物の確率を返してくる唯一のもの」だと述べ、ワークフローの自動化に有用だとしました。

これらは広範なベンチマークではありません。特定の設定で、実行した人々が詳細を管理した、報告された開発者テストです。それでも、現実のカテゴリを指し示しています。仕事が「答えを書く」ことではなく、「正しい分岐を選ぶ」ことであるケースです。

例としては次のようなものがあります。

多くのチームは現在、LLM promptと構造化出力を組み合わせてこれらを解決しています。このアプローチは機能します。特にスキーマ、リトライ、検証と組み合わせる場合はそうです。ただし、言語生成を必要としない可能性があるタスクに、LLMの予算を使い続けることにもなります。

TechCrunchが報じた例の外でもJevの初期の主張が成り立つなら、Jevはtool callingと構造化出力と同じ実用的な設計領域に入ります。つまり、モデルの振る舞いを、ソフトウェアが消費できる契約に変える領域です。

TechCrunchの報道で最も興味深い用途のひとつは、LLMを置き換えることではなく、いつLLMを使うかを決めることです。

RonacherはTechCrunchに対し、Jevはモデルルーティングに有用になり得ると述べました。つまり、あるワークロードに特定のモデルが必要かどうかを予測する用途です。その判断にLLMを使うと高くつく場合があります。キャリブレーション済みスコアを返す、より安く速いモデルをモデルスタックの前に置き、各リクエストをどこへ送るべきかを決められるかもしれません。

これは、複数のモデルで構築している人には馴染みのある問題です。最強のモデルが常に必要なわけではありません。最も安いモデルが常に安全なわけでもありません。長いコンテキストでの推論が必要なpromptもあれば、高速な分類器が必要なものもあり、画像、音声、検索ツールが必要なものもあります。ルーターは、予算を使う前に仕事を見積もらなければなりません。

ここでも、Jevの形式が重要です。ルーターには、あるpromptがなぜ難しいのかについてのエッセイは必要ありません。必要なのは、次のような意思決定です。

• 小さなモデルへ送る;
• フロンティアモデルへ送る;
• 先にドキュメントを取得する;
• 人間の承認を求める;
• 安全でないものとして拒否する。

これは会話よりも確率推定に近いものです。中核となるルーティング問題は、修辞的というより実務的です。価値のある部分は、多くの場合、利用可能な最大モデルをただ呼び出すことではなく、適切な価格で適切な能力を選ぶことです。

Jevは、ルーティング自体が、背後に専門モデルを持つAIワークロードになる可能性を示唆しています。

TechCrunchはまた、AlmeidaがJevを、LLMエージェントのトレースを監視し、脱獄を防ぐ用途で使うことを想定していると報じています。コスト面の主張は明快です。すべてのエージェント行動を別の完全なLLMでチェックしなければならないなら、安全レイヤーは高価になり得ます。より小さな意思決定モデルが不審な振る舞いを低コストでフラグできるなら、より多くのアプリケーションが継続的な監視を導入できます。

これは、エージェント安全性の難しい部分を取り除くものではありません。分類器には、明確に定義されたラベルが必要です。例も必要です。しきい値も必要です。信頼度が低い場合に何をするかというポリシーも必要です。そして、行動が十分にセンシティブであるなら、確率スコアが人間の判断に取って代わるべきではありません。

ただし、アーキテクチャは明快です。

1. エージェントがステップを提案または実行する;
2. 意思決定モデルがそのステップをスコアリングする;
3. システムがブロック、許可、ログ記録、またはエスカレーションを行う;
4. 人間は、人間によるレビューが必要なケースだけを確認する。

これは、本番システムがすでにリスクを考える方法に近いものです。決済システム、不正検知システム、スパムシステム、不正利用対策システムは、しきい値とエスカレーション経路を通じて動作することがよくあります。AIエージェントにも同じパターンが必要になり始めています。

自律型ワークフローを構築するチームにとっての教訓は、「安全対策をJevで置き換えよ」ではありません。安全性は生成から分離できる、ということです。あるモデルで行動し、別のモデルまたは分類器で監視し、取り消せない行動には人間の承認レイヤーを置くエージェントを設計できます。同じ原則は、human-in-the-loopの承認や、作業が進む前に1つのコンポーネントが別のコンポーネントをチェックするマルチエージェントシステムにも現れます。

アーキテクチャは部分的に不透明なままです。TechCrunchによると、AlmeidaはJevの内部構造について「口が堅い」一方で、外部の観察者は、JevがオープンウェイトのLLMの上に構築されているのではないかと見ています。TypeSafe AIはJevを「System One model」と呼んでいます。明示的な推論ではなく、高速で直感に近い意思決定に最適化され、タスクに合わせてより狭く設計されたモデルです。

AlmeidaはTechCrunchに対し、Jevは彼が「キャリブレーション済み意思決定からの強化学習」と呼ぶ手法を使い、合成データのみで訓練されていると述べました。また、TypeSafe AIは早い段階で、自社のデータをすべて自前で作ることに賭けたとも述べています。彼は同社の一部を、「統計的によく理解された合成データ」に焦点を当てたラボだと説明しました。

プロダクトの仮説を理解するには十分な情報がありますが、訓練手法を独立して評価するには十分ではありません。TechCrunchの報道からは、キャリブレーションがどのように測定されるのか、分布外でどれほど堅牢なのか、モデルが敵対的入力をどう扱うのか、ドメインをまたいで性能がどう変化するのかは分かりません。

これらの問いが重要なのは、確率はキャリブレーションされている場合にのみ有用だからです。モデルが95%と言い、似た条件下でおおむね95%の確率で正しいなら、開発者はそれを基にポリシーを構築できます。その数値が信頼度らしい形をした出力にすぎないなら、検証すべきものがもう1つ増えるだけです。

妥当な評価では、精度だけでなく、キャリブレーション曲線、棄権の振る舞い、しきい値性能、実トラフィック下でのコストもテストするでしょう。すでにモデル評価を運用しているチームにとって、Jevは、それが置き換えたり監視したりする可能性のあるLLMと同じテストハーネスに入れるべきものです。

Jevは、19世紀の経済学者William Stanley Jevonsにちなんで名付けられています。彼は、資源の利用効率が高まると、総消費量は減るのではなく増えることがあるというジェヴォンズのパラドックスで知られています。AlmeidaはTechCrunchに対し、TypeSafe AIは、より安価な知能が「至るところにあるスマートなソフトウェア」につながると期待していると述べました。それは、「メガアプリ」だけが支配する世界というより、初期のインターネットに近いものです。

それが戦略的な主張です。知能が通常の制御フローの中に置けるほど安くなれば、開発者はAIをチャットボットや大規模なエージェント体験のためだけに取っておくのをやめるかもしれません。代わりに、小さな意思決定があらゆる場所に現れます。キュー、管理画面、カスタマーサポートのワークフロー、デプロイチェック、メッセージングシステム、データパイプラインの中です。

これは意味のある変化になるでしょう。ChatGPT時代のインターフェイスはチャットでした。Jevは埋め込み推論の方向を指しています。つまり、ソフトウェアをリアルタイムに適応させる、見えない、狭い、頻繁な意思決定です。

ビルダーにとって実務的な動きは、現在、汎用LLMに限定的な仕事をさせている場所を棚卸しすることです。分類、ルーティング、抽出、ランキング、モデレーション、エスカレーションが明らかな候補です。LLMがまだ必要なものもあるでしょう。ルールで処理した方がよいものもあるでしょう。経済性が合えば、専門の意思決定モデルを正当化できるものもあるかもしれません。

ワークフローが多数の行、メッセージ、チケット、イベントを処理するものであるなら、問いはより鋭くなります。必要なのは生成されたテキストでしょうか。それとも、大規模に信頼できる意思決定でしょうか。これは、AIバッチ処理や多くの本番自動化システムの背後にある経済的な境界線と同じです。

重要なのは、Jevが「LLMより優れている」ということではありません。TechCrunchの報道はそれを立証していませんし、例もその結論には狭すぎます。重要なのは、人間との会話ではなくソフトウェアの意思決定に合わせて形作られたモデルに、開発者が関心を示していることです。

これは、チームがAIアーキテクチャを捉える方法を変えるはずです。

言語、推論、統合、tool useが重要なところではLLMを使う。契約が必要なときは構造化出力を使う。答えが非公開または変化する知識に依存する場合は検索を使う。行動がセンシティブな場合は人間の承認を使う。そして、文章よりも確率の方が有用な場所に対して、新しく現れている意思決定モデルのクラスを注視する。

Jevは専門プロダクトにとどまるかもしれませんし、競合が同じ大きな方向へ進むかもしれません。RonacherはTechCrunchに対し、他社も追随すると見ていると述べましたが、それは必ずしもJevの直接的なクローンを意味しません。オープンエンドなテキスト生成ではなく、狭く確率ベースの意思決定を中心に構築されたシステムが増える、という形かもしれません。いずれにせよ、これは有用なシグナルです。AIインフラの次の波は、1つのモデルをより上手に話させることよりも、ソフトウェアに、より安く、小さく、測定しやすい知能の部品を与えることに向かうのかもしれません。

実務的な結論は、LLMを置き換えることよりも、各意思決定に適したモデルの形を選ぶことにあります。

• Jevは、文章を生成する代わりに、事前定義された出力に対する確率を返すtransformerベースのモデルとして説明されています。
• このモデルは、分類、ルーティング、モデレーション、エスカレーション、安全性チェックといった境界のあるソフトウェア上の意思決定向けに売り込まれています。
• 報告された開発者テストは、Jevが一部の狭い分類ワークフローで汎用LLMより速い、または安い可能性を示唆していますが、広範なベンチマークではありません。
• キャリブレーション済みの確率は、アプリケーションがいつ行動し、棄権し、エスカレーションし、より強いモデルを呼び出すかを決めるのに役立つ可能性があります。
• ビルダーは、Jevのようなシステムを、精度、キャリブレーション、しきい値での振る舞い、棄権、堅牢性、実トラフィックでのコストで評価すべきです。

これらの質問では、Jev AIモデルの仕組み、汎用LLMとの違い、確率ベースの意思決定がソフトウェアシステムのどこに適合し得るかを取り上げます。また、Jevのようなモデルを本番環境で使う前にチームが評価すべきことも概説します。

JevはTypeSafe AIのモデルで、transformerベースだが大規模言語モデルではないと説明されています。テキストを書く代わりに、開発者が事前に定義した出力に対する確率を返します。

汎用LLMは言語tokenを生成しますが、Jevは事前定義された出力の中から選び、確率を付与するように設計されています。そのため、オープンエンドな会話よりもソフトウェア上の意思決定に適しています。

多くのAIワークロードでは、段落ではなく、信頼できる分岐、ラベル、安全性判断が必要だからです。TechCrunchは、特定の分類ユースケースでJevがより安い、またはより速かった初期テストを報じています。

この記事では、コマンド安全性レビュー、ビジネスメール分類、エージェント監視、モデルルーティング、ワークフローのトリアージ、LLMエージェント向けガードレールなどのユースケースを取り上げています。

チームは精度だけでなく、キャリブレーション、しきい値性能、棄権の振る舞い、訓練ドメイン外での堅牢性、敵対的入力、実トラフィック下でのコストを測定すべきです。