AIP-C01 · LESSON 5

テスト、検証、トラブルシューティング11% · 2項目

生成 AI の評価の仕組みの実装と、生成 AI のアプリのトラブルシューティングを学びます。

5.1GenAI の評価システムを実装する

5.1 GenAI の評価システムを実装する。

概念

Bedrock の評価には、モデルの評価(自動の指標・人による評価・LLM を審査員にする評価)と、RAG の評価(ナレッジベースの検索の評価:関連性・網羅性、検索と生成の評価:正確さ・忠実性・有用性)があります。評価のデータセット(プロンプトと期待する回答)を用意し、変更のたびに比べます。

仕組み・手順

  1. 代表的な質問と期待する回答の評価データセットを作る
  2. モデルの比較には、LLM を審査員にする評価で品質の指標を測る
  3. RAG は検索と生成を分けて評価し、問題の箇所を特定する
  4. 安全性(有害性・拒否の適切さ)も評価する
  5. 評価を CI/CD のゲートに組み込む

業務での例

チャンク分割の方式を変える前後で、ナレッジベースの評価を実行し、文脈の関連性と回答の忠実性がどちらも改善したことを確かめて本番に反映する。

紛らわしい点・試験の注意

ミニクイズ

Q1. LLM-as-a-judge の採点を信頼できるものにしたい。最も適切な方法はどれか。

  1. 回答を作ったモデルと同じモデルに、採点の基準を決めずに「よいかどうか」だけを聞いて採点する
  2. 評価のスコアを見て都合が悪ければ、評価のモデルを何度も変えて高いものを使う
  3. 評価のモデルのスコアが高ければ、基準や人の確認なしで品質がよいとみなす
  4. 明確な採点の基準を決め、一部を人が採点した結果と比べて、評価のモデルの採点を校正する
答えと解説を見る

正解:D 明確な採点の基準を決め、一部を人が採点した結果と比べて、評価のモデルの採点を校正する

採点の基準を明確にし、人の評価と比べて校正する。生成したモデルとは別のモデルを使うと偏りを減らせる。

Q2. 評価のデータセットを作る。最も適切な作り方はどれか。

  1. 開発者が思いついた簡単な質問を 10 件だけ用意し、ずっと同じものを使う
  2. 実際の利用者の質問を代表する例に、境界の例・攻撃的な入力・答えのない質問を加え、期待する回答も用意する
  3. 評価のデータセットは作らずに、毎回その場で思いついた質問で確かめる
  4. モデルが正しく答えられた質問だけを集めて、評価のデータセットにする
答えと解説を見る

正解:B 実際の利用者の質問を代表する例に、境界の例・攻撃的な入力・答えのない質問を加え、期待する回答も用意する

評価のデータは本番の質問を代表し、難しい例や攻撃的な例も含める。

参考リンク

5.2GenAI アプリのトラブルシューティング

5.2 GenAI アプリケーションをトラブルシューティングする。

概念

よくある問題と対処:ThrottlingException(429:再試行・クォータの引き上げ・クロスリージョン推論・プロビジョンド)、ValidationException(入力の形式・トークン数の超過)、AccessDeniedException(モデルのアクセスの有効化・IAM)、ModelTimeout・遅い応答(ストリーミング・出力の短縮)、ハルシネーション(RAG の検索の確認・グラウンディングのチェック)、ガードレールの過剰なブロック(フィルターの強さの調整)。

仕組み・手順

  1. エラーのコードとメッセージから原因の種類を切り分ける
  2. スロットリングはクォータと利用量を確認し、再試行と分散を行う
  3. アクセスの拒否はモデルのアクセスと IAM ポリシーを確認する
  4. 回答の品質の問題は、検索の結果・プロンプト・モデルの順に確認する
  5. トレースとログで再現し、修正後に評価で確認する

業務での例

回答の誤りの報告を受け、トレースで検索の結果を確認すると古い文書が上位に来ていたため、メタデータのフィルターで最新版だけを検索するように直す。

紛らわしい点・試験の注意

ミニクイズ

Q1. モデルの JSON の出力が、ときどき解析できずにエラーになる。最も適切な対策はどれか。

  1. プロンプトに JSON の例を 1 つ示し、同じ形式で出すように指示する
  2. 出力の最大のトークン数を増やし、JSON が途中で切れないようにする
  3. temperature を 0 にし、同じ形式の出力が出やすいようにする
  4. 構造化された出力やツールの使用のスキーマで形式を決め、失敗したらエラーを添えて再生成させる
答えと解説を見る

正解:D 構造化された出力やツールの使用のスキーマで形式を決め、失敗したらエラーを添えて再生成させる

スキーマで形式を決める。失敗したときは、検証のエラーを伝えて再生成させると直りやすい。 【他の選択肢】temperature や例の提示は失敗を減らすが、形式を保証しない。最大のトークン数は切れる場合にだけ効く。スキーマと検証のエラーの再生成で確実に直す。

Q2. Converse や InvokeModel の呼び出しで返るエラーの種類と、その対応の組み合わせのうち、誤っているものはどれか。

  1. 一時的なエラーは、指数バックオフで再試行するとよい
  2. ThrottlingException はリクエストの形式の誤りを表すので、再試行しても意味がない
  3. AccessDeniedException は、権限の不足を表す
  4. ValidationException は、要求の形式やパラメータの誤りを表す
答えと解説を見る

正解:B ThrottlingException はリクエストの形式の誤りを表すので、再試行しても意味がない

ThrottlingException は要求が多すぎることを表す。バックオフで再試行すると成功することが多い。

参考リンク

レッスンは当サイトがAWS 認定の公式ページと公式試験ガイドをもとに独自に作成したもので、試験の内容を保証するものではありません。製品の仕様は変わることがあるため、参考リンク先の最新情報を確認してください。

ご利用上の注意(非公式・独自問題・合格保証なし)