プロダクションAIに専用のプロンプト管理が必要な理由

昔々、スタートアップの時間の流れで言えば約半年前のことですが、急成長中のフィンテック企業にジェイソンという優秀なMLエンジニアがいました。ジェイソンは社内の「AIウィスパラー」でした。プロダクトチームが、新しいLLM搭載チャットボットに、金利についてより共感的に聞こえ、かつ幻覚を起こしにくくする必要があるとき、彼らはジェイソンを呼びました。

ジェイソンのツールキットは膨大でした。最先端のベクトルデータベース、高度に最適化されたKubernetesクラスター、洗練されたCI/CDパイプライン。しかし、何百万ドルもの機能を動かす実際のプロンプトという、運用の要は、不安定なエコシステムの中にありました。

あるプロンプトは、古代の遺物のように条件分岐ロジックの奥深くに埋め込まれたPythonのf文字列にハードコードされていました。また別のプロンプトは、「FINAL_PROMPTS_v3_REAL_FINAL(2).docx」というタイトルの40ページにわたる共有Googleドキュメントに存在し、3人の異なるプロダクトマネージャーによって管理されていました。最新の実験的なプロンプトは、CEOからジェイソンに午後11時30分にSlackで送られてきました。

顧客が、チャットボットがクリンゴン語で住宅ローンを提示してきて混乱したと苦情を言ったとき、ジェイソンはコードのデバッグはしませんでした。ジェイソンは、Slackの履歴とGitコミットを考古学者のように掘り起こして、何が原因だったのかを突き止めようとしました。 どのバージョン の「共感プロンプト」が本番環境で稼働していて、誰が最後に変更したのかを。

ジェイソンはもはやエンジニアリングをしていませんでした。ジェイソンはデジタルの雑用をこなしていました。チームはフェラーリのエンジンを作ったものの、それを緩い紐で操縦しているようなものでした。

プロダクション生成AIに関する厳しい現実

上記の物語の背後にある苦痛は、実際には切実で普遍的なものです。生成AIをハッカソンのプロトタイプから信頼性の高い本番システムへと移行させることは、従来のMLOpsスタックにおける決定的に欠けている部分を明らかにします。

初期段階では、プロンプトをコードとして扱うことは論理的に思えました。Gitでバージョン管理し、アプリケーションと一緒にデプロイする。しかし、チームが拡大するにつれて、このモデルは破綻します。プロンプトは従来のコードではありません。それらは、設定、ビジネスロジック、ユーザーインターフェースがすべて自然言語のパッケージとして一つにまとめられたものです。

プロンプトがコードベースと密接に結合している場合、いくつかの重大な問題が発生します。

1. イテレーション速度が低下する： ドメインエキスパートがトーンを改善するために数語を微調整したいとします。これにJiraチケット、Gitプルリクエスト、完全なCI/CDパイプラインの実行、そしてエンジニアリングの承認が必要であるべきではありません。
2. 可視性の欠如： 次のような単純な質問に答えることがほぼ不可能になります。「現在、本番環境で何が稼働していて、先週とどう違うのか？」
3. 共同作業の障壁： エンジニアがボトルネックになります。プロンプトの作成に最も適した人々（PM、コピーライター、主題専門家）は、プロンプトが存在するコードベースから最も遠い場所にいることがよくあります。

プロトタイプからプロダクションへのギャップを埋めるには、インフラストラクチャ全体に散らばる「魔法の文字列」としてプロンプトを扱うのをやめなければなりません。それらをファーストクラスの市民として扱う必要があります。

管理されていないプロンプトの混乱

構造化されたアプローチを導入する前は、ワークフローは誤解や手作業が絡み合い、複雑な状態になりがちです。

TrueFoundryの登場：GenAIのためのインフラ

ここで、専用のプロンプト管理システムが不可欠となります。これは、プロンプトエンジニアリングという実験的な技術と、本番環境のソフトウェアエンジニアリングという厳格な規律を結びつける架け橋となるものです。

TrueFoundryは、この中央制御システムとして機能します。プロンプト管理をアプリケーションロジックから切り離すように設計されており、チームは従来のコードに適用するのと同じ厳密さでプロンプトの共同作業、バージョン管理、評価、デプロイを行うことができます。ただし、LLMワークフローの特定のニーズに合わせて設計されたインターフェースを備えています。

TrueFoundryは、プロンプト管理を場当たり的なタスクから、構造化され監査可能なインフラストラクチャ層へと変革します。 

1. 単一の信頼できる情報源（レジストリ）

TrueFoundryは一元化されたプロンプトレジストリを提供します。Googleドキュメントやコードベースを探し回る必要はもうありません。あらゆるユースケースのすべてのプロンプトが、安全でアクセスしやすい一箇所に集約されます。

‍

2. プロンプトとコードの分離

これは、開発速度にとって最も重要な変化です。TrueFoundryでは、アプリケーションコードにプロンプトテキストは含まれません。その代わりに、目的のプロンプトのアクティブなバージョンを取得する軽量なSDK呼び出しが含まれています。

これにより、プロダクトマネージャーは、エンジニアがアプリケーションコードに触れたり、再デプロイをトリガーしたりすることなく、プロンプトを繰り返し改善し、TrueFoundryのプレイグラウンド内でテストし、本番環境に「昇格」させることができます。

3. 構造化されたワークフロー

TrueFoundryを使えば、混乱は合理化されたライフサイクルへと変わります。関係者はハブで共同作業し、バージョンは厳密に追跡され、アプリケーションはAPIを介してプロンプトを確実に利用できます。そして、 AIゲートウェイでのレート制限 により、大量の使用状況下でも安定した本番環境の動作を保証します。

4. 管理と統合された評価

プロンプトテキストの管理は、戦いの半分に過ぎません。バージョン2.0がバージョン1.5よりも実際に優れているかどうかをどうやって知るのでしょうか？TrueFoundryは、管理と並行して評価を統合します。プロンプトを本番環境に昇格させる前に、ゴールデンデータセットに対して実行し、精度、トーン、安全性が低下していないことを確認できます。

詳細については、こちらをご覧ください https://www.truefoundry.com/docs/ai-gateway/prompt-management

結論：AIのためのエンジニアリング規律

話を戻すと、ジェイソンはTrueFoundryを導入しました。Googleドキュメントはアーカイブされ、ハードコードされた文字列はSDKコールに置き換えられました。

今では、CEOがチャットボットのトーンを変更したい場合、TrueFoundryにログインし、新しいバージョンを作成し、いくつかの例でテストし、ジェイソンにレビューを依頼します。ジェイソンは正確な差分を確認し、評価セットで実行し、数分でデプロイを承認できます。しかも、Pythonコードを一行も書く必要はありません。

プロダクションAIへの移行には、プロンプトが新しい種類のソフトウェア成果物であることを認識する必要があります。それらには専用のインフラストラクチャが必要です。TrueFoundryは、プロンプトエンジニアリングの技術を、管理可能でスケーラブルなエンジニアリング規律に変えるツールを提供し、生成AIアプリケーションが他のスタックと同様に堅牢であることを保証します。