【要約】GEPA × dspy.Flex でプロンプトだけでなく手順まで最適化する [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
LLMを用いた高度なシステム開発において、開発者はプロンプトの調整だけでなく、解法の手順設計という困難な課題に直面している。従来の最適化手法では、以下の問題が解決できなかった。
- ・プロンプトのみの最適化に限定されており、推論ステップの構成は人間が設計する必要があった。
- ・複雑なタスクにおいて、最適なエージェントの構成（単発回答か多段構成か等）を特定するコストが高い。
- ・精度向上とLLM呼び出しコスト（レイテンシ・費用）のトレードオフを自動で制御する手段が不足していた。
// Approach
開発者は、dspy.Flexでプログラム構造を保持し、GEPAによってソースコード自体を書き換えるアプローチを採用した。
- ・dspy.Flexを用いて、プログラムのロジックをPythonのソースコード文字列として管理する。
- ・GEPAが失敗事例をReflection LMに解析させ、改善された新しいソースコードを生成する。
- ・Pareto最適化により、特定の解法に偏らず多様な候補プログラムを維持しながら集団を更新する。
- ・評価関数（metric）にLM呼び出し回数への罰則を組み込み、精度とコストを同時に最適化する。
// Result
公開ベンチマークを用いた実験により、手順とプロンプトの同時最適化が劇的な精度向上をもたらすことが示された。
- ・MATH algebraにおいて、gpt-5.4-miniの正解率が6.0%から90.8%へ大幅に改善した。
- ・JEMHopQAでは、事実確認と回答を分離する2段構成のプログラムが自動生成された。
- ・評価関数に罰則を課すことで、精度を維持しつつLM呼び出し回数を抑制する制御が可能となった。
Senior Engineer Insight
> 手順の自動最適化は、エージェント設計のパラダイムシフトになり得る。精度とコストのトレードオフを評価関数で制御できる点は、実運用において極めて強力だ。ただし、Reflection LMのコストと実行時間は、開発サイクルを鈍化させる懸念がある。また、解法が既知のタスクでは探索が停滞するため、適用対象の選定が重要となる。実験的機能ゆえ、本番導入にはバージョン固定などの運用設計が不可欠だ。