Show HN: RAG向けのオープンソース・ルールベースPDFパーサー

 (github.com/nlmatics)
1 ポイント 投稿者 GN⁺ 2024-01-26 | 1件のコメント | WhatsAppで共有
  • nlm-ingestor は llmsherpa API が接続して利用するサービスコードで、RAG 向けに PDF・HTML・Text・DOCX・PPTX などの文書パーサーを提供する
  • PDF パーサーは nlmatics の改変版 Tika から得たテキスト座標、グラフィック、フォントデータを使用し、スキャンページがある場合は apply_ocr オプションで OCR を自動適用できる
  • PDF 処理機能には、セクション・サブセクションレベル、段落結合、セクション-段落リンク、表、ネストされたリスト、ページ間コンテンツ結合、繰り返しヘッダー・フッター除去、ウォーターマーク除去、OCR バウンディングボックスが含まれる
  • モデルベースのビジョンパーサーと比べて、ルールベースパーサーは PDF ページ画像を生成する必要がないため 100倍高速 だと説明しており、OCR ではないテキストレイヤー PDF や数百ページの文書でより実用的だとしている
  • 開発用サーバーは Docker または直接実行で起動でき、本番環境では nginx やクラウドゲートウェイのような セキュリティゲートウェイ の背後で実行する構成が推奨される

nlm-ingestor が提供する文書パーサー

  • nlm-ingestor は llmsherpa API が接続できるサービスコードのリポジトリ
  • RAG（retrieval augmented generation）向けにカスタムパーサーを複数のファイル形式へ提供する

    • PDF

    • HTML

    • Text

      • DOCX、PPTX、Apache Tika がサポートするその他の形式

PDF パーサーの動作方式と機能

  • PDF パーサーはルールベースで、nlmatics の改変版 nlm-tika から取得した テキスト座標、グラフィック、フォントデータを使用する
  • PDF テキストレイヤーを基盤として動作し、apply_ocr オプションにより PDF にスキャンページがある場合は OCR を自動適用できる
  • OCR 機能は内部的に tesseract を使う nlmatics の改変版 Tika に基づいている
  • PDF パーサーを直接試せるノートブックとして pdf_visual_ingestor_step_by_step が提供されている
  • PDF パーサーの機能は次のとおり
    • セクションとサブセクション、および各 レベル の識別
    • 複数行を結合して 段落 を構成
    • セクションと段落の間のリンクを生成
    • 表と、表が見つかったセクションの識別
    • リストとネストされたリストの処理
    • ページをまたぐコンテンツの結合
    • 繰り返し現れるヘッダーとフッターの除去
    • ウォーターマークの除去
    • OCR 結果に対するバウンディングボックスの提供

HTML・Text・Office 文書処理

  • HTML パーサーは RAG 性能を高めるため、より高品質なチャンクを作れるよう レイアウト認識ブロック を生成する
  • Text パーサーは視覚情報、フォント情報、バウンディングボックスなしでテキストだけを見て、リスト、表、ヘッダーなどを推定する
  • DOCX、PPTX および Apache Tika がサポートするその他の形式は、Tika の HTML 出力 を使ったあとに HTML パーサーで処理する

実行と API 利用

  • 直接実行の手順は、Java のインストール、Tika サーバーの起動、nlm-ingestor のインストール、ingestor の実行で構成される
    • Tika サーバー起動: java -jar <path_to_nlm_ingestor>/jars/tika-server-standard-nlm-modified-2.9.2_v2.jar
    • インストール: pip install nlm-ingestor
    • 実行: python -m nlm_ingestor.ingestion_daemon
  • 公開 GitHub Container Registry に Docker イメージが提供されている
    • イメージ取得: docker pull ghcr.io/nlmatics/nlm-ingestor:latest
    • 実行例: docker run -p 5010:5001 ghcr.io/nlmatics/nlm-ingestor:latest-<version>
  • サーバー起動後は llmsherpa API ライブラリでチャンクを取得し、LLM プロジェクトに利用できる
  • llmsherpa_url の例は http://localhost:5010/api/parseDocument?renderFormat=all
    • OCR 適用: &applyOcr=yes
    • ヘッダーレベル割り当てに別のアルゴリズムを使う新しい indent パーサーの利用: &useNewIndentParser=yes
  • 開発用サーバーとしては使えるが、本番環境では nginx やクラウドゲートウェイのような セキュリティゲートウェイ の背後で実行する構成が推奨される
  • llmsherpa パーサーでサーバーをテストするサンプルコードは test_llmsherpa_api ノートブックにある

