4 ポイント 投稿者 GN⁺ 2024-10-25 | まだコメントはありません。 | WhatsAppで共有
  • 急速に変化する技術環境において、強力なオンコール運用を維持することは、サービスを円滑に機能させるうえで重要である
  • プラットフォームエンジニアリングチームは、オンコールのスケジュール、インシデント対応、重要な場面でのコミュニケーション、Slack® チャンネルでの強力なカスタマーサポートを効率的に管理することに苦労している
  • オンコールエンジニアとのコミュニケーションと質疑応答を最適化するために、生成AIを活用するオンコール Copilot「Genie」について説明する

さらに詳しく見る: 問題と動機

  • Uber では Michelangelo チームのようなさまざまなチームが、社内ユーザーが支援を依頼できる Slack サポートチャンネルを持っている
  • こうしたチャンネルでは、月平均 45,000 件の質問が投稿される
  • 質問数の多さと長い応答待ち時間は、ユーザーとオンコールエンジニアの生産性を低下させる

煩雑なプロセス

  • 通常、ユーザーが Slack チャンネルに質問を投稿すると、オンコールエンジニアの応答を待たなければならない
  • オンコールエンジニアは、ユーザーの最初の質問に答えるか、追加の詳細を求める
  • ユーザーはさらに質問したり、より明確な説明を求めたり、追加情報を提供したりする場合がある
  • その後、再びオンコールエンジニアの応答を待つ状況が発生する
  • 何度ものやり取りを経て、ようやくユーザーの質問が解決される

情報を見つけにくい

  • 多くの質問は既存の文書を参照することで回答できるが、情報が Engwiki と呼ばれる Uber の社内 wiki、社内 Stack Overflow、そのほかの場所に分散しているため、特定の答えを見つけるのが難しい
  • その結果、ユーザーは同じ質問を繰り返しがちになり、数百の Slack チャンネルでオンコールサポートへの高い需要が発生している

アーキテクチャ上の課題

  • オンコール Copilot を構築するにあたり、LLM モデルをファインチューニングするか、それとも Retrieval-Augmented Generation (RAG) を活用するかを選択した
  • ファインチューニングには、LLM が学習できる高品質で多様な例を含むキュレーション済みデータが必要である
  • さらに、新しい例でモデルを最新の状態に保つための計算リソースも必要となる
  • 一方で RAG は、最初から多様な例を必要としない
  • これにより Copilot のリリース時間を短縮できたため、このアプローチを採用した

オンコール Copilot の構築では、ハルシネーションの問題への対処、データソースの保護、ユーザー体験の改善など、いくつかの課題があった。ここでは、それぞれの課題をどのように解決したかを概観する。

ハルシネーションについては、次の点に重点を置いた。

  • 応答の正確性: 質問に関連する知識を検索し、LLM エンジンが誤った情報や誤解を招く情報を生成しないようにする
  • 検証メカニズム: ハルシネーションの可能性を減らすため、権威ある情報源に対して Copilot の応答を検証する方法を実装する
  • 継続的学習: Copilot が常に最新データにアクセスできるようにし、精度を高める

データセキュリティのため、Slack チャンネルに公開できないデータソースが多数あることから、取り込むデータソースを慎重に選定した。

ユーザー体験を改善するため、次のように設計した。

  • 直感的なインターフェース: ユーザーが Copilot と効率よくやり取りできる、使いやすいインターフェースを設計する
  • フィードバックループ: Copilot の性能を継続的に改善するため、ユーザーが応答に対してフィードバックを提供できる仕組みを構築する

このような課題を解決することで、信頼でき、使いやすく、安全なオンコール Copilot を開発した。

構造の詳細分析

  • オンコール Copilot「Genie」のアーキテクチャを見ていく
  • 要約すると、Uber の社内 wiki、社内 Stack Overflow、エンジニアリング要件文書のような社内データソースをスクレイピングし、OpenAI の埋め込みモデルを使ってそれらのデータソースからベクトルを生成する
  • これらの埋め込みはベクターデータベースに保存される
  • その後、ユーザーが Slack チャンネルに質問を投稿すると、その質問は埋め込みに変換される
  • サービスはベクターデータベースから、その質問に関連する埋め込みを検索する
  • 埋め込みでインデックス化された結果は、応答を得るための LLM へのプロンプトとして利用される

データ準備、埋め込み、サービングのためのアーティファクト push 段階は、Apache Spark™ を使う RAG アプリケーションとして一般化できる。これらの一般的な段階が、RAG アプリケーションの基盤を形作る。

