「ジェイソン・フラックスとともに会話型AI製品を本番環境に展開する」

Deploy conversational AI products in production environments with Jason Flux.

この記事はもともとMLOps Liveのエピソードであり、MLプラクティショナーが他のMLプラクティショナーからの質問に答えるインタラクティブなQ&Aセッションです。

各エピソードは特定のMLトピックに焦点を当てており、このエピソードでは、ジェイソン・フォークスさんとの会話を通じて「会話型AI製品の本番への展開」について話しました。

YouTubeで視聴できます：

または以下のポッドキャストで聴くこともできます：

• 「AIへの恐怖は迷信的なくだらないことだ」
• 「機械学習モデルのログと管理のためのトップツール」
• 鑑識分類器をだます：敵対的な顔生成における生成モデルの力

• Spotify
• Apple Podcasts

ただし、文章版をご希望の場合は、以下に掲載しています。

このエピソードでは、以下のことについて学ぶことができます：

• 1
  会話型AI製品の開発方法
• 2
  会話型AI製品の展開に必要な要件
• 3
  プロプライエタリデータを社内で開発するか、既製品を使用するかの選択肢
• 4
  会話型AIのテスト戦略
• 5
  大規模企業向けの会話型AIソリューションの構築方法

Sabine: 皆さん、こんにちは。またMLOps Liveの新しいエピソードにお帰りいただきありがとうございます。私はSabineです。いつものように、共同ホストのStephenと一緒にいます。

今日は、Jason Flaksさんが一緒にいて、会話型AI製品の本番への展開について話します。こんにちは、Jason、ようこそ。

Jason: こんにちは、Sabine。元気ですか？

Sabine: とても元気です。会話を楽しみにしています。

Jasonさんは、Xemblyの共同創設者兼CTOです。Xemblyは会話型タスクを自動化するチーフ・オブ・スタッフです。つまり、エグゼクティブ・アシスタントのようなボットですね。

Jason: はい、それは素晴らしい表現です。ほとんどの企業のCEOは、エグゼクティブ・アシスタントやチーフ・オブ・スタッフなどの人々に支えられています。これによってCEOは会社を支える非常に重要で意義のある仕事に時間を費やすことができます。アシスタントは、ミーティングのスケジュール調整やメモの取りまとめなど、その他の日常業務を手助けするために存在しています。

私たちはその機能を自動化し、組織内のすべての従業員がCEOや他の社内の人々と同じようにその支援を受けられるようにすることを目指しています。

Sabine: 素晴らしいですね。

ちょっと詳しく掘り下げてみましょう。まず、あなたのバックグラウンドについて少し聞かせてください。非常に興味深い経歴をお持ちですね。

音楽作曲、数学、科学の教育を受けた後、ソフトウェアエンジニアリングの方に進まれたのですよね。ただし、最初はソフトウェアデザインエンジニアリングでスタートされたのですか？

Jason: はい、その通りです。

おっしゃる通り、私は以前、音楽家としての人生をスタートしました。音楽から生まれる電子機器に対する情熱があり、数学も得意でした。

私は大学で音楽作曲専攻と数学専攻を始め、最終的にはそれらを組み合わせる方法を模索していました。その結果、プロのオーディオ機器に特化した電気工学の修士プログラムに入学し、初めてソフトウェア設計を行う職業に就きました。

それが私の最初の仕事でした。

Sabine: 異なる興味深い分野の交差点に自分自身を見つけたということですね。

Jason: そうですね。私は音楽やオーディオ、エンジニアリングに常に少し近くにいるように心掛けてきました。今でもそれは変わりません。

プロのオーディオ、音楽、ライブサウンド、音声、自然言語からは少し遠ざかっていますが、それは依然としてオーディオの領域に密接に結びついているため、私のスキルセットの一部となっています。

Sabine: 確かにそうですね。また、装置の話題ですが、Connectの開発に関わっていたのですよね？（またはXboxのことですか）

それが音声認識、機械学習のアプリケーションとの最初の接触だったのでしょうか？

Jason: それはいい質問ですね。音声認識の面白いところは、実際には2つのステージからなるパイプラインです。

ほとんどの音声認識システムの最初のコンポーネントは、長い歴史を持つもので、特徴の抽出です。これは音声信号処理の領域であり、私は他のキャリアの一部から多くの専門知識を持っていました。

私は音声認識を行っていませんでしたが、高速フーリエ変換やそれに関連するコンポーネントには精通していました。音声認識スタックの前段階に関連するものです。

しかし、あなたが言う通り、Connect Cameraチームに参加したときには、私の顔から本当に音声認識が初めて導入された時でした。私は自然にそれに引かれました、なぜなら私はスタックの初期の部分を深く理解していたからです。

そして、私はギターの歪み効果を作ろうとしていた音声信号処理の世界から、突然、音声コンポーネントを分析するために解体することが本当に簡単だと気付きました。それは私にとって本当に意味があったし、そこから私のスタートを切った場所でした。

私のスタートには非常に魅力的なプロジェクトでした。Connect Cameraは、ボタンを押さずにデバイスに話しかけることができる、最初の消費者向け商業製品でした。

いつも何かを押してから話さなければならなかったのです。今では皆アレクサやGoogle Homeを持っていますが、それらの製品が存在する前にはXbox Connect Cameraがありました。

特許文献を調べれば、アレクサデバイスがあの元々のConnectの特許に言及していることがわかります。それは本当に革新的な製品でした。

Sabine: そうですね、私はかつて講師の方が人間の話し言葉について、「それは宇宙で最も複雑な信号だ」と言ったことを覚えています。だから、一般的にその分野には課題が不足していないと思います。

Jason: そうですね、本当にその通りです。

