Archives

All posts for the month February, 2014

Automated Document Recognition

Posted by taylorwoodfnc on February 19, 2014
Posted in: app development, coding, using technology to solve real problems. Tagged: , , . Leave a comment

F# ADR Demo Project: https://github.com/taylorwood/ADRDemo

One of the greatest values we can provide to the customer is quick and complete visibility into the contents of their loan file, which would otherwise be an opaque stack of papers that a human would need to search exhaustively to find a particular document. A typical loan file is comprised of hundreds of discrete documents: legal documents, structured forms, appraisals, credit reports, tax documents, disclosures, financing documentation, etc. Some documents are fairly standardized and predictable, such as the URLA/1003 and the 1008, and some differ significantly by state or originator. Some documents are only one page and some can be dozens or hundreds of pages long. The loan files we process are typically 500-1,500 pages in length and contain hundreds of individual documents. We usually receive a loan file as a single PDF that may as well be a monolithic stack of papers: no table of contents, bookmarks, or any index information at all.

There is plenty written already about classification and recognition algorithms, but I will give a brief overview of how we employ a variety of these techniques in concert to provide incredibly accurate indexing for the types of documents found in loan files.

Nearly every loan file PDF we receive consists only of scanned images. The images can be of varying quality, from pristine digital scans to documents that have been through so many fax machines they’re indistinguishable from a Rorshach test. In order to gather textual information from these PDFs, we must first invent the universe (thanks Carl Sagan), but really, we must first rasterize the PDF, process the resulting images to adjust for binarization/rotation/skew, and then perform Optical Character Recognition on the images. We have developed a distributed, highly scalable processing pipeline using RabbitMQ (see our previous blog post) to perform these tasks in our server farm. The output of our OCR processing tells us what text each image contains and its precise location down to the letter. Now that we have textual data, we can think about what techniques one might use to classify textual data.

In order to perform statistical analysis on text, we must tokenize the text. This is basically the process of converting a word into something you can reason about mathematically: a number, obviously. A three-word document, “Taylor is hungry,” might be converted into three tokens: Taylor = 1, is = 2, hungry = 3. After tokenization, you’re left with what is essentially a “bag of words.” Any analysis of this bag of words is naive in the sense that it doesn’t quite matter which order the words came in, i.e. “Hungry is Taylor” would be considered identical to “Taylor is hungry” based solely on their token content. However, it’s possible to mitigate this naiveté using n-grams. We use a variety of values for n here, usually 1-3. Using bi-grams for example, “Taylor is hungry now” would tokenize to: “Taylor is”, “is hungry”, “hungry now.”

One of the text classification techniques used by our Automated Document Recognition is a variation of one of the oldest, simplest, most popular, and most effective techniques: TF-IDF weighting, which stands for Term Frequency – Inverse Document Frequency. I will summarize it as a method of counting the number of times a particular word appears in a text (a particular document), and augmenting that information using the number of times the same word appears in all texts (referred to as the corpus). In our corpus, words like “loan” and “address” are so ubiquitous they’re almost meaningless, which is why the IDF part of this technique plays an important role. Using TF-IDF we are able to create a type of signature (a very long vector of TF-IDF weightings) for each text. Once we’ve determined the signature of a particular text as can use a variety of similarity functions, such as cosine similarity or logistic regression, to compare it to the signatures of all other known documents. Another advantage of statistical text analysis is that it can be quite forgiving when it comes to classifying “noisy” documents like the aforementioned fax-machine-ravaged images that an OCR engine may not read very well. TF-IDF weights can be used as inputs to many popular classification techniques like Singular Value Decomposition, logistic regression, etc. We can also use decision tree algorithms to accurately identify multi-page or partial documents.

How do we determine what samples to use and types of documents to index? This is where supervision plays a part in supervised machine learning. The machine learns to recognize the types of documents we care about because we supervise the learning process by using known samples of documents we want it to recognize. For instance, let’s say we have 10 training samples of a variety of Trust Deeds. We can train the machine using these samples and the machine can internalize the patterns and “learn” what a Trust Deed is made of textually. The real power of this system is that it can recognize documents it’s never seen before, after being trained on just a few known samples of the respective document type. Managing the training data for your classifier can be a science and art unto itself, and is often more important than the type of classification algorithm you choose.

Another key feature of our ADR system is the implementation of a positive feedback loop, or validated learning. Since it’s impossible to teach our machine everything it will ever need to know from the start (new document types will be added, forms will change, etc.), we must be able to adjust the system’s knowledge on the fly. Using targeted manual review of current ADR results, we are continually expanding the scope and improving the confidence of the ADR system with each new loan file we process.

In practice, our ADR system has dramatically increased both the scope of documents we index and the efficiency with which we index them. There was a time when loan file indexing was a completely manual process for us, and probably still is for a lot of other companies. Fortunately, using data mining techniques we were able to leverage much of this manual indexing as training data for ADR. It would normally take a human worker well over an hour to index a complete loan file, and the consistency of the indexing might vary wildly depending on the worker even if they were only indexing a few critical document types. Our ADR system now indexes hundreds of types of documents at hundreds of pages per second and requires no human intervention!

–Taylor Wood, Senior Developer & Lead Architect at MortgageTrade™

iOS Training by Big Nerd Ranch: Part 3

Posted by courtneyhumphries on February 14, 2014
Posted in: app development. Leave a comment

Day 5 – Tuesday

