DSPy: 脆弱なプロンプトエンジニアリングをコンパイル済みのLLMパイプラインで置き換える

財務AIパイプラインについて考えるとき、いつも同じ壁に突き当たります。テストケースでは見事に機能するものを構築できても、ベンダーが請求書の形式を変更したり、新しい取引タイプが現れたりすると、静かに崩壊していくのを目の当たりにするのです。その脆弱性はほとんどの場合、プロンプトにあります。それは誰も触りたがらない、手作業で作成された文字列です。スタンフォード大学のKhattab氏らによって導入され、ICLR 2024で発表されたDSPyは、会計業務の自動化を試みているすべての人にとって注目に値する、LLMパイプライン構築の根本的に異なる方法を提案しています。

論文の概要

DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines (Khattab, Singhvi, Maheshwari et al., ICLR 2024) は、LLMパイプラインの構築をプロンプトエンジニアリングの問題ではなく、プログラミングの問題として再定義しています。核心となる観察は、現代のLLMアプリケーションが通常、ハードコードされたプロンプト文字列の集合（著者が「プロンプトテンプレート」と呼ぶもの）をPythonの制御フローで繋ぎ合わせることで構築されているという点です。モデルが変更されたり、タスクの分布が変化したりするたびに、誰かがそれらの文字列を手作業で書き直さなければなりません。

DSPyはプロンプトテンプレートを、シグネチャ (signatures) と モジュール (modules) という2つの抽象化に置き換えます。シグネチャは、LM呼び出しが何をすべきかを示す型付きの宣言的な仕様であり、question -> answer のように簡潔に、あるいはPythonクラス内の明示的なフィールド説明として記述されます。モジュールは、シグネチャを ChainOfThought、ReAct、ProgramOfThought、MultiChainComparison などの推論戦略でラップします。重要な追加要素は コンパイラ（論文ではテレプロンプターと呼ばれます）です。これは、DSPyプログラム、少量のラベル付きデータセット、および検証メトリクスを受け取り、few-shotのデモンストレーションを自動生成し、それらの中から選択して、そのメトリクスに最適化されたプロンプトを生成します。コンパイラはすべての中間ステップでラベルを必要としません。ラベルなしの入力に対して教師プログラムを実行し、正しい最終出力が得られたトレースをフィルタリングすることで、デモンストレーションをブートストラップできます。

主なアイデア

• シグネチャが意図を実装から分離する。 question, context -> answer と記述するだけで、DSPyは基底となるLM呼び出しをどのように構築し、呼び出し、最適化するかを認識します。開発者がプロンプト文字列を書くことはありません。
• コンパイルはメトリクス主導のブートストラップである。 BootstrapFewShot オプティマイザはトレーニング入力でプログラムを実行し、パイプラインが成功した入出力トレースを収集し、それらをデモンストレーションとして使用します。中間的な推論ステップの人間によるアノテーションは不要です。
• コンパイラが小規模モデルの可能性を引き出す。 GSM8K（数学の文章題）において、バニラのLlama2-13bはゼロショット・プロンプティングで9.4%というスコアでした。リフレクションとアンサンブルモジュールを用いたDSPyコンパイル後、そのスコアは46.9%に達しました。複雑な推論には向かないと多くの人が考えていたT5-Large（7億7000万パラメータ）は、わずか200個のラベル付きサンプルを使用して、HotPotQAで39.3%の正解率（Exact Match）を達成しました。
• エキスパートによるプロンプトは天井ではない。 GSM8Kにおいて、バニラのfew-shotプロンプティングを用いたGPT-3.5は25.2%に達します。エキスパートが作成したChain-of-Thought（思考の連鎖）を用いるとおよそ72–73%になります。DSPyのコンパイル済みリフレクション・アンサンブルパイプラインは、人間が一切プロンプトを書くことなく、これを81.6%まで押し上げました。
• プログラムは構成可能。 DSPyでのマルチホップ検索QAパイプラインは約12行のPythonコードで記述できます。著者らによれば、LangChainで同等のものを作成する場合、1000文字を超える手作りのプロンプト内容を含む50個の文字列が必要になります。
• 3つのコンパイルステージ。 オプティマイザは、候補生成（トレースのブートストラップ）、パラメータ最適化（ハイパーパラメータに対するランダムサーチやOptuna）、および高次最適化（アンサンブル、動的制御フロー）として動作します。

評価できる点、できない点

