# 本番接地型ベンチマーク ## 定義 本番接地型ベンチマーク(Production-Grounded Benchmarks)とは、AI エージェントや自動化システムの評価・最適化のために使うベンチマークを合成的に設計するのではなく、**実際の本番システムのテレメトリ(プロファイル・トレース・メトリクス・実際の入力データ)から生成**する設計原則である。合成ベンチマークでは入力分布・実行形状・システム状態が本番と乖離し、エージェントがベンチマーク人工物を最適化してしまう問題に対処するために導入される。 代表的な実装は [[DODO]](Datadog Observability-Driven Optimizer)で、CPU プロファイルと Live Debugger の実関数呼び出しを組み合わせて Go マイクロベンチマークを生成し、類似度 ≥98% を目標指標とする。(Source: [[@2026__Datadog__Production-Grounded Benchmarks for AI Code Optimization]]) ## 問題の本質: 合成ベンチマークとの乖離 合成ベンチマークには以下の 3 種の乖離が生じる: 1. **データ分布の乖離**: 合成入力が本番の統計的特性を反映しない。[[DODO]] の NormalizeTags 事例では入力タグの約 25% が大文字を含むという本番固有の特性が鍵だった。均一な合成入力ではこの特性が失われ、大文字比率依存の高速パスという最適化機会が不可視になる。 2. **実行形状の乖離**: ベンチマークの実行プロファイルが本番の CPU 時間配分と異なり、エージェントが実際のボトルネックでなくベンチマーク人工物を最適化する。 3. **検証ギャップ**: ベンチマーク上の改善が本番でのメリットに繋がらない。 ## 実装パターン 本番接地型ベンチマークを実現する主要な技術的要素: - **CPU プロファイリング**: 本番フレームグラフを類似度スコアのグランドトゥルースとして使用(プロファイル類似度 ≥98% を収束基準とする) - **本番呼び出しキャプチャ**: Live Debugger 等で実際の関数引数・受信オブジェクト状態を取得(合成再構築では複雑な設定オブジェクトを正確に模倣できない) - **ベンチマーク凍結**: 最適化フェーズ中はベンチマークを不変に保ち、メトリクスのゲーミングを防止 - **密なフィードバック**: スカラースコアでなく乖離タプルのリストを提供し、エージェントがボトルネックを特定しやすくする ## 横断的知見 - **本番接地は「訓練-テスト環境一致」原則の評価側への拡張**: [[エージェント型コーディング]] の文脈では、Composer 2 や DeepSWE が「本番と同一環境で訓練する」ことを核心原則とする。[[DODO]] はこれを評価・ベンチマーク生成側にも適用する試みであり、「本番で動くエージェントは本番に近いベンチマークで訓練・評価すべき」という統一的設計思想として位置づけられる。(Source: [[@2026__Datadog__Production-Grounded Benchmarks for AI Code Optimization]]) - **同型設計思想が AIOps ベンチマークにも存在**: AIOps 領域の [[SREGym]]・[[AIOpsLab]] が「ライブ環境での評価」を追求するのと構造的に同型。コーディング最適化と SRE エージェント評価が共通の「本番接地」原則を独立に発見している点は横断的に注目に値する。 - **入力分布の重要性が最適化機会の可視性を決定する**: DODO の NormalizeTags 事例は、ベンチマーク品質が単なる速度測定精度の問題でなく「どの最適化機会が発見可能か」という探索空間の構造を根本的に規定することを実証した。 - **DBA-Bench はデータベースエージェント評価に「稼働ワークロード付き live read-write 環境」という形で本番接地を実装する**: DODO/AIOpsLab/SREGym が「本番プロファイル・本番テレメトリからの生成」または「ライブなクラウド/マイクロサービス環境」として本番接地を実現するのに対し、DBA-Bench は計装済み PostgreSQL に OLTP/OLAP/混合ワークロードを稼働させたまま多ターンで診断・修復・検証させる。合成的な「クリーンな」テストベッドでは、エージェントは因果障害と相関するだけのワークロード活動を区別する必要がなく、本番診断の困難さが失われるとDBA-Bench は明示的に論じる——本番接地型ベンチマークの一般原則(合成環境は探索空間の構造を歪める)が、AIコード最適化・SRE・データベース運用という3つの独立した領域で並行して再発見されていることになる。(Source: [[@2026__arXiv__DBA-Bench - A Production-Fidelity Benchmark for LLM-Based Database Operations Agents]]) - **本番接地は「入力分布の忠実度」と「状態変化の忠実度」の2種を区別すべきことを DBA-Bench が示す**: DODO は入力データ分布の本番忠実度([[DODO]] の NormalizeTags 事例)を主眼とするのに対し、DBA-Bench は「エージェントの行動が環境の状態を変化させ、その変化が次のターンの観測に影響する」という状態変化の忠実度を主眼とする(執筆時点の環境が次ターンに持ち越されない静的タスクとの対比を明示)。前者は「入力がどれだけ本番的か」、後者は「介入の結果がどれだけ本番的にフィードバックされるか」であり、outcome-first・stateful なエージェント評価では後者が独自に重要になる。(Source: [[@2026__arXiv__DBA-Bench - A Production-Fidelity Benchmark for LLM-Based Database Operations Agents]]) - **時系列検索評価にも「本番接地」原則が独立に再発見されている**: [[@2026__KDD__TSRBench : Benchmarking Time-Series Retrieval]] は、UCR アーカイブ由来の公開データセット UCR-R に加え、通信事業者の実インシデントテレメトリから構築した産業データセット CU-RCA を導入する。両者を比較すると、UCR-R では事前学習済み埋め込みが最良の検索性能を示す一方、CU-RCA(本番接地型)では単純な統計的距離が上位ランクで埋め込みを上回るという明確なドメインシフトが観測された。これは DODO/DBA-Bench が示した「合成環境は探索空間の構造を歪める」という一般原則の、時系列検索という新しい領域における独立した再確認である。DODO(入力分布忠実度)・DBA-Bench(状態変化忠実度)に加え、TSRBench は「本番テレメトリで学術ベンチマーク上の手法ランキングそのものが逆転しうる」という第三のパターン(**手法選好の忠実度**)を示す点で新規性がある——合成データで最良とされた手法が本番では最良でないという、評価結果の妥当性そのものへの警鐘。(Source: [[@2026__KDD__TSRBench : Benchmarking Time-Series Retrieval]]) - **LLM4Logサーベイのコーパスメタ分析が、公開ベンチマーク偏重とdeployment証拠の希薄さを定量的に裏づける**: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis - Chapter 7 Cross-Cutting Insights and Future Directions|LLM4Log第7章]]は、収集した162件の論文レコードのうち産業/proprietary文脈への明示的言及が25件、人手/ユーザstudy信号の報告が17件、deployment-styleメトリクスの報告が23件にとどまり、明確なdeployment指向の証拠を示すのはわずか5件であると報告する。同章はHDFS・BGL等少数の公開ベンチマークへの依存が「統制された比較には有用だが、長い因果連鎖・複数ソース混在ストリーム・プライバシー制約・急速なソフトウェアバージョン変化という運用上の現実を部分的にしか反映しない」と明示的に述べる。これは、DODO/DBA-Bench/TSRBenchが個別ドメイン(コード最適化・DB運用・時系列検索)で実証した「合成的・公開ベンチマークは探索空間の構造を歪める」という一般原則を、ログ解析という第4のドメインで、システム設計ではなく**文献全体のメタ分析(162件中5件のみ明確なdeployment証拠)**という形で裏づける点が新規である。個々のベンチマーク設計の忠実度でなく、分野全体としての本番接地の希薄さを定量化した点で、他の3ドメインの知見とは異なる粒度の観察になる。(Source: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis - Chapter 7 Cross-Cutting Insights and Future Directions]], [[@2026__Datadog__Production-Grounded Benchmarks for AI Code Optimization]], [[@2026__arXiv__DBA-Bench - A Production-Fidelity Benchmark for LLM-Based Database Operations Agents]]) - **LLM サービングシステムのベンチマークでは、本番トレースへの接地だけでは「探索空間の構造の歪み」問題を解消できないことが示される**: [[@2025__ACM Computing Surveys__Towards Efficient Generative Large Language Model Serving - Chapter 5 Benchmarks and Connection with Other Surveys|Towards Efficient Generative LLM Serving第5章]]は、既存研究の多くが BurstGPT・Azure といった公開の本番リクエストトレースを用いて動的なリクエスト到着パターンを再現している(=本番接地の一種)にもかかわらず、MLPerf のような包括的で再現可能なベンチマークがこの分野にまだ存在しないと明示的に述べる。理由として、モデル構成・ハードウェア環境・リクエスト負荷という評価設定軸の組み合わせが極めて多く、限られた設定組み合わせでのテストでは信頼できる結論が得られない(ある最適化技術は高負荷/低負荷条件でのみ優位性を発揮し、それ以外の条件ではむしろ性能を損なうことすらある)ことが挙げられている。これは DODO・DBA-Bench・TSRBench が示した「合成環境は探索空間の構造を歪める」という原則の裏返しであり、**本番トレースへの接地(入力分布忠実度)を達成しても、評価設定空間そのものの網羅性(モデル×ハードウェア×負荷の組み合わせ)が担保されなければ、依然として結論の信頼性は損なわれる**という、本番接地型ベンチマークの一般原則に対する追加の限定条件を LLM サービング領域から示している。(Source: [[@2025__ACM Computing Surveys__Towards Efficient Generative Large Language Model Serving - Chapter 5 Benchmarks and Connection with Other Surveys]], [[@2026__Datadog__Production-Grounded Benchmarks for AI Code Optimization]], [[@2026__arXiv__DBA-Bench - A Production-Fidelity Benchmark for LLM-Based Database Operations Agents]]) ## 未解決の問い - 本番接地型ベンチマーク生成の収束保証はあるか。プロファイル類似度 ≥98% という目標に達しないケースのハンドリング方法は？ - Go 以外の言語(Python・JVM 系・Rust)への拡張はどの程度素直にできるか。特に動的型付き言語での実引数キャプチャは複雑さが増す。 - 本番接地型ベンチマークは入力分布を固定するため、分布シフト後の最適化効果を過大評価するリスクがあるか(例: タグ大文字比率が時間とともに変化する場合)。 - LLM コード最適化以外の用途への応用パターンはどのように体系化できるか。DBA-Bench はデータベース運用エージェント評価への適用例を示したが、「入力分布忠実度」型(DODO)と「状態変化忠実度」型(DBA-Bench・AIOpsLab)を統一する評価設計原則は明文化されていない。 ## 関連 - [[DODO]] — 本概念の主要実装(入力分布忠実度型) - [[@2026__arXiv__DBA-Bench - A Production-Fidelity Benchmark for LLM-Based Database Operations Agents]] — データベース運用エージェント評価への適用例(状態変化忠実度型) - [[@2026__KDD__TSRBench : Benchmarking Time-Series Retrieval]] — 時系列検索評価への適用例(手法選好忠実度型。CU-RCA でのドメインシフトが手法ランキングの逆転を示す) - [[エージェント型コーディング]] — LLM コード最適化エージェントの文脈 - [[継続的プロファイリング]] — CPU プロファイルシグナルの源泉 - [[agentic SRE]] — 同型の「本番接地型評価」設計思想を持つ SRE 自動化 - [[データベース O&M]] — DBA-Bench が評価対象とする領域概念 - [[時系列類似度検索]] — TSRBench が扱う検索タスクの概念ページ - [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis - Chapter 7 Cross-Cutting Insights and Future Directions]] — ログ解析文献全体のメタ分析による本番接地希薄さの定量化 - [[@2025__ACM Computing Surveys__Towards Efficient Generative Large Language Model Serving - Chapter 5 Benchmarks and Connection with Other Surveys]] — LLM サービングシステムのベンチマーク欠如を論じ、本番トレース接地だけでは評価設定空間の網羅性を担保できないことを示す ## 出典 - [[@2026__Datadog__Production-Grounded Benchmarks for AI Code Optimization]] - [[@2026__arXiv__DBA-Bench - A Production-Fidelity Benchmark for LLM-Based Database Operations Agents]](データベース運用エージェントの本番忠実度ベンチマーク、稼働ワークロード付き live read-write 環境) - [[@2026__KDD__TSRBench : Benchmarking Time-Series Retrieval]](時系列検索ベンチマーク。産業インシデントデータセット CU-RCA でのドメインシフト実証) - [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis - Chapter 7 Cross-Cutting Insights and Future Directions]](§7.2、162件中5件のみ明確なdeployment証拠という文献全体のメタ分析) - [[@2025__ACM Computing Surveys__Towards Efficient Generative Large Language Model Serving - Chapter 5 Benchmarks and Connection with Other Surveys]](§5 Benchmarks、本番トレース BurstGPT/Azure を使いつつも包括的ベンチマークが不在という指摘)