代理系統
PILOT、決定論的ガードレールで淘宝(Taobao)のレコメンド実験を管理、探索効率は53.3%から93.3%に向上
PILOTは、実験管理、セグメント別戦略の探索、メモリ整理を3つのLLMロールに担わせる一方、権限管理、統計的判定、状態の書き込みは決定論的サービスに委ねる。淘宝の5つのオンラインbucketにおける社内結果では探索効率が40ポイント向上したが、公開再現可能なコードやトラフィック規模は報告されていない。

淘宝チームは、LLMエージェントが推薦リストを直接生成するのではなく、オンライン推薦システムの実験設計に参加するPILOTを提案した。システムは3つのロールで構成される。Experiment Managerは、要件確認、モニタリング、異常対応、実験終了を管理する。Search Plannerは、決定木を用いてユーザーセグメントごとの候補戦略を提案する。Memory Curatorは、結果の確定後、戦略の差異と実験手法を、出典と信頼度を付したメモリとして整理する。
このアーキテクチャの要点は、エージェントにより多くの権限を与えることではなく、その意思決定空間を制限することにある。Manager Guardは、状態機械と凍結ポリシーに基づいて正当な命令の集合を生成し、LLMはその中からしか選択できない。State Committerは、状態を書き込める唯一のコンポーネントである。Statistics Engineはエージェントが変更できない判定証明を生成し、Contract Builderはデータ収集前に成功、失敗、観察期間延長の条件を固定する。Candidate ValidatorとAction Enumeratorは、Plannerが許可されていない操作を作り出すことを防ぐ。推定量、トラフィック予算、停止規則、最終的なスケール拡大といった高リスク項目には、引き続き人間による確認が必要となる。
探索では、固定ベースラインB0、現行のChampion、Challengerという構成を採用する。各ChallengerがChampionに対して加えられるのは、1つのアトミックな変更だけであり、事前登録されたルールに基づいてpromote、reject、continueのいずれかの証明を取得する。結果の覗き見、日付の恣意的な選択、しきい値の反復的な変更といったリスクを抑えるため、観察ウィンドウが実際に終了するまで、指標の方向性は意思決定に利用されない。メモリにもタスクのブランチとマージの仕組みを採用し、検証済みの内容だけが共有ナレッジベースに取り込まれる。
チームは、淘宝ホーム画面の「猜你喜欢(おすすめ)」に設けた5つの実験bucketで、PILOTと自由探索型のROAMを比較した。報告によると、探索効率は53.3%から93.3%に向上した。最も成果の高かったbucketでは、商品詳細ページの閲覧数、コア閲覧数、取引件数、取引金額が、それぞれ1.40%、1.60%、0.96%、1.50%増加した。技術的な意義は、LLMによる意味的判断を既存のA/Bテスト基盤に組み込みながら、不可逆な操作を監査可能なサービス内にとどめる方法を示した点にある。
ただし、これらは単一プラットフォームが自ら報告したオンライン結果である。論文では、トラフィック量、信頼区間、モデルコスト、完全なコードが開示されておらず、5つのbucketだけでは複数のユースケースに汎化できることを証明するには不十分だ。エンジニアリングチームは今後、ガードレールによる誤判定、エージェントのレイテンシ、メモリ汚染に加え、性能向上が追加の推論コストと実験トラフィックのコストを相殺できるかどうかに注目すべきである。