ETL

データ準備

  • Spark アプリは、Uber の Engwiki または Uber Stack Overflow API を使用して、各データソースからコンテンツを取得する
  • このデータ準備段階では Spark データフレームが出力される
  • スキーマには、ある列に Engwiki のリンク、別の列に Engwiki の内容が入り、どちらも文字列形式である

埋め込み生成

  • データのスクレイピング後、OpenAI の埋め込みモデルを使って埋め込みを生成し、Uber の Blob ストレージである Terrablob に push する
  • 生成された埋め込みには、Engwiki スペースに関連する特定の Slack チャンネルを通じてのみアクセスできる
  • 出力形式は、チャンク内容を対応するベクトルにマッピングしたスキーマを持つデータフレームである
  • Uber の社内 wiki の内容は langchain を使ってチャンク化され、埋め込みは PySpark UDF を通じて OpenAI で生成される

Pusher

  • Terrablob にベクトルを push する方法を示す
  • ベクトルがどのように push されるかを示す
  • データソースから Sia にデータを取り込むため、bootstrap ジョブがトリガーされる
  • Sia は Uber の社内ベクターデータベースソリューションである
  • その後、インデックスの構築とマージのために 2 つの Spark ジョブがトリガーされ、Terrablob にデータを取り込む
  • すべての leaf が、Terrablob に保存されたベースインデックスとスナップショットを同期・ダウンロードする
  • 検索時には、クエリが各 leaf に直接送信される

Knowledge Service

  • Genie には Knowledge Service というバックエンドサービスがある
  • 受信クエリをまず埋め込みに変換し、その後ベクターデータベースから最も関連性の高いチャンクを取得して、すべての受信クエリへのリクエストに応答する

コスト追跡

  • コスト追跡のため、Slack クライアントまたはその他のプラットフォームが Knowledge Service を呼び出す際、UUID が Knowledge Service に渡される
  • その後 Knowledge Service は、コンテキストヘッダーを通じて UUID を Michelangelo Gateway に渡す
  • Michelangelo Gateway は LLM へのパススルーサービスであるため、その UUID を使ってコストを追跡する監査ログに追加できる

Genie の性能評価

測定方法

  • ユーザーは Slack 上で、Genie の回答にある該当ボタンをクリックすることで即座にフィードバックを提供できる

  • ユーザーには次の選択肢が提供される:

    • 解決済み: 回答が問題を完全に解決した
    • 役に立った: 回答は部分的に役立ったが、ユーザーにはさらに支援が必要である
    • 役に立たなかった: 応答が誤っている、または関連性がない
    • 関連なし: ユーザーにはオンコールサポートが必要であり、Genie では支援できない(コードレビューのようなケース)
  • ユーザーがフィードバックを残すと、Slack プラグインがそれを取得し、特定の Kafka トピックを使ってフィードバックと関連メタデータを Hive テーブルにストリーミングする

  • 後でダッシュボードでこれらのメトリクスを可視化する

性能評価

  • Genie ユーザーには、カスタム評価を実行できるオプションが提供される
  • ユーザーは、ハルシネーション、回答の関連性、またはユースケースで重要だと考えるその他の指標を評価できる
  • この評価は、検索や生成のような関連するすべての RAG コンポーネントをより良く調整するために利用できる

評価プロセスは、すでに構築されている Michelangelo コンポーネントを利用する別個の ETL パイプラインである。Genie のコンテキストと応答は Hive から取得され、Slack メタデータやユーザーフィードバックなど、そのほかの関連データと結合される。処理された後 Evaluator に渡される。Evaluator は指定されたプロンプトを取得し、Judge として LLM を実行する。指定された指標が抽出されて評価レポートに含まれ、ユーザーは UI でこのレポートを利用できる。

文書評価

  • 正確な情報検索は、ソース文書の明確さと正確さに依存する
  • 文書自体の品質が低ければ、LLM がどれほど優れていても良い性能を出すことはできない
  • そのため、文書を評価し、文書品質を改善するための実行可能な提案を行える能力は、効率的で効果的な RAG システムに不可欠である

文書評価アプリのワークフローを示す。データがスクレイピングされた後、ナレッジベースの文書は Spark データフレームに変換される。データフレームの各行は、ナレッジベース内の 1 つの文書を表す。その後、Judge として LLM を呼び出して評価を処理する。ここではカスタム評価プロンプトを使って LLM に入力を与える。LLM は評価スコアに加え、そのスコアの説明と、各文書の品質を改善するための実行可能な提案を返す。これらすべてのメトリクスは、ユーザーが Michelangelo UI からアクセスできる評価レポートとして公開される。

課題へのソリューション

  • ハルシネーションを減らすため、ベクターデータベースから得たプロンプトを LLM に送る方法を変更した
    • ベクターデータベースから得たすべての結果について、部分的なコンテキストとともに対応するソース URL を明示的に追加する
    • LLM に対し、提供された複数のサブコンテキストだけに基づいて回答し、回答を引用するソース URL を返すよう求める
    • すべての回答に対してソース URL を提供するようにしている
  • OpenAI で埋め込みを生成する際や、重要なデータソースにアクセスできない人へ Slack 経由でデータソースを漏えいしないようにするため、Uber の大半のエンジニアが広く利用できるデータソースを事前にキュレーションし、埋め込み生成にはそれらのデータソースのみを使えるようにした
  • Genie が質問に答える可能性を最大化するため、新しいインタラクションモードを開発した
    • このモードでは、ユーザーがより簡単に追加質問をでき、Genie の回答をより注意深く読むよう促される
    • Genie が質問に答えられない場合、ユーザーは問題をオンコールサポートへ簡単にエスカレーションできる

新しいインタラクションモードでは、ユーザーが質問すると、Genie は次のステップのアクションボタンとともに回答する。これらのボタンを使って、ユーザーは簡単に追加質問をしたり、質問を解決済みとしてマークしたり、人的サポートに問い合わせたりできる。

成果

  • 2023 年 9 月のリリース以降、Genie は 154 の Slack チャンネルに展開を拡大し、70,000 件以上の質問に回答した
  • Genie は、効果の向上を示す 48.9% の有用率を誇る
  • リリース以降これまでに、13,000 時間のエンジニアリング時間を節約したと推定されている

今後

  • Genie は、オンコール管理を簡素化し、インシデント対応を最適化し、チームコラボレーションを改善するために設計された最先端の Slack ボットである
  • シンプルさと有効性を重視して開発された Genie は、包括的なアシスタントとして機能し、エンジニアリングチームがオンコール責任を円滑に処理できるよう支援する
  • このオンコールアシスタント Copilot は、ユーザーとオンコールエンジニアが各プラットフォームの Slack チャンネル内で相互作用し、関与する全体の体験を変える可能性がある
  • また、Michelangelo や IDE のような各製品の中で、ユーザーがオンコールサポートを待たずに、製品専用の Slack チャンネルや製品内で製品固有のヘルプを見つけられる体験へと変えていく可能性もある

結論

  • オンコールアシスタント Copilot「Genie」は、エンジニアリングチームのオンコール業務管理の方法を革新する
  • 自動解決を促進し、洞察に富んだ分析を提供することで、Genie はチームがオンコール責任を効率的かつ効果的に処理できるよう支援する

GN⁺の見解

  • Genie は、Uber の数多くの Slack チャンネルでユーザーの質問に回答し、エンジニアの時間を節約しながらユーザー体験を向上させる革新的なオンコール Copilot である
  • Genie の成功は、機械学習技術と人間の専門知識の強力な組み合わせを示している。大規模データと LLM を活用して、質問に対して正確で有用な回答を提供する
  • しかし、Genie には依然として制約と改善の余地がある。ハルシネーション問題を完全には解決しておらず、ときには不正確または誤解を招く情報を提供する可能性がある。継続的なモニタリングとユーザーフィードバックを通じてシステムを改善していく必要がある
  • もう 1 つの考慮事項は、データセキュリティとプライバシーである。Genie が扱うデータは機微かつ機密である可能性があるため、安全な処理とアクセス制御が不可欠である
  • 今後 Genie は、回答品質の向上、より多くのデータソースの統合、セキュリティ強化の方向に進化できる。また、Genie のような Copilot を他のビジネス領域へ拡張することも可能である
  • 自動化されたカスタマーサポート、営業支援、さらにはコーディング支援に至るまで、AI ベースのアシスタントはさまざまな作業に適用できる。こうしたツールは従業員の生産性を高め、ユーザー体験を改善できる
  • 全体として、Genie は AI と人間の専門知識がどのようにより良い働き方と顧客サービスにつながるかを示す興味深い事例である。こうした技術は今後も進化し続け、私たちの働き方や相互作用の仕方に大きな影響を与えると予想される

まだコメントはありません。

まだコメントはありません。