SpecMem、オンライン記憶でツール呼び出しエージェントを高速化

導入

データベース検索、外部 API の実行、業務システムの操作などを行うエージェントでは、最終回答だけでなく、ツール呼び出しの生成も大きな遅延要因になる。関数名や引数、呼び出し順序は依然としてトークン単位で自己回帰的に生成されるためだ。推測デコードを使えば、高速な仕組みで呼び出し候補を作り、対象モデルで検証できる。しかし、過去の呼び出しを最初に一度だけ保存したドラフトストアは、新しいセッションやタスクが増えるにつれて適合しにくくなる。

arXiv で発表された SpecMem は、この問題をモデルの再学習ではなく、運用中の記憶管理として捉える。実際のトラフィックに合わせて、推測デコードの候補源を更新し続ける設計である。

主なポイント

• 検証済み呼び出しを即時に書き戻す。 対象モデルによる検証を通過したツール呼び出しを記憶へ追加する。ストアはユーザーごとに上限を設け、LRU で古い項目を削除する。
• 新しい作業への適応を維持する。 マルチセッション・マルチユーザーのストリームでは、固定ストアの受理率が徐々に低下する。一方、SpecMem は運用中に現れた新しいパターンを取り込む。3つのオープンウェイトモデルで、平均受理トークン数は固定方式と比べて27%の差を示し、ベンチマークごとの差は11%から34%だった。実時間では最大1.74倍の高速化が報告されている。
• 安全性は検索信頼度ではなく副作用で制御する。 不可逆な操作は、検証が完了するまで実行を保留する。消融実験では、検索信頼度に基づくゲートより、宣言された副作用に基づくゲートの方が不可逆な誤操作をなくす仕組みとして機能した。
• ユーザー分離は主に情報保護のためにある。 ユーザー別のスコープは受理率を改善しなかったが、実験で確認されたユーザー間の漏えい経路を閉じた。速度と分離は別々の設計目標だと分かる。

意義と影響

この研究が示すのは、推測デコードの性能がモデルや検証器だけでなく、ドラフトの供給元をどう管理するかにも左右されるという点だ。初期状態で有効なキャッシュでも、実運用で新しい要求が増えれば陳腐化する。ユーザーごとに行動パターンが繰り返されるアシスタントや業務ワークフローでは、オンライン更新によってその価値を長く保てる可能性がある。

同時に、容量制限、追い出し規則、ユーザー境界を明確にする必要がある。ツール側も副作用の有無を正しく宣言し、検証経路を高速化ロジックで迂回させてはならない。SpecMem は単独のデコードアルゴリズムというより、予測可能な呼び出しは先に提案し、不可逆な操作は確認を待つという運用設計の指針と見るべきだろう。

出典：arXiv