ルールベースパーサーを選んだ理由

  • nlmatics チームは 4 年間にわたり、Tom Liu と Yi Zhang が開発した YOLO ベースのビジョンパーサーを含む複数の選択肢を評価したうえで、ルールベースパーサー を選択した
  • ルールベースパーサーはどのビジョンパーサーよりもかなり高速で、リポジトリ説明ではこれを 100倍高速 と表現している
    • ビジョンパーサーは、テキストレイヤーがある PDF でもすべてのページ画像を生成しなければならない
    • ビジョンパーサーは、テキストレイヤーのない OCR PDF やフォームデータで構成された小さな PDF ではより良い選択肢になる可能性がある
    • 数百ページに及ぶ大きなテキストレイヤー PDF では、ルールベースパーサーのほうがより実用的だと見ている
  • PDF OCR 機能を使わないなら、特別なハードウェアは不要
    • リポジトリ説明では 2000 年代初頭のハードウェアでも実行できるとしている
  • ビジョンパーサーを含むすべてのパーサーでエラーは起こり得るが、モデルベースパーサーのエラー修正方法には満足できなかったと説明している
    • 学習セットに例を追加すると、以前の学習精度が落ち、既存で動いていたコードが不確実になる可能性がある
    • モデルベースパーサーの問題をルールベースのアイデアで修正すると、結局また多数のルールを書くことになる

nlmatics の改変版 Tika

  • nlmatics の改変版 Tika は 2.4.1-nlm ブランチ にある
  • 便宜のため、コンパイル済み jar ファイルがリポジトリの jars/ フォルダに含まれている
  • 一部の PDF では Java サーバーでエラーが発生することがあり、その場合は該当コードを修正して jar ファイルを再コンパイルする必要がある
  • 変更されたファイルは、各 PDF テキスト要素に フォントと座標 を追加し、ウォーターマークを除去する
    • PDF2XHTML.java
    • AbstractPDF2XHTML.java
  • GraphicsStreamProcessor.java の変更は、表検出に役立つ 線と矩形 を追加するためのもの
  • 変更の影響は pdf_visual_ingestor_step_by_step ノートブック前半で確認できる
  • 今後の作業アイデアは次のとおり
    • pdfbox 上に独自ラッパーを書き、Tika 変更への依存をなくす
    • 最新の Tika バージョンへアップグレードする
    • 返される HTML 形式をより CSS フレンドリーに整理する

関連記事