会話型AIとは何ですか？

Sabine: そうですね、では、Jason、少しウォーミングアップするために…1分間で会話型AIを説明していただけますか？

Jason: おお、1分間の挑戦ですね。楽しみです…

人間の対話や会話は基本的には無限のドメインです。会話型AIは、この無限の会話ドメイン空間で人間と対話することができる技術や製品を構築することです。

私たちは、あなたと私が話している内容を理解し、会話に参加し、会話が進行するにつれて実際に対話を行うことができるものをどのように構築するのか、という問題に取り組んでいます。

Sabine: すごいですね。とても簡潔にまとめられましたね。まさに1分以内でした。

Jason: 早く進みすぎることを気にして、やりすぎてしまった感じがしました。

Xemblyは現在、会話型AIのどの側面に取り組んでいますか？

Sabine: 現在のチームの取り組みについて少し尋ねたいと思います。会話型AIの特定の側面に取り組んでいますか？

Jason: そうですね、それはとても良い質問です。私たちは会話型AIスタックの2つの側面に取り組んでいます。

チャットボット

これは、会話型音声を介して製品と対話することを可能にするものです。この会話の冒頭で言及したように、私たちは自動化されたスタッフ長やエグゼクティブアシスタントを目指しています。

その役割で誰かと対話する方法は、一般的には会話形式です。従業員への会話形式での応答能力は非常に役立ちます。

自動メモ作成

問題は、ZoomやGoogle Meetなどのビデオ会議プロバイダーを介してこのような会話に参加し、会議の内容を即座に送信できるような、わかりやすいまとめのアクションアイテムや決定事項を抽出する方法です。

これは単なる転写ではありません。会議を読みやすい要約にまとめ、会議に出席していない場合でも何が起こったのかがわかるようにします。

これらは、私たちが会話型AIの領域で取り組んでいる主な部分ですが、それを実現するためにはさらに多くの要素があります。しかし、今日はこれらの2つの大きな製品カテゴリに取り組んでいます。

サビン: では、高いレベルでまとめると、製品の開発にはどのように取り組んでいますか？

ジェイソン: そうですね、ノートテイキングについて話しましょう。これは興味深い話ですから、具体例を挙げて説明しましょう…

まず最初に、問題を分解する必要があります。

実際には、会議のメモはある意味で非常に複雑なものです。人々が異なるメモを取る方法に微妙な違いがあるため、私たちは一歩引いて考える必要がありました。

会議のメモを人々にとって価値あるものにする要点は何であり、それを定型化して繰り返し生成できるものにすることができるのか、定量化できるのか？

機械は曖昧さをうまく扱えません。やりたいことを構造化して定義する必要があるため、データ注釈者が情報をラベル付けできるようにするための明確な指示が必要です。

ラベル付けするための非常に良い指示を与えることができない場合、あいまいな結果が得られるでしょう。

また、一般的には、繰り返し可能な結果を生成する明確で具体的なシステムを構築したい場合、システムを定義する必要があります。そのため、適切な会議のメモの構造を把握するために、最初に多くの時間を費やしています。

初期の段階では、会議のメモには2つの重要な要素があることに着地しました。

• 1
  会議の中で行動が起こり、人々がフォローアップする必要があること。
• 2
  会議で起こったことを要約する線形のまとめ – できればトピックごとに区切られ、会議のセクションをカバーしています。

このようなフレームワークを持っている場合、次に個々の要素がどのように見えるかを定義する必要があります。これにより、実際にそれを達成するために構築する必要があるパイプライン内の異なるモデルが理解できるようになります。

対話型AIの問題の範囲

サビン: それに追加することはありますか？

ジェイソン: そうですね、行動項目のようなものの定義について考えてみましょう。機械が見つけるのに適した範囲にするために、どのようにそれを定義するのでしょう？

ほとんどの会議で、人々は「犬の散歩に行くつもり」といったことを言います。それは単に会議で他の人と話しているだけで、仕事とは関係のないことです。

会議では、仕事とは関係のないこと、その場で実際に進行中のこと、そして会議後に開始されなければならない実際の仕事である真の頭字語があります。

それをどのように範囲を限定し、機械が見つけることができる特定の領域に洗練させるのでしょうか？

実際には、これは非常に困難な問題です。私たちはそれに多くの努力を費やし、データ収集プロセスを開始できるようにしています。

さらに、対話型AIシステムを構築するためのパイプラインを理解する必要があります。実際には、2つの側面があります。

• 1
  対話自体を理解すること – スピーチを理解するだけではなく、そのデータでトランザクションを行うためには、多くの場合、データを機械が理解できる形式に正規化する必要があります。例えば、日付や時間などが該当します。
• 2
  システムの第1部分は、誰かが「来週それをやります」と言ったことを理解することですが、それだけではトランザクションには不十分です。来週にトランザクションを行いたい場合、実際にはコンピュータ言語で「来週」という言葉がどういう意味なのかを理解する必要があります。

つまり、現在の日付に対する参照が必要です。次の週というのは、現在の週から次の週までの期間ということを理解する必要があります。

これには多くの複雑さがあり、すべてを実行し成功するためには、異なるモデルを実行する必要があります。

会話型AI製品の準備

スティーブン: 素晴らしい…私はノートテイキングについてもっと深く掘り下げてみようと考えています。あなたが話した製品についてです。

もちろん、私は製品をユーザーに提供する側面からアプローチしていますが、その曖昧さはそこから生じます。

ですので、その複雑さに入る前に、このような製品をどのように展開するのかを理解したいです。特定のニュアンスや要件があるか、それともこれは単なる典型的なパイプラインの展開で、ワークフローを組み合わせるだけなのか知りたいのです。

ジェイソン: そうですね、それはいい質問です。

