はじめまして。東京大学大学院1年/マネーフォワードCTO室AI推進部で長期インターン中の満石風斗です。
先日行われたNLP若手の会 (YANS) 第18回シンポジウムに参加させて頂きました。
全体の様子などについては弊社山岸・竹下の記事で紹介しているため、このブログ記事ではシンポジウムを通して満石自身が得た学びについてお伝えしようと思います。
ポスター発表
私は「text embeddingを用いたデータ作成支援の検討」というタイトルで発表をさせて頂きました。研究の大元のモチベーションは「データの質/量が良くない状況でのテキスト分類の改善手法を開発したい」というものです。取り組みたいアプローチとしては
- Ground truthが存在しない状況においてデータ自体の質を高める手法の開発
- 教師なしのラベル誤り検出など
- ランダムにスプリットしたテストデータにおける分類精度を高める手法の開発
- テストデータにもラベル誤りが存在するため完璧な評価はできないことに注意が必要
の二つがあり、今回は主に2に関する研究になります。題目提出から更新した部分が多かったこともあり、少し内容が題目から離れてしまっています。
今回の研究ではテストデータにおける分類精度を高めるためにData Augmentationに着目しました。自然言語処理におけるData AugmentationはMixUpやGPT-2・BERTをファインチューニングしたもの、大規模言語モデルを用いたものが多いかと思います。しかしこれらの手法で拡張したデータが精度向上にどの程度効いているのかは不明瞭で、またファインチューニングの時間を減らすためにも拡張データはできるだけ少なくしたいというモチベーションもあります。そこで本研究ではブラックボックス最適化という手法を使うことで効率の良いデータ生成を探索できないかという萌芽的な取り組みを行いました。
今回の発表で以下のような議論を行い、アドバイスを頂くことができました。
議論
Q ラベルごとのデータを生成したいのであれば、埋め込み空間をラベルに沿ったものにするのはどうか
A デコードもしないといけないため、対照学習のような埋め込みのみの学習は難しい。デコードと分類のマルチタスク学習を行うなどは有効かもしれない
Q 最適化を行っても非文が多く生成されてしまった理由には何が考えられるか
A 最適化を行なった埋め込みの次元数が大きすぎること、また埋め込みに実はエンコーダによってエンコードされていてない領域が存在している可能性があることが挙げられる。事前学習時から最適化を行う空間を圧縮して学習する・VAEを用いるなどの対策が考えられる
Q 最適化のアイデア自体はどういう経緯で得たか
A 自分の大学院の専門であるケムインフォマティクスではブラックボックス最適化を用いた候補分子の予測が多く用いられている。同様の手法を自然言語処理でも活用できないかと考えた。分子の場合はシミュレーションによって物性を自動で調べることができるが、文章の場合は自動での評価が厳しい点に難しさを感じた
頂いたアドバイス
文章の評価としてPerplexityを用いているが、N-gramやトークンの頻度を使う方が適切かもしれない
最適化を行うよりも大規模生成モデルを用いて大量の拡張データを得たあと、スコアを用いたフィルタリングをした方が効率的なのでは
VAEを用いるとうまくいく可能性が高そう
データ蒸留というトピックが近いかもしれない
多くの議論を行い、アドバイスをもらうことができ更に研究を発展させることができると感じました。発表を聞きにきてくださり本当にありがとうございます！
発表中の様子
ハッカソン
29日（初日）にはハッカソンが開かれました。私はリーダーボードハッカソンに参加し、OpenAI APIを用いた訴求性の高い広告の自動生成に取り組みました。広告を表示したい商材のLPの説明文と検索キーワードから検索連動型広告を生成するタスクです。LLM時代だからこそできる明確な目的・制約のある生成タスクのハッカソンであり、とても興味深く取り組ませて頂きました。最終的な評価は参加者による投票で行いましたが、自動評価によるリーダーボードも用意してくださっており、リーダーボード上のスコアをどの程度信頼するかも鍵となっていました。
私たちのチームでは以下のような流れで開発を行いました。
- 2つに分かれてEDA&ベースラインをリーダーボードに一旦提出
- 前処理担当・プロンプトのチューニング担当・後処理担当に別れて実装
- 2をドッキング&スライド作成
まず1のEDAでは入力のLP・検索キーワードや開発データの正解広告文を自分達の目で見る・頻度解析をするなどして傾向を掴んでいきました。これにより全体の雰囲気が掴めたのと同時に以下のような発見をすることができました。
検索キーワードと全く関係ないような商品の広告生成が必要な場合がある
- 実はこれは開発データのみの傾向であり、本番ではこのような例は除外されました
[, ]や公式,予約などの単語が通常に比べて多い- 自分達自身の経験も踏まえると、ユーザーに「このサイトのみで予約までできる」と認識してもらえると訴求性が上がるのではないかと考えました
今回の評価尺度である訴求性のみを考えるともっと魅力的な文章を人手で作成することができるのではないか
具体的なアクションにつなげられる学びを得ることができ、EDAの重要さをあらためて実感することができました。またこのEDAを通して私達のチームではリーダーボードよりも自分達の感性を信じた生成文評価を行うことにしました。こういった何を信じるかといった面で個性を出せるのも生成型コンペの面白さだと感じました。
上記のような結果から、以下のような開発を行っていきました。
開発データに対して自分達の考える正解の広告を人手で作成し、Few-shot時はこの作成データから取り出してプロンプトに入力する
1/3の確率で文頭に[公式]という文言を入れる・LPに予約という単語が含まれていれば末尾に予約完了までという文言を入れる
- 本当に公式なのかについては、広告を出す際の審査の時点で公式である（フィッシングサイトではない）ことは保証しているだろうと判断しました
またプロンプトにおける工夫として、検索キーワード等に対する背景すらもOpenAI APIを用いて生成する多段でのプロンプティングを用いました。これによって目に見えて生成文が変わったため、一番効果の高い施策だったかもしれません。
プロンプトについては他にも様々な検証を行なっていて、例えば開発データからの近傍探索+Few-shotを用いた場合だと入力例の数n=1の場合とn=3の場合ではほとんど生成文に変化がありませんでした。これはよくよく中身を見てみると開発データには非常に似た文章が多く用意されていて、n=3にしてもほとんど同じ例が入力されていることが原因のようでした。本番では取り入れられていないのですが、まずは開発データをいくつかにクラスタリングして1つのクラスターからは1つしか例を取得しないという制約を加える、などの施策が考えられます。
結果だけを見ると不可解な現象でも中身を確認すると次の施策につながったりと、中身をしっかりと確認することの重要性を改めて実感することができました。
本番では最後のドッキングの実装が間に合わず、せっかく作成した正解データをプロンプトに入力できずに泣く泣くZero-shotのものを提出するという形になってしまいました・・・。改めて時間配分の重要性を痛感することになってしまいました。
反省点もありつつでしたが、順位としては3位という好成績を収めることができました！結果ももちろん嬉しいですが非常に面白いタスク・データに触れながらなんとかチームで開発をやり切ることができ、非常に良い経験となりました。
さいごに
YANSでの3日間を通して多くの技術的な学びを得られたと共に、多くの方々と交流することができました。ハッカソンで同じチームになった方と文章埋め込みについて盛り上がったり、就職活動やキャリアについて情報交換できたりと本当に良い経験をさせて頂きました。
企画・運営をして頂いた委員の皆様に心より感謝を申し上げます。
