PDFがRAGシステムの「敵」になる時
AI開発やDevOpsに携わっている方なら、チャットボット(RAG: Retrieval-Augmented Generation)が詳細な資料を与えているにもかかわらず、的外れな回答をしてしまう時の無力感を経験したことがあるでしょう。多くの実プロジェクトを経て得た教訓は、「データの抽出・変換(ETL)が成功の80%を占める」ということです。ベクトルデータベースに「ゴミ」を投入すれば、LLM(大規模言語モデル)からはそれ相応の結果しか返ってきません。
特に財務報告書や技術文書などのPDFファイルは、最も厄介な存在です。これらは通常、マルチカラム(段組み)のレイアウト、入り組んだ表、複雑な画像を含んでいます。従来のパース用ライブラリでは、内容がバラバラになり、数値の表が意味をなさない文字列の塊に変わってしまうことが多く、LLMを完全に迷走させてしまいます。
なぜ従来のPDFライブラリは頻繁に「お手上げ」になるのか?
根本的な問題はPDFの性質にあります。PDFはHTMLのような構造化データではありません。どちらかというとグラフィックの設計図に近く、各文字がページ上の座標(x, y)に配置されているだけなのです。
- 表構造の崩壊: PyPDF2のようなライブラリは、テキストを出現順に取得するだけです。その結果、列Aの数値が列Bの行に飛び込んでしまい、あらゆる論理的な関係性が失われます。
- マルチカラムレイアウト: ページ全体を左から右に読み取ると、ライブラリは左カラムの1行目を読んだ直後に右カラムの1行目へ飛んでしまいます。内容は寄せ鍋のように混ざり合ってしまいます。
- ヘッダー・フッターのノイズ: 繰り返し現れるページ番号やタイトルが本文の間に挿入され、検索(Retrieval)結果を汚染します。
私は以前、パース後のゴミデータを取り除くための正規表現(Regex)を書くのに1週間を費やしたことがあります。しかし、IBMのDoclingを試してからは、このプロセスは数分に短縮されました。
Docling — AIデータエンジニアのための「救世主」ツール
Doclingは単なるコンバーターではありません。これは、視覚的解析のために専用のAIモデル(DocLayNet)を使用するオープンソースライブラリです。文字を推測するのではなく、実際にページ全体のレイアウトを「見て」理解します。
最大の魅力は、クリーンなMarkdown形式で出力される点です。これは、GPT-4やClaudeといったLLMが最も得意とする「母国語」のような形式です。
30秒でクイックインストール
Python 3.9以上の環境があれば、すぐに始められます:
pip install docling
少し注意点として、初回実行時はDoclingが数百MBのAIモデルをダウンロードするため、動作が少し遅くなります。少しだけ辛抱してくださいね!
5行のコードでPDFをMarkdownに変換
何百行もの手動処理コードの代わりに、これほどシンプルになります:
from docling.document_converter import DocumentConverter
source = "bao-cao-phuc-tap.pdf"
converter = DocumentConverter()
result = converter.convert(source)
# 高品質なMarkdownを取得
print(result.document.export_to_markdown())
出力結果には階層化された見出し(#、##)が含まれ、表もテーブル形式が維持されます。これにより、LLMは文書構造を即座に把握できるようになります。
DoclingはどのようにRAGシステムを賢くするのか?
なぜMarkdownなのでしょうか? RAGにおいて、チャンキング(テキストの分割)ステップは極めて重要です。
プレーンテキストでは文字数で切るしかありませんが、DoclingのMarkdownを使えば、セマンティック・チャンキングが可能です。見出しごとに分割し、一つのチャンク内に表構造を維持したまま収めることができます。LLMは推測に頼ることなく、常に100%正確に回答するための十分な文脈(コンテキスト)を持つことができます。
表(テーブル)処理の威力
結合されたセル(merged cells)を持つ売上表を他のライブラリに読み込ませてみてください。悲惨な結果になるはずです。DoclingはAIによる表構造認識(TableStructureRecognition)を用いて行と列の関係を再構築します。私のテストでは、その精度は従来のOCRツールを遥かに凌駕していました。
プロダクション環境に導入する際の注意点
非常に強力なツールですが、実際にデプロイする際には、システムエラーを避けるために以下の3点に注意してください:
- RAMの消費量: PyTorch上でディープラーニングモデルを動かすため、Doclingは少なくとも4GB〜8GBのRAMを必要とします。Dockerで動かす場合は、Out of Memoryエラーを防ぐために十分なリソースを割り当ててください。
- GPUアクセラレーション: 数千ページのドキュメントを処理する必要がある場合は、CUDA対応のGPUを使用しましょう。パース速度はCPUのみの場合と比較して5倍から10倍速くなります。
- エコシステムとの統合: Doclingはメタデータ(ページ番号、座標)を標準で提供しています。これらを活用して、ベクトルデータベースをより豊かなものにしましょう。
LangChainとのクイックな統合例:
from langchain_core.documents import Document
from docling.document_converter import DocumentConverter
def load_pdf_docling(path):
# Doclingを使用してPDFを変換
res = DocumentConverter().convert(path)
# MarkdownコンテンツをLangChainのDocumentオブジェクトとして返す
return [Document(page_content=res.document.export_to_markdown(), metadata={"source": path})]
結論:データパイプラインをアップグレードする時
長年さまざまなツールに苦労してきましたが、現在のRAGプロジェクトにおいてDoclingは最良の選択肢であると断言できます。手動でのコーディングに手間をかけることなく、ドキュメントの文脈を維持するという課題を根本から解決してくれます。
もちろん、スキャンが極端に不鮮明なものについては、依然として高度なOCRとの組み合わせが必要です。しかし、現在のオフィス文書の90%において、Doclingは十分すぎるほどの性能を発揮します。今すぐあなたのパイプラインに統合してみてください。チャットボットが目に見えて「賢く」なるはずです!

