DSPyでコンテキストエンジニアリング：本番LLMアプリを構築する

コンテキストエンジニアリングは、洗練された大規模言語モデル（LLM）アプリケーションを開発するための重要な分野として登場しました。本記事では、コンテキストエンジニアリングの基礎概念を深く掘り下げ、そのコアとなるワークフローを説明し、実践的なアプリケーションを解説します。

コンテキストエンジニアリングとは？

単純なプロンプトと本番環境対応のLLMアプリケーションとの間のギャップを埋めるコンテキストエンジニアリングは、与えられたタスクのためにLLMのコンテキストウィンドウ内で情報を効果的に管理し、適合させる技術と科学として定義されます。これは基本的なプロンプトエンジニアリングをはるかに超え、より包括的かつ体系的なアプローチを採用しています。

コンテキストエンジニアリングの主な特徴は以下の通りです。

包括的アプローチ： 単一クエリのプロンプトを超え、複雑な問題を複数の管理可能なサブ問題に分解します。
モジュラーエージェント： これらのサブ問題は、多くの場合、複数のLLM搭載エージェントによって対処され、それぞれがそのタスクに合わせた特定のコンテキストを備えています。エージェントの能力とサイズは、タスクの複雑さに基づいて変化する可能性があります。
動的なコンテキスト： LLMに提供されるコンテキストは、初期入力に限定されません。処理中に生成される中間トークン（推論ステップやツール出力など）も含まれます。
オーケストレーションされたワークフロー： エージェント間の情報フローは、綿密に制御され、オーケストレーションされ、まとまりのあるシステムパイプラインを形成します。
多様な情報源： エージェントは、Retrieval-Augmented Generation (RAG)を介した外部データベース、ツール呼び出し（例：ウェブ検索）、メモリシステム、または少数ショットの例など、さまざまな情報源からコンテキストにアクセスできます。
実用的なインテリジェンス： エージェントは、推論に基づいて明確に定義されたアクションを実行するように設計されており、環境との動的な相互作用を可能にします。
システム評価と可観測性： 本番レベルのシステムでは、トークン使用量、レイテンシ、費用対効果の指標と監視を用いた継続的な評価が必要です。

なぜすべてをLLMに渡さないのか？

現代のLLMはますます大きなコンテキストウィンドウを誇っていますが、単に利用可能なすべての情報を供給することは、しばしば逆効果です。研究によると、過剰または無関係なデータは、「コンテキスト汚染」や「コンテキスト腐敗」といった問題を引き起こし、モデルの理解度を低下させ、幻覚を増加させ、パフォーマンスを損なう可能性があります。これは、単に大きなコンテキスト容量に頼るのではなく、体系的なコンテキストエンジニアリングのアプローチが必要であることを強調しています。

なぜDSPyなのか？

DSPyフレームワークは、モジュラーなLLMアプリケーションを構築するための宣言的なアプローチを提供し、コンテキストエンジニアリングの原則を示す優れたツールとなっています。DSPyは、LLMモジュールの入力と出力の「契約」を、情報フローを決定する基盤となるロジックから明確に分離します。この分離により、開発が簡素化され、堅牢性が向上します。これは、従来の非構造化プロンプト手法に比べて大きな利点です。

LLMが特定の構造（セットアップ、パンチライン、完全なデリバリー）を持ち、コメディアンの声でJSON形式にフォーマットされたジョークを生成する必要があるタスクを考えてみましょう。従来のプロンプト設定では、特定のフィールド（パンチラインなど）を抽出するには手動での後処理が必要であり、LLMが期待されるフォーマットから逸脱すると失敗しやすくなります。このような非構造化プロンプトでは、システムの正確な入力と出力を特定することも困難です。DSPyは、構造化された予測可能な出力を可能にすることで、これらの課題に対処します。

DSPyのSignatureメカニズムにより、開発者はLLMタスクの入力、出力、およびそのデータ型を明示的に定義でき、手動での解析やエラーが発生しやすい文字列操作を必要とせずに、構造化された予測可能な結果を保証します。dspy.Predictのようなモジュールは、入力から出力への変換を処理します。重要な利点は、DSPyに組み込まれた自動スキーマ検証機能です。これはPydanticモデルを使用し、LLMに再度プロンプトを出すことでフォーマットエラーを自動的に修正しようとするため、堅牢性が大幅に向上します。さらに、LLMが最終回答の前に推論ステップを生成するような、思考の連鎖（Chain of Thought）のような高度な技術の実装も簡素化されます。モジュールの種類を切り替えるだけで、LLMは自己生成された推論でコンテキストを埋めるように指示でき、出力品質が向上します。

