WEB問題集
正解：B
正解の根拠
プロンプトチェイニング (Prompt Chaining) は、複雑なタスクを小さなサブタスクに分割し、各ステップの LLM 出力を次のプロンプトの入力として連鎖させる手法です。タスクを段階的に解決することで、長いコンテキストや複雑な推論を必要とする処理を扱いやすくなります。Bedrock や SageMaker JumpStart の LLM で実装でき、Bedrock Flow や Step Functions と組み合わせるとオーケストレーションも可能です。
主要プロンプト技法の比較
| 技法 | 特徴 |
|---|---|
| Prompt Chaining | タスクを連鎖的に分割実行 |
| One-shot | 1 つの例を提示 |
| Tree of Thoughts | 分岐を探索する推論手法 |
| RAG | 外部知識を検索して回答 |
不正解の理由
- A: One-shot Prompting は単一の例示を含めて 1 回の推論で完結する手法で、タスクを連続的に分割する仕組みではありません。
- C: Tree of Thoughts は推論の分岐を探索する別の高度技法であり、サブタスクへの逐次的分割を主目的とするものではありません。
- D: RAG はベクトル検索で外部知識を取得し回答に含める手法で、タスク分割とは設計目的が異なります。
正解：A
正解の根拠
特定のデモグラフィックグループへのバイアスが見られる場合、根本原因の多くは訓練データの代表性不足です。より多様で偏りの少ないデータでファインチューニングをやり直すことで、コスト効率良くバイアスを是正できます。プリトレーニング全体のやり直しは膨大なコストがかかるため、ファインチューニングの再実施が現実的かつ最適な選択です。
バイアス対策の比較
| 手法 | コスト/効果 |
|---|---|
| 多様データでファインチューニング | 低コスト・高効果 |
| プリトレーニングやり直し | 超高コスト |
| RAG 追加 | 知識補完用、バイアスは未解決 |
| Trusted Advisor | AWS リソース最適化用 |
不正解の理由
- B: RAG は外部知識参照の仕組みで、モデル自体のバイアスを修正するものではありません。
- C: Trusted Advisor は AWS リソースの最適化チェックで、ML モデルのバイアス修正機能はありません。
- D: 新規プリトレーニングは数百万ドル規模のコストがかかり、最もコスト効率の悪い選択です。
正解：B
正解の根拠
レビュー文書の要約は LLM の代表的なテキスト生成タスクであり、Amazon Bedrock 上の Claude や Titan などの基盤モデルを利用すれば、ファインチューニング不要で API 呼出だけで高品質な要約を生成できます。プロンプトに「簡潔な概要を作成」と指定するだけで実装が完結し、サーバー管理不要のサーバーレス運用が可能です。
用途別 AI サービス
| サービス | 用途 |
|---|---|
| Bedrock LLM | テキスト生成・要約 |
| Personalize | レコメンド |
| SageMaker | カスタム ML 開発 |
| Rekognition | 画像/動画分析 |
不正解の理由
- A: Personalize は時系列予測ではなくレコメンド専用で、レビュー要約の機能は提供しません。
- C: SageMaker で分類モデルを構築する選択肢は要約という要件と一致せず、開発工数も過大です。
- D: Rekognition は画像/動画分析サービスで、テキスト要約機能を持ちません。
正解：B
正解の根拠
Amazon Aurora PostgreSQL は pgvector 拡張をサポートしており、生成 AI の埋め込みベクトルを格納し類似度検索 (cosine, L2, inner product) を実行できます。会話型検索 (RAG) のベクトル DB 用途に対応する数少ない AWS マネージドリレーショナル DB で、トランザクション整合性とベクトル検索を同時に得られます。OpenSearch Serverless も選択肢ですが、本問では Aurora PostgreSQL が正解です。
ベクトル DB 候補
| サービス | 用途 |
|---|---|
| Aurora PostgreSQL (pgvector) | RDB＋ベクトル検索 |
| OpenSearch Serverless | ベクトル/全文検索 |
| Athena | S3 SQL クエリ |
| Redshift | DWH 分析 |
不正解の理由
- A: Athena は S3 上の SQL クエリエンジンで、ベクトル類似度検索のネイティブサポートはありません。
- C: Redshift は DWH で、ベクトル DB 用途として埋め込み類似検索の標準機能を持ちません。
- D: EMR は Spark/Hadoop の分散処理基盤で、ベクトル DB として動作する設計ではありません。
正解：B
正解の根拠
製品カテゴリごとにプロンプトを作成し、主要機能を強調しつつ出力形式と長さを明確に指定するアプローチは、プロンプトエンジニアリングのベストプラクティスです。タスクをセグメント化することで一貫性と関連性が向上し、出力制約 (フォーマット、文字数) を指定することで簡潔で機能特化した説明が安定して生成されます。
プロンプト設計の原則
| 原則 | 内容 |
|---|---|
| カテゴリ別分割 | 関連性向上 |
| 機能強調 | 差別化 |
| 形式指定 | 一貫性確保 |
| 長さ指定 | 簡潔性担保 |
不正解の理由
- A: 全製品を 1 プロンプトにまとめる方式はコンテキスト長と出力品質が低下し、後編集の工数も増えます。
- C: 「創造的でユニーク」を優先するとブレが大きくなり、機能特化した簡潔な説明という要件と合致しません。
- D: 製品ごとの詳細プロンプトは管理コストが膨大になり、スケールしない設計です。