re:Invent 2025: SlackがAmazon BedrockとNovaでコスト90%削減とユーザー満足度向上を実現
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Delighting Slack users safely and quickly with Amazon Nova and Bedrock (AIM384)
この動画では、SlackがAmazon BedrockとNovaを活用してSlack AIを数百万ユーザーに提供するまでの実践的な取り組みが紹介されています。SageMakerからBedrockへの移行により、15以上のLLMを本番環境で運用可能にし、顧客基盤の拡大にもかかわらず90%以上のコスト削減(2000万ドル以上)を実現しました。FedRAMP Moderate準拠を維持しながら、Provisioned ThroughputからOn Demandへの移行、クロスリージョン推論の活用により利用効率を大幅に向上させています。また、LLM as a judgeやAmazon Bedrock Guardrailsを活用した独自の実験フレームワークを開発し、品質を客観的に測定する仕組みを構築しました。検索クエリ理解機能ではNova Liteへの切り替えでP50レイテンシーを46%削減、コストを70%削減しながら品質を維持。最終的に月間アクティブユーザーあたりのコストを90%削減し、運用規模を5倍に拡大しながらユーザー満足度を15-30%向上させた成果が報告されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
生成AIアプリケーションの本番環境化への挑戦：SlackとAmazon Bedrockの事例紹介
こんにちは、皆さん、こんにちは。今週のre:Invent 2025を楽しんでいただけていることを願っています。本日はお越しいただきありがとうございます。実際に始める前に、ちょっと挙手をお願いしたいと思います。すでに生成AI アプリケーションを構築して、実際にユーザーの皆さんを支援し、彼らの生活をより効果的に、あるいはより生産的にしようとしている方はどれくらいいらっしゃいますか?さあ、挙手をお願いします、遠慮しないでください。なかなか良い数ですね。これは本当に、この数年間で業界がどれほど素晴らしく変革してきたかの証だと思います。
考えてみてください、すべては初期の研究開発から始まり、それが最初のフロンティアモデルのセットにつながりました。それらは私たちに、そして全世界に、ユーザーが自分自身の自然言語でシステムとやり取りし、創造的に応答するという可能性と技術の可能性を示してくれました。それによって、今日では多くのツールが生まれました。それらは、自分で質問に答えられないときに情報を検索してくれるだけでなく、与えられた説明やキャプションに基づいて新しいリッチメディアコンテンツを生成してくれます。さらには、新しいコンセプトをプロトタイプとして人々と共有したい場合や、アプリケーションのギャップを埋めたり、小さな修正を行いたい場合に、まったく新しいコードを生成することもできます。この数年間で業界はそれほど急速に進化したのです。
しかし、何かをデプロイしたと言った皆さん全員が、おそらくそのようなアプリケーションを本番レベルの品質にまで持っていく際に伴うすべての課題も目にしてきたと思います。時間をかけてユーザーに提供しても安心できるレベルの品質にするための課題です。それでは、私の名前はGene Tingです。Amazon Web Servicesのプリンシパルソリューションアーキテクトです。そして本日は、SlackのAustin BellさんとShaurya Kethireddyさんにご参加いただき、彼らがそれらの課題を克服し、Amazon Bedrock とNovaを使って世界中の何百万ものSlackユーザーを喜ばせるための旅についてお話しします。
本番環境に耐えうる生成AIアプリケーション設計の基本原則とAmazon Bedrockの活用
それでは始めましょう。生成AIアプリケーションを本番環境に耐えうるものにする には、高いレベルで見ると、過去により伝統的なアプリケーションで考えてきたのと似たようなステップに従います。誰に向けて 構築しているのか、彼らがどのようなペルソナなのかをよく考える必要があります。それがユーザー要件と、アプリケーションを設計するために考える機能を定義します。 これらの決定がなされたら、信頼性、運用の卓越性、コスト管理について考える必要があります。特にアプリケーションが時間とともに成長するにつれて。常に、アプリケーションを有害な損傷から保護し、ユーザーセッションとそのデータを保護できるようにしたいと思うでしょう。
しかし、生成AIアプリケーションにとって新しく、興味深いニュアンスとなるのは、 システムが実際にユーザーに安全な方法で応答できるようにする方法と、システムが設計したワークフローやリクエストのタイプのみを処理するようにする方法です。ですから、 ユーザー要件を定義し、生成AIアプリケーションを設計する際に 考えるべき重要な要素には、いくつかの側面があります。時には、静的なLLMワークフローを通じて機能を構築するかどうかを考える必要があります。時には、より動的なエージェント的なワークフローをどのように適用できるかを見たいと思うでしょう。しかし、これらに共通しているのは、達成しようとしているタスクに基づいて、すべて異なるレベルの複雑さを伴うということです。
検索フレーズに答えて検索結果のリッチなサマリゼーションを返すなど、瞬時にあるいはできるだけ早くリアルタイムで応答したい場合があります。一方で、大量の会話スレッドやテキストを取得して、それを日次ベースでサマリーしたい場合もあります。これらはレイテンシーにあまり敏感でないタイプのワークフローです。しかし重要なのは、従来のアプリケーションと同様に、その時点で検討されているユースケースのタイプに基づいて、ユーザーにとってのレイテンシー感度を常に認識し、意識しておく必要があるということです。
ここでAmazon Bedrockの出番です。異なるタスクに対する異なる複雑さについてお話ししましたが、Amazon Bedrock内には実際にそれらのタスクを達成するために選択できる多くのモデルがあります。
これらの選択肢を持ち、その選択を行うことで、達成しようとしているユースケースのタイプに最適なものを見極めることができ、また時間の経過とともにコストを管理するのにも役立ちます。同様に、リアルタイムレスポンスか非同期レスポンスかを判断する際にも、Bedrockでは選択肢があります。provision throughput、priority tiers、または大半の質問に答えるためのstandard tierを選択できます。もし急いで質問に答える必要がない場合は、batch inferenceやflex tierに一部の推論を先送りすることもできます。これらの選択を行うことも、コスト管理に役立ちます。
アプリケーションが成熟し、時間の経過とともに改善されていく中で、それらのモデルをどのようにアップグレードし、置き換えていくかについての戦略を持ちたいと思うでしょう。同じモデルの新しいバージョンにアップグレードするか、同じタスクを達成できると思われる別のモデルにアップグレードするかです。また、時間の経過とともにモデルのレスポンスを反復的に最適化する方法も必要です。ここでAmazon Bedrockのprompt managementとprompt tuningが役立ちます。LLM as a judgeを使用し、カタログ化したプロンプトのセットを持つことで、実際にそれらを異なるモデルに適用して時間の経過とともに比較することができます。prompt tuningを使用し、prompt optimizerを使って、基本的に異なるプロンプトとコンテキストを送信して結果を確認する方法について提案を得ることができます。
大規模運用のための監視戦略、セキュリティ設計、そしてBedrock Guardrailsによる安全性確保
これらすべての基本的なアプリケーションの決定が行われた後、どのように運用し、基本的に大規模に実行していくかを考えたいと思います。まず、ユーザー要件や規制上のニーズに基づいて、実際にアプリケーションをホストするためにどのリージョンを選択するかという選択から始めます。これによって、Bedrockとのインタラクションを開始する場所が定義されます。すぐにモニタリング戦略を確立したいと思います。そこから、リクエストに対するtime to first tokenを監視することになります。Amazon CloudWatchメトリクスを使用して、エンドツーエンドのレイテンシー、エラーの発生頻度、スロットリングの発生頻度を実際に確認することもできます。例えばCloudWatchログや独自のロギングシステムを使用して、エージェントがどのように応答しているか、またはバックエンドでLLMが何をしているかを実際に確認したいと思います。
パフォーマンスのためにチューニングできるようにしたいですよね。そのため、パフォーマンスのためのチューニングには、常に何らかのキャッシング戦略が関わってきます。例えば、Bedrock上で明示的なプロンプトキャッシングを使用して、共通で頻繁に使用される入力を実際にキャッシュすることで、その入力を入力トークンに変換する際の時間とコストを節約できます。そして、Bedrockがコスト管理を支援するためのモデルの柔軟性を持っていることについてお話ししました。これはレジリエンシーの面でも非常に役立ちます。つまり、何らかの理由でモデルが誤動作し始めたり、そのモデルに関して可用性の懸念がある場合、アプリケーションをカバーできるように、常により深いモデル戦略を確立しておく必要があります。
アプリケーションが時間とともに本当に成長していくにつれて、それらのモデルをホストしている容量を持つ他のリージョンを使用できるようになります。Bedrockのクロスリージョン推論を使用すると、同じ大陸上であろうと地球の反対側であろうと、そのモデルをホストしている別のリージョンにリクエストを実際に送信するよう指示できます。設計によるセキュリティは、アプリケーションを本番環境化する上で常に不可欠な部分です。以前お話しした基本的なブループリントから始めると、まず安心していただけるのは、Bedrockはモデルプロバイダーが実際にモデルをホストしている環境にアクセスできないように設計されているということです。そして反対側も同様に、設計上、Bedrock上で使用するモデルに入力され、モデルから出力される入力と出力を共有することはありません。
IAMポリシーを適用して、組織内および環境内の特定の部分と特定のユーザーのみがBedrock上ですでに活用を開始しているモデルに実際にアクセスできるようにします。サービスコントロールポリシーを使用して、組織が承認した特定のモデルのみがインフラストラクチャ内で実際に利用可能であることを確認します。VPCエンドポイントによる追加の制御もあり、インフラストラクチャを通じてAmazon Bedrockに到達するには特定のパスを通過する必要があります。そして、Bedrock上で利用可能な場所ならどこでも容量に到達できるようにクロスリージョン推論を使用することについてお話ししたことを覚えていますか。特定の規制要件やデータ主権のニーズに基づいて、そのクロスリージョン推論の動作を、選択した特定の地理的な場所のみに制限することもできます。
では、アプリケーションが安全な方法で応答し、特別に設計したものだけを処理するようにすることに関するこのニュアンスに戻りましょう。基本的なリクエスト-レスポンスのワークフローについてお話しします。ユーザー入力側を見ると、Amazon Bedrock Guardrailsを適用して、特定のキーワードをフィルタリングできます。基本的に危険なコンテンツを拒否できます。システムに処理させたくない他のタイプのカスタムトピックを実際に選択できます。そして、これらのポリシーのいずれかがトリガーされた場合、Bedrockにカスタムのモデレート済みレスポンスで応答させることができます。
スペクトルのもう一方の端では、初期入力が精査されてモデルに入力された後、Bedrock Guardrailsに再度同じタイプのポリシーを適用させ、ユーザーにレスポンスを送り返す前に正確性のための追加の自動推論チェックを追加できます。さて、アイデアから本番環境への移行方法に関する基本的なブループリントについてお話ししましたので、最大級の顧客の1つであるSlackが、これらの原則と厳密さの一部をどのように適用して、Slack AIを効果的に、安全に、そして効率的に実際に提供しているかを見てみましょう。それでは、Austinさん、お願いします。
Slack AIの全体像：製品全体へのジェネレーティブAI統合の取り組み
素晴らしい、Geneさん、ご紹介ありがとうございます。そして皆さん、お集まりいただきありがとうございます。これから私たちSlackが、Slack AIの機能をいかに効果的に、安全に、そして効率的に提供しているかについてお話しさせていただきます。具体的には、私たちの目標は、Slack製品全体にジェネレーティブAIを浸透させることです。ジェネレーティブAI機能の80%まで到達するのは非常に簡単です。しかし、本当に差別化要因となり、他社と一線を画すのは、残りの20%、つまりコスト効率を高めたり、より高い品質を実現したりすることなのです。このプレゼンテーションでは、私たちSlackがどのようにスケールを実現し、品質要件を満たすことができたのか、その道のりについてお話しします。
具体的には、3つの異なる領域についてお話しします。まず、高度なセキュリティを確保し、すべてのコンプライアンス要件を満たす形で、スケーリングのニーズに応えることができたインフラストラクチャ層をどのように開発したかについて説明します。次に、ジェネレーティブAIの出力品質を客観的に測定し、実際に品質を確実に向上させているという確信を得ることができた、社内実験フレームワークをどのように開発したかについてお話しします。最後に、これら2つのセクションがどのように組み合わさって、製品全体にジェネレーティブAIをよりシームレスに統合できるようになったかについてお話しします。
しかしまず、私たちについて少しご紹介します。私の名前はAustin Bellです。Slackで機械学習、検索、そしてAIを担当するディレクターを務めています。そして同僚と一緒に参りました。皆さんこんにちは、私の名前はShauryaです。Slackでインフラストラクチャとプラットフォームチームに携わるエンジニアをしています。では、少し前提を揃えさせていただきますが、Slackが何であるかについてはある程度ご存知であることを前提としますが、Slack AIの提供内容についてご存知ない方のために、私たちは複雑さとユースケースの幅広いスペクトラムにわたる、十数種類以上のジェネレーティブAI機能とツールをサポートしています。
例えば、さまざまな製品のサーフェスエリアにわたってAIサマリー機能を提供しています。Slack内に保存されているデータに関連する質問をしたり、情報を見つけたりできる社内QAシステムがあります。また、進行中のすべてのことを非常に素早く把握できるデイリーダイジェストを作成する機能もあります。これらはほんの一部の例であり、非常に定期的にさらに多くの機能を追加し続けています。では、最初のトピックについて、同僚のShauryaに引き継ぎます。彼がSlackでインフラストラクチャ層をどのように構築したかについて説明します。
SageMakerからの出発：初期インフラストラクチャの課題とスケーリングの限界
Austinさん、ご紹介ありがとうございます。皆さんこんにちは、私たちが持つ数百万人のデイリーアクティブユーザーに対して、Slack AIをどのようにスケールさせているかについてお話しします。一般的にジェネレーティブAIについて話すとき、通常はスピードについて、つまりトークンがどれだけ速く生成されるか、製品がどれだけ速く動くか、そして市場がどれだけ速く動いているかについて話します。しかしここSlackでは、信頼という別の要素も加えています。私たちは、使用するサービスが顧客のデータを保護するために必要な信頼性を持ち、お客様が私たちのプラットフォーム内で安心して作業できるよう、お客様からの信頼に応えることを保証しています。
私たちが通常大切にしている言葉の一つに、スケーラブルなインフラストラクチャの真のテストとは、それがどれだけ速く成長するかだけでなく、成長するにつれて重要なものをどれだけうまく保護するかである、というものがあります。ご想像の通り、多くの人々がSlack内にすべての作業コンテンツを保存しています。私たちは、どのような機能を追加するにしても、ユーザーがSlackで作業を続けられるようにし、障害を追加する必要がないようにしたいと考えています。
Slack AIをどのようにスケーリングしているかという技術的な側面に入る前に、私たちの機能に対するプロダクトの約束について少し背景を説明したいと思います。最初の柱はtrustです。Slack AIのスケールアウトを開始したとき、お客様から多く寄せられた質問は、私たちのデータが生成AIモデルのトレーニングに使用されているのか、というものでした。答えはノーです。私たちはお客様のデータで生成モデルをトレーニングしていません。お客様のデータをログに記録していません。また、Slackワークスペースの管理者が機能をオプトアウトできるようにしています。つまり、管理者は特定の機能をオプトインしたり、オプトアウトしたりできるということです。また、データの保持期間はゼロであり、LLMプロバイダーに送信されるデータは共有されません。Geneが述べたように、入力と出力は共有されません。
2番目の柱はsecurityです。私たちはFedRAMP Moderateコンプライアンスの領域で運用しているため、使用するサービスが連邦ガイドラインによって設定された厳格な基準を満たしていることを確認しています。また、使用するサービスが私たちのトラストバウンダリー内に留まるようにしています。多くのデータが移動しているためです。また、技術的なアクセス制御も行っています。つまり、例えばプライベートチャンネルにメッセージがある場合、そのチャンネルに参加していない人がアクセスできないようにしたいのです。メッセージや共有される回答のセキュリティを確保しています。
3番目の柱はreliabilityです。trustとsecurityを持つだけでは十分ではありません。機能が高可用性である必要もあります。これにより、お客様が日常のプロセスで実際に使用できるようになります。さらに、contextual relevanceも必要です。つまり、お客様がリクエストを送信するときに、実際に求めているものに関連する回答を確実に得られるようにしたいのです。そしてtransparencyも必要です。つまり、回答を得たときに、可能な限り引用を追加できるようにし、お客様がLLMがその特定の回答を生成するために使用した可能性のある元のメッセージまで遡れるようにします。
これらすべての柱を持つことは、10人のユーザーがいる場合は非常に簡単かもしれませんが、Slackが現在どのように運用されているか見てみましょう。毎週、私たちは10億から50億以上のメッセージ、1億から5億のファイル、そして10億から50億の検索を処理しています。ご覧の通り、Slackは大規模なスケールで運用されています。AI機能をパブリックAPIに接続して最善を期待するだけではいけません。使用するサービスが舞台裏で適切にテストされ、セキュリティとトラストの姿勢を確保しながら、何百万、何十億ものリクエストを難なく処理できることを確認する必要があります。
それでは、製品のコンテキストとSlackのスケールについて説明したところで、2023年半ばから2024年半ばまで、私たちがどのようにSlack AIを提供していたかという過去の旅から始めましょう。当時、私たちには限られたLLMの選択肢しかありませんでした。コストが高く、柔軟性が低く、プロビジョンドスループット環境で運用していました。そこから現在では、高い柔軟性、高い利用効率、そして信頼性の向上を実現した未来へと進化しました。
2023年半ばに最初に始めたとき、私たちはAmazonが提供するサービスの中で、FedRAMP Moderateコンプライアンスの範囲内にあり、かつ私たちのセキュリティとトラストポスチャーに準拠しているものを探していたので、SageMakerから始めました。背景として、Slackは主にUS East Oneリージョン内で運用されており、Slackインスタンスを含むVPCがあります。そこからリクエストはVPCエンドポイントを通過します。Slack AIリクエストは、基本的にAWSの内部ネットワークを通過することを可能にし、そのリクエストはSageMakerエンドポイントに送られます。これは基本的にモデルのラッパーです。最初に始めたとき、私たちはモデルを1つしか持っておらず、このモデルはプロビジョンドスループット方式で提供されていました。また、VPC内に
concurrency checkerと呼ばれる小さなボックスがあるのが見えるかもしれません。これは負荷を維持するために使用しているものです。ピーク負荷の時には、優先度の低いリクエストを削減することができました。例えば、内部的には3つの優先度があります。最も高い優先度はレイテンシーに最も敏感なもの、中程度の優先度は5分から10分のSLA内で完了できるもの、そして第3層の優先度は夜間に実行されるバッチジョブのようなものです。高い同時実行性があり、クラスターがほぼピーク使用率に達しているときに、スケールアップする代わりに、当時は1時間以上かかる可能性がありましたが、非常に迅速に負荷を削減することができました。
これはSlack AIの初期の頃、まだスケールアップしている段階ではうまく機能していましたが、Slack AIも顧客ベースに指数関数的に追加されていることに気づきました。そこで、いくつかの問題に気づきました。1つ目はピーキーなトラフィックでした。2つの異なるタイプのリクエストが入ってきていました。時間に敏感なものとバッチワークロードです。これらは日常的なシナリオではかなり予測可能ですが、スループットの一貫性が異なっていました。また、当時GPUを入手することが困難でした。GPUの不足があったため、Slack AIに追加された新しい顧客ベースのためにスケールアップするために必要なGPUを入手するのに数週間かかっていました。GPUの不足のため、簡単にスケールアップやスケールダウンができませんでした。非ピーク時にもそれらを保持できるように、オンデマンドキャパシティリザーブでGPUインスタンスを維持しなければなりませんでした。
これら2つの問題の影響は、1日の大半でオーバープロビジョニングされていたということでした。これはGPUを稼働させ続けなければならなかったためです。このため、ピークトラフィックをサポートするためにインフラストラクチャをスケールさせていましたが、これは理想的ではありません。基本的にコスト非効率を引き起こすからです。顧客リクエストを提供するために積極的に使用していないインスタンスとGPU時間に対して支払っていました。この固定コストがあるため、LLMを多様化することができませんでした。1つか、せいぜい2つしかありませんでしたが、これは新しいモデルを実験したり、新しい機能を追加したりする際にも私たちを遅らせました。
Amazon Bedrockへの移行：FedRAMP準拠と90%以上のコスト削減を実現した道のり
これらの問題を念頭に置いて、私たちはどこに向かいたいかというビジョンを持っていました。マネージドでありながら、モデルの多様性も提供してくれる新しいサービスを探したいと考えていました。そこで出会ったのがBedrockでした。2024年半ばに、BedrockがFedRAMP Moderate準拠となり、私たちはこのサービスをより真剣に検討できるようになりました。これらすべてのリクエストを信頼境界内で処理できるようになり、またBedrockは入力と出力がプロバイダーと共有されないことを約束しているため、彼らが私たちの入力と出力でトレーニングすることができません。Bedrockには最先端モデルのコレクション全体があるため、これにより私たちのプロダクトエンジニアがより多くの機能を追加できるようになりました。Bedrockでは、モデルレジストリにモデルが追加される速度も速くなっており、これらのモデルが公開されてから1日以内にBedrockプラットフォーム内で利用可能になります。
Bedrockを移行先のサービスとして基本的に決定した後、顧客の信頼を維持し、ダウンタイムなしで非常に信頼性の高い移行を確実にするために、いくつかの移行ステップに従いました。最初の側面はBedrockインフラストラクチャを理解することで、2つの違いはプロビジョンドスループットとオンデマンドでした。SageMakerの世界ではプロビジョンドスループットのインフラストラクチャタイプを使用していたため、移行を容易にするためにBedrockでも同じものを維持し、次の段階でオンデマンドへの移行を処理することにしました。2番目の部分は、内部的な負荷テストを実施し、いくつかのコンピュート計算を行うことでした。これは、すでに持っているSageMakerコンピュートに対してBedrockモデルユニットの同等のものが何であるかを科学的に把握することに取り組んでいたことを意味します。これにより、推測とチェックを繰り返すことなく、同等のコンピュートを取得できるようになりました。
こちらが負荷テストの1つの例です。SageMakerとBedrockの両方でClaude InstantとClaude Haikuを実行することができました。ご覧のように、Claude Instantについては1対1のマッピングのようになっています。つまり、SageMakerをP4Dで実行したとき、それは1つのBedrockモデルユニットと同等でした。Claude HaikuインスタンスをP5インスタンスタイプで実行したとき、2つのP5が1つのBedrockモデルユニットと同等でした。これらの比率を使用することで、同等のコンピュートを取得することができ、Amazon Bedrockサービスチームと協力して、それを私たちのアカウントに提供してもらいました。
そのコンピュートが提供されると、シャドートラフィックの実行を開始できるようになりました。これは、SageMakerにリクエストが送信されるたびに、Bedrockにも重複したリクエストを送信していたことを意味します。これにより、サービスの内部を理解することができました。これは監視ダッシュボードの構築にも役立ちました。レイテンシー、最初のトークンまでの時間、その他の設定していたメトリクスを検証することができました。
シャドートラフィックが2週間100%で実行された後、完全なカットオーバープロセスを開始しました。これも段階的に行われ、1%、5%、10%、そして100%と進めました。これは基本的に、シャドーモードの代わりに、SageMakerサービスではなくBedrockサービスから送信されたレスポンスを提供するようになったことを意味します。Bedrockに移行することで、コスト削減に役立ち、より多くの実験も行えるようになりましたが、このサービスをより効率的にするために取り組むべきいくつかのギャップにも気づきました。
最初の課題は、Provisioned Throughputをスケールできなかったことです。これは依然として静的なコンピュートクラスターであり、そのためコスト効率の面でまだ問題を抱えていました。プラットフォーム側では、バックアップモデルを追加できるようにすることがより有用であることに気づきました。Bedrockモデルにリグレッションが発生した時や、一部の機能が期待通りに動作していないことに気づいた時に、バックアップモデルを追加することで、インシデント発生時にコード変更を行うことなく、本質的にリルートできるようにしました。
また、特定の機能とモデルに対する緊急停止機能も追加しました。これは基本的にバックアップモデルと連動しています。緊急停止がオンになると、機能全体が潜在的にオフになる可能性があり、私たちの側でモデルがオフになった場合、すべてのリクエストはバックアップモデルにリルートされます。Amazon Bedrockを使用することで、モデルが持つさまざまなツールを使用できるようにもなりました。例えば、ツール、プロンプトキャッシング、ガードレール、その他モデルが持つ機能などです。そして、私たちは内部のAIプラットフォームを拡張して、開発者がこれらにアクセスできるようにしました。
Provisioned Throughputから移行する中で、スケールできないことに気づき、この時点でOn Demandの世界に移行することを決定しました。これは異なるインフラストラクチャタイプで、ベアインスタンスではなく、クォータベースになっています。これは1分あたりのトークン数、入力トークン数、そして1分あたりのリクエスト数に基づいて行われます。また、Provisioned Throughput時代に私たちの側で多くのメタデータを持っていたため、メタデータから1分あたりのリクエスト数とトークン数を本質的に計算し、そのコンピュートリクエストをAmazon Bedrockに渡して、それらのクォータを私たちのアカウントに配信してもらうことができました。
SageMakerの世界と同様に、US East OneリージョンにSlackアプリがありました。VPCがSlackインスタンスを保持しています。リクエストはVPCエンドポイントに送られ、すべての内部ルーティングを行い、Bedrockサービスに送られます。そして、リクエストに追加したモデルIDに基づいて、特定のモデルを指し示します。SageMakerのアーキテクチャ図との違いの一つは、並行性チェッカーの代わりに、私たちの側で1分あたりのリクエスト数とトークン数のチェッカーを持っていたことです。これにより、異なる機能を本質的にコントロール下に置くことができ、特定の機能がBedrock全体のクラスターを占有してしまうことを防ぐことができるようになりました。
Bedrock On Demandから得られた別のメリットは、 現在、USクロスリージョン推論プロファイルを使用できるようになったことです。私たちはFedRAMP moderateショップであるため、US境界内に留める必要があり、Bedrockはその能力を提供しています。US West Twoにも展開することで、2つのリージョンから選択できるため、コンピュートをより速いペースで配信してもらえるようになりました。
これらすべてを通じて、マイグレーションの最後には多くの成果を得ることができました。最初に始めた時は、選択できるLLMは1つだけでしたが、マイグレーションの終わりまでに、そして現在の状態では、本番環境で15以上のLLMを実験し提供しています。また、信頼性も向上しました。LLMの柔軟性が高まったことで、特定のモデルにフォールバックできるようになり、インシデント発生時などに素早くモデルを切り替えたり、品質とコストの面で最適なモデルを見つけるための実験を行ったりすることができるようになりました。その上、最も大きな数値的成果は利用効率でした。
マイグレーション全体を通じて、顧客のオンボーディングが進むにつれてSlack AIの利用は指数関数的に増加していました。しかし、顧客基盤が増加したにもかかわらず、90%以上のコスト削減を実現し、金額にすると2000万ドル以上の削減となりました。最後にまとめますと、私たちはインフラをどれだけ速くスケールできるかではなく、スケールしながらデータをどのように保護できるかが重要だという言葉から始めました。Amazonが提供するサービスを利用することで、社内のクラウドチームやプラットフォームチーム、そしてAWS側とも協力しながら、すべてのAI機能を大規模に提供することができました。
生成AIアウトプットの品質測定：社内実験フレームワークの開発と評価システムの構築
ありがとうございました。それでは、高品質でどのように提供しているかについて、Austinにバトンタッチします。Shauryaさん、ありがとうございました。ここで少しギアを切り替えて、生成AIのアウトプットの品質をより客観的に測定できる社内実験フレームワークをどのように開発したか、そして実際にこの品質を向上させるためにどう取り組んでいるかについてお話しします。さて、これはSlackのエンジニアからの言葉なのですが、皆さんもこのような状況に陥ったことがあるかもしれませんが、生成AI機能をデモして、とても見栄えが良くなり、本当にワクワクしています。いよいよ本番環境に投入する時が来ましたが、品質面でいくつかのエッジケースを改善する必要があります。プロンプトを変更し、パイプラインを変更して、実際にリリースしようとします。しかし数日後、実は特定の領域で品質が後退していることに気づき始めます。これがサイクルとなり、モグラ叩きのような状況になります。1つの問題を修正しようとすると別の問題が発生し、数週間経っても実際には品質の改善が見られないのです。
では、なぜこのようなことが起こるのでしょうか。それは、生成されたアウトプットを評価することが難しいからです。私たちは、古典的な機械学習からパラダイムシフトの最中にあります。古典的な機械学習では、オンライン設定ではエンゲージメント指標を活用して品質を評価したり、オフライン設定では精度や再現率のようなものを活用したりできました。生成AIのアウトプットは、はるかに主観的です。私が良いアウトプットだと考えるものは、あなたが良いアウトプットだと考えるものとは大きく異なる可能性があります。また、この生成AIのアウトプットを実際に表示したいプロダクトの表面領域にも依存するかもしれません。そこで問題となるのは、目標を満たし、継続的に改善できるような方法で、実際にどのように測定するかということです。
さて、Slackで私たちが信じている重要なことは、実際に測定する能力があるものだけを改善できるということです。そこで私たちはまず、何を測定したいのかを定義する旅に出ました。私たちはそれを2つの柱で定義しました。品質、つまり答えが実際に求めているものを提供しているか、正確かどうか、そして安全性、つまりSlackで望ましい適切な環境を育成しているか、データを可能な限り安全に保護しているかです。これらのそれぞれについて、さらに細分化しました。品質の面では、2つの別々のカテゴリーに分けました。
まず、客観的な測定についてです。これは、私たちがより決定論的なアウトプットと考えているもので、いわばテーブルステークスのようなものです。適切にレンダリングできること、JSONやXMLの出力を正しくパースできること。IDを正しくフォーマットしているか？リンクを正しくフォーマットしてSlackを適切にナビゲートできるか？こういったものがなければ、ユーザーは気づいてしまいますし、生成AIのコンテンツがどうであれ、実際には関係ありません。なぜなら、ユーザーはこれらの問題を見過ごすことができないからです。より難しい側面として、主観的な測定があります。これは事実の正確性のようなものです：グラウンディングされたコンテキストに基づいて、実際に真実を伝えているか？回答の関連性：ユーザーが実際に尋ねた質問に答えているか？帰属の正確性、これはSlackにとって大きな問題です：正しいコンテンツを正しいユーザーや正しいファイルに帰属させているか？
安全性の側面では、これも2つの別々のカテゴリーに分けました：ハームとセキュリティです。ハームは、有害性に関して測定するものを指します。バイアスを捉えているか？良好な環境であることを保証し、LLMが私たちの価値観に沿った方法で応答しているか？2つ目は、セキュリティです：可能な限りプロンプトインジェクション攻撃から保護しているか？意図しない、あるいは意図的なサーチポイズニングとして行いたくないことを防いでいるか？
さて、これがステップ1で、実際に測定したいものを定義することです。次のパートは、実際にこれを測定する能力を与えてくれる評価器を生成することです。これは最初から旅のようなものでした。私たちはいくつかのことを実現したかったのです。プロダクトエンジニアが、プロンプトの変更やパイプラインの変更に基づいて、小規模なデータセット全体のアウトプットを非常に迅速に手動でレビューできる能力を確保したかったのです。また、品質の柱における客観的な測定を自動化された方法で捉えることができる、さまざまな自動化されたプログラマティックメトリクスを導入したかったのです。これにより、Slackでテーブルステークスと考えているフォーマットやレンダリング機能について、リグレッションが起きていないことを確保できます。
この旅において複雑さを増していて、これが現在のSlackの状況です。より複雑な品質の定義に取り組み始めています。LLMベースの品質メトリクスを活用して、事実の正確性や回答の関連性を測定できるようにしています。安全性とハームの問題を捉えるためにガードレールを活用しています。ここでの全体的な目標は、これらの自動化されたプログラマティックメトリクスとLLMジャッジ、そしてガードレールを組み合わせることで、本番環境をより代表するはるかに大規模なデータセットで生成AIの品質を評価し始めることができるということです。これにより、はるかに大規模な実験やテストを実行する能力が得られます。
さて、ここからどこへ向かうのでしょうか？目標は、基本的に生成AI向けのCI/CDを開発し始めることです。検証済みのアウトプットを定義する能力を与え、一連のテストを自動化できるようにすることで、リグレッションを捉え、より迅速で効率的な方法で品質改善につなげることができます。ここで少し立ち止まって、今お話ししたことについて少し説明させてください。Slackでは、数十種類の異なるタスク固有のLLMジャッジを実行しています。Slackで AI機能を開発する各プロダクトチームと協力して、その特定の機能にとって品質の定義が実際に何であるかについてのルーブリックを作成します。これはすべての機能で変わります。エンジニアに、これらをデプロイするためのコードを実際に書くことなく、ルーブリックを定義するだけの能力を与えることで、非常に迅速にこれらを展開できるようになります。
また、Amazon Bedrock Guardrailsも活用しています。これにより、LLMの入力と出力の両方において、毒性、有害性、プロンプトインジェクションを非常に簡単に測定する能力が得られます。 ここでは2つのステップを強調しています。まず、何を測定したいかを定義し、次にどのように測定するかを定義しました。しかし、エンジニアの生産性を本当に高めるのは、日々の開発体験の中でこれらの機能を活用できるワークフローを開発することです。機械学習のバックグラウンドをお持ちの方には、これは多少馴染みがあるかもしれません。
まず、一連のオフライン実験を行います。私たちがゴールデンセットと呼ぶものから始めます。これらは社内データから検証された出力で、ユーザーがLLMにプロンプトの変更を加え、10から20の小規模なデータセットで手動レビューを実行できるようにします。それに自信が持てたら、バリデーションセットと呼ぶものでの実験実行に移行できます。これらははるかに大規模で、本番データをより代表するものです。このように、これらの自動化されたプログラマティックなメトリクスと品質メトリクスの組み合わせを使用することで、大規模なリグレッションを捕捉し、意図した品質改善を実際に行っていることを確認できます。
ここで重要なのは、各ステップで可能な限り最速のフィードバックループを提供したいということです。これにより、エンジニアは可能な限り迅速に失敗し、振り出しに戻り、より迅速に機能をリリースする能力が得られます。 ここでの目標は最終的にこれを可能な限り自動化することですが、human in the loopを活用することが鍵となります。これらの評価器の開発において私たちは完璧ではないため、エンジニアに変更の影響とLLMレスポンスをデータ全体で非常に迅速に実際に確認する能力を与えることで、大幅に速く進めることができます。
さて、オフライン環境でこれらの多くを検証した後、オンライン評価に移行します。 ここでABテストの実行を開始し、先ほど述べたすべての評価器をABテストにも統合します。これにより、これらの品質メトリクスとユーザーフィードバックメトリクスの両方で実際に測定できるようになります。
本番環境へのロールアウトを実際に決定する前に。ここで重要なのは、あまりに多くのユーザーが実際に目にする前に、品質の変更を行っていること、特定の領域でリグレッションを起こしていないことを実際に確信することです。
少し戻りまして、今お話しした内容の一部について詳しく説明していきます。私たちは通常、3つの異なるタイプのデータセットを扱っています。ゴールデンセットは手動で精査されたもので、非常に小規模で10から50サンプル程度です。これにより、エンジニアが出力を手動でレビューできるようになっています。バリデーションセットは通常100から1000サンプルの範囲です。ここでは自動化された品質評価やプログラマティックなメトリクスが本当に力を発揮します。想像できると思いますが、例えば1000サンプルをレビューするのは人間にとってほぼ不可能ですからね。そしてABテストでは、通常、その特定の機能に対するSlack AIクエリの1%から25%の範囲で実験を実施しています。
これらは素晴らしいのですが、果たして価値があるのでしょうか？ここでは、私たちがSlackで取り組んでいるいくつかの異なる領域を示す3つの例を選んでみました。プロンプトエンジニアリングの面では、最近LLMに送信するコンテンツのシリアライズ方法を変更し、その結果、事実の正確性とユーザー帰属の正確性がそれぞれ5%と6%向上しました。新しいバージョンのモデルや新しいLLMがリリースされると、モデルのアップグレードを頻繁に実施します。最近のアップグレードでは、ユーザー満足度が11%増加し、主要な品質メトリクスも3%から5%向上しました。実際、新しいバージョンがリグレッションを引き起こしたため、ロールアウトしないと判断したこともあるので、現在では実施するすべてのLLMアップグレードに対して、このフローをより自動化された方法で実行しています。品質以外では、コスト管理が重要な領域です。品質を維持しながらコストを削減したり、レイテンシを改善したりしたい場合もあります。最近の変更では、同等の品質のLLMに移行することで、60%のコスト削減を実現しました。
検索クエリ理解への適用：Nova Liteによるレイテンシー46%削減とコスト70%削減の実現
ここまで2つの異なることを個別にお話ししてきました。まず、インフラストラクチャレイヤーをどのように構築したか、これによりLLMをより効率的に活用し、異なるLLM間で選択し、シームレスに切り替える能力を得ることができました。次に、AI出力の品質を実際に測定し、実施したい変更が確実に実施されているという確信を持つことができる、この社内実験フレームワークをどのように開発したかについてお話ししました。このセクションでは、これら両方をどのように活用して、コスト効率を保ちながら、ユーザーが期待する品質とスケールを維持する形で、アプリケーション全体にジェネレーティブAIをよりシームレスに統合しているかを説明していきます。
そのために、いくつかのユースケースを見ていきますが、その前に強調しておきたいのは、ジェネレーティブAIには複雑さのスペクトラムがあるということです。低複雑度の側には、おそらく過去には従来の機械学習モデルで行われていたようなもの、分類、非構造化データから構造化データへの変換、データの解析などがあります。中程度の複雑度に進むと、要約、非常に基本的な画像生成、コンテンツ編集機能などがあります。そして高複雑度の側では、メディアが好んで取り上げるようなもの、エージェンティックワークフロー、動画生成、ツールの使用、こういった大きなものがあります。さて、ここSlackでは多数のジェネレーティブAIアプリケーションがあり、それらは低複雑度から高複雑度まで、スペクトラム全体にわたっています。すべてのユースケースに最先端のフロンティアLLMを使用したくはありませんが、ユーザーへの品質を犠牲にすることなく目標を達成できる、正確に適切なLLMは何かという問いに答えるのは難しい問題です。
それでは、私たちがSlackで検索クエリ理解と呼んでいる、この低複雑度領域に取り組む具体的なユースケースを見ていきましょう。ただその前に、Shauryaが示したスケールのスライドの検索領域を再度見ていきます。さて、私たちはSlackで非常に多くの検索を実行しています。それらの大部分は単に
人を見つけたり、チャンネルを見つけたりすることです。そのうちのごく一部が、データに質問を投げかけたり、大量のメッセージを横断して検索を実行したりするような、非常に複雑な検索になります。この数のほんの一部であっても、効率的に実行していなければ、高いコストにつながる可能性があります。
では、検索クエリ理解とは何でしょうか？ユーザーがSlackに入ってきて、次のような検索語を追加したとしましょう。 FY25のセールスデッキで、John Doeが最近私に送ってくれたものを見つけてもらえますか？さて、これを検索クラスターに直接送信したくないかもしれません。それは役に立たないかもしれませんが、その中には多くの情報が隠されていて、それによって検索をより的を絞ったものにし、実際に探しているファイルやメッセージを見つけられる可能性を高めることができます。そこで、大規模言語モデルのパイプラインを通して実行し、フィルターやその他の関連する可能性のある情報を含むJSONを生成できるようにします。
これを分解してみましょう。実際に検索したいクエリは、その全文ではないことがわかります。おそらく、FY25 sales PowerPoint deckだけでいいのです。これは1つのクエリに過ぎませんが、多くの場合、複数のクエリを並行して実行するので、この検索語の複数のバージョンがあるかもしれません。recentlyという言葉を使っていますので、これは過去3ヶ月という特定の時間範囲に絞り込むことができ、探しているものを見つける可能性が高まることを示しています。セールスデッキを探していると言っているので、それにはプレゼンテーションのようなファイルタイプが含まれている可能性が高いです。ですから、プレゼンテーションを含むスレッドや会話のみに限定できるでしょうか。また、John Doeがあなたに送ったと述べているので、彼が含まれている会話やスレッドだけを見るようにしましょう。
では、これは実際に検索パイプラインではどのように見えるのでしょうか？ユーザーが検索を送信します。 機械学習モデルがあり、これが情報検索なのか、それともナビゲーション検索なのかを非常に迅速に判断できます。ナビゲーション検索の場合は、非常に特定の検索と機械学習ランキングパイプラインを通ります。情報検索の場合は、クエリ理解パイプラインを通って、実際の検索をより的確にターゲティングしようとし、その後、残りの検索取得機械学習、そして最終的にLLMレスポンスに進みます。
では、ここからどこから始めるのでしょうか？私たちには問題がありました。このケースで使用していた既存のLLMは、機能していました。品質目標は達成していましたが、検索レイテンシーの予算を超えており、運用する必要のあるスケールを考えると、非常に高コストでした。そこで、この特定のユースケースで私たちがやりたかったのは、品質を維持しながら、同時にレイテンシーとコストの両方を削減できるプロンプトエンジニアリングに切り替える、または活用することでした。さて、利点は、これらのインフラストラクチャレイヤーの変更とこの実験フレームワークの両方があったことです。そこで、この特定の問題に適したLLMを選択できるように、これら両方をどのように活用できるかを確認したかったのです。同時に、これら3つの目標すべてを満たしているという確信を持ちながらです。
それでは、これが実際に私たちの社内実験フレームワークでどのように見えるかをご説明します。これはオフライン実験を実行する際の様子を示した簡単なサマリーです。このケースではNova Liteと、私たちが使用していた元のLLMを比較して、これが実際に私たちが望む改善につながっているかどうかを判断します。特に重要なのは、レイテンシーと主要な品質メトリクスです。これはロールアップされたサマリーです。実際には数十種類の異なる評価指標があり、それらがこれらのサマリーに集約されています。これは非常に小さなサンプルセットで実行されていますが、ご覧のように、この小さなサンプルでレイテンシーの大幅な削減と品質の改善が見られました。このオフラインテストにより、私たちは実際に望んでいた改善を達成しているという確信を持つことができました。
そこで、オンライン評価に移行しました。ABテストの実行を開始し、これは私たちが懸念していた主要メトリクスに取り組んだ際の写真の一部です。具体的には、レイテンシーと、自動品質メトリクスおよびユーザー満足度の観点からの品質メトリクスを確認したいと考えていました。その結果、レイテンシーが大幅に改善され、ユーザー満足度と自動品質メトリクスの両方において有意な変化はありませんでした。
では、これは何を意味するのでしょうか。クエリ理解に関しては、最終的にNova Liteに切り替えました。その結果、一連のプロンプト変更の後、ユーザーに見える品質の低下なしに切り替えることができ、同時にP50レイテンシーを46%削減し、この特定の機能のサービス提供コストを70%削減することができました。
統合的アプローチの成果：月間アクティブユーザーあたりのコスト90%削減と品質向上の両立
では、ここで何を実現できたのでしょうか。私たちにはこれら2つの独立したセクションがあります。
これらのインフラストラクチャの改善により、将来に向けて適切なLLMを選択し、インフラストラクチャをはるかに効率的な利用率で運用できる能力が得られました。また、品質と評価システムもあり、これにより生成AIアウトプットの品質をより客観的にベンチマークし評価する能力が得られました。そしてこれにより、私たちはジョブに適したLLMを選択し、プロンプトエンジニアリングに実際に費やす時間を最大化しながら、これに費やすエンジニアリング時間を最小化し、インフラストラクチャをはるかに効率的に運用し、そして他のチームやリーダーシップに対して私たちが行っている改善を伝える際に、それらの改善が実際のものであるという確信を持つことができるのです。
これを数十もの異なる機能にわたって実施しています。この1年間におけるこれらすべての変更の結果はどうだったでしょうか？月間アクティブユーザーあたりのSlack AIの提供コストを90%削減することができました。同時に、運用規模を約5倍に拡大しました。これらすべてを実現しながら、Slack AIの主要機能全体でユーザー満足度とユーザーフィードバックを15%から30%向上させることができました。
素晴らしい。本日はご視聴いただきありがとうございました。ご質問があれば喜んでお答えします。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion