基盤モデルの統合、データ管理、コンプライアンス31% · 6項目

Q1. 経営層から「生成 AI で問い合わせの対応を自動化できるか」を 2 週間で判断したいと言われた。最も適切な進め方はどれか。

1. 本番の規模のインフラと運用の仕組みを先にすべて構築し、完成した後で初めて品質や費用が足りるかどうかを確かめることにする
2. 代表的な問い合わせのデータで Bedrock の複数のモデルを使った PoC を作り、品質・遅延・費用を測って判断する
3. 社内の担当者に聞き取りだけを行い、モデルは試さずに資料の上で実現できるかどうかを判断する
4. 最も有名なモデルを 1 つ選んで契約し、PoC は行わずに全社の問い合わせの窓口に直接つなぐ

Q2. 複数のチームがそれぞれ生成 AI のアプリを作っていて、設計の品質がばらばらになっている。設計をそろえる方法として最も適切なものはどれか。

1. Well-Architected の生成 AI レンズで設計をレビューし、共通の部品（プロンプトのテンプレート・ガードレール・ログ）を標準化する
2. 最初に作られたアプリのコードを全チームにコピーさせ、要件が違っても同じ構成で作らせる
3. 設計の文書は作らずに、毎週の会議で各チームの担当者が口頭で説明し合うだけにしておく
4. チームごとに自由に設計させ、問題が起きたアプリだけを後から個別に作り直すことにする

Q1. 100 ページを超える契約書の全体を一度に読ませて、条項の矛盾を見つけたい。FM を選ぶときに最初に確かめるべきことはどれか。

1. モデルの提供元の会社が、日本に事務所を持っているかどうか
2. モデルの出力の文字の色やフォントを、アプリの画面のデザインに合わせて変えられるか
3. モデルの最大のコンテキストの長さに、文書と指示と出力が収まるか
4. モデルの名前が覚えやすく、社内の利用者に説明しやすいかどうか

Q2. 利用者が撮った機器の写真と質問の文章をまとめて送り、故障の原因の候補を答えるアプリを作る。最も適切な実装はどれか。

1. 画像の入力に対応しないモデルを選び、画像のデータを文字列に変えてプロンプトに貼り付ける
2. 画像はファイル名だけを文章に書き、モデルにはファイル名から内容を推測させることにする
3. 画像を一度印刷して担当者が内容を文章に書き起こし、その文章だけをテキストだけに対応したモデルに送ることにする
4. 画像の入力に対応するモデルを選び、Converse API のメッセージに画像と文章の両方を入れて送る

Q1. 財務の分析で、多くの段階の計算と検討が必要な難しい質問に答えさせたい。応答の時間は多少長くてもよい。モデルの選び方として最も適切なものはどれか。

1. 推論（reasoning）の機能を持つモデルで、考える量の上限を決めて使う
2. 推論の機能を持つモデルを、簡単な質問も含めすべての処理に使う
3. 大きなモデルを財務のデータでファインチューニングして使う
4. 高速で安いモデルに Chain-of-Thought の指示を加えて使う

Q2. 東京リージョンで使いたいモデルが提供されておらず、日本の地域のクロスリージョン推論のプロファイルなら使える。使う前に確かめるべきことはどれか。

1. プロファイルを使うと、すべてのデータが自動で東京のリージョンに保存されることを確かめる
2. 振り分け先のリージョンの天気と、データセンターの建物の大きさを確かめる
3. プロファイルの名前が、社内の命名の規則に合っているかどうかだけを確かめる
4. 要求が振り分けられるリージョンでの処理が、会社のデータの所在の規則で許されるか

Q1. 書き方がばらばらな商談のメモを、埋め込みの前に整えたい。最も適切な方法はどれか。

1. メモをそのまま取り込み、チャンクのサイズを小さくして検索の精度を上げる
2. 埋め込みのモデルを多言語に対応した大きなものに替え、表記の違いを吸収させる
3. ハイブリッド検索を有効にし、キーワードの一致で表記の違いを補う
4. Lambda や Bedrock で日付・金額・製品の名前の表記をそろえ、決まった形式に整えて取り込む

Q2. 「製造業の顧客向けの、直近 1 年の提案書」だけを根拠にしたい。最も適切な設計はどれか。

1. 業種ごとに別のアプリを作り、営業の担当者に正しいアプリを選んでもらうことにする
2. 提案書に業種・作成日・作成者のメタデータを付け、検索でメタデータのフィルターを使う
3. 検索はすべての提案書から行い、モデルに古いものは無視するように頼んでおく
4. 提案書のファイル名に業種を書き、プロンプトでファイル名を見て正しく選ぶようにモデルに指示する

Q1. ベクトル検索の文書が 1 億件を超え、検索の遅延が増えてきた。OpenSearch Service で最初に見直すべきこととして最も適切なものはどれか。

1. ベクトルの次元の数を大きく増やして、検索の精度だけを上げるように調整しておく
2. すべての文書を 1 つの小さなシャードにまとめて、費用のためにインスタンスの数を最小にしておく
3. シャードの数とサイズ、レプリカ、インスタンスの種類、分野ごとのインデックスの分け方を見直す
4. 検索のたびにインデックスを作り直して、常に最新の状態で検索するようにしておく

Q2. 社内の Confluence と SharePoint の文書も、RAG の根拠に使いたい。最も手間の少ない方法はどれか。

1. Amazon Kendra のインデックスを作り、エージェントから検索させる
2. Web クローラーのデータソースで、両方のサイトの URL を巡回させる
3. Glue のジョブで文書を S3 に書き出し、S3 をデータソースにする
4. Bedrock ナレッジベースのデータソースのコネクターで、Confluence と SharePoint をつなぐ

Q1. AppConfig でモデルを別の提供元のものに切り替えたら、出力の JSON の解析の失敗が増えた。次に行うべきこととして最も適切なものはどれか。

1. モデルごとのプロンプトのテンプレートを用意し、構造化された出力で形式を守らせ、評価してから切り替える
2. AppConfig の切り替えを段階的にし、失敗の率を見ながら割合を増やす
3. 解析に失敗したら、同じ要求を前のモデルに送り直すフォールバックを入れる
4. temperature を 0 にし、同じプロンプトのまま新しいモデルで続けて使う

Q2. プロンプトを変更するたびに、品質が下がっていないかを確かめたい。最も適切な仕組みはどれか。

1. 期待する出力を持つ評価のデータセットで、CI のパイプラインで変更の前後を比べる
2. プロンプト管理で版を残し、問題が出たら前の版に戻せるようにする
3. 本番で A/B テストを行い、利用者の評価で良いほうを残す
4. 変更した担当者がプレイグラウンドで代表の質問を試し、良ければ出す