私はまず第一に、会話型AIの展開において、世界中に存在する大規模な伝統的な機械学習の空間と比較して、おそらく最も大きな違いの一つは、境界のないドメインであることに関連していると言えます。

迅速かつ反復的なデータラベリングは、私たちのスタックにおいて非常に重要です。そして、会話や対話、言語全般がどのように機能するかを考えると、私たちは今この瞬間に新しい単語を作ることができます。世界で最も大きな言語モデルであるGPT-3を例にとっても、それは彼らにとって未定義のトークンです。

私たちはこの瞬間に単語を作り出しましたが、それは語彙外のものであり、彼らはそれが何であるかを知らず、その単語をサポートするベクトルもありません。言語は生きているものです。絶えず変化しています。ですので、会話型AIをサポートしたいのであれば、言語のダイナミックな性質に常に対応できるように準備する必要があります。

それは現実の問題ではないと思われるかもしれません（人々がいつも即興で単語を作っているということ）、しかし実際には非常に大きな問題です。それはただの友達同士が部屋でおしゃべりをする場合だけでなく、ビジネスの観点からもさらに大きな問題です。

毎日、誰かが目を覚まして新しいブランド製品を作り、自分のものの上にXemblyのような新しい単語を作り出す可能性があります。それについて理解する必要があります。

私たちのスタックの多くは、まず第一に、データラベリングのための良いツールを持つことを確認することです。私たちは半教師あり型の学習を多く行っているため、データを迅速に収集できる必要があります。

迅速にラベルを付けることができる必要があります。私たちはライブデータフィードから得られるデータについてメトリクスを生成できる必要がありますので、ラベル付けされていないデータとラベル付けされたデータを組み合わせて使用できます。

私が以前にも言及したように、もう1つの非常に重要な要素は、会話型AIには通常、大規模な機械学習のパイプラインが必要です。今日読んでいるものに関わらず、「ここにモデルがあるから、すべてを処理します」という一発勝負は通常できません。

大規模な言語モデルの世界では、エンドツーエンドのスタックを動作させるためには一般的に多くの要素が必要です。したがって、私たちは実際にフルパイプラインのモデルを持つ必要があります。必要に応じてそのスタックにパイプラインを迅速に追加できるようにする必要があります。

異なる会話型AIの課題の解決

スティーブン: 有名な製品のエンドツーエンドのスタックを教えていただけますか。

実際にどれほどの課題があるのか、そしてチームがそれらをどのように解決しているのか、少し見てみましょう。

ジェイソン: はい、スタックは複数のモデルで構成されています。

音声認識

まずはじめに、基本的なコンポーネントである音声をテキストに変換することから始まります。従来の音声認識です。

ここでの質問は、「ここで持っているオーディオ録音をテキストドキュメントにどのように変換するのか？」です。

話者のセグメンテーション

対話や会話を扱っているため、多くの場合、すべての話者に対して独立したオーディオチャンネルがない場合があります。そのため、スピーカーのセグメンテーションというもう1つの重要なコンポーネントがあります。

例えば、Zoomの録音で、3人の独立した人物がチャンネルごとに話している場合、1つのオーディオチャンネルで6人が1つの会議室で話している場合などになります。

スピーチ認識システムからのトランスクリプトが対話フローに正しくマッピングされるようにするためには、実際に誰が話しているのかを理解する必要があります。

「会議室Bで、6人いましたが、私は会議室Bだけを理解している」と言っても十分ではありません。私たちは実際に対話-行き来するやり取りを理解する必要があるので、それぞれの話者を理解する必要があります。

盲目的な話者分割

この人がここにいる別の人の要求に対して「いいえ」と言ったことを知る必要があります。テキストを並列に使用することで、話者の割り当てを行います。まず、「盲目的な話者分割」と呼んでいるものから始めます。

つまり、誰が誰であるかは必ずしもわからないが、異なる人々が存在することはわかっているという意味です。その後、過去に彼らを見たことがある場合、オーディオフィンガープリント型のアルゴリズムを実行して、具体的に誰がその人々なのかを特定できるようにします。その後も、パイプラインの最後のステージがあります。これを「フォーマットステージ」と呼んでいます。

フォーマットステージ

句読点アルゴリズムや他のいくつかの小さなソフトウェアを実行して、ウェルストラクチャ化されたトランスクリプトのようなものを作成します。ここでは、SabineがStephenに話しかけ、StephenがJasonに話しかけていることを知っています。それに対応するテキストがあり、適切に句読点がついています。そして、読みやすいトランスクリプトができました。

MLパイプラインの分岐

そこから、パイプラインを分岐させます。2つの並行したパスで実行します：

• 1
  アクションアイテムの生成
• 2
  要約の生成

アクションアイテムでは、トランスクリプト内の発話されたアクションアイテムを見つけようとするため、独自のモデルを使用しています。しかし、これだけでは不十分です。会議では、人々が「それをやってもいい」と言うことがよくあります。もし会議の終わりに会議のメモを渡されたとして、「Stephenが言った、それをやれる」というものはあまり役に立ちませんよね？

そのフレーズを見つけた後、それをよく書かれた文にするためには、いくつかの処理が必要です。前に述べたように、代名詞を参照解除しなければなりません。トランスクリプトを再度確認し、それが何を意味しているのかを理解しなければなりません。それを再フォーマットする必要もあります。

• 代名詞を参照解除する必要があります。
• トランスクリプトを再度確認し、それが何を意味しているのかを理解しなければなりません。
• 再フォーマットする必要があります。

その文をよく書かれたものに再構築しようとします。動詞で始めて、その代名詞をすべて置き換えるので、「私はそれをやれる」という文は、「Stephenは新しいアーキテクチャのスライドを更新できます」となります。