実証結果は現実的かつ実質的なものです。わずか数個のラベル付きトレーニング例を使用するだけで、Llama2-13bのGSM8Kでの精度を9.4%から46.9%に向上させたことは、単なる漸進的な進歩ではありません。これは、以前はGPT-4を必要としていたタスクに対して、小規模で安価なモデルを実行可能にするほどの差です。また、アーキテクチャも非常にエレガントです。シグネチャは読みやすく、モジュールは構成可能であり、示されたタスクにおいて抽象化が不自然に感じられることはありません。

制限事項も存在しますが、論文では専用のセクションで議論されてはいません。最も重要なのは、コンパイラの性能は設定したメトリクス次第であるという点です。検証メトリクスが不正確であったり、実際のタスクの品質と乖離していたりする場合（これは実務において非常に一般的です）、オプティマイザは、開発者が実際に重視している点では失敗しながらも、メトリクスを最大化する巧妙な方法を見つけ出してしまいます。会計のような構造化されたドメインでは、「仕訳の貸借が一致している」といったメトリクスを定義できますが、貸借が一致していても勘定科目が完全に間違っているというケースは起こり得ます。著者らもこの問題が存在することは認識していますが、それを解決するのは開発者の責任としています。

第2の制限として、コンパイルには依然としてある程度のラベル付きデータが必要です。論文では BootstrapFewShot を使用すれば10個程度の例で十分であり、入力値のみが必要（中間ラベルは不要）であると主張しています。これは最良のケースでは真実ですが、実際には、開始時のプログラムがトレーニング例を一つも解決できない場合、ブートストラップの信頼性は低下します。財務エージェントのパイプラインで、新しいものを構築しているときによくあるように、ベースラインの精度がほぼゼロである場合、コンパイルは空回りする可能性があります。

第3に、より微妙な点ですが、DSPyはプロンプトとデモンストレーションを最適化しますが、プログラム構造 自体は最適化しません。タスクに対して根本的に間違った方法でモジュールを接続してしまった場合、コンパイラは助けてくれません。プログラムの設計は依然として開発者の手に委ねられています。

なぜこれが財務AIにとって重要なのか

プロンプトの脆弱性の問題は、おそらく財務AIエージェントを本番環境にデプロイする際の実務上の最大の障害です。説明文を勘定科目に照合して取引を分類するパイプラインは、加盟店データの形式が変わったり、新しい支出カテゴリが登場したり、勘定科目体系が更新されたりするたびに劣化します。DSPyを使用すれば、タスクを抽象的に定義し（transaction_description, chart_of_accounts -> account_code, confidence）、分布が変化するたびにコンパイラに最適なデモンストレーションを算出させることができます。

特にBeancountについては、3つの連結されたDSPyモジュールとして構成されたパイプラインが想像できます。1つは生の銀行エクスポートから構造化された取引データを抽出し、もう1つは元帳の既存の勘定科目体系から最適な一致を検索し、最後の一つは結果の仕訳が複式簿記の制約に適合しているかを検証します。各モジュールは独自のシグネチャを持ち、プログラム全体は会計上の正しさと形式の準拠の両方をチェックするメトリクスに対してコンパイルされます。ここではメトリクスの品質問題が最も深刻になります。単に貸借が一致しないエントリだけでなく、間違った勘定科目も捉えるメトリクスが必要ですが、それは解決可能なエンジニアリング上の課題です。

より深い意味として、DSPyは作業の焦点を「より良いプロンプトを書くこと」から「より良いメトリクスを書き、小規模なラベル付きデータセットを収集すること」へとシフトさせます。これは、規制、勘定科目構造、取引形式の変化に応じて進化し続ける必要がある本番環境の財務システムにとって、はるかに持続可能なエンジニアリング手法です。

次に読むべきもの

• OPRO: Large Language Models as Optimizers (Yang et al., arXiv:2309.03409) — 反復的なLM生成による洗練を通じてプロンプトの最適化を行うGoogle DeepMindのアプローチ。DSPyのブートストラップ手法に対する有用な対照点です。
• TextGrad: Automatic "Differentiation" via Text (Yuksekgonul et al., arXiv:2406.07496) — 最適化をメトリクス主導のブートストラップではなく、テキストフィードバックを通じたバックプロパゲーションとして枠付けしています。DSPyの手法が苦手とするコーディングや科学的なタスクで強力な結果を示しています。
• DSPy Assertions: Computational Constraints for Self-Refining Language Model Pipelines (Singhvi et al., arXiv:2312.13382) — DSPyプログラムにハードおよびソフトな制約を追加し、出力がドメインルールに違反したときにパイプラインが自己修正できるようにします。会計上の不変条件を強制するのに直接関連します。