アーカイブ / LLM / AI Agent
業務知識から特徴量の計算コードを作るEureka：GPU需要急増の予測に向けて
Eureka
Eurekaの原論文から掲載した図です。細部はクリックして拡大できます。
原論文の図の説明を読む
Figure 1: Comparison of different feature generation paradigms, highlighting their respective features, generation methods, and limitations/advantages.
概要
- 業務知識から特徴量の設計案を作り、Pythonコードで新しい列に変換して評価結果を次の設計に反映する。
- 公開7データセットとGPU使用ログ由来のEGSで評価し、EGSではEureka-gpt4oのROC-AUCが0.699だった。
- 著者らは2025年6～9月の警告165件のうち91％が運用チームに採用されたと報告する。
補足：編集した模式図で仕組みを確認する
VISUAL EXPLAINER
図でつかむ、Eurekaの仕組み
- 01業務説明と列の統計
- 02特徴量の設計案
- 03Pythonコードと新しい列
- 04評価と設計案の更新
原論文の説明をもとにした模式図です。処理の細部は省略しています。
研究の背景
Eurekaは、予測モデルへ渡す特徴量を業務知識から設計し、計算可能なコードにする仕組みである。特徴量とは、元の記録から取り出したり計算したりする予測用の値を指す。GPU需要は急増する場合があり、元の計測値だけでは前兆を捉えにくい。
有効な計算規則を人手で考えるには、業務とデータの両方への理解が要る。著者らは、この負担を減らすため、設計案の作成、コード化、結果を受けた改良を連続した工程にしている。
手法
まず、業務の説明と元データ各列の統計を受け取る。業務知識に基づく正解例で追加学習した言語モデルが、JSONという項目と値を定まった形で記す形式で設計案を出す。別の言語モデルが計算規則とPythonコードを作り、元データに適用して新しい列を得る。
事例では、vCPU対GPU比率が高く、GPU側の変化が小さい状態を組み合わせ、需要急増前の準備段階を示す特徴量を作った。候補は評価用に分けたデータで調べる。予測への有用性と業務上の意味を報酬にして設計案を作るモデルを更新し、採用した列を予測に使う。
新規性
著者らの提案は、特徴量を列の組み合わせとして選ぶだけでなく、生成・実行・評価できるプログラムとして扱う点にある。業務知識に沿った設計案をコードへ変換し、実行結果を調べる。
さらに、予測への有用性と業務上の意味を別々に評価し、その結果で設計案を作るモデルを更新する。候補の生成から評価、改良までを一つの工程につなぐ構成である。
従来手法との違い
比較対象には、列から特徴量を自動生成するDFS、AutoFE、OpenFEと、言語モデルを使うCAAFE、FeatLLMがある。Eurekaは業務知識を学習したモデルで設計案を作り、Pythonコードとして実行・評価する。
表の結果は一様ではない。HeartのROC-AUCはCAAFEが0.941、Eureka-grok2が0.940で、DiabetesでもDFSの0.882に対しEurekaの各構成は0.873～0.886だった。優劣はデータと構成に応じて読む必要がある。
実験結果
著者らは公開7データセットとAlibaba CloudのGPU使用ログに由来するEGSで、計8件の分類課題を評価した。生成した特徴量を元の列に加え、LightGBMとTabPFNのうち良い結果をROC-AUCで報告する。ROC-AUCは、正例を負例より上位に並べる性能の指標である。
表ではEGSのEureka-gpt4oが0.699、比較対象のTabPFNが0.694だった。EGSの構成要素を外す実験では、全構成が69.97％、LLM Feature Factoryを外すと63.84％。著者らは2025年6～9月の警告165件のうち91％が運用チームに採用され、上位顧客の需要充足率が16％改善したと報告する。
応用の可能性
編集上の応用案 · 論文が実証した用途とは区別しています。
編集上の応用案：クラウド運用担当者向けに、顧客と地域ごとのGPU需要急増の警告候補を作る。過去の需要記録、GPU使用ログ、利用可能なvCPUとGPUの計測値を入力し、担当者が警告と根拠となる特徴量を確認して配置計画を判断する。
学習には、対象業務の履歴と月次の需要急増有無を示す正解ラベル、設計案を点検する担当者の業務知識が要る。追加センサーは前提にせず、手元の項目に合わせて設計案とコードを調整する。効果は導入先で確かめる。
応用先の候補からNauhに相談できます。
導入時の検証
導入時の検証案 · 対象データでの再評価が必要です。
導入時の検証案：対象を一つの顧客群と地域に絞り、過去の需要記録、GPU使用ログ、利用できるvCPU・GPU計測値を集める。月次の需要急増有無を正解ラベルにし、担当者の業務知識で設計案を点検する。必要な項目が既存ログにない場合は、収集方法を検討する。
過去期間で特徴量を生成し、その後の期間で予測を評価する。元の列だけを使うモデルと、論文でも比較されたDFSを基準に置く。ROC-AUC、警告件数、担当者の採用率、需要充足率を記録し、導入先で差と運用負担を確かめる。
限界と課題
著者らは、評価の中心がGPU需要予測であり、他の資源や分野への展開を今後の課題としている。人が定めた経験則への依存を減らすため、報酬の学習方法も検討課題に挙げる。
編集上の検証事項として、警告の採用率と実際の需要充足との関係を確かめたい。また、移動に関する33％の改善は本文で「GPUサーバー移動率」、表で「サーバー移動損失率」と指標名が異なる。定義、比較基準、集計期間を確認する必要がある。
出典
元のタイトル・要旨を確認する（英語）
Eureka: Intelligent Feature Engineering for Enterprise AI Cloud Resource Demand Prediction
Effective features are crucial for predictive model performance, but creating them often requires domain expertise, limiting scalability across applications. We define feature engineering as an agentic code generation problem: features are not static data transformations, but executable programs that can be generated, evaluated, and iteratively improved. We present Eureka, an LLM-driven framework with three stages. (1) An Expert Agent, fine-tuned via SFT on domain knowledge, produces structured feature design plans in JSON format. (2) An LLM Feature Factory translates each plan into executable Python code through chain-of-thought reasoning, turning feature hypotheses into runnable programs. (3) A Self-Evolving Alignment Engine uses Reinforcement Learning (GRPO) with dual-channel reward (metric-based utility + semantic alignment) to enhance code quality. By expressing features as programs, the learned generation patterns can transfer across domains. Evaluated on 7 public benchmarks in healthcare, finance, and social domains, Eureka consistently outperforms both traditional AutoFE and LLM-based baselines. We further demonstrate Eureka's effectiveness on cloud GPU resource demand prediction at Alibaba Cloud, where Eureka improves demand fulfillment rate by 16% and lowers computing resource migration rates by 33%.
論文本体の取得範囲に基づく解説。AIが作成した未校閲の記事です。性能の数値は著者の評価条件に依存します。応用例と検証計画は編集上の提案です。解説更新：2026-10-01