クイズの説明
Step 5「AI運用体制を設計しよう」の理解度を確認します。LLMOps基盤、AI品質モニタリング、インシデント対応について問います。
合格ライン: 80%（5問中4問正解）
問題
Q1. LLMOpsとMLOpsの違い
LLMOpsがMLOpsと比較して特に重視する管理対象はどれですか？
- A. GPUクラスタの管理と分散学習の最適化
- B. 特徴量ストアの設計とデータパイプラインの構築
- C. プロンプトのバージョン管理と出力品質の継続的評価
- D. 教師データのラベリング品質管理
答えを見る
正解: C
LLMOpsは、MLOpsの基盤の上にLLM固有の課題を管理するプラクティスです。最大の特徴は「プロンプト管理」と「出力品質の評価」です。LLMではプロンプトがソースコードに相当し、そのバージョン管理、テスト、レビューが重要になります。また、LLMの出力は確率的であり、従来の精度/再現率だけでなくLLM-as-a-Judge等の手法で品質を継続的に評価する必要があります。GPUクラスタ管理（A）と特徴量ストア（B）は従来のMLOpsの領域、ラベリング品質（D）は教師あり学習に特有の課題です。
Q2. AI品質モニタリングの手法
RAGベースのAIチャットボットの回答品質を自動評価する手法として、最も適切な組み合わせはどれですか？
- A. 応答時間の測定とHTTPステータスコードの監視のみで十分
- B. LLM-as-a-Judgeによる品質スコアリングとRAGソースとの整合性チェックの組み合わせ
- C. BLEUスコアのみで評価し、閾値を下回ったらアラートを出す
- D. ユーザーフィードバックのみに依存し、低評価が多い場合に対応する
答えを見る
正解: B
RAGベースのシステムでは、回答品質の「正確性」と「根拠性」の両方を評価する必要があります。LLM-as-a-Judgeは回答の正確性・関連性・完全性を総合的に評価でき、RAGソースとの整合性チェック（Faithfulness）はハルシネーションの検出に有効です。HTTPステータスコード（A）はシステム障害は検知できますが品質劣化は検知できません。BLEUスコア（C）は翻訳や要約向けの指標であり、自由回答の品質評価には不十分です。ユーザーフィードバックのみ（D）では問題の検知が遅れ、すべてのユーザーがフィードバックするわけではないため不完全です。
Q3. ハルシネーション検出
LLMのハルシネーションを検出するために最も効果的なアプローチはどれですか？
- A. temperatureを0に設定すれば、ハルシネーションは完全に防止できる
- B. 回答の文字数を制限すれば、ハルシネーションの発生を防げる
- C. RAGソースとの照合、エンティティ検証、自己一貫性チェックを組み合わせる
- D. 最新のモデルを使用すれば、ハルシネーションは発生しない
答えを見る
正解: C
ハルシネーションの検出には複数の手法を組み合わせることが効果的です。RAGソースとの照合（Source Grounding）は回答が根拠に基づいているか検証し、エンティティ検証は固有名詞や数値の正確性を確認し、自己一貫性チェックは同じ質問への複数回の回答が一貫しているか確認します。temperatureを0に設定（A）しても確率的な生成は行われるためハルシネーションは完全には防げません。文字数制限（B）は品質を低下させるだけで根本的な解決になりません。最新モデル（D）でもハルシネーションは発生します。
Q4. AIインシデント対応
社内AIチャットボットが就業規則について事実と異なる回答をしていることが判明しました。最も適切な初期対応はどれですか？
- A. 即座にサービスを全面停止し、修正が完了するまで再開しない
- B. 該当カテゴリの回答に注意喚起を表示し、影響範囲を特定しながら修正を進める
- C. 次回のスプリントで修正タスクとして対応する
- D. モデルをより高性能なものに切り替えれば自動的に解決する
答えを見る
正解: B
AIインシデント対応では、影響を最小化しつつサービスの可用性を維持することが重要です。就業規則の誤回答はSEV2レベルであり、全面停止（A）は過剰対応です。まず該当カテゴリに注意喚起を表示して新たな被害を防ぎつつ、影響範囲（誰が誤情報を受け取ったか）を特定し、並行して修正を進めます。次スプリント（C）では対応が遅すぎます。モデル切り替え（D）は根本的な解決にならず、RAGデータやプロンプトの問題はモデルを変えても解決しません。影響ユーザーへの正しい情報の通知も重要な対応です。
Q5. 評価パイプラインの設計
AIシステムのCI/CDパイプラインに評価ステージを組み込む際、最も重要な設計原則はどれですか？
- A. 評価には時間がかかるため、本番デプロイ後に非同期で実行する
- B. プロンプト変更、RAGデータ更新、コード変更のそれぞれに適した評価スイートをデプロイ前に実行し、合格基準を満たさない場合はデプロイをブロックする
- C. 本番環境で実際のユーザーに使ってもらい、フィードバックで品質を判断する
- D. 評価は初回リリース時のみ実施し、以降は変更が小さいためスキップする
答えを見る
正解: B
評価パイプラインの最も重要な設計原則は「デプロイ前のゲート」として機能させることです。プロンプト変更には回帰テストと安全性テスト、RAGデータ更新には検索精度テストと回帰テスト、コード変更にはユニットテストと統合テストと回帰テストなど、変更の種類に応じた評価スイートを実行します。合格基準を満たさない限りデプロイをブロックすることで、品質劣化を本番環境に持ち込むことを防ぎます。デプロイ後の非同期評価（A）では問題が本番に到達してしまいます。本番でのフィードバック依存（C）ではユーザーが被害を受けます。初回のみの評価（D）では継続的な品質保証ができません。
結果
合格（4問以上正解）
Step 5の内容をよく理解しています。LLMOps基盤の設計、AI品質モニタリング、インシデント対応の要点を身につけました。次のStep 6「エンタープライズAI戦略を完成させよう」に進みましょう。
不合格（3問以下正解）
Step 5の内容を復習しましょう。特に以下のポイントを重点的に確認してください：
- LLMOps — MLOpsとの違いはプロンプト管理と出力品質評価にある
- 品質モニタリング — LLM-as-a-Judge、ソース照合、複数手法の組み合わせが重要
- インシデント対応 — 影響最小化とサービス継続のバランス、デプロイ前の評価ゲート
推定所要時間: 15分