接続を占有せずに、AI アシスタントの負荷をさばく

背景

オンラインの EC プラットフォームで、既存の業務フローに加えて、顧客に応対する AI カスタマーサポートがありました。

課題と不明確だった点

あらゆる LLM プロダクトの中心には、構造的なミスマッチがあります：モデルの 1 ターンは数十秒かかることがあるのに、Web リクエストがモデルに届くまでに通過するもの —— ゲートウェイ、ファイアウォール、プロキシ —— はすべて、ミリ秒単位のリクエストを前提にタイムアウトが設定されています。だから同期設計には失敗のしかたが 2 つあります。わかりやすいほうは、遅い回答が経路上のどこかの上限を超えること。見落とされるほうは、それが動いているあいだ経路を占有し、次の顧客が後ろで待たされることです。外から見ると、この 2 つは区別がつきません：AI が遅い。そしてどちらもモデルの問題ではありません。

私の担当

社内の AI カスタマーサポートに関わり —— 知識の構成、応答のルーティング、ツール呼び出し、会話管理、評価、安全面の制御、有人への引き継ぎ —— そしてここで説明するリクエスト経路の変更を設計・納品しました。プラットフォーム本体の本番 EC システムの保守も担当しています。

在職中に意図して選んでいる、公開レベルの表現です。社内の記録はより強い動詞を裏づけますが、公開ページではこちらを使っています。

要件把握

役に立つ問いは「どうすればモデルを速くできるか」ではなく、「この経路上で、リクエストがすぐ終わることを前提にしているものは何か？そして終わらなかったとき、他の人はどうなるか？」でした。この問いに答えると、課題はモデルのチューニングから接続の構成へと入れ替わります。

設計とトレードオフ

同期処理をやめました。リクエストはキューに入り、ブラウザが数秒おきにポーリングして、準備できたら描画します。接続を占有するものが何もないので、経路上のタイムアウト上限が 1 回の会話を左右することはなくなり、顧客は互いに待つのではなく並行して処理されます。代償はクライアント側が少し複雑になることと、待機状態が目に見えることです —— この交換なら何度でもします。もう一方の選択肢は、静かに、しかも不公平に失敗させることだからです。

実装と連携

プラットフォームの既存フレームワーク上の queue workers と、フロントエンドのポーリング、そしてモデル呼び出しの周囲のリトライとエラー処理です。加えて 2 つの制御を持ち込みました：アイドルの会話は期限切れにする —— 静かになった会話には一度だけ促し、応答がなければ閉じて占有していたリソースを解放します。そして軽いリクエストは小さいモデル階層へルーティングし、毎回いちばん大きなモデルを叩かないようにしました —— 重要な回答の品質を落とさずにできる、最も単純な推論コストの制御です。

本番運用の作り込み

モデル呼び出しの周囲のリトライとエラー処理、会話のライフサイクル管理、そして「後付けではなく設計に組み込む」評価の考え方 —— 1 つの回答が複数の情報を検索して統合する必要があるときの正確さと、敵対的・ソーシャルエンジニアリング的な探りに対する挙動を含みます。その評価は構築中であって、完了した本番向けの強化ではありません —— 私が説明しているのは設計であって、結果ではありません。

結果

この作り替えは完了し、プラットフォームにマージされています。この仕事について性能の数字は公表しませんし、今後もしません —— 正直に主張できる本番の結果を持っていないからです。

持ち越せる学び

AI の機能が「遅い」と言われたら、モデルに手をつける前に経路を測ってください。私の経験では、モデルはそれまでと同じことをしていて、変わったのは周囲の構成が利用者の体験に与える影響です —— そして直し方はほぼ必ず、接続を占有するのをやめることです。