re:Invent 2024: KONEがAmazon Bedrock Guardrailsで AIアプリケーションを保護
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら!
📖 AWS re:Invent 2024 - KONE safeguards AI applications with Amazon Bedrock Guardrails (AIM302)
この動画では、Amazon Bedrock Guardrailsの機能と実装事例について詳しく解説しています。Generative AIアプリケーションの安全性を確保するための6つのポリシー(Content Filter、Prompt Attack Filter、Denied Topics、PIIフィルター、Word Filter、Contextual Grounding)の詳細と、新機能のAutomated Reasoningチェックについて説明します。また、KONE Corporationの事例として、世界60カ国で170万台以上のエレベーター・エスカレーターを保守管理する現場で、Technician Assistantアプリケーションを開発・導入した経緯を紹介。Claude 3 SonnetやClaude 3 Haikuなど複数のモデルを使い分け、処理時間を1.02秒から0.48秒に短縮し、コストを38%削減した具体的な成果が示されています。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください!
本編
Amazon Bedrock Guardrailsの概要と本セッションの紹介
こんにちは、ようこそ。本日は re:Invent 2024の3日目です。お忙しい中、ご参加いただき、ありがとうございます。皆様、素晴らしい re:Inventをお過ごしのことと思います。この1週間は私たちにとって1年で最も楽しみな週であり、皆様にお会いできて大変嬉しく思います。始める前に、簡単にお伺いしたいのですが:空港やホテル、あるいは re:Inventの各会場でエレベーターやエスカレーターを使った方は手を挙げていただけますか?皆さんですね、素晴らしい。では、エレベーターやエスカレーターと、本日のテーマである Generative AIと安全性を関連付けて考えられる方はどのくらいいらっしゃいますか?1、2人ですか?今日は、エレベーター、エスカレーター、そして安全な Generative AIアプリケーションの構築に関する興味深いストーリーについてお話しします。きっと気に入っていただけると思います。
私は Shyam Srinivasanと申します。AWSのPrincipal Product Managerとして、責任あるAIのための主力サービスである Amazon Bedrock Guardrailsのプロダクトマネジメントを率いています。本日は、素晴らしいお二人をお迎えできることを光栄に思います。まず、エレベーターとエスカレーター業界のリーダーである KONE Corporationから、Strategic PartnershipsのVP兼責任者である Tero Hottinenさんをお迎えします。美しいフィンランドからはるばるお越しいただき、大変感謝しております。こちらの方が暖かいことを願っています。そして、私の敬愛する同僚で、Senior Generative AI Specialist Solutions Architectの Talha Chatthaさんをお迎えできることも同様に嬉しく思います。彼は私の発言の正確性を確認してくれる存在で、Guardrailsの技術的な詳細について皆様にご説明いただきます。
それでは、アジェンダの簡単な説明から始めましょう。まず、Amazon Bedrock Guardrailsとは何か、その概要についてお話しします。すでにご覧になった方もいらっしゃるかもしれません。なぜ私たちがこれを構築したのか、どのような機能が含まれているのかについてお話しします。また、アーキテクチャの観点からその仕組みについても説明します。その後、Talhaが私の説明を補完する形で、インタラクティブなプロダクトデモをご紹介します。スライドだけでは製品の良さを十分にお伝えできないことはご存知の通りです。そして、Teroに登壇していただき、KONEのストーリー、そして長年にわたるAWSとの素晴らしいパートナーシップについてお話しいただきます。さらに、KONEがAWSと協力して開発した Technician Assistantというアプリケーションのデモもご覧いただきます。最後に、いくつかの参考リソースをご紹介します。明日はワークショップも予定していますので、ぜひご参加ください。
Generative AIの課題とAmazon Bedrock Guardrailsの機能
Generative AIモデルについて話すとき、モデルはますます大規模化し、性能も向上しています。火曜日の Mattのキーノートで、私たちの最新モデルについて発表があったのをご覧になったと思います。しかし、それは同時に一連の課題ももたらします。注意を払わなければならない点があるのです。環境内で望ましくない、あるいは無関係なトピックが導入されることは避けたいものです。さらに重要なのは、企業内や環境全体で有害または不快な内容となりうる有害なコンテンツを避けることです。プライバシー保護は私たち全員にとって最重要事項です。名前、住所、電話番号、あるいはアメリカの場合はソーシャルセキュリティ番号といった個人情報を漏らすことは避けたく、そのような情報はアプリケーションから送信される前に編集またはマスクされるようにする必要があります。
最近、Prompt攻撃と呼ばれるものが注目を集めています。以前から存在していましたが、最近ではより巧妙になってきています。Prompt攻撃とは、アプリケーションに入力を提供する際に、AIシステムやモデルを欺いたり操作したりして、不正確または無関係な応答を生成させようとするものです。これは大きな問題となる可能性があり、確実に避けなければなりません。そして、モデルについて話すとき、確かにモデルは改善され、大規模化しています。モデルの処理能力は向上していますが、モデルが不正確または作り出された情報を生成するという幻覚の問題は依然として残っています。これは対処しなければならない課題です。
組織に参画する際には、それ以上のことが求められます。追加のコントロールが必要になるのです。ユースケースは様々で、各組織の各部門にはたくさんのユースケースが存在します。前のスライドで説明したような攻撃から保護するためのセーフガードを、特定のユースケースに合わせてカスタマイズする必要があります。Responsible AIは重要性を増し、多くの組織における重要な柱となっています。
企業はResponsible AIポリシーを定義しており、安全性のコントロールがそれらのポリシーに準拠することが求められます。AWSのポリシーは、単一のモデルでは組織のすべてのユースケースに対応できないという考えに基づき、モデルの選択肢を提供することです。しかし、すべてのモデル、すべてのアプリケーションにわたって一貫したレベルのセーフガードが必要です。
では、Generative AIアプリケーションを構築する際の基本的なコンポーネントを見ていきましょう。 まずアプリケーション自体があります。アプリケーションに入力されるのは、 ユースケースに対応するために必要なプロンプト、つまり入力のロジックです。そして当然、アプリケーションを動かし、応答を生成するモデル自体も必要です。 これはとてもシンプルなユースケースですが、問題は各ステップに弱点が存在することです。 不適切なアプリケーションロジックは意図しない攻撃を引き起こす可能性があり、プロンプトハイジャックはアプリケーションの誤動作につながり、さらにモデルの選択と理解力の問題は誤解釈のリスクを生む可能性があります。
各レイヤーでセーフガードが必要であり、そこで紹介したいのが Amazon Bedrock Guardrailsです。Amazon Bedrock Guardrailsは、各レイヤーにセーフガードを提供する要となります。 Generativeアプリケーションの要件とResponsible AIポリシーに基づいて、すべてのセーフガードを使用するか、必要な組み合わせを選択してカスタマイズされたセーフガードを適用できます。 Guardrailsは潜在的な攻撃や脅威に対するセーフガードを提供し、閾値の設定や必要なセーフガードの量を調整してカスタマイズすることができます。
Amazon Bedrock Guardrailsの最新機能とデモンストレーション
Guardrailsのローンチ以降、私たちは進化を続けています。昨日と今日、今週発表したことをお話ししたいと思います。 Generativeアプリケーションの増大する能力に対応するため、Guardrailsをより強力に、より有能にしました。本日のSwamiのKeynoteで発表したように、Guardrailsの画像サポートの追加は非常に興奮する発表でした。これにより、テキストコンテンツと同じレベルの安全性とセーフガードを持つマルチモーダルアプリケーションを構築できるようになります。これは素晴らしい進展です。モデルがマルチモーダルアプリケーションでより優れた性能を発揮するようになる中、同じレベルのコントロールとセキュリティでアプリケーションを保護できることを確実にしたいのです。また、昨日のMatt GarmanのKeynoteで発表された新機能、Automated Reasoning Checkの追加にも大変興奮しています。これは自動推論を使用して応答内の事実に関する主張を特定、修正、説明する新しいセーフガード機能です。
ここまでGuardrailsの概要についてお話ししてきましたが、それでは各機能の詳細と使い方について見ていきましょう。最初に説明したいのはContent Filterです。このフィルターは、スライドに示したような多くのカテゴリーにわたって有害なコンテンツを検出し、フィルタリングします。しきい値を設定するだけのシンプルな仕組みで、しきい値を高くするほど制限が厳しくなります。アプリケーションで想定されるコンテンツの種類に応じて、カテゴリーごとに異なるしきい値を選択することができます。この機能は、本日からテキストと画像の両方に対して利用可能です。
先ほどPrompt Attacksについても触れましたが、同様の対策としてPrompt Attack Filterがあり、システムを操作しようとするPrompt InjectionやJailbreakなどの攻撃から保護する機能を提供します。Guardrailsはこれらの攻撃に対する防御を支援します。次のGuardrailsについて説明すると、Denied Topicsは、アプリケーションで扱いたくないトピックのリストを定義する機能です。トピックの名前を定義し、定義に基づいてこれらのトピックを検出します。説明は自然な言語で記述できます。また、要件に応じてフレーズを追加してより具体的な定義も可能です。
PIIフィルターの実装には2つのアプローチがあります。1つ目は、約30種類のPIIラベルを提供し、その中から選択してマスクまたはブロックするかを選べる機能です。これによってPII情報を必要に応じて編集することができます。もちろん、企業、場所、国、環境によって異なるため、すべてのケースを網羅することはできません。そこで2つ目のアプローチとして、正規表現を使用して独自のパターンを定義し、同様の保護機能で機密情報を検出・編集することができます。
先ほどDenied Topicsについて触れましたが、次はWord Filtersについて説明します。これは、特定の単語に対して保護機能を定義できる機能です。包括的な不適切な言葉のセットを通じて、すべての不適切な表現をフィルタリングするフラグを提供しています。さらに、避けたい独自の単語を定義してフィルタリングすることもできます。単語を手動で定義するか、単語リストのファイルをアップロードすることができます。
先ほどHallucinationについて触れましたが、この課題に対しては、夏に導入したContextual Grounding Checkを通じて2つの方法で対応しています。Contextual Groundingには、GroundingとRelevanceという2つの側面があります。簡単な例で説明しましょう。現在のGenerative AIで一般的なRAGアプリケーションがあり、ソースに国とその首都のリストがあるとします。入力プロンプトで「日本の首都は何ですか?」と尋ね、回答が「日本の首都はロンドンです」となった場合、これはソース情報に従っていないためGroundingエラーです。一方、同じ質問に対して「イギリスの首都はロンドンです」という回答があった場合、これはRelevanceの問題です。回答は事実として正しく、適切なソースを使用していますが、実際の質問に対して関連性がありません。私たちは、回答のGroundingとRelevanceの両方に基づいて、信頼度スコアを選択できる柔軟性を提供しています。内部のベンチマークによると、RAGのようなアプリケーションにおけるHallucinationの75%以上が検出・フィルタリングされており、これは非常に重要な成果で、多くのお客様が広く活用されています。
それでは、最新機能である Automated Reasoning チェックについてお話ししましょう。 私たちは Foundation Model の事実的な正確性を確保したいと考えています。Automated Reasoning は、Amazon と AWS が長年にわたって IAM や S3 などの多くのサービスで活用してきた技術です。そして Matt が言及したように、これは Foundation Model ベースのアプリケーションでより重要になってきています。事実に基づく主張を明確に特定し、誤った情報がある場合は修正を提案します。これは単なる正確性や不正確性の問題ではありません。私たちは論理的な健全性にも重点を置いています。つまり、お客様が定義したポリシーに基づいて、絶対的な確実性を持って妥当性を判断し、証明を提供します。これは特に、HR ポリシー、法的文書、保険金請求など、絶対的な確実性が求められ、不正確な情報を即座に検出して修正を提案する必要があるユースケースで重要です。各ポリシーはバックエンドで数理論理にマッピングされ、事実に基づく主張の検証を行います。最後に、多くの AWS サービスと同様に、私たちは透明性を重視し、なぜその主張が正確なのか、あるいは正確でないのかを明確に説明します。これらが現在 Guardrails がサポートしているすべてのポリシーですが、ユースケースに応じて、これらの中から任意のポリシー、すべてのポリシー、または任意の組み合わせを選択する柔軟性があります。
Amazon Bedrock では、ご存じかもしれませんが、通常使用する2つの API があります - invoke model API と converse API です。ユーザー入力はポリシーを通過し、保護したい内容に準拠していることを確認します。その後、Bedrock 内で選択したモデルに対して推論呼び出しを行い、Foundation Model からの応答も同じポリシーセットによって保護されます。このように、ユーザープロンプトからモデルの応答まで、望ましい最終応答を得るための一貫したセーフガードソリューションを提供しています。
これはinvoke model API と converse API の両方で実行できますが、多くのお客様から、推論モデルを呼び出したくない、ユーザープロンプトを保護するためのセーフガードセットだけが欲しい、そして必要なときに好きなモデルを呼び出せる柔軟性が欲しいという声がありました。これは Bedrock 以外のモデルでも同様です。そのため、今年の夏に apply Guardrail API を導入しました。apply Guardrail API は、モデルを呼び出さない独立型 API としても知られています。apply Guardrail API は、お客様が定義したポリシー(任意の組み合わせが適用可能)で動作し、モデルを呼び出したり Bedrock モデルに縛られたりする必要はありません。これはパブリック API なので、Bedrock 内のモデル、自己ホスト型モデル、Amazon SageMaker で構築したモデル、さらにはサードパーティのモデルなど、どのモデルに対しても呼び出すことができます。
つまり、モデルを呼び出すことなくセーフガードを使用する柔軟性を提供します。まとめると、Amazon Bedrock Guardrails はプロンプトとモデルの応答を評価し、孤立したソリューションにならないよう、すべての Bedrock ツールと連携します。つまり、Agent ワークフロー、Agent、RAG アプリケーションのナレッジベースなどがあるかもしれませんが、Guardrails は新しく発表された Nova モデルを含む Bedrock でサポートされているすべてのモデル、さらには自己管理型やサードパーティのモデルとも連携します。しかし、私の言葉を信じるだけでなく、実際の証拠を見ていただきたいと思います。ここで、私の友人の Talha にデモをお願いしたいと思います。
KONEのエレベーター事業とGenerative AI活用の背景
ありがとうございます、Shyam。Shyam が説明したように、様々なポリシーが用意されています。合計で6つのポリシーから選択できます:denied topics、content filters、contextual grounding を使用した幻覚の検出、そして Automated Reasoning などの新機能です。これらの機能の1つを見てみましょう。 Guardrail の作成は非常に簡単です。Amazon Bedrock コンソールにアクセスするだけです。左側に Guardrails を選択するオプションがあり、そこから Guardrail を作成できます。必要なのは、後で使用する Guardrail の名前を付けることだけです。Guardrail が入力レベルで呼び出されたときに表示するメッセージを定義でき、カスタムメッセージを選択することもできます。もちろんデフォルトメッセージも用意されており、デフォルトとカスタムメッセージのどちらかを選択できます。ユーザーからの入力がブロックされた場合や、モデルによって生成された応答がブロックされた場合に表示されるメッセージを変更することができます。
先に進んで「次へ」をクリックすると、特定のポリシーを選択する画面に移ります。例えば、最初にContent Filterを作成します。利用可能なポリシーは多岐にわたり、必要に応じて選択できます。画面には、Content Filterポリシーの作成方法が表示されています。これには2つの側面があります。1つは有害なカテゴリーで、Amazon Bedrockのガードレールによって定義され、利用可能なものがすべて表示されています。これらのContent Filterは、テキストや画像の有害な入力やモデルの応答を検出してフィルタリングすることができます。
Content Filterは、利用可能な最新の機能に基づいて、テキストや画像の有害な入力やモデルの応答を検出・フィルタリングできます。特定のカテゴリーを選択するか、すべてを有効にすることができます。例えば、画像に関しては、侮辱、性的コンテンツ、暴力のみを検出するように設定できます。各カテゴリーの強度しきい値も調整可能です。例えば、中程度の侮辱は許容するがそれ以上は許容しないソーシャルメディアビジネスを運営している場合、それに応じてガードレールポリシーを調整したり、特定のフィルターのオン/オフを切り替えたりできます。
入力レベルと出力レベルの両方でポリシーを設定する柔軟性があります。モデルが出力を生成する際の異なるパラメータを定義できます。これは、Titan TextやLlama 2.1のようなユニモーダルモデルだけでなく、画像を処理できるClaude 3ファミリーや、画像を生成できるStable Diffusion、画像を出力する新しいNovaモデルなど、マルチモーダルモデルにも適用されます。テキストと画像の両方のポリシーを、入力レベルと出力レベルの両方で定義できます。
ポリシーを生成し、適切な強度を選択したら、ガードレールの作成に進むことができます。すべてのパラメータがビジネス戦略に合致していることを確認した後、ガードレールを作成できます。ガードレールはすぐにテスト可能になり、様々な入力でテストすることができます。例えば、有害な画像を使用してシステムに画像の説明を求めることで、ガードレールの介入がどのように機能するかをテストできます。また、どのガードレールポリシーが呼び出されたか、例えば侮辱とその強度レベルなどのトレースを確認することもできます。
Shyamが言及した独立したAPIでも同じ動作が期待できます。同じファイルをアップロードし、モデルを使用するか、そのまま使用して、ガードレールの介入を確認できます。これは、Amazon Bedrock Guardrailsを使用して安全なアプリケーションを構築することがいかに簡単かを示しています。それでは、次の講演者に実装についてお話しいただきたいと思います。
KONEのTechnician Assistantアプリケーションの開発プロセス
Talha、ありがとうございます。以前は登壇する際にCDCをバックグラウンドに使っていたのですが、今日はLevel 300のセッションということで、そこまでする必要はないと思いました。 まず皆さんにお聞きしたいのですが、この1週間でエレベーターやエスカレーターを使った方はどのくらいいらっしゃいますか?もちろん、全員ですよね。では、人生でエレベーターに閉じ込められた経験のある方は?5人ですか - この人数だとかなり多いですね。私自身、10歳くらいの時にそういう経験をしました。脱出までに15分ほどかかりましたが、本当に恐ろしい経験でした。
それから35年後、今や私はエレベーター業界のグローバルリーダーで働き、そのような事態が二度と起こらないようにデジタルソリューションの展開に携わっています。私はKONEのHead of Global Partner Strategyを務めています。KONEはエレベーターとエスカレーターのグローバルリーダーとして、未来の都市づくりを目指しています。当社の事業規模についていくつかご紹介させていただきます。私たちの設備は毎日20億人の移動をサポートしており、皆さんも必ず当社の設備を使ったことがあるはずです。現在、世界60カ国で約170万から180万台の設備を保守管理しており、保守担当者は1日あたり約10万回の保守点検を行っています。当社の戦略として、すべての従業員のデジタル化を進めています。
現場でデジタルを活用した顧客価値を提供するため、社内業務のデジタル化において、いくつかの重要なソリューションがあります。顧客向けの業務に関して、特に強調したいのが予知保全ソリューションです。これは当社のデジタル主力サービスで、これによって閉じ込め事故を平均50%以上削減することができました。私たちはこの取り組みを継続しており、すでにグローバルで展開済みのソリューションもあれば、グローバル展開を進めながら、その上にさらに接続レイヤーを追加しているものもあります。
ここで、私たちがGenerative AIを使って開発した特定の製品についてお話ししたいと思います。Generative AIのユースケースは保守業務にあり、私たちが解決しようとしている課題は2つあります。1つ目は、私たちが保守している製品が、エレベーター、エスカレーター、自動ドア、入退管理ゲートなど、非常に多様な設備で構成されているということです。実際の課題は、その設備を製造しているメーカーが数十社、あるいは数百社にも及び、業界の慣習として、どのメーカーも他社の設備を保守するということです。つまり、1000種類以上のエレベーターが存在し、1人のフィールドサービスエンジニアがそのすべてを知ることは不可能なのです。
もう1つの課題は世代交代です。ほとんどの先進国で人口ピラミッドが逆三角形になっており、人口の高齢化が進んでいます。つまり、専門的なフィールドサービス人材が退職し始めているのに、若い世代があまり入ってこないのです。特に、デジタル体験やデジタルエンパワーメントがなく、本来やるべき仕事に集中できない場合、このような仕事は魅力的ではありません。幸いなことに、Generative AIのようなソリューションやツールを使えば、これらの問題の両方に対処することができます。
先ほど述べた、技術者が問題を解決できないケースに対して、私たちはTechnical Help Deskというソリューションを用意しています。コールセンターにTechnical Help Deskを設置し、そこには経験豊富なField Service Engineerがエージェントとして常駐しています。彼らはユーザーマニュアル、フィールドサービスレポート、過去のメンテナンスレポートなど、あらゆる関連文書にアクセスできる環境を持っており、特定の機器に関する情報を掘り起こして現場の技術者をサポートすることができます。ただし、この方法では数時間かかることもあり、誰かと連絡を取るだけでも30分はかかってしまいます。
そこで私たちが新たに開発したのが、その間に入る生成AIアシスタントです。これは基本的にモバイルアプリケーションで、同じ文書類にアクセスでき、数分で同様の回答を提供できるため、問題解決のプロセスを大幅にスピードアップし、カスタマーサービスを向上させることができます。もちろん、これはKONE単独で実現したものではなく、AWSと密接に協力して開発したものです。
私たちは昨年後半、生成AIが注目を集めていた時期にこの取り組みを開始しました。当初は具体的に何をすべきか分からなかったものの、世界60カ国で4万人のプロフェッショナルを擁する私たちのフィールドオペレーションには、生成AIで解決できる大きな課題があることは分かっていました。パートナーシップを通じて、AWS Gen AI Innovation Centerに早期アクセスする機会を得ることができ、この分野の真の世界クラスの専門家たちと協働することができました。
4週間の共同プロジェクトを通じて、機器のメンテナンスに関するフィールドオペレーションの課題を、この技術でどのように解決できるかの実証実験を行いました。結果は非常に有望だったため、Prototypingチームに移行し、5週間の開発スプリントを通じて、現場に展開可能な最初の実用的なプロトタイプを作成しました。フィールドでの検証は今年初めに開始され、第一段階としてTechnical Help Deskのユーザー約50名が参加しました。この初期フェーズは、ソリューションのテストと改善に重要な役割を果たしました。
主なポイントは、これらのスタッフが、このソリューションが実際に解決している課題と同じ課題を解決できるかどうかを比較できることでした。それが実証されたため、私たちは実際のエンドユーザーであるField Service Engineerへの展開という次のパイロットフェーズに進みました。現在、アジアとヨーロッパでそれぞれ2カ国、4つの言語で約250名が利用しており、実際のエンドユーザーからのフィードバックに基づいて継続的に改善を重ねています。
Technician Assistantの技術的実装とAmazon Bedrockの活用
年末に向けて、私たちは継続的にソリューションの最適化を行ってきました。特に、より優れたモデルへの移行を進めてきました。これについては、後ほど同僚のTalhaが詳しく説明します。 また、文脈的な根拠付けと関連性チェックを目的として、Amazon Bedrock Guardrailsの評価も行いました。私たちは既に自社のドキュメントを使用しているため、これらのソリューションは既に導入済みです。評価の結果、これはその目的に最適なツールであることが分かり、このGuardrailingの一部となる予定です。将来的には、有害かどうか判断できないサードパーティのデータを含めることや、マルチモーダルサポートへの拡張を行うため、現在の制限を超えて進化させていく予定です。
それでは、これがどのように実装されているのか、同僚のTalhaが説明します。 KONEのGenerative AIの取り組みについて説明いただき、ありがとうございます。KONEが歩んできた素晴らしい道のりですね。ここで少し視点を変えてみましょう。皆さんはre:Inventに来られましたが、金曜日か土曜日に荷物を詰めた時のことを思い出してください。全ての持ち物を詰め込みましたか?それとも、この1週間で本当に必要なものだけを選んで詰めましたか?スーツケースに不要なものを詰め込むと、それは役立つどころか重荷になってしまいます。必要なもの、重要なものに焦点を当てることで、より良い旅になるのです。
これは、まさにKONEが実践してきたことでもあります。 このパイプラインについて、詳しく見ていきましょう。このパイプラインは比較的シンプルですが、複雑なユースケースを可能にします。KONEの技術者は複数の国で働き、何百もの機器を扱っています。これにはいくつかの課題があります。どんな課題でしょうか?まず、入力の理解です。Teroが言及したように、現在は4カ国で運用していますが、グローバルでは60カ国以上のポートフォリオを持っています。これらの異なる場所での言語、人々、文化などを理解することが非常に重要です。
次に、必要な情報の抽出です。ユーザーはアプリケーションに文字通り何でも入力できます。しかし、そのうちどれだけが実際に有用なのでしょうか?入力から必要な情報を取得することが本当に重要です。そのための前処理が重要になってきます。入力は必要に応じて前処理され、データの加工や必要な変換が行われます。KONEはこの前処理の部分を柔軟に保っているため、異なる国、市場、製品に展開する際にも、この前処理ステップで対応できます。
このユースケースの中核を支えているのは、リスクアセスメント文書、承認済みマニュアル、必要な情報を含む機器データベース、THDエキスパートからのアドバイス、そして診断における過去のケース(以前のケースがどのように処理され、技術者がどのようなアプリケーションを使用する必要があったか)を含むデータです。このレイヤーは、目の前のタスクに最も適切で有用なものを見つける責任を担っています。データには必要な情報が含まれていますが、技術者が最高の仕事をするために、すべてのデータが本当に必要または関連しているわけではありません。
最高品質で正確なレスポンスを提供するためには、新しいデータの中から最も関連性の高い情報を絞り込むための評価チェックを行う必要があります。関連性の高い情報が特定されると、テキスト生成のステップに移ります。これらのパズルのピースがすべて揃うと、テクニシャンがサポートを呼ぶことなく作業を行えるように、レスポンスが生成され共有されます。
これは比較的シンプルなパイプラインですが、エンドツーエンドで複雑なユースケースを解決します。エンドツーエンドのパイプラインは、機器IDと特定の質問を含むテクニシャンの入力から始まります。最初の部分では、与えられた機器IDに対して、扱っている機器の初期診断を行います。データベースから関連情報が探索され、その特定の機器で発生した可能性のあるイベントが取得されます。初期診断レポートが生成され、テクニシャンにすぐに共有されるので、彼らは対処すべき状況を理解することができます。
この処理が行われている間、テクニシャンから提起された質問という形での課題は前処理段階に進みます。KONEはグローバルに事業を展開しているため、質問は様々な言語から一つの言語に標準化するために翻訳が必要かもしれません。これにより、関連文書から取得するデータを組み合わせてクエリを生成することができます。Vector Databasesがセマンティック検索のために探索され、文書が取得されます。しかし、取得された文書のすべてがそのユースケースに実際に関連しているわけではないため、コンテキストの評価が重要となります。
これらの文書はすべてチェックを受け、本当に必要なものだけが通過します。文書が収集されると、テクニシャンが故障したエレベーター、エスカレーター、その他の機器を修理できるように、指示が生成されます。プロセスはそこで終わりではありません - テクニシャンがこの複雑な作業の中で直面する可能性のある事態に備えて、フォローアップの質問も生成されます。
重要な側面の一つがコンテキストの評価です。KONEは、データを保護するだけでなく、テクニシャンを無関係または潜在的に有害なコンテンツから守ることを重視しています。彼らは、元の問題と取得した文書を特定のモデルに提供する「LLM as a judge」というテクニックを開発し、その文書が実際に関連性があるかどうかを判断します。これにより、関連性なしの場合は0、関連性ありの場合は1というバイナリスコアが生成されます。これにより、実際に必要な文書を絞り込むことができます。
最終結果を生成するにあたって、いくつかの重要なコンポーネントがあります。プロンプトには、理由とスコアの両方を必要とするモデルへの指示が含まれています。この手法はKONEにとってうまく機能しましたが、1回の処理に1.02秒かかりました。1.02秒は短く感じるかもしれませんが、エンドツーエンドの処理全体では大きな負担となります。そこで、Amazon Bedrock Guardrailsが同じ目的を達成するための次善の候補として選ばれました。
KONEはGuardrailsの関連性チェック機能の実験を開始し、より迅速で費用対効果の高いレスポンスを得ることができました。これは完全マネージド型のソリューションで、メンテナンス不要で簡単に統合できます。さらなる利点として、KONEは詳細なスコアを受け取ることができ、二値ベースのスコアリングからドキュメントの合格判定に特定のしきい値を設定できるスペクトラムへと移行できました。この実装とテストにより、処理時間が大幅に短縮され、1回あたり1.02秒かかっていた処理が、プリプロダクションテストでは0.48秒で完了するようになりました。これは2倍の高速化であり、自社開発のソリューションと比較してコストを38%削減することができました。
このパイプライン全体で最も重要な側面は、KONEが保有する人々とデータの両方を保護するコンテキストの評価です。このパイプラインの主要コンポーネントを振り返ってみると、Technician Assistantのユースケースにおいて、LLMsが様々な場面で役立っています。Amazon Bedrockが提供するモデルの選択肢により、KONEは異なる目的に応じて異なるモデルを使用し、最適な価格性能バランスを実現することが可能になりました。
先ほど申し上げたように、自分に本当に役立つものだけをスーツケースに入れておく必要があります。例えば、KONEではClaude 3 Sonnetをクエリの生成とデータベースとのマッチング、そしてフォローアップの質問に使用しています。また、ドキュメントの関連性評価にはClaude 3 Haikuを、技術者向けの正確な指示の生成にはClaude 3.5 Sonnet v1を使用しています。
この取り組みはそこから始まったわけではありません。現在、KONEは利用可能な最新のAnthropicモデルを使用していますが、それが最初からではありませんでした。KONEはAmazon Bedrockのサービス開始当初からイノベーションパートナーとして参加し、サービスとそのモデルの進化とともに着実に成長してきました。KONEはAWSと協力して、Bedrockのプレビュー時代からGenerative AIの旅を始め、Claude 1.3モデルからClaude 3.5 Sonnetを経て、将来提供される最新モデルへと進化を続けています。
これらのコンポーネントすべて、つまり入力の前処理から出力の生成まで、その間の関連文書の取得、それらの妥当性評価、評価ステップ、適切なモデルの選択といった一連のパイプラインにより、KONEは技術者から最小限の入力で、最も関連性が高く、最高品質の回答を生成できるようになりました。実際の本番環境での動作をご覧いただくために、もう一度ご案内させていただきます。
Technician Assistantの実績と今後の展望、セッションのまとめ
エンドユーザー側については既にご覧いただきましたが、もう一度数字を確認させていただきます。私たちには約40,000人のField Service Engineerがおり、毎日約100,000件の保守点検を行っています。また、毎月約30,000件のTechnical Help Deskへの問い合わせがあります。まさにグローバルな規模の課題に直面しているのです。Field Service Engineerたちは、Field Service Management Toolを使用しており、そこにTechnician Assistantアプリケーションを実装しています。彼らは作業している特定の機器に対して、自動診断を開始することができます。
まず、ソリューションは作業している機器が正しいものであることを確認します。確認が取れると、デフォルトで過去12ヶ月の保守記録のサマリーを自動的に保持し、その特定の機器に対して過去12ヶ月間に行われた作業内容と、発生した障害があればそれも表示します。次に、最近の故障データを取得します。この例では、現在アクティブなアラートはないものの、特定の故障が1,414回発生しており、これが問題の原因である可能性が非常に高いことを示しています。
故障コードの意味が分からない場合、アプリケーションはその内容の要約を提供し、考えられる根本原因とその解決方法も示します。また、あらかじめ用意された質問のセットが表示され、該当する質問がない場合は、自分で問題を記述することができます。これは特定の問題の解決方法を尋ねるものではありません。Technician Assistantはドキュメントを参照してガイダンスを提供し、図面や図表などの関連ドキュメントに直接アクセスできます。必要な情報のみを利用可能にすることで、現場でどのような問題が発生しても素早く解決できる、非常に効率的な方法となっています。
私たちの成果についてですが、現在までにこのソリューションで数百件の問題が解決されています。先ほど申し上げたように、現在4カ国で250人の技術者が使用しており、このソリューションが的確で、開発している機能が実際に現場で必要とされているものであることを確認するため、ユーザーと日々やり取りを行っています。技術者からは多くの評価の声をいただいていますが、特に最後の「若手にも、現役世代にも、ベテランにも役立つ」という声が印象的です。これは、必要な情報のレベルに応じて適切な情報が得られるということを意味しています。特定の問題の解決方法を一歩一歩手取り足取り教えてもらいたい場合はそれが可能ですし、十分な経験があって深い部分まで踏み込みたい場合もそれが可能です。さらに嬉しかったのは、最初のパイロットフェーズで、ユーザーにいつでも離脱できる選択肢を与えたのですが、誰も離脱しなかったことです。ある技術者は、パイロット期間が終わってこのツールを取り上げられてしまうのではないかと心配していたほどでした。これは、私たちが本当に重要なものに取り組んでいることの証です。
今後は、データソースを充実させることでソリューションを強化していきます。先ほど申し上げたように、サードパーティのデータの活用を開始していますが、その際には有害なコンテンツを排除するためのSafeguardingとGuardrailsが重要になってきます。60カ国、4万人のフィールドサービスエンジニアを対象としたグローバル展開を予定しており、これは非常に大規模な導入となります。
テキストベースのやり取りだけでなく、音声、画像、動画にも対応を広げていく予定です。最近発表されたリリースは、今後非常に重要な意味を持つことになるでしょう。私たちはAWSとの素晴らしいパートナーシップを継続していきます。このパートナーシップのおかげで、高性能なFoundation Modelに早期段階で容易にアクセスすることができています。また、世界クラスの専門家に直接アクセスできるため、私たち自身がすべてを知る必要がなく、プロセスやお客様への価値提供に集中することができます。
そして、AIとKONE AIを活用したサービスにおいて、イノベーションのリーダーであり続けたいと考えています。KONE AIに関しては、現在30以上のユースケースがポートフォリオにあります。Technician Assistantのように既に本番環境で稼働しているもの、本番環境に近いもの、初期段階のものなど様々です。今後、ユースケースの数は爆発的に増加すると確信しており、この点について次のステップでお話しさせていただきます。
ありがとうございます。なんと魅力的なストーリーでしょう。Guardrailsのプロダクトマネージャーとして、私は本当に感銘を受けました。このような実例こそ、私が大好きなものです。これは現実のものです。私たちは日常的にエレベーター、エスカレーター、動く歩道を利用していますが、これらが驚くべきスピードで進化するテクノロジーとどのように結びついているか想像してみてください。改めて、ストーリーの共有に感謝いたします。今後も引き続き皆様との協力を楽しみにしています。
このセッションを楽しんでいただけたと思います。最後に、いくつかの有用なリソースをご紹介させていただきます。私たちのプロダクトページと、この15分間でお伝えした内容の詳細が記載されているユーザーガイドをご確認ください。また、Amazon Bedrock GuardrailsのGitHubサイトにはコードサンプルも用意しています。ぜひチェックしてみてください。皆様の環境で活用できる数百の実例が用意されています。
明日は、Bedrock Guardrailsに関する様々なストーリーを扱う2つのブレイクアウトセッションを含む、複数のセッションで旅を続けます。ぜひご参加ください。特に、自動推論の詳細に踏み込むAutomated Reasoningのセッションへの参加をお勧めします。また、Guardrailsを実際に体験したい方のために、明日の午後に素晴らしいワークショップをご用意していますので、ぜひご参加ください。本日の午後にご参加いただき、誠にありがとうございました。今後もAWSで皆様とご一緒できることを楽しみにしています。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion