ハクソク

世界を動かす技術を、日本語で。

Llama-Scan: ローカルLLMを用いてPDFをテキストに変換する

281日前原文(github.com)

概要

llama-scan は、PDFファイルをテキストへ変換するローカルツール。 Ollamaの最新マルチモーダルモデル に対応し、画像や図表も詳細なテキスト化が可能。 Python 3.10+とOllama のインストールが必要。 インストールや使い方は pipまたはuv 経由で簡単。 多彩なオプションで柔軟なPDF処理が実現。

llama-scan 概要

  • PDFファイル をローカル環境で テキストファイル に変換するツール
  • Ollama の最新マルチモーダルモデルに対応
  • 画像や図表 も詳細なテキスト説明へ変換
  • トークンコスト不要、完全ローカル処理
  • Python 3.10以上 と Ollama のインストールが必須

必要環境

  • Python 3.10以上 のインストール
  • Ollama がローカルでインストール・起動済みであること

Ollamaとデフォルトモデルのインストール

  • Ollama のインストール
    • 公式サイトからダウンロード・インストール
  • デフォルトモデル の取得
    • コマンド：ollama run qwen2.5vl:latest

llama-scan のインストール

  • pip でのインストール
    • コマンド：pip install llama-scan
  • uv ツール経由でのインストール
    • コマンド：uv tool install llama-scan

基本的な使い方

  • コマンド例：llama-scan path/to/your/file.pdf
  • 主なオプション
    • --output, -o：出力ディレクトリ（デフォルト: "output"）
    • --model, -m：使用するOllamaモデル（デフォルト: "qwen2.5vl:latest"）
    • --keep-images, -k：中間画像ファイルの保存（デフォルト: False）
    • --width, -w：画像リサイズ幅（0でリサイズ無効、デフォルト: 0）
    • --start, -s：開始ページ番号（デフォルト: 0）
    • --end, -e：終了ページ番号（デフォルト: 0）

使用例

  • 特定ページのみ処理し、画像幅を指定
    • コマンド：llama-scan document.pdf --start 1 --end 5 --width 1000
  • 別のOllamaモデルを利用
    • コマンド：llama-scan document.pdf --model qwen2.5vl:3b

Hackerたちの意見

ほぼ完璧だった！テストしたPDFでは、いくつかの記号だけが抜けてたけど、これは絶対に使うよ。ありがとう！

└

それ聞いて嬉しい！どんな記号が抜けてたの？

コードを見た感じ、PDFページを画像に変換して、その画像をテキストにしてるみたい。pdftotextの後処理があると思ってたけど、PDFの複雑さってこういうことなんだろうね…

└

ocrmypdfっていうすごく人気のあるPythonモジュールがあるよ。これを使って、俺のHOAの古いPDFをOCRしたんだ。https://github.com/ocrmypdf/OCRmyPDF LLMは必要ないよ。

└

シェル: GNU parallel、pdftotext Python: PyPdf2、PdfMiner.six、Grobid、PyMuPdf; pytesseract (C++) paperetlはgrobidを基にしてる: https://github.com/neuml/paperetl annotateai: https://github.com/neuml/annotateai : > annotateaiは大規模言語モデル（LLM）を使って論文を自動的に注釈付けする。LLMは論文を要約したり、検索したり、生成的なテキストを作ったりできるけど、このプロジェクトは読者に文脈を提供することに焦点を当ててる。 pdf.js-hypothes.is: https://github.com/hypothesis/pdf.js-hypothes.is: > これはMozillaのPDF.jsビューワーのコピーで、Hypothesisの注釈ツールが追加されてる。HypothesisはW3CのWeb Annotations仕様に基づいてる。 dokieliはW3CのWeb Annotationsや他の多くのLinked Data仕様を実装してる: https://github.com/dokieli/dokieli : > バージョン管理を実装していて、不変リソースの概念がある。 > データブロックを埋め込む、例えば、Turtle、N-Triples、JSON-LD、TriG（ナノ出版物）。LLMへのdokieliドキュメントインターフェースは基本的に反PDFになるだろうね。 Rustクレート: rayonは並列処理を扱い、pdf-rs、tesseract (C++) pdf-rsの例/src/bin/extract_page.rs: https://github.com/pdf-rs/pdf/blob/master/examples/src/bin/e...

└

問題の一部は、PDFがただの画像の連続になってることだと思う。

└

この前見たツイートが、PDFのパースがどれだけクレイジーか理解するのに役立ったよ。https://threadreaderapp.com/thread/1955355127818358929.html

└

画像ベースの抽出は、レイアウトを保持し、埋め込まれたフォントやスキャンしたコンテンツ、セキュリティ制限のあるPDFを直接テキスト抽出よりも上手く扱うことが多いよ。

1990年にはOmnipage 3とその後継が「十分に良かった」し、コンパクトな辞書と文字認識で当時の奇跡だったんだ。2025年にはLLMがメモリのトリロバイトとペタフロップスを使って「偽装」できるようになる。実際、すごく面白いよね、超コンピュータが本当に速いジャカード織機でリアルタイムにエミュレートされてるみたい。2027年には、シンプルな手持ち計算機の足し算でもキロワット時で請求されるようになるだろう。

└

トリロバイト？あれは本当に原始的なコンピュータだったね。

└

1990年代のOCR、いや2000年代のOCRが現代のOCRと同じくらい良いと思ってるなら、売るものがあるよ。

└

ちょっと前に、Pixivからランダムな簡単な日本の漫画（4コマを考えてるけど、実際には4パネルじゃなかったと思う）をGemma 3bに投げ込んでみた。

  • すべてのテキストを転写してくれたよ。セリフや物のラベル、アクションのオノマトペなんかもね。 転写の中で一つのかながダイアクリティカルマークを欠いてるのに気づいたけど、全体的にはかなり近い感じだった。 漢字は全部正しく見えたし、ラテン文字はすでにOCRが得意だけど、他の言語は経験上ちょっと苦労することが多い。
  • それに、特に促さなくても、かなりシンプルな日本語を正しく英語に翻訳してくれた。 専門家じゃないけど、翻訳は良さそうに見えたよ。 Gemini 2.5も同じことをして、少し違う翻訳だったけど、機能的には同じで、Google翻訳に似てた。
  • それに、ジョークやオノマトペの説明もしてくれた。 私が確認できる範囲では正しかったけど、日本の漫画で使われるアクションのオノマトペは結構多様で、必ずしもすごく文書化されてるわけじゃないから、文脈的には合ってるように見えた。 これは面白いと思う。モデルを擬人化したくはないけど（少なくとも不当に）、こういうことを手書きの日本語テキストがある任意の画像でできるGemmaのような比較的小さなローカルモデルがあるのは良い兆しだと思う。 従来のOCRは、英語以外のテキストやスタイライズされた/手書きのテキストを見つけたり認識したりするのが苦手で、文脈の手がかりや自分の「理解」を使って読めない部分を補うことができない。 せいぜい基本的な統計を利用することができるけど、それだけでは人間のような熟練度には達しない。 でも、vLLMは埋め込まれた知識の量で明らかに優位性があって、その知識を使ってあいまいさを切り抜けることができる。 これが彼らを近づけていると思う。 OCRのタスクにvLLMを使うことを何度か試してみたけど、正直言ってTesseractのような従来のオプションにはあまり感心していない。 場合によっては、転写したいテキストを見つけるのにかなりの助けが必要だから。 AIのハイプの中で、画像認識と転写のユースケースはほぼゼロに近い。 ここでは本当に役に立つよ。 いくつかの研究では、vLLMが「盲目」であることが示されている（例えば、猫に余分な足をPhotoshopで加えて、その動物が何本の足を持っているかを尋ねると失敗することがある；この場合、モデルのトレーニングデータからの先入観が逆に働く）。 他にもいくつかの制限があると思う（一般的にAIを転写に使うと、認識されているものの空間情報を得るのが難しいけど、画像を再帰的に切り分けてバウンディングボックスを洗練させるためにフィードする技術が適用されていると思う）。 でも、実際に機能する程度は、私の正直な意見としては非常に印象的で、すでに非常に役に立つと思う。 これが基本的なPDF転写、特にきれいにスキャンされた文書には大きなMLモデルが本当に必要だとは思わないけど、 一方で、大きなMLモデルはここで簡単なタスクと難しいタスクの両方をかなりうまく処理できると思う。 個人的には、こういうことにもっと取り組んでほしいな。 もし信頼性が高くなれば、アクセシビリティや言語の壁を打破するのに驚くほど役立つだろう。 機械翻訳は、画像でどれだけうまく機能するかに関しては伝統的に少し限界があったけど、Geminiや驚くほどGemmaもこれらのタスクを簡単にこなせることが多い。 これらのモデルが非効率的だというのには同意するよ。 従来のOCRを除けば、私たちの脳も似たようなタスクをこなすけど、電力をあまり消費せず、明らかに必要なトレーニングデータ（少なくともテキストは）も少なくて済む。 これらのタスクを今の精度でこなせるより効率的な機械を作ることは物理的には可能だと思う。

これが良いものになることを本当に期待してたんだけど、残念ながらテーブルが含まれているページを変換したら、変換器がうまく処理できなくて、「! Picture 1:」だけのページができちゃった。それに加えて、25ページのドキュメントの17ページでフリーズして、全然動かなくなった。

└

