前回つくったものと不満点
前回記事ではarXivから取得した論文のAbstractをOpenAI APIを用いて3行で要約し、Slackに投稿するシステムを作った。
概ねうまく動いていて満足だったのだが、それでもいくつかの不満が残っていた。
今回は不満の中でも以下の三点に注目した。
- 取得する論文の基準をカテゴリ内の最新論文と同じSubmittedDateのもの*1とたため、たまに収集が漏れる
- 異なるカテゴリにまたがって投稿されている論文を二重に収集してしまう
- 取得したデータはSlackにのみ蓄積する形だったため、無料版では一定期間で消えてしまい検索性に欠ける
これらに共通する原因は、収集済みの論文データを判定できないことにある。
そこで今回はMySQLに収集したデータを蓄積することで、これらの不満を解消した。
使ったものと躓いたところ
MySQLに論文データを蓄積
データベースと連携して論文データを蓄積することで、不満点は次のように解消される。
- 収集漏れ：取得条件を「データベースに存在しないもの」に変更することで防げる
- 二重収集：データベースに存在していれば二重に収集されない
- 保存期間・検索性：(実質的に)いくらでも保存でき、検索も容易
データベースについてはMySQLの経験が少しだけあったし、Pythonからのラッパーも使いやすそうだったのでこれを使うことにした。
- 参考にした記事
- 躓いたところ
できあがったものとまとめ
結果として抜け漏れがなく被りもない収集体制が"ほぼ"整った。
全体の流れとしては、最新論文から多めに見て、データベースと照合し、未収集のものだけ要約して保存＆Slackに投稿という手順。
なので初回は尋常じゃない数の論文がSlackに流れて通知がとんでもないことになったが、二回目以降は差分だけを投稿してくれた。
現状なんらかのバグがあり、少ない割合だが以下の二種類の失敗が確認されている
- 確率的な失敗：おそらくGPTの出力が適切なフォーマットになっていないせいか、作成したクエリに存在するはずの要約文のキーが存在しないことがある
- 決定論的な失敗：いくつかの決まった論文がデータベースにinsertされない現象が起きている。例えばこれ
前者についてはGPTの出力が確率的なのはしょうがないんだが、一定の基準を満たしているかテストして失敗したら再チャレンジさせているので、なんか変な感じがする。
後者はデータベースの定義に問題があったか、挿入する文字列が悪質になってしまっているかなどの候補が思い浮かんだが、細かいところはわかっていない。
詳細な原因を調査したいが、今週末に向けて本業(？)の練習をしないといけないので、またしばらくしてから。
せっかくデータベースに貯めるなら、適当な期間で区切ってクラスタリングしたりすると面白いかも。
*1:厳密には24時間以内
