A technology entrepreneur who has directed and managed pre-sales to after support and everything in between. Naveen started his career in IBM working with the Watson Research Center solving combinatorial optimization problems using asynchronous agents.

He continued this work with i2 Technologies when IBM transferred its supply chain portfolio of products to i2. He moved into a more product management role while continuing to work on the core algorithms.

He took leave of i2 technologies and the next couple of years spent on researching unstructured text processing. His goal was to create a practical real-world natural language processing engine that will make sense of unstructured text. Instead of boiling the ocean, he concentrated on niche vertical applications which could use domain knowledge in addition to general language processing and AI algorithms to handle and understand large volumes of English text.

This gave birth to the Matching engine featured in OdinJobs. He is a Founder and the resident technology evangelist of OdinJobs. (See the ReasonsWhy OdinJobs is Essential Today). 

As part of the OdinJobs strategic team, he dabbles in marketing and business development, in addition to establishing the strategic vision and managing the development team. With considerable success in driving organic traffic to OdinJobs, he can be considered an expert in SEO. 

OdinJobs mission is to Match the Right Talent to the Right Opportunity, Wherever They Are. OdinJobs has developed and fine-tuned an AI-NLP based matching engine, a technology that is a find-the-needle-in-the-haystack that generates the best possible matches wherever they are. It uses contextual  search, pattern matching and natural language processing to intelligently read, filter, and prioritize limitless possibilities based on relevance.

Technology Roles & Responsibilities

Designed and architected the NLP/AI engines that are at the heart of OdinJobs.

• The Language Processing Module:  A general purpose engine that processes unstructured English text and makes sense of it. The language processing module is built on the principles of Natural Language Processing (NLP) including structure detection and categorization, named entity detection, parts of speech tagging, stemming, shallow and deep parsing. The module also uses Artificial Intelligence principles of pattern detection and matching, finite state machine, re-enforced learning, AHP based scoring, knowledge acquisition and representation.

• Domain Specific Parsing Engine: OdinJobs primarily operates on two unstructured text documents, resume and job. A resume and a job description have certain expected board characteristics even though each one of them may look and read very different. The domain specific parsing engine uses the language processing module perform an initial processing and then apply domain specific algorithms including pattern detection, shortest edit distance, re-enforced learning, bayesian classification to cluster, categorize and classify the documents. The output of the parsing engine is a structured representation of the document. Lucene is used to represent the data structure.

• Domain Specific Matching Engine: The matching engine pairs a resume and a job description and computes how well they match. This is a multi-criteria optimization problem, where there are trade-offs between conflicting criteria. The matching engine uses a Analytical Hierarchy Process (AHP)heuristic to compute each criterion score based on a weighting generated through supervised learning. The end result of the process is a match score between 0 (no match) and 5 (perfect match). The matching engine is the next step in the evolution from keyword searches for a defined domain. The Lucene search engine was modified and adapted to be used as part of the matching algorithm.
  
   

The Research

Objective was to extend my combinatorial optimization experience from structured data to unstuctured data. Started with a literature survey to analyze unstructured language processing applications. To my surprise, found very little real-world applications, most of them were either academic or were highly simplified toy world applications.

The Language Processing Engine

Core Functionality: The goal was to create a domain-neutral engine that used the best techniques of language processing to understand a English language document. The developed engine contained word, sentence, paragraph and header detection algorithms that converted a document into its basic units. Brill's part of speech tagger and Porter stemmer were incorporated in the engine to add more actionable information to the identified units. The language processing engine also has the capability (optionally) for syntactic analysis using Link Grammar (Daniel Sleator and Davy Temperley's Link Parser), and anaphoric resolution. It also used Wordnet and the Penn Treebank as corpora for morphological resolution and syntactic analysis.

The engine was created in C++ as that was the language I was most comfortable at that time and did not want a new language learning curve. These basic units had to have multiple intermediate data stores, and felt that this data store need to be file based as they were not really relation-based and the other requirement was retrieval should be fast.

Intermediate Data Store - Lucene

Came across the Lucene project in early 2002, that offered the ability to store and retrieve text data structures efficiently. Started using Lucene 1.0 to manage the language engine's internal store. Adapated the lucene Hits, Score and its entire retrieval mechanism to suit the language engine. Lucene has been a part of the language engine ever since.

Domain Specific Match Engine

The philosophy adopted was that natural language engines should not be horizontal but focus on a vertical, where domain specific information can be incorporated in the engine so that it becomes an effective special purpose engine. The first vertical the engine was applied to was the job market. Domain specific engine can take advantage of characteristics found in resumes and job description. Even though these documents are un-structured they contain generally accepted information. The domain specific processing engine understands these documents and creates the best match using a combinatorial optimization approach. Thus the match engine powering OdinJobs was born.

Went to work for i2 Technologies, the then market leader in Supply Chain solutions,  when they acquired supply chain products from IBM. 

Product & Solution Management

Was charged with creating the solution map for the process industry. Designed and developed a solution that included i2's best of breed horizontal solutions - Demand Planner, Supply Chain Planner, Factory Planner and Transportation Planner/Optimizer along with industry specific products like Enterprise Planning for the Process Industry.

Development Management

Managed the development process co-ordinating between client requirements and the development teams in the United States and India. Was responsible for analyzing and prioritizing client/prospect requirements and incorporating them into release plans.

Business Development & Pre-Sales

Created solution collateral describing the solution and its ROI. Analyzed the competition and created comparison matrix. Assisted industry and Geo sales to propose the right solution for the clients. 

The Research

Worked with the Watson Research Lab on A-synchronous Teams (A-Teams) to develop a combinatorial optimization approach to solve the supply chain problem for process industry. Worked on bin packing, math programming (LP, IP/MIP), vehicle routing algorithms. The research project was unveiled as a generally available supply chain solution for the process industry.

Product Development

Used classic design patterns to create a scalable and extensible product architecture around the algorithms. Designed and created an Enterprise Planning module that tackled a multi-location, multi-product planning and scheduling problem. This is a classic multi-optimization problem where there are conflicting objectives like cost and tardiness. The plan that is produced also needs to be feasible even though it may be sub-optimal. A Pareto frontier was used to evaluate the various plans to select the best possible plan.