ACES エンジニアブログ

ACESのエンジニアブログです。

AIアルゴリズムのプロフェッショナルと協働するソフトウェア開発の魅力

ACES Meet 組織・文化

こんにちは、株式会社ACES でソフトウェアエンジニアをしている奥田（@masaya_okuda）です。

独自 AI による話者ごとの自動文字起こしや重要なシーンの可視化を行い、オンライン商談における成約率の向上と現場の工数削減に寄与する商談解析 AI ツール「ACES Meet」を開発しています。

meet.acesinc.co.jp

現職で初めてAIが根幹にあるソフトウェアサービスを開発し、従来の開発と比較して「設計の難易度が明確に上がった」と感じています。AI機能はユーザーが使えば使うほど精度が上がる一方で、学習が十分でないフェーズでは期待値を下回ってしまう可能性があります。

それを乗り越えてユーザーにご利用いただくため、開発時にはAIエンジニアとソフトウェアエンジニアが協働して機能開発を行います。AIエンジニアがAI自体の精度向上を担当し、ソフトウェアエンジニアがAIをユーザーが利用可能なUIを持ったソフトウェアとして実装します。

特に、「いかにユーザーにストレスを感じさせない体験を作るか？」「100%ではないAIの精度をソフトウェア側でどうカバーするか？」をAIエンジニアと共に設計しプロダクトに落とし込んでいく過程に、これまでにない面白さを感じています！

そこで今回は、ソフトウェアエンジニア目線でAIプロダクト開発の課題や魅力をご紹介したいと思います。

ACESの開発組織

まずは簡単に組織についてご紹介します。ACESは「アルゴリズムで、社会はもっとシンプルになる。」というビジョンのもと、アルゴリズム事業を展開する会社です。SaaSを提供するAIソフトウェア事業に加え、クライアントとプロジェクト型で伴走するDXパートナー事業、AIソフトウェアの研究開発部門があり、時短社員も含めると30名以上のエンジニアが所属しています。

私はAIソフトウェア事業に所属しており、研究開発部門と連携して「ACES Meet」を開発しています。

直近のAI機能リリース

ACES Meetは先日、「同じマイクで複数人が話しても、話者を識別する機能」をリリースしました。ユーザーの音声データを学習し、同じマイクに対して複数人が話しても話者を特定して文字起こしを行うことができます。この機能によってオフライン会議でもACES Meetを活用できるようになります。

同じマイクで複数人が話しても、話者を識別する機能
同じマイクで複数人が話しても、話者を識別する機能

この機能を実装する中でAIプロダクトの難しさに直面しました。

AI故の課題

これまで私が経験してきたソフトウェア開発は、「あらかじめ機能要件を定義し、要件を実現するように実装する」というプロセスで行われていました。エンジニアが開発した以上のことはできませんが、十分に検証すれば不具合のリスクは小さくできます。一方で、AIの期待性能を100%にすることは難しいため、AIが間違えたときの体験を保証する必要があります。

エンジニアの精度テストでは高い性能で話者を識別できていたにも関わらず、いざビジネスサイドの方を交えてレビューを行ったところ、稀に起こる失敗によってユーザーの体験を大きく損ねるのではないか？というリアクションが返ってきました。

音声を聞いて話者を識別することは人間にとって簡単であり、それをAIが間違えると、ユーザーは自分で手を動かした方が速いと見切りをつけてしまうリスクが高まります。

この機能の場合、会議参加者の発話量や音声の学習状況によっては3人で会議しているのに4人に過剰分割されるといったことが起こり、ユーザー体験の悪化が懸念されました。

トラストの観点をもとにユーザー体験を考える

仕様を再度検討するにあたり、AIエンジニアからトラストの観点をもとに見直そうと提案が上がりました。AIをプロダクトやサービスに組み込む場合には、人とAIの間にトラスト（信頼関係）が構築され、人が安心して使える状態を追求することが重要です。

たとえばAIの技術そのものが素晴らしくても、人が使い方を理解できなかったり、期待と異なる動作をし且つその理由がわからないと継続的な利用には繋がりません。

以下はMicrosoftの「人間と AI の相互作用に関するガイドライン」を参考に、特にACES Meetに重要な部分をピックアップした観点です。

learn.microsoft.com

トラストの観点

  • 機能を使う前に、
    • AIが「何ができるか」を容易に理解できるか？
    • AIが「どれくらい上手くできるか」を容易に理解できるか？
  • AIが間違えた時に、
    • ユーザーが「なぜAIがそのように間違えたか」を理解できるか？
    • ユーザーがAIの失敗を容易に修正することができるか？
    • AI機能をすぐさまオフにできるか。また必要な時だけ呼び出せるのか？

この中でも、

  • AIが「どれくらい上手くできるか」を容易に理解できるか？
  • AI機能をすぐさまオフにできるか。また必要な時だけ呼び出せるのか？

に着目し、最終的にはソフトウェアエンジニアとAIエンジニアで役割分担してリリースまで走り切ることとなりました。

  • AIエンジニア
    • AIの精度自体をさらに向上させる
    • 発話量が少ない場合、無理に分割しない
  • ソフトウェアエンジニア
    • 機能をON / OFFできるようにし、ユーザーが必要なときだけONにできるようにする
    • 「どんな環境なら高い精度で利用できるか？」を厚く説明したサポートページを設け、機能のすぐ近くに導線を設置する

AIプロダクトの面白さ

ACESで働くソフトウェアエンジニアとして、AIという新しいパラダイムのユーザー体験をAIエンジニアと共に考え作り上げていくことが、最も面白い瞬間です。

ACESにはAIアルゴリズムのプロフェッショナルが多数在籍しており、AIの精度をチューニングし理想の状態に近づけることができます。一方で、どんなに精度が高くてもAIの処理では間違いは発生し、結果ユーザーは難解であると感じやすいのです。

そのため、ソフトウェアエンジニア側では「どのようなインターフェースが分かりやすいのか？」「AIの精度が及ばない部分をどうフォローするか？」を設計し、ユーザーがより利用してくれる状態を目指します。

私はフロントエンドを中心に開発していますが、AIを利用したプロダクトにおいてどのようなUIがユーザーにとって分かりやすいのか？に関する国内の事例はまだ多くありません。具体的な実例が限られているチャレンジングな環境での開発を日々楽しんでいます！

今回はトラストの観点に沿って、以下の工夫を行いました。

  • 機能のON / OFFを簡単に切り替えられる
  • 設定導線の中にサポートページへのリンクを設置し、「AIに何ができるか？どれくらい上手くできるか？」を説明する

同じマイクで複数人が話しても、話者を識別する機能の設定画面
同じマイクで複数人が話しても、話者を識別する機能の設定画面

サポートページでフォローできることには限界があるため、機能設計時点でいかにUI/UXをシンプルにできるかが今後の課題です。

おわりに

本記事では、AIプロダクト開発の課題や魅力についてご紹介してきました。今後もAIエンジニアとソフトウェアエンジニアの協働を通して、お客様にとって使いやすいプロダクトづくりに努めてまいります。

これを実現するために、ソフトウェアエンジニアをはじめNLPのアルゴリズムエンジニアなど幅広く募集しています。弊社の取り組みにご興味をお持ちいただける場合は、下記の募集ページから是非ご応募ください！

Serverside Engineer

https://open.talentio.com/r/1/c/aces/pages/22028

Front-end Engineer

https://open.talentio.com/r/1/c/aces/pages/22026

Algorithm Engineer（自然言語処理・音声認識）

https://open.talentio.com/r/1/c/aces/pages/55104

【登壇レポート】LLMをファインチューニングして対話用のLLMを作成する

大規模モデル イベント

こんにちは、株式会社ACESの久保 (@seishin55) です。 1ヶ月程前になりますが、大規模言語モデルのイベント「TechFeed Experts Night#23 〜 【非AI技術者向け】大規模言語モデルを易しく学ぶ」で登壇してきたので、そのときの資料等内容について公開します！

techfeed.io

イベント概要

内容としては以下のような内容でした。

  • @karaage0703 オープンなLLMをローカルで動かす
  • @seishin55 LLMをファインチューニングして対話用のLLMを作成する
  • @y_kimura199412 LLMの非専門家のエンジニアのためのGPT活用具体例

からあげさんも登壇レポートを上げていらっしゃるのでこちらもご参照下さい！

karaage.hatenadiary.jp

登壇内容

私は「LLMをファインチューニングして対話用のLLMを作成する」という題目でLLMのファインチューニングについて発表しました。以下の資料をご参照下さい。(内容は登壇時のものです。オープンなLLMもこの1ヶ月で色々と進展がありましたね)

techexpert_20230719 by @seishin55

イベントは以下の動画で見ることができます。

youtu.be

イベントの書き起こし記事を以下で見ることができます。 techfeed.io

おわりに

ACESではLLMの開発・導入をガンガン行っています！ご興味ある方は以下のリンクから是非ご応募ください！

acesinc.co.jp

MicrosoftのOAuth2.0連携機能の開発を振り返る

ACES Meet

こんにちは、株式会社ACESでソフトウェアエンジニアをしている村上 (@d_murakami_0816) です。

ACES は、オンライン会議を録画し、独自 AI による話者ごとの自動文字起こしや重要なシーンの可視化を行うことで、オンライン商談における成約率の向上と現場の工数削減に寄与する商談解析 AI ツール「ACES Meet」を提供しています。今回はACES Meetで提供しているMicrosoft IDプラットフォームとの連携機能 (以下Microsoft連携) について、実装に至った背景と実装の際に苦労した部分についてこの場を借りて振り返りたいと思います。今後同様に連携機能を開発する方の助けになれば幸いです。

Microsoft連携の前提知識

Microsoft連携はOAuth 2.0の認証フローを用いて実現しています。OAuth 2.0の認証フローについてはRFC 6749のドキュメントをご参照ください。 (内容はこちらで翻訳されているのでこちらもご参照ください)

OAuth認証にはその認証方法で大きく分けて以下の4つのフローが存在しています。

  • Authorization Code Grant
  • Client Credentials Grant
  • Implicit Grant
  • Resource Owner Password Credentials Grant

今回のMicrosoft連携ではこのうち、Authorization Code Grant, Client Credentials Grantを扱っています。

Microsoft連携をなぜ実装したか

ACES Meetはオンラインで行った会議の情報を取得して、解析を行いその結果を提供するサービスになっています。したがってまず機能を利用するためにオンラインで行った会議の情報を取得する必要があります。

ACES Meetは初期リリース時、ZoomのAPIを用いてZoomで行った会議に対して上記のような解析機能を提供していました。しかし、その中で2つの課題がありました。

  • ACES Meetで作成した会議をMicrosoft Outlookに反映させてスケジュール管理できるようにしたい
  • Microsoft Teamsで行なった会議を録画できるようにしたい

Microsoft Teams (以下Teams) やMicrosoft Outlook (以下Outlook) は日本国内で見ても利用率が高く、ACES MeetとしてもTeamsを利用するユーザーもACES Meetの機能を利用できるようになることや、Outlookを利用しているユーザーがよりACES Meetを使いやすくなることは今後サービスを多くの方にご利用いただくには必要不可欠となっていました。

そういった背景から今回Microsoft連携を実装することを決定しました。

Microsoft連携を実装するにあたって苦労した部分

Microsoft連携を実装することが決まったものの、弊社では普段社内会議・商談ともにZoomの利用が主となっており、Microsoft環境についての知見はほとんどない状態でした。そんな状態から公式のドキュメントを参考に実装を進めていくわけですが、当然多くの壁にぶつかることとなりました。今回はその中でも特に大変だったものについていくつかピックアップしてみました。これからMicrosoft連携を実装する方の参考になれば幸いです。

①ドキュメントが膨大かつ用語が複雑

Microsoftのドキュメントは非常に内容が多く、かつ複雑です。Microsoftの歴史を考えれば当然のことだと思います。知りたい情報だけを得ようとしてもその説明を理解するために別のページを開くみたいなことが繰り返され、気がつくとタブがMicrosoftのドキュメントだらけになります。

一方で体系的に情報を取得しようとしてもどこを見れば知りたい情報に繋がっているのか最初はなかなかわからないです。

Microsoftのドキュメントトップページ

Microsoftのドキュメントを開くとこのようなトップページが出てきます。これだけでもサービスの多さを感じます。Microsoft連携はAzure ADを通して行われるのでAzureを選択します。

Azureのドキュメントトップページ

大分数が絞れてきたので探しやすくなると思ったのですが、この中にAzure ADがありません。ここに出ているのは「基本」の製品のみなのでAzure ADは出てきていないようです。なのでここからAzure ADを探すことになります。連携機能に関係するので「開発者ツール」、ユーザーに連携機能の許可を出したりするので「管理とガバナンス」、サービス間の通信やMicrosoft内のリソースを扱うので「ネットワーク」や「セキュリティ」など思いつく項目から探していくと、

AzureのドキュメントでIDを選択した場合

「ID」の中で見つかります。連携機能を実現する際にAzure ADから操作することが多いのですが、Azure ADそのものは「Azure Active Directory (Azure AD) は、クラウドベースの ID およびアクセス管理サービスです。」とAzure ADの説明にある通り、ID管理の製品になります。このAzure ADのドキュメントからMicrosoft IDプラットフォームのドキュメントに遷移することでやっと連携機能の実装に必要な情報に辿り着くことができます。

このようにドキュメントが膨大なので必要な情報に辿り着くのに非常に苦労しました。自分の主観になりますが、今後Microsoft連携を実装する方に向けて特に読んでおくべき記事をいくつかピックアップしたので参考にしていただければと思います。

②アクセス許可の種類による連携フローの違い

Microsoft連携を実現するにあたってAzure AD上でアクセス許可を設定するのですが、このときにアクセス許可の種類に「委任されたアクセス許可」と「アプリケーションの許可」の2つが存在します。

Azure ADのアクセス許可の画面

説明だけではあまりイメージが掴めなかったので「委任されたアクセス許可」と「アプリケーションの許可」についてドキュメントを探してみたのですが、こちらもなかなか見つかりません。

サポートの方などに問い合わせをする過程でわかったのですが、「委任されたアクセス許可」がAuthorization Code Grantと、「アプリケーションの許可」がClient Credentials Grantとそれぞれ対応づけされているようでした。

その情報を元にドキュメントを確認すると、Client Credentials Grantの説明の方に「アプリケーションの許可」に関する記載がありました。

ここに関してはドキュメントからなかなか辿れなかったのもあり、情報が結びつかずかなり苦戦した箇所になりました。

③Authorization Code Grantの管理者による同意

Authorization Code Grantは基本的にユーザーによってリソースへのアクセスに同意する形になっていますが、Azure ADではユーザーから同意する代わりに管理者が一括で同意するということが可能になっています。加えてユーザーからの同意を禁止して管理者しかリソースへのアクセスに同意できないようにする設定も存在しています。

この設定自体は問題ないように思えるのですが、OIDCの仕様と合わせたときに直感的ではない挙動がありそこでハマることになりました。

OIDCでは最初にユーザーに同意を要求する際にpromptという値を設定することができます。これは一度同意を行なったユーザーであっても連携時に再度同意を要求するという設定になります。一方でAzure ADではユーザーからの同意を禁止できるので両方の設定が有効になっていると「ユーザーから同意はできないのに毎回ユーザーの同意が要求される」という状態が発生し連携できなくなってしまうという問題がありました。

管理者の同意がうまくいかないように映るのでなかなか連携時の設定の方に思考がいかず、こちらもかなりハマることになりました。

(サポートの方に問い合わせたときに紹介していただいたのですが、サポートブログというものがあるらしく、そこにこの件についての記載がありました。当時はサポートブログの存在を知らなかったのでなかなか見つけるのは難しかったのですが、上手く検索できていれば辿り着けたのかなと思っています。)

また、この設定自体もClient Credentials Grantと混同しやすいので注意が必要になります。

どちらも管理者から同意を行うという点は同じなのですが、以下のように違いがあるので注意した上で必要なフローを選択していただくのが良いと思います。

  • Authorization Code Grant
    • 管理者から同意を行なった後にユーザーごとに連携処理を行う必要がある
    • 操作できるリソースをユーザーによって制限することができる
    • Azure AD内の「委任されたアクセス許可」に対応
  • Client Credentials Grant
    • 管理者から同意を行なった後にユーザーごとの操作は必要ない
    • 全ユーザーのリソースを操作することができる
    • Azure AD内の「アプリケーションの許可」に対応

まとめ

今回はACES MeetでMicrosoft連携を実現するに至った経緯とその際に苦労した箇所について簡単に説明させていただきました。

今回これらの課題を解決するにあたってサポートの方には大変お世話になりました。この場を借りて感謝を述べさせていただきます。

同様にMicrosoft連携を実装する方にとってこの記事が問題解決の参考になってくれればいいなと思っています。

ACES Meetはサービスの性質上、これ以外にも複数のサービスとの連携機能を実装しています。今後もこういった連携機能を強化していくことでより多くのユーザーに使っていただけるように努めて参ります。

弊社ではACES Meetをより良いサービスにしていくために引き続きソフトウェアエンジニア、アルゴリズムエンジニアを補充しております。弊社の取り組みにご興味をお持ちいただける場合は、下記の募集ページから是非ご応募ください！

Serverside Engineeropen.talentio.com

Front-end Engineeropen.talentio.com

Algorithm Engineer（自然言語処理・音声認識）open.talentio.com

参考サイト

CyberAgent社の日本語LLM OpenCALMの対話モデル用途のfinetune検証

大規模モデル

こんにちは、ACESでアルゴリズムエンジニアとして働いている檜口です。最近はChatGPTを始めとする言語モデルの研究開発やプロダクト改善に取り組んでいます。

昨年末のChatGPTのリリース以降、大規模言語モデル（large language model, LLM）の社会実装が急速に進んできています。弊社でも商談解析AIツールACES MeetにLLMを組み込むなど、LLMの活用を広げています。こちらに関してはLLMを活用したAIまとめ機能リリースの裏側について過去記事を書いてありますのでご興味ある方はぜひご覧ください。

tech.acesinc.co.jp

LLMはOpenAIのChatGPTが最も有名ですが、最近はオープンソースでモデルを開発する流れも活発になっています。特に、英語で学習したオープンソースモデルはMeta社のリリースしたLlamaを始めとして非常に強力なものがリリースされています。オープンソースモデルは性能的にはOpenAIのモデルにまだまだ及ばないものの、データをセキュアに扱えたり、個人のPCでも動いてAPI利用料がかからないなど、ビジネス面からは非常に魅力的な存在です。

さて、英語でのオープンソースLLMは活発に開発されている一方で、日本語LLMはなかなか出揃っていないというのが記事執筆時点での状況です。純粋な日本語コーパスで学習されたモデルはABEJA社からリリースされた2.7Bのモデルが最大でした1。また、学習コーパスもオープンソースの多言語データセットの日本語サブセットを抜き出したもので学習したものが多く、性能的には英語と比べるとまだまだという状況です2。

huggingface.co

ところが、今週になってCyberAgent社から純粋な日本語コーパスで学習した最大のパラメータサイズを持つLLMモデルがサプライズ的に発表されました。また、ほぼ時を同じくして日本語LLMに取り組んでいたrinna社からも3.6BというCyberAgentモデルを除けば最大級の日本語LLMを発表しており、日本語モデルのオープンソース化が加速していてデベロッパー目線では嬉しい限りです。

こんな背景を受けて本ブログ記事では今回CyberAgent社から公開された最大の日本語LLMである open-calm-7b のLoRA finetuneを試してみました。今までの日本語モデルからは考えられないほど回答の質が良いので是非結果を見ていただきたいと思います。

モデル情報

今回リリースされたモデルの情報はhuggingfaceの各ページからアクセスできます。モデルサイズはsmall〜7Bまで6種類のモデルがリリースされています。

huggingface.co

今回公開されたモデルはtokenizerも日本語で学習されているため、日本語の埋め込み効率が非常に良くなっている点が特筆すべき点だと思います。これによって同じ文章の長さであっても、（今回リリースされたモデルとアーキテクチャが同じ）GPT-NeoXと比べてトークン数が少なく、長いコンテキストの入出力を扱うことができます。なお、コンテキスト長はGPT-NeoXと同様の2048です。

github.com

検証条件

学習データには kunishou/databricks-dolly-15k-ja を使いました。こちらは商用利用可能なオープンソースのinstructionデータセットであるdollyをdeeplを使って日本語に翻訳したものです。instructionデータセットとは何らかのリクエストとそれに対する望ましいレスポンスをペアにしたもので、このようなデータで学習するとモデルの出力を望ましい方向に誘導できます。

huggingface.co

学習の際にはparameter efficient finetune手法であるLoRAを使いました。コードはalpaca-loraをベースに弊社でリファクタしたもの（ハイパラを触りやすくした程度の改変です）を使いました。モデルがGPT-NeoXベースであるため、LoRAのターゲットは query_key_value です。

github.com

その他学習のパラメータは以下のような感じでした。

dict(
  batch_size=128,
  micro_batch_size=2,  # gradient_accumulation_steps=64
  num_epochs=3,
  learning_rate=3e-4,
  lora_r=8,
  lora_alpha=16,
  lora_dropout=5e-2,
  lora_target_modules=['query_key_value'],
  train_on_inputs=True,
  add_eos_tokens=True,
  warmup_steps=100,
)

生成パラメータは以下のものを使いました。

dict(
  temperature=0.7,
  top_p=0.75,
  top_k=40,
  max_tokens=128,
  repetition_renalty=5.0,
)

なお、学習にはRTX3090を使いました。DeepSpeedは使っていません。

検証結果

実際の入力プロンプトはalpacaスタイルに変換して与えています。LLMの出力は原文ママです。

回答サンプル

人工知能って何？

AIは、人間の知的能力をコンピュータ上で実現する技術である。具体的には、人間の使う自然言語を理解したり、論理的な推論を行ったり、経験から学習したりするコンピュータプログラムを開発することを指す。近年の技術進歩により、音声認識や画像認識の精度は大幅に向上した。また、機械による自動翻訳の精度も向上しており、近い将来、通訳がいらない時代が来ると予想されている。<|endoftext|>

何だか普通に人に聞いたみたいな答えが返ってきました。テキストの終わり位置も完璧です。（<|endoftext|> はテキストの終わりを示すマーカーです。）ChatGPTに慣れてると「まあそんなもんかな」と思うかもしれないですが、オープンソースの日本語モデルとしてこの性能は驚異的なんです。本当に。

自然言語処理とはどのようなものですか？

「自然言語処理」は、人間が日常的に使っている自然言語をコンピュータに処理させる一連の技術の総称である。具体的には、文章や話し言葉を機械的に解析する形態素解析、構文解析、意味解析、文脈解析、固有表現抽出といった技術を指す。近年、人工知能(Artificial Intelligence:AI)の一分野として、注目が高まっている。<|endoftext|>

（感動）

広島の世界遺産を教えて

世界遺産に登録されているのは、厳島神社と原爆ドームの2つです。厳島神社は宮島で、原爆ドームは広島平和記念公園にあります。<|endoftext|>

今開催G7サミットがされている広島について聞いてみました。なお、どちらの情報も合っています。ちなみに筆者は厳島神社の所在地を知りませんでした。

日本で一番高い山は？

富士山(ふじさん、Mount Fuji)は、静岡県と山梨県に跨る活火山である。標高3776.24m、日本最高峰(剣ヶ峰)[注釈 1]の独立峰で、その優美な風貌は日本国外でも日本の象徴として広く知られている。数多くの芸術作品の題材とされ芸術面で大きな影響を与えただけではなく、気候や地層など地質学的にも大きな影響を与えている。懸垂曲線の山容を有した玄武岩質成層火山で構成され、その山体は駿河湾の海岸まで及ぶ。数百万年前から火山活動を営んでおり、山頂部には高温火砕物によって形成された竪琴状の堆

出力が長かったので今回は指定したトークン数で終わりませんでした。すごい、完璧な情報だ……なんかwikipediaにありそうな文章だな……と思ってwikipediaを見たら完全に同じでした。こんなに完全に記憶しているものなんですね。（商用利用可能モデルですが、著作権侵害のリスクもありそうですね。）

参考 ja.wikipedia.org

りんご1個が100円のとき、りんご4個を買うといくらになりますか？

100×4=400円です。<|endoftext|>

言語モデルには苦手とされる計算問題も簡単なものなら解けるみたいです。感動ものです。

現時点での限界

  • 今回学習したパターンではopen QA以外のタスク（追加のコンテキストを必要とするタスク）の性能が微妙でした。うまく学習できている方もいるのでハイパラチューニングなどが必要なのかもしれないです
<user>: ACESのビジョンはなんですか？
<context>: ACESは、「アルゴリズムで社会はもっとシンプルになる」というビジョンのもと2017年に立ち上がった東京大学松尾研発のAIスタートアップです。Deep Learningを用いて属人化しているヒトの知見を数式化し、幅広い業界のAI事業の開発を推進しています。
<cyber LLM>: この課題では、以下の2つの問いに答えることが求められています。

 1. ACESは何を実現しようとしているのか。

 2. ACESの技術的な特徴は何か。<|endoftext|>
  • repetition_penalty をデフォルトの値（1.0）にすると結構出力が繰り返される現象が見られました
  • 学習時のハイパラにセンシティブかもしれないです
    • 結局alpaca-loraのデフォルトが一番いい感じになりました
    • あるトライアルでは失敗してあんまりいい感じの出力が出なかったです

まとめ