Tuesday was spent covering topics such as text input, using table views, and controlling app navigation. If using XCode’s interface builder to construct views, it becomes very trivial to configure a keyboard based on its reason for being on the screen. From the interface builder, you can configure the keyboard to be numeric only, control autocorrect and autocapitalization, and choose context specific keyboards (e.g., an email keyboard) to better enhance user experience. For example, if the user is to enter a number, you can present them with a keyboard that only allows them to input numbers.

For the sample app we were building, we used table views to display lists of items on the screen. I felt that table view was a bit of a misnomer because unlike HTML tables, iOS’s table views only have one column. They are quite easy to use, however. iOS development relies heavily on the delegate pattern. Much like implementing an interface in other languages, in order to interact with much of Objective C’s built-in features, you implement the methods needed for a given component to get the data it needs or to handle the events it generates. For table views, you implement a data provider delegate in order to supply the data for each of the rows in a given table view.

If you’ve ever used an iPhone’s Settings app, it makes heavy use of the UINavigationController. A navigation controller allows a user to “drill down” a series of menus and provides the “back” button at the top of the app to traverse back up the navigation hierarchy. At the end of the day we learned how to interact with an iOS device’s built-in camera. In this lab, we added a button to our app that allowed the user to take a picture, and then that picture was added to a UIImageView inside our app.

Day 6 – Wednesday

Wednesday was a fun day for different reasons than just learning new iOS features (which I’ll talk about shortly). There was a two-hour block of time in the afternoon set aside for those who wanted to go on the zip lines. HBM has over 90 zip lines available for use at their facility. We had the opportunity to do the stage 2 and 3 level zip lines. Over the course of the two hours, we did six different zip lines, the fastest of which had us moving at speeds of about 50-55 MPH according to the guides. We had a really good time. Thankfully the high that day was a whopping 45 degrees (a heat wave compared to the previous few days), so for those of us who went, we had a blast.

bnr1bnr2bnr3bnr4

On this day, we went down the rabbit hole of using XCode and iOS’s auto layout features. One of the more challenging aspects of learning iOS code is how to build your app in such a way that everything looks right on an iPad or iPhone regardless if it’s in portrait or landscape mode. For many views in an iOS application, you build one view and use auto layout to configure how it looks in landscape mode or on a bigger screen. Much of the time is spent designing the view in portrait mode for an iPhone and then configuring it to look right in other sizes/orientations. It is possible to have code that allows you to use different views based on device or orientation but this can potentially become a maintenance headache. Image you want to add a new button that controls some new feature you’re adding to your app. The more your app’s code diverges based on device/orientation, the more places you have to add/support the new button. When possible, it’s best to use one view and use different constraints to support other devices/orientations.

We also learned the first of the two most common ways to store persistent data for an iOS app: archiving. Unlike a traditional operating system, iOS apps only have access to a dedicated location on a device’s file system. iOS gives apps access to the folders: Documents, Caches, Preferences, and tmp. iTunes backs up data stored in the Documents and Preferences folders. Anything in the Caches or tmp folders do not get backed up and can be purged by the operating system at any time (as long as the app isn’t running). If it is a normal file (e.g., an mp3 downloaded from the Internet), you can save the file straight to disk. If you need to persist data generated in memory, most commonly you implement the NSCoding interface on whatever class you wish to encode/decode.

Day 7 – Thursday

The first thing we learned about on Thursday was the second of the two most popular ways to persist data in an app: Core Data. Archiving is good for persisting fewer than 1000 objects. The problem with archiving is that the whole file must be read/written at a time instead of being able to append/modify objects one at a time. Core Data can turn Objective C objects into data that is stored in a SQLite database file. This allows developers to work with subsets of much larger datasets.

iOS allows developers to use web services to access/send JSON data to a web server. Unfortunately, the serializer used by iOS can only work with arrays, dictionaries, strings, and numbers. This means you can’t go directly from JSON to an Objective C class if the class contains properties such as dates. A developer must deserialize JSON into a class that only has string and number properties and then map that class to a class with more types of properties.

The last major topic discussed on Thursday was the UIGestureRecognizer. While it is possible to handle touches, touch movement, etc. manually, the UIGestureRecognizer gives developers the ability to easily recognize common gestures such as tap, flick, pinch zoom, finger rotate, etc.

Day 8 – Friday

Friday was the last day of training. We only had a half days’ worth of material. Most of this day was spent covering how to use XCode as a debugger and all of the profiling features it offers. The debugger is quite easy to use. One of the best features of using XCode is that it is able to give performance statistics (CPU/memory usage) on whatever device you’re running your code on. If you’re running the simulator all the numbers are in relation to what CPU your Mac is running and how much RAM you have. The nice thing is the same holds true for running the device on you iPhone while tethered to your Mac. You can use your own device to run your code and XCode will gather all the performance numbers for whatever device you have. This can be very handy when testing your app, not only on different size devices, but also different versions (iPhone 4, 4S, 5, 5S, etc.)…assuming you have all of these devices lying around somewhere.

After lunch, we all said our goodbyes to each other. There were a lot of friendly people I chatted with over the week, and I met a lot of very smart people. One of the best resources you get once attending a BNR training seminar is access to their user forums. They encourage students to stay in touch and use the forum to work through challenging tasks together. The instructors also remain available as valuable resources for any future roadblocks one might encounter during iOS development.

If you ever have the chance to do a BNR training session, I highly recommend it. Sure there may be a few topics that aren’t relevant to whatever purpose you’re going for (which is true for any broad topic training sessions), but it really helps overcome the initial hurdle of learning how to develop applications for complex frameworks. iOS development is unique and complex but can become very manageable given an opportunity like mine.