【Conference Projector】OpenAI API を使って CVPR 2023 全体を眺めるWebサイトを作成した
概要
CVPR 2023 会議全体を可視化したグラフを眺めながら論文検索できるWebサイトを作成したので紹介します。
会議に採択された論文全体を可視化したグラフから、 カテゴリやアプリケーションが近い論文を探せます。
テキスト検索ではない方法で、広い視野で論文を探せます。
会議全体で盛り上がっている分野や、逆にニッチな分野を把握することもにも役立ちます。
研究テーマを模索している方や、広い視野で業界動向を知りたい方におすすめです。
yuukicammy--conference-projector-wrapper.modal.run
はじめに
こちらの記事にインスパイアされました。
このシステムは文章やキーワードから論文を検索しますが、具体的なキーワードというよりは会議全体を俯瞰して調査したいなと思ったため今回のWebサイトを作りました。
cvpaper.challengeの活動に興味のある方などは関心が近いかもしれません。
Conference Projector で何ができるか
会議全体の論文を投影した散布図から、ノードをクリックすることでその論文の概要やその論文に近い論文を閲覧できます。 論文のカテゴリ、アプリケーション、タイトル、アブストラクトの観点から会議全体の俯瞰や近しい論文を探すことができます。
ここでカテゴリ*1とは、論文が取り組んでいる特定の研究テーマや研究領域を示します。例えば物体検出や露光補正などです。 アプリケーションとは、論文の技術が想定している応用先を示します。例えば自動運転などです。
使い方はこんな感じです。
カーソルを合わせるとの論文情報が表示されます。カーソルを移動させながら素早く多数の論文タイトルや研究カテゴリを把握できます。
会議全体の論文を可視化したページノードをクリックすると、その論文に関する情報が閲覧できます。選択中の論文に近い論文も閲覧できます。
選択した論文とその類似論文を閲覧するページ
システム概要
下記のツールを利用してシステムを構築しました。
- LLM: OpenAPI API
- グラフィックライブラリ: Plotly
- Webアプリフレームワーク: Dash
- DB: Azure Cosmos
- インフラ: Modal
下記の手順でシステムを構築しています。
- (1) スクレイピング
- (2) カテゴリ、アプリケーションなどのテキスト生成
- (3) Embedding
- (4) PDFからの画像抽出
- (5) 次元圧縮
- (6) K-D Tree構築
- (7) Webサイトデプロイ
(1)から(6)までが前処理で、データを揃えたのちにWebサイトをデプロイしています。 Webサイトは前処理で揃えたデータのみを使っており、新たに OpenAI APIなどへのリクエストが発生することはありません。 これによりWebサイトのレイテンシを小さくするとともに、ランニング費用 (APIリクエスト費用) を抑えています。
データ前処理のパイプライン論文を散布図に投影し類似の論文を検索できるようにするまでには、下記のようなプロセスをとっています。
論文を散布図に投影し、近傍探索するまでの処理詳しいプロセスは次の章で述べます。
実装詳細
(1) スクレイピング
会議に採択された全ての論文情報を抽出します。 CVPR 2023 Open Access のタイトル一覧ページ を最初の入力として論文情報をスクレイピングしました。 抽出したデータはAzure Cosmos DBに保存しています。
ここで抽出する論文情報は下記4つです。
- タイトル
- アブストラクト
- arXiv ID
- PDF URL (CVPR Open Access)
(2) カテゴリ、アプリケーションなどのテキスト生成
会議のWebサイトから抽出できない情報 (カテゴリなど) をOpenAI Chat APIで生成しました。
こちらの方法と同じように、出力のフォーマットを指定する目的でFunction callingを使っています。
モデルには gpt-3.5-turbo-0613 を使いました。2023年6月時点でFunction callingを利用できるモデルがこれとgpt-4-0613しかなく、自分のアカウントではGPT-4のAPIは使えないためです。
論文のタイトルとアブストラクトを含むプロンプトから、 論文のカテゴリ、アプリケーションなど下記6項目をテキスト生成しました。
- 論文の概要
- 先行研究より優れている点
- 提案手法のポイント
- 実験結果
- カテゴリ
- アプリケーション
各項目を日本語と英語で生成するため、計12項目の文章をGPTで生成しています。 利用したプロンプトとFunction callingのスキーマは下記をご覧ください。
プロンプトはバッチ化せず、1リクエストで1論文-12項目のテキストを生成しています。 OpenAI Tokenizer で測ったところ、リクエストの入力トークン長は500程度、出力トークン長は2000程度でした。2359件のリクエストをして各論文12項目のテキストを揃えます。
この GPT-3.5 Turbo によるテキスト生成プロセスが最も時間とお金を消費しました。 ここに書かれている 通りGPT-3.5 Turboはレスポンスが遅く、頻繁に過負荷による 503 Error が出ます。 レスポンスを得るまで20秒程度かかり、2359件揃えるのに最低16時間かかります。 またFunction callingで指定している12項目全ての出力を必須にしても、一部あるいは全ての項目で生成されないされない場合があります。 12項目が全て生成されるまで数回リトライしました。 さらに入力・出力の試行錯誤もあります。間違えたリクエストを大量に送って時間と数千円を無駄にしたりもしました。
(3) Embedding
各論文に関する4つのテキスト (カテゴリ、アプリケーション、タイトル、アブストラクト) をOpen AI Embeddings APIで
Embeddingしました。モデルには text-embedding-ada-002 を使いました。
処理時間を短縮する目的で、GPT best practices - Improving latencies を参考にバッチ化してリクエストしました。最大で20のテキストをバッチ化してリクエストできます。一時的に過負荷エラーが出つづけることもあったのですが、Chat APIのテキスト生成に比べれば素早く全ての処理を完了できました。
(4) PDFからの画像抽出
提案手法の概要を示したような画像を取得したくPDFから画像を抽出したのですが、これが一筋縄ではいきませんでした。 CVPR Open Access に置かれたPDFから図を PyMuPDF で抽出したのですが、良さげな画像があまり抽出できませんでした。*2
試行錯誤の上、下記のプロセスで論文の代表画像を抽出しています。
- CVPR Open Access にあるarXiv情報、および、arXivでタイトル検索し、arXivに登録されていればソース一式から最大サイズの画像を取得する。
- 1に失敗すれば、CVPR Open Access のPDFをPyMuPDFで解析し、表示領域が最大の画像を取得する。
工夫はしましたが、いい感じの代表画像が取得できている割合は感覚的に20%程度です。 ここは改善したいです。
(5) 次元圧縮
各論文情報を散布図に投影するためにEmbeddingを2次元と3次元に次元圧縮します。 次元圧縮の方法はUMAP、t-SNE、PCAの3手法を採用しました。 次元圧縮したEmbeddingで論文の類似度を測っているため (理由は後述)、ここでの次元圧縮結果が非常に重要です。 Webサイト上でユーザに次元圧縮のハイパーパラメータを変更してもらうことも考えましたが、実装負荷とWebサイトのレイテンシの観点から今はやっていません。
(6) K-D Tree構築
類似の論文を高速に検索するために、事前にEmbeddingをノードとしたK-D Treeを構築しています。 K-D Treeは下記の設定で次元削減した24種類 (4 x 3 x 2) のEmbedding群のそれぞれで構築しています。
Embeddingを次元削減する設定 (組み合わせは24種類):
OpenAI APIで得た1536次元のEmbeddingのまま類似度を測りTreeを構築すればシンプルですが、それだとユーザが散布図で見ている近傍ノード (論文) と、システムが高次元Embeddingから判断した近傍ノードが異なり、ユーザ体験を損ねます。それゆえ、次元削減した2次元・3次元のEmbeddingからK-D Treeを構築しています。
高次元で探索された近傍ノードは、2次元投影後に近傍にみえない場合が多い
(7) Webサイトデプロイ
Dashを使って構築しました。DashはPlotly社が開発したPythonフレームワークで、FlaskをベースのWebサイトを簡単に構築できます。Plotlyのグラフを使ったインタラクティブなWebが作れるので今回の利用に適していました。Dashを使ったのは初めてでしたが比較的かんたんにWebサイトを構築できました。
今はModal上にDashをのせるかたちでサーバレスなWebサイトを構築していますが、このインフラ選択はまだ悩みがあります。サーバレスとして作るよりモノリスなWebサイトとして構築した方がレイテンシやトラブル回避の観点で良いかもしれません。またWebサイトをDashを使わず構築した方がレイテンシを小さくできるでしょう。今回は使い慣れているためModalを選んだ*3 ことに加え、HTML/CSSのフロントエンドコーディングはあまり頑張りたくないのでDashを使うという判断でした。
役立つものはできたのか？
広い視野からの論文検索
- 会議全体の論文を眺めながら読みたいと思う論文を探せるという意味では、広い視野からの論文検索は実現できたと思います。
- 今のままでは情報がのっぺりしていて、自分にとって関心の高い論文に行き着くまでに手間がかかります。
改善に向けて
- キーワード検索を組み合わせたり、評価された論文をわかりやすく示すなど論文に辿りつくための手がかりがあった方がよさそうです。
カテゴリ・アプリケーション観点での類似論文検索
- 特定のカテゴリ・アプリケーションはうまく近傍にまとまっており類似の論文が見つけやすいと感じました。
- カテゴリ・アプリケーションがうまく推定できていないケースも多く存在します。例えばカテゴリがコンピュータビジョンになっているケースがあります。アプリケーションは長文になりがち、かつ、的を得ないケースが多かったです。
- カテゴリが的確につけられても、カテゴリ間の近さがうまく表せませんでした。例えば画像の露出補正とノイズ除去は近しいような気がしますが、カテゴリでもアプリケーションでも近づけられませんでした。
改善に向けて
- プロンプトに記載する具体的なカテゴリとアプリケーションの例を増やすことが必要そうです。
- アプリケーションの推定はPDF本文も参考にした方がいいかもしれません。
- 近しい論文をより的確にするために、次元圧縮方法などの工夫が必要です。
会議全体のトレンド把握
- Zero-Shot/Few-Shotが高い密度でそれなりに大きなクラスタになっており、トレンドを表していることがわかります。
- 実はプロンプトにカテゴリの例として「3D人物姿勢推定、3D物体追跡、物体検出, 露出補正」を記載しています。これらは比較的うまくまとめられたものの、他のカテゴリは低密度になることが多いです。
- 距離が離れているとマイナーなカテゴリとみなしやすいものの、低密度なエリアはマイナーなのかどうなのか判断しづらいです。
改善に向けて
- プロンプトにカテゴリとアプリケーションの具体例を増やす改善に加え、次元圧縮のチューニングとそれらの効率化も必要です。
おわりに
活躍するツールになるにはまだ課題が多いです。初日はほぼ徹夜で一人ハッカソンとして作って完成させましたが、「後もうちょっと」が続き3週間が過ぎました。当初ハッカソン的に作り始めた時よりは実用的に使えそうなツールになりましたが、多数のバックログがあるのと、Embeddingを作り直すのにお金がかかるという問題があります。
作ってみて実感したのは、LLMをモデル更新に関与せず活用するには、実用上プロンプトエンジニアリングから逃れられないということです。 正直これまでプロンプトエンジニアリングの価値を軽視しており、今回もあまり練られていません。 論文に付与するカテゴリ・アプリケーションのテキストを的確に生成することが可視化全体、つまりユーザ体験に強く影響しており、これらを生成するためのプロンプトが重要だと考えています。具体的には、生成させたいカテゴリやアプリケーションの具体名をプロンプトで示すことに効果がありそうです。 プロンプトエンジニアリングを効果的なチューニング作業の一つとして捉えるようになりました。
yuukicammy--conference-projector-wrapper.modal.run
コードはこちら
英語ブログはこちら
こちらの記事も関心が近いです。