本ブログ記事ではCyberAgent社がリリースした open-calm-7b モデルのfinetuneを行いました。今までリリースされた日本語モデルと比べてダントツに回答のクオリティが高くて感動するレベルです。特に、コンテキストを利用しないで回答させた場合のクオリティはかなり信頼できるものが出てくると感じました。

自分の学習の設定に問題があるのかもしれないですが、コンテキストを利用した回答生成はあまりうまくいかなかったのでこの辺りはfuture workにしようと思います。

CyberAgentさんが今回のモデルをリリースしたことで日本語LLMのオープン化の流れが一段と加速したように思います。デベロッパーとしてはうれしい限りです。今後もこの流れが続くと日本語LLM界隈が盛り上がっていいなと思っています。

弊社ではLLM技術を始めとして自然言語を扱えるエンジニアを募集しています。ご興味ある方は以下のリンクから是非ご応募ください。

www.wantedly.com

www.wantedly.com

  1. 英語で事前学習したのちに日本語でfinetuneした7BモデルはNovelAI社からリリースされています。こちらのモデルは学習コーパスがなろう小説を含んでいて、なかなかラノベチックな文章を生成してくれます。↩
  2. 英語で学習されたモデルを日本語でfinetuneするという方法もあるのですが、日本語での知識がどうしても不足していて、不自然な文章が生成されたり、問いかけに対して頓珍漢な回答をしたり、文章が繰り返してしまうなどの現象が起きることが多いです。また、英語で学習したモデルは日本語のトークン効率が悪く、英語と同じ内容を持つ文章であっても、英語と比べてトークン数が増えやすい（＝計算コストの増加、出力トークン数の減少）傾向があり、長い文章を扱いづらいなどの問題もあります。（これは厳密にはLLMの問題というよりtokenizerの問題ですが。）↩

ChatGPT API を活用したAIまとめ機能リリースの裏側

ACES Meet 大規模モデル

こんにちは、株式会社 ACES でサーバーサイドエンジニアをしている福澤 (@fuku_tech) です。

ACES は、オンライン会議を録画し、独自 AI による話者ごとの自動文字起こしや重要なシーンの可視化を行うことで、オンライン商談における成約率の向上と現場の工数削減に寄与する商談解析 AI ツール「ACES Meet」を提供しています。

今回は、先日プレスリリースが公開された ACES Meet の新機能である ChatGPT API を活用した AI まとめ機能の裏側についてご紹介します。

prtimes.jp

はじめに

近年、 AI 技術の発展に伴い、大規模言語モデルが実用的なアプリケーションで広く利用されるようになりました。 特に、 GPT シリーズのような革新的なモデルは、自然言語処理のさまざまなタスクで優れた性能を発揮し、多くの企業や研究者がその活用方法を模索しています。 これらの技術の進歩は、ビジネスプロセスの効率化や新たなサービスの創出に寄与していくことが期待されています。

そのような中弊社では、このような大規模言語モデルの力を活かすため、自社の商談解析 AI ツールである「ACES Meet」に大規模言語モデルを活用した AI まとめ機能をリリースしました。

本記事では、具体的なプロンプトの内容については割愛し、 ChatGPT API の性能を最大限に活かすための工夫や、 AI まとめ機能がどのような検証プロセスを経てリリースされたのかという点に焦点を当てて解説していきます。

AI まとめ機能を実現するための課題

AI まとめ機能を実現するにあたって、以下のような課題をクリアしていく必要がありました。

  1. 入力データの精度改善
  2. 長時間の会議・商談への対応
  3. 商談と商談以外の会議の性質の違いの考慮
  4. 適切なプロンプトの模索

以下ではそれぞれの課題に対してどのように取り組んだかについて説明していきます。

2-1. 入力データの精度改善

そもそもの大前提として、 ChatGPT API に渡す元々の入力データの精度が良くなければ、 ChatGPT API の真価を発揮できません。

この点については、元々、 ACES の独自アルゴリズムによる話者分割および文字起こしの精度が高い (※1) ことが分かっていたため、この前提条件は最初からクリアできていました。そのため、この部分は実際にはボトルネックにはなりませんでした。

詳細は後述しますが、入力データの精度が高いという前提条件をクリアしていることで、商談では特に誰の発言を中心に要約すべきかという情報をプロンプトに組み込むことができ、それが ACES Meet の AI まとめの精度向上に繋がっています。

(※1) https://prtimes.jp/main/html/rd/p/000000042.000044470.html

2-2. 長時間の会議・商談への対応

ChatGPT API はトークン長の制限があるため、長文を渡して要約をしてもらう場合は何かしらの工夫を施す必要があります。なお、トークン長は API 利用コストにも関係してくるため、金銭的な問題も発生してきます。

例えば、1時間の商談はおおよそ2万文字程度の文字数があるため、何らかの方法で文字数を圧縮しなければ、エラーになってしまうか、出力文が途中で途切れてしまいます。

そこで、長時間の会議・商談の要約を可能にするために、以下の2つのパターンをベースに AI アルゴリズムパイプラインの検証・構築に取り組みました。

案1: 社内アルゴリズムと ChatGPT API を併用する

1つ目の案は、 ACES の独自アルゴリズムである重要シーン抽出アルゴリズムを使用してまとめるべき発話を原文で抽出した後、 ChatGPT API に要約だけを依頼するようなパイプライン設計でした。

これにより、 ChatGPT API へのリクエストを最小限に抑えることができ、コストが安くなるというメリットもあります。

ただし、重要箇所を除き文章を全てカットしてしまうというロジックの都合上、意味のある要約を生成するために十分な情報が残らないことがあるという課題がありました。

社内アルゴリズムと ChatGPT API を併用する要約パイプライン
社内アルゴリズムと ChatGPT API を併用する要約パイプライン

案2: ChatGPT API をフル活用する

案1の検討中にタイミングよくOpenAI の API 提供が開始され、コストが約 1/10 になったことで、コスト面でも ChatGPT API だけで全ての処理を行うという案が現実味を帯びてきました。

具体的に考えたこととしては、発話データを一定間隔 (約3,000字ごと) で区切りながら各ブロックで要約し続け、出てきた複数個の要約をマージしたものに対して最終要約を行うというシンプルなものでした。

その結果、精度も上記の案よりも安定的に高いことが確認でき、かつ、 API 利用コストも許容範囲内に収まることが確認できたため、最終的にこちらの案を採用することにしました。

ChatGPT API をフル活用した要約パイプライン
ChatGPT API をフル活用した要約パイプライン

2-3. 商談と商談以外の会議の性質の違いの考慮

ACES Meet は主に商談向けのサービスですが、社内の議事録や採用シーンで利用されるお客様も多いため、商談以外の会議への配慮も必要でした。 商談に特化させすぎると、他のお客様の体験が悪くなる懸念があります。例えば、採用面談なのに商談特有の BANTC (※2) 情報の内容を一律で出してしまうと違和感を強く抱くことがあります。

そこで、事前に ChatGPT API に会議が商談かどうかを判定してもらうようにする工夫を取り入れました。なお、 ACES の独自アルゴリズムでも判定は可能とのことだったのですが、工数の関係等もあり、取り急ぎ ChatGPT API に判定をしてもらうようにしています。

これにより、商談の場合と商談以外の場合でプロンプトを分けることや、商談だと判定された時だけ商談特有の要約ポイントを組み込んだりすることが可能になりました。

ACES Meet における商談判定フロー
ACES Meet における商談判定フロー

(※2) BANTC とは、商談において重要とされる要素の頭文字をとったもので、 Budget (予算), Authority (決裁権), Needs (必要性), Timing (導入時期), Competition (競合) を意味します。一般的に、これらの要素を把握することで、商談が成功する可能性が高まると言われています。

2-4. より良い商談議事録を出力するためのプロンプト改善

ここまでの流れで、商談議事録を自動生成するための大枠の方針が決まりました。 そのため、後はチーム一丸となって、ひたすらプロンプトの最適化を進めていきました。

まず最初に、プロンプトの改善を効率的に実施するために、アルゴリズムエンジニアに上記のアルゴリズムパイプラインを動かせるデモ環境を構築してもらいました。 その結果、ビジネスチームを含む誰でも、そのデモ環境を使って思い付いたプロンプトを簡単に試し打ちすることができるようになったのと、複数人で並列かつ高速にプロンプトの改善を進めることが可能となりました。

その後、以下の項目について検証を進めていきました。

検証1: プロンプトの Tips を愚直に検証

社内のアルゴリズムエンジニアから、プロンプトエンジニアリングをするにあたってこれだけは読んでおいて！と言われた以下の資料を読み漁り、 step by step や few shot prompting 等の有名所は一通り試してみました。

