1,000冊をすべて処理した後で、もっともらしいOCR結果が人名を変え、段組みを逆順にし、ウルドゥー語の行を黙って落としていたと気づくのは遅すぎます。
最初に「どのOCRエンジンが一番か」と考える必要はありません。手元の蔵書を代表する小さなテストセットを先に作ります。最適解は一つのエンジンではなく、きれいな英語ページ、アラビア語やNastaliq、どの方式でも不安定で人手確認が必要な少数ページを、それぞれ別の経路へ振り分ける形かもしれません。
Table of Contents
本ではなく、ページの種類を抽出する
全体を処理する前に、まず約60ページを選びます。60という数字自体より、実際の状態を覆うことが大切です。最初の構成例は次の通りです。
- きれいな英語 10ページ
- きれいなアラビア語 10ページ
- ウルドゥー語またはNastaliq 10ページ
- 右書きと左書きが混在するページ 10ページ
- 傾き、裏写り、低コントラスト、書き込みなど、難しいスキャン 10ページ
- 二段組み、脚注、表、詩、対訳など、構造を持つページ 10ページ
出版社、年代、書体、スキャン元が偏らないようにします。調整に使わない小さなホールドアウトセットも残してください。最初の数例だけに合わせた改善を、書庫全体の改善と取り違えないためです。
サンプルは単純なmanifestで記録できます。
page_id,book_id,page_label,script,page_type,image_sha256,ground_truth
p001,b017,23,ara,single_column,8a4f...,truth/p001.txt
p002,b042,118,urd,nastaliq_footnotes,37c1...,truth/p002.txt
p003,b051,ix,mixed,mixed_rtl_ltr,2e90...,truth/p003.txtページ画像とハッシュが固定の基準です。エンジン、モデルまたは言語パック、バージョン、設定、処理時間、出力先は実行記録へ分けます。これで「先週はPaddleの方が良かった気がする」ではなく、再現できる比較になります。
Ground truthは小さく、確かにする
用途に必要な精度で各ページを正確に転記します。検索用なら、本文、見出し、人名、引用、意味のある句読点が中心です。脚注が必要なら含めます。母音記号などが資料の意味に関わるなら、それも残します。
転記はUTF-8で保存します。紙面どおりの外交的転写は変更しません。比較用に正規化が必要なら別の派生ファイルを作り、規則を記録します。W3Cの文字列照合仕様は安定した比較のためにUnicode正規化を勧めていますが、互換正規化は残したい区別まで畳み込むことがあります。NFCは妥当な比較の出発点です。ダイアクリティカルマークの削除、ウルドゥー文字のアラビア文字形への置換、句読点の統合は、黙ったクリーニングではなく明示的な実験にします。
アラビア語／ウルドゥー語と英語が混在するページは、二つを別々に確認します。Unicode文字列は正しいか。そして読み順は正しいか。文字がすべて認識されていても、英語の句、ページ番号、脚注が誤った位置へ入れば、検索用テキストとしては使えません。
文字誤りとレイアウト誤りを分けて測る
最初の指標には文字誤り率（CER）が使えます。
CER =（置換 + 削除 + 挿入）/ 参照文字数全体平均だけでなく、ページ種別と文字体系ごとに計算します。大量の簡単な英語が、壊滅的なウルドゥー語の結果を隠すことがあるからです。JiWER などは文字・単語単位の誤り率を計算できますが、どの正規化規則を使ったかも結果の一部として保存します。
CERだけでは読み順を測れません。OCR-Dの評価仕様は、テキスト、レイアウト、読み順、実行時間を別々の品質軸として扱います。各サンプルに短い構造チェックを加えます。
- 見出しが対応する段落より前にあるか
- 段組みが意図した順番か
- 脚注が正しいページと記号に結び付いているか
- 表がセルとして保たれているか、壊れた場合は不確実と明記されているか
- 右書き・左書きの混在部分が論理的な順番か
- ページ境界が残っているか
エンジンがレイアウト付き出力を提供するなら保存します。TesseractはプレーンテキストだけでなくhOCRやTSVを出力できます。ALTO は、OCR文字、ページレイアウト、座標、処理メタデータを保持する、現在も維持されているXML形式です。最初から全書庫を一つの規格へ統一する必要はありません。ただし評価前にbounding boxを捨てると、レイアウト障害の原因を追いにくくなります。
前処理を制御変数として試す
Tesseractの品質ガイド は、解像度、二値化、ノイズ、回転、境界、ページ分割などの問題を分けて説明しています。一度に変える要因は一種類にし、未加工の原本は必ず残します。
PDFでは、OCRmyPDF が、既存テキストのあるページをskipする、既存OCR層をredoする、全ページをforceでラスタライズする、といった処理を選べます。これは同じ動作ではありません。forceは対話要素や既存文字を平坦化し、skipはボーンデジタルページを残せます。現在のrendererは右書きに対応しますが、それだけで特定のウルドゥー書体やスキャンの認識精度が保証されるわけではありません。
最初の実験表は小さくて十分です。
run A：原画像 + エンジン／モデル1
run B：傾き補正だけ + エンジン／モデル1
run C：原画像 + エンジン／モデル2
run D：傾き補正だけ + エンジン／モデル2CER、読み順、失敗ページ、処理時間、容量を比べます。一枚の傷んだページが改善したからといって、全フィルターを全冊へ適用しないでください。
万能の勝者ではなく、ページのルーティングを作る
採点後は単純なルーティング表にします。
| ページ分類 | 選ぶ処理 | 確認ルール |
|---|---|---|
| ボーンデジタル英語 | 既存テキストを抽出 | 抽出失敗だけ確認 |
| きれいなアラビア語印刷 | 実測で最良のアラビア語経路 | 信頼度しきい値未満を確認 |
| ウルドゥー語Nastaliq | 実測で最良のウルドゥー語経路 | 人名、引用、低信頼区間を確認 |
| 右書き・左書き混在 | レイアウトを保持する経路 | 読み順を必ず確認 |
| 表または対訳 | 構造向けの経路 | セルが崩れたら散文として索引しない |
異なるエンジンのconfidence scoreは、ground-truthセットで校正するまで直接比較できません。観測した誤りを基準にする方が安全です。サンプル中の悪いページを大半拾えるしきい値を決め、それ未満を人が確認します。
RAGまで証拠のつながりを保つ
各ページについて、次の四つを一緒に保管します。
- 元ページ画像または元PDFへの参照
- 未加工のOCRとレイアウト出力
- 検索用に正規化したテキスト
- 正確なエンジン、モデル、設定、実行時刻
検索には正規化テキストを使っても、結果から必ず元ページへ戻れるようにします。後の訂正で検索テキストが変わっても、古いraw出力は残し、修正履歴を記録します。
言語モデルによる「清書」は特に慎重に扱います。宗教、法務、歴史、科学の文書では、珍しい正しい文字を、流暢だが誤った文字列へ置き換えることがあります。不審箇所の抽出や確認順の決定には使えますが、唯一の転記を黙って書き換えさせてはいけません。
最後に実際の質問で検索を試します。20〜50件の問い合わせ、見つけるべきページ、読者が照合すべき箇所を保存します。OCRが人名を壊して失敗したならOCR経路を直します。文字列は正しく、語彙だけが異なる場合に、はじめて字句検索と意味検索の併用を検討します。関連する科学文献コレクションの完全性ガイドでは、この評価を版管理、引用、検索、知識グラフのprovenanceへつなげます。embeddingで元データの品質問題を覆い隠さないためです。
60ページ後に欲しい結論
テストの終点では、次を具体的に答えられる状態にします。
- 自動処理できるページ分類
- 各文字体系・レイアウトに最適な経路
- 人手確認が必要なページ
- 残る文字誤りと読み順障害
- 全量処理の時間と容量
- 書庫を索引してよいかどうか
私が管理している Local Knowledge Terminal は、多言語コレクションの処理を検証可能な原典へ結び付けます。サンプルレポート ではprovenanceとgo/no-goの形を確認できます。一つのコレクションで同じ範囲の確認が必要なら、まず無料fit checkへ。メタデータと権利条件が合った後にだけ、任意のUSD 250 sprintの範囲を決めます。対象は代表サンプルの評価で、カスタムOCRや書庫全体の変換は含みません。
順番は単純です。抽出し、転記し、測り、振り分け、保存してから索引します。