re:Invent 2024: AWSとCiscoが語るResponsible AIの実践
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Responsible AI: From theory to practice with AWS (AIM210)
この動画では、AWSのAI/ML Worldwide Tech LeaderのDenis V. BatalovとCisco Systems, Inc.のDirector of Software EngineeringのMatt FreyがResponsible AIについて解説しています。Generative AIの課題としてHallucinationや品質、Toxicity、安全性などを挙げ、それらへの対策として8つの柱からなるResponsible AIの考え方を説明します。特にAmazon BedrockやSageMaker Clarifyなどのツールを活用したBiasの検出や、Explainabilityの実現方法、さらにCiscoにおけるResponsible AIの実践例として、AIモデルの評価プロセスやガードレールの実装方法など、具体的な取り組みが紹介されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Denis V. Batalovによる自己紹介とResponsible AIの背景
私はDenis V. Batalovと申します。Seattleを拠点としています。私はAI/MLのWorldwide Tech Leaderを務めており、実質的には、AWSのお客様がAI/MLアプリケーションを構築するのを支援する何百人ものAI/MLスペシャリストの業務をまとめる役割を担っています。さらに、Generative AIが登場する以前から、ここ数年はField部門のResponsible AIを率いてきました。この分野は科学的な観点からも、エンジニアリングの観点からも、そして一般的にこのトピックにどのようにアプローチするかという点からも、追加の取り組みが必要だということは明確でした。
現在、私はResponsible AIを科学的なモデル評価の重要な考慮事項の一つとして扱うチームも率いています。個人的にも、ISOやヨーロッパの同等の標準化活動にも参加し、説明可能性の基準や透明性、バイアスなどの分野に貢献してきました。本日は、Cisco Systems, Inc.のDirector of Software EngineeringであるMatt Freyが同席しており、後ほど登壇してCiscoのResponsible AIの取り組みについてお話しいただく予定です。
Generative AIがもたらす新たな課題と考慮事項
明らかに、Generative AIは大きな可能性を示しています。機械学習における能力の大きな飛躍です。しかし、既存の課題の一部がまだ残っている中で、新たなリスクや課題も数多く見られます。これらについても触れていきたいと思います。Generative AIには、全く新しい問題が山積しています。その中でも特に目立つのがHallucinationの問題です。指の本数が間違っている画像などが広く知られていますね。この点については確かに大きな改善が見られましたが、数字が正しい場合でも、時々問題が発生することがあります。
なぜGenerative AIにこれほど多くの問題があるのでしょうか。品質はその一つに過ぎません。従来のMLとGenerative AIの重要な違いの一つは、Foundation Modelが幅広く、多様なユースケースに対応できることです。もう一つの違いは、既製のモデルを文字通り取り出して、さまざまなユースケースに適用できるようになったことです。一方、従来のMLでは、例えば消費者向け融資の場合、専門的なトレーニングデータを使用し、その特定の目的だけのためのモデルを構築します。そのため、関連するリスクを理解したり評価したりすることがはるかに容易です。
ニュースで見てきたように、リスクは数多く存在します。例えば、弁護士が判例を検索する際、これらのGenerativeツールを使用するのは非常に簡単です。しかし、Hallucinationが発生し、驚くべきことに一度ではなく、実際に何度も起こっています。 時には、Hallucinationだけでなく、全体的な品質の問題もあります。例えば、Chatbotがポリシーを誤って解釈した場合、ユーザーが誤った想定や判断をしてしまう可能性があります。これらは非常にコストのかかる問題となる可能性があります。
より最近の例として、医療サマリーのAI文字起こしが挙げられます。ケアチームが過去のやり取りの記録を確認する際に、ハルシネーションが混入すると非常に危険な状況になり得ることは想像に難くありません。私たちの多くは、こうした文字起こしの誤りはすぐに見分けられます。というのも、明らかな間違いであることが多いからです。しかし、時にはそれを見分けるのが非常に難しく、ミスが発生する可能性があります。一方で、ハルシネーションが実際に歓迎される用途もあります。これは明らかにその一例で、むしろハルシネーションが望ましいケースですね。
ここで、Generative AIに関する新たなリスクと課題について話しましょう。これまでハルシネーション、事実の正確性、そして出力の質の高さに関連する真実性について触れてきましたが、次は知的財産とデータプライバシーについて詳しく見ていきます。
Toxicityと安全性も新たな考慮事項です。というのも、生成される言語に、個人や特定のグループに向けられた憎悪表現や、脅迫的、侮辱的、あるいは軽蔑的な内容が含まれる可能性があるからです。この基盤を適切に整えることは非常に重要です。ただし、具体的なユースケースによっては、ある程度の許容が必要な場合もあります。例えば、ある人物の発言を引用する場合や、100年前に書かれた本の一節で、当時とは異なる表現が使用されているような場合です。これは事実に基づくものなので、このような例や状況では許容されるべきでしょう。もちろん、これらのChatbotではスコープ外とすべき質問もあります。これについては、後ほど制限トピックとして取り上げます。
Responsible AIの8つの柱とリスクアセスメント
Responsible AIについてよく耳にしますが、それが具体的に何を指し、どのように定義されるのかが不明確な場合があります。組織によって定義が若干異なることもあります。私たちの考え方では、Responsible AIは8つの柱から成り立っています：制御可能性、プライバシーとセキュリティ、安全性、Toxicity、バイアスと公平性、真実性と堅牢性、説明可能性、透明性、そしてガバナンスです。お気づきかもしれませんが、このリストにサステナビリティは含まれていません。これは通常、私たちにとってはResponsible AIの考慮事項とは別に、AWS全体の課題として扱われているためです。ただし、多くの場合、Responsible AIの考慮事項に含まれることもあります。ここでの私の意図は、これらの柱のいくつかを取り上げ、それに対応する具体的なツールや技術について説明することです。
まず、AIリスクとアセスメントについて話したいと思います。というのも、EU AI Actなどの新しい規制の多くは、まずリスクに着目しているからです。システムが禁止されているのか、ハイリスクなのか、あるいは低リスクなのかを見極めましょう。組織内でこの能力や機能を構築することは実際に重要です。理想的には、プロジェクトの構築を始める前にリスク評価を行うべきです。
私たちは、特に確立されたリスク管理プロセスがまだない、あるいはAIに関してどのように進めればよいかわからないお客様のサポートを始めています。これまでに何度かワークショップを実施してきました。実は本日も、Caesar's Forum（Palace Forumではありません）で午後4時から、仮想的なアプリケーションやユースケースを用いてこのようなリスクアセスメントのプロセスを解説するChalk Talkのセッションが再度開催されます。まずは何かから始めることが重要です。通常は、AIシステムに関わるすべてのステークホルダーを特定することから始めます。
次に、ユースケースに応じて異なる深刻度レベルの定義や、有害事象の発生可能性とその重大性を把握します。そして、起こりうる有害事象を列挙していきます。この段階では、多様な視点を持つ様々な人々を議論に参加させることが望ましいでしょう。ツールを活用することで、Toxicityスコアなどを通じて、これらの状況の発生可能性を評価することができます。 昨年、リスクアセスメントに関する最初のChalk Talkを開催し、ブログ記事も公開しました。これは非常に重要な取り組みの第一歩となるため、私たちは引き続きお客様のサポートを行っています。
公平性とバイアス：Generative AIにおける新たな課題
それでは、公平性とバイアスについて見ていきましょう。実は、これは私の最も好きなトピックで、おそらく2時間くらいは簡単に話せるテーマです。
従来型の機械学習やデシジョンメイキングシステムにおいてバイアスを評価したり検出したりする場合、適切なデータさえあれば、技術的には解決済みの問題と言えます。 実際、Amazon SageMaker Clarifyには、かなり前からバイアス検出ライブラリが搭載されています。21種類のバイアス指標をサポートしており、これらの指標の意味を説明したホワイトペーパーも用意されています。このライブラリはSageMakerに統合されていますが、実質的にはオープンソースライブラリなので、使い方を試してみたい場合は自分のラップトップで実行することもできます。
ここでの課題の一つは、なぜ21もの異なる指標が必要なのかということです。興味深いことに、公平性には単一の定義や基準が存在しません。実際にはいくつかの定義があり、課題は多くの場合、技術面ではなく、ある定義の公平性を追求するという決定を下し、それに納得することにあります。そうすることで、別の基準では不公平になる可能性があります。この選択に納得する必要があります。なぜなら、いわゆる「ただ飯」はないからです - 選択を行う必要があり、多くの場合、精度と公平性のトレードオフを考慮しなければなりません。
公平性の基準を決めたら、その後は、Pre-trainingデータに対してであれ、モデルの学習後であれ、どのようなバイアス指標が適切かを判断することができます。 私たちは、この判断を支援するためのブログ記事を公開しました。目指す公平性の基準に応じて、どのような指標をデフォルトとして選ぶべきかについて解説しています。技術的な観点では解決済みと申し上げましたが、ここには他にも多くの考慮すべき点があります。例えば、多くの公平性指標は本質的にグループ公平性の指標であり、これは特定の人口統計グループに対する公平性を最適化することを意味します。その結果、グループ全体としては公平になっても、そのグループの特定のメンバーに対しては不公平になる可能性があり、これは少し奇妙な状況です。
実際、ほとんどの法律は、様々な属性に基づいて個人を差別することを禁止する形で制定されています。また、Simpsonのパラドックスなど、他にも多くの問題がありますが、これらの問題があるからといって進歩を止めるべきではありません。どこかから始めて、結果を確認し、そこから前進していくべきです。興味深い質問は、これが Generative AIとどのように関連するかということです。なぜなら、私は意思決定システムについて話してきたからです。もう一つの問題は、例えばバイアスを測定したい場合、特定の個人の人口統計学的属性を知る必要があるということです。人種に着目する場合、多くのケースでは、ユーザーや顧客に関するそのような情報を収集することが許可されていないため、そのデータを持っていません。
これは、その情報を推定する方法やデータを取得する方法を見つける必要がある問題の一部です。実際、EU AI Actでは、測定目的に限り（もちろん他の用途ではなく）、機密属性の収集を特別に許可する規定がすでに含まれています。Generative AIのケースに話を戻すと、ここで強調したいことが一つあります。Chatbotの言葉遣いが決して不快感を与えないようにすることは明らかに基本的な要件ですが、業界が公平性についてより成果ベースの評価に移行することを期待しています。これは、これらのGenerativeシステムでも全く同じ方法で可能です。
システムが意思決定において何らかのバイアスを持っているかどうかを知りたいのです。この人は返金を受けられたのか？あの人はローンの承認を得られたのか？それが成果です。これは依然として意思決定であり、測定可能で、これに従ってシステムがどのように機能しているかを把握することができます。
Explainabilityと透明性：AIシステムの信頼性向上への取り組み
次に、Explainabilityという興味深いトピックに移りましょう。これはTransparencyと混同しないことが重要です。Explainabilityは、機械学習モデルが実際にどのようにしてその出力に到達したかということに関するものです。これは、AIシステムが特定のFoundation Modelや特定のアルゴリズムに基づいているということを理解することとは異なります。 従来の機械学習に関しては、標準的なアプローチは常にModel Agnosticでした。これは、内部のモデルが何であるかに関係なく、入力を少し変化させて、その結果として出力がどの程度影響を受けるかを見るという便利な方法です。この場合、摂動が出力にどのように影響するかを観察することで、この不透明なシステムがどのように動作しているかについての精神モデルを構築しようとすることができます。
後ほど具体例をお見せしますが、ここではAmazon SageMaker Canvasのスクリーンショットを使って、この計算がどのように行われたかをご説明します。この説明可能性はSageMaker Clarifyにも組み込まれています。これは、大腸がんの5年生存率に関する標準的な指標のモデルです。モデルのグローバルな説明可能性を高レベルで見ると、特徴量の重要度の観点から、がんのステージが最も重要な属性であることがわかります。次に診断時の年齢が続き、以下同様です。年齢の分布を見ると、残念ながら、X軸上で年齢が高くなるほど、5年以上生存する確率が低くなることがわかります。これは80代、90代になると右下に向かって低下していきます。また、個々の予測の説明可能性も確認できます。この場合、上部にPredictボタンがあり、この特定の患者さんについては、判断の主な理由がステージではなく、年齢や他の要因である可能性があることもわかります。
これは従来の機械学習の例ですが、このアプローチは生成AIシステムを分類に使用する場合にも適用できます。分類は生成AIシステムでより効果的に行える一般的なユースケースの1つです。 例えば、カスタマーレビューの感情分析などのテキスト分類が挙げられます。この場合、個々の単語や文、フレーズを特徴量として使用し、これらの特徴量の一部を除去することで入力を変化させ、その結果のレビューがポジティブかネガティブかを分類できるかを確認します。これにより、緑や濃い緑で示された部分が一方向の判断を導き、赤で示された部分が反対方向の判断を導くということがわかります。
興味深いことに、画像分類でも同様のアプローチが可能です。これは非常に有名な研究論文で、HuskyとWolfを区別するモデルを構築したのですが、うまく機能していませんでした。多くのHuskyがWolfと誤分類され、その理由を理解しようとしていました。LIMEと呼ばれるこのアプローチにより、モデルが動物自体ではなく、背景の雪を見て判断を下していることが明らかになりました。トレーニングデータセットには雪を背景にしたWolfの写真が多かったため、雪が写っている画像をWolfと分類していたのです。
これはSageMaker Clarifyでもサポートされており、ここではピラミッドの画像を例に挙げています。これがピラミッドであると分類された場合、その判断に影響を与えている画像の部分を特定するために、個々のピクセルを特徴量として見る方法もありますが、それとは異なるアプローチを取ります。スーパーピクセルと呼ばれる、画像を分割した領域全体を見ます。これらのセグメントの一部をランダムなノイズに置き換え、そのような画像の変形バージョンを多数作成して、最終的な予測がどのように影響を受けるかを観察し、ヒートマップを作成します。この例では、ピラミッドの側面が暗色または青色で示されており、これらの部分がこれがピラミッドであるという予測を支持していることがわかります。この場合、アルゴリズムが私たちの期待通りの方法で機能していることを理解するのに役立ちます。
生成系AIの場合はどうでしょうか？生成系の場合は少し難しくなります。同じモデル非依存のShapley値やSHAPアルゴリズム（これはSageMaker Clarifyで使用されているKernel SHAPのことですが、言及し忘れていました）を使って、入力に基づく特定の単語の生成を予測することはできますが、通常は単一の単語の生成について気にすることはありません。本当に知りたいのは、なぜその完全な文章が生成されたのかということです。分類の場合、モデルにその判断に至った理由を尋ねるというテクニックがあります。この場合、これは特定のメールであり、そのため「その他の製品使用に関する質問」というカテゴリーに分類できると判断します。これは実際に正しい判断なのですが、ご想像の通り、説明自体も誤った情報（Hallucination）を含む可能性があるため、確実な方法として頼ることはできません。
エージェントアーキテクチャで見られる他のアプローチとして、これらのエージェントがChain of ThoughtやReActパラダイム、あるいはTree of Thoughtなどを通じて行動計画を立てる際、その行動計画自体が一種の説明となります。それを記録して後で監査し、エージェントが特定の方法で何かを行った理由を確認することができます。
ここで最後に一つ付け加えたいことがあります。Generative AIにおいて、Explainabilityは依然として活発な研究分野であり、使いやすい既製のツールを見つけることは困難です。いくつかのアプローチでは、Transformerアーキテクチャやモデルの内部を調べ、特定の概念が提示されたときにニューラルネットワークのどの部分が実際に反応するのかを理解しようとしています。しかし、あるモデルから別のモデルに切り替えた際に、それまでの手法が機能しなくなるようなモデル非依存の状況では、このアプローチを適用するのが難しくなります。
AIシステムの制御とプライバシー保護：Amazon Bedrockの事例
AIシステムのBias、Fairness、Explainabilityが重要視される理由は、これらが不透明で非常に複雑で理解が困難だと認識されているからです。もしこれらが正しく機能していなければ、不公平さが大規模に拡大される可能性があります。これは確実に防ぎたいことですが、AIシステムだけではないということを指摘しておきたいと思います。「この身長以上でないとこの乗り物に乗れません」というような、非常にシンプルな意思決定システムもあります。これはif-thenルールという非常にシンプルな判断システムです。しかし、誰がその基準を決めたのか、どのようなトレードオフが考慮されたのかについての説明性はどこにあるのでしょうか？明らかに安全性への配慮やセキュリティ上の考慮事項がありますが、おそらくコストも関係しているでしょう。最終製品の安全性にもう少し投資していれば、より小さな子供たちも乗れるようになったかもしれませんが、それは分かりませんし、その情報にアクセスすることもできません。興味深い考察として、組織や政府、法制度が意思決定を行う場合、私たちが話し合ったBiasに関するテクノロジーの多くは、実際にこれらのシステムが異なる人口統計グループに対してどれだけ公平であるかを評価するために使用できるかもしれません。
もう一つの重要な側面は、先ほど議論したControllabilityです。これらのシステムをモニタリングする必要があり、これはObservabilityに関連します。今週初め、Cloud Ops分野の同僚とGenerative AIのObservabilityについて話し合い、その内容は現在YouTubeで公開されています。
AIシステムの制御に関して、興味深い機能が利用可能です。例えば、Amazon Bedrockエージェントでは、アクショングループが定義されており、エージェントがそのアクションを実行することを選択した場合、これらのアクションの中には冪等性がなく、何かが削除されるなどの重大な副作用を持つものがあります。エージェントがこのアクションを選択した際、ユーザーが介入してそのアクションを許可または拒否することができます。これはAmazon Bedrockエージェントの設定で構成可能です。
プライバシーとセキュリティは明らかに非常に重要なトピックです。Amazon Bedrockについて、皆様に改めてお伝えしたいのは、お客様が常にデータを管理できることを明確にお約束しているということです。つまり、私たちはお客様のデータを使って、私たちのモデルやBedrockで利用可能なサードパーティのモデルを改善することは一切ありません。実際、プロンプトや生成結果さえも保存していません。Bedrockの初期バージョンでは、ChatGPTのように特定のモデルをテストできるプレイグラウンドがコンソールにあり、利便性のためにプロンプトと生成結果の履歴を記録していました。これは本番利用ではなくプレイグラウンドだけの機能でしたが、データを保存しているように見えてメッセージが薄まってしまうため、お客様の混乱を避けるためにその機能を削除しました。
お客様が特定のリージョンを選択して操作を行うと、データはシステムとモデルを通じて生成結果を出力する際も、そのリージョンから出ることはありません。Bedrockにはクロスリージョン推論という機能もありますが、これはデフォルトではオフになっています。キャパシティの問題やスロットリングの場合に別のリージョンを使用できるようにするには、明示的に設定する必要があります。これらはすべてデフォルトでは発生しません。
また、標準的なセキュリティ機能も提供しています。転送中の暗号化と保存時の暗号化を提供しています。カスタムモデルを作成する際、そのカスタムモデルの作成に使用されたデータはどこにも保存されません。最初にお客様自身のS3バケットにデータを置き、トレーニングに使用され、トレーニングが完了すると、そのデータは不要になるため、お好きなように処理していただけます。このようにカスタム作成されたモデルは、作成したお客様のみがアクセス可能で、他の誰もアクセスできません。
アクセス管理も可能で、さらにAmazon CloudWatchを使用した使用状況の追跡、問題のトラブルシューティング、AWS CloudTrailによるAPI活動のモニタリングも可能です。また、様々なコンプライアンス体制にも対応しています。
ここからは、Generative AIに関する重要な追加の考慮事項についてお話しします。これまで安全性、Toxicity、Veracity、そしてRobustnessについて説明してきました。VeracityとRobustnessは、入力に小さな変更や摂動が加えられても、出力に大きな変動が生じないようにすることが重要です。
CiscoにおけるResponsible AIの取り組み：Matt Freyの視点
システムがそのような変更に対して適切に対応できることが求められます。 モデルを選択する際に注意すべき点の1つは、すでにさまざまな保護機能が組み込まれているということです。モデル自体に多くのガードレールが組み込まれています。通常、Temperature、Top P、Top Kなどのハイパーパラメータを除いて、これらを意味のある方法で設定変更することはできません。
これらのモデルに組み込まれている内部的なガードレールを理解することが重要です。例えば、Titan Image Generatorで「Baby Yoda」の画像生成を依頼すると、著作権で保護されているイメージであることを認識して、プロンプトを拒否します。さらに、「尖った耳を持つ小さな緑色の動物で、袋を着ている」というように言い換えてトリックを試みても、内部的にBaby Yodaに似たものが生成されたとしても、別のチェックが働いて出力を防止します。このような仕組みが働いていることを理解しておく必要があります。
これらのガードレールの評価とその仕組みを理解する一つの方法が、モデル評価です。昨年、SageMaker Clarifyでファンデーションモデルの評価機能をリリースしました。また、FME Valというオープンソースライブラリもリリースし、同じ技術がAmazon Bedrockの評価機能にも組み込まれています。ここでは、標準的な評価データセットを使用して、自動化可能な指標の自動評価を行うことができます。また、出力の創造性など、自動化が難しい特性や指標については、人による評価を選択することもできます。
デフォルトのデータセットから始めることはできますが、真の価値は、ユースケースに基づいて独自のカスタム評価データセットを作成することにあります。公開されたデータセットで最適化・トレーニングされ、良好なパフォーマンスを示すモデルのリーダーボードに頼るのではなく、特定のニーズに対してモデルがどのように動作するかを見極めるには、これが唯一の方法です。重要なのは、独自のデータセットを持ち、それを慎重に管理することです。 最近、Bedrockのモデル評価機能に新しい機能が追加されました。特に、LLM as a Judgeという興味深い機能がプレビューで利用可能になりました。
人間による評価を行う場合、複数の人間が同じ出力を見て判断を下すため、良い結果が得られる可能性がありますが、コストがかかります。大規模に評価を行いたい場合は、LLMを評価者として使用することが良い出発点となるでしょう。例えば、左側に2つのモデルからのResponse 1とResponse 2があり、右側にGround Truthがあるとします。人間がこれを見て、どちらかを好ましいと判断し、スケールで評価します。最終的に、モデルAとモデルBのどちらがより良いパフォーマンスを示したかを統計的に示すことができます。
評価や組み込みの制御は素晴らしいものですが、ユースケースに特化したカスタマイズされたGuardrailsをアプリケーションに追加したい場合もあるでしょう。また、あるモデルから別のモデルに切り替えても、Guardrailsは一貫して機能させたいと考えるかもしれません。そのため、私たちはAmazon Bedrock Guardrailsをローンチしました。これは以前から存在していましたが、re:Inventの直前に発表された最新の機能として、スタンドアローンAPIとして使用できるようになりました。つまり、必ずしもAmazon Bedrockのモデルだけでなく、AWS内外の任意のモデルにこれらのGuardrailsをAPIを通じて適用できるようになったのです。
re:Inventでの興味深い進展には、2つの重要なローンチが含まれています。1つは画像フィルタリングに関するもので、テキストだけでなく画像もフィルタリングできるようになりました。もう1つは、基調講演で発表されたAutomated Reasoningチェックで、これは非常に大きな進展です。なぜなら、モデルのランダム性に頼って正しい結果を生成するのではなく、推論チェックを適用できるようになったからです。これについては後ほど詳しく説明します。
フィルターの定義方法はこのようになっています。PromptとCompletionに対して、ヘイトスピーチ、侮辱、性的コンテンツ、暴力、不正行為などのチェックを行うことができます。これらは画像に対しても設定可能で、さらに既知のPrompt攻撃を自動的に検出する機能も備えています。また、Denied Topicsがあり、30種類の異なる禁止トピックを設定できます。これは実質的に範囲外の会話を指定するもので、例えばChatbotに政治や投資アドバイスについて話させたくない場合などに使用します。結局のところ、お客様のためにChatbotを構築し、その費用を負担しているのですから、完全に無関係な話題や、ブランドにそぐわない内容について話させたくないものです。
これらは英語でプログラミングし、自然言語で定義します。実際に見てみると非常に興味深いものです。例を提供すると、LLMの分類器がこれらの判断を行います。PII検出機能があり、特殊なPIIがある場合は、正規表現を使用してより正確に定義することもできます。標準リストを持つProfanityフィルターがあり、ブロックしたい独自の単語を追加することもできます。Automated Reasoningチェックのローンチ以前に、非常に重要な機能である文脈的な根拠付けと関連性チェックをローンチしました。
これは幻覚（Hallucination）に対する最初の防衛線です。RAGアプリケーションでは、コンテキストを構築し、そのコンテキストを取得し、このClassifierがモデルによって生成された出力が実際にそのコンテキストに基づいているかどうかをチェックします。さらに、出力が質問に対して関連性があるかどうかもチェックできます。コンテキストに基づいていても関連性がない場合もあり、これら両方の状況を検出する必要があります。この後でAutomated Reasoningについてもう少し詳しくお話しします。
ここで最後に話したいのは透明性についてです。ここには様々な考慮事項があります。その1つは、出力や生成されたコンテンツが実際にAIによって生成されたものであることを知ることです。AmazonはC2PAステアリング委員会に参加し、Amazon Titan Image GeneratorやAmazon Nova Canvasモデル（今週初めに発表されたもの）などの画像生成モデルには、すべて目に見えない透かしが画像に含まれています。画像を少し切り取っても、その透かしは残っており、AIによって生成されたものだと検出できます。しかし、より重要な防御として、メタデータに実際のクレデンシャルデジタル署名が付加されています。ツールを使用して、この画像が実際にこのモデルによって生成されたことを確認できます。また、広く一般に、AWS Service Cardsと呼ばれる透明性に関する声明を公開しており、そこではモデルがどのように訓練されたかについて説明しています。
また、モデルがどのようにベンチマークされ、何に使用すべきで、何に使用すべきでないかについても説明しています。Amazon Novaモデルについては、これらの詳細についてさらに深く掘り下げた技術レポートを別途用意しています。通常、お客様は自社でのモデル使用を承認するための追加情報を求めてこられます。私たちは追加の質問にお答えし、規制状況に対応するためにお客様に喜んで情報を提供しています。
CiscoのResponsible AI実践：評価プロセスと具体的な事例
ここで、Mattをステージにお迎えしたいと思います。彼がCiscoのResponsible AIの取り組みについてお話しします。ありがとうございます、Dennis。私がもう一人の講演者です。Dennisが言及したResponsible AIツールの多くの側面が、Ciscoのプロセスにも採用されており、私たちのビジネスにおけるAIへのアプローチに適用されています。まず、ある声明から始めたいと思います。これに対して幻覚検出をしてみましょう。「Ciscoは橋を架ける事業を行っている」- これは真実でしょうか、それとも偽でしょうか？おそらくコンテキストが十分ではありませんね。修辞的には、はい、Ciscoのビジョンは実際に人々をつなぐ橋を架けることです。人々がつながるとき、そのつながりを通じて素晴らしいことが起こると私たちは信じています。
Ciscoは、世界中の人々を結ぶ接続性を確保するネットワークソリューションで最もよく知られています。Ciscoのコラボレーショングループは、Webex SuiteとContact Center Suiteを通じて、社内のチームや外部の顧客との接続性を提供するソフトウェアスイートを提供しています。私はCollab AIで働いています。これはCisco Collaboration Business Unitの中心的なグループで、製品チームがAI機能を自社製品に統合したい場合にAI機能を提供しています。私たちは、顧客の問題を解決したいProduct Manager、AIツールと機能を活用してそれらの問題を解決したいエンジニアリングチーム、そしてAI機能の開発を管理する中央のCiscoポリシーの交差点に位置しています。私の役割では、Cisco内でのResponsible AIの働きを最前線で見ることができます。
これらは私のチームが関わっている領域の一部です。Contact Center、会議や通話、メッセージングなどのチーム間のコミュニケーションを担うWebex Suite、そしてオフィスでの顧客体験領域におけるAI機能の構築をサポートしています。また、会議室でConference Hardwareを使用する場合、それらはCiscoのデバイスですが、私たちはそれらで動作するAIモデルの開発と展開も行っています。これらについては後ほど詳しくご説明します。
まず、私たちのResponsible AIの取り組みがどのように始まったかについてお話ししたいと思います。多くの方にとって馴染みのある話かもしれません。Ciscoは他の多くの企業と同様に、ChatGPTがリリースされた際、社内のプロセスやワークフローを整備し、ビジネスにおけるこれらの製品の調達や使用方法を決定する間、Generative AIモデルや製品へのアクセスを制限しました。Generative AI以前からResponsible AIのワークフローは整備されていましたが、Generative AIの急速な普及とその範囲の広さは、私たちが取り組まなければならない課題をもたらしました。
Cisco全体で、同じモデルに対しても異なる目的で異なるタイプのアクセスが必要とされていました。社内ワークフローにLarge Language Modelを適用したい人もいれば、これらのAIの進歩を活用して顧客向け製品に組み込みたい人もいました。また、Ciscoの研究部門では、これらの問題が解決するまでの間、以前のバージョンの言語モデルを使用して研究を継続したいと考えていました。これらの異なるニーズに責任を持って対応するには、Legal、Privacy、Procurement、ITなど、これまであまり密接に協力する必要のなかったグループ間の緊密な連携が必要でした。
この連携は、Engineering、Marketing、Sales部門にも及び、すべての部門がこの問題に関わっていました。ビジネスの異なる部門のニーズを理解するために、中央チームを結成する必要がありました。問題の一部は、これらのグループの多くがAI技術の経験がなく、誤解が生じていたことでした。
ここで伝えたいことがあるとすれば、それは教育の重要性です。Responsible AIのポリシーを策定し始める際には、ある程度の教育が必要です。機械学習の仕組みや微積分の詳細を知る必要はありませんが、推論のために既製のモデルを使用する場合の違いを理解することが重要です。推論だけを実行している場合、そのモデルは学習していないことを理解してください。モデルの使用方法には、Training、Evaluation、Inferenceなど、異なる方法があります。ポリシーを決定する人々は、これらの技術の使用方法の違いと、それが顧客データ、データの安全な使用方法、またはこれらのシステムの使用にどのような影響を与えるかを理解する必要があります。
現在、Ciscoでは3つの主要なAIカテゴリーを評価するための確立されたプロセスがあります。1つ目は、ベンダーがAI機能を追加しているCiscoで使用する製品やサービスです。これらがCiscoでの使用に適しているかを判断する適切な方法が必要です。2つ目は社内のユースケースで、ドキュメントを簡単に検索できるようにするボットの構築や、社内ワークフローの効率化などです。3つ目は、顧客に提供している製品にAI機能を統合するケースです。私たちのチームがプロダクトチームと協力してAI機能を統合しているCollaboration事業部で最も経験があるため、ここではこの3つ目のユースケースに焦点を当てます。
私は、CiscoのResponsible AIプログラムを、ユーザーやCiscoの従業員とAIを結ぶ架け橋のようなものと考えています。安全、セキュア、そして倫理的にそれを実現するにはどうすればよいのでしょうか？評価すべき3つの要素があります：基盤、インフラストラクチャ、そしてエンドツーエンドのユーザー体験です - いわば橋の道路部分です。まず、基盤について見ていきましょう。これらは、その上に構築されるすべてのものを支える機械学習モデルそのものです。これらのモデルの一部は社内で開発し、一部はサードパーティの商用ベンダーから調達し、そして一部はダウンロードして使用できるオープンソースのモデルです。
私のチームは、自然言語に関する幅広い課題に取り組んでいます。これらには、LLMや特定のケースで使用する他の言語分類器などの言語モデルを使用しています。Webexミーティングで使用するComputer Visionモデルもあります。私のチームは、背景のぼかし、ミーティング中のジェスチャー認識、AIによる照明調整などの機能を提供しています。また、オーディオや音声のモデルにも取り組んでいます。Webex Suiteの私のお気に入り機能の1つが背景ノイズ除去です - 3人の子供と犬がいる家庭なので、この機能には感謝しています。すべてのNLP機能は、ASR（Automatic Speech Recognition）と呼ばれる音声モデルによって支えられています。これらは音声からテキストへの文字起こしを処理し、その後、NLPモデルでさらに処理することができます。
モデルを評価する際には、いくつかの異なる側面を検討する必要があります。その1つが、モデルの使用目的と評価です。モデルがなぜ開発されたのか、どのような問題を解決しようとしているのか、何を分類しようとしているのかを理解する必要があります。モデルが開発された理由を理解し、トレーニングデータのソースを理解することが重要です。社内で開発したモデルの場合、使用したトレーニングデータを把握しているため、これは比較的簡単です。外部のモデルはより難しく、商用ベンダーやオープンソースのモデルを使用する場合、それらの企業と連携してアセスメントを実施し、データの調達方法が倫理的で合法的であり、適切にアノテーションされているかをより深く理解するためのプロセスがあります。
既知のバイアスやエッジケースが重要なのは、すべてのモデルが統計的なものだからです。100%正確に処理できるわけではないので、それを知っておく必要があります - そのようなモデルを使用できないということではなく、その限界を理解するためです。
これらのモデルをどのような場面で適切に使用できるのか、そのエッジケースを理解する必要があります。例えば、一部の小規模なLarge Language Modelには、単語を繰り返し表示する傾向があります。インターネット上のデータで学習されているため、時にはあまり適切でない言葉を出力することもあります。私たちはこの振る舞いを理解し、文書化し、ユースケースにおいて認識しておく必要があります。さらに、ライセンスと法的契約も確認する必要があります。サードパーティベンダーの場合はモデルの使用について交渉が必要であり、オープンソースモデルの場合は、社内開発と商用利用の両方に適したライセンス条件を理解する必要があります。
次に、モデルを取り巻くプラットフォームと呼ぶべきベンダー評価に移ります。モデルの使用方法にはいくつかの異なるアプローチがあります。自社でホストするものもあれば、Amazon Bedrockのようなマネージドソリューションを利用するものもあります。Amazon SageMakerを使用すると、モデルの実行場所や設定をより詳細に制御できます。私たちのチームでは、インフラを完全に自社で管理し、GPUを立ち上げ、モデルをデプロイして運用する、セルフホスト型のモデルも扱っています。この評価は、Amazon Bedrockのような完全マネージド型ソリューションにより重点を置いています。
この評価は、データを外部で管理する第三者やクラウドソリューションを評価する場合とよく似ています。データのプライバシーとセキュリティについて知る必要があります。一部のプラットフォームでは、データを使用されたくない場合にオプトアウトするか、契約上の合意が必要です。お客様のデータがモデルの学習や微調整に使用されて公開されることがないよう、確実にする必要があります。システム内でのデータの取り扱い方、アクセス権限を持つ人、データが永続化されるかどうかを把握する必要があります。お客様のデータが他人のコンピュータやラップトップに残ることがないという保証をお客様に提供したいと考えています。
モデルの可用性とサポートについて検討し、お客様にサービスを提供する必要がある地域で利用可能であることを確認します。これは、データセンターが構築され、モデルが異なる地域にデプロイされるにつれて変化していきます。あらゆるソフトウェアと同様に、モデルのライフサイクルも重要な考慮事項です。お客様向け機能で依存しているモデルが廃止される場合（この急速に変化する市場では必ず廃止されます）、お客様体験を維持しながら移行するためにどれくらいの期間が与えられるのかを知る必要があります。また、コンテンツモデレーションについても検討します。Denisが言及したように、ガードレールが効いている領域があります。モデルに組み込まれている場合もあれば、プラットフォームがモデルの外部でコンテンツモデレーションを課す場合もありますが、必ずしも設定を変更できるわけではありません。コンテンツモデレーションが実施されているかどうか、そしてそれを私たちのニーズに合わせてどのように設定できるかを理解する必要があります。
生成されたコンテンツの所有権に関して、これはある種のエッジケースです。最も大きな影響を受けるのは4つの関係者です：AIの機能を使用するCisco製品を購入するお客様、機能を開発するCisco、プラットフォームのプロバイダー、そしてモデルのプロバイダーです。一般的に、モデルの使用料を支払う人が出力結果を所有します。しかし、より強力な大規模モデルを使用して、特定のタスク用に小規模なモデルを学習させるケースが増えてきています。私たちは使用しているモデルと潜在的に競合する可能性があるため（レイテンシーを下げたり、コストを抑えたりするために置き換えたいと考えているため）、これが適切かどうかを確認する必要があります。
最後のアセスメントに移りましょう。これは実際のユースケースに焦点を当てています。この機能自体は、これまでに収集したすべての情報を基に構築されています。私たちは、これまでのアセスメントから再利用可能なコンポーネントを厳選し、作成します。まず、この問題がそもそもAIで解決すべきものなのかを検討することから始めます。 マーケティングチームは何でもかんでもAIにしたがりますが、AIを必要としないものもたくさんあります。 AIソリューションが妥当だと判断された場合、選択したモデルとアーキテクチャが問題に適しているかを評価します。潜在的な悪影響や、エンドユーザーが意図せずに個人やグループに対してネガティブな選択に導かれる可能性がないかを検討します。 より広い視点でデータリスクを再度確認します。データの露出リスクはFine-tuningだけではありません。Dennisが先ほど言及したように、RAGシステムを使用する場合、AIチャットボットにアクセスできる全員が見るべきではないシステムからデータを取得する可能性もあるため、そういった懸念事項も考慮する必要があります。
エンドユーザーの実現性（これはむしろエンパワーメントと呼びたいところですが）に関して、AIの出力を扱うエンドユーザーがそれがAIであることを認識しているか、必要に応じてこの機能を設定変更したりオプトアウトしたりできるか、AIと協調して編集や修正を行えるか、問題のある動作を報告できるかなどを考慮する必要があります。
ガードレールは、その適用範囲をうまく示してきました。システムによって、より多くのガードレールや異なるタイプのガードレールが必要になります。オープンな会話アシスタントは、データフローをより制御できるクローズドループのシステムと比べて、より多くの種類の攻撃に対して脆弱です。 AIで構築されたほとんどのシステムには複数のステップがあるため、顧客に悪影響を及ぼす可能性のある複合的なエラーが発生する可能性を考慮する必要があります。
一例を共有させていただきます。Webex Contact Centerの提供機能として開発したTopic Analyticsです。これは顧客の通話トランスクリプトを取得し、顧客がコールセンターに問い合わせた理由を抽出し、それらをグループ化してトピックとしてラベル付けすることで、コールセンターの管理者が顧客がなぜコンタクトセンターに電話をかけているのかを把握できるようにするものです。 これを詳しく見ていくと、エンドツーエンドのソリューションには3つのステップがあり、もしすべてのステップを完全にAIに依存した場合、最初のフェーズで発生したエラーが後続のフェーズに波及してしまうことに気づきました。
そこで、ユーザーエクスペリエンスを変更し、早い段階で人間をループに組み込んで、クラスターのレビュー、編集、場合によっては再生成ができるようにすることにしました。ユーザーにより多くの権限を与えることで - 何万件ものトランスクリプトを自分で確認するよりはまだ効率的ですが - 最終的に生成されるモデルに対してユーザーがより多くのコントロールと洞察を得られるようになります。 Collaborationビジネスユニットでは、顧客の信頼を得るためにさらに一歩進んだ取り組みを先駆的に行っています。開発中のAI機能すべてについて、透明性に関する注記を作成しています。これにより、顧客はデータの流れや処理方法に関する懸念事項を素早く特定し、このAI機能が自社のビジネスに適しているかどうかについて、十分な情報に基づいた判断を下すことができます。
最後に、先ほど発表した自動推論チェックについて説明し、その仕組みをご紹介したいと思います。これは、ロジックルールを使用した明示的な推論を組み込んだ業界初の製品です。基本的な考え方は、自然言語でポリシーを定義すると、そのポリシードキュメントが解析され、明示的なルールに変換されます。そして、そのルールを言語モデルの出力結果の検証に適用するというものです。この例では、仮想的なUnicorn Airlinesというケースについて説明します。 ポリシーを定義してルールが設定されると（例えばチケットの変更に関するルールなど）、システムはクエリを処理します。例として「Unicorn Airlinesでワンダーシティに飛行する予定です。チケットに記載された姓のスペルが間違っているのに気付きました。現在、空港に来ていますが、対面で変更を申請できますか？」というケースを見てみましょう。システムは最初、「はい、チケットの名前変更は空港での対面でも含め、いつでも可能です」と回答します。
しかし、自動推論システムはこの回答が無効であると判断し、その理由を説明します：名前の変更が許可されるのは、変更が許可されており、かつ申請方法が有効な場合のみです。そして、申請方法が有効となるのは、メールでの申請の場合に限られます。現在、このスピーカーはGated Previewの段階にあるため、アクセスをリクエストする必要があるかもしれません。皆様のユースケースでどのように機能するか、ぜひご確認ください。ご清聴ありがとうございました。アンケートへのご記入もお忘れなく。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion