今回の検証内容
今回の検証は、前回の検証の続きからとなる。
前回の検証では、動物の名前を使ってWikipediaのsummaryを抽出してそれを人間の作成した文章とし、AIの作成した文章はChatGPTのAPIを使用して作成したうえで600件ほどのスモールなデータセットで、動物に関する説明の文章という種類を絞ったもので実施をした。今回の検証では、より汎化性を上げられるのかという命題のもと訳8万件ほどのデータセット(AIと人間それぞれ約4万件)を準備して検証を実施した。
データセットに準備
今回に関しては、それぞれのデータセットは以下のように作成した。
- 人間の作成した文章:Wikipediaのsummary
- AIの生成した文章:LINE社の公開しているjapanese-large-lm-3.6b-instruction-sftの回答
人間側のデータセットの準備
人間側に関しては、前回の検証と同様にWikipediaのsummaryを使用して作成した。前回と違う点としては、大量のデータの準備が必要であったため、tensorflow_datasetsからwiki40b/jaを使用してWikipedia上のタイトルのみを取得したうえで、そのタイトルをWikipediaのAPIを使用して検索をかけsummaryを取得した点である。wiki40b/jaに関しては、タイトルのみだけでなく本文も取得できるものの、このデータセットが作成された当時の文章であることと、区切り方の関係でsummaryのみを抽出するのが難しかったため、タイトルのみを取得する形をとった。
取得に使用したnotebookに関しては以下に格納してある。
https://github.com/N-OKAMOTO1031/detect_AI_generated_sentences/blob/main/get_wikipedia_sentence.ipynb
データセットに関しては以下に格納してある。
https://github.com/N-OKAMOTO1031/datasets/blob/main/detect_AI_generated_sentences/main_verification/wikipedia_summary.csv
AI側のデータセットの準備
今回の検証では、AI側のデータセットは公開されているモデルを使用して作成することにした。というのも、今回の4万件をChatGPTに投入するととんでもない料金(約400トークン×4万×0.002$=32000$)になるため流石に無理だったためである。使用したモデルとしては、LINE社が公開しているjapanese-large-lm-3.6b-instruction-sftを使用して実施した。ただ、それでも以下のような問題が発生した。
- モデルが重く、colabのハイメモリ、A100のGPUでないとまともに動かない。
- それらを使用しても単一のnotebookでは85時間かかる。
問題点の一つ目としては、お金の暴力で解決した。(大体15000円ぐらい飛んでった)二つ目に関しては、4万件のデータセットを100個ずつに分割したうえで一つずつ番号で管理し、ロードする際に終了している番号を探索し同じ番号を実行しないような仕組みを構築したnotebookを6枚(A100,V100のGPUに対して3枚ずつ)用意し同時実行することによって実行時間を短縮した。(一時間当たりの消費コンピューティングユニットが33とかになって買った分で足りるかかなりビビッた)
ただ、データ数が多く個人で検証を実施している関係でデータのクレンジングに関しては行っていない。今回に関しては、AIが生成した文章であればいいという判断のもと問題ないかと思ったが、後述するがクレンジングを行うことによって精度の向上ができた可能性もあったかもしれない。
こちらに関しても、作成したnotebookは以下に格納してある。
https://github.com/N-OKAMOTO1031/detect_AI_generated_sentences/blob/main/get_llm_sentence.ipynb
データセットに関しては以下に格納してある。
https://github.com/N-OKAMOTO1031/datasets/blob/main/detect_AI_generated_sentences/main_verification/llm_summary.csv
ファインチューニングの実行
今回に関しても、使用したモデルは前回と同じモデル(bert-base-japanese-whole-word-masking)を使用した。
前回の検証と違う点に関しては、データセットの量が十分にあるためtrain、valid、testの3つに90%、10%、10%に分割を実施して検証を行った。
それ以外の大きな変更点はないため、詳しく確認したい方がいたら以下のnotebookを格納していただきたいです。
https://github.com/N-OKAMOTO1031/detect_AI_generated_sentences/blob/main/tuning_bert_japanese_classifier.ipynb
結果
今回のファインチューニングに関しては、前回に比べて大きく結果が変わった。今回の検証のtrainとvalidのlossの変化をいかに示す。問題点としては、trainのlossに関しては小さくなっていっているものの、validのlossが逆に大きくなってしまっている。(train側が振動していたためepochを20で終了させている)
testデータに対して予測した際のAccuracyに関しては、99.2%となったもののvalidのlossの挙動がかなり気になる結果となった。
考察に関しては次の項で実施したいと思う。
epoch | train | valid |
---|---|---|
1 | 170.2533 | 13.4073 |
2 | 65.7433 | 16.3315 |
3 | 48.2002 | 11.6937 |
4 | 33.2247 | 11.3996 |
5 | 25.2652 | 11.9813 |
6 | 16.6875 | 15.9069 |
7 | 12.8385 | 14.8391 |
8 | 8.4734 | 15.2402 |
9 | 7.1986 | 16.2623 |
10 | 6.2786 | 16.6848 |
11 | 3.8589 | 19.2246 |
12 | 6.7874 | 17.5390 |
13 | 4.625 | 17.8305 |
14 | 4.6859 | 18.3513 |
15 | 2.3763 | 19.8515 |
16 | 3.4197 | 18.3330 |
17 | 1.4315 | 21.2472 |
18 | 2.6571 | 20.8284 |
19 | 3.0832 | 20.8726 |
20 | 1.9641 | 21.0284 |
以下に前回の検証時のtrainとvalidのepochごとのlossの変化を添付する。(前回の検証に使用したnotebookを書き換えてしまっていたのでepochを20にして今回のために実行しなおしている)
epoch | train | valid |
---|---|---|
1 | 0.0503 | 0.0060 |
2 | 0.0425 | 0.0066 |
3 | 0.0343 | 0.0047 |
4 | 0.0309 | 0.0041 |
5 | 0.0276 | 0.0038 |
6 | 0.0271 | 0.9346 |
7 | 0.0227 | 0.4970 |
8 | 0.0197 | 0.1995 |
9 | 0.0179 | 0.0362 |
10 | 0.0161 | 0.0068 |
11 | 0.0148 | 0.0051 |
12 | 0.0129 | 0.0042 |
13 | 0.0120 | 0.0027 |
14 | 0.0111 | 0.0020 |
15 | 0.0098 | 0.0019 |
16 | 0.0101 | 0.0016 |
17 | 0.0086 | 0.0013 |
18 | 0.0082 | 0.0013 |
19 | 0.0073 | 0.0013 |
20 | 0.0072 | 0.0012 |
考察
今回の結果に関して、過学習の際の挙動に見えるためデータの分離に失敗している可能性があるようにも考えられる。しかしながら、ランダムにデータを分離しており一応3回ほど(これ以上はリソースの関係で難しい)実施したもののすべて同じような挙動をしていた。今回から以下のような原因が考えられる。
- 今回、8万件とデータセットの規模が大きくなり、文章のカテゴリーに関してもかなり増えたためランダムな分離でも偏りが発生している可能性。
- データセットに関して、単純に抽出しただけなのでノイズが多く混ざっている可能性。
- 単純にカテゴリーが増えすぎて結果が発散してしまった可能性。
これらの考察に対しての対策としては以下のようなものが考えられる。
- 文章をカテゴリーに分けて、それぞれでtrain、valid、testに分割を行う
- クレンジング
しかし、個人での検証ではこの辺りが限界(リソース的にも規模的にも)な気がしているため今後の検証に関しては未定です。