なお、 ACES Meet の AI まとめにおいては、それらのテクニックを駆使しても劇的な効果が見られなかった (後述しますが、そもそも良いまとめとは何か？を言語化してプロンプトに落とし込むという作業の方が効果が高かった) ため、現状は深津式プロンプト・システムをベースとしたシンプルなプロンプトに落ち着いています。

検証2: プロンプトの分割単位の検証

AI まとめの 1st リリース時点では、「まとめ」「ネクストアクション」および、商談の場合のみ「商談ヒアリング項目 (BANTC)」の大項目を出すことを目指しました。 この時、選択肢としては一つのプロンプトで全ての大項目を出力させるか、大項目毎にプロンプトを分割するかの二択を考えていました。

後述のプロンプト改善項目を進めていく中で、プロンプトについても単一責任の原則のような考え方で、一つのプロンプトに対して一つのことに集中させた方が ChatGPT API は制約条件を聞いてくれやすく、安定した出力が得られる傾向が見られたため、最終的には後者を選択しました。

検証3: ChatGPT API への文字起こしデータの渡し方の検証

商談の特徴として、必ずその場に買い手と売り手が存在していることが挙げられます。 そこで、ただ単に文字起こしの内容だけを ChatGPT API に渡すのではなく、話者名もセットで渡し、更に誰が売り手で誰が買い手かという情報を与えることで、 ChatGPT API に買い手側の発言が重要度が高く、買い手側の発言を中心に要約してもらうようなプロンプトを用意しました。

その結果、 ChatGPT API に商談における重要ポイントを適切に伝えることができるようになり、意味のある要約が出力されやすくなりました。 これは、上述した文字起こしと話者分割の精度の高さがないと実現が難しいことであり、 ACES Meet における1つの強みだと考えています。 (それらの精度が低いと、 ChatGPT に間違った前提情報を与えてしまい逆効果になることが予想されます。)

また、全ての会話文を渡すべきか、前半部分はノイズが多いものと仮定して一律カットすべきかも併せて検証しました。

結果として、「まとめ」と「商談ヒアリング項目（BANTC）」については全ての会話文を渡した方が意味のある要約が出力される傾向があることが分かり、「ネクストアクション」については、商談の前半を思い切ってカットすることで、ネクストアクションとして違和感のある項目が減少する傾向が掴めたため、 ChatGPT API に渡す前にあえてデータをカットして渡すようにする工夫を入れています。

検証4: 出力形式の検証

ソフトウェア上で ChatGPT API からの出力結果をハンドリングしやすくするために、どの出力形式がベストかについての検証も行いました。

まずは JSON フォーマットでの出力を検証しました。 JSON での出力におけるメリットは文字列をパースできれば、その後の処理が容易に操作可能であることです。 一方、デメリットとしては以下のようにフォーマットが指定通り出てくれなかった場合や、トークン長の問題で出力が途中で切れてしまった場合のエラーハンドリングが煩雑なことが挙げられます。

配列を期待しているが配列になっていない例

{
  "summaries": "str"
}

フォーマットは正しいが不要なまとめ文章が最後に付記されている例

{
  "summaries": ["str"]
}
この商談では、xxxについて話し合われていました。

出力が途中で切れてしまった例

