Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AI時代に調査、執筆を高速に行う方法まとめ
Search
逆瀬川
January 17, 2025
6
990
AI時代に調査、執筆を高速に行う方法まとめ
Qiita Advent Calendar 2024 Online Meetup Lightning Talkの登壇内容です
文献調査、執筆等の方法についてまとめました!
逆瀬川
January 17, 2025
Tweet
Share
More Decks by 逆瀬川
See All by 逆瀬川
o1 Product Idea (Generated)
sakasegawa
0
5.5k
Featured
See All Featured
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
7.1k
4 Signs Your Business is Dying
shpigford
183
22k
The Cost Of JavaScript in 2023
addyosmani
47
7.5k
Documentation Writing (for coders)
carmenintech
69
4.6k
The Art of Programming - Codeland 2020
erikaheidi
53
13k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.2k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
12k
Facilitating Awesome Meetings
lara
53
6.3k
Fontdeck: Realign not Redesign
paulrobertlloyd
83
5.4k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.8k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
227
22k
Transcript
ソロアドベントカレンダーをやってみた 件について〜AI時代に調査、執筆を 高速に行う方法〜 Qiita Advent Calendar 2024 Online Meetup
Lightning Talk by 逆瀬川ちゃん
Who are you 逆瀬川 (さかせがわ) https://x.com/gyakuse 敵か味方か 謎の美少女。 2
アドベントカレンダー結果 生成AI プロダクトカレンダー2024 3
今日話すこと • どのように計画するか • どのように調査するか • どのように執筆するか • どのように失敗したか
4
どのように計画するか 5
経緯 • 発端 ◦ アドベントカレンダー書きたいな〜と思 いつく ◦ 生成AIアドベントカレンダーが埋まって て泣く •
やってみよう! ◦ 生成AIプロダクトアドベントカレンダー を書いてみることにした ◦ 12月1日のアドベントカレンダー開始ま で残り2日間 • とにかく計画を立てる! 6
さくっと計画を立てる方法 • 締め切り、作業可能な期間を把握する ◦ 11月29日-12月19日 ◦ ネタ決め、下書きを29-30日で終わらせる •
タイトルを考える ◦ 生成AIプロダクトカレンダー • 方針を考える ◦ 面白いモデル・簡単なプロダクトを25個作成する • ネタを洗い出す ◦ がっと書く • 下書きを書く ◦ フォーマットを作成し、下書きを書いていく 7
下書き (アイデアメモ) のフォーマット • これはなに? • なにが嬉しい? (課題やうれしさ等) •
誰が喜ぶ? • なにを使う? (ライブラリ、フレームワーク、モデル等について) ◦ フレームワーク: ◦ ライブラリ: ◦ モデル等: • どう見せる? (画面等) • 具体的にどうする? (処理の流れ、実装等の詳細、アイデアについて) • その他 8
実際に書いた下書きの例: 画像からいい感じの確信度つき構造的データ抽出をするアプリ • メモ ◦ gradio or streamlit ◦
読み取りの確信度を出してくれる ◦ LLMの出した数字をそのまま信じるのって難しいよね ◦ 複数のvision系のAIを組み合わせる ◦ OCR (microsoft), LLM (gemini, openai) ◦ 判断が分かれる部分はあやしい… ◦ もっとシンプルなOCRも混ぜてもいい • これはなに? ◦ レシート等をいい感じに構造的データ抽出してくれるやつ i. レシートに限定しない ◦ いい感じの確信度を入れてくれる • なにが嬉しい? (課題やうれしさ等) ◦ gpt-4o等のLMMで普通に抽出すると、ミスる。手書き文字だとCAR (文字単位の正確度) はかなり下がる ◦ 一方で、間違って検出された文字列でも、LLMの特性上、『それっぽい』ものを出してしまう ◦ 画像からのデータ抽出作業のサポートとしてLMMを導入したいが、安易に導入するとリスクがあるので、それの解決策を検討する • 誰が喜ぶ? • なにを使う? (ライブラリ、フレームワーク、モデル等について) ◦ フレームワーク: ◦ ライブラリ: ◦ モデル等: • どう見せる? (画面等) • 具体的にどうする? (処理の流れ、実装等の詳細、アイデアについて) • その他 ◦ 確信度は一般的な課題と思われるから先行研究があるはず。既存の手法を調べる ◦ gpt-4vの既存のOCRのSOTAモデルとのOCR性能比較 i. https://arxiv.org/pdf/2310.16809 9
どのように調査するか: MCP記事調査事例 10
概要 書きたいこと: • MCPの解説 • Claudeを使わないMCPサーバーの 実装
事前の状況: • MCPが何かわからないので調べる 必要がある • 実装も理解する必要がある 11
未知の概念を理解する 概念の骨子を理解する際は以下を把握するように読み進めると便利! • それは何か • それがなぜ嬉しいか (モチベーションは?)
• 何に使えるか • 結局、噛み砕くと、どういうものか また、技術系の問題であれば、書籍、公式ドキュメント、実装を読むのが重要 →MCPの場合はリリースから日が浅かったので公式ドキュメントを読むことに 12
公式ドキュメントの読み方 高速読解するときは以下の順序が易しい 概要部分を読む → 図を見る → 図のわからない部分を読み込む → 全体をざっと読む
→ 理解しづらい部分は実装をざっと読む 右図が実際にMCPの説明で使われている ものにあたる。 • LLMとデータやサービスをつなぐサーバー のためのプロトコル群 と一旦理解してしまえば、理解は早い 13
LLMを使った実装の読み方: uithubを使おう! https://github.com/modelcontextprotocol/python-sdk • 上記のようなリポジトリURLのgithubをuithub (g→u) にすれば 実装をコピー容易な形状にできます。 •
これをもとにLLMにコンテキストとして供給し対話を行うこと で、高速に理解をすることができます。 • 注意: コンテキストを大量に消費するため、推論能力に制限 がかかり誤読が起きうることを気をつけましょう。 14
どのように調査するか: ハルシネーション記事事例 15
概要 書きたいこと: • ハルシネーションの分類について • ハルシネーションの研究動向
事前の状況: • サーベイは常に行っている状態 16
継続的に文献調査を行う方法: (1) 論文情報の入手 • ChatPaper でarXivのデイリーを読む ◦ abstractが日本語訳されているだけでなく、内容もまとめてあり、手っ取り早く見るのにとても良
いです • Xでおすすめに上がってくる論文をチラ見する ◦ Xを完全に調教すると論文情報しか上がってこなくなります • Xで信頼できる人のポストを見る ◦ 信頼でき、自分の言葉で書いている人のポストに目を通すのがオススメ ◦ 自分の場合は英語圏であれば Sumit さん、日本語なら岡野原さんの投稿から興味のある分 野を見たりしています • Discordで情報を収集する ◦ EleutherAIのoff-topicチャンネルやresearchチャンネルなど 17
継続的に文献調査を行う方法: (2) 管理方法 • 自分の管理方法の変遷 ◦ Evernote → Mendeley
→ Notion ▪ ちゃんとやるなら現在でも Paperpile, Mendeleyのような 文献管理ソフトは必須 • 以前はTODOリスト形式で綺麗に分類 していたが、現状は雑に放り込んでい る 18
継続的に文献調査を行う方法: (3) 論文を読む • どのように論文を読むか ◦ まずReadableで翻訳 ◦
一通り読んだあとChatGPT / Claude等 にも放り込み対話 ◦ 実装がある場合はそれも目を通す ◦ 自分の言葉でまとめる ◦ 引用先の論文は可能な限り読む • 最低限以下をまとめる ◦ 分類 (アルゴリズム, システム, データ セット, 等々) ◦ 一行概要 ◦ モチベーション ◦ うまいな、かしこいな〜って思ったとこ 19
論文読解例: mini-omni2 -> ここは発表では飛ばす • https://arxiv.org/abs/2410.11190 , https://github.com/gpt-omni/mini-omni2
• これは何? ◦ S2Sモデル ◦ gpt-4oのように単一のモデルでVision, Audio (Speech), Textを入力でき、Realtime APIのようにend-to-endでリアルタイムに音声入力し出力 をストリーミング生成可能なモデル ◦ mini-omniの後継。Vision入力、ストリーミング生成、interrupt機能(音声対話中断)に対応 • ここがすごいよmini-omni2 ◦ delay部分がガチでかしこい • アーキテクチャ ◦ 入力 ▪ Vision Encoder • CLIPの ViT-B/32 (openai/clip-vit-base-patch32) を使ってencode • Adapter層 (1層) 挿入 <- ここが学習対象 ▪ Audio Encoder • Whisper-small のエンコーダのみを使ってencode • Adapter層 (1層) 挿入 <- ここが学習対象 ◦ Language Model (主部) ▪ Qwen2-0.5Bがベース ▪ デフォルトのvocabにSNAC tokenizerのvocabをくっつける ◦ 出力 (Text-Instruct Delay Parallel Decoding) ▪ テキストトークンと オーディオトークンを擬似的に並列生成 • テキスト1層+音声7層のlogitをスライスして使っている • テキスト->音声は1ステップずれた交互生成の形をとる • 学習の流れ ◦ Stage1: Multimodal Encoder Adaptation ▪ Vision, Audioのエンコーダの後ろにあるアダプタを学習する -> テキスト埋め込みに近い表現になるようにしたい ▪ encoder, LLMは固定しアダプタのweightのみを更新 ▪ 損失関数はCE loss (LLMの最終CE loss) ◦ Stage2: Modality Alignment with Languague Model ▪ マルチモーダル入力 -> テキスト出力の学習を行う • 画像QAや音声QAのデータセットでの学習 ▪ encoder, アダプタは固定しLLMのweightのみを更新 ▪ 損失関数はCE loss ◦ Stage3: Post-Training of the Model's Multimodal Output Capabilities /Semantic Interruption ▪ 音声生成を含めた学習を行う (adapterも一部更新) ▪ テキストと音声の同時生成(を行えるようにする ▪ 損失関数はCE loss • 利用しているデータセット ◦ テキストQA: Open-Orca ◦ ASR: LibriTTS, VCTK, Multilingual LibriSpeech ◦ 音声QA: Moss-002-sft (ttsで音声変換) ◦ 画像QA: ALLaVA-4V ◦ 音声アシスタント: VoiceAssistant-400K 20
効率的に文献調査する 日常の文献調査と異なり、特定の分野・トピックについて調べるときは以下のように行う • 検索する ◦ arXiv search、Google
Scholar、Semantic Scholar などで引用数ソート等して主要論文を見つける ◦ Perplexity AIのPro SearchやGemini Advancedの1.5 Pro with Deep Researchは2025.1時点では痒いところに手 が届かない • awesome xxx のリポジトリを探す ◦ 人気のある分野では優れた論文集として有志がまとめてくれている ◦ たとえばNeRFの場合は awesome-NeRF リポジトリ等がある • サーベイ論文を読む ◦ 人気のある分野では ◯◯: A Survey のような典型的なタイトルでサーベイ論文が出ているのでそこで引用され ている論文を読む ◦ サーベイ論文ではその分野の勘所もわかりやすく説明されていることが多く便利(誤った解釈もある) • 該当分野の対象トピックに対する最新の論文を読む ◦ たいてい Related Work として示されたりしているので、それを拾う 21
どのように執筆するか: OCR事例 22
概要 記事の内容: • OCRの確信度を出す手法 ここで語りたいこと
• 試行錯誤を見せることの重要性に ついて 23
試行錯誤を見せる 「なぜそうしなかったか」「それがうまくいかなかったか」の形跡を見せよう! • 成功例をそのまま出すのは味気ない上に学びが少ない ◦ 特定の問題に対し、アプローチはいくつもある場合が多い。 ◦
そのアプローチを実際にやってみせ、どううまくいっていないか、ということを明 らかにしておくと、後続の人がその失敗したアプローチの改善点を見つける可 能性もあるし、回避する場合でも重要な根拠になってくれる 24
このお話の前提 • OCRでは、複数のモデルで抽出候補を複数出したかったが、LMMでの抽出は座 標付きでない場合が多い ◦ そのマッチングをどうするか。考えられるのは以下のようなアプローチ ▪ LMMでテキストと矩形範囲をそのまま出すように指示し、近傍のボックス
とマッチングする ▪ OCRでスキャン後、画像にバウンディングボックスとIDを直接書き込み、 LMMにはIDに対応する部分の矩形の中にあるテキストを抽出させる • 結果、2つ目を採用したが、1つ目がどうしてうまくいかないかを示すことが大事 →うまくやらないケースも改善手法や別のアイデアの源泉になりうる 25
失敗による学び 以下の実験を行うことで、現時点のLMMでテキストと矩形範囲をそのまま出力させる とミスマッチングが起こりやすいことが明らかになった 26
個人的に好きな失敗 Unityで合成データを作り、 Florence2をFine-Tuningして麻雀牌を検出させる記事 用意した合成データ FT後の推論結果 27
個人的に好きな失敗 ピーナッツ!!! 28
どのように失敗したか 29
どのように失敗したか インフルエンザにかかりました 30
うまくいかなくてもやることは大事 • 頑張ってもうまくいかないときもある ◦ 病気、モチベーションの低下、いろんなことが起こり得る • でも、気楽にやろう
◦ 保険をかけて入念に事前準備をしてアドベントカレンダーに望んだりしたら疲 れてしまう ◦ 仕事でもなんでもないので、気楽にやってみよう! ◦ アドベントカレンダーじゃない月に連続投稿してみてもいい (アドベントカレン ダーの月は人が多いので、他の月のほうが見てもらいやすい) 31
完 アドベントカレンダー完⾛勢も未完⾛勢も 投稿したかたもそうでないかたも、 お疲れ様でした! みんなえらい! 32