映画『メン・イン・ブラック 2』で、エージェント J はごく普通の郵便局に見える場所で K を訪ねる。彼は仕分け機を開け、その中で手紙を猛スピードで仕分けているエイリアンを見つける。
ばかばかしい短いシーンだが、AI について考えるための便利な視点も与えてくれる。
何かを受け取ってからそれを使って何かをするまでの間に、たいていはもっと小さな判断が挟まる。「これはどこに分類されるのか？」という問いだ。
この判断を早い段階で正確に下せれば、システムの残りの部分は適切な経路を進める。
私は AI ソフトウェアを作りながら、あの小さなエイリアンのことをずっと考えていた。
あるアプリケーションが、請求に関する質問、バグ報告、製品写真、デモ予約のリクエストを受け取る。それぞれに必要な対応は異なる。それなのに結局、同じ大規模言語モデルにすべてを検査させ、次に何をすべきか考えさせてしまうことがある。効率もコストパフォーマンスも最悪だ。
だからこそ、専門特化型モデルが今後の AI でより大きな役割を果たすと考えている。たとえば Jev は、ソフトウェアが実行できる構造化された意思決定のために作られている。Coinbase は Qwen3.5-9B を Onramp サービスの不正検知向けに特化して調整した。どちらも明確な仕事に集中し、結果を測定できる。
https://x.com/brian_armstrong/status/2109412046244913643
私が作っているのは「仕分けレイヤー」だ。
見慣れたリクエストは、そのまま定義済みのワークフローへ進められる。より深い推論が必要なリクエストは別のモデルへ送られる。曖昧なものは確認やレビューのためにフラグが立てられる。
節約の可能性は、各リクエストに必要なだけの処理量を割り当てることから生まれる。そして、その仕分け機が十分な精度で判断を下し、存在する価値があるかを測定しなければならない。
私たちの出発点は CludeMem だった。AI が何を記憶すべきか、何を取得すべきか、何が不要にトークンを消費しているかを判断しようとしていたのだ。永続的な好み、一時的な指示、未解決の質問は、それぞれ異なる扱いを受けるべきだ。そうした判断の前に、情報を分類する必要があった。
それが、より広い分類レイヤーというアイデアにつながった。同じステップで、サポートリクエストの仕分け、ドキュメントのルーティング、タスクを担当する専門家の選択ができるようになる。
GIF
専門特化型モデルが増えるにつれ、アプリケーションはどの入力に注意を向けるべきか判断しなければならなくなる。私たちが作っているのはまさにその部分だ。届いたものを分類し、見慣れたケースはローカルで処理し、難しいものは適切なモデルやレビュー工程に渡す。
ここで Clude Cat の登場だ（Cat は categorisation（分類） 😉）。
メモリを保存したり、ドキュメントを取得したり、ツールを呼び出したり、応答を生成したりする前に、通常は「どのような種類の情報を扱っているのか」という判断が必要になる。
こうした判断は至るところにある。
誰かがソフトウェア会社にこう書いたと想像してほしい。
「請求書はどこからダウンロードできますか？」
AI エージェントはメッセージを読み、利用可能なツールを確認し、顧客の意図を推測して、請求書を探すことに決められる。
より直接的なワークフローは次のようになるだろう。
メッセージ → 請求書類のリクエスト → アカウント認証 → 請求書の取得。
返信文を書くのは依然として言語モデルの仕事だ。最初のルーティング判断はローカルで処理できるかもしれない。
では、メッセージを変えてみよう。
「二重請求され、アカウントがロックされ、解約したい。」
これを自信満々に単一の請求書ワークフローへ流し込めば、作業はむしろ増える。解決すべき問題が複数あり、適切な対応には確認や人間の介入が必要になるかもしれない。
仕分け機には「これは確実に分類できません」と言える権限が必要だ。
それはプロダクトの本質的な部分だ。間違った宛先にリクエストを自信満々に送り込むシステムは、ミスを修正する手間によって速度面の優位性を打ち消してしまう。
顧客にとっての狙いは、待ち時間の短縮と繰り返しの削減だ。
開発者にとっては、検査・テスト・変更が可能な明示的な判断となる。選択されたカテゴリ、モデルのバージョン、処理時間、そしてシステムが判断を保留したかどうかが見える。
内部的には、テキスト実装はエンコーダーと呼ばれる小さな事前学習済みモデルから始まる。
エンコーダーはメッセージを、その意味の側面を表す数値のリストに変換する。開発者はこの表現を埋め込み（embedding）と呼ぶ。
「請求書はどこですか？」と「請求書のコピーが必要です」は使われている単語が異なる。しかし数値表現は十分に似ており、システムは同じ種類のリクエストだと認識できる。
分類レイヤーはこれらの表現を使い、開発者が定義したカテゴリをスコアリングする。
私たちは 2 つのアプローチを実装した。1 つは受信メッセージを各カテゴリの例と比較するもの。もう 1 つはラベル付きの例からカテゴリ間の境界を学習するものだ。
後者のフィッティング方式では、エンコーダーを固定し、その上にある小さな決定レイヤーだけを訓練する。アプリケーションごとに新しい基盤モデルを訓練する必要はない。
それでも開発者は、各カテゴリの意味を定義し、有用なアクションに結びつけなければならない。分類器が会社の部署、返金ポリシー、アカウント権限を勝手に発明することはできない。
また、受け入れポリシーも必要だ。
最もスコアの高いカテゴリでも、実際には不適切な場合がある。2 つのカテゴリがほぼ同点になることもある。未知のリクエストが見慣れたものに似ていることもある。
現時点でのローカルスコアは較正された確率ではない。スコア 0.92 が自動的に「92% の確率で正しい」を意味するわけではない。
これらのスコアが判断を制御したときに何が起こるかをテストしなければならない。
そのため出力は、受け入れられたカテゴリ、レビューが必要なリクエスト、技術的な失敗を区別する。タイムアウト、キャンセル、モデルエラーにも予測可能な処理が必要だ。
これが仕分け機を取り巻くエンジニアリングであり、他のアプリケーションがその結果を安全かつ一貫して利用できるかどうかを決める。
このアプローチで生成モデルの負荷を減らせるかを確認するため、770 件の銀行関連リクエストで実験を行った。
第 1 の構成では、すべてのリクエストをローカルで動作する Qwen2.5 7B モデルに送り、分類させた。
第 2 の構成では、まずローカル分類器を使い、未解決のリクエストだけを Qwen に送った。
結果は以下の通りだ。
- Qwen の呼び出し回数が 770 回から 227 回に減少した。
- 正しい分類が 535 件から 642 件に増加した。
- 全入力における精度が 69.5% から 83.4% に上昇した。
- 計測されたクエリ時間の合計が 299.7 秒から 87.7 秒に短縮された。
ローカル段階で 543 回の Qwen 呼び出しを回避でき、70.5% の削減となった。
キャッシュは有効にしたままで、直接方式を先に実行し、その後で組み合わせ方式を実行した。タイミングの数値にはセットアップとウォームアップを含めていない。最終的な顧客向け返信の生成やモデルプロバイダーへの支払いは行わず、分類のみを計測した。
これらの数値はこの構成のものであり、あらゆる LLM に対する優位性や、顧客側のコスト削減を保証するものではない。
その後に行った別の実験では、旅行および職場に関する 24 のインテントに対してフィッティング済みローカル分類器をテストした。
720 件のリクエストのうち、688 件をローカルで受け入れた。そのうち 681 件が正解で、7 件が誤りだった。32 件はレビューに残された。
ここから 2 つの指標が得られる。
- カバレッジ：リクエストの 95.6% をローカルで処理した。
- 受け入れ精度：受け入れた判断のうち 99.0% が正しかった。
両方とも結果に含める必要がある。簡単なリクエストだけを選んで受け入れれば、見かけ上の精度は高くなるからだ。
さらに、サポート対象カテゴリの外にあるはずの未知の入力 10 万件もテストした。94% 以上の確率で正しく判定できた。
システムが「知らないこと」を認識できるかは、依然として重要な作業の一部だ。
速度についても同じ慎重さが必要だ。別のウォーム状態の CPU テストでは、M4 Max 上で完全な銀行分類器が 1 リクエストあたり中央値で約 1.8 ミリ秒かかった。これにはトークン化、埋め込み、スコアリングが含まれる。
モデルのダウンロードや起動時間は含まれていない。これは分類の計測であり、ユーザーのリクエスト全体を解決するまでの時間ではない。また、スマートフォンや一般的なノートパソコンで同等の性能が出ることを示すものでもない。
Jev がこの議論に関わるのは、すでに似た種類の判断に対応しているからだ。
TypeSafe は Jev を、提示された選択肢からの選定や、リクエストを通常のコード・専門モデル・人間へ振り分けるなど、範囲が限定された判断のためのモデルとして文書化している。\Jev のインテント・ルーティングに関するドキュメント\
私が考える Jev の役割は、ローカル分類器が確実に解決できないリクエストのための、任意のエスカレーション先だ。
私たちが目指しているアーキテクチャはシンプルだ。
受信リクエスト → ローカル分類 → 見慣れたリクエストは定義済みの経路へ。不確かなリクエストは Jev、別のモデル、または人間のレビューへ。
Jev がなくても、同じローカル分類段階で、未解決のリクエストをアプリケーション既存の LLM、確認ステップ、レビュー工程に戻せる。
カテゴリ、受け入れ閾値、フォールバックは開発者が制御する。既存のワークフローにローカル分類器を組み込み、どの判断を任せられるかを測定できる。
現在、Jev との統合はシャドウモードで動作しており、5 つの大まかなトピックにわたって判断を比較するだけで、アプリケーションの挙動は変えない。次のステップは、選択的なエスカレーションがワークフロー全体を改善するかどうかの検証だ。前述の Qwen の結果は Jev のベンチマークではない。
測定すべきはまさにこれです。不要なモデル呼び出しの削減、見慣れたリクエストの高速な処理、そしてより注意が必要なケースに対する明示的な経路の確保。
同じアプローチを画像にも拡張し始めた。
レシート、エラーのスクリーンショット、製品写真を受け取るビジネスを想像してほしい。それぞれに異なる処理経路が必要だ。
レシートはレシート抽出へ。スクリーンショットはサポートワークフローへ。製品写真はカタログワークフローへ。不確かな画像はレビューへ送れる。
分類器が行き先を選ぶ。購入合計額の読み取り、エラーの診断、製品詳細の特定は、それぞれ別のタスクのままだ。
実験的な画像実装では、事前学習済み CLIP エンコーダーを使って画像の数値表現を生成している。
フィッティング済みの研究用候補モデルは、小規模な診断テストで食品写真 20 枚中 19 枚を正しく分類した。また、豆の葉の画像 30 枚はすべてレビューへ送った。
間違いは、ボトルの栄養成分表示とバーコードをレシートとして分類してしまったことだ。
問題は明白だ。どちらも密集したテキスト、数字、長方形のレイアウトを含みうる。アプリケーションにとって重要な境界を教えるための例が必要なのだ。
このサンプルは本番環境での主張には狭すぎる。ラベルはデータセット由来で独立した判定によるものではなく、テストには新しいレシートやスクリーンショットの例が含まれていなかった。公開デモは別のベースラインを使用しているため、フィッティング済み候補の結果をそれに帰属させるべきではない。
画像処理はテキスト分類よりも負荷が高かった。M4 Max 上でのウォーム状態の中央値処理時間は、Node で約 36 ミリ秒、Chromium で約 197 ミリ秒だった。ブラウザではまず約 85 MiB のモデルアセットとランタイムが必要になる。
ローカル実行にもコストはある。ダウンロードサイズ、メモリ、起動時間、デバイスの性能はすべて評価対象だ。
私が思い描いているプロダクトは、既存のアプリケーションに組み込まれ、「次に何をすべきか」を判断するものだ。
開発者がカテゴリを定義し、代表的な例を提供し、行き先を接続し、分類が不確かな場合の挙動を選択する。
最初の導入では、結果を変えずに現在のワークフローを観察すべきだ。その後、提案された判断と検証済みの結果を比較してから、分類器にルーティングを任せる。
受け入れられた間違いは、却下されたリクエストと同じくらい慎重に検査する必要がある。そうしなければ、自信に満ちた誤りが安心感のあるスコアの裏に隠れてしまう。
訓練、較正、テストにもそれぞれ別のデータが必要だ。訓練はカテゴリを教え込む。較正は受け入れルールを選ぶ。保護されたテストは固定された結果を検証する。
テストでのミスが次のモデルに影響を与えた時点で、その例は開発用データになってしまう。次の評価には新しいテストが必要だ。
郵便仕分け機の小さなエイリアンは、この仕事をイメージしやすくしてくれる。有用なものを作るには、どの入力を確実に処理できるか、いつ助けを求めるべきか、ミスにどれだけのコストがかかるかを正確に見極める必要がある。
次のステップは、独立したラベルとすべての結果の記録を備えた、代表性のあるワークフローだ。ローカル経路を通るリクエストの数、別のモデルに到達する数、間違える数、そしてそれらのエラーを考慮してもアプリケーション全体が速く・安くなるかを測定しなければならない。
スケールアップして、このローカルモデルにドーピングを与える時が来た。
