DataRobotにおけるオープンソースの10年—予測AIからエージェントのライフサイクルへ

DataRobotは、創業以来、あらゆる段階でオープンソースのツールを公開してきました。直近の取り組みも同様で、エージェントが本番環境で実際に問題を起こす箇所に合わせて作られています。

エージェントを作ること自体は、かつてないほど簡単になっています。フレームワークを選び、モデルとリトリーバーを組み合わせ、いくつかツールを追加すれば、昼までにはデモが動き出します。問題が起きるのは、そのデモの後です。当て推量で選んだ業務フローは、最も精度が高い選択肢でも、最も安い選択肢でもないことが分かってきます。エージェントは不確実な状況の中で判断を下さなければならず、リスクを素早く見極める手立てもありません。そして、複数のチームが使い始めた瞬間、推論コストとレイテンシーの両方がおかしくなっていきます。

これらは、フレームワークの問題ではありません。ライフサイクルの問題であり、業務フローの設計、実行時の不確実な状況下での推論、そして実際の利用者に対して規模を伴って結果を提供する、という3つの異なる段階で表面化します。

これは、まったく新しい領域の話ではありません。DataRobotにおけるオープンソースは、これまで本筋から外れた余談だったことは一度もありません。むしろ、プラットフォームの進化を段階ごとに追いかけてきました。予測AIをオープンな形で教え、次にAutoMLをプログラムで扱えるようチームに委ね、そして今では、エージェントが本番環境に向かうそれぞれの場所に必要な、実際のインフラを世に出しています。

10年にわたって、その過程を見せてきた

この習慣は2014年にさかのぼります。当時、チームはKDD Cupで上位入賞したコードをオープンソースとして公開し、勾配ブースティング、scikit-learn、statsmodelsによる回帰についてのブログチュートリアルも合わせて発表しました。tutorials for data scientistsリポジトリ、そして後に続く一連の生成AIアクセラレーターも、同じ発想から生まれたものです。AIを本当に理解する唯一の方法は、それを自分の手で作ってみることであり、だからこそホワイトペーパーではなく、実際に動くコードを人々に手渡す、という考え方です。これらはすべて、RおよびPythonのSDKの上に成り立っており、それによってトライアルアカウントは、クリックして触るだけのものから、スクリプトを書いて操作できるものへと変わりました。

ここまでのチュートリアルやアクセラレーターが答えていたのは、「これをどう学ぶか」という問いです。次に来るのは、「作られたものをどう信頼するか」という問いであり、その答えがオーケストレーションでした。Pulumiプロバイダーと、それに付随するCLIによって、業務フローをコードとして定義し、別の人のマシン上で同じ結果を得ながら再実行できるようになりました。これにより、AutoMLはブラックボックスから、書き出し可能で監査可能な記録へと変わりました。Blueprint Workshopは、処理手順をプログラムで構築・編集するためのPythonクライアントであり、同じ発想をモデリングの層そのものにまで広げました。前処理、アルゴリズム、後処理を、UI上のノードとしてだけでなく、コードとして扱えるようにしたのです。

オーケストレーションの次に論理的に続いたのが、オーナーシップです。オープンソースのDRUMフレームワークの上に構築されたCustom ModelsとCustom Tasksによって、チームは自前の学習済みモデルや前処理の手順をデプロイメントに持ち込み、モニタリング、ガバナンス、リーダーボードをそのまま利用できるようになりました。Custom Tasksの上に構築されたComposable MLによって、1つの処理手順の中で、プラットフォーム自体のアルゴリズムと、チーム独自の前処理を混在させられるようになり、どちらか一方を選ばなければならない、という制約がなくなりました。

その時代と今とをつなぐ結節点が、Pulumiです。かつて予測パイプラインを記録するために使われていたのと同じ宣言的なパターンが、今ではエージェントのインフラをプロビジョニングしています。CrewAI、LangGraph、LlamaIndex向けのエージェントテンプレートには、既定でPulumiが組み込まれた状態で提供されています。ツールは変わりました。しかし、閉じた環境ではなくコードによる道筋にこだわるという姿勢は、変わっていません。

エージェントのライフサイクルと、それが壊れる場所

ツールの名前を挙げる前に、まず段階に名前を付けておくと分かりやすくなります。エージェントは、予測可能な一連の流れをたどります。まず、情報の取得、推論、応答の方法を定める業務フローを設計します。実行時には、行動するのに十分なだけ、不確実な世界について推論する必要があります。そして、プラットフォームは、サービスレベル目標や予算を崩すことなく、そのエージェントを多数のテナントに提供しなければなりません。それぞれの段階には、難しい問いが1つずつ結び付いています。syftrが設計の問いに答え、Token Poolが提供の問いに答えます。いずれもオープンソースとして公開されており、実行時の推論の段階については、さらに作業が進行中です。

