Instacart、エージェント活用による機械学習モデリングの運用変革を報告

imageTilman Drerup, Moe Moazzami, Shih-Ting Lin, Greg Reda (and many more)

導入

Instacart では、人工知能が機械学習エンジニアの働き方を根本から変えています。以前のブログ記事では、あるチームを事例として取り上げ、エージェントの登場が機械学習エンジニアの時間配分をどう再構築したかを解説しました。

今回の記事はさらに一歩踏み込み、機械学習モデリングのプロセスそのものに焦点を当てます。AI を活用した研究開発における最近の進展により、この分野では新たな可能性が開かれ、私たちは現在も積極的に探求を進めています。複数の機械学習エンジニアからの知見を統合し、これまでの大きな成果や悔しい失敗、そして予期せぬ驚きについて共有します。

それでは詳しく見ていきましょう。

全体像

機械学習モデルは、Instacart のマーケットプレイス全体に浸透し、検索結果から代替商品の推奨、配送時間の予測に至るまで、あらゆる機能を支えています。これらのモデルはすべて、熟練した MLE（機械学習エンジニア）によって慎重に構築され、維持・改善されています。

モデル作成に費やす時間は会社にとって極めて大きなインパクトを持ちますが、そのプロセス自体は非常に時間がかかり、MLE が数多くの大小の意思決定を下す必要があります。具体的には、適切なモデリングアーキテクチャの選定、多数のハイパーパラメータの最適化、取り込む特徴量の選択、最も適した損失関数の決定などが含まれます。これらの判断は通常、関連する文献を相当量レビューすることと、MLE の直感に裏打ちされた経験則に基づいて行われます。

残念ながら、この問題が抱える組み合わせ的な複雑さと、人間の時間の制約を考慮すると、MLE が探索できるのはモデル作成の選択肢全体のごく一部に限られがちです。その結果、潜在的な価値の多くが見過ごされてしまうケースも少なくありません。

ここ数ヶ月、Instacart の MLE たちは、この課題に対処するために AI エージェントを活用したモデリングループの開発に取り組んできました。以下では、これまでの取り組みを要約し、多様なモデル作成の文脈で有効だった手法や、予期せぬ発見、そして現在も警戒している点について紹介します。

Stylized Setup

概念的に、当社のチームはエージェント支援型モデリングを「人間がループに参加する問題」と捉えています。機械学習エンジニア（MLE）が解決すべき課題の定義と作業の監督を担当し、エージェントには仮説の開発・実装、そして事前に定められた目標や制約に対する評価という役割を与えています。必要に応じて、MLE はいつでも介入してエージェントの取り組みを方向転換できます。

以下の図は、この一般的なアプローチを示しています。

インフラ面では、多くのチームが社内 ML プラットフォームである Griffin に大きく依存しました。Griffin はモデルの推定と評価を特に容易にし、複雑なモデリング問題に対して大規模な計算リソースを活用することを可能にしました。なお、ここでは実装の詳細は省略しますが、将来的にこのトピックについて改めて取り上げる可能性があります。現在、私たちはこうしたエージェント支援型モデリングユースケースを特化してサポートする新しいインフラの構築に積極的に取り組んでいます。

事例研究

より具体的なイメージを持っていただくため、比較的よく知られた 2 つのモデリング問題に対してエージェントが挑戦した事例を 2 つご紹介します。

配送時間

配送時間予測モデルは、Instacart の物流システムにおける「ルーティング」機能の中核的な入力データです。ルーティングでは、注文をどのようにグループ化し、順序付けするかを決定します。このモデルは、店舗から最初の顧客へ、あるいは複数注文のバッチ内での顧客間など、配送の各区間の所要時間を予測するものです。

もし配送時間の見積もりが短すぎれば配送が遅延し、長すぎればルーティングシステムが効率的な複数注文ルートを却下してしまう可能性があります。

このモデルの生産環境におけるベースラインは、長年の慎重な改良を経て成熟した、トラフィック情報を活用した勾配ブーストツリーモデルです。特徴量には地理情報や顧客・店舗の位置、時間帯に加え、ルート距離、移動時間、速度などが含まれています。このような強力なベースラインが存在する中で、自律的な研究ループが現状を大幅に改善できるのかについては、当初は懐疑的でした。

