re:Invent 2025: IndeedのAI責任ある運用とAWS Responsible AIフレームワーク実践
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - From principles to practice: Scaling AI responsibly with Indeed (AIM3323)
この動画では、AWSのMike DiamondとIndeedのLewis Bakerが、AIを責任を持ってスケールさせる方法について解説しています。すべてのAIシステムには固有のResponsible AIの姿勢が組み込まれており、OECDのデータでは2025年10月にAIインシデントが509件と前年比95%増加したことが示されています。AWSはControllability、Privacy、Safety、Fairnessなど8つの次元でResponsible AIを定義し、Baking、Filtering、Guidingという3つのリスク軽減戦略を提唱しています。AWS Responsible AI Best Practices FrameworkはWell-Architected Toolで公開され、設計、開発、運用の各段階でベストプラクティスを提供します。IndeedではAI Constitutionを策定し、月間1,060万件のAIレスポンスに対して17個のガードレールを運用しています。責任あるAIは開発の最初から組み込むべきインフラストラクチャへの投資であり、ポリシー段階での対応では遅すぎると強調されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
Responsible AIの重要性：すべてのAIシステムに組み込まれた姿勢
おはようございます。本日は満席のようで、素晴らしいですね。私の名前は Mike Diamond で、AWS の Responsible AI の Principal Product Lead を務めています。本日は Lewis Baker と一緒に進めさせていただきます。Lewis は Indeed の Senior Data Science Manager で、Responsible AI の責任者です。今日は、AI を責任を持ってスケールさせることについてお話しします。
すべての AI システムは、Responsible AI に対する特定の姿勢を組み込んでいます。つまり、どのように責任を持って運用し、リスクを最小化するかについての一連の決定と立場の上に構築されているということです。私が言っていることは、いくつかのユースケースの例を通じて説明すれば、より明確になると思います。
最初の例を見てみましょう。不動産会社が、買い手と売り手向けにコンドミニアムの物件説明を出力するシステムを構築しているケースです。彼らはいくつかの質問を検討する必要があります。生成されたテキストは、すべての買い手の人口統計グループを平等に歓迎していますか？物件の特徴は正確に捉えられていますか、それとも物件の説明に幻覚がありますか？前の所有者と居住者からの個人情報が説明に漏れていないでしょうか？そして、彼らが使用しているコンテンツ、提示している画像には、安全でない、または違法なコンテンツが含まれていないでしょうか？
では、今日多くの人が取り組んでいるもう一つの例を、さっと考えてみましょう。それは e-commerce サイト向けのショッピングエージェントです。この e-commerce 企業がサイトを構築する際に、いくつかの質問を検討する必要があります。エージェントは個々のユーザーにとって意味のある具体的な推奨事項を提供できるでしょうか。同時に、そのサイトの異なるデモグラフィックユーザー全体で公平性を保つことができるでしょうか。不正な請求の蓄積や予算超過に対して脆弱ではないでしょうか。支払いレールを通じて個人データを不適切に共有していないでしょうか。そして、大規模な不正払い戻しをトリガーするように設計された操作攻撃に対して脆弱ではないでしょうか。
これら 2 つのユースケースにわたるこれらの質問のそれぞれは、AI システムの本質的な技術的特性を表しています。それが AI システムの構築者によって意図的に対処されるかどうかにかかわらずです。もちろん、それらに意図的に対処しないことには結果があります。
AIインシデントの急増とAWSが定義する8つのResponsible AIカテゴリー
OECD、つまり経済協力開発機構は、AI モニターを使用して、複数年にわたってインシデントとハザードを追跡しています。インシデントは有害なイベント、つまり個人に有害な影響を与える AI イベントとして定義されており、ハザードは個人に害を与えた可能性があるが、評判上の損害をもたらした可能性のあるものです。私の後ろのチャートでわかるように、2025 年 10 月に 509 件のインシデントという最高点に達しました。これは昨年の同時期比で 95 パーセントの増加です。この期間中のこの上昇は、過去数年間に私たちが目撃した AI の使用拡大、特に生成 AI に対応しています。
AWSでは、責任あるAIを、ここに見えるこの8つのカテゴリーで定義しています。先ほど、AIシステムに固有の技術的特性があると言いましたが、これがまさにそういった特性の例です。従来、機械学習の訓練を受けた人たちは、損失関数に対する精度に向けて予測を最適化するように訓練されてきました。責任あるAIというのは、AIシステムの利益を最大化し、これら8つの次元全体にわたるリスクを最小化する、そしてそれらの間で必要とされるトレードオフを考慮する、そういった技術なのです。
それでは、AWSで追跡しているこれらの次元と特性について、簡単に説明します。Controllabilityというのは、AIシステムの動作を監視し、操舵するためのメカニズムを持つという特性です。Privacy and securityというのは、そのシステムを支える基盤となるデータとモデルを適切に取得し、使用することに関するものです。Safetyというのは、詐欺のようなものを含む有害な悪用を防ぐという特性です。Fairnessは、システムの出力が異なるステークホルダーとグループに与える影響を考慮するものです。
Veracity and robustnessというのは、予期しない入力や敵対的な入力があっても正しい出力を達成するという特性です。Explainabilityというのは、出力を理解し、評価することに関するものです。Transparencyはexplainabilityに似ていますが、ステークホルダーをガイドし、そのAIシステムの使用についての情報に基づいた選択ができるようにすることに関するものです。GovernanceはこれらのAIシステムの技術的特性に関するベストプラクティスを組み込むもので、これについては今後さらに詳しく説明していきます。
Responsible AI導入における4つの課題：専門知識、ツール統合、規模の拡大、コンプライアンス
Responsible AI の Principal Product Lead としての私の役割では、皆さんの多くや、組織内で Responsible AI を大規模に導入する際の課題について教えてくれるお客様とお会いする機会があります。
その課題の一つは、これらの技術的特性のそれぞれが、ある程度の専門知識を必要とするということです。それぞれの特性には科学があります。Fairness に対応するには、複数の測定方法があります。Robustness を見る場合でも、複数の方法があります。つまり、専門知識が必要なのです。
お客様と話す中で聞く二番目の課題は 、オープンソースコミュニティ、AWS、サードパーティベンダーから提供される多くのツールがあるということです。しかし、これらのツールを、AI ライフサイクル全体を通じてビルダーチームに提供できるような統合的なソリューションに組み立てることは、はるかに難しいのです。一部の組織では、Responsible AI への投資がイノベーションへのボトルネックと見なされています。これについてはもっと詳しく話します。
私は AWS の Responsible AI チームにいますが、これを個人的に見てきました。また、組織内の多くの Responsible AI エキスパートは、この数年間で対応する必要がある AI ユースケースの数が非常に増えた一方で、チームの規模は変わらないため、圧倒されていると感じています。私が協力している医療関連のある企業は、Responsible AI エキスパートチームのレビュー待ちのバックログが 1,000 件以上のユースケースあると言っていました。
Responsible AI はまた、コンプライアンスも関わってきます。それは、皆さんが事業を展開している地域によって異なります。ヨーロッパ内、コロラド州内、カリフォルニア州内、そして ISO 42001 のような管理基準も関わってきます。ビルダーチームは、これらの規制に準拠するために、正しい形式でエビデンスを出力する必要があります。では、これらの課題にどう対応するのでしょうか？
リスク軽減の3つの包括的戦略：Baking、Filtering、Guiding
まず最初に言いたいことは、これは議論を呼ぶかもしれませんし、そうでないかもしれませんが、責任あるAIの技術的特性や側面すべてを見渡すと、リスク軽減の際に使用できる3つの包括的な戦略があるということです 。私はそれらを「Baking」「Filtering」「Guiding」と呼んでいます。
Bakingというのは、AIシステム自体に望ましい動作を組み込むことです。不要なバイアスのリスクを軽減したい場合、システムがどのように使用されるかに応じて、人口統計グループの分布を持つデータセットを構築することでこれを行うかもしれません。ハルシネーションのリスクを軽減したい場合、先ほど議論していたコンドミニアムの説明ユースケースに戻ると、回答をデータに基づかせるRAGパイプラインを持つかもしれません。
Filteringというのは、AIシステムへの入力と、それから出力される両方をブロックすることです。コンドミニアムの説明のユースケースに戻ると、個人識別情報がAIシステムに入ったり出力されたりするのをフィルタリングまたはブロックするガードレールを設定したいかもしれません。そのシステムがAPIと統合されたり、ユーザーに返されたりする際に、フィルタリングを行うかもしれません。それがFilteringです。
Guidingというのは、ユーザー、つまりシステムのユーザーで、それは人間のユーザーかもしれませんし、エージェントや他のシステムかもしれませんが、そのユーザーをシステムの適切な使用と意図された使用に向けて導くことです。これはデータカード、モデルカード、AIシステムカードなどを通じてシステムの制限について透明性を持つことについてです。ですから、これらが責任あるAIに対処するために使用する3つの包括的なテクニックです。
3つの防御線モデルとResponsible by Designの実践
ここで手を挙げてもらいたいのですが、規制産業でリスクに対処するために使用される3つの防御線モデルに精通している人は何人いますか 。かなりの数の人が手を挙げていますね。良いことです。このスライドで私がしたことは、そのモデルをAIリスク管理に適用したもので、それについて説明します。
一番左から始めると、それが最初のラインです。これはビルダーチームで、AI システム自体に実際のセーフガードとコントロールを組み込む責任があります。2 番目のラインは、私が話した AI エキスパートのグループです。組織内には複数の 2 番目のラインチームが存在します。クラウドセキュリティの 2 番目のラインチームがあるかもしれません。コンプライアンス、マネーロンダリング対策、または他の形式のリスク管理に取り組んでいるかもしれません。その 2 番目のラインチームは、最初のラインチームと密接に協力し、ガイダンスを提供し、サポートし、プラクティスをセットアップします。
そして一番右には 3 番目のラインがあります。これは最終的には内部監査と独立した保証の役割です。これらのチームは、右側に見える外部監査人とインターフェースします。
私たちは、組織に内部セキュリティと全体的な保証を提供するさまざまな機関とコンサルティング機関と協力しています。組織が responsible AI がボトルネックだと話すとき、私がよく見るのは、responsible AI が最初のラインと 2 番目のラインから 3 番目のラインへの引き継ぎの間で対処されているということです。そこで responsible AI に対処しているなら、それはもう遅いです。なぜなら、今はアーキテクチャを再設計して最初からやり直す必要があるからです。
セキュリティでは、secure by design という概念を使ってこれを解決しています。これは多くの人が馴染みのある概念ですが、私たちは responsible by design という概念を使っています。これは、3 番目のラインによって最終的に設定されたポリシーを、さまざまな管理基準と規制に関連して、2 番目のラインによってベストプラクティスのセットに翻訳し、それらのベストプラクティスをビルダーチームにプッシュすることを含みます。これは多くのボトルネックを排除し、開発プラクティスを加速させることができます。
これが AWS でやってきたことです。私たちは responsible AI best practice framework と呼ぶものを定義しました。これはスライドに表示されているフレームワークです。これは、今後数日間に聞くか、現在使用している AI サービスをビルダーチームが構築する際に使用されるフレームワークです。このようにすることにはいくつかの利点があります。最初の利点は、私たちが今説明したものです。ポリシーをビルダーチームにできるだけ左にシフトできればできるほど、彼らが最初から正しく構築できるようになり、イノベーションを加速させることができます。
2番目のメリットは、こう考えてみてください。右側には、組織が設定しているすべての管理基準、ポリシー、そして私たちが議論した規制があります。そして左側には、すべてのツールがあり、オープンソースコミュニティやベンダーから毎週新しいツールが出てきて、responsible AIのさまざまな特性に対応しています。これらは2つの非常にダイナミックなレイヤーです。ここで私が位置付けているようなベストプラクティスフレームワークをその中間に置くことで、安定性と堅牢性が得られます。新しいツーリングをそのベストプラクティスフレームワークにマッピングしてオンボードすることができ、出力は複数の規制に対応できる標準化されたフォーマットにすることができます。
AWS Responsible AI Best Practice Frameworkの詳細とWell-Architected Tool
では、ベストプラクティスフレームワークとは何でしょうか？非常に高いレベルで説明していきます。スライドでここに見ることができます。これはAIとMLのライフサイクル全体にわたっています。設計、開発、運用です。ビルダーチームのために私たちが定義した最初のベストプラクティスのセットは、ユースケース、つまり意図されたユースケースを狭く定義することに関するものです。これはビルダーチームで見てきた非常に一般的な問題です。非常に広く定義してしまうと、リスク露出が大幅に増加します。ユースケースを適切に狭めることで、リスクを最初から絞り込むことができます。
そのユースケースに対して、固有のリスクを特定するのに役立つベストプラクティスのセットを定義しました。実際のステークホルダーを個別に検討してから、私が8つのディメンションで示したようなフレームワークを通じて、各ステークホルダーに対して潜在的なリスクが何であるかを検討します。その後、それらのリスクを影響度と発生の可能性または頻度に従ってランク付けして、それらに対処できるようにします。これはビルダーチームのためのリスク特定に関するベストプラクティスを設定します。
3番目のベストプラクティスは、本当に逆算思考です。最初の段階で、設計段階の間でさえ、リリース基準を確立します。メトリクスベースの基準で、前の演習から懸念している最も高いリスクをどのように測定するかについてです。それらのメトリクスのメトリクスと閾値をリリース基準として定義します。これは意図的に円として表現されています。なぜなら、これは反復的になるからです。AIユースケースについてもっと学ぶにつれて、データを扱い始めるときにそれらを調整したいかもしれません。これらの目標を設計原則として最初に設定し、メトリクスから逆算して作業することが重要です。
次のベストプラクティスのセットは、開発フェーズの間のものです。チームが確立した各リリース基準と各リスクに対して、それをテストする方法が必要です。システムを設計する前に、個々のリスクをテストするテストセットを設計します。入力と出力の理解に基づいて、フェアネスをテストしている場合は、統計的に有効な方法でデータ内に適切なデモグラフィックグループがあることを確認してください。データセットを開発してください。複数のリスクにわたって1つのデータセットを使用することもできますが、すべてのリスクをテストするためのデータセットがあることを確認してください。
その後、AI システムを設計および構築します。これは前のスライドで説明した、ベイキング、フィルタリング、ユーザーのガイダンスまたはステアリングが機能する場所です。これら3つの包括的な戦略を使用して、それらのリスクに対処するようにシステムを設計し、その後、評価スイートで評価を実行してそれを実際にテストします。その終わりに、まだ存在するリスクがあるかもしれません。その場合、プロセスが循環的で反復的である理由はここにあります。または、それらのリスクを受け入れることもできます ですが、それらを文書化してください。これが次のベストプラクティスのセットが機能する場所です。つまり、私たちのチームはガイダンスツール、本当にデータカード、モデルカード、AI システムカードを構築します。これらは AWS のユーザーに提供されます。これらはユーザーをガイドし、AI システム自体の制限について可能な限り透明性を持たせます。
その後、モニタリングフェーズに入ると、特定のリリース基準に関連するメトリクスのセットを定義し、継続的に同じメトリクスのセットをモニタリングしていることを確認してください。 先週、私たちが内部で使用している Responsible AI Framework のバージョンを公開しました。これは現在 Well-Architected Tool の中にあります。以前は Well-Architected Tool の中に Machine Learning Lens と Generative AI Lens がありましたが、現在は AWS Responsible AI Best Practices Framework に基づいた Responsible AI Lens があります。これについては先ほど説明しました。
このパイチャートのフォーカスエリアは、左側に表示されるレンズのフォーカスエリアと同じです。各フォーカスエリアについて、回答する1～5個の質問があります。 これは、解決しようとしている特定の問題を定義する方法についての質問の1つを示しています。各質問について、そのベストプラクティスを満たすための1～5セットのベストプラクティスがあります。右側には、そのベストプラクティスについて説明する段落があり、そのベストプラクティスを実装するための実装ステップに関する非常に価値のある詳細情報を提供するガイダンスペーパーを開くリンクがあります。このフレームワークは GitHub でも利用可能です。そこにも公開しました。
Well-Architected Tool を完了してすべての質問に答えると、最後にアセスメント結果が得られます。つまり、検討すべき高、中、低のリスクのリストが表示されて、改善計画も下部に表示されるわけです。この改善計画は、あなたがどのように質問に答えたかに基づいて具体的にカスタマイズされたものになります。ぜひそれをチェックしてみてください。これが AWS Responsible AI Framework の最初の公開版で、今後も更新していく予定です。
エージェント駆動開発への応用：Quiroにおける仕様駆動開発
Lewis に引き継ぐ前に最後に言いたいことは、フレームワークの中でベストプラクティスを定義したら、このプロセスから恩恵を受けるのは人間のビルダーだけではなく、エージェントも同様だということです。私たちがみんなエージェント駆動開発と仕様駆動開発にますます投資していく中で、エージェントはビルダーと同じように自然言語を読むことができますし、あなたのベストプラクティスも読むことができます。Gartner は guardian agents について語っており、信頼とセキュリティのためにそれらを使用しています。これがまさにそのコンセプトです。つまり、責任あるプラクティスをエージェント向けのベストプラクティスのセットとして定義することです。
それが具体的にどういう意味なのか、少し説明させてください。これが Quiro で、統合開発環境です。その中にはエージェントが組み込まれています。Quiro の新しい点の一つは、仕様駆動開発というアイデアを組み込んでいることです。ちなみに、Quiro には AWS Responsible AI Framework が付属していません。私がここに追加したもので、やり方は難しくありません。Quiro の構成要素を使ってどのようにそれを実現しているかを説明します。
Quiro は 2 つのタイプの仕様ファイルを区別しています。1 つは steering files で、これはより組織的なポリシーとベストプラクティスです。つまり、Responsible AI ベストプラクティスフレームワークはこのコンセプトに非常にうまく適合し、ビルダーをガイドする方法についてエージェントに教えることになります。
ビルダーがプロジェクトを開始すると、プロジェクトを自然言語で Quiro に説明します。そうすると Quiro は use case specification files を出力します。これが上部に表示されているものです。これは先ほど説明したのと同じコンドミニアムの説明ユースケースです。Quiro はベストプラクティスフレームワークを読んで、それのさまざまな部分に対応する仕様ファイルを作成し始めます。ビルダーはこれを Quiro がコードを作成し始める前にレビューする必要があります。最終的には、ベストプラクティスに従ってコードが作成されることになります。
Indeedにおける大規模AI運用とCareer Scoutの実例
皆さん、こんにちは。Lewis Baker と申します。私はデータサイエンティストでマネージャーであり、Indeed の responsible AI の責任者をしています。Mike と私は、製品の使用方法と responsible AI についての相互情報共有について、かなり前からお話しさせていただいており、彼は私にここに来て、Indeed における responsible AI の実践的な応用についてお話しするようお願いしてくれました。
Indeed のことをご存知でない方もいらっしゃるかもしれませんが、私たちは求人サイトとしてご存知かもしれません。ただし、Indeed が運営する規模の大きさについてはすぐにはお気づきにならないかもしれません。Indeed には 6 億 3,500 万人の求職者プロフィールがあります。これは仕事を探している個人からのレジュメデータであり、私たちには 330 万人の雇用主がいて、彼らは仕事を探しているすべての人々を整理しようとしています。
業界内の人々と話をすることが多いのですが、むしろ社交の場でのことが多いのですが、私が Indeed で responsible AI をしていると言うと、「え、Indeed って AI を使ってるんですか」と言われることがよくあります。現実のところ、その量を処理する唯一の方法は AI なのです。 Indeed は求人掲示板ではありません。Indeed は検索エンジンなので、すべての求人が一箇所に集まった状態から始まります。
その求人についてのより多くのデータが必要です。その仕事をするために人々が実際に何を必要としているのかを理解する必要があります。その求人を宣伝して、ウェブサイトへのトラフィックを増やす必要があります。より多くの求職者が集まったら、彼らが正確に何を探しているのか、どのようなスキルを持っているのか、どのようなスキルを持っていないのか、どのようなスキルをリストアップしているのかを理解する必要があります。誰かが Microsoft Word を履歴書に載せていますか？これはあなたが理解する必要がある質問です。
人々が応募している求人と必要なスキルを特定すると、成功につながるものを特定することができ、それによってより多くの雇用主が得られ、サイクルが続きます。私はこのすべてを通じて、Indeed は AI 企業であり、AI は私たちが行うすべてのことに深く組み込まれていることをお伝えしたいのです。
では、これを責任を持ってどのように行うかについて、具体的な例を挙げさせていただきます。これは Indeed Career Scout で、Career Scout はかなりシンプルなチャットボット体験です。推奨オプションのリストが表示されて、それを確認していくこともできますし、キャリアについてオープンエンドな会話をすることもできます。ハイライトされたツールの中には、履歴書を作成したり、求人検索をしたり、現在の職種以外の職種を検索したりするものがあります。
最初のオプションを選ぶと、例えば「私は受付として長い間働いてきたのですが、クリエイティブな分野に興味があり、試してみたいと思っています」というようなオープンエンドな会話ができます。Career Scout は、あなたが持っているスキル、必要なスキル、そしてキャリアの転職を実現するためにどのようなオプションが利用可能かについてガイドしてくれます。
その後、一連の求人が表示され、「これはあなたが探しているものですか？」と言うことができ、最終的にはそれらの求人に応募することができます。概念的には非常にシンプルです。あなたは単に会話をしているだけで、仕事を見つけようとしているだけで、運が良ければ、私たちがあなたを見つけるのを手伝います。
これには課題があります。シンプルなシステムには、誤った使い方が無数にあります。このトークに参加されている方は、以前に何か問題が起きたことを聞いたことがあるかもしれませんので、ここは早めに進めます。例えば、2年未満前に、Google AI Overview に「人は何個の石を食べるべきか」と聞くと、1日の栄養価を得るために約1個を食べることをお勧めしていました。これは良くありません。それほど害があるわけではありませんが、ご理解いただけると思います。
その後、「妊娠中の喫煙について」と聞くと、「1日2～3本のタバコは素晴らしい」と言うでしょう。これは正しくありませんが、繰り返しになりますが、ご理解いただけると思います。
それが Target です。記録には残さないんですが、やはり良くないですね。意図的にかなり平凡な例を挙げてきたんですが、皆さんは「何が大事なの？」と思ってるかもしれません。実は、本当に酷いこと、ひどいことをいっぱい見てきたんですが、ここでは共有しません。でも、他の人の安全や、岩を食べるなという助言に従うべきではない人たちの懸念が気にならないとしても、この非常に現実的な状況では気になるかもしれません。つまり、初期段階の、正直に言うと非常に初期段階の ChatGPT のバージョンが、自動車販売店のチャットボットとして組み込まれたとき、誰かに Chevy Tahoe を 1 ドルで売ったんです。それが法的拘束力のある声明だと言ったんです。その企業への害は本当で、エージェントから生じる可能性のあるものなんです 。
AI Alignmentの実践：AI Constitutionによる人間のアラインメントからAIアラインメントへ
では、AI をレールの上に保つにはどうすればいいのか。Mike は高レベルのフレームワークと Quiro 内の特定のツールについて、spec-driven development のやり方を説明してくれました。私は Indeed がこれをどのようにやってきたかについて、具体的に掘り下げたいと思います。 Mike が話した AI の側面に戻ると、心配すべきことの全体的な風景があります。Indeed の場合、非常に堅牢なセキュリティチーム、プライバシーチーム、ガバナンスチームがあります。ですから、責任あるAIについて、これら4つのことに集中しようと思います。他のことを気にしていないわけではありませんが、この部屋からいつかは出ないといけませんので。安全性、公平性、透明性、そして真実性に焦点を当てます。つまり、物事が真実であり、公平であり、意味があり、使用するのに安全であることをどのように確認するのかということです。
私たちの一般的な戦略は このフライホイールに従うことです。前もって何が悪くなる可能性があるかを予測し、これを設計段階での判断に活かします。これが Mike が spec-driven development について話していたことです。安全性を設計要件として中心に据える必要があり、そこに到達するための具体的なメトリクスが必要です。何かが世に出たら、開発者が考えていた通りに物事が進むと信じることはできません。ガードレールを設置する必要があり、ここでリアルタイムガードレールが何であるかについて少し説明しますが、一般的には、あらゆる種類のモデレーションシステムはガードレールと見なすことができます。
そして最後に、観察する必要があります。私はおそらく合唱団に話しかけているんですが、ログに記録しなければ、それは存在しなかったのと同じです。正確に何が起こったのかを知る必要があります。その経験から学ぶことができるようにして、将来の問題を予測でき、一般的にあなたの製品をより良くすることができます。この全体のことは、傘のような用語として、AI alignment として知られています。AI alignment の考え方は、オープンエンドの AI システムを自分たちの価値観に合わせたいということです。最初は理にかなっていますね。その概念をもう少し掘り下げると、次の質問が出てきます。私の価値観は何なのか。
Indeed での私の仕事は、人々が仕事を得るのを助けることだと知っています。私がすることは何でも、それに役立つようにしたいと思っています。そして一般的に、人々に悪い経験をさせたくないと知っています。でも、その中間にあるすべてのものがありますよね。明らかに、私のチャットボットが暴力の脅迫をするのは望みません。ヘイトスピーチを使うのも望みません。チャットボットにどんなトーンを持たせたいのか。非常に厳格で堅苦しくしたいのか。ジョークを言わせたいのか。仕事検索を通じて人々が仕事を見つけるのを助けることに特に焦点を当てたままでいたいのか。誰かが数学の宿題をするよう頼んできたときのように、他のこともできるようにしたいのか。チャットボットにそれをさせるつもりなのか。これらはすべて、この問題を責任あるAIチームに渡す前に、ずっと前に、本当にずっと前に解決する必要があることです。これは人間の alignment の問題です。
Indeed でこれにどう対応したかというと、様々な部門から素晴らしい同僚たちを集めて、3時間くらい一緒に時間を過ごして、それぞれの視点から見た良い製品とは何かを、徹底的に詰めていったんです。もちろん私は responsible AI の観点から話すことができますが、trust and safety、security といったチームは、彼らのエージェントにも守ってほしい非常に具体的なポスチャーを持っています。こうしたすべてのことを AI constitution という形にまとめました。そしてそれはまさに名前の通りのものです。大きな文書です。
そこでは人々が原則とガイドラインを確立しました。私たちは人々が仕事を見つけるのを手助けしたい。プライバシーに関するいかなるインシデントも起こしたくない。セキュリティ上の脅威もあってはならない。ユーザー体験は比較的シームレスであってほしい。人々がウェブサイトに留まって検索を続けてほしい。
ここからスペックが生まれます。これは新しい製品が開発されるたびに、人々が AI Constitution を参照して、設計段階からそれに合わせることができるということです。彼らは自信を持って、チャットボットがどのようなトーンを持つべきか、どのようなデータにアクセスすべきか、そしてセッション終了後にどのようなデータを削除すべきかを言うことができます。
その後、さらに進めて、よし、これに合わせて構築したなら、それが機能していることを確認するガードレールを構築しようと言うわけです。ガードレールは、並列プロンプトを持つくらい単純なものかもしれませんし、あるいはシステムプロンプトの中に、言われたことが X、Y、Z の基準に従っていることを確認しろというようなものかもしれません。
最後に、あなたは観察します。X、Y、Z の基準が守られていることを確認します。ガードレールでフラグが立てられたものすべてにラベルを付けて、監視し、どのような害が発生したのかを見ることができるようにします。それを調査して、見落としていたものを特定します。
これが、大規模な人間のアラインメントから AI アラインメントへの移行方法です。1 スライドで述べるより難しいことは保証します。
Career Scoutでの具体的実装：レッドティーミング、ガードレール、観察の循環
Career Scout でのアラインメント方法を具体的に見てみましょう。Career Scout は、あなたのキャリアをどうしたいのかについてのオープニングの会話です。起こりうる問題を予測するために、私たちは特定のルーブリックを使った一連の AI レッドティーミングイベントを開催し、何が受け入れられるのか、何が受け入れられないのかを調整しました。
何かをリリースする前に、私たちは敵対的な AI エージェント、つまり攻撃者 LLM を作成し、それにプロンプトを与えました。そのプロンプトは、差別を試みたり、誰かの社会保障番号を取得しようとしたり、あるいは誰かを詐欺に巻き込もうとするものかもしれません。
その敵対的な LLM は何度も何度も私たちのチャットボットと対話します。すべての反復で、詐欺が私たちのガードレールを通り抜けたかどうかを特定するための一連のルーブリックがあります。これを何度も繰り返します。複数の異なるエージェントペルソナで数千回これを行い、私たちのガードレールが実際にどの程度堅牢であるかを確認します。
本番環境に入ると、私たちはガードレールで対応できる潜在的な害の広い範囲を予測しています。その最も基本的なものは標準的なコンテンツモデレーションです。それ自体も非常に複雑ですが、一般的に、私たちの価値観の 1 つは、チャットボットが人々に悪態をつかないようにすることなので、私たちのプラットフォーム上に悪態がないようにするためのフィルターがあります。
物事はより複雑になり、より文脈に依存するようになるので、私たちはコンテキスチュアルなガードレールも持っています。これらは二次的なシステムプロンプトで、何かが私たちの利用規約に沿っているかどうかを評価します。これらは何かが害をもたらすかどうかを検出できるようにするものです。
エージェントに誰かに「どっか行け」と言うように指示したら、それはあまり良い言い方ではありません。私たちは「以下のタイプの発言を許可しない」と言うガードレールプロンプトを持っていて、また、このフラグも与えます。これは害としてフラグが立てられています。「憎悪的または有害な会話のトピックを促進しないこと」と言っています。LLM as a judge がこれを私たちの閾値を超えて評価し、これを害としてフラグを立てました。
応答を生成する代わりに、AI は「申し訳ありませんが、人々に『どっか行け』と言うことはできません」という応答を生成するようになります。これが基本的にガードレールがどのように機能するかです。
製品を持ったら、それがどのように悪くなる可能性があるかを予測しようとして、それが悪くなるのを防ぐためにガードレールを構築します。その後、実際に何が起こったかを観察します。これの大きな部分は単にイベントをログに記録することです。必ずしも永遠にログに記録する必要はありませんが、何が起こったかを知るためにはログに記録する必要があります。異常検知は大きな役割を果たします。
モデレーションシステムをより定期的にトリップさせているイベントはありますか？それは adversarial attack かもしれません。TikTok で何かがトレンドになっているのかもしれません。システムの何かが壊れているのかもしれません。いずれにせよ、それを検出できる必要があります。また、私たちが親しみを込めて「unknown unknown analysis」と呼んでいるものもあります。これは、フラグが立てられなかった非常に大きなサンプルのイベントを取得して、それを一連の実験的なものを通して押し出し、見落とした可能性のあるものがあるかどうかを確認するというものです。クラスター分析を実行して、境界線上にある会話があるかどうかを確認します。99 ポイント何度かは仕事を検索しようとしている人々かもしれず、常にゼロから車を作る方法を理解しようとしている人々の一部がいて、そこで何が起こっているのか、そしてそれがどのようにしてあなたのガードレールを通り抜けたのかを理解したいのです。
こうした話をしているのは、本当に Mike が最初に言った重要なポイントを強調したいからです。すべての AI システムには責任ある AI の姿勢があります。もしあなたがポリシーの観点から責任ある AI を推進しているなら、それはもう遅いということです。責任ある AI は、1 行のコードが書かれる前に、1 つのワイヤーフレームが描かれる前に始まります。責任ある AI はインフラストラクチャへの投資です。Indeed における責任ある AI は、私たちの AI インフラストラクチャ組織の一部です。私たちは R&D の必要不可欠な部分なのです。
具体的な例を挙げると、現在私たちは 17 個のアクティブなガードレールを持っています。それらはこの会社のあらゆる AI インターフェースに配置されています。現在、私たちは月に 1,060 万個の AI レスポンスを処理しています。もし私たちがポリシーチームだったら、これらすべてを手作業で行うことはできません。すべてのチームに私が書いたルールに従うよう求めることはできません。私たちが行ったことは、一連のツールを作成し、一連のチェックを作成することです。そして、人々はそれらのチェックに合格するまで、本番環境にモデルをリリースすることはできません。
今、私があなたに伝えたいポイントは以下の通りです。まず第一に、責任ある AI の主要な部分は、あなたの価値観が何であるかを知り、それに対する合意を得ることです。あなたの会社が何を望み、何を望まないのかを知る必要があります。何が可能で、何が不可能なのかを知る必要があり、開発者にそれを伝える必要があります。なぜなら、あなたが伝えなければ、彼らは推測するからです。開発のあらゆる段階に責任を組み込む必要があります。すべてのシステムには責任ある AI の姿勢があります。それが好きかどうかに関わらずです。何かが使用される方法はたくさんあります。あなたが知らないかもしれない規制もたくさんあります。あなたはそれらを予測する必要があります。それらのためにガードレールを構築する必要があり、その後、実際に何が起こるかを監視する必要があります。
最後に、プラットフォーム化への道を見つけてください。Mike は先ほど素晴らしいオプションをいくつか提供してくれました。これらのものを開発に組み込むことができます。チェックを組み込むことができます。開発者がそうしなくても済むように責任を持って物事を行うことができます。以上です。Mike に戻ってきてもらい、これを締めくくってもらいます。
ありがとうございました。QR コードをスキャンしたい場合のリンクをいくつか紹介します。AWS または Indeed での責任ある AI についてもっと知りたい場合は、上の 2 つのボックスがウェブサイトに移動します。私が紹介した責任ある AI レンズは、Well-Architected Tool で利用可能で、その QR コードでそこに移動できます。そしてもちろん、Qiro に興味がある場合は、そのリンクがあります。AWS での AI についてもっと知りたい場合は、学習の旅のために検討すべきコースがいくつかあります。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion