> [!abstract] 概要 > DODO(Datadog Observability-Driven Optimizer)は、LLM 駆動のコード最適化エージェントを本番テレメトリで接地するシステムである。CPU プロファイリングデータと実際の関数呼び出し(引数・受信オブジェクト状態)を組み合わせて本番実行パターンを忠実に再現するマイクロベンチマークを生成し、そのベンチマークを凍結した上で最適化エージェントが変更を提案・検証する。成熟した Datadog サービスに適用してサービス CPU コストを 8% 以上削減、手作業では O(週)かかる成果を自動化した。 ## 論文情報 - **タイトル**: Production-Grounded Benchmarks for AI Code Optimization - **著者・所属**: Junaid Ahmed、Piotr Bejda([[Datadog]]) - **発表媒体**: Datadog AI Research ブログ - **公開日**: 2026-06-08 - **URL**: https://www.datadoghq.com/blog/ai/production-grounded-code-optimization/ - **arXiv ID**: なし(ブログ記事) - **コード**: 非公開(内部システム) - **謝辞**: Andrew Werner、Andrei Matei(Debugger・Profiling・Metrics Intake チーム) ## 概要 DODO は合成ベンチマークと本番ワークロードの乖離問題を解消するため、Datadog Continuous Profiler の CPU プロファイルと Live Debugger の実関数呼び出しを組み合わせてマイクロベンチマークを生成する 2 ループシステムである。ベンチマーク生成ループでベンチマークを凍結し、最適化ループで LLM エージェントがコード変更を繰り返し提案・検証する。 ## 問題設定 - **入力**: 対象 Go サービスの CPU フレームグラフ + Live Debugger で取得した実関数引数・受信オブジェクト状態 - **出力**: 本番プロファイルと ≥98% の類似度を持つマイクロベンチマーク + 最適化パッチ - **前提**: ハードウェアパリティ(ベンチマーク実行環境と本番プロファイル収集環境が同 CPU アーキテクチャ) - **核心的課題**: 合成ベンチマークでは入力分布・実行形状・状態が本番と乖離し、エージェントが実際のボトルネックでなくベンチマーク人工物を最適化してしまう ## 提案手法 ### アーキテクチャ DODO は逐次動作する 2 ループで構成される: **ループ 1: 本番接地型ベンチマーク生成** ベンチマーク生成エージェントが以下の 2 シグナルを入力に反復的に Go マイクロベンチマークを構築する: - **CPU プロファイル**: Datadog Continuous Profiler の集約フレームグラフ。CPU 時間 1% 未満のサブツリーを刈り込み、グランドトゥルースとして使用 - **本番呼び出し**: Live Debugger が本番インスタンスから実際の関数呼び出し(引数・受信オブジェクト内部状態を含む)をキャプチャ 評価ツールが候補ベンチマークをコンパイルして CPU プロファイルを計測し、乖離をラベル付きタプル `(call_path, prod%, bench%, gap)` の降順リストとして返す。目標は類似度 ≥98%。 **類似度スコアの正規化処理**: 1. アーキテクチャ固有の関数名をカノニカル形式にエイリアス化 2. Go ランタイム内部フレームをトップフレームに折り畳み **状態キャプチャの重要性**: 受信オブジェクトの状態(ルールセット・事前投入キャッシュ・ルックアップテーブル等)を本番呼び出しから直接取得する。合成的な再構築では複雑な設定オブジェクトの内部状態を正確に模倣できない。 **ループ 2: 凍結ベンチマークに対するコード最適化** ベンチマーク確定後、最適化エージェントが反復的にコード変更を提案・検証する: - ツール構成: コード読み取り、コード編集、`run_tests`、`run_benchmark` - ユニットテストを 3 回実行して既存のフレーク(不安定テスト)を指紋化し、最適化による偽陰性を排除 - ベンチマーク実行前にベースライン `ns/op` を確定 - 各 `run_benchmark` 呼び出しが `ns/op` のベースライン比較と番号付きパッチスナップショットを返す(最良値を保持) **設計上の核心原則**: - 最適化フェーズ中ベンチマークを不変(immutable)にする → メトリクスのゲーミングを防止 - スカラースコアではなく密なフィードバック(乖離リスト)を提供 → エージェントがボトルネックを特定しやすくなる ## 新規性 既存の LLM コード最適化研究は HumanEval や合成ベンチマークで評価するが、本番ワークロードの入力分布・実行形状・オブジェクト状態と乖離するため実世界の改善に繋がらない。DODO の新規性は: 1. CPU プロファイル類似度を定量的フィードバックとして最適化ループに組み込む最初の実装(既知) 2. Live Debugger によるオブジェクト状態の直接キャプチャでベンチマーク忠実度を高める 3. 2 ループ構造でベンチマーク生成と最適化を分離し、メトリクスのゲーミングを構造的に防止 ## 実験設定 - **対象**: 成熟した Datadog 内部 Go サービス(すでに人手で十分最適化済み) - **シグナル取得元**: 本番ライクな内部インスタンス(顧客向けシステムではない) - **評価指標**: ns/op の改善率(ベースライン比)、サービス全体の CPU コスト削減率 - **ハードウェアパリティ**: ベンチマーク実行を本番プロファイル収集と同一 CPU アーキテクチャで実施 ## 実験結果 成熟した内部 Go サービスに適用した結果: | 対象関数 | CPU 占有率 | 高速化率 | 最適化内容 | |---|---|---|---| | `intern` | 9.8% | 40% | ホストごとにホストタグ ID をキャッシュ | | `MergeTags` | 11.5% | 4% | 半分ずつ独立ソート後マージ+重複除去 | | `NormalizeTags` | 7.5% | 22% | 大文字比率に依存した高速 ASCII 折り畳み | | `HandleFromSortedTags` | 3.7% | 15% | バッファへの直接書き込み、append 回避 | | `ComputeTagsHash` | 3.2% | 27% | ハッシュバッファをスタックに割り当て | | `FilterPayloads` | 2.7% | 75% | マップによるリテラルフィルタの O(1) ルックアップ | | `writeTagsetsMut` | 2.0% | 76% | 有界 ID のビットセットソート | | `filterTags` | 1.1% | 82% | ビットマスク棄却・インプレースフィルタ | **総合効果**: サービス全体の CPU コストを 8% 以上削減、O(10k) コアを常時節約。 **NormalizeTags の代表例**: 本番テレメトリにより入力タグの約 25% が大文字を含む(タイムスタンプの 'T'、バージョン文字列の 'RC' 等)ことが判明し、この分布をベンチマークに保存した。エージェントはこの比率に有効性が依存する高速 ASCII 大小文字折り畳みパスを発見した。合成ベンチマークではこの最適化機会は不可視となる。 **工数比較**: 同規模の手作業最適化は代表的トラフィックパターン再現の困難さから「O(週)以上」かかると著者は述べている。 ## 考察 - **本番接地の本質的価値**: NormalizeTags の事例は、ベンチマークの入力分布が最適化機会の可視性を直接決定することを実証する。合成的な均一入力では 25% 大文字比率という特性が失われ、最適化が「正しくない」方向に進む可能性がある。 - **成熟サービスへの適用可能性**: 人手で十分最適化済みのサービスでも 8% CPU 削減を達成した点は、AI 駆動最適化が経験豊富なエンジニアでも見過ごすボトルネックを発見できることを示す。 - **設計の汎用性**: Go に特化した実装だが、CPU プロファイル + Live Debugger のパターン自体は言語非依存であり、他言語サービスへの拡張可能性がある。 ## 強み・弱点・課題 **強み**: - 本番データを直接利用することで、合成ベンチマーク固有のバイアスを構造的に排除 - ベンチマーク凍結により最適化のゲーミングを防止 - 実際に本番デプロイして O(10k) コア削減という具体的成果を示した - 状態キャプチャが合成再構築では困難な複雑オブジェクトに対処 **弱点・課題**: - 現時点は Go 言語のみ(他言語対応は将来課題) - データ収集元が Datadog 内部インスタンスであり外部再現が不可能 - 詳細な評価方法論(DODO の反復回数・タイムアウト・エージェントモデル等)の記載なし - ベンチマーク生成の収束失敗事例や限界条件の報告がない ## 関連 - [[DODO]] — 本ブログが紹介するシステム - [[Junaid Ahmed]] / [[Piotr Bejda]] — 著者 - [[Datadog]] — 所属組織・Continuous Profiler/Live Debugger の提供元 - [[エージェント型コーディング]] — LLM エージェントによるコード最適化の文脈 - [[継続的プロファイリング]] — ベンチマーク生成の CPU シグナル源 - [[本番接地型ベンチマーク]] — 本稿が体現する設計原則 ## 出典 - ブログ記事: https://www.datadoghq.com/blog/ai/production-grounded-code-optimization/ (2026-06-08) - 原本: [[.raw/articles/dodo-production-grounded-code-optimization-2026-06-08.md]]