パイプライン内の他の処理としては、所有者の抽出と締切日の抽出があります。所有者の抽出は、文の所有者が誰であるかを理解し、そのトランスクリプト内の対話に戻って所有者を正しく割り当てることです。

締切日の検出は、そのシステム内の日付をどのように見つけるか、それを正規化して会議の参加者に提示するか、ということです。

「火曜日に締切」と言っただけではなく、実際には2023年1月3日を意味します。そのため、カレンダーに予定を入れてもらってそれを完了できるようにすることができます。これが私たちのスタックのアクションアイテムの部分であり、そして私たちのスタックの要約部分があります。

スタックの要約部分では、2つのことを実現しようとしています。

一つは、盲目的なトピック分割です。「対話の中でどのように区切りを引けば、会話のセクションに大まかに対応するか」ということです。

終わった後、誰かがこの会議やポッドキャストを聞いて、いくつかのトピックに関連するセクションにグループ化できるようになるでしょう。私たちはそれを行う必要がありますが、実際にはそれらのトピックが何であるかはわかりません。そのため、いくつかのアルゴリズムを使用します。

これらを「変化点検出アルゴリズム」と呼んでいます。言語の流れの性質において系統的な変化を探しています。それによって、基本的な要約を作成します。したがって、モダンな大規模な言語モデルのいくつかを使用して、会話のセグメントのウェルストラクチャ化された要約を生成します。そのスタックの一部が完了すると、アクションアイテムとウェルストラクチャ化された要約の2つのセクションができます。これらは、会議の直後にすぐに人々に送信できるようになっています。

ビルド vs オープンソース: どちらの対話型AIモデルを選ぶべきですか？

Stephen: たくさんのモデルとシーケンスがあるようですね。少し複雑であり、多くのオーバーヘッドがありますが、それは私たちにとって興奮するものです。

あなたはこれらのモデルのほとんどが社内の独自のものであると言いましたね。

ただ興味がありますが、最新の戦略や市販のモデルをどこで活用しているのか、また、すでに解決されていると感じることと、社内で解決できると思っていることはどのような場合ですか？

Jason:私たちは「ここで開発されていない」という問題を抱えないようにしています。もし公開されているモデルが存在し、私たちの目的に沿っているのであれば、喜んで使用します。

対話型の音声には、一般に、独自のモデルを作成する必要がある場合と、市販のモデルを使用する必要がある場合の2つの主要な問題があります。それは、前述したドメインが非常に広範囲であるためです – 実際には非常に大きなモデルを使用することで逆の問題が生じる可能性があるからです。

そして統計的には、大規模な言語は、あなたのドメインの言語とは一致しないかもしれません。その場合、大きなモデルを使用することで、求めている結果が得られないかもしれません。

私たちは音声認識でこれを非常に頻繁に見ます。たとえば、Googleの独自の音声認識システムがある場合、良い例です。

私たちが見つける問題の一つは、GoogleがYouTubeのすべての動画の転記に対処するために、自分たちのシステムを訓練しなければならなかったということです。YouTubeの言語は実際には企業の会議の言語とは一般的に上手くマッチしないのです。

それは、彼らが一般的な領域で正しいとは限らないということではありません、彼らは一般的な領域の言語をよく表しています。私が言いたいのは、YouTubeはおそらくマクロ領域の言語のより良い表現であるということです。

私たちはビジネス音声のサブドメインで取り組んでいます。これは、確率的に、ほとんどの機械学習モデルが言語の一般的なセットに基づいて単語を予測しようとすることと、私たちの世界で取り扱っている制約のあるドメインとの間で予測が間違ってしまうことが多いということを意味します。

そのような場合、私たちは、市販のシステムを使用する代わりに、何かを構築する方が良いとわかりました。少なくとも、独自のデータでトレーニングされたものを使用することでしょう。

ただし、私たちは要約の場合、要約を行います。GPT-3のような大規模な言語モデルを使用しないと、馬鹿げたことをしていると思います。

それを微調整する必要がありますが、結果はあなたができることをはるかに超えています。

テキストの要約は、非常に読みやすくするのが難しいですし、それをうまく行うために獲得する必要のあるテキストデータの量は、小さな会社としては考えられないほどです。

今では、私たちのような小さな組織には困難なデータ量で大規模なモデルをトレーニングするために、OpenAIのような素晴らしい企業が存在します。

私たちはそれを活用するだけで、非常によく書かれた要約の利点を得ることができます。私たちが必要とする結果を得るために、それを適応させて微調整するだけです。

複雑な対話型AI システムの課題

Stephen: そうですね、それは非常に興味深いです。システムを運用するということは、チームの設定からコンピューティングの問題まで、さまざまな課題があると思いますが、品質のデータについて話していましたね。

あなたの経験から、システムを破損させる課題は何であり、それを修正して再稼働させるためにどのような対策を講じますか？

Jason: そうですね、この種のシステムを運用する際には、多くの問題があります。いくつかカバーしてみましょう。

ライブ推論の本番環境に入る前に、私たちが「機械学習の技術的負債」と呼ぶ最大の問題の一つは、これらのダイジェストチェーンシステムを実行するときに発生することです。

私たちは、相互に依存し合ったり、依存し合う可能性のある一連のモデルを持っており、それは問題を引き起こす可能性があります。

これは、下流のアルゴリズムが上流のアルゴリズムからのエラーを処理するようにトレーニングする際に、新しいシステムを導入すると混乱が生じる可能性があるためです。

たとえば、私の転記エンジンが単語の転記でたくさんの間違いをする場合、私のチームの中には（伝統的な英語の名前ではない）名前が常に誤って転記される男性がいます。

もし私たちが下流の言語モデルをそれを隠蔽してそれに対応するように作る場合、転記システムを突然変更したり新しいシステムを導入したりした場合、すべてが崩れて壊れることになります。

私たちがやろうとしていることの1つは、上流のシステムのエラーを下流のシステムに組み込まないことです。私たちは常に、下流のパイプラインのモデルが純粋なデータで動作していると仮定し、それによって理想的にはすべてのモデルとシステムを独立してアップグレードできるようにします。

もちろん、私たちは完璧ではありません。私たちはそれを目指していますが、品質の結果を得るためには時にはそのようにするしか選択肢がない場合もあります。

ただし、理想的には、私たちはシステム内のモデルを完全に独立させることを目指しています。それによって、パイプライン内の他のすべてのモデルを更新する必要がなくなる危険を回避できます。

たとえば、転記システムを更新したときに、もはや転記しない単語を取得するようになったが、句読点システムを更新する必要があり、句読点の動作が変わったために行動項目検出システムを更新する必要があります。要約アルゴリズムはもう動作しないので修正する必要があります。

変更を行うコストが極端になる危険な状況に自分自身を閉じ込めることができます。これがその要素の1つです。

もう1つの発見は、機械学習アルゴリズムのデイジーチェーンスタックを実行する際に、パイプラインの任意のコンポーネントでシステムを迅速に再実行できる必要があるということです。

基本的には、あなたの質問の根本に戻ると、私たちはすべてのプロダクションシステムで何かが壊れることを知っています。それは頻繁に起こることです。私はそれが起こらないことを願っていますが、起こるのです。

キューイングされた機械学習アルゴリズムを実行する場合、非常に注意していないと、データがバックアップされ始めてストレージ容量が不足している場合や、パイプラインの途中にデータを保持している場所に問題が発生し、さまざまな悪影響が生じる可能性があります。

システムのさまざまな状態でデータを適切に管理し、パイプラインを常に迅速に再実行できるようにするための優れたツールを構築すると、トラブルから脱出できることがわかります。

私たちは内部で多くのシステムを構築していますので、顧客からの苦情や予想外の受信物がない場合、パイプライン内で失敗した場所を迅速に見つけ出し、パイプラインのそのステップから正確に再開することができます。

問題を修正した後、誤ってデプロイした小さなバグがあったかもしれません、または単なる異常または奇妙なメモリスパイクなどがパイプラインの途中でコンテナがクラッシュすることが原因かもしれません。

私たちは素早くそのステップを実行し、それをシステムの残りの部分を通して押し進め、顧客の手元に出力することができます。システムがどこでもバックアップされ、壊滅的な障害が発生することはありません。

Stephen: そうですね、これらのパイプラインは独立したサービスとして実行されていますか、それとも実行方法には異なるアーキテクチャがありますか？

Jason: はい、ほとんどのモデルとシステムは個別のサービスとして実行されています。私たちは以下のものを使用しています：

• Kubernetesとコンテナ：スケーリングのために使用します。
• Kafka：システム間のメッセージパイプラインソリューションとして使用します。
• Robin Hood Faust：パイプライン内の異なる機械学習モデルをオーケストレートするのに役立ちます。私たちはこのシステムも活用しています。

XemblyはMLチームをどのように設立しましたか？

Stephen: はい、それは素晴らしいポイントです。

チームのセットアップに関して、チームはある意味で言語の専門家を活用しているのでしょうか、また、オペレーションの面でも別個のオペレーションチームが存在し、研究または機械学習エンジニアがこれらのパイプラインなどを行っているのでしょうか？

基本的に、チームの構成はどうなっていますか？

ジェイソン：機械学習の側面に関して言えば、私たちの機械学習チームには3つの要素があります。

• 応用研究チーム：彼らはモデルの構築、どのようなモデルが必要か、どの種類のモデルが必要か、トレーニングとテストはどのように行うかといった研究の側面に責任を持っています。彼らは一般的にモデルを構築し、精度と再現率を定期的に測定し、時間とともに精度を向上させるために変更を加えます。
• データ注釈チーム：彼らの役割は、データの一部を継続的にラベル付けすることです。
• 機械学習パイプラインチーム：このチームは、これらのモデルをホストし、データの入力、出力側でどのように見えるか、スタック全体で異なるモデル間でのデータの交換方法、スタック自体についてのコアソフトウェア開発エンジニアリング作業を行う責任を持っています。

例えば、私たちがKafkaやFaust、MongoDBデータベースについて話したように、それらの要素すべてが効果的に連携する方法に関心を持っています。

計算上の課題と本番環境での大規模言語モデル（LLMs）

スティーブン：なるほど。それを共有してくれてありがとう。大規模な言語モデルを展開する際には、計算パワーに関するもう一つの主な課題がありますよね。これはGPTが抱える課題でもあります。サム・アルトマンがよくツイートしています。

ただ興味深いのですが、本番環境での計算パワーの課題にどのように取り組んでいますか？

ジェイソン：私たちは計算上の課題を抱えています。音声認識は一般的に計算負荷が高いです。スピーカーセグメンテーションや、一般的には生のオーディオに関わるものは、計算負荷が高く、それらのシステムでは通常GPUが必要です。

まず第一に、オーディオコンポーネントなど、純粋な言語処理モデルのような純粋な言語側に対して、重いGPUマシンが必要な部分があることを認識しなければなりません。一部はCPU処理だけで処理できますが、すべてではありません。

私たちにとって重要なことは、スタック内の異なるモデルを理解することです。どのモデルが異なるマシン上に配置される必要があるかを知り、それらの異なるセットのマシンを調達できるようにする必要があります。