多段階インタラクションとエージェントワークフロー

Signatures（システム依存性）とModules（制御フロー）を分離するDSPyのアーキテクチャは、多段階エージェントワークフローの作成を簡素化します。このモジュール性は、洗練されたLLMアプリケーションの設計を容易にします。

逐次処理

コンテキストエンジニアリングは、大きな問題を小さなサブ問題に分解することを提唱しています。この原則は逐次処理に適用され、全体的なタスクが複数の専門LLMエージェントに分割されます。たとえば、ジョーク生成では、あるエージェントがクエリからジョークのアイデア（セットアップとパンチライン）を生成する役割を担い、2番目のエージェントがこのアイデアを完全なジョークのデリバリーに拡張します。このモジュラー設計により、各エージェントを適切な能力とリソース（例：アイデア生成にはより小さなモデルを、最終的なジョーク作成にはより強力なモデルを使用）で構成でき、パフォーマンスとコストを最適化できます。

繰り返しによる改善

繰り返しによる改善は、LLMが自身の出力を反省し、改善することを可能にするもう一つの強力なパターンです。これにはフィードバックループが含まれ、「改善」モジュールが批評家として機能し、以前のLLMの出力にフィードバックを提供します。その後、最初のLLMはこのフィードバックを使用して、応答を繰り返し強化します。

条件分岐と多出力システム

制御フローのオーケストレーションは、コンテキストエンジニアリングの中心です。これにより、条件分岐と多出力システムが可能になり、エージェントが複数の応答バリエーションを生成し、最適なものを選択できます。たとえば、システムは複数のジョークのアイデアを並行して生成し、「ジョーク審査」モジュールを使用して最も面白いものを評価して選択し、その後、選択されたアイデアのみを完全なジョークに拡張することができます。

ツール呼び出し

LLMアプリケーションはしばしば外部システムとの対話を必要とします。この機能は「ツール呼び出し」によって提供されます。ツールは、その説明と入力データ型によって定義される任意の関数です。DSPyは、dspy.ReAct（Reasoning and Acting）のようなモジュールを通じてこれを容易にします。このモジュールにより、LLMはユーザーのクエリについて推論し、外部ツール（例：ニュース取得機能）が必要かどうかを判断し、必要な関数呼び出しと引数を生成し、ツールを実行し、その結果を最終的な応答に統合できます。LLMは、十分な情報が収集された後、さらにツールを呼び出すか、プロセスを終了するかを動的に決定します。このメカニズムにより、エージェントは明確に定義されたアクションを実行でき、推論と行動のサイクルを通じて外部リソースと対話できます。

高度なツール利用 — スクラッチパッドとファイルI/O

単純なAPI呼び出しを超えて、コンテキストエンジニアリングにおける高度なツール利用には、LLMがファイルシステムと対話できるようにすることが含まれます。これにより、エージェントはファイルの読み書き、検索、さらにはターミナルコマンドの実行といった複雑な多段階タスクを実行でき、受動的なテキスト生成器からユーザー環境内のアクティブなエージェントへと変身します。

MCPサーバー

MCP（Multi-Capability Platform）サーバーは、LLMに特化したツールを提供するための新たなパラダイムを表しています。クライアント/サーバーアーキテクチャに従い、LLMはMCPサーバーにアクションを要求するクライアントとして機能し、サーバーはタスクを実行して結果を返します。このアプローチは、システムプロンプト形式、リソースアクセス、さらには制限されたデータベース操作の正確な宣言を可能にするため、コンテキストエンジニアリングにとって特に有益であり、アプリケーションの制御とセキュリティを向上させます。

検索拡張生成（RAG）

検索拡張生成（RAG）は、現代のLLM開発における基本的な技術であり、外部の、最新で、文脈的に関連性の高い情報をLLMに注入するように設計されています。RAGパイプラインは2つのフェーズで動作します。前処理フェーズでは、データコーパスが準備され、クエリ可能な形式で保存されます。推論フェーズでは、ユーザーのクエリが関連文書の検索をトリガーし、それらの文書がLLMに提供されて応答が生成されます。これにより、LLMエージェントは多様な情報源から情報にアクセスでき、内部知識を外部データで補完します。

