OpenAIはJevの牙城を崩すかもしれない

OpenAIはJevの牙城を崩すかもしれない？ TypeSafeのJevは、AIの世界に旋風を巻き起こした大規模言語モデルの新しいアプローチを導入しました。Vercelによると、「JevはAI Gatewayの歴史の中で最も速く採用されたモデル」とのことです。 しかし、地平線には暗雲が立ち込めています。OpenAIは間違いなく注目しており、次に何をすべきかを決定しています。TypeSafeの成功を祈っていますが、もし彼らが約束を真に果たすのであれば、OpenAIはJevの主力製品を模倣するだけでなく、その機能を今後のモデルやエージェントに組み込み、Jevが再現できない本当に有用な新しい動作を提供するのに有利な立場にあると懸念しています。 私の論文の要点は以下の通りです。OpenAIは何年もの間、LLMを暗黙的な分類器として使用してきました。ただ、汎用的な分類タスクのために訓練しておらず、汎用分類をスタンドアロン製品としてパッケージ化していなかっただけです。OpenAIがその訓練を再現できれば、短期間でJevを再現できるようになるでしょう。さらに、OpenAIは既存のモデルやエージェント内でこの新しい分類器を使用する準備ができており、これは迅速なモデル選択、より効率的な思考、より優れたセキュリティガードレール、そして一般的にスマートで、より速く、より安価なモデルに役立つ可能性があります。これらすべてを決定する鍵は、TypeSafeが自身を守るための堀を持っているかどうかです。私が考える最大の堀は、TypeSafeの訓練データと訓練プロセスにあります。 古いものが新しくなる 私の主張をする前に、私の仮定を述べ、OpenAIからの関連する歴史と例でそれを裏付けます。私の主な仮定は、Jevが従来の巨大言語モデルに非常に近いものを使用しているということです。その証拠として、Latent Spaceは、初期のクローンの多くが実際にLLMベースであると報告しています。 アイデアはこうです。状態と一連の質問が与えられると、JevのLLMは単一のトークンを生成するか、より正確には、すべての可能な次のトークンに対する確率分布を生成します。その1ステップにおけるすべての可能なトークンのログ確率（logprobs）は、Jevが必要とする形式にマッサージされて返されます。（ここからは、私たちの目的のためには同じものなので、「ログ確率」ではなく単に「確率」と言います。） 二項選択の質問の場合、Jevは真と偽の2つのトークンだけを見て、他はすべて無視し、それらの確率を正規化して、答えが真である単一の確率を生成します。多肢選択の質問の場合、Jevは可能性のあるリスト（例えば、A=嬉しい、B=悲しい、C=怒っている、D=怖い）でプロンプトされ、それらの4つのトークンの相対確率を見て、完全な分布を構築し、最も高いものを勝者として選択します。 この選択パターンは、私が2025年に「Supercharging LLM Classifications with Logprobs」でブログに書いたものとほぼ同じであり、ファインチューニングなしでもすでに有望な兆候を示していました。（ため息…アイデアと実行の重要性について彼らは何を言っているのでしょう？） スコアプリミティブについてはあまり考えていませんが、同じパターンのバリアントだと推測しています。この投稿の前提の一部は、OpenAIがこのアイデアを迅速に活用する準備ができているかもしれないということであり、それがどのように行われるかを理解すると、これがより明確になります。 OpenAIは、少なくともツール呼び出しの導入以来、大規模言語モデルを特殊な分類器として暗黙的に使用してきました。2024年初頭、私は「Tool Invocation – Demonstrating the Marvel of GPT's Flexibility」という記事を書き、GPTモデルにツールを呼び出す方法を正確に明らかにさせました。 以下は、内部でチャットセッションがどのように見えるかです。ここでは、ユーザーメッセージ、ツール呼び出しなしのアシスタント応答、そしてツール呼び出しありのユーザーメッセージがあります。 テキストを色分けしてトークン境界を示しました。ChatMLを見たことがない場合、これはOpenAIがユーザーとエージェントの会話プロンプトを整理するために導入した内部マークアップ言語です。<|im_start|>と<|im_end|>はメッセージを区切る予約済みトークンであり、<|im_start|>の直後の最初のトークンは、話者をユーザーまたはアシスタントとして識別します。 <|im_start|>assistantの直後、モデルが予測する最初のトークンは またはto=function.のいずれかです。もし を予測した場合、通常の自然言語応答を続けます。もしto=function.を予測した場合、そのトークンシーケンスは、ツールを呼び出すべきかどうかを決定する分類器として機能します。次のいくつかのトークンは、どのツールを呼び出すかを識別します – get_temperature – これは別の分類器で、利用可能なツールのリストから選択します。その後、モデルは引数名を生成し、次に引数値が生成されますが、これらも分類器または推定器と見なすことができます。最後に、モデルが<|im_end|>トークンを生成すると、それはメッセージが完了したとモデルが信じる場合に「真」と読み取る分類器でもあります。 一部のLLMは、いつ黙るべきかを知りません – ユーモラスな余談です。 私がGitHubでCopilotに取り組んでいた頃、GPT-4用の非常に新しく、非常に生の内部APIを扱う機会がありました。最初から、何かひどく間違っていることに気づいていました。なぜなら、最初は非常に首尾一貫した応答の後、モデルは終了に苦労していたからです。それは、応答の最後に「他に質問があればお知らせください。良い一日を。良い一週間を。楽しんでください。素晴らしい人生を。特別な一日を…」のようなものを付け加え、応答トークン制限に達するまで続けました。 結局、APIは、モデルがこれらの特別なメッセージ区切り文字<|im_start|>と<|im_end|>を使用できるようにするいくつかのヘッダー値を設定する必要がありました。実質的に、モデルに応答の終了を予測することを許可していなかったのです – 文字通り、内部的に自分自身をシャットアップする能力がありませんでした！ その古い投稿で私が言いたかったのは、OpenAIは何年も前から単一のトークンを小さなマイクロ分類器として使用してきたということです。各トークンには確率がありました。ツールを使用すべきか否か、どのツールを使用すべきか、アシスタントは終了したか、などです。それがJevのトリック全体ですが、重要な点が1つあります。これらのマイクロ分類器はスペシャリストであり、これらの小さなタスクにのみ適していますが、Jevの分類器は汎用的です。しかし、一歩か二歩戻ると、これが実際には小さなことかもしれないことがわかります。なぜなら、LLMは本質的に、すべての後続トークンに対して常に確率分布を割り当てている、驚くほど汎用的な分類器だからです。 TypeSafeには堀があるか？ 私はJevを応援しています。彼らは私たちのすぐそばに隠れていた非常に興味深いものを見つけたと思います。アーキテクチャ的には、上記の理由から、それほど大きな堀はないと思います。TypeSafeはJevのために従来の巨大言語モデル、またはそれに近いものを使用していると思います。たとえそうでなくても、従来のLLMは汎用的な分類作業に適しているようです。 おそらく本当の堀は、訓練データそのものにあります。生のデータではなく、それをJevを「キャリブレーション」するために訓練する何かに変える技術です。 TypeSafeの共同創設者であるDiogo Almeidaは、データがアーキテクチャよりも重要だと示唆したときに、次のように述べています。 > データがアーキテクチャよりも重要だと言う人はあなたが初めてかもしれません！🥲 私たちは自分たちをデータリサーチラボと考えています！研究の大部分は、真に汎用的なデータ（認知コアのようなもの）を作成することにあり、私たちのデータは100％合成です（ただし、LLMから吐き出されるようなくだらないものではありません）。— Diogo Almeida（@CompleteSkeptic）2026年9月17日 もし私がそのデータセットを構築するとしたら、結果がすでにわかっている例（サポートチケットとその実際のルーティング方法、履歴書とその候補者が実際に採用されたかどうか、製品レビューとその実際の星評価、モデレーションキューとその実際の判決、予測市場とその実際の解決方法など）を大量に集め、それぞれに私がすでに知っている真実の答えを持つ質問をペアにしたいでしょう。ポイントは、Jevにサポートチケットや履歴書について具体的に教えることではありません。それは、さまざまなドメインにわたる何千もの状況を示し、分類を一般化する筋肉を構築することです。