私たちはKubernetesとAmazon（AWS）を活用して、機械学習パイプラインが異なるセットのマシンで動作できるようにしています。重いGPUマシンと、より伝統的なCPU志向のマシンがあり、それぞれで実行できます。

それに関連して、費用の面での取り扱いについては2つのことを試みる傾向があります：

• 1
  Kubernetes内のポッドの独立したスケーリング
• 2
  基礎となるEC2ホストのスケーリングも行います。

それには多くの複雑さがありますが、それをうまく行うためには重要です。先述したパイプラインデータやバックアップ、クラッシュに関するいくつかの事柄について話すと、致命的な障害が発生する可能性があります。

マシンのスケーリングをオーバーやアンダースケールしてしまうことは許容できません。マシンの起動と停止を効果的に行う必要があります。特にトラフィックが発生する直前に行うようにします。

基本的に、トラフィックのフローを理解する必要があります。CPU負荷や一般的なリクエストなど、適切なメトリクスを設定する必要があります。

理想的には、トラフィックが発生する前にマシンを適切なタイミングで起動することで、十分に先行している状態にする必要があります。しかし、ほとんどの人にとって、何らかの形で自動スケーリングを行うことが絶対に重要です。

私が音声認識を行っていたキャリアのさまざまな時点で、スケールで動作するために何百台ものサーバーを実行する必要がありました。非常に高額です。もしトラフィックが一般的に米国国内のトラフィックである場合、03:00のサーバーを実行することはお金の無駄です。

もし夜間の期間にマシンの負荷を下げることができれば、多くのお金を節約できます。

NLP製品を構築する際にデータの品質をどのように確保しますか？

スティーブン：素晴らしいですね。では、まずコミュニティからの質問にすぐに入りましょう。

はい、まず、この人が尋ねている最初の質問は、対話型AIや一般的なNLP製品を構築し展開するためには、品質の高いデータが必要ですよね？

製品のライフサイクル全体でデータが高品質であることをどのように確保しますか？

ジェイソン：まったくその通りです。素晴らしい質問ですね。データの品質は重要です。

まず、私たちは実際に独自のデータを収集することを心掛けています。一般的に、公開されているデータセットは必要なものに比べて不十分であることがわかりました。特に、対話型音声の領域ではこれが非常に大きな問題です。

その理由はたくさんあります。まず、データの規模に戻ると、私は対話型音声のおおよそのサイズを算出しましたが、おおよそ1.25京の発話が必要です。

それは、大量の単語の他に、無限に組み合わせることができるという特徴があるためです。私たちはしばしば言葉をつなげて話しますが、それでも互いを理解することができます。

話される音声には実際には文法的な構造があまりありません。私たちは試みますが、書かれた音声のように文法のルールに従うことはほとんどありません。したがって、書かれた音声の領域は限られています。

対話型音声の領域は実際には無限です。人はどもります。言葉を繰り返します。たとえば、トリグラムを扱っている場合、3回言葉を繰り返す「I I I」という発話を有効なものとして受け入れる必要があります。

さらに、すべての単語と組み合わせを考慮すると、無限のデータセットになります。そのため、まず十分なデータが存在しないというスケールの問題があります。

また、プライバシーや法的な問題など、他の問題もあります。なぜ大規模な対話型データセットが存在しないのかというと、自社の会議の録音をすべてオンラインで公開する企業はほとんどありません。

そういったことは普通は行われません。インターネット上で利用できる対話型データセットを探すと、実際のライブオーディオの録音の一部があるかもしれませんが、それらは作り物であり、実際の世界とは関係ありません。

政府の会議を見つけることもありますが、やはりそれらは扱う世界とは関係ありません。一般的には、インターネット上にあるデータを活用することはできません。独自のデータを収集する必要があります。

したがって、独自のデータを持った後、そのデータの品質が十分であることを確認する方法は本当に難しい問題です。

まず、良いデータ注釈チームが必要です。そして、私たちはLabel Studioというオープンソースのツールを使用してデータを迅速に注釈付けしています。データ注釈者には良いツールを提供する必要があります。

データの注釈付けにおけるツールの重要性を人々は過小評価していると思います。また、データセットの品質を時間とともに分析できるように、データにいくつかのメトリクスを適用しようとしています。

私たちは常に「ミスマッチファイル」と呼ばれるものを実行しています。これは、注釈者が付けたラベルをモデルに通し、差異を確認するものです。

それが終わった後、データが正しくラベル付けされているかどうかを手動で評価し、そのプロセスを繰り返しています。

基本的には、新しいデータのラベル付けを常にモデルの予測と比較しているため、データセットが高品質であることを確認しています。

MLチームはどのようなドメインで活動していますか？

スティーブン：そうですね、エピソードの前半を忘れてしまったかもしれませんが、気になっていたのですが、チームはどのようなドメインで活動していますか？ビジネスドメインなのか、一般的なドメインなのか？

ジェイソン：はい、一般的にはビジネスドメインです。企業の会議がまだ比較的大きなドメインですね。

世界にはさまざまなビジネスがありますが、ほとんどがビジネスです。それは消費者間ではなく、私が母に電話をかけるのではなく、ビジネス内の従業員同士が話しています。

会話型AI製品のテスト

Stephen: そうですね、そして私は興味があります、次の質問は、ところで、一部の企業から、会話型AIおよび一般的なNLU製品のテスト戦略について尋ねたいです。

Jason: 自然言語のテストは、モデルの構築において非常に困難だとわかりました。私たちはもちろんトレーニングデータセットとテストデータセットを持っています。データを評価するために、機械学習の伝統的なルールに従ってモデルの構築を行っています。

私たちは時々、少なくともガッチリとチェックできるようなゴールデンなデータセットやミーティングを割り当てて、新しいシステムが全体的に正しいことを確認するために試しました。

