AIP-C01

SkillBuilder Official Practice Question set

推論リクエストでガードレールの使用を強制する
- InvokeModel APIとConverse APIコールにIAMポリシーを適用する。
  - 条件キーには、bedrock:GuardrailIdentifierを使用する。
  - このポリシーをAmazon Bedrock FMにアクセスするすべてのIAMロールに適用することで、ガードレールの使用を強制する

サービス単位

Bedrock FM

基盤モデルのこと
AWS独自のモデル以外にも各社のものを使える。ChatGOT系も最近使えるようになりつつある
- Anthropic
- AWS独自モデルはTitan/Novaシリーズ
実運用で使う時はRAG,Agents,Guardrails等の周辺機能と組み合わせることが多く。そこらへんが出題される。

AWS認定Generative AI Developer - Professional (AIP-C01)模擬試験問題集

Bedrockの設定値系

推論プロファイル
- FMごとに、推論リクエストのルーティングルールを定められる
- SDK視点だと、この推論プロファイルのARNをInvokeModel APIのmodelIdに指定する感じ
クロスリージョン推論プロファイル
- マルチリージョンに推論リクエストを振り分けられる
- リージョンの意味合い
  - ソースリージョン
    - リクエストを受け付けるリージョン
    - ログはここに保存
  - 送信先リージョン
    - リクエトをルーティングできるリージョン
- 2種類
  - Geographicプロファイル
    - 地理的な境界に収める。データレジデンシー要件に対応する目的でやる。GDPAとか
      - データレジデンシー要件対応はむしろ各リージョンでガードレールをデプロイする方向かも（マルチリージョン推論を無効にする）
  - Globalプロファイル
    - 全世界の商用リージョンを使える。コスト的に有利

各論(1セット)

1-9略

10

マルチリージョンで可用性確保したい
- 対象のFMで、Bedrockのクロスリージョン推論プロファイルを利用
- ただし、リージョンの容量上の制約等でリクエストが失敗することがあり、そのエラーハンドリングをワークフローに閉じたい（ソースコードにリージョンフェイルオーバーの実装を書きたくない）
- StepFuncionのステートマシンでモデル呼び出しを組み、Catchで大体ステートに移す
StepFunctionはBedrockとのオプティマイズド統合がサポート
- Lambda関数を仲介しなくても、InvokeModel APIをTaskステートのResourceに指定できる
- Bedrockの推論ループをStepFunctionsで実装するのが楽なのでよく試験に出る
  - 仮説・検証・判断のこと
Route53でBedrockの推論のマルチリージョンフェイルオーバーはできなそう。Bedrock側で使えるヘルスチェック機能が用意されてないから

11

Bedrock Agents
- 自律型エージェントを実装できる
- Lambda関数とかAction Groupとかを組み合わせる
- Bedrockのマネージドエンジンが制御するので、自前で実装したいときにはStepFunctionとの使い分けになる
- 実行履歴はInvokeAgentレスポンスのストリーミングデータから取得できる。StepFunctionsはサービス自体が90日間実行履歴を保持する上にグラフビューでステップ単位で追跡できる。
- BedrockAgentsで長期保存するならFirehoseとS3でパイプライン構築する

12

Bedrockプロンプト管理
- 再利用可能なプロンプトの作成・保存・管理
- ほかのワークフローに使いまわせる
- 変数埋め込みで、プロンプトのテンプレート化が可能
- バリアント機能で、同一プロンプトでちがうモデル・推論パラメータとかを設定できる
- バージョン管理
- リージョナルサービスなので、マルチリージョンで利用するには各リージョン間でテンプレートとかバージョンを同期する実装を自前でする必要がある

13

Sagemaker ModelMonitor
- Sagemaker AIの管理するエンドポイント方向へのデータ監視
  - データドリフト検出
