変更要約: 初版: ドメイン4（運用効率と最適化）の3節を作成
4.2アプリケーションパフォーマンスの最適化
GenAI アプリの応答性を高める手法を学びます。レイテンシ最適化モデル、並列リクエスト、ストリーミング、temperature／top-k／top-p の調整、検索の最適化、Auto Scaling を扱います。
生成は本質的に時間がかかります。体感レイテンシを下げ、スループットを上げ、出力品質をパラメータで整えることで、ユーザー体験を最適化します。
4.2.1性能を上げる手段
- レイテンシ低減：レイテンシ最適化モデル、ストリーミング、予測可能な問い合わせの事前計算、複雑ワークフローの並列リクエスト。
- 出力パラメータ：要件に応じて temperature／top-k／top-p を調整（決定的なら低 temperature、多様性なら高め）。
- 検索の最適化：インデックス最適化・クエリ前処理・カスタムスコアのハイブリッド検索で RAG の取得を高速・高精度化。
- スループット/スケール：トークン処理の最適化、バッチ推論、同時呼び出し管理、GenAI トラフィック向け Auto Scaling。
「体感を上げる＝ストリーミング＋レイテンシ最適化モデル」「決定的な出力＝低 temperature」「多様な出力＝高 temperature/top-p」「予測可能な問い合わせ＝事前計算」「RAG 高速化＝インデックス/クエリ前処理」 は頻出です。
性能最適化は「待たせない・速く返す・要件に合った出力」です。体感レイテンシは ストリーミング（逐次表示）と レイテンシ最適化モデル（時間制約が厳しい用途向け）で下げ、予測可能な問い合わせは事前計算、複雑なワークフローは並列リクエストで短縮します。出力品質は temperature（低＝決定的/事実重視、高＝創造的）・top-k／top-p（候補語のサンプリング範囲）を要件に合わせて設定し、A/B テストで検証します。RAG の遅さはインデックス最適化・クエリ前処理・カスタムスコアのハイブリッド検索で改善。スループットはトークン処理の最適化・バッチ推論・同時呼び出し管理で上げ、容量は GenAI トラフィック特性に合わせた Auto Scaling とプロビジョンドスループット最適化で確保します。API のプロファイリング（プロンプト/補完パターン）でボトルネックを特定し、LLM 推論特有のレイテンシ削減を施します。
| 課題 | 対策 | 補足 |
|---|---|---|
| 体感が遅い | ストリーミング＋レイテンシ最適化モデル | 逐次表示 |
| 出力が不安定/散漫 | temperature/top-p 調整 | 決定的なら低 temperature |
| RAG が遅い | インデックス/クエリ最適化 | ハイブリッド検索 |
| 負荷変動 | Auto Scaling | GenAI トラフィックに調整 |
ひっかけ： 「事実重視の回答の精度を上げるには temperature を上げる」は誤りです。決定的・事実重視は低 temperature。temperature を上げると多様性は増すが幻覚も増えやすい。また「ストリーミングは総処理時間を短縮する」も誤り（総時間でなく体感レイテンシを下げる）。
4.2.2この節のまとめ
- 体感＝ストリーミング＋レイテンシ最適化モデル／出力＝temperature/top-k/top-p 調整
- RAG＝インデックス/クエリ最適化／スケール＝Auto Scaling＋同時実行管理
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 事実ベースで一貫した回答が求められる業務アシスタントで、毎回ぶれない決定的な出力にしたい。パラメータ調整として正しいのは？
Q2. リアルタイム性が重要なチャットで、長い回答の体感レイテンシを下げたい。最適な組み合わせは？
Q3. RAG アプリで検索（取得）部分が遅く全体のレイテンシを押し上げている。検索を高速・高精度化する手段は？