すべてをトークンでコスト計算すべきではない：決定論的AIの提唱

すべてをトークンでコスト計算すべきではない：決定論的AIの提唱 最近話を聞いたチームが、シンプルなタスクを実行するエージェントを開発しました。毎朝、メトリクスAPIからデータを取得し、JSONを整形してテーブルに格納するというものです。素晴らしいアイデアでした。初日はうまくいきました。しかし、請求書が届いたとき、その「シンプルな」ジョブが毎朝、数千トークンの生のJSONをコンテキストウィンドウに読み込み、推論する必要のないデータを言語モデルに整形させ、その対価を支払っていることに気づきました。さらに、整形は時折間違っていました。なぜなら、確率的なモデルが、5行のスクリプトなら毎回同じように実行できる作業を行っていたからです。コンテキストウィンドウは古いデータで埋め尽くされ、エージェントが本来行うべき推論の質まで低下してしまいました。この落とし穴には、現在ほとんどの人が陥っています。チームは言語モデルをユニバーサルランタイムとして扱います。タスクを文章で説明できれば、それをプロンプトにします。しかし、モデルはcronジョブでもデータベースでもありません。それはトークン単位で借りている推論エンジンであり、請求額を急増させ、出力を低下させる最も速い方法は、そもそも頭脳を必要としなかった作業をそれにやらせることです。学ぶべきスキルは、何をトークン化しないかを知ることです。 なぜ「すべてはプロンプト」が正しく聞こえ、多大なコストがかかるのか その魅力は明白です。プロンプトは高速です。スキーマ設計、エンドポイント、デプロイをスキップできます。ただ尋ねるだけです。一度きりのタスクであれば、それはまさに正しい選択です。問題は、一度きりが繰り返し行うジョブになったときに現れます。モデル経由でルーティングするすべての決定論的なタスクは、本来持つべきではなかった3つの特性を継承します。それは、非決定論的になり、遅くなり、従量課金制になるということです。スケジュールされた関数が無料で、決して間違えずに実行する作業に対して、実行ごとに料金を支払うことになります。そして、互いに増幅し合う2つの症状が現れます。最初の症状は、間違ったものにコストがスケーリングすることです。トークン消費量は、求めている判断の価値に追随すべきです。代わりに、モデルに押し込んだ機械的な作業量に追随します。1日1つのAPIではなく10個のAPIを呼び出すと、その呼び出しに知性は必要なかったにもかかわらず、請求額は10倍になります。2つ目は、コンテキストの肥大化です。「処理」するために、チームはデータをコンテキストウィンドウに読み込みます。しかし、コンテキストウィンドウは有限であり、推論が行われる場所です。生のレコードでそれを満たすと、モデルが実際に得意とすることから場所を奪ってしまいます。品質が低下し、ほとんどのプロバイダーは入力トークンを計測するため、長いコンテキストのコストは同時に上昇します。より悪い回答を得るためにより多くのお金を払うことになります。それが痛いところです。 それを解決する区別：確率的作業 vs. 決定論的作業 私が常に立ち返るメンタルモデルがあります。実行場所を決定する前に、すべてのタスクを2つのバケットのいずれかに分類します。 エージェントに属するもの（確率的） アプリに属するもの（決定論的） 判断と解釈 スケジュールされた反復タスク ドラフト作成、要約、分類 API呼び出しとデータ変換 何をすべきか、何が重要かを決定する 格納、取得、クエリ 曖昧さとエッジケースの処理 実行ごとに正確かつ再現可能でなければならないもの 線引きはシンプルです。タスクに判断が必要なら、それはエージェントに属します。タスクに正確さと再現性が必要なら、それはアプリに属します。決定論は制限ではなく、機能です。毎朝同一に実行されるスケジュールジョブは、退屈で予測可能なものであることが望ましいです。そして、この考え方全体のアンカーラインがあります。トークンを使ってアプリを一度構築すれば、それが実行されるたびにトークンを支払うのをやめることができます。知性は機械の創造に注がれます。機械自体は無料で実行されます。「何をトークン化しないかを学ぶ」とは、一度切り替える設定ではなく、すべてのタスクで実践する規律です。 誰もが間違える点：メモリノートをデータベースとして使う これは、それ自体で呼び出す価値のある間違いの特定のバージョンであり、賢い人々が絶えずそれを行っているのを目にします。人々はエージェントのメモリやノートをデータベースとして使用します。構造化されたデータ（レコード、メトリクス、パイプラインステージ、顧客リスト、在庫数など）をノートにドロップし始めます。ノートがすぐそばにあり、エージェントがそれをすでに読んでいるため、自然に感じられます。しかし、ノートは構造化データには不適切なツールであり、その理由はすぐに積み重なります。スキーマがないため、一貫性を強制するものはありません。クエリがないため、エージェントはフィールドが必要なときに毎回ノート全体をコンテキストに読み込むため、遅く、計測されます。そして、ノートは成長するにつれて劣化します。なぜなら、半構造化されたテキストの壁は、まさに実際のテーブルが存在する理由だからです。 ここで、「データベースを使えばいい」というアドバイスで見失われがちな、そして重要な部分があります。メモリノート自体が問題なのではありません。間違った仕事にそれらを使用することが問題なのです。ノートは、クリーンなスキーマがなく、今後も決して存在しない、まったく異なるカテゴリのコンテキストにとって、本当に適切なツールです。好み。トーンとボイス。エージェントが学んだパターン。決定とその背後にある理由。「これは我々のやり方だ」という知識は、エージェントの考え方を形作りますが、SELECTを実行するようなものではありません。そのコンテキストは意図的に非構造化されており、判断を伝えるために存在します。それを厳格なテーブルに押し込むと、それが有用であったニュアンスが失われてしまいます。したがって、ルールは両方に適用されます。構造化され、クエリ可能で、大量のデータは実際のデータベースに入れます。非構造化され、解釈的で、推論を形作るコンテキストはノートに残します。顧客リストをノートに入れると、苦痛を感じるでしょう。ブランドボイスガイドをデータベースに入れると、元々問題なかったものを過剰設計したことになります。ツールの形状をデータの形状に合わせれば、両方の問題は消えます。 Vybeモデル：AIとアプリ、それぞれが独自のレーンに ここで、アーキテクチャは哲学から製品の決定へと移行します。Vybeでは、エージェントは単にチャットするだけでなく、実際のアプリケーションを構築・運用します。「何をトークン化しないかを学ぶ」ことが、単なる良いアドバイスではなく、実際に達成可能になるのは、エージェントが決定論的な作業を配置する場所があるからです。パターンは次のようになります。反復的な作業は、モデルに実行を覚えておくように依頼するのではなく、アプリ内でスケジュールされます。データ取得と変換は、エージェントが必要なときに呼び出すアプリのエンドポイントの背後に配置されるため、機械的なステップはプロンプトではなくコードとして実行されます。状態は、エージェントが決定論的にクエリする実際のデータベースに格納されます。エージェントがオーケストレーションと推論を行い、アプリが実行と記憶を行います。各レイヤーは、実際に構築されたジョブを実行します。 2つの例がそれを具体的にします。そのうちの1つは私たち自身のものです。競合レーダー。私たちは社内で競合追跡エージェントを構築しました。競合データをコンテキストやノートに溜め込むことも容易でした。しかし、そうしませんでした。スケジュールされたリフレッシュを備えたライブデータベースアプリを構築しました。スケジューリング、取得、格納はすべて、決定論的な作業としてアプリレイヤーで行われます。エージェントは、脳が必要とする部分、つまり実際にフラグを立てる価値があるものを決定する部分にのみトークンを費やします。そのシステムは出荷され稼働しており、エージェントが配管自体を行っていた場合よりもトークンコストはわずかです。Falcon。私たちのギャラリーにあるFalconは、競合他社の変更履歴、ブログ、ソーシャル活動を毎日監視し、スケジュールされたインテリジェンスブリーフをメールで配信する競合インテリジェンスアナリストです。同じアーキテクチャで、今回は顧客向けです。監視のケイデンスとメール配信は、決定論的なアプリレベルの配管です。これらはスケジュール通りに、毎日同一に実行されます。Falconがトークンを費やすのは、判断の呼び出し、つまりこの変更は実際にシグナルなのか、それともノイズなのか、という部分だけです。アーキテクチャはまさに期待通りに機能しています。 両者に共通することに注目してください。高価で知的なリソースは、知性が必要なジョブのその部分に向けられています。それ以外のすべては、安価で信頼性の高い、決定論的なコードとして実行されます。 なぜこれがコピーしにくいのか 市場のほとんどのツールはこれを行うことができません。その理由は、洗練度の問題ではなく、構造的な問題です。純粋なチャットエージェントアシスタント、単一モデルのコパイロット、Slackの