syftr—当て推量の前に、業務フローを設計する

RAGやエージェント型の構築において最初に下すべき判断は、多くのチームが飛ばしてしまう判断でもあります。それは、どの構成を使うかという判断です。どの統合用LLMを使うか、どの埋め込みモデルを使うか、どのリトリーバーを使うか、チャンクサイズをどうするか、リランキングを加えるか、そもそもエージェント型のフローにすべきか。この選択肢の空間は、ユニークな構成の数にして10の23乗を超え、どの選択も精度・レイテンシー・コストのトレードオフを伴います。ほとんどのチームは、一見妥当に見える既定値を選び、それが最適な水準からどれだけ離れているかを知らないままになります。

syftrは、当て推量に頼る代わりに、この選択肢の空間を探索します。多目的ベイズ最適化を用いて、パレート最適なフロー —コストをかけなければ精度を上げられず、精度を犠牲にしなければコストを下げられない、という構成—を見つけ出します。ドメイン特化の早期終了の仕組みによって、明らかに最適でない候補を、評価予算を使い切る前に取り除き、探索にかかる計算量を60〜80%削減します。業界標準のRAGベンチマークにおいて、精度への影響をわずかに抑えながら、コストを最大13分の1にまで削減する業務フローを特定します。

syftrは、判断そのものを代替するものではありません。手作業では扱いきれないほど大きな設計空間を、データに基づいて進むための手段を提供するものです。10種類の独自・オープンソースのLLM、13種類の埋め込みモデル、4種類のプロンプト戦略、3種類のリトリーバー、4種類のテキスト分割方式を横断的に探索し、最終的に本番投入可能なパイプラインのコードを生成します。

pip install git+https://github.com/datarobot/syftr.git

Token Pool—重要なテナントを飢えさせずに、すべてのテナントに提供する

設計が優れており、実行時の推論も鋭いエージェントであっても、どこかで動かす必要があり、たいていは他の誰かのものと同じ場所で動くことになります。マルチテナントの推論は、ここで壁にぶつかります。専用のエンドポイントは、使われていないモデルの上にGPU容量を塩漬けにしてしまいます。レート制限は、すべてのトークンを均等に扱いますが、実際には1つのリクエストが、別のリクエストより桁違いに多くのGPU時間を消費することがあります。どちらの方式も、空いている容量を他に回すことができず、実際の推論トラフィックの特徴であるバーストに耐えられません。よくある結果として、1つのチームのバッチジョブがエンドポイントを飽和させ、全員の本番環境のレイテンシーが急上昇します。

Token Poolは、この問題をAPIゲートウェイの層で解決します。下にある推論のランタイムには一切手を加えません。容量は、マシン数やPod数ではなく、トークンのスループット、KVキャッシュ、並行実行数といった、推論本来の単位で表現します。各テナントは、プール内の取り分に対するエンタイトルメント（利用権）を持ち、サービスクラス（dedicated、guaranteed、elastic、spot、preemptible）が、競合が発生した際の保護の優先順位を決めます。負債ベースの公平性の仕組みによって、一時的にスロットリングされたワークロードには、後で埋め合わせの優先度が与えられるため、どのテナントも飢えることなく、また誰か1人がプールを独占することもありません。vLLMまたはTensorRT-LLMの上に、Kubernetesネイティブな層として動作します。

過負荷テストでは、Token Poolはspotトラフィックを選択的に絞ることで、guaranteedワークロードのP99 Time to First Tokenを1.2秒未満に保ちました。一方、受け入れ制御を行わないベースラインでは、すべてのワークロードで19秒を超える劣化が見られました。従量課金型の経済性やAPIガバナンスを担う立場にとって、これは欠けていたプリミティブです。推論の実際のコストに見合った単位で、容量を表現できるということです。

kubectl apply -f examples/sample-tokenpool.yaml
kubectl apply -f examples/sample-entitlement.yaml

次にすべきこと—ループを閉じる

これらの公開済みのプロジェクトは、現時点では別々のつながりとして動いています。設計時の探索は1回きりで実行されます。実行時の推論は、提供層がどう機能しているかを把握しないまま動きます。提供層は、上流に何もフィードバックすることなく、ポリシーを適用します。先四半期にsyftrが見つけた業務フローが、今月のトラフィックやモデル、価格に対して最適だとは限りません。

次のオープンソースプロジェクトは、本番環境のテレメトリー——提供層から得られる実際のコスト、レイテンシー、品質のシグナル——を、最適化の層へとフィードバックします。これにより、業務フローは、1回きりのオフラインベンチマークではなく、本番環境の実態に照らして再評価されるようになります。まだレビュー段階にあるため名前は付いていませんが、設計・推論・提供に続く、論理的な4つめの段階です。