アジェンティックモデリングの可能性を公平に評価するため、私たちはこの課題をモデル開発のハッカソンとして捉えました。複数の機械学習エンジニア（MLE）が独立した自己研究ループを実行し、既存の常識に挑戦する形で、異なるモデルファミリーや特徴量、チューニング戦略を探求しました。

比較可能性を確保するため、すべての MLE は同じ標準的なデータスナップショットと生産環境ベースラインを使用しました。これには共有されたデータ分割、明確な検証指標、そして明示的なガードレールが含まれています。

結果は、我々が正しい道を進んでいることを疑う余地もありませんでした。MLE（機械学習エンジニア）間でのいくつかの試行錯誤がありましたが、多くのケースで共通のベースラインに対して有意な改善が見られ、最も有望な実験では保持されたデータセットにおける平均絶対誤差（MAE）が 3〜5% 低下しました。例えば、LightGBM の 30 回の探索により、本番環境との比較で MAE が 3.6% 削減され、別の試みではチューニングされた MLP（多層パーセプトロン）の探索が木ベースのベースラインに対して 4.8% の削減を達成しました。注意すべきは、この成果をもたらしたのは単一の「魔法のような」実験ではないということです。個々のエージェントは、独自の仮説を立て、失敗した試行から学び、複数の改善を重ねることで前進しました。

以下のグラフは、あるエージェントによる 30 回の連続実験のうち 1 つの具体的な実行を拡大表示し、このループの様子を示しています。

image図：30 回の実験における最良の検証 MAE。平坦な部分はエージェントが試し、却下したアイデアを示しています。その後の低下は、直近の重み付け、シード平均化、および木モデルの容量に対する集中的な変更によるものです。

この特定のランでは、探索は以下の 3 つの主要な段階を経て展開されました：

異なるモデルファミリーを試すことが重要です。生産環境で使われていたヒストグラムベースのモデルから LightGBM へ移行したことで、最も大きな初期の性能向上が実現しました。CatBoost も競争力がありましたが、反復に時間がかかりました。一方、XGBoost やその他のバリアントは期待通りの結果を出せませんでした。

また、マルチ GPU 学習に関する別の仮説ラインでは、学習済みカテゴリカル埋め込みを持つニューラルネットワークが、訓練データの量が増えるにつれて次第に競争力を持つようになることが明らかになりました。

有望なアーキテクチャを微調整する。ニューラルネットワークのブランチは、バッチ正規化と軽いドロップアウトを備えたより深い MLP に収束しました。また、Huber 損失の閾値を下げることで、異常に長い配送の影響を抑え、意味のある改善をもたらすことができました。これらの設定は数十回の試行を通じて導き出されたもので、手動で行うには手間がかかるが価値のある、慎重で相互作用的なハイパーパラメータ調整の典型例です。

小さな改善を組み合わせる。LightGBM においては、エージェントが以下の手法から追加的な効果を得ました：直近のサンプルにより重みを付与する、異なる乱数シードで訓練したモデルを平均化する、リーフ容量を増やす、および各リーフに含める最小サンプル数を調整する。いずれも単独では劇的な変化をもたらしませんでしたが、これらを組み合わせることで、大きなアーキテクチャ上の改善を達成した後にも誤差をさらに低下させることができました。

上記の例は、エージェント支援型モデリングプロセスが持つ適応性の高さをよく示しています。初期段階ではリーフ数を増やすと LightGBM の性能が低下したため、エージェントはその変更を却下しました。しかし、シード平均化によってモデルが安定した後、エージェントは再び同じアイデアを検討し、今回は追加の容量が効果を発揮しました。このように、得られた結果に基づいてモデリング手法を適応させ、修正していく能力こそが、エージェント支援型モデリングの最も顕著な強みの一つであり、これは MLE（機械学習エンジニア）が同様の課題に取り組む際の姿勢に非常に近いです。

次の例では、これらの能力がやや非標準的なモデリング問題にも適用できることが示されます。

カタログ属性抽出

