Vision Language ModelでOCRを置き換える

 (github.com/vlm-run)
14 ポイント 投稿者 GN⁺ 2025-02-28 | 1件のコメント | WhatsAppで共有
  • このクックブックは、さまざまなケーススタディと実習を通じて動画および画像処理アルゴリズムを探究するオープンソースプロジェクトである
  • 動画推論、画像カタログ、ファッション画像のハイブリッド検索など、さまざまな応用分野を扱っている
  • 他のプロジェクトと比べて、多様な実例を通じてアルゴリズムを学べる利点がある
  • 主要ファイルとノートブック
    • 00_quickstart.ipynb: プロジェクトをすばやく開始するためのガイド
    • 01_schema_showcase.ipynb: さまざまなデータスキーマを示すケーススタディを含む
    • 02_case_study_drivers_license.ipynb: 運転免許証を認識する
    • 03_case_study_tv_news.ipynb: TVニュースの画面を理解する
    • 04_visual_grounding.ipynb: 視覚的グラウンディングアルゴリズムを探究。画像ボックス内からJSONを抽出
    • 05_case_study_image_catalogue.ipynb: ファッション製品カタログを分析し、商品説明、カテゴリ、ターゲット性別、季節を認識
    • 06_fashion_images_hybrid_search.ipynb: ファッション画像のハイブリッド検索のケーススタディ
    • advanced_finetuning_video_inference.ipynb: 動画推論のための高度なファインチューニング手法

関連記事

1件のコメント

 
GN⁺ 2025-02-28
Hacker Newsのコメント

  • 興味深いアイデアだが、まだ本番環境で使うには信頼性が不足している。従来のOCRモデルはテキストを読めないとき、低い信頼度で意味のない結果を出力する。一方VLMは読めないときでも自信満々に捏造した結果を出力し、信頼度を報告する方法がない。筆記体認識の試行では、VLMが文書の雰囲気に合った偽の名前や日付を作り出した。ソーステキストにモデルを根拠づける方法がない

  • 最近、VLMとOCRを評価するためのオープンソースベンチマークを公開したが、全体としてはVLMのほうが従来のOCRモデルより良い性能を示した

  • VLMの利点:

    • 筆記体認識。文脈理解が役立つ。つまり、文字を一つずつではなく単語や文全体を解釈する
    • チャート/インフォグラフィック。VLMはチャートやフローチャートをテキスト形式で解釈できる。色分けされた線も含まれる

  • 従来のOCRの利点:

    • 標準化された文書（例: 米国の税務フォーム）
    • 高密度のテキスト。教科書や多段組みの研究論文を思い浮かべればよい。これはOCRにとって最も簡単なユースケースだが、VLMは出力トークン数が増えるほど苦戦する
    • バウンディングボックス。非常に正確なバウンディングボックスを提供するモデルはまだ存在しない。GeminiとQwenは訓練されているが、従来モデルほどにはうまく機能しない

  • 改善の余地は大きいが、特にGeminiのようなモデルは精度/コストの面で非常に競争力がある

  • なぜすべてのOCRサービスがデジタル文書の完璧なスクリーンショットばかり見せるのか不思議だ。デジタルデータをOCRしようとする人がそんなに多いのだろうか？ ただHTMLをコピーすればいいのではないか？ デジタル文書ではないなら、折れ目、行のずれ、照明のグラデーション、指などが写り込んだスクリーンショットはどこにあるのか？

  • vlm-runとカスタムフォーム定義を試してみたが、Gemini 2.0 Flashと組み合わせると驚くほどうまく動作した。コストも低いと理解している。シンプルで中程度の複雑さのフォームで最良の結果が得られる。10分未満のトレーニングで、人間が処理できるのと同程度のフォームだ

  • OCRツールは、紙の上の文字認識など、ラベルどおりの仕事はきちんとこなす。ビジョン言語モデルを使う利点は、「これは文字列だが、タイムスタンプのように見えるか？」のようなロジックを追加できることだ

  • 私が欲しいもの: 文書（本全体を含む）をスキャン/撮影して言語モデルに渡し、元の文書と正確に一致するLatex文書を得ること。コピー機/カメラの欠陥や角度は除外する。そのための強化学習モデルは可能そうに思える。ピクセル単位で画像を再現するLatexを生成することを学習できるはずだ

  • 両方使うべきだ。OCRとLLMを使った後で両者の結果を突き合わせると、品質は大幅に向上する。文書理解や文脈だけでなく、バウンディングボックスなども得られる。「絶対に書類を書かない」アプリを作っていて、興味のある人と話したい

  • 私のプロンプトのせいかもしれないが、画像埋め込み後の解釈が多すぎるように感じる。私の例では、テキストの一部を要約し始めたが、残念ながら間違っていた。タイプされた文字のある請求書では、実際には金曜午後2時以降に提出すると次の月曜まで掲載されないと書かれていたのに、2〜3営業日は掲載されないと要約していた。これはかなり違う。こうしたレイヤーを何らかの形で取り除けるのか気になる。ワンショットの構造化テキスト検出認識は、基本的なOCRよりはるかに良かった

  • より多くの作業が進んでいるのを見るのは良いことだが、なぜこれが誰かの独占APIに縛られているのか理解できない。モデルプロバイダーの切り替えや基本的なロギング追加が、別のベンダーをオンボーディングするほど苦痛ではない。特にLLMプロンプトのような機微なものを扱う場合はなおさらだ

  • 最も高速で正確なCLI OCRツールは何だろうか？ 私のユースケースはシンプルだ。画面の一部をキャプチャし（Flameshotがこれに向いている）、OCRしたい。Zoomでペアプログラミング中にメモを取るために必要だ。今はtesseractを使っていて、速くてよく動くがミスをする。表形式を識別してASCIIやMarkdownテーブルに変換できるとありがたい。doclingも試したが、少し大げさに感じる。遅いようだ。スクリーンショットから非常に素早くテキストを取得する必要がある。デフォルト設定しか試していないが、調整すれば改善するかもしれない。これについて意見を共有してくれる人はいるだろうか？ ありがとう！