これは継続中のシリーズの一部です。最初の投稿はこちらをご覧ください。
AI 原則 II: プロンプトを安全に読み込む (本当に必要な場合)
チャットボットがテクニカル サポートを提供する代わりに、テイラー スウィフトの歌詞について議論し始めることを望みますか? 上記の原則に違反したとき、私たちのチャットボットはまさにそのようにしました。アプリケーションを Swift から脱却し、AI アーキテクチャをより安全にしたい場合は、読み進めてください。(テイラー ファンの皆さん、ごめんなさい!)
プロンプトを保存する場所
プロンプトをコードの残りの部分と一緒に保存しますか? それとも別のソースから読み込みますか? あるいは、両方の組み合わせでしょうか? 以下は、この決定について考えるためのフレームワークです。
オプション A - プロンプトを Git に保存する
最初に尋ねるべき質問は、「プロンプトをコードとは別に保存する直接的な理由があるか」です。ない場合は、プロンプトをコードベースの残りの部分とともに Git に残し、本来あるべき場所にします。これは、維持するのがはるかに簡単で安全な設定です。これがデフォルトのオプションです。
原則 1 に戻ります:プロンプトはコードです。コードベースの一部を Git の外部に保存することは可能であり、必要な場合もありますが、簡単ではありません。プロンプトを移動するという決定は軽々しく行わないでください。
オプション B - バージョン管理されたプラットフォームからプロンプトを読み込む
プロンプトの一部をエンジニア以外の人が編集する必要がある場合はどうでしょうか? これは、特定の領域で深い専門知識が必要な場合に発生する可能性があります。または、プロンプトを非常に頻繁に変更する必要があり、エンジニアリング部門を待つことができない場合です。
この場合、実行時にバージョン管理されたソースからプロンプトを読み込む必要があります。この目的で Confluence と Google Docs がうまく使用されているのを見たことがあります。バージョン管理された API アクセス可能なプラットフォームは他にも多数あります。
プロンプト読み込みロジックを計画する際は、この統合を追加するのにかかる労力を過小評価しないでください。アプリケーションに自信を持つためには、さまざまなエラー条件とシナリオを処理する必要があります。アクセス権限を設定して維持する必要があり、自動テストと追加の監視を拡張して、できるだけ早くエラーを検出する必要があります。
計画する必要があるシナリオをいくつか示します。
- アプリケーションは実行時にプロンプトを読み込むことができません。デプロイメントを強制終了しますか? プロンプトのバックアップ バージョンに切り替えますか?
- 変更後にプロンプト構文が無効になり、使用できないデータ構造が返されます。テスト実行中にプロンプトが読み込まれなかったため、自動テストでは問題を検出できませんでした。これを検出し、顧客への影響を最小限に抑えるには、どのような追加のテスト インフラストラクチャと監視を追加する必要がありますか?
- プロンプトを緊急にロールバックする必要があります。これには新しいコードの展開が必要ですか? または、プロンプトの展開用に別の UI を構築しますか?
- Confluence などのプラットフォームによってドキュメントに追加された構文がランタイム プロンプトに侵入し、パフォーマンスに悪影響を及ぼす可能性があります。Beautiful Soup などのツールを使用して、不明瞭な部分を必ず除去してください。
これらの問題はすべて 100% 解決可能です。しかし、Google ドキュメントからプロンプトを読み込むことは、アプリケーション アーキテクチャに深刻な影響を与えない些細な操作であると考える傾向に陥りがちです。上で示したように、外部プロンプトを読み込むことは、高信頼性アプリケーションにとって慎重に取り組むべき重要な作業です。
オプション C - バージョン管理されていないプラットフォームからプロンプトを読み込む
これは悪い考えであり、後悔することになります。プロンプトの信頼できる情報源はバージョン管理され、適切な API とアクセス制御を備えている必要があります。これは手抜きできる領域ではありません。
オプション D - ハイブリッドアプローチ
ハイブリッド アプローチでは、一部のプロンプトをコードベース内に直接保存し、他のプロンプトを外部のバージョン管理されたソースから読み込みます。すべてのプロンプトを 1 か所にまとめて保存する方が簡単で信頼性が高い場合が多いですが、ハイブリッド戦略がメリットをもたらすシナリオもあります。
次のような状況では、ハイブリッド アプローチの採用を検討してください。
- 混合使用法: 特定のプロンプトは、コーディングを担当しないドメイン エキスパートによる頻繁な更新が必要なため、外部読み込みが実用的になりますが、他のプロンプトはエンジニアによってのみ変更されます。
- リスク管理: 信頼性を最大限に高めるには、重要なプロンプト (ガードレールなど) をメイン リポジトリに配置する必要があります。それほど重要でないプロンプト、特に頻繁に調整されるプロンプトは、外部に安全に配置できます。
- 評価の柔軟性: ML スタイルの評価を目的としたプロンプトは、評価フレームワークとの統合を簡素化するために外部で管理できます。
ガードレールプロンプト
ガードレール プロンプト (検閲プロンプトとも呼ばれる) は、応答がユーザーに届く前にスクリーニングを行い、適切で安全かつ準拠した出力を確保することに特化しています。ガードレールは、特にユーザー インタラクションによって重大な法的または倫理的リスクが生じるアプリケーションで保護メカニズムとして機能します。ガードレールは、第 2 の防御線となり、不適切な出力を捕捉します。
ガードレール プロンプトを外部ドキュメントから読み込まないでください。これにより、重大な不要なリスクが発生します。コードとともに Git に保存するか、 Fiddle Guardrailsなどの専用のサードパーティ ツールを使用します。ガードレールのロジックは頻繁に変更されないため、このアプローチではそれほど速度が低下することはありません。
ガードレールの使用は独自の原則であり、今後の投稿でさらに詳しく説明します。これはアプリケーションの安全性を向上させ、安心して眠れるようになる優れたパターンです。ただし、Google ドキュメントからロードしないでください。
評価を容易にするための読み込みプロンプト
チームは、プロンプトを外部から読み込み、 ML Flowなどの評価エンジンと統合することがよくあります。この方法の背後にある基本的な前提は、プロンプトは ML モデルに似ており、独立した統計的評価が必要であるということです。プロンプトをプラグインし、出力の F1 スコア (または任意のメトリック) を測定して、反復します。
このアプローチは、たとえば ML モデルとして動作するように設計された分類プロンプトでは有効な場合があります。ただし、ほとんどのプロンプトは根本的に異なります。これは、「原則 1: LLM プロンプトはコードです」で概説されています。一般的なプロンプトは、ML モデルよりもアプリケーション ロジックに似ています。統計的な評価アプローチではなく、周囲のコードと一緒に合否タイプの評価を行うのに適しています。
外部評価エンジンは、ほとんどのプロンプトには役立ちません。代わりに、従来の単体テストに似た、自動化された AI 駆動型テストを使用する必要があります。これらについては、以降の投稿で重点的に取り上げます。
次の方法を検討してください。
- 機能が機械学習モデルを明示的に模倣するプロンプト（分類やスコアリングタスクなど）のみを外部で評価する必要があります。
- ML 検証手法ではなく、ユニット テストに似た従来の自動テスト アプローチを採用して、ビジネス ロジック プロンプトの大部分をメイン コードベース内に維持します。
- 外部評価が正当化される場合は、可能であれば、それらのプロンプトのみを分離します。
ケーススタディ
読み込みプロンプトに関する中心的な問題は可用性です。つまり、期待どおりにプロンプトが読み込まれない場合はどうすればよいでしょうか。
テイラー スウィフトの例で起こったことはこれです。Confluence の資格情報の問題が原因で、ガードレール プロンプトを含むテクニカル サポート アプリのプロンプトがまったく読み込まれませんでした。どういうわけか、これによってランタイム エラーは発生せず、ボットは指示や入力なしで応答し始めました (入力書式設定文字列がプロンプトの一部であったため)。では、入力がない場合、OpenAI の LLM は何と対話したいのでしょうか。それは、Queen の「I Want to Break Free」の歌詞と、テイラー スウィフトのさまざまな曲でした。幸い、この問題はすぐに検出され、修正され、ユーザーは音楽の議論を楽しみました。少なくとも、私はそう思っています。
なぜこのような事件が起きたのでしょうか? 2 つのミスがありました。
- プロンプトが正常に読み込まれたかどうかのチェックは実行されませんでした。プロンプトが読み込まれないとアプリは機能しないため、プロンプトの読み込み時にエラーがスローされるはずでした。
- ガードレール プロンプトは、他のプロンプトとともに外部に読み込まれました。これは、このように読み込まれるべきではないプロンプトの 1 つです。最後の防御線として Git に保持しておくべきでした。
インシデント後、ガードレール プロンプトは Git に再移行され、プロンプトの読み込みに失敗した場合や無効な場合にデプロイメントを防止するための例外ロジックが追加されました。これらの推奨事項に積極的に従うことで、事後検証を回避できます。
結論
この記事では、AI アプリケーション内でのプロンプトの保存と読み込みに関する重要な考慮事項について説明しました。デフォルトでは、プロンプトはコードと一緒にバージョン管理されたリポジトリに保存されます。エンジニア以外の人が頻繁に編集したり、特定の評価要件がある場合など、やむを得ない理由がある場合にのみ、この方法から逸脱してください。
プロンプトを外部から読み込む必要がある場合は、信頼性が高く、厳密にバージョン管理されたソースを選択し、復元力のためにテストと監視を追加します。ガードレール プロンプトは、アプリケーションの安全性において重要な役割を果たすため、重大な信頼性リスクを回避するためにコードベースに残しておく必要があります。
ほとんどのプロンプトは、本質的には ML モデルよりもコードに近いため、必要な場合にのみ ML スタイルのツールを使用してください。一部のプロンプトの評価ツールとの統合を簡素化するためだけに、すべてのプロンプトを外部に保存しないでください。
この投稿が気に入ったら、シリーズをフォローしてさらに詳しい情報を入手してください。
