Upgrade to Pro — share decks privately, control downloads, hide ads and more …

【AWS AIF対策】透明性と説明可能性

【AWS AIF対策】透明性と説明可能性

Avatar for 赤神青空

赤神青空 PRO

October 06, 2026

Video

More Decks by 赤神青空

Other Decks in Programming

Transcript

  1. ▪資料から外れた答えを見るのは文脈的接地チェック 前回のクイズの答えは「C」 前回のクイズ RAG の回答が、渡した資料に 書いていないことを答えてしまう。 Guardrails のどの機能で検出できる? 渡した資料 応答がこれに

    基づいているか 利⽤者の質問 応答が的を 射ているか 答えは C 今ココ おさらい A コンテンツフィルタ 有害な内容を⽌める B 拒否トピック 扱わせたくない話題を⽌める C ⽂脈的接地チェック 資料から外れた答えを⽌める D 機密情報フィルタ 個⼈情報を⽌める 2/13
  2. ▪どちらも責任あるAIの側面に入っている 説明可能性と透明性は、別のもの 説明可能性 透明性 Explainability Transparency 出⼒を理解して評価できる 関係者が納得して選べる 「なぜこの出⼒になったのか」が分かる 「AIを使っていること」「何ができないか」が分かる

    融資を断られた理由が分かれば、直せる AIだと気づかないまま使うことを防ぐ 説明可能性は「出⼒の理由」、透明性は「システムの素性」 どちらも AWS が挙げる責任あるAIの8つの側⾯に⼊っている(第14回 p ) 今ココ 2つの言葉 3/13
  3. ▪違いと、あとから説明を足すやり方 そのまま読めるモデル、中が見えないモデル そのまま読めるモデル 中が⾒えないモデル 線形回帰、決定⽊など 深層学習、⼤規模⾔語モデル 構造を⾒れば、なぜそうなるか分かる 重みを⾒ても、なぜかは分からない ただし表現できることが限られる そのぶん性能が⾼いことが多い

    interpretable complex 中が⾒えないモデルには、あとから説明の道具を付ける SHAP‧LIME — どの⼊⼒がどれだけ効いたかを、あとから推定する 説明の道具が「本当に分かりやすいか」は、実際の利⽤者で試す AWS は「混乱させていないか確かめること」と書いている 今ココ 2つの言葉 4/13
  4. ▪試験ガイドの「解釈可能性と性能を測る」 説明しやすさと性能は、引っ張り合う 説明 しやすさ ↑ 決定⽊ 線形回帰 この辺りは 取りにくい 深層学習

    ⼤規模⾔語モデル 性能(当たりやすさ)→ AWS の⾔い⽅ 説明が要るなら、まず 決定⽊や線形モデルを検討する 説明が得られる利点が、 精度の犠牲に⾒合うかを⽐べる 複雑なモデルしかないなら、 SHAP や LIME をあとから⾜す 「説明しやすさを取ると、精度を少し諦める」ことがある どちらが正しいではなく、⽤途ごとに⽐べて決める、というのが AWS の書き⽅ 試験ガイドの「解釈可能性と性能を測る」は、この⽐較のこと 今ココ トレードオフ 5/13
  5. ▪試験ガイドの「安全性と透明性のトレードオフ」 透明にすればするほど良い、ではない 透明にすればするほど良い、とは限らない 出しすぎると 出さなすぎると モデルの作りや弱点が外から分かる AIを使っていることに気づかれない 攻撃の⼿がかりになる 出⼒の確からしさが分からない 説明から学習データが推測されうる、という研究も

    問題が起きたとき追えない ちょうどよい⽔準を探す 信頼を得るのに⾜りるだけ開き、新しい弱点を作らない 何を公開して何を社内に留めるかは、決めて審査する 試験ガイドの「安全性と透明性のトレードオフ」は、この話 今ココ トレードオフ 6/13
  6. ▪試験ガイド透明性・説明可能性を見る道具 4.2 が例に挙げる3系統 透明性‧説明可能性の道具 Amazon SageMaker Model Cards ⾃分が作ったモデルの 素性を1か所に書き残す

    Amazon Bedrock Evaluations 出⼒を測って⽐べる(第13回) 試験ガイドの表記は Model Evaluations 試験ガイド 4.2 が例に挙げているのは、この3系統 オープンなモデル データ‧ライセンス 出⾃と使ってよい条件を ⾃分で確かめられる AWS ⾃⾝が出している AI Service Cards もある AWS のサービスやモデルの、想定する⽤途‧限界‧設計の考え⽅をまとめた⽂書 作る側が書くのが Model Card、AWS が書くのが Service Card 今ココ 道具 7/13
  7. ▪作る側が、モデルの素性を書き残す Amazon SageMaker Model Cards モデルの概要 想定する⽤途 リスクの格付け 何のモデルか、誰が作ったか どんな⽤途‧場⾯‧データに向くか

    向かない場⾯も書く unknown / low / medium / high の4段階 学習の詳細 評価の詳細 倫理上の考慮‧注意 ⽬的関数、学習データ、 ハイパーパラメータ 評価データと、指標の結果 気をつけること、推奨すること Amazon SageMaker Model Cards に書き残せること(主なもの) 状態は4つ 下書き∕レビュー待ち∕承認済み∕保管 直すと版が増える ただし承認状態の更新だけは版を増やさない 監査のときに「どういうモデルか」を⽰す書類として使う 今ココ 道具 8/13
  8. ▪いつ同意したことになるのか オープンなモデルとライセンス Bedrock のモデルのライセンスは、いつ同意したことになるか Marketplace の権限があれば モデルの利⽤は既定で有効 他社のモデルを 初めて呼び出した時点で そのライセンスに

    同意したことになる 先に中⾝を読んでから決めたいなら SCP や IAM でいったん⽌めておき、確認してから開ける オープンなモデルでも、使ってよい条件は⾃分で確かめる SageMaker JumpStart は「使うモデルのライセンスを必ず確認すること」と明記している Apache . 、OpenRAIL など、モデルごとに条件が違う。確認する責任は使う側にある モデルの出⾃と条件をたどれること⾃体が、透明性の材料になる 今ココ 道具 9/13
  9. ▪使う前・使っている間・使ったあと 説明できるAIの、人間中心の設計 利⽤者から⾒た時間の流れで考える 使う前 使っている間 何ができて何ができないかを 知らせておく AIが動いていることと、 途中の状況を⾒せる AIを使っていることを知らせる

    フィードバックの⼿段を⽤意する 重い判断には⼈が関わる AWS が繰り返し書いている3つ 使ったあと なぜその結果かを⽰し、 異議とフィードバックを受ける 影響を受ける⼈にも伝える 良い∕悪いのボタンでもよい 権利‧健康‧安全に関わる判断では、適切な監督を 出⼒をどう読めばいいかの案内も、あわせて⽤意する 確信度、効いた要素、判断の経路など。詳しさは相⼿に合わせる 今ココ 人間中心の設計 10/13
  10. ▪4つの目的と、このスライドの対応 試験ガイド 4.2 の地図 試験ガイド 4.2 の4つの⽬的と、このスライドの対応 透明なモデルと、そうでないモデルの違い そのまま読めるか、あとから説明を⾜すか p

    ‧p 透明性‧説明可能性を⾒る道具 Model Cards∕Bedrock Evaluations∕オープンなモデルとライセンス p 〜p 安全性と透明性のトレードオフ p ‧p 説明できるAIの⼈間中⼼設計 p 解釈可能性と性能を測る。出しすぎの害もある フィードバックの⼿段、AIの判断の透明性 第14回の 4.1 と合わせて、第4分野「責任あるAI」は⼀周 4.1 が「どんな偏りや危険があるか、どう⽌めるか」 4.2 が「それを外から確かめられる形にしておくか」 今ココ まとめ 11/13