訳：EvernoteのIndexシステム

Evernote Indexing System | Evernote Tech Blog

====

Evernote Indexシステムは、テキストからメディアファイルまで検索できるように設計され、いかなるテキスト情報も検索対象として読み込む。現在では、 image/PDFやデジタルインクドキュメントまで対応するメディアタイプを拡大している。生成されたIndexは、認識した単語、代替スペル、関連レベル、位置情報を含んだXMLかPDFドキュメントの形式で配布される。

Indexシステムは Debian64の専用サーバ群で実装され、各サーバでは、 AMPプロセスと複数(通常はサーバーのCPUコアと同数)のENRSプロセスが稼動している。ENRS(EN Recognition Server)はJava6 ウェブサーバアプリケーションでラップされたネイティブライブラリ群として実装されていて、現在は２つのコンポーネント機能AIRとANRを提供している。AIRは多様な画像ファイルとPDFを扱い、AMPはデジタルリンクドキュメントを扱う。AMPはHTTP REST APIでサーバと通信することで、大きなメディアファイルのやり取りを高スループットに維持するために柔軟なシステム設定を可能にしている。

AMPはユーザ用データのシャードからリソースを受け取り、生成したIndexを返す。Indexは、EN Web Servcie用の検索Indexに追加され、ローカル検索を可能にするために 携帯やデスクトップのEvernoteクライアントに配信される。ユーザのリクエストですでに逼迫しているシャードに対してこの余分なトラフィックを最小化するため、AMPはお互いにキュー情報をブロードキャストすることで、EN Serviceの負荷と処理優先度に最適化された単一の分散メディアプロセッサを構成している。Evernote Index Systemは、各種のコンポーネントが1つしか残っていなくても処理を行うための十分な弾力性(resilient)がある。（そして現在、37個のAMPプロセスと 500個以上のENRSサーバプロセスによって、1日に2百万個のメディアファイルを処理している。)

ENRSサーバの一部であるAIRを詳しく見てみよう。AIRの認識方針は通常のOCRとは異なり、その目的は印刷可能なテキストを生成するのではなく、広範囲(comprehensive)な検索Indexを生成することだ。どんな種類・質の画像からでも多くの単語を検出することに的を絞っている。不完全・不明瞭・ぼんやりした単語の代替候補も生成する柔軟性もある。

現実世界の画像を扱うため、AIRサーバは、異なる仮定(assumption)に絞った複数の「経路」で処理を行う。画像は大きいかもしれないが、少ししか単語を含んでいないかもしれない。異なる方向にバラバラにあるかもしれない。同じ領域に、極小と極大のフォントが混在しているかもしれない。白地に黒字、黒地に白字が混ざっているかもしれない。異なる言語と文字が混在しているかもしれない。アジア言語では横書きと縦書きが混在しているかもしれない。標準的なOCRでは同じレベルのグレーにするような、似たようなフォント色が混ざっているかもしれない。印刷されたテキストには手書きコメントがふくまれているかもしれない。広告用画像素材はwarped/slanted/changing size on the goかもしれない。AIRサーバが1日200万回直面している数少ない問題を示す。

 

以下の図は、 AIRサーバの主なビルディングブロック(単一の「pass」)である。呼び出しのパラメータで異なる種類の処理(scale,orientation,etc)を決めている。passに応じて、pass( scaled,converted to gray, binarized)を特定する準備からはじめる。イメージ画像・表・マークアップ・非テキスト人工物は、可能な限り除去する必要がある。候補となる単語が検出された後、テキスト行とブロックに組立て直す。

各ブロックの各行は、沢山の認識エンジンによる解析を通過していく。認識エンジンには、内部開発したものや他ベンダーからライセンスされているものもある。複数の認識エンジンを採用することは異なる種類のテキスト・言語を特定するために重要なだけでなく、「投票」機構(analyzing word alternatives created by diverse engines for the same word allows for better suppression of false recognitions and giving more confidence to consensus variants)を実装する事ができるようになる。これらの自信のある答えが、テキスト行の構造再決定、単語グルーピング、検索ミスを減らすために曖昧な箇所を除去する、といったテキスト行再構築に基づいた「pass」処理の最後のブロック上の柱になっている。

イーメージレンダリングと分析モジュールによって、作成されるpass数が最初に決められる。が、認識過程でこのカズは増減する。綺麗なドキュメントをスキャンする場合は、標準のOCR処理だけで十分だ。薄暗い状況で携帯カメラで撮影された複雑な風景は、テキストデータを取得するために全passを使って深い分析を行う必要がある。複雑な背景上にある色のついた沢山の単語は、色分割に特化したpassが追加で必要になる。小さくぼんやりした(blurred)テキストは、他の認識処理の前にテキストイメージを復元するために高価なreverse digital filtering技術が必要になる。一旦全passが完了すると、AIR処理の重要な最終結果を組み立てる次工程に進む。複雑な画像では、異なるpassが同一領域の解析結果を生成しているかもしれない。これらの衝突を解決(reconcile)し、最良の解析結果を選択しそれ以外を除外し、最終ブロック・テキスト行を構築する必要がある。内部ドキュメント構成が決まれば、要求された出力フォーマットを生成するという最終工程が残るのみである。PDFドキュメントは画像がテキストボックスに置換されたPDFになる。位置情報は、イメージやテキスト上で検索ワードをハイライトさせることを可能にする。