ここでの著者だけど、それは残念だね。ローカルで再現してみたいな。PDFを共有してもらえる？

今日、iPhoneで撮った写真から60ページの密な紙のドキュメントをMarkdownに変換しようとしてるんだけど、これが一番いい方法じゃないのは分かってる。でも、最新のクラウドモデルでも多くのページを処理するのが難しいってことに驚いてる。ハルシネーションが多かったり、「テキストが見えない」って言われたり（写真は完璧にクリアなのに）。いろんなモデルを試したり、LLMと昔ながらのOCRを切り替えたり、自分で間違いを読んで直したりしてる。手動で全てを書き起こすよりは早いけど、技術がもっと進んでると思ってた。

└

これを試してみて: https://github.com/rednote-hilab/dots.ocr

ちょっと関係ないかもしれないし、せいぜい想像力のある愚痴かもしれないけど、PDFを解析するための中途半端な解決策や特定のユースケースに近い完璧なものはたくさんあるよね。これはその一つとして素晴らしい追加だと思う。ただ、ここ2年間でPDFを解析するための多くのユースケースに出会ったけど、それぞれ異なる要件がある（例えば、タイトルを特定したり、ページ番号を削除したり、特定のセクションを抽出したり）。それぞれに違ったアプローチが必要なんだ。要するに、これは素晴らしいけど、HTMLやXML、JSON、その他無数のフォーマットがある中で、PDFをあまり使わないようにするための広範な取り組みが必要なんじゃないかと思う。大変なことだとは思うけど、より良い技術のために古い技術（例えばファックス）を捨てることは珍しくないよね。

└

その船はもう出航しちゃったね。ここにいるほとんどの人も同じ状況だと思う。お客さんが送ってくるファイルを選ぶことはできないから、彼らのいるところに合わせるしかない。

└

LLMがPDFを「読む」目的では、ただの画像としてレンダリングされるだけなんだ。ファイル形式は関係ない。既存のドキュメントがあるとしたら、テーブルや図を扱える堅牢なOCRソリューションは非常に価値があると思う。

「画像や図を詳細なテキスト説明に変換する。」私は、画像や図がそのままコピーされて、Markdownのような一般的なフォーマットで表示される方がいいな。

PDFからMarkdownへのワークフローをやったことがあるよ。各ページについて：

  • 普通にテキストを抽出。
  • ページ全体を画像としてキャプチャ（約200 DPI）。
  • 必要に応じて、ページ内の画像やグラフを抽出して、同じLLMコールに含める。
  • 隣のページから少しコンテキストを追加するのもオプション。 それをすべて明確なプロンプトでラップして（構造化された出力＋グラフの扱い方）、準備完了。今はGPT-5-nano/miniやGemini 2.5 Flashみたいなモデルが安くて強力だから、これが実用的になってる。そう、ちょっと蚊にロケットランチャーを使うみたいだけど、実際には実装が簡単で、かなり柔軟でパワフルだよ。ほぼどんなフォーマットでも動くし、MarkdownはAIにも人間にも優しいし、意外とメンテナンスもしやすい。
└

安くて強力だから、これが実用的になってる。必要なスケールによるけど、APIを使えば何も考えずに数百万のトークンを生成できるよ。

Ollamaを使ってPDFを整理する似たようなプロジェクトがあったよ。 https://github.com/iyaja/llama-fs

重要な情報が欠けてる - 他のOCRプロバイダーとの精度比較。私の経験では、LLMベースのOCRはレイアウトを誤読したり、値を幻覚したりすることがある。これは非常に微妙だけど、時には致命的に間違っていることもある。従来のOCRは精度が高いけど、レイアウトは全く把握できない。両者を組み合わせると他の問題が出てくるし、どのアプローチも100%信頼できるわけじゃない。

└

ページを分割して、パーツを一つずつ読み込んで出力を再構成するのが助けになるんだよね。これを期待してたんだけど、結局はページ全体しか読み込めないみたい。

└

そういえば、前にCVを読むためにLLMを使ってみたんだけど、重要な情報を省かれちゃってすごく苦労したよ。

└

最近これを評価した？去年や今年の初めにはほぼ同意してたと思うけど、今はちょっと違うかな。少なくとも私が扱っている文書に関しては、GPT5やMistral OCRのOCRの信頼性が、従来のドメイン特化型OCRよりもずっと良くなってる。文書のレイアウトがちょっとでも複雑だと（ページ番号や見出し、珍しいフォントのことは言わずもがな）、最新のLLMの精度は私の作業では桁違いに高いよ。特にドイツ語の文書を扱うときに、ページをまたいで文を仮に組み合わせる能力は本当に貴重だね。

└

スキャンしたPDFを取り込んで、OCR処理したテキストをスキャンの上に重ねて、テキストが検索可能になるツールってある？