Edit

OCR implementation

This section provides information on working with OCR where it is used in WorkFusion projects: requirements to installation, scaling, relation to model quality, approaches to improving.

Introduction

OCR might be used for ML use cases when we are dealing with documents in the form of images or PDF files. It is also regular case when OCR is used for RPA use cases - rule based extraction from documents. Some of the things to consider when your project involves OCR are:

• Installation. If WF OCR is used, customer will need an OCR server
• License. During the installation process you will be asked to request an OCR license (see How to request OCR license ). This should be done in accordance with the contract/SOW, which specifies the number of OCR pages granted to customer at set time periods
• Scaling. In typical deployment only one OCR server is installed; however, if there is a need to scale OCR to process more volume, a cluster of several servers can be created (see Scaling OCR ). Check OCR Capacity Planning for information on what volumes can be processed with what hardware and when scaling would be required.

Documents quality

Common customer questions

Will the quality of our documents be sufficient for the model? What is the required quality? Why not all of the provided documents were used in model training?

At the stage of choosing documents for training set Data Analyst should have filtered out the documents where OCR has not recognized something or messed up some fields. Still if the quality of original documents is low (<300dpi) - for example, customer could not provide better quality documents - you can encounter significant problems with statistics. If OCR does not recognize part of document you can end up with a lot of false negatives; if OCR recognizes some fields in a wrong way they can also be missed by the model (resulting in FN) or extracted by the model in the wrong form in which OCR recognized them (resulting in false positives (FP)).

The action plan in this case depends on multiple factors: is customer able to provide higher quality documents, is the number of available documents sufficient to filter out the worst ones, are OCR errors expected to be counted towards model stats. If there is no way to receive better quality documents, the focus will be on tuning OCR, writing post-processing that will help to mitigate OCR errors, filtering out the worst documents from the training set. In any case it is better to agree to exclude OCR errors from model stats and set it in the contract along with the desired dpi.

Refer to the description of OCR influence on dataset to understand the connection between OCR and model quality and find out how to act with documents that are candidates for training set in case of different level of OCR quality.

OCR results improvements

There're approaches how to improve OCR output for the documents even in case of insufficient quality:

1. You can prepare input images (or PDFs) using imagemagick tool. Increase DPI, improve brightness, turn image to black and white, etc
2. You can play with the parameters that are passed to OCR api to help OCR engine understand where on the document tables are usually located, what language is used in the documents, etc. See more info here:
   1. How to tune OCR
   2. How to improve OCR Results
   3. OCR FAQ

The OCR process is resource consuming. In case in scope of your use case it is expected to work with heavy flow of documents (especially multi page documents, 50+ pages) you should be aware of OCR scaling approach.