カタログ属性抽出とは、製品情報から構造化され、フィルタリング可能な主張を抽出するタスクです。具体的には、「この製品はグルテンフリーですか？」「小麦を含んでいますか？」といった質問に答えるものです。これらの属性は、Instacart マーケットプレイス全体で、食事制限フィルター、アレルゲン警告、代替品提案などの体験を支えています。

これを大規模に行うため、Instacart では LLM（大規模言語モデル）を活用し、製品名、説明、成分リストから各属性を予測しています。

しかし、LLM の支援があったとしても、カテゴリ分類の改善は依然として非常に時間のかかるプロセスでした。適切なモデルの選定や、回答前の推論範囲を制御するためのパラメータ設定（例）、そして何よりプロンプトの微調整などが必要でした。後者は、詳細な指示の作成、エッジケースへの対応、教育的な例の追加を含むものです。最適な設定を見つけるために、私たちはこれらの選択肢を繰り返し調整し、得られる分類の品質を評価していました。1 ラウンドに最大 2 時間かかることもあり、新しい属性によっては収束までに 20 ラウンド以上必要で、手動での最適化は約 1 週間ものカレンダー時間を要するものでした。

私たちはこの問題を、通常の回帰スタイルの問題とは意味的に異なり、やや扱いやすい従来のアプローチではなく、エージェント駆動の最適化ループを用いて解決できないかと考えていました。そのために、エージェントには現在のプロンプトとモデル設定、そして人間がラベル付けした評価セットを与えました。各ラウンドでは、エラーを分析し、候補となる変更案を提案・評価し、提供された目的関数を改善するものだけを保持するように指示しました。

ここでは、25 ラウンドにわたる最適化実行の一例を示します。低推論コストで始まる GPT-5-mini から出発し、エージェントは承認されたモデルの中から選択し、対応する箇所では推論コストを調整するとともに、プロンプト内の抽出指示を精緻化しました。その目的は、抽出再現率（正解値として抽出された属性値の割合）を最大化しつつ、精度（抽出された値のうち正しいものの割合）が一定の閾値を下回らないように保つことにあります。

image図：25 回の最適化ラウンドにおける最良の抽出再現率。緑色のステップはエージェントが採用した設定、オレンジ色のダイヤモンドは有益な候補だが却下されたケースを示しています。

上記のグラフが示す通り、エージェントは新たな証拠が蓄積されるにつれて戦略を適応させ、その過程で複数の仮説を立案・破棄しました。探索初期にはいくつかのプロンプト修正を試みましたが、いずれも採用に至りませんでした。その後、より直接的な調整要素として推論の努力量とモデル選択に注目します。推論の努力量を増やすことで再現率がベースラインから 2.0 ポイント向上し、GPT-5.4-mini に切り替えることでその効果は 4.0 ポイントに拡大するとともに、適合率も改善されました。

これらの成果を踏まえ、エージェントは 7 ラウンド目に o4-mini を試しましたが、再現率は 9.1 ポイント向上したものの、適合率が設定した下限を下回ってしまいました。9 ラウンド目ではより保守的なプロンプト指示によって適合率を下限以上に回復させましたが、この候補は修正したエラーよりも新たなエラーを生み出していたため、エージェントは却下しました。

o4-mini の候補が却下された後、エージェントは最良の GPT-5.4-mini 設定に戻り、6 つのプロンプト変種をテストしました。保守的な変更は再現率を低下させ、再現率重視の変更は偽陽性が多すぎました。いずれも結果の改善にはつながりませんでしたが、この実験から、GPT-5.4-mini におけるさらなるプロンプト編集は、再現率と適合率の両方を向上させるのではなく、互いとのトレードオフに過ぎないことが示されました。

17 ラウンド目、エージェントは過去の知見と今回の教訓を結びつけました。o4-mini はリコールの余地が十分にあるにもかかわらず、偽陽性（false positives）のために候補が採用されなかったのです。エージェントは o4-mini を再検討し、なぜ候補が失敗したのかを分析しました。その結果、モデルが属性ルールで求められている以上に明確な製品証拠を要求するケースがあることが判明しました。

このパターンに対応するため、抽出指示を見直したところ、25 ラウンド目までに最も強力な設定が完成しました。完了時、リコールは 8.1 ポイント向上しましたが、精度はベースライン付近で維持され、必要な下限値も上回りました。

