True ML Talks #17 - SlackにおけるMLプラットフォーム、LLMとSlackGPT

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
True ML Talksの新しいエピソードをお届けします。今回は、SlackのRecommend API、SlackGPT、LLMについて深く掘り下げ、お話しいただくのは カトリーナ・ニー氏。
カトリーナ・ニー氏は、SlackのシニアMLエンジニアであり、技術スタッフのリードメンバーでもあります。彼女はそこでMLチームを率い、Recommend API、スパム検出など、様々な製品機能に携わってきました。
📌
カトリーナ氏との対談では、以下の点について取り上げます。
- SlackにおけるMLと生成AIのユースケース
- MLに焦点を当てたSlackのインフラストラクチャ
- SlackのRecommend APIにおけるトレーニング、検証、デプロイ、モニタリング
- Recommend APIのビジネスインパクトの測定
- 顧客プライバシーがトレーニングインフラストラクチャに与える影響
- Slack GPTの構築とLLMトレーニングにおける課題
- 言語モデルにおけるプロンプトエンジニアリングの未来
- LLMの進歩に関する最新情報の把握
全エピソードはこちらからご覧ください:
SlackにおけるMLと生成AIのユースケース
- パーソナライズされたチャンネルレコメンデーション: Slackでは、MLと生成AIがパーソナライズされたチャンネルレコメンデーションを可能にします。チームに参加する新規ユーザーは、関係性やデータに基づいた洞察に基づいて関連性の高いチャンネルの提案を受け取り、ユーザーエクスペリエンスが向上します。
- レコメンダーAPIの統合: Slackの統合型レコメンダーAPIは、製品機能チーム全体にわたってサービスレコメンデーションを提供します。レコメンデーションが主要なビジネスモデルではないにもかかわらず、その高度なレコメンダーエンジンはあらゆる規模のユーザーにシームレスに対応します。
- マルウェアの検出とスキャン: MLと生成AIは、マルウェアリンクを検出・スキャンすることでSlackのセキュリティ改善にも貢献し、より安全なコミュニケーション環境を構築しています。
MLに焦点を当てたSlackのインフラストラクチャ
Slackは、熟練したデータエンジニアリングチームと堅牢なデータウェアハウスソリューションを活用しています。ジョブスケジューリングとビッグデータ処理にはAirflowを使用し、MLタスクに不可欠なサポートを提供しています。
SlackのインフラストラクチャはKubernetesを基盤とし、マイクロサービスアーキテクチャをサポートしています。クラウドチームは、マイクロサービスのデプロイを容易にするKubernetesベースのフレームワークを開発し、柔軟性とスケーラビリティを提供しています。
特定のニーズに対応するため、Slackは既存のソリューションを使用する代わりにカスタムのフィーチャーストアを開発しました。このカスタムストアは、MLアプリケーション向けの機能を効率的に管理・活用しています。
Slackの専任チームは、Kubernetes上にオーケストレーションレイヤーを構築し、マイクロサービスのデプロイを効率化し、コンソールなどの内部サービスと統合しました。これによりKubernetesの利用は強化されますが、データベースに大きく依存するアプリケーションには課題が残っています。
SlackにおけるレコメンドAPI
Slackの初期には、効果的な埋め込みとグループ分けの仕組みを開発する努力がなされました。これには、ユーザーのインタラクションを理解し、ユーザーとチャンネルの数値埋め込みを生成するために膨大な量のデータを処理することが含まれていました。その成果の一つはユーザーアクティビティに基づいた埋め込みサービスであり、もう一つはメッセージに基づいたものでしたが、当時は広く採用されませんでした。
その後、これらの埋め込みを活用して、よりユーザーフレンドリーな製品を構築することに焦点が移りました。チャンネルやユーザーの推薦など、提案がユーザーに役立つ領域を特定することで、レコメンデーションの概念が生まれました。これにより、Slackプラットフォームの様々な部分と統合され、既存の埋め込みを活用してユーザーアクティビティに基づいた関連データを取得するレコメンドAPIの開発につながりました。このAPIはフィーチャーストアも組み込み、追加の機能でデータを充実させ、フィルタリングとスコアリングのメカニズムを適用しました。
開発が進むにつれて、レコメンドAPIはSlack内の様々な機能に統合され、プラットフォームがユーザーに関連するチャンネルやユーザーを推薦できるようになりました。これにより、ユーザーエクスペリエンスが合理化され、エンゲージメントが高まりました。
SlackGPTの詳細については、以下のブログでご覧いただけます。
同じブログからの画像で、SlackのレコメンドAPIインフラストラクチャの非常に良い概要を示しています。