{
  "summaries": ["too long str...

JSON の場合は、上記のようなイレギュラーな出力がどうしても一定確率 (体感で数%程度) で発生してしまうことで、 AI まとめが出力できないという問題がユーザー体験を悪化させてしまう懸念が強く残ったため、次に箇条書きでの出力も検討しました。

箇条書きで出力する場合は、出力結果を自前のロジックで後処理していく必要はあるものの、箇条書き形式になっていないイレギュラーなパターンの場合は一律で無視するなど、柔軟に調整がしやすいというメリットがあります。 例えば、出力結果が以下のような文字列だった時は、正しく箇条書きになっているもののみを残すようなことをルールベースで実装すれば、簡単にノイズを削除することができます。

- まとめ
\t- インデント付きの箇条書き
箇条書きになっていない項目

それぞれのメリット・デメリットを踏まえた上で、 今回は AI まとめが出力できないことによるユーザー体験の悪化を防ぐことが最重要だと考え、箇条書きを採用することにしました。

検証5: 良いまとめとは何か？を言語化してプロンプトに反映

ここまでで、様々な説明をしてきましたが、私の体感として、結局、「良いまとめとは何か？」についてヒアリングし、仮説を立て、言語化し、プロンプトに反映させるという地道な作業の繰り返しが、意味のある要約になるかを分けるポイントだったと感じています。

上述のプロンプト改善と並行して、ビジネスチームに「良いまとめとは何か？」についてのヒアリングを行った結果、特に重要な部分が明確になりました。

一例として、以下の点が挙げられます。

  1. 箇条書きの個数や文字数については、適切な範囲を越えないことが極めて重要
  2. ネクストアクションに関しては、担当者とセットで出力すべき
  3. 商談においては、売り手側の発言よりも買い手側の発言の方が重要度が高い (実際に、営業マンが商談議事録を作成する際は、お客様の発言を中心に記載している)。

これらの重要項目を可能な限り外さないような制約条件をプロンプトに組み込むことで、より満足度の高い「まとめ」「ネクストアクション」「商談ヒアリング項目 (BANTC)」を出力できるようになりました。

なお、これらの外すべきでないポイントをプロンプトだけで何とかしようとするのではなく、 ChatGPT API の苦手な部分 (※3) をアプリケーション側でもルールベースで補完していくような設計もユーザー体験をより良いものにしていく上で重要だと考えています。

(※3) 例えば、 体感として、ChatGPT API は個数や文字数に対する制約に対してはあまり言うことを聞いてくれない時が多いです。

AI まとめ機能リリース後の反響

開発当初からアルゴリズムチームおよびビジネスチームの方々と密に連携し、多くの意見や提案をもらいながら、約3週間という短い開発期間の中、何周も何周も上記の項目についてPDCAサイクルを回すことができました。

これは、今回の開発に携わった全員が、ただ単に ChatGPT API を利用するのではなく、意味のあるもの・実際に使いたいと思ってもらえるものをお客様に提供したいという情熱を持っていたからこそできたことだと感じています。

上記のような流れで作り上げられた AI まとめ機能ですが、リリース後に社内外問わず沢山の方々から以下のような反響をいただくことができたのでいくつかご紹介します。

■ 社外のお客様からの反響

ACES Meet AI まとめ機能の反響 - 1

ACES Meet AI まとめ機能の反響 - 2

ACES Meet AI まとめ機能の反響 - 3

■ 社内ユーザーからの反響

ACES Meet AI まとめ機能の反響 - 4

ACES Meet AI まとめ機能の反響 - 5

ACES Meet AI まとめ機能の反響 - 6

以上のように、リリース後に沢山の反響をいただくことができました。一方、まだまだブラッシュアップすべき部分は沢山残っているため、今後もさらなる改善と機能追加に努めてまいります。

まとめ

本記事では、商談解析 AI ツール「ACES Meet」における ChatGPT API 活用についてご紹介しました。

1st リリース後も、沢山の喜びの声をいただいている機能ですが、改善の余地が多く残っています。 そのため、今後も継続して改善を行い、営業マンのより効率的な議事録作成や、商談時の生産性・パフォーマンスの向上に役立てられるように努めてまいります。

これを実現するために、現在、ソフトウェアエンジニアをはじめ、NLPのアルゴリズムエンジニアなど幅広く募集しています。弊社の取り組みにご興味をお持ちいただける場合は、下記の募集ページから是非ご応募ください！

Serverside Engineer open.talentio.com

Front-end Engineer open.talentio.com

Algorithm Engineer（自然言語処理・音声認識） open.talentio.com

大規模言語モデルの知識を補完するための Retriever の紹介

こんにちは、株式会社ACESでインターンをしている篠田 (@shino__c) と申します。普段は博士課程の学生としてNLPの研究をしています。

ここ数ヶ月で ChatGPT に加えて GPT-4 等の大規模言語モデル (LLM) が次々とリリースされていますね。 ChatGPT (gpt-3.5-turbo) はAPIの使用料が安いことから、多くの人が気軽にLLMを使用できるようになり、AI、特にNLPを売りにしている多くの企業は技術的にどうやって競争優位性を築けばいいのか模索しているのではないでしょうか。 その問いに対する１つの答えになりそうなものに、Retriever というものがあります。

例えば、社内にある外部には出せない文書を元に顧客からの質問に答える質問応答のサービスを作りたい場合、ChatGPT のような LLM の訓練にはそのようなデータは使われていないため、prompt として社内にある文書を LLM に与えて質問に答えさせることが必要になります。 （prompt = LLMに与える入力の文字列のこと） 一方で、LLM に与えられる prompt の長さには上限があり、社内にある文書の量が膨大であった場合はそれらを全て prompt に含めることはできません。

そこで、質問に関連する一部の文書だけを検索してきて prompt に追加することが１つの解決策になります。 このように言語モデルの知識を補完するために関連する文書を外部の文書集合から検索してきて言語モデルに入力として与えるような技術を、Retrieval-augmented Language Model (LM) と言います。（新しい Bing AI チャットは Web からの検索で知識を補うようなことをしていますね。参照1,2）

Open AI からも検索に使える embedding という API が公開されており、手軽に検索機能を実装するにはそれで十分かもしれません。（参照）しかし、その API は有料であることに加えて、embedding の訓練に使われたデータとは異なるような特殊なドメインの文書が検索対象で、一般的にメジャーではない語彙が多い場合には Open AI の embedding では検索の精度が劣化してしまう可能性もあります。 公式の Documentation でも、embedding は2020年8月までのデータを用いて訓練されたため、それ以降に起きたイベントについての知識には弱いことが欠点として挙げられています。（参照） 例えば、ACESが提供する "ACES Meet" は "AIがオンライン商談の録画・書き起こしを行い、商談の内容や温度感を共有・解析できる営業支援AIツール"（参照）なのですが、実際に OpenAI の embedding (text-embedding-ada-002)で計算したcos類似度は以下のようでした。

t1 = "AIがオンライン商談の録画・書き起こしを行い、商談の内容や温度感を共有・解析できる営業支援AIツール"
t2 = "ACES Meet"
t3 = "営業支援のためのAIツールで、オンライン商談の録画と書き起こしを行い、商談内容や感情表現を共有し、分析することができます"    # ChatGPT が生成した t1 のパラフレーズ
t4 = "りんご"    # t1とは全く関係のないテキスト

cos(t1, t2) = 0.7234
cos(t1, t3) = 0.9655
cos(t1, t4) = 0.7780

cos類似度 (-1 以上 1 以下) が高いほど似ていると判断されるのですが、この結果によると OpenAI の embedding では、t1 と t3 は似ていると判断された一方で、t1とt2は、t1とt4よりも似ていないと判断されています。

そのため、特定のドメインの文書に特化した検索器 (= Retriever) を独自に訓練することで、その文書を有効に使えるようになり、競合他社との差別化になりうるのではないでしょうか。 直近でも、今年の3月23日に ChatGPT の機能を拡張できる Plugin というものが Open AI から発表されました。（参照） Plugin の１つとして、クエリと関連する文書を独自の文書集合から検索できる ChatGPT Retrieval Plugin （参照）がリリースされており、Githubレポジトリのスターが1万を超えるなど注目が集まっています。 OpenAI の co-founder の Greg Brockman 氏も近い未来に LLM と Retrieval の組み合わせがおそらく主流になるだろうと述べています。（参照） そこでこの記事では検索のために使われる Retriever に関する研究をその訓練方法に着目して少し古いものから最近ものまで代表的と思われるものを紹介しようと思います。 もしも独自の Retriever を訓練する必要がある場合には参考になれば幸いです。 （これまでに多くの論文が発表されており全ては紹介し切れないため、なるべく幅広い訓練方法を紹介するように心がけました。他にも関連する面白い文献や、さらに説明中の言葉遣いや解釈が誤っている箇所がありましたら、こっそり教えていただけると幸いです。）

Retrieval-augmented LMとは

LM (language model) は自然言語という形での知識は完全に持っていません。 一般に外部の知識源を与えることで、LMが事実ではないことや古くなった情報を生成するのを防いだり、同等の性能を出すために必要なパラメータ数を削減することができます。 Retrieval-augmented LM はそのような手法の一種で、近年も盛んに研究が行われています。 適用可能なタスクは言語生成やOpen-domain QA（下図）、言語モデルの事前学習など多岐にわたります。

Retrieval-augmented LMが有効なOpen-domain QAタスクの例。もしLMがバラク・オバマの誕生日を知らなくても、Wikipediaから関連する文章を検索して知識を補完することで正しく答えることができます。（出典：http://arxiv.org/abs/2101.00774）

Retriever としてはクエリや文書中の各単語の出現頻度を使って類似度を計算するTF-IDFやBM25のようなニューラルネットを使わないスパースな手法が古くから使われてきました。（参照） しかし、ORQA（参照)という手法がニューラルネットを用いてBM25を検索精度で上回るようになってから、ニューラル Retriever の研究が加速したように思われます。 そのため以下では基本的にニューラルネットを用いた Retriever について紹介します。

Open-domain QA における Retriever の使い方

仮に今、Retrieverとしてモデル f が得られているとして、質問 q に対する回答を出力したい場面を想定します。 また、知識源としての文書の集合が D = {d_1, d_2, ..., d_n} で与えられるとします。 実際に Retriever を使うときは、まず

\displaystyle e_q = f(q), e_q ∈ R^m \\ e_d = f(d), e_d ∈ R^m

のように クエリと各文書をそれぞれ f に与えて m 次元のベクトル e を得ます。 （ここで、q と d のエンコードには違うモデルを使う場合も同じモデルを使う場合もあります） その後、クエリのベクトルと各文書のベクトル同士のcos類似度を計算し、cos類似度が大きいものから上位 k 個の文書を検索結果として得ることができます。 その後、それらの文書と質問を入力として、Reader g に回答を予測させます。 この時回答は文書からフレーズとして抜き出すか、0から生成する場合があります。 このように Retriever を使うことで、検索対象の文書集合から質問に関連する文書だけを検索してきて、Reader に与えることで回答を出力することができます。 前提を抑えたところで、次に今までに提案されてきた Retriever の訓練方法を紹介します。

Retrieverの訓練方法

まず質問に対する回答が含まれるような正例の文書がラベルとして与えられている場合に使える教師あり学習の手法を紹介します。 次に、そのようなラベルがなくても学習が可能な教師なし学習についても紹介します。 最後にパラメータを更新しづらいようなLLMと一緒に使う場合の効果的なRetrieverの使用・訓練方法についての最近の研究を紹介します。 教師あり学習をする前に、教師なし学習によって得られた重みで Retriever を初期化することでさらに精度が向上することが報告されているため、色々な訓練方法を知っておくことが重要そうです。

教師あり学習

Dense Passage Retrieval for Open-Domain Question Answering (Karpukhin+ EMNLP2020)

論文URL

通称 DPR と呼ばれ、元祖ニューラル Retriever という感じです。 質問用のエンコーダと文章用のエンコーダを別々に用意します。 どちらもBERTを使い、[CLS]のembeddingの類似度を検索に使います。 質問と回答のペアは数千〜数万のオーダーで必要です。 Retrieverの訓練には質問に対して positive pasage と negative passage を用意する必要があります。 positive passageがデータセットで提供されていない場合は、単語の出現頻度に基づくニューラルではない検索手法の BM25 で似ていると判断された文書のうち回答を含むものを positive passage として利用しています。

we use the highest-ranked passage from BM25 that contains the answer as the positive passage

BM25と比べて、top-20の検索精度で9-19%の向上が可能です。 Retriever 単体の検索精度は以下の表の通り（DPR が劣る場合もあり）

Retriever の研究はこの論文を引用しているものを探せば良さそうです。

教師なし学習

Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (Lewis+ NeurIPS2020)

論文URL

手法名は Retrieval-Augmented Generation (RAG) です。 先程のDPRとは異なり、Retrieverに対するラベルを用意する必要がない教師なし学習を提案しています。 大量の検索対象から関連する文書をラベルとしてアノテーションするのは大変そうですし、BM25で擬似的にラベルを作るのも限界がありそうですよね。

RAG では、検索されてきた関連する文書を潜在変数 z とみなして、クエリ x とラベルyのペアのデータのみで end-to-end に学習しています。つまり、Retriever のラベルを必要としない訓練方法を提案しています。 評価は Open-domain QA に加えて、言語生成や Fact Verification でも行っています。 DPRと同様、クエリと文書には別々のエンコーダを用意しています。 Retriever の初期化には DPR を用いています。 また Retriever を訓練している際に検索対象の文書のベクトルを更新するのはかなりの計算量ですが、これは更新せずに固定しても大して精度は変わらないことを示しています。

Unsupervised dense information retrieval with contrastive learning (Izacard+ Transactions on Machine Learning Research 2022)

論文URL

対照学習による教師なし Retriever の Contriever というモデルを提案しています。

背景として、ニューラル Retriever は訓練データとは異なるドメインのテストセットではあまり性能がよくなく、かえってBM25などのスパースな手法がニューラル Retriever を上回ることがあリました。 例えば上図に示されるように、Trec-COVID という COVID-19 に関する文書からなるテストセットでの検索精度は、BM25の方が他のニューラル Retriever よりも高いです。 この原因について、ニューラル Retriever の訓練には COVID-19 に関する文書が含まれないからだろうと著者は推測しています。 一方、ここで提案されている Contriever は訓練セットがない BEIR ベンチマークで多くの場合BM25を上回っています。 さらにContrieverを初期化に用いて fine-tune することでドメインに特化した Retriever を得ることもできますし、英語データから低リソース言語にも転移できます。

Contriever ではクエリと文書のエンコードには同じモデルを用いています。 DPR は違うモデルを使ってエンコードしていましたが、同じモデルを使った方が新しいドメインに対して頑健であることを示しています。 ベクトルは最終層のmean poolingで得ています。 通常の対照学習と同様に、ここでも1つのpositive documentとK個のnegative documentを用意してクエリのベクトルとのcos類似度をpositive documentとは最大化してnegative documentとは最小化します。

数百〜数千の教師データがある設定では、fine-tuned BERT や BM25 よりも高い精度です。 このことから、Contriever は教師なしでも高い精度が得られるだけでなく、教師あり学習をする前の初期化としても有効であることがわかります。

（日本語含む）29の言語のデータで訓練したmContrieverは日本語データ (ja) に対してもある程度汎化可能です。 学習用のコードと学習済みモデルは公開されています。 mContriever を MS MARCO でfine-tuneしたモデルはこちらのレポジトリと以下のコードで簡単に使えます。

from src.contriever import Contriever

mcontriever_msmarco = Contriever.from_pretrained("facebook/mcontriever-msmarco")

LLMと一緒にRetrieverを使う

REPLUG: Retrieval-Augmented Black-Box Language Models (Shi+ 2023)

論文URL

（今までに紹介した Retriever がLLMと一緒に使えないわけではないですが） こちらはLLMを訓練せずに Retriever を効果的に使う方法を初めて提案した論文です。 ここではRetrieverに教師なしモデルを使うのも可能 (Frozen) ですが、ラベル付きデータで訓練してさらに精度を上げることも可能 (Traineble)なことを示しています。

上図の黄色の四角で示されるように、Retrieved document dをそれぞれクエリ x と concat してLLMに入力した後、出力分布を（xとdの類似度で重み付けして）アンサンブルしています。

LLMと一緒に使う場合のRetriever の訓練方法

提案手法の１つのRePlug LSRでは、LLMを使ってどの文書を検索するべきかの教師信号をRetrieverに与えて訓練することができます。 大きく以下の4つのステップからなります。

  1. retrieved documentsにretrieverが与えた確率を計算
  2. LMを使ってretrieved documents をスコア付け
  3. 1と2で得られたretrieved documentsの確率分布同士の間のKL divergenceを最小化
  4. indexの更新

1ではクエリと各文書のベクトルのcos類似度を温度付きsoftmaxにかけます 2では各文書dとクエリxが与えられたもとで正解yにLMが割り当てた確率P(y|d,x)を計算し、これが高ければ高いほどdは良い文書だと仮定します。このP(y|d,x)を各retrieved documentに対して計算した後に温度付きsoftmaxにかけたものを3で使います。 3では1と2で得られたretrieved documentの確率分布同士を近づける。この時にLMは固定でretrieverのパラメータのみ更新する。 4で Retriever の更新に伴うindexの更新はT training steps (実験では3000 step) ごとに行います。

教師なしRetriever (RePlug) にはContriever (Izacard et al., 2022b) を使用し、教師ありの方 (RePlug LSR) の初期化にも Contrieverを使用しています。 LMにはGPT-3 Curieを使用。

訓練データには、Pileというデータから得た800Kの文章を使い、各文章の最初の128 tokenを入力クエリ、後半の128 tokenを正解yとして使用しています。

言語モデル、MMLU、Open-domain QAのタスクでSOTA or パラメータ数のより多いベースラインに匹敵する精度を達成しています。

おわりに

以上紹介した Retriever の研究をまとめてみます。

  • 訓練データとは異なるドメインのテストセットでは、検索精度が BM25 > 既存のニューラルRetriever になりうる (Izacard+ Transactions on Machine Learning Research 2022, Figure 1参照)
  • Retriever はどうやって訓練する？
    • 教師あり学習：質問と文書の正解ラベルで教師あり学習 (Karpukhin+ EMNLP2020) 。正解文書はBM25と質問への回答から人工的に作成することも可能 (Karpukhin+ EMNLP2020)。
    • 質問と回答のペアから学習：正解文書を用いずに、文書を潜在変数として扱って質問と回答のペアだけから訓練することもできる (Lewis+ NeurIPS2020) 。ただし質問と回答のペアは教師データとして必要。
    • 教師なし学習：対照学習による教師なし学習は有効 (Izacard+ Transactions on Machine Learning Research 2022) で、後発の研究でもfine-tuningをする前の初期化に用いられています。
    • LLMと一緒に使いながら訓練：パラメータが固定されているLLMと一緒に使いながら Retriever を効果的に訓練する方法 (Shi+ 2023)。
  • エンコードの仕方
    • 文書とクエリに異なるエンコーダ又は同じエンコーダを用いて別々にエンコードする (= bi-encoder)。文書とクエリには同じエンコーダを用いた方が新しいドメインのデータに対して頑健。
    • 文書とクエリをくっつけて同時にエンコードする (cross-encoder)。こちらの方がかなり精度が良い模様 (Izacard+ Transactions on Machine Learning Research 2022, Table 2)。ただしクエリごとに逐一各文書とつなげてエンコードする必要があり、bi-encoderよりも計算が大変。
  • Retriever の初期化
    • BERT-base (Karpukhin+ EMNLP2020)
    • DPR (Lewis+ NeurIPS2020)
    • Contriever (Shi+ 2023)
      • などが使われる

場合によってはラベル付きデータセットを用意できる場合と難しい場合、LLMと組み合わせてさらにチューニングしたいなど多くのユースケースを想定して、なるべく広範囲の訓練方法から代表的なものを紹介してみました。 訓練方法としては、教師なし学習ではアノテーションがいらないという利点がある一方で、特定のドメインの文書での検索精度をより上げるためには教師あり学習が有効な傾向があります。コストと精度の兼ね合いで手法を選択する必要がありそうですね。 一方で LLM へ入力できる prompt の長さは長くなっており、検索対象の文書がそこまで大規模でない場合には、Retriever を介さずに全ての文書を入力として扱うこともある程度は可能になっていきそうです。

今回は Retrieval-augmented LM についての論文をいくつかご紹介しました。 ACES では今後 ChatGPT のような LLM を用いたサービスの開発に並行して、今回ご紹介した Retriever などの、LLM のための外部モジュールを積極的に開発していく予定です。 弊社の取り組みに興味を持っていただける方は、ぜひ以下のリンクからご応募いただけると幸いです。

open.talentio.com

気軽に話だけでも聞いてみたい方は、弊社の開発部署のマネージャーとカジュアル面談もできます。

meety.net

Appendix

最後に、さらに深掘りたい方のために関連する最近の論文を簡単に紹介します。

人とAIが協働するコミュニケーションの科学の取り組み

組織・文化

こんにちは、株式会社ACESの開発部責任者の久保 (@seishin55) です。

ACESは自然言語や音声、映像といった非構造データを構造化し、属人化した知見や業務をDeep Learningを中心としたAI技術で再構築しながら、人とAIが協働し、ともに進化できる未来をデザインすることに取り組んでいます。

今回は特に力を入れて取り組んでいる「コミュニケーションの科学」について紹介します。

コミュニケーションの科学

コミュニケーションの科学とは？

昨今の時勢の影響も受けながら、私達の生活様式は大きく変わり、オンライン上でのコミュニケーションも当たり前になりました。ZoomやTeams、Google Meetのような動画を介したやり取りが普及し、VRのようなバーチャル空間上でのやり取りも行われるようになりました。これまでのコミュニケーションのあり方が多様になっていること、また、デジタルを介したコミュニケーションが増え、解析・介入する余地が増えたことによって、改めてコミュニケーションのあり方を考える好機が生まれています。

コミュニケーションが発生する場面・業界は多岐に渡りますが、例えば、営業、会議、コールセンター、問診、カウンセリング、コーチング、人事などが想定されます。ACESでは、まずはコミュニケーションの解析・データ化に注力し、以下の項目に取り組んでいます。

  • 振り返りや報告業務の効率化
  • 個人のコミュニケーション (スキル・状態) の定量化・評価による振り返り
  • 定量化されたコミュニケーションデータの集積による知見・ノウハウの蓄積

これらは、これまで属人化されていた個人のスキルを解析し、「質の高いコミュニケーションは何か？」という問いにチャレンジするものです。

また、解析の延長として、人と人のコミュニケーションにAIを介在させることも行います。例えば、以下のように、よそ見を検知したAIが人の注目を集めるアクション（ここでは話す速度をあげる）を取ることで、人の行動を変容させます。

[CHI '21 Arakawa and Yakura] Mindless Attractor: A False-Positive Resistant Intervention for Drawing Attention Using Auditory Perturbation (Honorable Mention 受賞)

これに限らず、質問対応業務の中で、「自動的に回答候補を出し、人の補助を行う」など、人のコミュニケーションに介入・補助できるようにして、コミュニケーションを直接的にアップデートしていきます。

そして、将来的には、音声合成やアバターの活用などのデジタルインターフェースも介して人とAIのコミュニケーションにもチャレンジします。

コミュニケーションの科学の方位磁針「トラスト」

人とAIが協働していく未来を実現するためには、人とAIの間のトラスト（信頼関係）が大切だと考えています。AIをプロダクトやサービスに組み込む場合に、そのAIに信頼を持って使ってもらえるかを重視し、議論を行っています。例えば、AIによる書き起こしの結果にミスがあった場合のために、対応する時間の動画を参照し、情報を補完できるように工夫を行います。技術的に素晴らしいものがあったとしても、人がその使い方を理解できなかったり、非直感的な間違いが多く認知負荷が高い場合は、うまく使うことができず、効用が小さくなってしまいます。

また、人とAIが協働する中で、① データが蓄積され、AIが強くなること、② より質の高いAIのサポートを受けることで人も強くなること、③ 質の高いデータがAIにFBされること、のループを回すことによって、人とAIが共に進化することを目指します。このような、人間がシステムのループの中で相互作用を生み出すことは　Human in the loopと呼ばれており、人とAIの不得意をそれぞれが補う形で協働することをイメージしています。

営業を科学する「ACES Meet」

ACESでは、コミュニケーションの科学の取り組みの1つの役割・インターフェースとして、ACES Meetというプロダクトを開発しています。ACES Meetは、AIがオンライン商談の録画・書き起こしを行い、商談の内容や温度感を共有・解析できる営業支援AIツールです。

meet.acesinc.co.jp

ACES Meetは以下の画像のように、オンライン商談を分析します。動画から書き起こし、会議のトピックの分析 (何を話しているのか) 、重要なシーンの抽出、コミュニケーションスキルの定量化 (例: 話速)などの解析を現在は行っています。

また、これに限らず様々な技術トピックで研究・開発が行われており、最近、その一部である笑顔・視線の分析のリリースが出されましたし、要約技術について特許の出願も行っているところです。

prtimes.jp

現在の取り組みテーマ

対話要約・Q&A (自然言語)

コミュニケーションは言語を介して行われるため、自然言語による解析は重要です。現在はまず、商談/会議における議事まとめ業務をAIでサポートするための研究・開発を行っています。前述したように、既に特許出願を行っている要約技術もありますが、一言で要約といっても様々な形があります。商談/会議の実施者が議事にまとめる作業において、どのようなステップがあり、どのようなAIが重要かを考えながら、研究・開発を行っています。

ニュースのような整ったテキストではなく、口語表現が混じった対話のやり取りであったり、会話データのために重要な情報がスパースになっていたりと対話文章であることの特有な難しさがあり、チャレンジングな領域になっています。また、生成される文章は単にそれっぽい文章であればよいわけではありません。例えば、要約の中で誰の発言かを間違ってしまうことは大きなミスで、ユーザーの信頼を失ってしまいます。そうならないために、適切なアプローチ・ステップを考える必要があります。

また、対話文章ではQ&A(質問と答え)は重要な要素です。例えば、Q&Aを対話文章から抽出する要素技術がありますが、Q&Aの抽出は上記の要約にも寄与しますし、Q&Aの集積はノウハウ蓄積にも繋がります。また、蓄積されたQ&Aのペアのデータを元にAIが介入することで、新規のメンバーであっても既存のQ&A (例えば、答えの候補)をリアルタイムで確認できることに使うこともできます。

近年では、特に自然言語はTransformer及びBERT、GPT-3などの発展、特に大規模モデル化の恩恵を受けて、実現可能な範囲・水準が上がっています。そうした最先端の研究領域の知見の恩恵も受けながら、まずは「解析」を行いつつ、開発内容を拡張していきます。

書き起こし (音声認識)

発話を伴うコミュニケーションを解析するためには音声認識を行い、書き起こしを行う必要があります。書き起こしの機能はプロダクトとして運用しているACES Meetに搭載・運用されているため、その中でユーザーからのフィードバックも受けながら書き起こしのモデルの開発・改善を繰り返し、精度を向上させています。また、データの蓄積とアノテーションの仕組み化も行っており、継続的に学習できる仕組みが整っています。

音声認識は最近ではOpenAIから公開された大規模言語モデルのWhisperが注目されるなど、音声認識の分野にも大規模モデル化の波が来ています。現状ACESで開発・運用されている音声認識モデルは独自の学習データで学習していることから、対象とするオンライン会議ドメインにおいて、定量的・定性的にWhisperの精度を上回っていますが、大規模モデルの影響は大きいと考え、その恩恵を取り入れるための開発も行っています。また、固有名詞や専門用語の書き起こしを可能にし、精度の向上を行うための取り組みも短期・長期それぞれの施策に取り組んでいます。

今後としては、同一音源の複数人の話者分割やリアルタイムの音声認識の開発なども含めて、開発が検討されています。

分析指標・重要シーン抽出 (マルチモーダル)

コミュニケーションの解析にあたって、スキルを分析指標として、定量化・可視化することにも取り組んでいます。個人のスキルを定量的に把握・認識し、また、他者との比較によって、自分の得意・不得意を認識できるようになることによって、これまではブラックボックスで難しかったコミュニケーションスキルの改善に生かすことが可能になります。分析指標としては、非言語 (映像解析)、準言語 (話す際の声の強弱などの語調など)、言語 (発話内容)に分けて開発を行っています。前述したように、自然言語処理や音声認識の開発を注力していることと、別領域の開発によって映像解析も弊社の得意な技術領域であることから様々な指標が開発されています。指標の例を挙げると、弊社プロダクトであるACES Meetでは既に以下のように笑顔の指標と視線の指標が表示されます。

prtimes.jp

現在ACES Meetに搭載されているアルゴリズムは内部で開発されているもののうち一部のみで、今後も内容の拡充が行われる予定です。内部的には他社との取り組みを含めて、様々な研究・開発が行われているところです。例えば、人材アセスメント支援業務におけるプロジェクトとして以下のような研究を行い、CHI 2022のワークショップである Trust and Reliance in Human-AI Teaming に採択されています。

arxiv.org

acesinc.co.jp

また、取得される各種定量情報の時系列的な情報から特徴的なシーン (大きく変化したタイミング)を推定する技術も保有しています（弊社特許技術）。以下の例は映像データの例ですが、同技術では音声・自然言語も含めた様々なモーダルから得られる指標を使って推定を行うことが可能で、活用が進んでいます。

acesinc.co.jp

さらに、現在は上記のマルチモーダルな指標を使って観察したいシーンを汎用的に取得できる技術の研究・開発を行っているところです。どの指標が改善対象として重要であるかの分析も重要で合わせて進めています。

おわりに

今回はACESが現在特に力を入れている「コミュニケーションの科学」の取り組みについて紹介しました。現在は対面の商談/会議等を解析し、効率化や定量化・評価による振り返り、ノウハウ蓄積を行ってますが、冒頭でも触れたように、今後としては、リアルタイムにフィードバックを返したり、トーク内容をサポートしたりするように人のコミュニケーションに介入・補助して、支援できる領域を拡張したり、音声合成やアバター、対話のようなデジタルインターフェースの活用によって、AIが人と直接的に協働できるような展開にもチャンレンジしていくことを想定しています。

それを実現するために、現在、特に自然言語処理のアルゴリズムエンジニアを募集しています。弊社の取り組みに興味を持って頂ける場合は是非ご応募頂けますと幸いです。

Talentio (Tech Lead / 自然言語処理): open.talentio.com

Talentio (Algorithm Engineer / 自然言語処理): open.talentio.com

Wantedly: www.wantedly.com

Meety: meety.net

よく分からなければ私へTwitter DMでも大丈夫です！@seishin55

まずは30分のカジュアル面談からでもできればと思うので、お気軽にご応募・お声掛け下さい！