SageMaker Clarify
- MLモデルのバイアス分析
- 説明可能性の提供（SHAP値ベース？）
LLMの回答精度の評価パイプラインをできる限りAWSマネージドに
- CodePipelineにLambda Invokeアクションを組み込む。まだCodePipelineにBedrock評価ジョブ用のネイティブアクションが存在しないから
- LambdaではBedrockの評価ジョブAPIを呼び出す
  - 参照回答を含むプロンプトデータセットを使う
  - Bedrockのビルトインメトリクス（LLM-as-a-Judge）で回答の採点
  - 評価ジョブLambdaはS3に蓄積されたレポートを読み取って、CodePipelineに結果を送信
    - PutJobSuccessResult/PutJobFailureResult

16

StepFunctionsで手動承認フローを挟むには
- ⭕️ Standardワークフロー
- ❌　Expressワークフロー
  - Expressは短時間で終わるワークフロー向けなので、手動承認のように長時間待つステップを挟むことができない

18, 21

Bedrock Guardrails
- ワードフィルター
- コンテキストグラウンディングチェック
  - 応答がソース情報に基づくか、問い合わせに関連するか
  - 設定値を高くするほど厳しい
  - 下回るとハルシネーションとして検出・応答のブロックも可能
- 拒否トピック
- 機密情報フィルター
- 回答品質や一貫性については守備範囲外。やるならBedrockモデル評価ジョブをCIに組み込むとか

19

AgentCore Evaluations

20

推論結果を逐次表示するみたいなことをしたいときに一番実装負荷が小さいのはWebSocket接続
- API GatewwayかAppSync
- Bedrockで叩くAPIとしてはInvokeModelWithResponseStream API

23

StepFunctionsでのBedrock使ったワークフローを組んだときに、推論実行にはInvokeModelしか使えない
- オンデマンド推論APIということなので、バッチ処理で使ったときにコスト削減は見込めない

28

Amazon Q Business
- S3に格納されたドキュメントを検索・回答できる
- S3コネクタでACL設定ファイルをサポート
  - 指定のバケットないならどこにおいても良い（最大文字長はある）
    - aclConfigurationFilePathパラメータで指定
  - 単一ファイル。パスに応じて分割するとか不可能
  - keyPrefixごとにaclEntriesを定義。ALLOW/DENY
  - {{ファイル名}}.metadata.jsonで制御する方法も公式にサポートされてルガ、ファイルごとに作らないといけないのでACL設定ファイルが一つで済むのと比べて運用負荷が大きすぎる
- IdentityCenterと統合できる
  - ACL設定ファイルではIdentityCenterのグループ名を指定してアクセス制御できる
- 回答に使うかのアクセス制御はIAMポリシーとかバケットポリシーでのリソースレベルのアクセス制御と完全に別の仕組み
  - Q Businessでの検索結果のフィルタリングに、ACL設定ファイルとかメタデータファイルでのアクセス制御を実施する
- メタデータファイル
  - オブジェクトごとにメタデータファイルを配置する
    - オブジェクトごとに設定が必要なので運用負荷が高め
  - AccessControlListフィールドでアクセス制御
- ACL設定とメタデータ設定を両方指定した時はドキュメントからわからないので実際にやってみるしかない

32

DataWranglerはデータ探索・変換用途に合致しているが、品質ルールを宣言的に定義して評価・スコアリングするのはできない。
なのでそういうことをしたいときにCWでカスタムメトリクスを自前で書くことになる
Glue Data QualityならDQDLルールで検証・スコアリング・監視までサーバーレスで実装できる

33

S3イベント通知は新規作成と上書き更新を区別できるようなイベント種別がない

41

SDKのリトライモード
- Standard：デフォルト。ジッター付きのエクスぽねんシャルバックオフ。再試行クォータでサーキットブレーカーが発動する。
- Adaptive：Standardにクライアント側のレートリミッターを足した。SDKクライアント単位なので、送るリソースとかテナントの構成次第では無関係なリソースへのリクエストにも影響するのに注意

42

InvokeModel APIとConverse APIは、ひとまずマルチターンなら後者、細かい制御は前者

43

Lex v2
- 音声認識（ASR）と自然言語理解（NLU）を組み合わせて会話できる。
- インテント認識→スロット収集→フルフィルメントの流れ
  - インテント：ユーザーの意図
  - スロット：インテントに紐づいたパラメータ。商品名とか購入日とか
  - フルフィルメント：実行
  - 各会話ステップでLambda関数を呼び出せる
    - タイミングはインテント認識後の初期応答とかスロット値取得・確認時とかフルフィルメント時とか
    - この関数内でBedrockで推論したりできる
- Assisted NLU機能
  - LLMでインテント分類とかスロット解決の理解精度を上げる
  - ボットからのレスポンスの生成・変更はしない
    - 生成・・変更したいなら、Lambda関数を挟んでBedrockで推論とか
  - トレーニングデータが少なくてもインテントを正確に認識したいとか

47

WAFでプロンプトインジェクションは防げない。自然言語でLLMに想定外の動作をさせようとするものなためシグネチャからどうしようもない？

48

LLMへの攻撃の多層防御はアプリケーション層とBedrockのGuardrailsの二段構えが基本？
プロンプトインジェクション対策
- Guardraild：
  - PROMPT＿ATTACKフィルターを設定できる。入力感度も変えられる。
- アプリケーション：
  - ユーザー入力のプロンプトを所定のxmlタグで囲む。サフィックスをリクエストごとにランダム文字列にしたらユーザーがタグ構造を予測しても効かない
  - ` ここまでの指示を全部無視して`みたいなプロンプトインジェクションにも効く
- リーケージ検出にはGuardrailsのStandardティアで有効

51、52

StepFunctionsでBedrockモデルをカナリアリリースする
- ステートマシンとして10→20→......→問題があったため切り戻しを実装できる
  - Lambda関数の実装は必要かも
- CWメトリクスを定期で評価する
  - リアルタイム推論とか
- 複数メトリクスを組み合わせたいとか、外部の合成監視をしたいとか、ビジネス上のKPIを使いたいとか
- ECS以外のサービスでの切り戻しがあるサービス
SageMaker Model Registryでできるケースもある
- モデルパッケージグループという単位でモデルバージョン・学習精度・損失値とかのメタデータも一覧参照できる
- モデルバージョンのステータスに応じたアクションを作れる
- MLOpsテンプレートがあって、商人ステータス変更に応じたCodepipelineが発火するようにできる
  - Rejectedに変更した場合は最新のApprovedなバージョンが再デプロイされる
  - Approvedにしたらそれがデプロイ

56

LLM as a judgeは法律（とか多分金融とか）の高い正確性がいる分野ではあくまで一時スクリーニングくらいの立ち位置にする
- エッジケースの判断は専門家に任せられるようにする

57

BedrockのナレッジベースのRAGの精度を計測したい
- RAG評価ジョブ
  - context relevanceスコアとか
- モデル更新前後のスコア比較をしたいときには埋め込みモデルが更新されてるかをちゃんと確認すること

58

DataZone

61

Bedrockのジョブから読み出すデータをS3に置く時のアクセス制御
- IAMのアクセス許可
- CORS設定
  - VPCエンドポイントでSGで許可して…とかではない。内部的な使い方の問題っぽい。Sagemakerでもあった

各論（2セット）

コールセンターで500msとかの低レイテンシで文字起こしとFMからの応答に基づいた対応案を表示する
- 文字起こしとFMへのリクエストを両方ともストリーム処理する
  - Transcribeを50-200msのチャンクでストリーミングAPIに送って、応答生成はInvokeModelWithResponseStream API
text-to-SQL
- 自然言語をSQLに変換する手法
- RDSの構造化データをLLMから取得したい時に使う
  - GenerateQuery APIをサポートしていないDBの場合はSQLバリデーションフローを自前実装する。RDSもまだ
- ハルシネーションを提言するのにStepFunctionsでバリデーションワークフローを組むらしい
RAG機能の検索と生成の品質評価は同じ評価ジョブにまとめて良い
- LLM-as-a-judgeメトリクスとprecision at kメトリクスあたりを使う
Bedrock Data Automation
- ドキュメント・画像・音声・動画の4つのモダリティを単一のAPI IFで処理できる。
- モデル選択とかプロンプト設計もせずに済む
- 処理結果は指定したS3バケットに出力する
- 処理完了の通知先も指定できる。EventBridgeとか
MCPサーバーをLambda関数で公開する時に運用オーバーヘッドを抑えるなら
- 関数URL発行
- カスタムStreamable HTTPトランスポート
  - ネットワーク経由で使う時にこっちを設定する。ローカル実行だとstdioを使ってるので意識しないかも
- SigV4とIAM認証を設定。必要なポリシーは下記
  - InvokeFunctionUrl
  - InvokeFunction
チャンキング手法
- 階層型
  - 親子のチャンクがある
  - 重なりを持たせることもできる
  - 科学論文で複数セクションにまたがるようなクエリの精度を上げたい時に有用
- 固定チャンキング
  - 短い文章むき
- セマンティックチャンキング
  - 類似度の単位で区切る
  - ブレークポイントパーセンタイル閾値で分割の厳しさを制御
StepFunctionsの直接統合にOpenSearchもある
Bedrockのモデル評価ジョブ
- S3にJSONLファイルでプロンプトを格納
- 入出力先のS3バケットを指定
- FMごとに同じ基準で評価できる
StepFunctionのChoiceステートでプロンプトの複雑さを判定して使うモデルを切り分ける設計パターンがある
- StepFunctionsとBedrockがネイティブ統合してるので、使うモデルはGUI操作で終わる（Lambdaのコード改修とか再デプロイ不要）
Bedrockのインテリジェントプロンプトルーティングでも、動的にモデル切り替えができる
- 同じモデルファミリー内のFMでリクエストを振り分けられる
- リクエストごとの応答品質を動的に予測して、フォールバックモデルとの品質さが基準を超えたら振り分ける
- 違うベンダーのモデルファミリーも振り分けたい時にはLambda関数
  - StepFunctionsのChoiceステートは応答品質の評価とかまではできないので、少なくともChoiceステートに渡す値を作るLambda関数の実装は必要
API GWでレスポンスストリーミングする
- RESTが対応。HTTPでは非対応
- Lambda関数のレスポンスを段階的にレスポンスできる感じ
- Lamnbda関数内でBedrockのInvokeModelWithResponseStreamで良い
CloudWatchでMLモデルを監視したい時にはAnomalyDetectionがだいたいセットかも
ゾーン・オブ・トラスト外の外部エンティティとリソース共有されてないかを自動検出したり、未使用権限の最小顕現化を定期的にチェックするのに、Access Analyzerを使う
- Configだと静的なルールとの照合なのでゾーン・オブ・トラストの境界を論理的に解きほぐしてどういう状態かまではわからない
- ゾーン・オブ・トラストという言葉がAnalyzerを作る時にしか聞かない概念かも
  - 信頼できる範囲とするAWSアカウントとかAWS Organizationsの組織とか
Bedrockのプロンプトルーターはリクエストの複雑さに応じてモデルを切り替える機能。プロンプト内容の管理はプロンプトマネジメント
Bedrock GuyardrailsのApplyGuardrail APIでFMを呼ばずにPIIを検出・マスキングできる
- 認証情報ごとにガードレールを切り替えて、権限に応じてマスクするしないとかできる
Bedrock FlowsとStep Functionsの使い分け
Bedrock Flows
- 使えるノードが限定的？S3取得と保存はある。
- Promptノードでモデル呼び出し
- Agentノードもある
Lambdaで構築したMCPサーバーを公開する時に、API GWのHTTP APIで構築する。エージェントからはStreamable HTTPで叩く
- 認可はOAuthとか
顧客データをコンテキストにしたGen AIサービスを提供するのに、顧客データ所有・管理研のガバナンス対応でAmazon Q Bussinessを使うケース
- 顧客にAmazon Q Businessインデックスを構築してもらって、データアクセサーに登録してもらう
- API経由で必要なコンテンツを読み出せるようになる
  - セマンティック検索（dense）とキーワード検索（sparse）を使ったハイブリッド検索ができる
BedrockのストリーミングAPIは部分再開できないので、Bedrockのクォータとかでタイムアウトしたリクエストを再開するときはそれまでの全リクエストを送り直すことになる？
- 少なくとも欠落チャンクだけを要求して再開するのは使用上できない
StepFunctionではステートかんで受け渡す出力が256KiBのクォータがあるので、Bedrock統合ではS3を使う
- たとえば大きめのコンテキストの推論結果とかをそのまま渡そうとするとかで割と簡単に超過する
- Input/Out putにS3Uriを指定できる
- Bodyが256KiB制限がある
RetrieveAndGenerate APIは回答根拠となる検索結果を紐づけたい時に有用
- RetrieveとInvokeModelを分けるとここが微妙になってハルシネーションを起こしたりするらしい
Bedrock AgentCore
- 同期呼び出しとイベント駆動型の呼び出しの両方に対応
- セッション間でメモリ共有できる
- カスタムコードなしでだいたい実現できる
Bedrockナレッジベースではクエリ分解機能で複雑な質問を扱いやすいサブクエリに分解できる
OutPosts
- EKSを使えるのは42Uラックだけ
  - たいていのサーバーを使える
- EC2とかECSとかは1U/2Uラックでも使える
LocalZonesはデータセンターがある？AZほどでない規模の
BedrockとManagedGrafanaとのzero-ETL統合はまだない。ECSとかならある
データレジデンシーがあって、同じモデルでも日米欧それぞれのリージョン内からトラフィックが出ないようにしたい時
- クロスリージョン推論プロファイルで、各リージョンにモデルを配置して、各リージョンでクロスリージョンプロファイルを設定する
  - イメージとしては日本向けはap-northeast-1,2にモデルを置く感じ
Bedrockナレッジベースの精度が微妙な時に最小の運用オーバーヘッドで検索精度を上げられるかもしれないのは、リランキング設定を有効にする

AIサービス以外

Macie
- S3の機密情報の認識
- 機密情報を検知したオブジェクトの分類レポートを得られる
SageMaker Pipelineはモデルのビルドからデプロイまでの自動化
- リリース後の監視とかは違うサービスで実装。ModelMonitorとか
AppConfig
- パラメータ系のごく短いキャッシュ的なもの？
- ParameterStoreから直接取得みたいなことをできる？
CloudTrail Lake
- SQLベースのクエリでイベントを分析できる
- Organizationsのイベントを横断検索するとか

間違えた問題だけ復習

SCPで禁止しているリージョンでしか使えないBedrock FMがある時の権限設定
- SCPに例外を設けて、特定の推論プロファイル経由でのクロスリージョン推論を許可
  - ControlTowerの管理してるSCPを編集することもできるけど、強く非推奨
    - やるなら新規SCPをデプロイする感じ
- そもそもの、利用側のロールで推論プロファイルARNへの呼び出し権限も必要
Bedrock評価ジョブ
- 自動評価では正確性・堅牢性・有害性とかのメトリクスを定量スコアで返す。タスクタイプとして質問応答・要約・分類・テキスト生成とかを選択できる
- 評価主体はLLM-as-a-judgeか人間評価か
CodePipeneでのデプロイゲート
- デプロイステージ前に評価ジョブを起動して、スコアに応じて条件分岐する
  - ステータスをポーリングしてジョブ完了を確認する
AIアシスタントに仮説を立てて確認して次の手を考えてというループを繰り返させたい。ループをいつ打ち切るかという条件を状態定義として記述して運用開始後も変更したい。ステップの流れをグラフィカルに追いたい。各ループでのログ系を一定期間は保持して検索・閲覧したい
- 【⭕️】StepFunctionsのStandardワークフローで組む
  - ループの定義はASLで記述できる
  - 実行履歴はデフォルトで90日間保持するし各ステートをグラフィカルに確認もできる
- 【❌】Bedrock Agents
  - オーケストレーションループはマネージドロジックが自律的に回すので、ループを打ち切る条件を定義できない
  - グラフィカルなコンソールも提供されていない
プロンプトのバージョンごとにバイアスモニタリングしたい時にはClarify
- キャプチャ済みの推論データからいろんなメトリクスを自動計算してCWにメトリクスを発行してくれる
  - メトリクスを使って定期レポートとかダッシュボードとかを自前で作る
  - モニタリング頻度は1時間なのでニアリアルタイム監視
