3 ポイント 投稿者 GN⁺ 2024-11-17 | 1件のコメント | WhatsAppで共有
  • 文書画像をテキストに起こしてから再整理する作業を、構造化されたMarkdown変換によって減らせるウェブツール
  • 現在のウェブ入力は画像アップロードが中心で、PDF対応はまもなく提供予定と案内している
  • サービスは npm パッケージ llama-ocrTogether AI を基盤に動作する
  • JavaScript では ocr 関数に filePathTOGETHER_API_KEY を渡して Markdown の結果を受け取れる
  • ウェブアップロードとコード呼び出しの両方をサポートし、文書画像の変換を手作業にも開発フローにも合わせて試せる

画像ドキュメントをMarkdownに変換

  • LlamaOCR.com は、アップロードしたドキュメントを Markdown に変換するツール
  • ウェブページでは「Upload an image to turn it into structured markdown」と案内しており、画像アップロードで 構造化されたMarkdown を生成する
  • PDF対応 は「soon」と表示されており、現在の提供範囲は画像中心

コードで使う方法

  • npm パッケージ llama-ocr を使うと、JavaScript コードから OCR を実行できる
import { ocr } from 'llama-ocr';

const markdown = await ocr({
  filePath: './trader-receipt.jpg',
  apiKey: process.env.TOGETHER_API_KEY
});
  • 例では filePath に画像ファイルのパスを入れ、apiKeyTOGETHER_API_KEY 環境変数を渡す
  • サービスは llama-ocrTogether AI を基盤としている

