■ 1. LLMの捉え方と「ソフトウェア＋AIモデル部品」という構成
- LLMの本質:
- 言語や意味をソフトウェアから扱うための技術として捉えると分かりやすい
- 分類、意味抽出、曖昧な入力の解釈、構造化データへの変換をコードから呼び出せる点に価値がある
- 言うなれば「記号操作 as Code」
- 現在主流の構成:
- 「AIモデル ＋ ハーネス」という構成が一般的
- 汎用モデルを中心に置き、周囲をプロンプト、ツール、メモリ、ルール等で制御する
- 汎用モデルを毎回動かす無駄:
- ソフトウェアが必要とするのが分類、抽出、評価、分岐などの限定的な処理なら大きな汎用モデルは不要
- 毎回動かすのは計算資源の無駄
- 別の構成案:
- 「ソフトウェア ＋ AIモデル部品」という構成
- 決定論的に処理できる部分はコードで実装する
- 意味解釈や曖昧な判断が必要な部分だけAIモデルを呼び出す
- Jevの位置付け:
- この方向をかなり具体的な形で示すモデル
- TypeSafeの公式記事、開発者Diogo Almeidaの論考とインタビュー、外部メディアの記事をもとに整理する
■ 2. ソフトウェアから直接呼び出す「プリミティブな知能」
- System One Model:
- TypeSafeはJevをこの新カテゴリの最初のモデルとして紹介している
- 特徴を表す言葉は「unstructured state in, typed probabilistic decisions out」
- 非構造化された状態を入力し、型付きの確率的判断を出力するという意味
- LLMとの違い:
- LLMは基本的に文字列を生成する
- JevはChoice、Score、Yes/Noなど、あらかじめ定義された型に従って判断結果を返す
- 構造化出力付きLLMとの違い:
- Jevのために新しいモデルアーキテクチャ、並列サンプラー、学習アルゴリズムを設計した
- 既存LLMの出力をJSONにしたのではなく、ソフトウェアからの直接利用を前提にモデル設計自体を変えた
- 想定される処理:
- 分類、ルーティング、評価、抽出、分岐（classify, route, score, extract, branch）
- 通常のソフトウェア内部でも頻繁に発生する判断
- smart if-statements:
- この利用形態をTypeSafeは「スマートなIF文」と表現している
- a new intelligence primitive for software:
- primitiveはより大きなソフトウェアを構成する基本部品という意味
- 人間との対話が主目的ではなく、制御フローから直接呼び出される判断部品として設計されている
■ 3. 計算資源を増やす前に「何をモデルにさせるか」を決める
- The Bitterest Lesson:
- Jev公開直前にAlmeidaが発表した論考
- 製品説明ではないが、TypeSafeがJevに至った問題設定を理解するうえで重要
- 機械学習の優先順位:
- Rich Suttonの「The Bitter Lesson」を踏まえた「right task > data > compute > algorithms」
- 計算資源の投入量やアルゴリズムの優劣以前に、モデルに何をさせるかの設定が最も重要
- InstructGPTの例:
- GPT-3は次tokenの予測という目的に対しては優秀だった
- 人間が求めたのは高性能なautocompleteではなく、指示に従って仕事をするモデルだった
- モデル規模を拡大するのではなく、学習するtask自体を変えた
- 得られた教訓:
- 能力を高める際はcomputeやalgorithmの前に「何を最適化するのか」を問い直す必要がある
- Jevへの延長:
- A/B/Cを選ぶ判断だけが必要なら、文章生成能力まで必要なのかという問い
- 確率付き判断が必要なら、そのtask自体にモデルを最適化すればよい
- より強力な汎用モデルよりも、必要な仕事を先に定義し、それに適したモデルを作るという考え方
■ 4. 「God」ではなく「Prod」のための設計
- Prod, not God:
- Almeida本人ではなくLatent Spaceが付けたインタビューのタイトル
- 神のような汎用知能ではなくproductionで使うモデルという対比がインタビュー全体をよく表す
- code to be the consumer:
- Jevの最終的な利用者は人間ではなくsoftwareであり、出力を読むのはコード
- そのため出力形式の変更だけでなく、モデル内部までsoftware向けに最適化する必要がある
- AIとして意識されなくなる未来:
- Jevのようなモデルは最終的にソフトウェアの背景へ入り込む
- 問い合わせ分類、検索結果の関連性評価、処理継続やエスカレーションの判断などが例
- これらがソフトウェア内部で行われるなら、利用者がAIの使用を意識する必要はない
- TypeSafeの方向性:
- 汎用知能そのものではなく、production softwareの中で実際に利用できる知能を作ること
■ 5. ラベルが欲しいだけの処理に文章を生成するLLMの無駄
- VentureBeatの指摘:
- 企業はラベルが一つ必要なだけの判断のために、LLMへ文章を生成させるコストを払っている
- 該当する処理の例:
- 問い合わせの分類、RAGで取得した情報の関連性判定
- 異常検知、モデルルーティング
- 最終的に必要な出力:
- sales / support / billing、relevant / irrelevant、safe / unsafe
- retry / stop、model A / model Bといったラベルや数値
- LLM利用時の非効率:
- 一度token列として出力を生成し、それをソフトウェア側で再び解釈することになる
- typed decisions:
- Jevはこうした判断を型付きの判断として直接返す
- Jevのアプローチ:
- 単なる小型LLMではない
- modern pre-trainingで獲得した能力を、classifierやspecialist modelに近い形でproductionへ持ち込むもの
- 問題の本質:
- LLMによる意味理解能力そのものは否定していない
- 意味理解能力を使うたびに文章生成を経由する必要があるのかが問題
■ 6. まとめ: AIモデルを普通のソフトウェア部品として設計する方向
- Jevの興味深さ:
- 単に小さく効率のよいモデルを作ったことではない
- 「ソフトウェアの中でモデルに何をさせるのか」から逆算してモデル自体を設計している
- 従来の生成AIとの対比:
- これまでは「モデルがどこまで多くのことをできるか」が進化の中心だった
- 出力とAIの役割:
- 出力は文章ではなく、Choice、Score、Yes/Noといったソフトウェアがそのまま扱える値になる
- AIはユーザーと対話する存在ではなく、コードに埋め込まれ必要な判断だけを担う
- 今後の展望:
- AIモデルが一つの巨大な汎用モデルへ集約されるとは限らない
- 用途に応じて特性の異なるモデルをソフトウェア内で使い分ける形が増えていくはず
- もう一つの進化の方向:
- Jevが示すのは、AIモデルを普通のソフトウェア部品としてどう設計するかという方向性