良いRAGのための実践的なヒント

チャンクメタデータ： 効果的なRAGのためには、前処理中に各データチャンクに追加のメタデータ（「このチャンクが答える質問」など）を生成して保存することを検討してください。このメタデータは検索精度を向上させることができます。
クエリの書き換え： ユーザーの生のクエリを直接検索に利用すると、フレーズのバリエーションやコンテキストの不足により非効率になることがあります。クエリの書き換え技術は、クエリを洗練させることでこれに対処します。具体的には、文法を修正したり、会話履歴で文脈化したり、キーワードを追加したりして、コーパスとのマッチングを改善します。仮説文書埋め込み（HYDE）は、LLMがユーザーのクエリに対する仮説的な回答を生成し、その仮説的な回答を検索に利用する特定の形式のクエリ書き換えであり、回答指向のデータベース検索に効果的であることが多いです。
ハイブリッド検索とRRF： セマンティック検索（ベクトル埋め込みと類似度測定を使用）とキーワードベースの検索（BM25など）を組み合わせることで、多くの場合、優れた結果が得られます。このアプローチはハイブリッド検索として知られています。複数の検索戦略が採用されている場合、逆順ランク融合（RRF）は、それらの結果を単一の最適化されたリストに効果的に結合できます。
マルチホップ検索： マルチホップ検索には、最初に取得したドキュメントをLLMに戻して新しい洗練されたクエリを生成し、その後のデータベース検索でより深い情報収集を可能にすることが含まれますが、レイテンシが増加します。
引用： 取得したドキュメントから応答を生成する際、LLMにソースへの引用を含めるよう促すことができます。これにより透明性が向上し、モデルがコンテンツを利用するための計画を最初に立てることができます。
メモリ： 会話型LLMアプリケーションにとって、「メモリ」の管理は非常に重要です。Mem0のようなメモリシステムは、多くの場合、検索とツール呼び出しのメカニズムを組み合わせています。LLMは、新しいデータが観測されたときに情報を動的に保存または変更することを決定でき、その後のインタラクション中にRAGを介して関連するメモリを取得し、その応答に反映させることができます。

ベストプラクティスと本番環境に関する考慮事項

コアとなるコンテキストエンジニアリング技術に加え、LLMアプリケーションを本番環境にデプロイするには、特に評価と可観測性に関して、いくつかのベストプラクティスを遵守する必要があります。

評価を最初に設計する： 評価の設計を優先します。機能開発の前に、成功のための明確な指標を確立します。これにより、アプリケーションの範囲と最適化がガイドされます。理想的には、客観的で検証可能な報酬（例：分類のための検証データセット）を使用します。そうでない場合は、ヒューリスティックな評価関数（例：RAGチャンクの検索数）を定義します。人間のアノテーションも代替手段です。最終手段として、LLMを審査員として機能させ、異なる条件下で生成された応答を比較およびランク付けできます。
ほぼすべての場所で構造化出力を使用する： 自由形式のテキストよりも構造化された出力を一貫して優先します。これにより、システムの信頼性が向上し、デバッグが簡素化され、堅牢な検証および再試行メカニズムが可能になります。
障害に備えて設計する： プロンプトおよびモジュールの設計中に障害シナリオを予測します。堅牢なソフトウェアと同様に、LLMアプリケーションは、エラーを適切に処理し、予期しない状態を最小限に抑えるように構築する必要があります。
すべてを監視する： 包括的な監視が不可欠です。DSPyとMLflowの統合、またはLangfuseやLogfireなどの代替ツールは、個々のプロンプトと応答、トークンの使用量とコスト、モジュールのレイテンシ、成功/失敗率、および時間の経過に伴うモデルのパフォーマンスの追跡を可能にします。

コンテキストエンジニアリングは、基本的なプロンプトエンジニアリングから、洗練されたモジュラーLLMアプリケーションの開発へと著しい進化を遂げました。DSPyのようなフレームワークは、これらのパターンを体系的に適用するために必要なツールと抽象化を提供します。LLMの機能が進化し続けるにつれて、本番環境で大規模言語モデルの力を効果的に活用するために、コンテキストエンジニアリングは不可欠なものとなるでしょう。