教訓

全体的に、エージェント支援によるモデリングへの取り組みは大成功でした。基盤となるインフラのスケールアップはまだ進行中ですが、エージェントを起動して広範な仮説を検証するのは通常容易であり、成熟したモデルであっても有意な改善点を見つけることができました。

その過程で、チームは個々のエージェントが課題にどの程度成功するかに影響を与えるいくつかの高レベルなパターンにも気づきました。

仮説空間を広げよう

エージェントは、与えられたモデリング問題のより多様な側面を探索する余地を与えられると、より多くの改善点を見つけ出す傾向があります。これは一見自明のように思えるかもしれませんが、強調して伝える価値があります。

ハイパーパラメータ最適化といった古典的な自動化手法とは異なり、エージェントは人間が時間を制約要因としていた領域、つまり特徴量の拡張や特徴量・ラベル定義の変更、新たなサンプリング戦略の導入、アンサンブル手法の採用など、より曖昧で広範な領域を探索できます。同様に、任意のモデルクラス（XGBoost と CatBoost、AdaBoost、LightGBM、TabPFN など）を比較する際の実装コストと評価コストは現在極めて低く、これらの間で「馬車競走」を行うことが非常に魅力的になっています。

要するに、エージェントを使って与えられたモデリング問題を包括的に探索してください。単なる賢いハイパーパラメータチューニングアルゴリズムとして使うのではなく（もちろんその点でも強力ですが）、より広い視点で活用することが重要です。

評価基準と適応性

エージェント支援モデリングの特に魅力的な点は、新しい結果が入ってくるたびにエージェントが戦略を適応的に変更できることです。これは特定のハイパーパラメータをいくつかグリッド上で微調整するよりもはるかに先を行くアプローチです。

代わりに、エージェントはモデルのパフォーマンスを直接検証し、例えば最も価値を生み出す特徴量の隣接する特徴量を作成するなどして、さらに調査すべき領域を特定できます。同様に、エラー分布の解釈を通じて、モデルが現在苦手としている分布の特定の部分（例えば、地域によって予測精度に差がある場合など）を直接的に改善するためのアプローチを検討することも可能です。

これらの能力を活用するためには、エージェントは与えられたモデルの出力を適切に解釈できる能力を持ち、かつ積極的にそれを促される必要があります。具体的には、モデルのエラー分布を分解するスクリプトを提供することで、その実現を図ります。

人間をループに組み込む

適応的に特定のモデリング問題を探索する際、エージェントは全体像を見失い、特定の小さな部分空間に過度に執着することがあります。この狭い焦点は局所最適解に陥るリスクがあり、しばしば大きなコストに対してほとんどリターンをもたらさない結果になります。こうした状況を回避し防止するために、私たちは定期的に MLE がエージェントの進捗をチェックし、軌道から外れているか立ち止まっていると判断された際に介入することが有効であることを発見しました。また、事前にどのような仮説タイプを探索すべきかを明確にし、広範な潜在仮説空間をカバーする探索計画にエージェントが事前合意することも役立ちます。

文献調査

エージェントは大量の情報を解析する点で極めて優れています。特定のモデリング問題に対する探索計画を立てる際、まず学術論文や業界ブログ、関連するオンラインリソース、さらには内部ドキュメントや実証結果を基盤として理解させた上で、探索すべき仮説セットを検討させるのが効果的です。

エージェントの過小評価

エージェント支援によるモデリングは本質的に確率的なプロセスです。あるエージェントが 50 回の試行を経て「これ以上ない」として敗北を宣言する一方で、同じエージェントでもわずかに異なるプロンプトを与えられれば、最初の 20 回で 5 つの有用な改善点を見出す可能性があります。

残念ながら、この確率的な性質はプロセスに組み込まれた特徴です。これを克服するためには、現在の設定から大きく離れた広範な仮説空間を探索することから始めるのが有効です。また、仮説生成の段階では、より賢く、コストのかかるモデルの力を借りることも検討すべきでしょう。

具体的には、「最も賢いモデル」に大まかな仮説空間を描かせ、その詳細や実行計画は別のモデルに任せるという分担が効果的です。もちろん、これで必ず改善が見つかるわけではありませんが、成功する確率を格段に高めることは間違いありません。

