LLMアプリケーションエンジニアリングのベストプラクティス

- プロンプトをコードとして扱う：インライン文字列として散在させるのではなく、名前、バージョン、所有者を持つバージョン管理されたファイルに保持する。 - プロンプトを調整する前に、実際のユーザー入力から評価セットを構築し、プロンプトまたはモデルの変更ごとにそれを再実行する。 - JSONスキーマまたはツール呼び出しで構造化出力を要求し、使用前にスキーマライブラリで検証する。 - モデルプロバイダーの周りに薄いゲートウェイまたはラッパーを配置し、モデルの切り替えやフォールバックの追加を設定変更で行えるようにする。 - 本番環境では正確なモデルバージョンを固定し、評価が合格した後に意図的にアップグレードする。 - 出力が1文か2文より長い場合は、常にユーザーにストリーミング応答する。 - 複雑なRAGパイプラインに手を出す前に、単純なハイブリッド検索（キーワードと埋め込み）から始め、再ランキングを追加する。 - ドキュメントを自然な構造（見出し、セクション）に沿ってチャンク化し、ソースメタデータを保持して、回答が引用できるようにする。 - コンテキストを小さく関連性のあるものに保つ；取得したテキストが多いほど、回答が悪化することがよくある。 - エージェントには、何でもできる1つのツールではなく、厳密な入力スキーマを持つ狭くて明確に記述されたツールの短いリストを与える。 - エージェントループにハード制限を設ける：最大ステップ数、最大トークン数、およびウォールクロックタイムアウト。 - アプリ外のデータを送信、削除、支払い、または変更するツール呼び出しの前に、人間の確認を要求する。 - 取得したすべてのドキュメント、ウェブページ、ツール結果を、プロンプトインジェクションを含む可能性のある信頼できない入力として扱う。 - プロンプトバージョン、モデル、レイテンシ、トークン数、コストを含むすべてのモデル呼び出しをログに記録し、ユーザーデータは編集する。 - 決定論的な呼び出しをキャッシュし、長く安定したシステムプロンプトにはプロンプトキャッシュを使用する。 - 評価に合格する最小のモデルを使用し、難しいケースのみを高価なモデルにルーティングする。 - レート制限や一時的なエラーには、指数バックオフとジッターで再試行し、検証失敗でタイトループを組まない。 - 抽出と分類では温度を低く保ち、クリエイティブ生成でのみ高くする。 - 回答の出所をユーザーに示し、悪い応答を報告しやすくする。 - サムズアップとサムズダウンのフィードバックを収集し、悪いケースを評価セットにフィードバックする。 - プロンプティング、検索、評価が明らかに限界に達するまで、ファインチューニングを行わない。