1件のコメント

 
GN⁺ 2024-01-26
Hacker News のコメント

  • 科学論文を扱うなら GROBID も追加する価値があります: https://github.com/kermitt2/grobid
    paperetl(https://github.com/neuml/paperetl) と一緒に使っています

  • 良いプロジェクトです。ドキュメント解析には、成熟度が高く対応形式も幅広いので、長年 Tika を使ってきました。XHTML 出力は RAG 向けのドキュメント分割に役立ちます
    例としては https://neuml.hashnode.dev/build-rag-pipelines-with-txtai と https://neuml.hashnode.dev/extract-text-from-documents があります
    ちなみに txtai(https://github.com/neuml/txtai) の主な作者です

    • 少し話題から外れますが、Tika が他の PDF 解析ライブラリと比べてどうなのか気になります
      pdfminer.six（unstructured が使っているもの）はレイアウト検出がかなり基本的で、複数段組みテキストの解析に失敗したので期待外れでした。一方 MuPDF は完璧に処理しました
      今は MuPDF + AWS Textract（主に表）を組み合わせて使っていますが、他の人が何を使っているのか知りたいです

  • かなり役に立ちそうです。私が働いている会社には、PDF を読み込んで意味的な差分を比較する PDF 比較ツール「PDFC」があります: https://www.inetsoftware.de/products/pdf-content-comparer
    PDF 形式は非常に複雑なので、解析はかなり厄介になり得ます。私たちはすでにこうした機能の大半をサポートしていますが、エッジケースは常に多いので、追加のアプローチは役立つ可能性があります

  • Tesseract OCR フォールバックは良さそうです
    今では RAG 向けのファイルローダーは langchain、LLMindex、unstructured など数多くありますが、これを選ぶ理由があるのか気になります。例えばベンチマークスコアで上回っている、といった根拠があるのでしょうか

    • このツールは Apple Silicon でビルドできず、ARM Docker イメージもないので、実際には試せていません
      ただ、PDF 解析用途でそうした RAG ツールを使ったことがありますが、出力品質はかなり低かったです。LLM が問題をある程度回避してくれるので RAG としてはそれなりに動きますが、適切な参照付きのより高品質な回答が欲しいなら、ルールベースのパーサーを自分で使うのが最善だと思います。結局私もそうしました。ただし Tika ではなく MuPDF ベースでした
      このツールの作者たちも似た考えだったのかもしれません
    • 最後に Langchain を使ったときは、確か約6か月前ですが、PDF と HTML ファイルからコンテンツ抽出する実装は非常に基本的でした
      RAG のプロトタイプを回すには十分でしたが、信頼できるものを作るには不十分でした。このプロジェクトは、はるかに実運用で検証された実装のように見えます

  • 素晴らしい仕事で、とても興味深いです。ただ GitHub に行くと “This organization has no public members” と表示され、あなたたちが誰なのかまったく分からず、非公開のままこの中に他に何が含まれ得るのかも分かりません
    全体として、「名前のない隠れたグループが $CORP のセキュリティサイトに置いたもの」と、従来の紹介・信頼構築の方法との間に、時間をかけて識別と信頼を築ける中間地点が必要だと思います

  • LLM/RAG プロジェクトで最適なチャンクを得るには、このサーバーを llmsherpa LayoutPDFReader と組み合わせて使えばよいです: https://github.com/nlmatics/llmsherpa
    リポジトリの例とノートブックを見るとよいです

  • サンプルの入力・出力ペアがどこかにあるのか気になります

  • これで数百個の PDF を解析してみましたが、結果はかなり良かったです。Julia で開発されていれば、少なくとも10倍は速かったと思います

  • これが Azure Document Intelligence とどう違うのか、あるいは実質的に同じものなのか気になります

    • 同じことをしているわけではありません。ほとんどのクラウドパーサーはビジョンモデルを使うため、はるかに遅く高価で、良いチャンクを抽出するにはその上にさらにコードを書く必要があります
      このサーバーと llmsherpa ライブラリ(https://github.com/nlmatics/llmsherpa)を一緒に使うと、LLM/RAG プロジェクトに適したレイアウトに配慮したチャンクを得られます
    • ここには OCR も AI も入っていません。標準のフォールバックを除けば、という意味です
      このライブラリや fitz/pymupdf のようなツールは、PDF からテキストを直接抽出し、解析と構造化ルールを適用できるようにします。最近の PDF の大半は OCR なしでテキスト抽出が可能です
      当然ずっと安価ですが、動的なレイアウト全般にはうまくスケールしないので、通常は標準構造に合わせて設定できる場合に使うことになります。それでも科学論文のようなものでは、ルールベースのテキスト抽出がかなり動的にうまく機能するのを見てきました
    • 最後に使ったとき、Azure Document Intelligence は分割点を選ぶのがそれほど賢くありませんでした。こちらはより良いヒューリスティックを実装しているように見えます
    • 私も気になります。ADI は信頼できますが、作りの悪い PDF ではエッジケースの問題があります
      ただ Tesseract OCR が潜在的な限界になるのではないかと心配です。あまりにも多くのミスをするのを見てきました

  • 例があるのか気になります。リポジトリには PDF ファイルが1つもないように見えます

    • 例は llmsherpa プロジェクトで見られます: https://github.com/nlmatics/llmsherpa
      この nlm-ingestor プロジェクトは、llmsherpa と連携するバックエンドを提供します。llmsherpa ライブラリは、LLM/RAG プロジェクト向けに良いチャンクを抽出するのに非常に便利です