「LLM時代に進化するプロダクト開発」でAIサマリーの開発プロセスについて登壇してきました
こんにちは。mento データサイエンティストの杉浦です。
8/27（火）に「LLM時代に進化するプロダクト開発」というイベントで登壇してきたので、その内容をブログで紹介したいと思います。LLMを使ってコーチングの対話を要約する「mento AIサマリー」のリリースまでのプロセスについてお話します。
登壇資料はこちらから。
プチ自慢ですが、ありがたいことにmentoの「AIサマリー」は、最近第9回HRテクノロジー大賞で部門優秀賞も受賞しました。
問題は小さく分けて、いい分析にはいいデータを
さて、今回は対話要約機能「AIサマリー」を作るときに具体的に気をつけたことについてご紹介します。LLM活用プロダクトを作る上で「問題は小さく分けることが大事」「いい分析にはいいデータが必要」という話を改めてお伝えできたらと思っています。
LLMを活用して作った「AIサマリー」とは？
まず前提として、コーチングとはコーチングの受講者であるクライアントが望む状態を実現するために行うコーチとの1on1の対話のことを指します。
話すことで考えが整理され、そこで気づきが生まれ、こうしようという意志が決まり、そして行動につながる。このようなサイクルで行動変容を促進するものです。
mentoは企業の中間管理職や次世代リーダー層に多くご利用いただいていますが、半年から1年ほどの期間でコーチングセッションを受けていただくことが多いです。
ただ、コーチングの領域はまだまだ白地まみれです。
例えば、横軸にコーチングのセッション日と縦軸にコーチングを受けた時のパフォーマンスやコンディションとします。コーチングセッションを受けた直後は「よしいくぞ！頑張るぞ！」となるのですが、そこから忙しい日々に戻ると忘れてしまいます。
最終的には右肩上がりになっていくのですが、パフォーマンスが下がることも多くて、あまり効率はよくありません。60分コーチとの対話があっても、そのコーチングの内容を忘れてしまうので、結果として具体的なアクションを変えられていないということが発生しています。
そんななか、“負荷なく”、”適切な粒度で”セッションを振り返ってもらいたいと考えて「AIサマリー」を開発しました。
簡単なデモはこちらです。コーチングセッションが終わると通知が届き、mentoにアクセスすると、セッションの内容がサマリーとして見られます。
＜AIサマリーの内容＞
1時間のコーチングを通じた「タイトル」「キーワード」
全体の流れがわかる「ピックアップ」
次回のコーチングに向けて宣言した「ネクストアクション」
手間なく負荷なく、セッション中にメモを残していなくても後で内容を思い出して行動できるような要約を作成します。
AIサマリーを作る上での壁
このAIサマリーを実際にどう作るか？
シンプルに考えると、録音データから文字起こしをして、そこから要約データを作るといったプロセスになります。要約だったら割と普通に精度が出るんじゃないか？と思うかもしれませんが、精度はかなり低いです。
実際に企画開発する時に社内でPoCをするのですが、社内で募ったフィードバックだと「このままだと外には出せない」という評価でした。
初期に作った要約は、下記のような状態でした。
言ってもいないことが勝手に書かれている（ハルシネーション）
コーチとクライアントがいる中で、自分の発言ではなくコーチの発言が書かれている
欲しい粒度の要約ではない。例えば「自身のマネジメントの悩みを話した」と書かれても大まかすぎて意味がない
そもそも文字起こしの精度が低い。例えば「部下との1on1」が「部下とのワンワン」になる
そこから何が起きているか？を生データから全て徹底的に確認しました。初期のAIサマリーと実際の文字起こしのデータや録音データを全部見て、何が合っていて何が間違っているかを手動でチェックしました。
生データでの検証は数十件近くにのぼります。もちろん、社内協力者に許可を取った上での検証です。
どうやって直していくか？
生データを確認・検証した上で、これらをどうやって修正していったかをお話します。結論、機械学習プロダクトの実装の基本の通りに愚直に解きました。問題を小さく分けることと、いい分析にはいいデータが必要、という話です。
まず録音データから「文字起こしの精度が低い」という問題については「誤字脱字がある」、「発話していない単語が存在する」という小さい問題に分けられます。
次に「要約の精度が低い」という問題については、「誤字が存在する」「抽出したい内容が含まれていない」「発言していない内容が含まれる」「意味がある抽象度ではない」「フォーマットが守れていない」という問題に分けられます。
これらの問題を一つ一つ具体的に解いていきました。
＜文字起こしの精度について＞
問題1.誤字が存在
誤字を100％なくすのはもちろん無理だが、コーチングのデータに対して、複数のモデルを適用して検証
Amazon transcribe/Gemini/Azure Speech to text/AmiVoice/Whipser(v2/v3)/…
問題2.脱字が存在
話者が重なった場合に誤りが増えるケースが多い
音声認識の前提として、音声ファイルが分離されているケースの方が精度が圧倒的に良い
そのため、そもそも録音時に音声ファイルを話者分離できるサービスを利用
問題3.発言していない内容が存在
コーチングが1on1のセッションなので、話者分離されているデータを使って文字起こしした場合に、無音期間が長くなる
クライアントが話している間、コーチのデータはずっと無音になる
そうなると無音期間に対して、特定のモデルは文字起こしの精度が非常に不安定になる
音声扱っている人はあるあるだと思いますが、無音なのに「ご視聴ありがとうございました」と出てきてしまう問題がある
そのため、発話区間推定(Voice Activity Detection)を行い、発生部分のみを文字起こしを実施
＜要約の精度について＞
問題1.誤字が存在
誤字の中でも「人名」や「専門用語」、フィラーなどは一定のパターン化が可能です。それらは個別の前処理を対応
つまりAIを噛ませる必要がない部分は手動対応するということです
問題2.抽出したい内容が含まれていない
文字起こし全体をいきなり要約させると精度が悪い
そのため、まずは文字起こし全体を段落分割
ここまでが一段落目、ここまでが二段落目……と段落分けだけのタスクをさせます
問題3.発言していない内容が含まれる/意味がある抽象度ではない
こちらも要約を一気にするのではなく、タスクを分解
今回でいうと「キーワード特定」「ネクストアクション特定」「テーマ特定」の3タスクに分けた上で実施
問題4.フォーマットを守れていない
Function calling/Structured Outputなどフォーマットをある程度固められるものを利用して精度向上
まとめると、下記の通り（本当はもう少しいろいろある）。
改めて「問題を小さく分けて、いい分析にはいいデータを」という考え方で愚直に解いて、AIサマリーを開発したプロセスをご紹介しました。
リリースについて
最後に、リリースについてもお話します。
リリース基準となる精度は定性評価になりがちだと思います。それでも定性の基準を定量評価に落とし込んで1,2,3,4などの点数にして「何点以上だったらリリースしましょう」ときちんとリリース基準を定めました。
実際にAIサマリーはこの開発プロセスを進めたおかげで、コーチからもクライアントからもいいフィードバックを頂けています。
終わりに
今回は「AIサマリー」の具体的な開発プロセスについてお話しましたが、今後も非構造化データに対する機能開発やプロダクト作りを進めていきます。LLM活用機能は事業の根幹として継続していきます。
LLM活用のテーマについても、コーチングや組織の話でも、お話したい方がいたらお気軽にカジュアル面談しましょう！