CyberAgent AI Labにおける論文投稿管理術
はじめに
CyberAgent AI Labにてリサーチエンジニアをしている大田です。普段は研究の成果最大化と事業還元を目的とした活動をしています。業務の片手間でAI Lab全体に関わる社内ツール運用も行っており、今回のアドベントカレンダーではそこでのお話をしてみようと思います。AI Labでの論文投稿管理の仕組みについてです。
論文投稿管理画面のキャプチャ（2024年上半期以前の採択・公開済み論文を表示中）
Publications Management Database (PMDB)
AI Labは企業の研究開発組織であり、主な業務として論文執筆・出版があります。これは各研究チーム・個人の成果目標にもなっており、期初に「今年のCVPRに論文を投稿する（そして採択される）」などといった目標を立てて各自が研究に励んでいます。AI Lab全体としても期中に論文投稿・採択数がどれだけあったのかは組織のメトリクスとして追跡しており、常に最新の論文投稿状況を把握しておく必要があるため、メンバーには下記のようなタイミングで専用の論文投稿管理DB（Publications Management Database; PMDB）に投稿情報の登録・編集を依頼しています。
- 論文投稿が決まったとき
- 論文を投稿したとき
- 採択結果が返ってきたとき
投稿情報は下記のようなデータで構成されています。投稿が決まった時に一度登録してしまえば、その後は状況の変化に伴って投稿ステータスを変更するだけのユースケースとなっています。
- タイトル
- 著者
- 論文投稿先の会議・雑誌
- 査読の有無
- 会議開催日・雑誌出版日
- 研究分野
- 投稿ステータス
- 投稿予定、投稿済み、投稿結果（採択 or 不採択）
このPMDBの実態はごく普通のRDBMS（MySQL）です。2023年まではGoogle SpreadSheetで投稿情報を管理していたのですが、下記のようなSpreadSheetならではのツラミもあり、2024年からはGCP CloudSQLでMySQLインスタンスを立ててそこで管理を行う運びとなりました。
- 誤操作
- 誰かの意図しないセル操作でデータが変わってしまう
- 表記揺れによる別データ化
- 著者名、所属名、会議名の記載方法が人によって異なる
- データ重複
- ユニーク制約がかけられず、警告として強調表示できるのみ
これまでのSpreadSheetシート1枚のデータを正規化して複数のテーブルに分割し、各カラムに必要な制約をかけることでデータ全体での整合性を高めています。
管理画面
SpreadSheetをRDBMS化するのは良いとして、メンバーがブラウザから直接触れる管理画面も一緒に提供してあげないと直感的で一貫性をもったDB操作ができません。正直SpreadSheetに近い操作感を実現するフロントエンドをサクッと実装できる自信は自分にはなく、PMDBの運用が本業ではない以上それに工数をかけるわけにもいかなかったため、MySQLをバックエンドに据えることのできるWebDBツールや管理画面用CRUDツールを検証し、最終的にSQLAdminというOSSの利用に落ち着きました。
DBテーブルのプロビジョニングにSQLAlchemyを使用していたのですが、SQLAdminはSQLAlchemyのモデルコードをそのまま利用可能だったことと、テーブルUIにtablerが採用されておりデータの見栄えも悪くはなさそうだったことが挙げられます。ウェブフレームワークにはFastAPIが採用されており、そのままGCP Cloud Run上でホストすることで動くようになったのもありがたかったです。
また、内部で発行されているSQLのデフォルトのソート方式を変更したり、バリデーションクラスをオーバーライドしたりと、使ってみて気になった点についてはカスタマイズしています。もともと自由度の高い設定が可能なツールになってはいますが、中身の挙動を変えたいところはどうしても出てきてしまい、その過程でコードをしっかりと読み込むハメにはなりました。他には主に下記のような点を独自実装しています:
- ログイン機能を社内のOpenID Providerと連携するようにし、PMDB側で認証情報を保持しないように変更
- ログイン時に社内認証基盤から得られたユーザ情報（社員番号、メールアドレス）をセッションに埋め込むことができ、画面表示についてちょっとしたパーソナライズが可能に
- データ一覧画面にチーム、査読の有無、出版年次など投稿情報として重要なカラムで絞り込める機能を追加
- デフォルトで設置されているのはテキスト部分一致検索のみ
- セッション内のユーザ情報と合わせて自分の論文のみに絞り込んで表示する機能を追加
逆に採用を見送ったのが各種WebDBツールでして、AirtableやBaserowが挙げられます。これらはSpreadSheetに限りなく近い操作感に加えRDBMSのテーブル・カラム制約を活かせるいいとこ取りのような良さがあったのですが、画面上に表示したくないカラムの不可視化や関連テーブルの操作などに難があった上、SQLAdminほどカスタマイズを柔軟に施せそうになかったため、今回の件においては使用を断念しました。
1年間運用してみて
12月でPMDB運用開始からちょうど1年が経過します㊗️。新しくDBを構築して運用するほどのことなのかとは今でも思う時がありますが、SpreadSheet管理で困っていた件は一応クリアでき、当時しばしば発生していたデータの修正ごとに関する相談が激減したのは良いことです。
RDBMS化したことで登録されている論文投稿情報に対する集計作業も一新しました。SQLを発行することができるようになったため、現在の投稿状況について、チームや査読の有無などセグメントごとの集計・可視化のクエリを管理しやすくなりました。システム連携の可能性も広がり、今後はAI LabウェブサイトのPublicationsページに採択論文を自動反映する仕組みを計画中です（現状は論文著者によるWordPress管理画面からの手入力が必須…）。
ただ、主にSQLAdminに対してカスタマイズしたい・するべき案件が未だ山積みの状況です。メンバーからのバグ報告や要望もちょくちょく貰っており、本業が忙しいときには捌ける余裕が全然ないのがツライところです。それでもゼロからフルスクラッチで作っていた場合はもっと大変だったはずで、片手間運用ということを踏まえるとデフォルトでもそこそこ使いやすい管理画面用CRUDツールであるSQLAdminの採用は丁度良い落とし所だったとは感じています。
おわりに
PMDBはシステムとしてはウェブサービスの管理画面とほぼ一緒です。社内限提供のため外部ユーザからの膨大な高負荷リクエストが届くわけでもなく、データ容量も1年運用して数MB増えた程度です。DB構築運用としては本当に簡単なことしかしていません。ウェブ系の勉強会などで発表するテーマとしては特に面白みもなく受けが悪いでしょう。
しかしながら、これまで研究組織における論文投稿管理術というテーマについてネット上で見聞きしたことがなかったため、「AI Labではこんな感じでやってますよ」的に今回アドベントカレンダー用の記事にまとめてみました。他の研究組織での論文管理の需要がどれだけあるかはわかりませんが、もし「我々もSpreadSheetなりテキストファイルなりで論文投稿の管理を頑張ってるけど、もうちょいいい感じにしたい」というような課題感があれば少しは参考になるかもしれません。ウェブ開発・運用経験を身につけるうえでも丁度良い規模のシステムにも思えます。今回のような小粒なシステムでも運用上考えることは想像以上に出てくると思いますので、学生が研究室で構築・運用してみるのも良いのではないのでしょうか。もし詳しく話を聞きたい場合は私までお気軽にご連絡いただければと思います。
Discussion