レコメンドAPIのモデルトレーニングパイプラインと検証ワークフロー
Kubernetes、Airflow、およびトレーニングと検証への階層的アプローチを活用することで、SlackはレコメンドAPIのモデルが効果的で信頼できるものであることを保証し、ユーザーにパーソナライズされたレコメンデーションを提供しています。ABテストにより、デプロイ前にオンライン環境でのモデルパフォーマンスの厳格な評価が保証され、Slackにおける堅牢でデータ駆動型のML運用フレームワークに貢献しています。
1. 階層型コーパスとユースケース: Slackのモデル学習パイプラインは階層的なアプローチを採用しています。これは、チャンネルやユーザーで構成される階層型コーパスから始まり、日次ダイジェスト、コンポーザー、チャンネルブラウザなど、Slack内の特定の機能に対応する複数のユースケースがあります。
2. モデル選定と実験: 各ユースケースに対して、大規模な回帰モデルから始まり、XGBoostやLightGBMのような他のアルゴリズムも検討しながら、さまざまなモデルが学習され、実験が行われます。モデルのパラメータは微調整され、最適なモデルを特定するためにさまざまなデータバリエーションが試されます。
3. KubernetesとAirflowによる学習パイプライン: 学習パイプラインはKubernetesとAirflowを使用してオーケストレーションされます。Kubernetesクラスターはモデル学習タスクを効率的に処理し、Airflowがデータ収集から、さまざまなユースケースに対応する多様なモデルの学習まで、ワークフローを管理します。
4. ロギングとオフラインメトリクス: 学習中、チームは将来の監視と分析のためにオフラインメトリクスとモデルパラメータを記録します。
5. モデルのシームレスな追加と管理: このアーキテクチャにより、最小限のコード変更で新しいソースや学習用モデルをシームレスに追加できます。
6. 検証とABテスト: モデルを本番環境にデプロイする前に厳格な検証が行われ、分類モデルやランキングモデルのAUCなどのオフラインメトリクスを比較します。ABテストは広範囲に利用され、より優れたオンラインメトリクスを持つモデルがデプロイのために選択されます。
7. 社内ABテストフレームワーク: Slackには独自の社内ABテストフレームワークがあり、新機能のローンチ時にMLチームとプロダクトチームによって使用されます。このフレームワークは、さまざまなビジネスメトリクスでモデルのパフォーマンスを比較することで、データに基づいた意思決定を可能にします。
Recommend APIのモデルデプロイとスケール
SlackのMLモデルは、リクエスト処理のインターフェースとしてGRPCを使用し、Kubernetesクラスターにデプロイされます。GRPCは、FastAPIのようなJSONベースのAPIと比較して、安全性、効率性、高速な処理を提供します。その制約にもかかわらず、GRPCはAPIとモデル間の堅牢で効率的な通信を保証し、スムーズなデプロイプロセスに貢献しています。
デプロイ戦略には、Kubernetesのオートスケーリング機能を活用することが含まれており、これによりモデルは需要に基づいてリソース使用量を調整できます。膨大なユーザーベースを持つSlackは、平均して毎秒約100リクエストに達する多数のリクエストを処理しています。
GRPCの実装とサービングクラスターマイクロサービスのセットアップには集中的な努力が必要でしたが、スケールへの対応とモデルパフォーマンスの最適化において効果的であることが証明されました。
Recommend APIのモデル監視と自動再学習
1. オフラインおよびオンラインメトリクスの追跡: Slackのモデル監視パイプラインは、オフラインおよびオンラインのメトリクスを効率的に追跡します。精度、F1、ROCなどのオフラインメトリクスはログに記録され、専用のダッシュボードで可視化されます。承認率を含むオンラインメトリクスも、別のダッシュボードを通じて監視されます。
2. 異常検知と特徴量ドリフト: Slackは独自の異常検知フレームワークを活用し、特徴量ドリフトを監視しています。定期的なモデルの再学習(日次学習と週次デプロイ)により、特徴量ドリフトの影響が軽減され、懸念が少なくなっています。
3. 自動再学習パイプライン: 再学習パイプラインはAirflowを使用して自動化されており、モデルが最新のデータで常に最新の状態に保たれるようにしています。
4. 可視化のための自動ダッシュボード: データエンジニアは、モデルのパフォーマンスとメトリクスを可視化するユーザーフレンドリーなダッシュボードを開発しました。ダッシュボードは新しいデータで自動的に更新され、新しいユースケースの追跡を容易にしています。
5. 新しいユースケースの容易な統合: データエンジニアによって構築された自動統合フレームワークのおかげで、監視および再学習パイプラインに新しいユースケースを追加することは容易です。
自動化と定期的な再学習を活用することで、SlackのMLモデルは本番環境で継続的に監視、最適化され、信頼性を保っています。堅牢なMLOpsフレームワークは、Slackの多数のユーザーベースに対するシームレスで効率的なモデルデプロイメントに貢献しています。
Recommend APIのビジネスへの影響を測定する
Slackは、Recommend APIのビジネスへの影響を評価するために様々なメトリクスを採用し、そのパフォーマンスと有効性に関する貴重な洞察を得ています。使用される主要なメトリクスは次のとおりです。
- 承認率: ユーザーが推奨されたチャンネルやユーザーを受け入れたり、操作したりする割合を測定することで、APIのオンラインパフォーマンスを監視します。承認率が高いほど、ユーザーエクスペリエンスとエンゲージメントが向上していることを示します。
- ユーザーのクリックと承認: 推奨されたチャンネルやユーザーに対するユーザーのクリックと、提案された接続の承認を追跡します。これらのメトリクスは、推奨に対するユーザーエンゲージメントと、プラットフォーム内での有意義なインタラクションを明らかにします。
- プロダクトチーム向けのカスタムメトリクス: さまざまなプロダクトチームが、それぞれの特定の目標と目的に合わせて調整されたカスタムメトリクスを使用しています。これらのメトリクスには、ユーザー参加者数、チームの成功、最優先スタックメトリクスなどが含まれます。
- ABテスト: モデルのパフォーマンスとAPIのバリアントを評価するために不可欠です。これにより、デプロイする最も効果的なモデルを選択するためのデータに基づいた意思決定が可能になります。
- 総合的なビジネスインパクト評価: 複数の指標から得られた知見を組み合わせ、APIが目標達成とユーザーへの価値提供においてどれほど効果的であるかを包括的に理解します。
これらの指標を分析し、ユーザーフィードバックに基づいてRecommend APIを最適化することで、SlackはAPIがユーザーエクスペリエンスを大幅に向上させ、つながりを育み、プラットフォーム内でポジティブなビジネス成果をもたらすことを確実にしています。
顧客プライバシーがトレーニングインフラストラクチャに与える影響
Slackの顧客プライバシーへのコミットメントは、トレーニングインフラストラクチャのアーキテクチャとデータ処理方法に大きく影響を与えています。データプライバシーへの厳格な焦点はMLOpsスタックの様々な側面に反映されており、機密情報の安全かつコンプライアンスに準拠した取り扱いを保証しています。顧客プライバシーがSlackのトレーニングインフラストラクチャにどのように影響するかを以下に示します。
- 機密データの慎重な取り扱い: Slackは、個人識別情報(PII)などの機密情報を処理するために堅牢なデータプライバシー対策を採用しています。データエンジニアリングチームは、PIIを削除し、プライバシー規制に準拠するための保持ポリシーを実装しています。
- 機密データへのアクセス制限: 機密情報を含むデータセットへのアクセスは制限されており、Manitobaという名前の分離されたデータウェアハウスに格納されています。このアクセス制限はデータセキュリティを強化しますが、モデルのデバッグや分析中に課題となる場合があります。
- デバッグの課題とモデルの相互作用: 機密データへのアクセスが制限されているため、モデルのデバッグが複雑になる可能性があり、モデルの動作の正確性を確保するために代替のアプローチや監視ツールが必要となります。
- モデルトレーニングにおけるデータプライバシー: Slackは、モデルのトレーニング、特に機密情報との相互作用を伴う可能性のあるスパム検出のようなタスクにおいて、データプライバシーポリシーへの準拠を保証しています。
- データプライバシーのためのアーキテクチャの適応: データプライバシーを維持するため、Slackは安全なデータストレージ、アクセス制御、データ暗号化の実践を組み込むなど、特定のアーキテクチャ上の選択を行っています。
Slack GPTの構築と大規模言語モデルのトレーニングにおける課題
Slackは、プラットフォーム上の情報過多に対処し、ユーザーの生産性を向上させるため、要約のための強力な言語生成AIであるSlack GPTを導入しました。
Slack GPTの構築は課題を伴い、大規模言語モデルのトレーニングにはインフラストラクチャの革新が必要でした。これには、クラスターのセットアップ、Kubernetesの使用、並列処理技術の探求が含まれます。要約の品質を向上させるため、チームはプロンプトチューニングを実装し、モデルの動作に影響を与え、一貫性のある要約を生成するためにプロンプトを慎重に作成しました。
プロンプトの体系的な評価は極めて重要であり、チームはプロンプトの有効性を評価するためのツールを開発し、異なるプロンプトでの実験を可能にしました。オフライン評価とオンライン評価の間のギャップを埋めることで、オフラインでの探索中に観察された品質がオンラインのユーザーエクスペリエンスにシームレスに移行することを確実にしました。
SlackがAI機能に投資するにつれて、MLエンジニアはSlack GPTのようなAI駆動型機能の探索、評価、体系的な改善を通じて、ユーザーエクスペリエンスを最適化する上で極めて重要な役割を果たしています。
SlackGPTについては、以下のリンクから詳細をご覧いただけます。
言語モデルにおけるプロンプトエンジニアリングの未来
プロンプトエンジニアリングは言語モデルにとって極めて重要であり、応答の品質に影響を与えます。現状では試行錯誤が繰り返されており、標準化されたアプローチが確立されていません。今後の可能性としては、以下が挙げられます。
- 標準化とベストプラクティス: 特定のユースケースに合わせてプロンプトを最適化するための、標準化されたプラクティスとガイドラインの登場。
- プロンプトの自動最適化: 分析とユーザーフィードバックに基づいてプロンプトを洗練し、プロセスを効率化するAI駆動システム。
- 実験インターフェースの強化: モデル間でプロンプトを効率的に操作・比較できる、ユーザーフレンドリーなプラットフォーム。
- ユーザーフィードバックの組み込み: 適応的でパーソナライズされた応答のために、プロンプト調整を導くリアルタイムの洞察。
プロンプトエンジニアリングは、手動介入と自動化のバランスを取りながら、AIを活用したコミュニケーションの未来を形作るために積極的に探求されている分野です。
LLMの進歩に常にキャッチアップする
大規模言語モデル(LLM)の継続的な進歩に常にキャッチアップすることは、データサイエンティストやMLエンジニアにとって不可欠です。
AIおよびNLPコミュニティの多くの専門家は、LLM分野における新しい研究、モデルのリリース、ブレークスルーに関するリアルタイム情報にアクセスするための貴重なプラットフォームとしてTwitterを利用しています。Twitterで影響力のある研究者や実務家をフォローすることで、彼らはこの分野の最新トレンドや更新情報を迅速に知ることができます。
さらに、専門家は同僚との交流を通じて情報を得ています。チーム内では、Llama-2のようなLLMのリリースやSageMakerのようなプラットフォームとの統合といった重要なニュースが共有され、共同学習の環境が生まれています。
データサイエンティストやMLエンジニアの中には研究論文を読むことに重点を置く人もいますが、実用的なユースケースを優先する人もいます。彼らは、新しい開発がどのように自分たちの仕事に直接影響を与え、現実世界のシナリオにおけるLLMの応用を改善できるかを探求する傾向が強いです。
TrueMLシリーズの過去のブログを読む
TrueMLの YouTubeシリーズを視聴し、 TrueMLのすべての ブログシリーズを読んでください。
TrueFoundry は、Kubernetes上で動作するMLデプロイメントPaaSであり、開発者のワークフローを高速化し、モデルのテストとデプロイにおいて完全な柔軟性を提供しつつ、インフラチームには完全なセキュリティと制御を保証します。当社のプラットフォームを通じて、機械学習チームは デプロイおよび監視 を15分で、100%の信頼性、スケーラビリティ、そして数秒でのロールバック機能を備えて行えるようになります。これにより、コストを削減し、モデルをより迅速に本番環境にリリースできるようになり、真のビジネス価値の実現を可能にします。
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.















.webp)
.webp)


.png)

.png)














