Amazon Bedrockの自動推論チェックを検証！

Transcript

1. Amazon Bedrockの自動推論チェックを検証！
3. 今日お話しすること・しないこと お話しすること Amazon Bedrock のガードレールでの自動推論チェックの作成方法と機能 実際に使ってみた検証結果と実装体験 実運用に向けた知見と学び お話ししないこと 自動推論そのものの学問的説明 気になる方はAmazon Science Blogをご参照ください （https://www.amazon.science/research-areas/automated-reasoning）
4. 自動推論チェックとは？ 2025年8月6日に一般公開されたAmazon Bedrock Guardrailsの新 しいポリシー 何がすごい？ 最大99%の検証精度でハルシネーションを検出・抑止 数学的手法で応答の正確性をチェック 生成AIを使う上で皆様が最も気にされる正確性の問題に対するソリューション
5. なぜ自動推論チェックが必要？ 生成系AIの利用にはハルシネーションのリスクがある RAGなどの手法を用いても完全に防ぐことは難しい 従来の対策の限界 RAGだけでは「正しさの証明」は不足 従来のAmazon Bedrock Guardrailsでは有害なコンテンツは防げるものの、ハルシ ネーションの対策は難しい 解決策 → 「自動推論チェック」
6. Guardrails全体における、自動推論チェックの位置づ け フィルター種別 目的 自動推論チェック コンテンツフィルター 有害・過激・成人・ヘイト等 トピックフィルター 業務外領域や話題制限 機密情報フィルター PII/PHI/秘密情報のマスキング 単語フィルター 禁止語など 自動推論チェック 正しさの検証・ルール適合
7. 仕組み：どう動くのか？ 自動推論ポリシーの作成 ドキュメントから自動で作成してくれるため、組織のルール・前提・定義などの 既存ドキュメントが利用可能 実装 Guardrailsにポリシー追加し、bedrockのAPI呼び出し時にGuardrailsを指定すれば OK
8. 実際に試してみた：人事ポリシーデモ ポリシー例（人事規程風） 前提: 勤続年数・評価ランク・就業形態 ルール: 勤続3年以上 かつ ランクB以上 → 特別休暇可 テストケース 合致: 勤続4年・ランクA → 可 不一致: 勤続1年・ランクA → 不可
9. 設定手順①：ポリシー作成 Amazon Bedrock コンソールでの操作
10. 設定手順①：ポリシー作成 Amazon Bedrock コンソールでの操作 遷移先画面でポリシー名を定義し、使用するドキュメント（pdf or txt）をアップ ロードし、それに対する説明すれば記入すればOK！
11. 設定手順②：ポリシー内容確認 自動生成される3つの要素
12. 設定手順②：ポリシー内容確認 自動生成される3つの要素 変数（Variables） 元の自然言語ドキュメントに含まれる重要な概念を変数として定義 例：勤続年数、評価ランクなど、判定に使用する要素 ルール（Rules） ポリシー内の変数同士がどのように関連するかを定義 テキストをどのように評価するかのルール カスタム型（Types） 真偽値や数値以外のデータ型を定義
13. 設定手順③：Bedrock Guardrails への組み込み クロスリージョン推論の有効化（必須！）
14. 設定手順③：Bedrock Guardrails への組み込み 自動推論ポリシーを有効化し、作成したポリシーを選択する ここで指定したConfidenceが閾値になる
15. 設定手順④：ポリシーのテスト方法 2つのテストシナリオ作成方法 自動生成（推奨） 定義からシナリオを自動生成 ポリシー検証の最も簡単な方法 基本的にこちらが推奨される 手動作成 入力（質問）と出力（回答）のペアを設定
16. 設定手順④：ポリシーのテスト方法 2つのテストシナリオ作成方法（自動作成の例） 自動生成された内容を確認し、 / をクリックする
17. 設定手順④：ポリシーのテスト方法 テストシナリオを用いた検証
18. 設定手順④：ポリシーのテスト方法 テストシナリオを用いた検証（結果）
19. 実装：2つのAPI（js） Converse API const command = new ConverseCommand({ modelId, messages: [{ role: 'user', content: [{ text: userMessage }] }], guardrailConfig: { guardrailIdentifier, # 作成したガードレールのID guardrailVersion } }); 特徴: ガードレールを適用した応答の生成
20. 実装：2つのAPI（js） ApplyGuardrail API const apply = new ApplyGuardrailCommand({ guardrailIdentifier, 　# 作成したガードレールのID guardrailVersion, source: 'OUTPUT', content: [{ text: { text: answer } }], outputScope: 'FULL' }); 特徴: ガードレールで評価した結果を取得。
21. レスポンスの構造と評価結果 ApplyGuardrailのレスポンス構造（抜粋） assessments.automatedReasoningPolicy.findings: 自動推論チェックの評価結果 評価結果の種類（抜粋） valid : ポリシーに合致 invalid : ポリシーに違反 translationAmbiguous : 複数の解釈が可能で評価が曖昧 satisfiable : コンテキスト不足で複数解釈が可能
22. 実装で直面した問題と解決 問題：valid/invalid にならない... vvalid/invalid ではなく translationAmbiguous が多発して困りました 生成されたテキスト例（英語→日本語に翻訳済み） はい、あなたは特別休暇（特休）の取得資格があります。以下に詳しく説明させていただきます。 人事ポリシーのルールR1 （特別休暇付与条件）に基づいて判断すると、以下の3 つの条件を全て確認する必要があります： ... ... ... したがって、全ての条件（勤続年数：3 年、評価ランク：A 、就業形態：正社員）を満たしているため、特別休暇を取得する資格があります。
23. 実装で直面した問題と解決 なぜtranslationAmbiguous になるのか？ 文章が長くなると複数解釈が可能になり、評価が曖昧になる 特に、一文に複数のルール要素が含まれると発生 例： 「勤続3年、評価A、契約社員の場合...」→ 3つのルール要素が混在してる
24. 実装で直面した問題と解決 解決策：モデル出力の決定性を上げてみた！ 1. temperature を 0.1 に設定 2. JSON形式で出力させた 改善後のテキスト生成例： { "input": { "tenureYears": 3, # 勤続年数 "performanceRating": "A", # 評価ランク "employmentType": "CONTRACT" # 勤務形態 }, "output": { "isSpecialLeaveEligible": true # 判定結果 } } → valid/invalid と評価されるようになった！
25. まとめ 既存ドキュメントを用いることが可能なので、自動推論チェックポリシーは比較 的簡単に構築可能 適切な評価を行うためにはルールの調整や評価対象テキストの出力調整が必須
26. ご清聴ありがとうございました！