しかし、システムが非常に大きいため、それらのテストはガッチリとチェックする以外の何物でもありませんでした。それらは本当のスケールでの評価には適していないため、通常はライブでテストします。それが無制限のドメインでこれを十分に行う唯一の方法だとわかりました。

開発の進行状況によって、2つの異なる方法で機能します。 時にはモデルを展開し、実際の結果を顧客に使用しないままライブデータに対して実行します。

私たちは、私たちのシステムをすべて構造化しています。ダイジェストチェーンのように、機械学習のステップをパイプラインのどこにでも挿入し、並列ステップを実行できるようにしています。これにより、時には「モデルをサイレントモードで実行する」と言えるようなことができます。

私たちは、アクションアイテムを予測するための新しいモデルを持っています。それを実行し、結果を書き出します。しかし、それはパイプラインの残りの部分が操作するものではありません。パイプラインの残りの部分は古いモデルで動作しますが、少なくとも今では、広告テストを行い、両方のモデルがどのような結果を出力したかを確認することができます。

しかし、その後も、非常に頻繁に、新しいモデルを一部のトラフィックにのみ展開し、トップラインのヒューリスティックスやメトリクスを評価して、より良い結果を得られるかどうかを確認します。

私たちの世界では、顧客が私たちが送信する会議の要約を共有してくれることを望んでいます。だから、パイプラインのアルゴリズムを変更して、例えば「顧客は会議のノートをより頻繁に共有していますか？」と確認するのは非常に簡単です。

なぜなら、会議のノートの共有は、私たちが顧客に提供したものの品質のかなり良い指標になる傾向があるからです。したがって、それを追跡して「良くなったか悪くなったか」を確認するための良いヒューリスティックがあります。

それが私たちの一般的なテスト方法です。ほとんどはライブでのテストです。ドメインの性質によるものです。ほぼ無限のドメインで作業している場合、おそらく最終的には改善したかどうかを定量化するためのテストセットは存在しないでしょう。

ML監視とテストのバランスを保つ

Stephen: 本番環境でのモニタリングと実際のテストの間の微妙なバランスはどこにありますか？

Jason: 私たちは常にスタックのすべての部分を監視しています。モデルの出力に対して何かがうまくいっていないかを示すかもしれないシンプルなヒューリスティックスを常に探しています。

言語でギブリッシュを生成していないかを検出するために、perplexityのようなメトリクスを使用することがあります。

ミーティングで予測したアクションアイテムの数を単純にカウントするような簡単なこともできます。これにより、レールから外れていないかなどを常に追跡することができます。また、システム全体の健全性に関するさまざまな監視も行っています。

たとえば：

• すべてのDockerコンテナは実行中ですか？
• CPUやメモリの使用量は適切ですか？

これは、スタックの一部であり、モデル構築側とは少し異なると思います。モデルの構築側では、常にトレーニングデータを作成し、実行し、結果をモデルの日次ビルドの一部として送信しています。

私たちは、データをラベリングし、新しいデータを取り込む際に、常に適合率と再現率のメトリックスを確認しています。モデルの構築そのものをテストすることで、適合率と再現率のメトリックスがどちらかの方向に逸脱していないかを常に確認できます。

対話型AIのためのオープンソースツール

Stephen: そうですね、興味深いですね。さて、次の質問に移りましょう。この人は「対話型AIのためのオープンソースツールをおすすめできますか？」と尋ねています。

Jason: はい、もちろんです。音声認識の領域では、Kaldiなどの音声認識システムがあります。私は強くおすすめします。長い間音声認識のバックボーンの一つでした。

新しいシステムもありますが、Kaldiを使用して素晴らしいことができます。音声認識システムをすぐに始めるためのものです。

明らかに、GPT-3のようなシステムもおすすめです。素晴らしいツールです。微調整するとより良い結果が得られますが、APIの提供や必要に応じた更新の容易さなど、素晴らしい仕事がされています。

エンティティ検出には、SpaCyのようなシステムをよく利用しています。自然言語処理を始めるためには、SpaCyをよく知ることを強くおすすめします。素晴らしいシステムです。箱から出してすぐに素晴らしい結果が得られます。さまざまなモデルがあります。年々一貫して改善されています。

そして、データラベリングにはLabel Studioを使用しています。これは、さまざまな種類のコンテンツ（音声、テキスト、ビデオ）のラベリングをサポートするオープンソースツールです。すぐに始めてデータを迅速にラベリングすることができます。始めようとしている人に強くおすすめします。

大規模企業向けの対話型AI製品の構築

Stephen: それでは、共有してくれてありがとう。次の質問です。

この人は「大規模企業向けの対話型AI製品をどのように構築しますか？プロジェクトが始まるときに考慮すべき点は何ですか？」と尋ねています。

Jason: はい、私は大規模な組織で非常に高いトラフィック負荷を扱う場合は、費用とスケールが最大の問題だと思います。

大規模な組織では、そのようなスケールを処理するために非常に多くのサーバー容量が必要になります。ですので、私のおすすめは、そのスタックの真のオペレーションサイドをよく考える必要があります。Kubernetesを使用しているか、Amazonを使用しているかに関係なく、自動スケーリングの構成について考える必要があります。

• 自動スケーリングをトリガーするメトリックスは何ですか？
• それをどのように機能させますか？

ポッドとKubernetesを、自動スケーリングされるEC2ホストの上に配置することは、迅速に機能させるのは非常に困難です。以前にも述べたように、一部のモデルの複雑さには、一般的にはGPUが必要ですが、他のモデルには必要ありません。

したがって、システムを適切なタイプのノードに分散させ、独立してスケールする方法も考慮する必要があります。また、それらのマシンをどのように割り当てるかも考慮する必要があります。