Prompt Managemantではグループ間でのバイアス測定とかはできない
Bedrock Flowsはブルーグリーン的なデプロイしかできなそう。トラフィック分割とかカナリアデプロイとかできなそう
SageMakerのリアルタイム推論エンドポイントにリクエストするLambdaについて、応答時間が安定しないという苦情。レイテンシを小さくしたい
- モデルの重みをコンテナ起動の段階でGPUメモリに読み込むようにする
  - 重み読み込みをヘルスチェックが通った段階で完了させておけば、最初の応答が安定する
- 最小インスタンス数を0より大きくして常時軌道を保つ
- ストリーミングを有効にする
  - HTTP/1.1 chunked encodingで逐次送る感じっぽい
すでにLakeFormationのデータレイクにあるデータで、件数は50万未満。これをセマンティック検索できるようにしたい。最小の運用オーバーヘッドで
どっちのプロンプトが公平かを継続的に比較したい。公平性メトリクスを定期的に収集・監視して、グループ間の不一致が閾値を超えたら通知するのを想定している。比較する週次レポートも欲しい
- 【⭕️】Clarifyのバイアスドリフトモニタリング。バイアスメトリクスをCWメトリクスに定期的に送る。メトリクスにCWアラームを貼って、週次レポート用のダッシュボードも作る
  - モデル出力のバイアス検出と公平性測定をできる。自動計算してくれるメトリクスがあるので、CWに発行するように設定する。
- 【❌】ModelMonitorのデータ品質モニタリングジョブ
  - データ品質なので、今回必要な推論結果のドリフト評価はできない。入力データの統計的性質がベースラインからドリフトしていないか。
OpenSearchでのハイブリッド検索のメリット
- 弱点を補い合える
  - 略語や専門用語の完全一致を字句検索（BM25）
  - 意味的な関連性の把握にベクトル検索
- サーチパイプラインの正規化プロセッサがスコアを統合する感じなので追加のインフラは不要
OpenSearchで似た質問が多いのでキャッシュできるようにしたい
- 【❌】質問と回答をOpenSearchにインデックスして、そこもセマンティック検索するようにする。新しい回答は都度インデックスに登録する
  - キーワード検索するからダメ？
- 【⭕️】質問と回答をベクトル化してElasticacheに保存。基準を超えるエントリはインメモリデータストアから返して、なかったらインジェスト時と同様の処理で追加
  - BedrockのFMでベクトル化するならTitan Text Embeddings V2とか
  - Elasticacheはセマンティックキャッシュを公式のユースケースに位置付けるので使って良い
BedrockにもCompaction機能はあるが、まだInvokeModel APIでしか利用できない（2026年9月時点）
- しかも対応モデルが古め。Sonnet 4.6とか
- Converse APIとかのマルチターンでコンパクションしたい時は自前実装することになる
  - 推論の手前でCountTokens APIで入力トークン数を数え上げて、閾値を超えたら古いターンをようやくメッセージに置き換えてから推論リクエストする
  - 前提として、Bedrockはリクエストを跨いだ会話状態を保持しないので、多ターンでの会話にはこれまでの全メッセージを送る必要がある。
Lex V2のAssisted NLUは意図分類とスロット解決を補強する。フルフィルメントはLambdaを発火するようにしてそこでBedrockのFM叩くとか
プロンプトインジェクション攻撃への対策にガードレールのワードフィルターは不適切
クロスリージョン推論を正しくいうと？ガードレールプロファイルによるクロスリージョン推論
ガードレール把握まで生成後の出力をブロックする層に位置付けられる？入力プロンプトもフィルターかけれた気がするけど
プロビジョンドスループットはアクセス数の少ない時間帯がはっきりしてる時に無駄が多い
Bedrockのリクエストの性能設定にレイテンシパラメータ：optimizedがある。プロンプトキャッシュ機能もある
- レイテンシ最適化推論
- プロンプトキャッシュ：文脈を共有する問合せのレイテンシ削減
- どっちも従量課金
Step functionsでBedrockのモデルのカナリアデプロイするアーキ？
- 段階的な意向・メトリクス評価・トラフィック量の増減とロールバックをかを1つのワークフローにまとめる
- LambdaでCWメトリクス評価とか、Choiceステートで条件分岐するとか
- ModelMonitorで似たことをできるけど、SageMaker AIでデプロイしたモデル向け。Bedrockのモデルで適用できない
埋め込みモデル更新後からRAGの精度が微妙な時の対応方針
- まずは埋め込みモデルが新しいものに切り替わってるか確認。チャンク化設定とかも確認
- 次にデータソースを作り直して再同期
- 最後にRetrieve onlyモードのRAG評価ジョブで対応前後とか埋め込み更新前とかと品質を数値比較
Bedrockのプロンプトキャッシュは毎回送らざるを得ないシステムプロンプトにも適用できる
- ConverseAPIで全会話を送るので、そのうちのシステムプロンプトとかを削減できる
  - ConverseAPIではキャッシュチェックポイントを置けて、システムプロンプトをキャッシュする
  - TTLを設定できてその範囲内でトークン使用料を抑えられる（課金も抑えられる）
