ナレッジワークAI商談記録のインフラアーキテクチャ

株式会社ナレッジワークは「LIFE WITH ENABLEMENT できる喜びが巡る日々を届ける」をミッションに、現在は主に大手企業を対象に営業支援およびセールスイネーブルメントAI「ナレッジワーク」を中心に開発・提供しています。
ナレッジワークはマルチプロダクトを展開しており、今回事例として紹介する「ナレッジワークAI商談記録」は日本語文字起こし機能、Salesforceとの連携、オンライン・オフライン両方の商談対応、要約機能、話者分離機能を備えています。
ナレッジワークAI商談記録では多くのAIモデルを内製しており、AIリサーチャーによって開発したモデル・処理をAIエンジニアがデプロイする、という体制で開発しています。

アーキテクチャ設計について

■ オンライン会議


■ オフライン会議

議事録を生成するパイプラインの処理フローは以下のようになります。

1. 話者分離（ただし、オンライン会議の場合はWeb会議システムの話者・発話情報を利用）
2. 音声区間検出（VAD）・音声認識（ASR）
3. 文字起こしの後処理
   • フィラー・吃音の削除
   • 漢数字をアラビア数字に変換
   • 句読点の挿入（系列ラベリング）
   • 辞書による単語の上書き
4. LLMによる要約

この中でLLMのみAPIを利用し、その他は内製のモデルやルールベースの処理を使用しています。内製化してる理由は2つで、1つは話者分離や後処理といった他の処理と柔軟に組み合わせてカスタマイズが容易になるためです。 2つ目はコストメリットでAPIを利用するよりも安く抑えることができるため内製化しています。 一方LLMは、APIと同等レベルのOSS LLMを動かすには、インフラ管理に労力を割かなければならないことが想定されたのですが、少人数でサービス開発をしている状況を踏まえてAPIを活用しています。

開発時の課題として、プロダクトとして議事録の精度を最優先するため、高精度なASRモデルを開発しました。その結果、処理に一定の時間を要していましたが、精度を維持したまま高速化するためにアーキテクチャの最適化を行いました。結果として、1時間の会議でおよそ10〜20分でユーザーに結果を表示できるようにしました。これらの施策はゴールではなく、将来のStreaming ASR導入やリアルタイムAIエージェントの実現に向けた基盤強化につながっていますので、今回は現段階の工夫点について紹介します。

オンライン会議では、録画ボットを利用して音声データを取得し、10秒単位でチャンク化してS3に保存します。文字起こしタスクではそのチャンクデータを逐次読み込みながらVAD→ASRを実行しています。会議のバックグラウンドで解析処理を進めることで、体感的な待ちを抑えられます。さらに音声ストリーミング時の欠損に備え、各フラグメントと併せて欠損のメタ情報も保存。会議終了後はそのメタ情報に基づき、欠損区間のみを元の全体音声から抽出して ASR を再実行し、欠損を補完します。

オフライン会議の場合、録音時の通信環境が悪く、オンライン会議と同等の音声ストリーミングが達成できない懸念がありました。またオフライン会議ではWeb会議システムのように「誰が・いつ話したか」の情報がないため話者分離も実行する必要があります。そこでオンラインとは根本的にアーキテクチャを変え、会議全体の音声データをASRの並列処理する方法を取っています。

並列化を行うために、VADとASRを別タスクとして分離し、VADのセグメントを分割して複数のASRタスクで解析する、という処理に変更しました。また、文字起こしのタスクと並列で話者分離を実行し、後処理で話者情報と文字起こし情報を結合することで、全体での処理時間短縮を実現しています。

今後の展望や取り組み予定

今後取り組んでみたいことは3つあります。1つは解析ワークフローのさらなる高速化に取り組んでいきます。具体的には、話者分離タスクをCPUからGPUに移行する、コンテナイメージを最適化して起動のオーバーヘッドを削減するなどの改善余地があります。加えて、ASRモデルについても次に述べるStreaming ASRによる高速化が挙げられます。こうした施策を積み上げることで、1秒でも速い結果表示を実現していきたいと考えています。

2つ目に、現在使用しているASRモデルと同等精度のStreaming ASRモデルの開発です。これは単なる高速化手段にとどまらず、商談中にリアルタイムでフィードバックを返す「AIエージェント」構想の実現に欠かせない要素です。それを実現するためには現在のASRモデルでは限界があるため、速度・精度を両立したStreaming ASRモデルの開発とプロダクト実装を進めて行きます。

最後に、学習したモデルのプロダクト上での精度比較を、もっと簡単にできる仕組みを導入したいです。現在だとstg環境に新モデルをデプロイして、prod環境の出力と見比べる、という定性評価を行っています。しかしその方法だと、環境毎の設定によって精度差が発生するものもあるため切り分けが難しくなります。そのため、シャドウテストなど、同じ環境で2つ以上のパイプラインを実行できるようにして、より厳密な比較検証をできる環境を作っていきたいです。

◆執筆：みつい