トラフィックに応じてどのマシンを購入しますか？どのマシンを予約しますか？コストを削減するためにスポットインスタンスを購入しますか？これらは、大規模な企業でこれらのことを成功させたい場合に考慮するべきすべての要素です。

エッジデバイスに対話型AI製品を展開する

Stephen: 素晴らしい。それを共有してくれてありがとう。

それでは、次の質問に移りましょう。オンデバイスの対話型AI製品の展開と一般的な製品の課題はどのように扱いますか？

Jason: オンデバイスと言うと、サーバーに展開するのか、制約のあるデバイスに展開するのかどちらを指していますか？

Stephen: ああ、制約のあるデバイスです。エッジデバイスや計算能力のないデバイスです。

Jason: はい、私は数年間小さな計算デバイスへのモデルの展開には関わっていません。例えば、接続カメラの場合は、過去に取り組んだことを共有できます。

デバイスとクラウドの間で負荷を分散しました。高速な応答、低遅延のものについては、システムの小規模なコンポーネントをそこで実行し、より複雑なコンポーネントをクラウドに転送します。

これがユーザーの質問にどれだけ関連しているかはわかりませんが、私は過去にこれに取り組んだことがあります。基本的には、デバイス上で非常に軽量なスピーチ認識システムを実行して、ウェイクワードを検出したり、初期のシステムを立ち上げたりします。

しかし、一度動作し始めると、これらのシステムのいくつかの計算を小さな制約のあるデバイスで処理することは一般的にできませんので、すべての大規模な要求をクラウドインスタンスに転送します。

ChatGPTについての議論

Stephen: ChatGPTについて議論しないで終わるのは犯罪だと思います。ちなみに、これはよくある質問です。

ChatGPTと人々が今日どのように使用しているかについて、あなたの意見は何ですか？

Jason: ええ、まさにそれを始める前に聞いてくれれば、おそらく1時間半話せるでしょう。

ChatGPTやGPTは、一般的にすごいです。これについてはすでにたくさん話しましたが、言語が非常に多くのトレーニングを受けているため、非常に少ない入力で素晴らしいテキストを生成することができます。

ただし、これらのシステムを使用する際にはいくつかの注意点があります。

まず、言及したように、トレーニングセットは固定されています。動的に更新されないため、セッション内で状態を維持できるかどうかは考える必要があります。対話中に新しい単語を発明した場合、通常はその単語を後の会話で活用できるでしょう。

しかし、セッションを終了して戻ってきた場合、その単語については何も知りません。また、固定されているため、2021年以前のことしか知りません。

オリジナルのGPT3は2018年以前のものであり、現代の出来事には無知です。しかし、おそらく最も重要なことは、これを使用することから判断すると、それは大規模な言語モデルであり、実際には次の単語を予測しているだけであるということです。

それ自体は知能ではありません。データの人間エンコーディングを取り、それを言語としてエンコードし、次の単語を予測するように学習します。これは知能の良い代理であることがわかりますが、それ自体が知能ではありません。このため、GPT3やChatGPTは、次に予測される単語に基づいてデータを作成することがあります。

ChatGPTの少し怖いところは、非常にうまく書くことができるので、非常に説得力のある形で誤りを述べることができるということです。細部に注意を払わない限り、見逃してしまう可能性があります。それがおそらく最も恐ろしい部分です。

それは、否定のような微妙なものかもしれません。素早く読むと、目はそれを見逃し、気づかないかもしれませんが、それは完全に事実に反するかもしれません。何かしらの方法で、我々は素晴らしいものの過剰に苦しんでいます。それはあまりにも良くなりすぎていて、読みやすいため、人間が評価する際に実際に間違っているということが見逃される可能性があるのです。

これらのシステムは素晴らしいと思います。多くの人々にとって、機械学習や自然言語処理の方法を根本的に変えるでしょうし、人々がどのようにインタラクトするかも変えるでしょう。

ただし、一般的なコンピュータと同様に、それはただ動作する魔法のようなものではなく、それを前提にすることは危険です。自分自身で使用する場合は、微調整を強くお勧めします。

他の人のためにコンテンツを生成するなど、そのまま使用しようとする場合は、お客様に内容の確認と読解を強くお勧めします。盲目的に共有しないでください。なぜなら、そこに含まれているものが100％正確ではない可能性があるからです。

まとめ

Stephen: 素晴らしい。ありがとう、ジェイソン。それで、これが私からのすべてです。

Sabine: そう、まだ説得力があるかどうかは分かりませんが、今のところは単なる作り話ですね。ですから、どうなるか見てみましょう。でも、ジェイソン、本当に専門知識とアドバイスを共有してくれてありがとうございます。

あなたと一緒にいてとても楽しかったです。

Jason: はい、スティーブン、本当に素晴らしかったです。会話をとても楽しんでいました。

Sabine: 最後に、どのようにオンラインであなたの活動をフォローできますか？連絡を取りたい場合はどうすればいいですか？

Jason: はい、Xemblyはオンラインでwww.xembly.comをフォローできます。私に連絡を取ることもできます。私の名前はジェイソンで、[email protected]です。質問があれば、喜んでお答えします。そして、私たちのウェブサイトをチェックして、最新情報を確認してください。

Sabine: 素晴らしい。とてもありがとうございます。mlops Liveでは、いつものように2週間後に戻ってきます。そして次回は、Silas BempongとAbhijit Rameshが一緒にいて、臨床研究のためのMLOpsについて話す予定です。

それまでの間、ソーシャルメディアやMLOpsコミュニティのスラックでお会いしましょう。近いうちにお会いしましょう。ありがとうございました。お元気で。

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!