決まった種類の請求書がアップロードされるバケットから、それぞれの請求書タイプに応じた情報を抽出するには？
- BDAプロジェクトを1つ作って、請求書タイプごとにブループリントを作る
- S3イベント通知からLambdaを起動するようにEventBridgeルールを作成
  - 関数ではInvokeDataAutomationAsyncAPIを叩いて、適切なブループリントを選択して情報抽出する
  - ブループリントの定義から、文書をどのブループリントで処理するべきかを判断する
    - 1ファイル内で複数ブループリントを適用するのもできる
    - どのブループリントにも当てはまらない時用のフォールバックブループリントを指定することもできる
- 【❌】Recognitionをつかってオブジェクトにラベル付与。ラベル付与のイベント通知でLambdaを起動してラベルに応じたデータ抽出
  - 運用オーバーヘッドが不要に大きい。ラベル識別をBDA内でできるため
Amazon Q Busineesはエンタープライズデータとアプリケーションを接続するときに使うので、エンタープライズのデータ基盤とかの前提が出てこない限り選択しない
命題を推論ステップに分解したい時にStep functionsで導入する設計に、ReAcctパターン
- どっかにノート取ったのでそれを読んで
SageMakerリアルタイム推論エンドポイントはWebsocketに対応してない
- BedrockならそういうAPIをLambdaから叩く、LambdaはAPI GWのWebsocketもしくはLambda直接実行で実現できる
- 独自のMLモデルなら、レイテンシを気にするならECSとか
Clarifyは埋め込みのドリフトには対応してない
- ベクトル検索で入力ドリフトを検証するのにはカスタムのECRイメージでSageMaker ModelMonitorジョブを実装する
  - ベースラインのトレーニングセットと比較するのは普通のドリフト調査と同じ
  - S3に違反レポートを保存するのは監査目的ぽい。ここまで独自実装する必要がある
Bedrock Flow vs StepFunctions
- 高度な制御があればStepFunctions
  - リトライ・分岐・並列・長時間の待機とか
- Prompt Managementとかとの統合の容易さでいくとBedrock Flow
SagemakerAIのエンドポイント以降にUpdateEndpoint API
- エンドポイント更新した時にSagemakerAIエンドポイントのトラフィックを移行するのに使うらしい。
- 古いインスタンス削除もしてくれる？
AmazonQBusinessにはモニタリング機能が組み込まれてるらしいので、追加でメトリクス作るみたいな回答は大抵運用不可の観点から微妙
Bedrock Intelligent Prompt Routing機能はあるが、同一モデルファミリー内でしかできない
- 使える場合、ベースラインを設定してフォールバックモデルを設定する感じ？

Hikaru's notes

AIP-C01

SkillBuilder Official Practice Question set

サービス単位

Bedrock FM

AWS認定Generative AI Developer - Professional (AIP-C01)模擬試験問題集

Bedrockの設定値系

各論(1セット)

10

仮説・検証・判断のこと

11

12

13

16

18, 21

19

20

23

28

32

33

41

42

43

47

48

51、52

Approvedにしたらそれがデプロイ

56

57

58

61

各論（2セット）

AIサービス以外

間違えた問題だけ復習

このフォルダのページ一覧