- 今回作ったのは加法注意に相当する
- これが内積注意に変わるとどうなるか？
- 次元削減注意の有用性を確かめる実験をしたい
- 当初構想していたネットワーク
- でもこれ[類似度]ベースの構造
- 「似てる」と「次に来そう」の違いで書いたように、類似度ベースにしないことが有益な可能性がある
- 類似度ベースでないように書き換えるとこうなる
- Keyを作るためのレイヤーと「直近のスライドから、次に来るスライドのqueryを作るレイヤー」は全く別物
- これは現状たまたま1ページのスライドを入力として受け取っているので似た形だから混同されていた
- 文脈を表現するのが「直近1ページ」である必然性はないよね
- 不定長の「ページ」を受け取って固定長のベクトルに変換するなら自己注意かな
作ったシステムの不便な点
- PDFをまずCUIで処理しなきゃいけない
$ ruby pdfs_to_onepage_json.rb in/未来の検索技術.pdf > hackathon.json
- Pythonの方が得意なのにRubyのGyazoクライアントを使っている増井先生のコードからforkしたのでRubyで実装されている
- PDFからpdftocairoでJPEGに変換しているのでKeynoteから作られたPDFみたいな文字情報が本来含まれているものまで画像化されてる
- 本当は文字情報を持っているPDFはそれも使える方が良い
- Gyazoの(内部でGoogle Vision APIを叩く)OCRによって文字列化される
- 意外なことだが、大きい文字はOCRされない(多分文字にマッチしそうなところを探すウィンドウサイズの上限のせい)
- グラフや表のスクリーンショットを貼り込んでいるようなケースで、その画像の中の文字列もデータとして扱えるのはOCRの長所
- ただしグラフや表の数値が全部入力データに含まれてしまう
- 人間は「大きい文字は重要」「小さい文字は重要ではない」と自然に判断できるがOCRするとその情報が失われる
- Gyazoへのアップロード、Gyazo側やネットワークの調子によっては失敗する、1秒1枚でアップロードするので割と待ち時間がある
- OCRがGyazoサーバ側で非同期で走っているので完了タイミングは読めない
- 出来上がったJSONファイルを手作業でインポートしなければならない
- これは自動化もできるけど、僕のログイン情報をクッキーから取り出してリクエストに積む必要がある
- OCRが取れなかった場合にリトライしていないので失敗した時にOCR情報のついていないJSONが出力される
- OCR情報がついてないことにScrapboxに手動でインポートしてから気づく
どうであるべきなのか
- MacならAutomatorでCUIスクリプトをキックできるので、それをFinderの「よく使う項目」に入れておけば良い
- PDFをドラッグドロップして起動できる
- 大きい文字の含まれた画像、縮小したらOCRされるようになる？
- なるなら、スライド画像を縮小してからOCRすれば小さすぎる字が適切に潰れ、大きな文字が認識されるようになる
- Rubyで頑張るかPythonに移植して頑張るかして、エラー時のリトライをする
- Scrapboxに個人用非公開のプロジェクトを作っておき、そこへのインポートまで自動でやる
- 全部終わってから通知する(人間が過程を見てなくて良いように)