アジェンティック・マテリアル知識の普及。Instacart では、MLE 間でのモデリング知識を効果的に共有するために、詳細なドキュメント、セミナー、ディスカッショングループなど、さまざまなツールと仕組みを整えています。アジェンツを導入した際、私たちは即座に、アジェンティック・モデリングに関する知見を、単一のモデルコンテキスト内だけでなく、異なるコンテキスト間でも伝達するための同等の場が必要だと気づきました。言い換えれば、アジェンツが生成する膨大な数のモデリング洞察を効果的に保存し、検索できる手段が必要です。そこで私たちは、アジェンティック・モデリング作業から得た知見を蓄積する構造化された台帳の構築を徐々に進めています。

アジェンティック・モデリングの探索に取り組むチームは、いくつかの落とし穴に直面しました。これらは明確に指摘しておく価値があります。軽微で対処が容易なものもあれば、検出されずに本番環境へ移行した場合に重大な問題を引き起こす可能性のある深刻なものもあります。

データと評価の正確性

エージェントによるモデリングループは、それを評価するデータの質に依存します。過去の実装では、モデルの品質を評価するために使用された評価データに問題があるケースが複数あり、その結果、エージェントがバイアスのかかった、あるいは完全に無効な成果物に対して最適化を行ってしまう事態が発生しました。

例えばあるプロジェクトでは、ゲートウェイタイムアウトが誤って有効なベースラインとして記録されていました。これが偽の正解（グランドトゥルース）を埋め込み、エージェントは実質的にこの偽のターゲットをモデル化しようとする無駄な探求に走ることになりました。

こうした問題を避けるためには、評価環境において何らかの形式的なチェックや、第一級クラスの失敗処理機構を組み込むことが不可欠です。プロンプト内に厳格なガードレールを設定することも有効ですが、その効果は必ずしも安定したものではありません。

微妙な正確性のバグ

モデリング活動全体を通じて recurring していた問題の一つに、特徴量のリーク（情報漏洩）があります。これは時として非常に巧妙で、エージェントが新しい特徴量を追加する際に、結果変数に関する情報が漏れ出してしまうケースです。

特徴量のリークは特に厄介な問題です。オフライン分析では発見が極めて困難だからです。例えば、ある事例ではエージェントが時点ごとの結合（point-in-time join）でエラーを発生させ、実質的に未来のデータを現在に組み込んでしまいました。別の事例では、エージェントが学習データで使用されているデフォルト値とは異なる「特徴量と場所」の組み合わせをデフォルトとして採用してしまい、文脈によっては同等に深刻なバグとなりました。

これらの問題に対処するには、プロンプト内に厳格なガードレールを設定することや、評価環境に組み込まれた形式的な検証チェックが有効です。

エージェントは時として不正を行うことがあります。少なくとも一つの事例では、あるエージェントがモデルのハイパーパラメータを選択する際に、保持された評価セットの中身を覗き見ていたことが確認されました。明らかに、このような「覗き見」行為は評価セットを設けるという前提そのものを損なうものです。プロンプトでこれを明示的に指摘する以外に、有効な代替手段として、モデル構築を行うエージェントと評価を行うエージェントを厳格に分離し、実質的にクロスエージェント検証のような仕組みを導入することが考えられます。

スケーリングの不整合を避けること。処理速度を高く保ちつつコストを抑えるため、多くのチームでは当初、利用可能なデータの小さなサブセットに対してのみアジェンティックループを実行することを決定しました。このアプローチには本質的なリスクが伴います。つまり、これらの小規模データセットに基づいたエージェントの学習成果は、大規模なデータセットには一般化されない可能性があるという点です。特に尾部性能（tail performance）の確保が求められるモデリング問題においては、エージェントが作業を行うための信頼性の高い評価データを構築する仕組みを慎重に検討することが不可欠です。一つの解決策として、より現実的なトレーニングシナリオに近づいた際に学習成果が持続することを保証するため、定期的に問題規模を拡大していく方法があります。

アジェンティックモデリングにおけるこれらの課題は決して新しいものではありません。