クイズの説明
Month 2「RAGシステムを構築しよう」の卒業クイズです。RAGアーキテクチャ、ドキュメント処理、検索パイプライン、精度最適化、評価と運用の全領域から出題します。
合格ライン: 80%（10問中8問正解）
問題
Q1. RAGの基本概念（Step 1）
RAGシステムにおいて、LLMが社内固有の最新情報を用いて回答できる理由として最も正確なものはどれですか？
- A. LLMが社内データで再学習（Fine-tuning）されているから
- B. 外部の知識ソースから関連情報を検索し、プロンプトのコンテキストとしてLLMに渡すから
- C. LLMのパラメータに社内情報が自動的に反映されるから
- D. ベクトルDBがLLMの代わりに回答を生成するから
答えを見る
正解: B
RAGの核心は、外部の知識ソース（ベクトルDB等）から関連情報を検索（Retrieve）し、その情報をプロンプトのコンテキストとしてLLMに渡す（Augment）ことで、LLMが最新の社内情報に基づいた回答を生成（Generate）できる仕組みです。Fine-tuning（A）とは異なり、モデルの再学習は不要です。パラメータへの自動反映（C）は行われません。ベクトルDBは検索のみを行い、回答生成はLLMの役割です（D）。
Q2. Embeddingモデルの選定（Step 1）
日本語の社内ナレッジRAGシステムで、コサイン類似度を使った検索を行います。以下のうち、Embeddingモデル選定時に最も重要度が低い基準はどれですか？
- A. 日本語テキストでの検索精度
- B. モデルのパラメータ数（大きいほど良い）
- C. 1リクエストあたりのAPIコスト
- D. 最大入力トークン数（チャンクサイズの上限に影響）
答えを見る
正解: B
Embeddingモデルのパラメータ数が大きいことは、必ずしも日本語の検索精度向上に直結しません。英語に最適化された大規模モデルよりも、多言語対応に優れた中規模モデルの方が日本語での精度が高い場合もあります。日本語での検索精度（A）、コスト（C）、最大トークン数（D: チャンキングとの整合性）はいずれも実用上の重要な選定基準です。MTEBなどのベンチマークスコアも参考にしますが、実際の対象データでの検証が最も重要です。
Q3. チャンキング戦略（Step 2）
FAQ形式のドキュメント（質問と回答のペア）をRAG用にチャンキングする場合、最も適切な手法はどれですか？
- A. 固定長チャンキング（500トークン、オーバーラップ20%）
- B. セマンティックチャンキング（Embeddingの類似度で分割）
- C. Q&Aペア単位でのチャンキング（1ペア = 1チャンク）
- D. ドキュメント全体を1つのチャンクとして格納
答えを見る
正解: C
FAQ形式のドキュメントでは、質問と回答のペアが意味的な最小単位です。これを分割してしまうと、質問と回答の対応関係が失われ、検索精度が低下します。1つのQ&Aペアを1つのチャンクとして格納し、質問文をメタデータとして付加するのが最適です。固定長（A）やセマンティック（B）ではQ&Aペアが途中で分割される可能性があります。ドキュメント全体を1チャンク（D）にすると、関連しないFAQがノイズとして混入し、検索精度が低下します。
Q4. ハイブリッド検索（Step 3）
「チケットINC-2847の対応状況を教えて」というクエリに対して、最も効果的な検索戦略はどれですか？
- A. ベクトル検索のみ（alpha=1.0）で検索する
- B. BM25キーワード検索の重みを高くしたハイブリッド検索（alpha=0.3）で検索する
- C. LLMにクエリを書き換えさせてからベクトル検索する
- D. 全ドキュメントをLLMに渡して回答を生成させる
答えを見る
正解: B
「INC-2847」というチケット番号は固有名詞であり、意味的な類似度よりもキーワードの完全一致で検索するのが効果的です。ベクトル検索は意味的な類似度を捉えますが、チケット番号のような識別子にはマッチしにくいです。BM25の重みを高くした（alpha=0.3はベクトル30%、BM25 70%を意味する）ハイブリッド検索が最適です。ベクトル検索のみ（A）ではチケット番号が見つかりにくく、クエリ書き換え（C）ではチケット番号が変わるリスクがあります。全ドキュメントをLLMに渡す（D）はコスト・速度の面で非現実的です。
Q5. Reranking（Step 4）
Cross-Encoder Rerankingを導入したところ、Precision@5が0.60から0.85に向上しました。しかしレイテンシが1秒追加されています。レイテンシを抑えつつRerankingの効果を維持するための最も適切なアプローチはどれですか？
- A. Rerankingを削除してベクトル検索のみに戻す
- B. Rerankerに渡す入力件数を20件から10件に減らす
- C. Cross-EncoderをColBERTに置き換えてトークンレベルの事前計算を活用する
- D. Rerankingの結果をキャッシュし、同じクエリには再計算しない
答えを見る
正解: B
Rerankerのレイテンシは入力件数に比例します。20件から10件に減らすことで、レイテンシをほぼ半分にできます。ただし、入力件数を減らしすぎるとRerankingの効果が低下するため、バランスの確認が必要です。Rerankingの削除（A）は精度が大幅に低下するため不適切です。ColBERTへの置き換え（C）も有効ですが、入力件数の調整はより簡単で即座に効果が出ます。キャッシュ（D）は同一クエリにのみ有効で、新しいクエリには効果がありません。
Q6. クエリ変換（Step 4）
ユーザーが「なんか最近のデプロイの話」という曖昧なクエリを入力しました。検索精度を最も向上させるクエリ変換手法はどれですか？
- A. Step-back Prompting — クエリをさらに抽象化する
- B. Query Rewriting — LLMでクエリを具体的な検索用語に書き換える
- C. HyDE — 仮の回答を生成してそのEmbeddingで検索する
- D. クエリ変換は不要 — そのまま検索する
答えを見る
正解: B
「なんか最近のデプロイの話」は口語的で曖昧なクエリです。Query Rewritingでは、LLMがこのクエリを「最近のデプロイメント作業に関する技術文書・議事録」のような検索に適した具体的な表現に書き換えます。Step-back（A）はすでに抽象的なクエリをさらに抽象化するため逆効果です。HyDE（C）も有効ですが、曖昧なクエリに基づく仮回答は不正確になる可能性が高いです。そのまま検索（D）では口語表現がドキュメントの表現とマッチしにくいです。
Q7. Self-RAG（Step 4）
Self-RAGのFaithfulness評価で「NOT SUPPORTED」と判定された回答に対する、最も適切な対応はどれですか？
- A. そのまま回答を返し、ユーザーに判断を委ねる
- B. 「該当する情報が見つかりませんでした」と回答する、またはクエリを変換して再検索する
- C. LLMのtemperatureを下げて再生成する
- D. 検索結果のTop-Kを増やして再生成する
答えを見る
正解: B
NOT SUPPORTEDは、回答がコンテキスト（検索結果）に基づいていない、つまりハルシネーションの可能性が高いことを示します。この場合、誤った情報をユーザーに返すよりも「情報が見つかりませんでした」と正直に回答する方が信頼性が高いです。または、クエリを変換して再検索し、より関連性の高いコンテキストを取得して再度生成を試みます。そのまま返す（A）はハルシネーションを容認することになり危険です。temperatureの調整（C）やTop-K増加（D）はコンテキストの内容を変えないため根本的な解決にはなりません。
Q8. RAGAS評価（Step 5）
RAGASの評価で以下の結果が得られました。最も優先的に改善すべき指標はどれですか？
| 指標 | スコア | 目標値 |
|---|---|---|
| Faithfulness | 0.65 | 0.85 |
| Answer Relevance | 0.82 | 0.80 |
| Context Precision | 0.78 | 0.75 |
| Context Recall | 0.80 | 0.80 |
- A. Answer Relevance（0.82）— 最もスコアが高いから
- B. Faithfulness（0.65）— 目標値との乖離が最も大きく、ハルシネーションリスクがあるから
- C. Context Precision（0.78）— 検索精度に直結するから
- D. Context Recall（0.80）— ちょうど目標値に達しているから
答えを見る
正解: B
Faithfulness（0.65）は目標値（0.85）との乖離が0.20と最も大きく、最優先で改善すべきです。Faithfulnessが低いということは、LLMがコンテキストに基づかない回答（ハルシネーション）を頻繁に生成していることを意味し、システムの信頼性に直結します。改善策としては、プロンプトの改善（「コンテキストのみに基づいて回答すること」の強調）、軽量版Self-RAG（忠実性チェック）の導入、検索結果の品質向上（Rerankingの調整）などが有効です。他の指標は目標値を達成または近い状態にあります。
Q9. 運用設計（Step 5）
本番運用中のRAGシステムで、ある朝「検索結果ゼロ件率」が通常の3%から25%に急増しました。最も可能性の高い原因はどれですか？
- A. ユーザーの質問パターンが急に変化した
- B. ベクトルDBのインデックスが破損、またはコレクションが誤って削除された
- C. LLMのAPIが値上げされた
- D. 新しいドキュメントが大量に追加された
答えを見る
正解: B
検索結果ゼロ件率の急激な増加（3%→25%）は、検索基盤自体に問題が発生していることを強く示唆します。ベクトルDBのインデックス破損やコレクションの誤削除が最も可能性が高い原因です。ユーザーの質問パターン変化（A）は通常、急激ではなく漸進的です。API値上げ（C）は検索結果に直接影響しません。新規ドキュメントの大量追加（D）は検索結果が増える方向に作用するため、ゼロ件率の増加には繋がりません。即座にベクトルDBのヘルスチェック、コレクションの状態確認、スナップショットからの復旧を検討すべきです。
Q10. 総合判断問題（All Steps）
あなたはRAGアーキテクトとして、以下の状況に直面しています。最も適切な対応はどれですか？
状況: Phase 1のPoC（Naive RAG + Reranking）が完了し、評価結果は以下の通り。
- Precision@5: 0.72（目標0.60を達成）
- Faithfulness: 0.80（目標0.80をギリギリ達成）
- ユーザー満足度: 75%（目標70%を達成）
- レイテンシ P95: 4.2秒（目標5秒以内を達成）
- しかし、チーム内から「議事録の検索精度が特に低い」「コード検索がほとんど使えない」という声が上がっている
- A. すべての目標値を達成しているので、Phase 2ではなく全社展開に移る
- B. 目標値は達成しているが、特定ドメイン（議事録、コード）の精度課題に対応するため、Phase 2でドメイン別のチャンキング戦略見直し + クエリルーティングを実装する
- C. Faithfulnessが目標ギリギリなので、フルSelf-RAGを即座に実装する
- D. ユーザーの声は主観的なので無視し、RAGAS指標のみで判断する
答えを見る
正解: B
数値目標を達成していることは重要ですが、特定ドメインでの精度課題を無視して全社展開する（A）のはリスクが高いです。議事録とコードの検索精度が低いのは、チャンキング戦略がこれらのドキュメント特性に最適化されていない可能性が高いです。Phase 2では、議事録に適した時間/議題ベースのチャンキング、コードに適した独立チャンク化 + 言語メタデータ付加、さらにクエリルーティングで検索戦略を動的に切り替える設計を実装します。フルSelf-RAG（C）は現時点で過剰な対策であり、ユーザーの声を無視（D）するのは改善の機会を逃します。定量的なメトリクスと定性的なフィードバックの両方を活用して意思決定するのが正しいアプローチです。
結果
合格（8問以上正解）
おめでとうございます。Month 2「RAGシステムを構築しよう」を修了しました。
RAGアーキテクチャの設計、ドキュメント処理パイプライン、検索パイプライン構築、検索精度の最適化、評価と運用設計 — RAGシステムの構築に必要なすべての要素を学び、社内ナレッジRAGシステムの設計書を作成する力を身につけました。
「LLMの基礎、プロンプトエンジニアリング、そしてRAGシステム。生成AIの基盤技術を体系的に理解し、実用的なシステムとして設計できるようになった。次のステップではさらに高度なAI活用に挑戦しよう」 — 田中VPoE
不合格（7問以下正解）
Month 2の内容を復習し、再度チャレンジしましょう。特に不正解だった領域のStepを重点的に復習してください。
| 問題番号 | 対応するStep |
|---|---|
| Q1 | Step 1: RAGの基本概念 |
| Q2 | Step 1: Embeddingモデルの選定 |
| Q3 | Step 2: チャンキング戦略 |
| Q4 | Step 3: ハイブリッド検索 |
| Q5 | Step 4: Reranking手法 |
| Q6 | Step 4: クエリ変換 |
| Q7 | Step 4: Self-RAG |
| Q8 | Step 5: RAGAS評価フレームワーク |
| Q9 | Step 5: RAG運用設計 |
| Q10 | 総合: 全Stepの統合判断 |
推定所要時間: 30分