メインコンテンツへスキップ
必要に応じて、自動処理された文書は手動で検証できます。このため、ABBYY FlexiCapture には、リッチ クライアントとシン クライアントの両方の検証クライアントが用意されています。 検証は時間もコストもかかる処理です。ABBYY FlexiCapture には、文書を自動的に検証できる自動バリデーションルール機能があり、手動検証を省略できます。 検証作業を減らすもう 1 つの方法は、どの文書フィールドを 100% の精度で抽出する必要があるのかを顧客と明確にすり合わせることです。文書内のすべてのフィールドが対象とは限らないため、これにより、それらのフィールドに問題がある文書だけに検証を集中させることもできます。 検証オペレーターの人数を算出するには、処理対象の文書数、そのうち検証が必要な文書数、Service Level Agreement に基づく処理期限、および 1 文書の検証に必要な平均時間を把握する必要があります。 検証担当者も System に負荷をかけます。Verification Station は Processing Station と同様に Application Server とやり取りし、Application Server にタスクを要求して画像や文書データをダウンロードし、修正したデータを送り返します。
  • Verification Stations の処理速度は大幅に遅くなります。通常、手動検証は Processing Station での自動処理よりもはるかに時間がかかるためです。
  • 検証オペレーターは、必ずしも原本と同じ品質の文書画像を見る必要はありません。FlexiCapture の設定では、オペレーターが Application Server からダウンロードする画像の圧縮率 (既定では 60%) を変更できます。
実務上は、能力の上限で作業している 1 人の検証オペレーターが生み出す負荷は、Processing Station の 1 つの処理コアが生み出す負荷の最大 1/5 と見なせます。 この仮定を使えば、テスト結果 (検証オペレーターを使わず、無人処理のみで実施したもの) を解釈できます。たとえば、100 個の処理コアを備えた System が安定しているようであれば、そのうち N 個の処理コアを、同時に稼働する N*5 人の検証オペレーターに安全に置き換えられます。 例。ある顧客が、100,000 文書を 8 営業時間で処理する必要があるとします。 先の仮定、つまり手動検証が必要なのは文書の 30% のみで、各文書の検証には最大 2 分かかるという前提に基づくと、必要な検証担当者は最大 125 人という結論になります。 各文書は平均で約 3 ページあります。代表的な文書からテスト batch を作成し、本番稼働前に無人処理モードで System をテストできます。たとえば、100 個の処理コアを使用しているときは System は安定しており、ボトルネックも見られず、一方で目的の 300,000 ページを 8 時間で処理するには 60 個の処理コアですでに十分だとします。125 人の検証担当者に対する上限見積もりは 25 個の処理コアなので、System は 60 個の処理コアで処理しながら 125 人の検証担当者にも十分対応できます。