【要約】【実測比較】日本語RAGのOCR、結局どれを使う？ glm-ocr / dots.ocr / Unlimited-OCR / MinerU を社内ドライブの実データでガチ評価 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
RAGを実業務に適用しようとするエンジニアは、社内ドキュメントの多様な形式によって検索精度が低下する問題に直面する。テキスト層のない資料や図表が混在することで、LLMが参照すべき根拠が消失してしまうからである。
具体的には以下の課題が存在する。
具体的には以下の課題が存在する。
- ・テキスト層のない提案スライドや図中の数値が無視される。
- ・スクリーンショット内の表構造が崩れ、意味のあるデータとして抽出できない。
- ・単一のOCRエンジンでは、速度と精度の両立が困難である。
// Approach
筆者は、4つのOCRエンジンを異なるデータ形式に対して実行し、出力精度と速度を比較する検証を行った。その結果、単一のエンジンに依存せず、用途に応じてエンジンを切り替える「混合採用」のアプローチを導き出した。
具体的な実装戦略は以下の通りである。
具体的な実装戦略は以下の通りである。
- ・文書・表形式：MinerUを主力とし、高速なMarkdown構造化を行う。
- ・図・チャート・スライド：glm-ocrを用い、図中の数値やテキストを完全に復元する。
- ・Fallback構成：まずMinerUで解析し、図や欠落ページのみをglm-ocrで補完する。
// Result
検証の結果、用途に応じた2系統のルーティングが、情報の取りこぼしを最小化する最適解であることが示された。
得られた具体的な知見は以下の通りである。
得られた具体的な知見は以下の通りである。
- ・図・チャート・SmartArt：glm-ocrが唯一、高い精度でテキストと数値を復元できる。
- ・テキスト主体のPDF：MinerUが最速かつ、扱いやすいMarkdown形式で出力する。
- ・表構造の維持：Unlimited-OCRやMinerUが、HTMLテーブル形式での厳密な復元に強い。
Senior Engineer Insight
> RAGの性能はLLMのモデル性能以上に、前段のデータ抽出精度に依存する。図表を「画像」として扱うレイアウト解析器と、画像全体を「視覚」として捉えるモデルでは、得られる情報の密度が根本的に異なる。コストとレイテンシを考慮し、MinerUで大半を高速処理し、難所のみをglm-ocrへ回すFallback設計は、実戦における極めて合理的なアーキテクチャである。