はじめに
はじめまして.東京都立大学システムデザイン研究科情報科学域修士 2 年の今藤誠一郎と申します.
大学院では,自然言語処理に関する研究をしています.私は 2021 年 9 月から,株式会社 AI Shift と都立大小町研究室の共同研究に参加しています.AI Shift では音声自動応答サービスである AI Messenger Voicebot を展開していますが,その対話の中から特定のキーフレーズ (e.g. 地名、人名、etc.) を認識するためには,発話内容からキーフレーズに対応するテキスト中の区間を推定,抽出する必要があります.今回は,発話を音声認識して得たテキストデータと公開されている対話コーパスを対象としてキーフレーズの抽出に取り組んだ内容をまとめます.
モチベーション
音声自動応答サービスでの対話を実現するにあたって,ユーザが対話の中で特定のキーフレーズを発話するケースがあります.そのような際に,ユーザの意図推定を行うために発話から該当区間を抽出することは重要な課題の一つといえます.実際のユースケースとして,例えば道路交通情報の文脈で「いちごっぱの交通情報が知りたい」のような発話がされた時には,'いちごっぱ' という部分を抽出して,それから手元の辞書内の索引と結びつけることによってそれが何を表しているのかを認識し,ユーザの意図推定へと繋げます.このように対話内の特定のキーフレーズの認識処理はテキスト中からキーフレーズを表す文字列を抽出して,辞書を用いてリンキングを行うというステップになります.本共同研究において,私はこの第一ステップとなる音声テキストからのキーフレーズ抽出に取り組みました.
音声対話テキストからキーフレーズを抽出する際には,音声認識誤りや口語表現,略称や別称などが含まれるといった点が難しい点として挙げられます.これまではこのような問題に対して,辞書を作成し,文字列のマッチングを行うことで対応してきましたが,辞書の作成にもコストがかかりますし,カバーできる範囲も限界があります.そこで,入力テキストの文脈からキーフレーズとなる部分を抽出できないかというモチベーションで BERT や T5 を用いたキーフレーズの抽出に取り組みました[^1].
しかし,多様なドメインを扱うにあたって正解データをそれぞれ作成し,事前学習モデルを個別に fine-tuning するのには作業量的な面,時間的な面,計算資源的な面からコストがかかるため大変になります.
そこで,今回はデータ数が少数の設定における事前学習モデルによるキーフレーズの抽出を検証しました.
GPT を用いた少量データにおけるキーフレーズの抽出
いくつかのタスクにおいて使用できるデータ数が少ない時に,Few shot の設定として GPT を用いることで様々な生成系のタスクをある程度解決できることが示されています.具体的には,数事例のデータをプロンプトとして用いて,続きの文を生成させるような形でモデルにタスクを解かせます.この手法の利点としては,必要なデータが少数でも扱えることに加えて,モデルの追加学習が不要であることが挙げられます.したがって,事前にドメイン別のモデルを用意しなくても良く,学習にかかるコストそのものも抑えることができます.
テキストからの抽出タスクであっても文中の抽出箇所を生成するタスクとみなすことで,GPT を適用させることができると考えられます.
実験
事前に,テキストとテキスト中の抽出すべきキーフレーズのペアが各ドメインに対して 5 セットのみ与えられている設定でキーフレーズの抽出を行います.
GPT モデル
事前学習済みモデルとして,rinna 社が公開している japanese-gpt-1b を利用しました.
今回の設定では出力に多様性を求めてはいないため,do_sample
を False として greedy に生成を行います.
プロンプト
3 通りのプロンプトで実験を行いました.(〇〇: 入力 n,△△,◇◇: 入力 n から抽出したいフレーズ)
- 事例:
文章:〇〇, タスク:[ドメイン名] を抽出せよ。, 答え:△△、◇◇...。</s>
- 事例:
「〇〇」から [ドメイン名] を抽出せよ。:△△,◇◇</s>
プロンプトをより自然な文にすることで抽出精度が高くなることを期待してこのような形で実験しました. - タスクの説明:
[ドメイン名]を抽出せよ。</s>
,事例:〇〇:△△,◇◇</s>
タスク指定を最初の一度のみ行って事例を列挙する形になります.プロンプトに冗長な情報を入れないことで抽出精度が高くなることを期待して実験を行いました.
few shot の事例は全データから 5 事例をランダムにサンプリングすることで選択しました.また,実際の運用時には入力されるテキストの中には目的となるキーフレーズが含まれないケースがあることも想定されます.プロンプトの事例の中にそのような負例となるケースが入っていないと何かしらの出力をしてしまうため,プロンプトの最後の事例としてキーフレーズのないものを追加しました.本研究ではそのような事例に対して抽出したいフレーズとして "無し" というテキストを用います.合計 6 つの事例をプロンプトとして用いました.
データ
システム主導型の対話ログ
AI Shift で運用している福井県の道路交通情報に関する対話システムのログから,実際にユーザが道路名や住所名を発話していると期待されるターンの発話になります.発話中の道路名と住所名をキーフレーズのドメインとして扱いました.運用上,辞書マッチで抽出できなかったデータに対して,音声認識誤りや福井県内での存在の有無を考慮した上でアノテーションを行ったデータを用いました.道路名と住所名のデータ数はそれぞれ 226 発話と 116 発話でした.
データの具体例として,住所名のプロンプトに用いた事例は以下になります.
入力 | 抽出したいフレーズ |
---|---|
吉田郡松岡町 | 吉田郡,松岡町 |
丸岡町長崎 | 丸岡町,長崎 |
清水ません | 清水 |
清水みません | 清水 |
渕町 | 渕町 |
もう一度言ってください | 無し |
宿泊施設探索対話コーパス
宿泊施設探索対話コーパス はMegagon Labs が公開しているデータで架空の宿予約サービスでオペレータ役とカスタマー役が日本語でチャットを行う形で集められたものになります.発話内で宿泊施設に関するリクエストに該当する区間がアノテーションされているデータ(request_span)を利用しました.本研究では,データセットである 210 の対話の中からカスタマーの発話かつ要求を行っている発話を抽出して実験に用いました.なお,音声認識結果には含まれにくいと思われる句読点,疑問符,感嘆符は削除しました.リクエストの区間はその内容に応じて 12 種類の分類分けがされていたためそれぞれをキーフレーズのドメインとして扱います.ドメインごとのデータ数は下記表の通りです.
サービス | スケジュール | 子供 | 施設 | 宿 | 食事 | 人数 | 部屋 | 風呂 | 予算 | 立地 | 旅行 |
---|---|---|---|---|---|---|---|---|---|---|---|
134 | 302 | 165 | 226 | 38 | 229 | 53 | 383 | 294 | 221 | 61 | 278 |
データの具体例として,サービスのプロンプトに用いた事例は以下になります.
入力 | 抽出したいフレーズ |
---|---|
公共交通機関を使っていく予定なのですが現地で レンタカーを借りようと思っています | 現地でレンタカーを借り |
日にちも近いので何か割引サービスなどがあれば 嬉しいです(直前割など) | 割引サービス,直前割 |
あちこち回るために自転車などの貸し出しもあれ ばありがたいです | 自転車などの貸し出し |
早めかどうか微妙ですが14時ぐらいにチェック インを希望します | 14時ぐらいにチェックイン |
ミーティングスペースがあるところを希望したい のですが | ミーティングスペース |
お盆頃に娘と2人で島根に行こうとおもってます | 無し |
評価
recall で評価を行います.
運用上でも後続タスクとして辞書を用いたリンキングを行うことを想定しており,取りこぼしのないようなキーフレーズの抽出が好ましいため recall での評価が適切であると考えました[^2] .
結果
システム主導型の対話ログ
道路名 | 住所名 | |
---|---|---|
プロンプト 1 | 0.632 | 0.636 |
プロンプト 2 | 0.479 | 0.660 |
プロンプト 3 | 0.513 | 0.624 |
宿泊施設探索対話コーパス
サービス | スケジュール | 子供 | 施設 | 宿 | 食事 | 人数 | 部屋 | 風呂 | 予算 | 立地 | 旅行 | |
---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | 0.169 | 0.042 | 0.150 | 0.508 | 0.117 | 0.332 | 0.207 | 0.361 | 0.647 | 0.044 | 0.219 | 0.369 |
2 | 0.345 | 0.600 | 0.225 | 0.623 | 0.326 | 0.344 | 0.046 | 0.365 | 0.824 | 0.137 | 0.230 | 0.388 |
3 | 0.176 | 0.150 | 0.150 | 0.426 | 0.095 | 0.192 | 0.175 | 0.069 | 0.691 | 0.016 | 0.094 | 0.354 |
考察
システム主導型の対話ログ
- 福井県のデータを用いた際の recall による評価は,道路名に関するデータのプロンプト 1 の結果が他のプロンプト例に比べて高く,住所名に関するプロンプトによる差はそこまで大きくないように見えます.誤ってしまったものの中には,抽出したい区間を誤っているものの他に,抽出してほしいのに数値を漢字表記にして出力したり,末尾の表現を変更するようなもの(街道 → 通り,"町" を付与など)が見られました.このような誤りを考慮した上でも実際の出力を見てみると,道路名,住所名共にプロンプト 1 の出力が最も期待に応えるような結果となっていました.
- 入力テキストに該当区間がなく,本来出力しなくても良いようなケースにおいて,誤った出力がどの程度含まれるのかを検証しました.後続で辞書を用いたリンキングを行うとはいえ,誤出力が少ない方が良いことには変わりないため,こちらについても福井県のデータを用いて確認しました.
- 該当キーフレーズが無く,"無し" と出力してほしいデータ(道路名:418 発話,住所名:429 発話)に対して,期待通りに "無し" と出力できたデータ数
道路名 | 住所名 | |
---|---|---|
プロンプト 1 | 24 | 12 |
プロンプト 2 | 234 | 119 |
プロンプト 3 | 131 | 105 |
この結果から本来抽出しなくてもいいようなデータに対しても何かしらの抽出を行なってしまっていることがわかります.今回用いた福井県のデータは系列長が短いものが多いことが特徴に挙げられ,入力をそのまま出力することで正解となるようなケースが多くありました.したがって few shot の事例もそのようなものが多くなっていることが原因として考えられます.特に,プロンプト 1 は発話中の何かしらを抽出すべきキーフレーズと認識して出力を行う傾向が強いことが確認されます.プロンプト 1 の出力例を確認すると "「[ドメイン名]」を抽出せよ" というタスク指定をしているにも関わらず,ドメイン内容は考えないで発話中の何かしらの表現を抽出していることがわかりました.これは言語モデルの学習時に利用されるテキストの形式と入力が異なるため,モデルが文意をつかめていないのではないかと考えられ,より自然な文に近いプロンプト 2 を採用することでこの問題がある程度軽減できるのではないかと考えています.
宿泊施設探索対話コーパス
- こちらのコーパスを利用した際のスコアは福井県のデータに比べて全体的に低くなってしまってることが確認されます.これについては大きく 2 つの原因が考えられます.
- キーフレーズを抽出することにおける,データセット自体の難しさ
- 完全一致による評価という厳しさ
以下にドメインの一つである "サービス" の出力結果の一部を示します.
キーフレーズを抽出したいテキスト | リファレンス | プロンプト1 | プロンプト2 | プロンプト3 |
---|---|---|---|---|
またわんこそばを食べたい(体験したい)ので観光客向けのそのようなプランがあれば尚幸いです | わんこそばを食べたい(体験したい)ので観光客向けのそのようなプラン | わんこそば | わんこそば | わんこそば |
あと泊まってることで他のお店が割り引きがされたりするサービスの宿がいいです | 他のお店が割り引きがされたりするサービス | 他のお店が割り引き | 割引サービス,他のお店が割り引き | 他のお店が割り引きがされたりするサービスの宿 |
あとは遅くチェックインしたり早くチェックアウトすることで安くなるプランの宿とかってあります | 遅くチェックイン,遅くチェックインしたり早くチェックアウトすることで安くなるプラン,早くチェックアウト | 無し | 割引プラン,早割 | 無し |
チェックアウト後でも荷物を預かってくれるホテルがいいです | チェックアウト後でも荷物を預かってくれる | 無し | チェックアウト後でも荷物を預かってくれるホテル | 無し |
なので駐車場が無料か安い宿がいいです | 駐車場が無料か安い | 駐車場が無料か安い宿 | 駐車場が無料か安い宿 | 駐車場が無料か安い宿 |
煙草吸うのと吸わないやつがいるので禁煙の部屋だけど別に喫煙ルームとかあると助かります | 喫煙ルーム | 禁煙ルーム | 禁煙ルーム,喫煙ルーム | 禁煙ルーム,喫煙ルーム |
もし駅から遠ければシャトルバス等があるとありがたいですね | シャトルバス等がある | 無し | シャトルバス | シャトルバス |
あとは蕎麦アレルギー持ちがいるので事前にメニューを教えて欲しいです | 事前にメニューを教えて | 無し | アレルギー対応 | 蕎麦アレルギー持ちがいるので事前にメニューを教えて欲しいです |
これらのようにデータセット内には,リファレンスとなっている抽出すべきキーフレーズの部分が長い系列になっているものが多く存在します."〇〇なサービス","〇〇なプラン" のようにあるものを補足するような情報を含む区間を抽出しなければならない点が,一般の抽出タスクで抽出の対象する表現とは異なり,本タスクを一層難しくしていると考えられます.
また,"駐車場が無料か安い" がリファレンスの時に "駐車場が無料か安い宿" まで抽出してしまうと誤りとしてカウントされてしまうようなものや,逆に "シャトルバス等がある" がリファレンスの時に "シャトルバス" のみを抽出するようなものが確認されました.今回は完全一致による評価を採用しているため,これらは誤りとしてカウントされてしまいますが,実際にこれらの例は抽出する区間の判定が難しいと考えられます.
また,言語モデルを採用しているため抽出ではなく生成をしてしまう例も見られました.今回のユースケースとしては好ましくはないのですが,意味的には間違っていないような生成も見られました.生成を行うのか抽出を行うのか制御する手法については今後検討の余地があるように考えられます.
- 宿泊施設探索対話コーパスを用いた際の recall による評価は,"人数" を除く全てのドメインにおいてプロンプト 2 が最も高いスコアでした.今回用いた GPT モデルは Wikipedia,CC100,C4 といった,ネット上にある文を用いて学習が行われています.これらの文の多くはカンマやコロンなどの特殊なトークンを含まない自然な文です.したがって,プロンプトの形式をそのような自然な文に近づけることで GPT を扱う際に性能を向上させることができることが示唆されます.
- "予算" や "人数" では,他に比べて recall が著しく低いことが確認できます.このことから数字を抽出するような設定において,GPT は適切に抽出が行えないことが考えられます.
- ドメインによっては繰り返しの出力を行なってしまうケースもあったため
repetition_penalty
[^3] を 1.1 にした追加実験も行いました.繰り返しの出力は無くなりましたが,入力テキスト中の単語をそのまま出力する例が少なくなってしまい,recall は大きく低下する結果となりました.この原因としてはrepetition_penalty
がプロンプト中のトークンに対してもかかってしまうためであると考えられます.
結論
few shot の設定で GPT を用いてキーフレーズの抽出を行うことは可能なケースもあるものの,プロンプトによる影響が大きすぎることやプロンプト中の事例の中から抽出してしまうこと,抽出ではなくテキスト中に含まれない表現を生成してしまう例もみられて出力が安定しないことが確認できました.
プロンプトによる出力の制御に関しては今回 3 通りを試して,流暢な入力をするのが一番良い結果得られそうなことがわかったものの,出力の制御は難しそうであることが推測されます.このことから,現状の GPT モデルを今回の手法でキーフレーズの抽出器として実際にプロダクトに組み込むのは難しいと言えます.
共同研究を通して
私は 2 年半に渡って,株式会社 AI Shift と都立大小町研究室の共同研究に参加させていただきました.
杉山さん,邊土名さん,二宮さんをはじめ,毎月のミーティングや Slack で議論を行い,研究の深掘りをしてくださった皆様に感謝いたします.
まず,実際に企業で集められる自然言語処理に用いるデータに触れることができたのは大きな経験でした.普段大学の研究では既に整理されたデータを利用して実験を行なっていますが,それがいかに恵まれているのかを知ることができました.同時に,自然言語処理技術を活用するためにはデータを作成するところから始める必要があることを身をもって痛感しました.チャットボットのやりとりからQA集を用いたアノテーションと今回利用した福井県のデータから音声認識誤りを考慮した固有表現抽出のアノテーションを経験させていただいたのですが,どちらもアノテーションの基準を事前に決めて,作業中にそれをぶらさないことの難しさと重要性を実感することができました.
また,自分は研究室では機械翻訳に関する研究を主に取り組んでいるのですが,共同研究を通して固有表現抽出タスクであったり,音声認識に関する研究に触れる機会が得られたことも,自分の知見を広げることができて非常に勉強になりました.
今回のテーマではあまり望ましい結果が得られなかったのが心残りではありますが,昨年までの研究に関しては年次大会と PACLIC での発表までできて学会の場で議論できたのも貴重な経験になりました.そこまで至れたのも,ミーティングで議論や論文執筆にあたってのサポートあってのものだと思います.本当にありがとうございました.
[^1]: こちらの研究成果につきましては年次大会とPACLICの方で発表させていただきました.
[^2]: 今回想定しているような後段タスクとしてリンキングを行うような場合,前段のタスクにおいて recall が重要となるという話に関連して,言語処理学会第 29 回年次大会 (NLP2023) にて "日本語 T5 を用いた Entity 辞書のメンション候補自動獲得手法の提案と評価" という題で,株式会社 AI Shift と都立大小町研究室の共同研究として発表が行われます.
[^3]: repetition_penaltyに関する論文 🔗.1.0 でペナルティがかからないようなパラメータになります.