1件のコメント

 
GN⁺ 2024-11-17
Hacker News のコメント
  • llama-ocr を作った者です。共有してくれて、また好意的な反応に感謝します。シンプルな OCR API が必要だったので今週初めに作りました。Together.ai でホストされている Llama 3.2 Vision を使って、画像を構造化された Markdown にパースします
    npm パッケージとしても提供しています。PDF パースや JSON レスポンスなどの機能も追加する予定で、質問があれば答えてみます

    • 同じ項目が3つある請求書を入れたところ、いつものように箇条書き3つとして出力するのではなく、元の紙にはない quantity 列を持つ表を作り出しました
      この程度の大きな変換が、想定された、あるいは望ましい挙動なのか気になります。出力があるときは箇条書きリストで、あるときは表になるので、その後の自動処理が少し難しくなります
    • ポスター PDF から科学コンテンツを抽出するのに苦労していて、たとえば Nougat はレイアウトが変わると崩れることがよくありました
      こうしたユースケースも考慮したことがあるのか気になります
    • 「Need an example image? Try ours.」は良いアイデアです。もっと多くのサービスが同様の機能を提供してくれるといいですね
    • 精度がどの程度なのか気になります
      既存の OCR システムと比べて、どのような種類のミスをするのか知りたいです
    • ローカル LLM を使うオプションも可能なのか気になります
  • これは画像を Llama 3.2 Vision に送って、テキストを読んでくれと頼んでいるだけです
    他の LLM の出力と同じく、幻覚に弱いです。ピクセルから文字の形を読んでいるのではなく、学習した画像とキャプションをもとに絵を説明しながらテキストを判断しているからです。特に読みにくい場合は、単語を完全に作り上げることがあります

    • 他の OCR システムでも同じことはありました。ただ、この文脈ではそうした誤りを 幻覚 と呼んでいなかっただけです
  • 良さそうに見えます。最近 OCR をよく使っているので、この分野に新しいツールが出てきたのはうれしいです。PDF→Markdown 分野の現在の有力候補はおそらく Facebook の Nougat[1] で、これを DSPy につないで哲学書ではどちらが優れているか比較してみたいです
    このリポジトリがリンクしているスタートアップの Zerox[2] プロジェクトも良さそうで、少なくとも Nougat より宣伝はずっと洗練されています。実際の専門家が通りかかったら、訂正や助言を聞きたいです
    気になる点は2つあります。1) Together.ai とは何で、このモデルはオープンソースなのか知りたいです。Webサイトはホスティングサービスのように見え、「Custom Models」ページ[3]は独自のプロプライエタリモデルの学習というより、カスタム微調整に近いように見えます。HuggingFace のプロフィールがあるようですが、本当に彼らのものなのかは曖昧です https://huggingface.co/TogetherAI
    2) GitHub には「hosted demo」とありますが、ホストされている部分は小さくてきれいな WebGUI だけのように見えます。この機能は今も今後も API 呼び出しでしか使えないという意味なのか気になります
    追伸: デスクトップブラウザではヘッダーリンクが壊れていて、onClick がトリガーされません
    [1] https://facebookresearch.github.io/nougat/
    [2] https://github.com/getomni-ai/zerox
    [3] https://www.together.ai/products#custom-models

    • プロジェクト作者は Together.ai DevRel です。それでも開発者ツールを宣伝するやり方としては見事です
    • together.ai がデモを少なくとも一部支援しているのだと思います
    • プライバシー保護とコストのため、セルフホスト できるものを期待していました
    • together.ai は、マルチモーダル Llama 3.2 を含む 100以上のオープンソースモデル を OpenAI 互換 API で提供しています
  • 変わった点がありました。例としてWebコミックをアップロードしたのですが、すべてのセリフが大文字だったにもかかわらず、出力はパネルごとに文頭だけ大文字の表記とタイトルケースが一貫せず混在していました
    実際に OCR を使いたい問題も試してみました。デジタル化が必要な古いスライドがあり、その多くにラベルが付いています。1つアップロードすると、スライドまたはフィルムフレーム写真のように見える、古くて黄ばんでおり中央に暗い長方形の切り抜きがあり、テキストは「Once Upon a Time」、数字は「1069」だと説明されました
    不要に反復的なスライド説明も問題ですが、実際の文字は筆記体でもなく「Once Uniquitous.」で、数字は 106g でした。「9」ではなく「g」であることは非常に明確でした
    興味深いのは、モデルのバイアスの一例かもしれない点です。スライドを古物のように見すぎた結果、完全に陳腐なタイトルを幻覚し、黒い四角形は透明部分が見えないよう前から光を当てた結果だったのに、それを見落としていました
    さらに API 自体に、文書化されていないファイルサイズや解像度の制限があるようです

  • 最近、チャリティオークション用の紙の入札シートを処理するのに llama3.2-vision を使ってみましたが、かなりひどい手書き文字でも相当正確でした。来年のイベントでも使いたいです
    ただし CSV を一貫して出力させるのが難しい点はかなり面倒です。ChatGPT と Gemini はその部分ではもっと良さそうに見えますが、自動化までは試していません
    規模は入札シート約100ページなので、ある程度の手作業での整理は許容できます。ボランティアの時間を費やすよりは明らかにましです
    https://github.com/philips/paper-bidsheets

    • この作業で Handwriting OCR(https://www.handwritingocr.com) がどの程度比較対象になるのか聞いてみたいです
      無料ではありませんが、手書き文書の精度は最高水準です。私が創業者なので偏りはありますが、現在の精度レベルには本当に期待できます。100ページのプロジェクトなら12ドルしかかからず、時間を節約できます
    • OCR 部分は llama3.2-vision に任せて、CSV 変換 は ChatGPT に渡す形はどうでしょうか
  • 最近OCRをかなり使っていて、主に家族写真の中のテキストをデジタル化する作業だった。一般的なOCRモデルはひどく、LLMのほうがずっとよかった。試したモデルの中では Gemini Flash が圧倒的によかったが、それでも失敗やハルシネーションが十分多く、手で入力したほうが速かった。
    もう少しでうまくいきそうに感じるのに、できないのが腹立たしい。このツールはもっと悪そうに見える。あるときはテキストだけを返し、別のときは「The image is a scanned document with handwritten text...」のような全体説明を返す。Gemini Flashに勝てるようなファインチューニングなどがあることを期待していたが、そうならかなり時間を節約できただろうに残念。

    • 画像を ダウンスケールしてみたのか気になる。低解像度の画像でより良い結果が出始めた。スマートフォンのカメラで作ったスキャンを使った。
      convert -density 76 input.pdf output-%d.png
      https://github.com/philips/paper-bidsheets
    • 一般モデル基準では、オープンソースOCRの状態はかなりひどい。残念ながらMicrosoftやGoogleのような非公開オプションのほうがずっとよい。そういうものも試したのか気になる。
      Flashは興味深いが、どのLLMをテストしたのかも知りたい。
    • 最近 gpt-4o で画像コーパスにOCRをかけ、かなり良い結果を得た。最も重要だと気づいたのは、派手なLLMを使っても、地味なデータ準備は依然として重要だということ。
      画像をテキスト部分だけが残るように切り抜き、枠線を除いてからコントラストを上げたところ、非常に役立った。2015年に書いた記事だが、GPTにも今なおよく当てはまる: https://www.danvk.org/2015/01/07/finding-blocks-of-text-in-a...
      GPTにはページ全体を一度に渡すより、数段落以下だけ渡すほうがよかった。テキストが短いほどハルシネーションの可能性は下がる。
    • 自分も今まさに同じことをしようとしているので残念。家族写真をデジタル化していて、一部は裏面にドイツ語がある。
      最近話題になったOCRはひどく、これはもっと良いことを期待していた。個別画像をチャットに貼り付ける場合は ChatGPT 4o がよかったが、APIはまだ使っていない。6500枚の写真を処理すると費用がどれくらいかかるのか分からないし、その中には空の写真も多いが、簡単に除外する方法もない。
    • Claude を試したのか気になる。
      テキスト位置を返すのはまだ良くないが、自分がテストした範囲ではOCR性能はすごかった。
  • これが「Show HN」投稿であるべきなのか疑問。単なるフロントエンドに見えるし、名前の Llama と直接結び付けられる部分もなさそう。together.aiがクラウド空間を提供した可能性はあるかもしれない。

  • 遺伝的アルゴリズムで円を500個配置して文章を作り、実際の物理的な円で描いた文章を入れてみた。
    https://www.instagram.com/marekgibney/p/BiFNyYBhvGr/
    興味深いことに、円はよく認識するが文章は見えない。「画像にはMarkdownで表現できるテキストや要素はなく、円の視覚的な構成にすぎず、Markdownに翻訳する情報はない」というように返答した。

    • 目を細めると読めるという点に着目して画像に ガウシアンブラーを適用したところ、ぼやけたテキストが「STOP THINKING IN CIRCLES.」と読めるという応答を得た。
      応答は決定的ではないので元画像も何度も試したが、一度も成功しなかった。一方で、適用したすべてのローパスフィルター効果は高い成功率で機能した。
      https://imgur.com/q7Zd7fa
    • 自分にもこれは読めない。
      遠くから見るともっと読みやすい。
    • そもそもLLMがこうした 元素材で学習されたことがあったのだろうかと思う。
      遺伝的アルゴリズムの使い方はかなり格好いい。コードか、少なくとも報酬関数を見てみたい。
    • 正解を見る前は、自分も「stop」以外は何も読めなかった。
    • 何が興味深いのか分からない。画像は何にも見えないし、文字を見るには角度を変えてようやく見える程度だ。
  • 笑った。長い文書のスクリーンショットを3枚入れたところ、比較的うまく処理したが、校正してみるとAIが原文にない段落を作り出していた。
    おそらくスクリーンショットの性質上、一部の文や段落が途中で切れていて、それがLLMの 穴埋め傾向を刺激したのだと思う。終わっていない段落をそのままにしておけず、元の文書にはまったくなかった短い結論段落まで入れていた。

    • 何かを でっち上げる可能性が少しでもある技術が、現実世界で使用対象として検討されることが理解できない。
  • 1997年のAsus P3B-Fマザーボード回路図の古いスキャンを入れてみた。
    タイトルブロックの一部テキスト、例えばプロジェクト名と日付くらいしか抽出せず、フォントははっきりしているのに8/Bと1/Iをすべて混同していた。
    実際に有用な情報は「Tables / Table 1: [Insert table 1 here] / Other Elements / [Insert other elements here]」のようなものに変わっていた。