RAGシステムを構築するとき、多くの人はまず埋め込みモデルや検索アルゴリズムに注目します。
でも実際は、その手前でつまずいているケースが多いんですよね。
つまり、文書の取り込み段階です。
先日、Redditで興味深い投稿を見つけました。
特許情報サービスを手がけるPatSnap社が、社内ツールをオープンソース化したという内容です。
1. 公開された2つのツール
投稿で紹介されていたのは、次の2つです。
Hiro-Smart-Doc
セルフホスト型の文書解析パイプラインです。
FastAPIで動きます。
処理の流れとしては、まずRT-DETRでレイアウトを検出します。
このとき、ページを25種類の領域カテゴリに分類します。
その後、各領域に対して正しい読み順でOCRをかけていく仕組みです。
段組みページにも対応しているとのこと。
また、出力形式にも工夫があります。
表はHTML、数式はLaTeX、本文はMarkdownとして書き出します。
対象はPDFだけではありません。
Officeファイルや画像も処理できるそうです。
ライセンスはApache-2.0。
GitHub: https://github.com/patsnap/Hiro-Smart-Doc
Hiro-MOSS-OCR
上記パイプラインのOCR層を担うモデルです。
パラメータ数は、わずか0.3B。
しかも、5,000万件以上の技術文書でスクラッチから学習させたと説明されています。
ベンチマークのOmniDocBench v1.5では、93.63というスコアを記録しました。
さらに、vLLM経由ならRTX 4090が1枚あれば58 QPSで動くそうです。
こちらもApache-2.0で公開されています。
GitHub: https://github.com/patsnap/Hiro-MOSS-OCR
HuggingFace: https://huggingface.co/PatSnap/Hiro-MOSS-OCR-0.3B
2. なぜ「レイアウト検出が先」なのか
コメント欄で最も評価されていたのが、この設計判断でした。
OCRをかける前に、レイアウトを検出する。
この順番が正解だという意見で、複数のコメントが一致していたんです。
理由はシンプルです。
段組みページや表を1本のテキストの塊に潰すと、そこでRAGの取り込み精度が静かに失われます。
大事なのは「静かに」という部分です。
エラーは出ません。
テキスト自体は抽出できています。
しかし、段組みの左右が混ざった文章では意味が通りません。
行と列の構造を失った表も同様です。
その結果、検索しても使いものにならない結果が返ってきます。
あるコメントは、こう指摘していました。
多段組みの技術系PDFでは、読み順の崩れが下流の処理すべてを汚染する、と。
また、表をHTMLとして保持する点も好評でした。
テキストに平坦化すると、行・列の構造が捨てられてしまいます。
一方、HTMLなら構造が残るため、後段の処理がずっと楽になるからです。
3. コメント欄で挙がった鋭い論点
賞賛だけではありません。
実運用を見据えた質問や懸念も寄せられていました。
むしろ、ここが一番の読みどころだと思います。
ページをまたぐ表の扱い
表がページ境界や段組みの境界で分断されるケースがあります。
これは、多くのHTML表抽出ツールを壊す難所だそうです。
さらに、怖い指摘がありました。
「半分だけ取り込まれた表は、欠落した表より悪い」というものです。
なぜでしょうか。
中途半端な表でも、検索時には自信満々にヒットしてしまうからです。
そのため、密度の高いリファレンス文書ほど問題は深刻になります。
回転スキャンとスタンプ付きページ
こんな経験談もありました。
25カテゴリのレイアウトモデルが領域を取りこぼし始めるのは、
たいてい回転したスキャン画像やスタンプが押されたページだそうです。
だから、ストレステストをするならそこから、とのアドバイスでした。
きれいなデジタルPDF向けの高速パス
もうひとつ、面白い質問がありました。
「大半のきれいなデジタルPDFには、0.3Bモデルすら不要では?」というものです。
つまり、VLMを通さない高速パスを検討したかという問いですね。
このコメント主は、同じ課題に別のアプローチで取り組んでいました。
Rust製のCPU専用ツール(MITライセンス)で、GPUを一切使わない設計です。
ピークのOCR精度は犠牲になります。
その代わり、スループットとセルフホストの手軽さを取るわけです。
なお、OCRは必要なページだけフォールバックで実行する仕組みだそうです。
ゴールは同じ「構造を保ったMarkdown出力」でも、トレードオフの取り方はチームごとに違います。
この対比は参考になりました。
既存ツールとの比較
doclingとの比較結果を尋ねる声もありました。
加えて、ParseBenchでの評価はないのかという質問も出ています。
ただ、投稿時点では、これらへの回答は確認できていません。
4. RAG構築者が持ち帰るべき視点
この投稿とコメントから学べるのは、個別のツールの話にとどまりません。
本質は、文書取り込みの品質問題が目に見えにくいことです。
パースが失敗すれば気づけます。
厄介なのは「一応成功しているが、構造が壊れている」ケースです。
段組みの混線、分断された表、崩れた読み順。
どれも例外を投げずに通過します。
そして、検索結果の質だけをじわじわ下げていきます。
自分のパイプラインを点検するなら、次の観点でテスト文書を用意してみてください。
- 段組みレイアウトのページ
- ページや段をまたいで続く表
- 回転スキャンやスタンプ入りの文書
回答精度が上がらない原因を、検索側だけで探していませんか。
もしそうなら、一度取り込み側を疑ってみる価値があります。
まとめ
PatSnap社が、Hiro-Smart-DocとHiro-MOSS-OCRを公開しました。
「レイアウト検出を先に、OCRは領域ごとに読み順で」という設計の文書解析パイプラインです。
0.3Bという小さなモデルサイズも魅力でしょう。
RTX 4090の1枚運用が現実的だからです。
しかも、両方ともApache-2.0なので、商用利用のハードルも低めです。
一方で、検証すべき領域も残っています。
ページをまたぐ表や回転スキャンといった難所への耐性は、各自のデータで確かめる必要があるでしょう。
RAGの品質は、検索の手前で大きく決まります。
つまり、取り込みの段階です。
パイプラインの見直しを考えているなら、まず自分の文書の「壊れやすい箇所」を洗い出すところから始めてみてください。
