プロンプト最適化

FaissベクトルDB

中心にあるのは、ベクトル集合を保持して検索する索引です。索引構造が何十種類も存在するのは、トレードオフが実在するからです。検索時間、結果の質、1ベクトルあたりのメモリ、構築にかかる時間、そして学習用データが必要かどうかが互いに競合します。一部の方式は圧縮表現だけを保持し元のベクトルを持たないため、1台のサーバーで数十億件規模に届きます。サーバー機能、絞り込み、アクセス制御はここにはありません。それらは、この上に築かれたデータベースが足している部分です。

DSPyプロンプト最適化

各ステップが何をすべきかを宣言し、評価指標を与えると、オプティマイザがそれを最大化するプロンプトと少数事例を探索します。パイプラインの改善が、経験則ではなく計測可能な作業になるのが利点です。評価用データセットが前提であり、それがなければ最適化の対象自体が存在しません。

Opik可観測性

関数にデコレータを付けるか、クライアントを包むだけでトレースの記録が始まります。同じデータがそのまま実験機能に流れ、幻覚・回答の関連性・文脈の再現率といった指標で、手作業ではなく自動的に応答を採点します。30を超える連携が主要なフレームワークとプロバイダを覆い、ホスト型サービスとしてだけでなく、ローカルやKubernetes上でも全体を動かせます。難点は機能ではなく重複です。本カタログに既に載る2つのプラットフォームと真正面から競合するため、選択の分かれ目は不足している機能ではなく、連携先と運用形態になります。

Agent Lightningプロンプト最適化

エージェントに強化学習を使うという話でいつも問題になるのは、学習環境として作り直すことになり、その時点で本番のものを改善しているとは言えなくなる点です。Agent Lightningは、モデルの窓口があった場所に中継役を置くことでこれを避けます。エージェントは自分のツール、プロンプト、制御の流れ、環境をそのまま保ち、中継役を通るやり取りがそのまま学習データになります。学習側が方策を更新し、制御役がエージェントを手元またはKubernetesのジョブとして動かします。Microsoftは、90億パラメータのモデルを6,000件の学習データでSWE-bench Verifiedの41.8%から56.4%へ引き上げたと報告し、その一連の手順を公開しています。これはアプリケーションに足すライブラリではなく、学習基盤を伴うGPUの作業です。

GEPAプロンプト最適化

強化学習は実行全体を1つの数値へ圧縮するため、何が悪かったかを示す部分を捨ててしまいます。GEPAはそれを保持します。エラーメッセージ、実行の記録、推論のログをモデルへ戻し、失敗の原因を診断させて具体的な修正案を出させます。さらに、1つの勝者へ収束させず、それぞれ異なる事例で強い候補プロンプトの集合を保ちます。プロジェクトは、強化学習が1万回超を要する場面で100〜500回の評価で結果に達すると述べています。実行も反省もモデル呼び出しであるため、この効率は強化学習との比較であって、費用ゼロという意味ではありません。