Patent Application
20190213252
A collection of data that is extremely large can be difficult to search and/or analyze. For example, in the case of the Web, a large fraction of the data is unstructured and value is locked in the data itself. It is not enough to store the web page of a service provider. For this information to be useful, it needs to be understood. A string of digits could be a model number, a bank account, or a phone number depending on context. For instance, in the context of a ski product, the string “Length: 170,175,180 cm” refers to 3 different ski lengths, not a ski length of 1700 kilometers. An incorrect interpretation of the data may result in useless information.
As an example, if a user enters the two words “mtor” and “stock” into an Internet search engine, and the results largely consist of web pages related to the drug mTor, the search engine has failed to recognize the search as a stock quote query. As another example, if a user enters the two words “seattle” and “sushi” into an Internet search engine, and the results largely consist of web pages related to hotels in Seattle, the search engine has failed to recognize the search as a restaurant query. While Internet search engines often do a reasonable job for head queries and documents, the accuracy quickly falls off in the tail because the information is not automatically understood by the search engines.
Relevance of search results may be dramatically improved if queries and web pages could be automatically classified in useful categories, such as stock quotes or restaurants, and if these classification scores were used as relevance features. A thorough approach might require building a large number of classifiers, corresponding to the various types of information, activities, and products. The number of classifiers might be further multiplied by the number of language and the number of context (queries, web pages, ad snippets, product feeds, etc). It is desirable to bring computer accuracy in classification and schematization tasks to human levels, and to make it easy for ordinary people to create computer clones of themselves to perform such tasks at scale. As one example, a tool could be provided that is optimized to allow the creation of classifiers and schematizers on large data sets in a matter of hours. When the classifiers and schematizers are exercised on hundreds of millions of items, they may expose the value that is inherent to the data by adding usable metadata. Some applications of such a tool include search, advertising, and commerce.
The term schematization as used herein refers to the action of identifying and filling the fields of a Schema. For example, the schema of a recipe could be made of four fields: Title, Description, Ingredients, and Directions. The schematization of a web page for the recipe schema is the action of segmenting the page into one or more instances of the recipe schema and filling the fields accordingly.
Internet search engines have built hundreds of classifiers and entity extractors in an attempt to understand queries, web pages, and ads. Unfortunately, the efficacy of the current approaches is limited by the number of machine-learning experts, the number of programmers, and the complexity of the tasks.
Humans are excellent at extracting semantic meaning from data. This is especially true when the data was authored for them or by them. For instance, they can label (or segment) web pages, queries, or product feeds with ease. Unfortunately, humans are embarrassingly bad at doing these things at scale. At ten seconds per page, a lifetime will not be long enough for someone to sift through 100 million web pages to identify all the pages related to a given topic. Computers have the exact opposite capabilities. They are embarrassingly poor at semantic understanding and they are outstanding at doing things at scale. The philosophy behind the approach described herein is to build a highly interactive and intuitive system that leverages the strengths of both humans and computers. “Highly interactive” means that a label or a feature entered by a human should have an immediate effect on computation. Within seconds, it should impact which errors are made or avoided, which item should be labeled next, which feature the user should focus on, and which field of a schema should be added or removed. “Intuitive” means that users should understand the effect of their actions and how to achieve their goals without requiring machine learning or programming expertise. This approach requires cycles from both computers and humans. The cycles may be tightly intertwined through quick machine learning “revisions.” Humans are guiding the computers and vice versa.
Another aspect of efficiency is the ability to build on other people's work. An important contributor to the explosion of the Web was the “view source” and copy-paste capability. In machine learning, the copy-paste capability comes from the fact that trained classifiers can be used as features to other classifiers. By creating a searchable and documented classifier repository, people are enabled to build on each other's work. This applies to both classifiers and schematizers.
The approach described herein creates a number of engineering and scientific challenges, which will be discussed. The challenges include:
In a first aspect, computer-readable media embodying computer-usable instructions are provided for facilitating a method of interactively generating dictionaries for machine learning. A user interface is presented for generating a dictionary that includes a list of one or both of words or n-grams that define a concept usable as a feature for training a classifier. On the user interface, a positive-example field is presented that is configured to receive user-input words or n-grams that are positive examples of the concept, where the positive examples are received from one or more of A) a typed entry or B) a selection of one or more suggested words or n-grams from one or more suggestion-set fields. On the user interface, the one or more suggestion-set fields are presented that are configured to display one or more system-generated lists that contain suggested words or n-grams that are selectable for inclusion in the positive-example field.
A first user-input word or n-gram may be received that is a first positive example of the concept. A list of suggested words or n-grams may be presented that represent a generalized concept generated based at least on the first positive example of the concept. Subsequent to presenting the list of suggested words or n-grams, a second user-input word or n-gram may be received that is a second positive example of the concept. The list of suggested words or n-grams may be refined based at least on a combination of the first positive example and the second positive example. The refined list of suggested words or n-grams that represent a refined generalized concept may be presented.
On the user interface, a negative-example field may be presented that is configured to receive user-input words or n-grams that are negative examples of the concept, where the negative examples are received from one or more of A) a typed entry, or B) a selection of one or more suggested words or n-grams from one or more suggestion-set fields. Subsequent to presenting the list of suggested words or n-grams, a second user-input word or n-gram may be received that is a negative example of the concept. The list of suggested words or n-grams may be refined based at least on a combination of the first positive example and the negative example, and the refined list of suggested words or n-grams that represent a refined generalized concept may be presented. A user selection of one or more words or n-grams from a suggestion-set field may be received. The user-selected one or more words or n-grams from the first suggestion set may be included in the positive example field.
Each word or n-gram in the dictionary may be assigned a respective weight. The respective weight of each word or n-gram may be scaled by a function of frequency and dictionary size based on training data during generation of the dictionary. The scaled weights may be related by a regularization constraint that adjusts the weights of the words that have less training data toward a value determined by the words that have more training data.
In a second aspect, computer-readable media embodying computer-usable instructions are provided for facilitating a method of interactively generating dictionaries for machine learning. A user interface is presented for generating dictionaries, where a dictionary includes a list of n-grams that define a concept, and where the dictionary is usable as a feature for training a classifier. On the user interface, a positive-example input field is presented that is configured to receive user-input n-grams that are positive examples of the concept. On the user interface, one or more suggestion-set fields are presented that are configured to display one or more system-generated lists of suggested n-grams. One or more user-input n-grams are received that are positive examples of the concept. A first set of suggested n-grams is generated that represents a first generalized concept based on the one or more user-input positive examples. The first set of suggested n-grams is presented in a first suggestion-set field on the user interface.
A refinement of the first set of suggested n-grams may be generated that that represents a refinement of the first generalized concept based on at least one or more additional user-input positive examples, and the refinement of the first set of suggested n-grams may be presented on the user-interface. The steps of generating the refinement and presenting the refinement may be repeated until an indication is received that the user has finished editing the dictionary, and the contents of the positive-example input field may be saved in a dictionary.
A second set of suggested n-grams may be generated that represents a second generalized concept based on the one or more user-input n-grams. The second set of suggested n-grams may be presented. The first set of suggested n-grams may be generated utilizing a first source. The second set of suggested n-grams may be generated utilizing a second source. The first source may include one or more of A) a previously-stored dictionary, B) a click graph representing queries and visited web pages, C) content of a table found on the world-wide web, or D) semantic representations of words.
On the user interface, a negative-example input field may be presented that is configured to receive user-input n-grams that are negative examples of the concept. One or more user-input n-grams may be received that are negative examples of the concept. A refinement of the first set of suggested n-grams may be generated that represents a second generalized concept based at least on the one or more user-input negative examples, and the refinement of the first set of suggested n-grams may be presented on the user-interface.
In a third aspect, computer-readable media embodying computer-usable instructions are provided for facilitating a method of interactively generating dictionaries for machine learning. An interface is generated for editing dictionaries, where a dictionary includes a list of words that define a concept usable as a feature for training a classifier. On the interface, a positive-example input field is presented that is configured to receive user-input words that are positive examples of the concept. On the user interface, a negative-example input field is presented that is configured to receive user-input words that are negative examples of the concept. On the user interface, a suggestion-set field is presented that is configured to display a system-generated list of suggested words, where the list of suggested words represents a generalized concept based on words in one or both of the positive-example input field or the negative-example field. One or more user-input words that are positive or negative examples of the concept are received, where the one or more user-input words are received from one or more of A) a typed entry, or B) a selection of one or more suggested words from the suggestion-set field. A set of suggested words is generated that represents a generalized concept based on the one or more user-input positive or negative examples. The set of suggested words is presented in the suggestion-set field on the user interface. A user selection of a first suggested word from the set of suggested words is received. The first suggested word is included in the positive-example field or the negative-example field. The set of suggested words is refined based at least on the first suggested word that was included in the positive-example field or the negative-example field. The refined set of suggested words is presented in the first suggestion-set field. An indication is received that the user has finished editing the dictionary, and the contents of the positive-example input field are saved in a dictionary.
On the user interface, one or more input fields may be presented that are configured to receive one or more of A) a user-selection that indicates whether trainable parameters are associated with each word in the dictionary or whether there is one trainable parameter associated with the entire dictionary, B) a user selection that indicates whether a feature value associated with the dictionary is a binary value based on a quantity of dictionary words or whether the feature value is a pre-determined function of a frequency of dictionary words, C) a user selection that indicates whether word frequencies are normalized, D) a user selection that indicates a regularization threshold that regulates a degree of interrelatedness between respective weights assigned to words in the dictionary, or E) a user selection that indicates whether the feature value is higher when multiple words from the dictionary appear within a document or when a single word from the dictionary appears multiple times in the document.
Each word in the dictionary may be assigned a respective weight, where the weights are related by a regularization constraint that adjusts the weights of words that have less training data toward a value determined by words that have more training data.
Having briefly described an overview of some aspects of the invention, an exemplary operating environment suitable for use in implementing some aspects of the invention is described below.
Referring initially to
Some embodiments of the invention may be described in the general context of computer code or machine-useable instructions, including computer-executable instructions such as program modules, being executed by a computer or other machine, such as a personal data assistant or other handheld device. Generally, program modules including routines, programs, objects, components, data structures, etc., refer to code that perform particular tasks or implement particular abstract data types. Some embodiments of the invention may be practiced in a variety of system configurations, including hand-held devices, consumer electronics, general-purpose computers, more specialty computing devices, etc. Some embodiments of the invention may also be practiced in distributed computing environments where tasks are performed by remote-processing devices that are linked through a communications network.
With reference to
Computing device 100 typically includes a variety of computer-readable media. By way of example, and not limitation, computer-readable media may comprises Random Access Memory (RAM); Read Only Memory (ROM); Electronically Erasable Programmable Read Only Memory (EEPROM); flash memory or other memory technologies; CDROM, digital versatile disks (DVD) or other optical or holographic media; magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, carrier wave or any other medium that can be used to encode desired information and be accessed by computing device 100.
Memory 112 includes computer-storage media in the form of volatile and/or nonvolatile memory. The memory may be removable, nonremovable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard drives, optical-disc drives, etc. Computing device 100 includes one or more processors that read data from various entities such as memory 112 or I/O components 120. Presentation component(s) 116 present data indications to a user or other device. Exemplary presentation components include a display device, speaker, printing component, vibrating component, etc.
I/O ports 118 allow computing device 100 to be logically coupled to other devices including I/O components 120, some of which may be built in. Illustrative components include a microphone, joystick, game pad, satellite dish, scanner, printer, wireless device, etc.
I. The ALE (Active Labeling Exploration) Challenge
Building a classifier (or a schematizer) on a very large data set presents a unique challenge: From what distribution should the training set be drawn? Randomly selecting items from the true distribution may not yield any positive examples after observing a million samples. A biased sampling could yield more positives but it may be so uncharacteristic of the true distribution that the resulting classifier is unlikely to perform well when deployed into the real world. Consider a fictitious scenario where the task is to build a classifier to find cooking recipe pages over the Web. A random selection of pages is unlikely to return any recipes (even after viewing one million pages). A search for the term “recipe” would return a biased sample of recipes (it would find “Numerical Recipes” and miss “Cooking Adventures”). The traditional development in four phases: data collection, labeling, training and featuring and tuning, and deploying, is suboptimal and can lead to disasters. For instance, one may discover during deployment that the classifier misses many of the ethnic recipes and returns cement mixing pages as cooking recipes. The classifier is not at fault. The problem lies with the sampling and the problem formulation. A classifier trained with a uniform sampling will quickly learn that the constant answer “not a recipe” is good enough for that distribution. A clever operator may tweak the distribution to build a more useful classifier, but this introduces biases that betray the ignorance of the operator. The operator, for instance, may have no knowledge of African recipes until the system is deployed and users start complaining. From the operator's point of view, the world looks like the picture in
The question is, how can a system be deployed that will perform well on data that one does not know exists? One observation is that the operator can be ignorant of the distribution as long as he/she can correctly classify items on demand. The Active Labeling Exploration (ALE) algorithm is based on this observation. Labeling is the process of classifying data or patterns of data as belonging to a particular class, e.g., labeling “321 Market Street” as being part of an address. Active labeling exploration is performed using a large set of unlabeled data (data on which the labeling process has not yet been performed), drawn from the true distribution. After each label (or few labels), a classifier is retrained with the new label, and the large unlabeled data set (e.g., tens or hundreds of millions of unlabeled patterns) is rescored. The system then selects which patterns to label next according to their scores. For this approach to work, one needs to solve the cold start problem (i.e., find “seeds” of positives).
In one aspect, an integrated interactive labeling system includes a labeling component, a training component, a scoring component, a sampling component, and a search engine component. The integrated interactive labeling system may also include one or more other features, such as where the search engine is based on keyword search; the search engine uses feature scores as a filter; training and scoring are done automatically without being triggered by the operator; or where scoring and sampling can be done asynchronously.
In another aspect, an integrated interactive labeling system includes a labeling component, a training component, a scoring component, and a sampling component, where labeling can be can offloaded as a service and labeling quality is measured by generalization gains. The integrated interactive labeling system may also include other features, such as where multi-class labeling consists of multiple binary labeling; or where multiple samples are labeled approximately simultaneously using system generated pre-labels, and a verification mode is included in the system to review approximate labels sorted by confidence.
Consider the example of building a classifier for web pages (the methods would work for queries, images, or other types). Assume that a user has access to 100 million web pages, referred to herein as the working set. These web pages may be biased by importance (e.g., high page rank) but they are not biased by the nature of the classifiers intended to be built. These pages are neither labeled nor ordered. Assume there is a small and biased set of positive and negative examples and that a classifier can be trained with these examples with reasonable generalization performance. (The “cold start” challenge for training classifiers with small data sets with good generalization performance is discussed below.) The result of training is called a “scorer.” Scorers have version numbers that reflect the set they were trained on. As soon as the first scorer is available, “scoring” of the working set begins. This process requires a large amount of computing power. As a result of scoring, the items can be ordered by their probability of being an “X,” where “X” is a class of the classifier to be built, i.e., where “X” is a positive example of the feature, or label.
The objective of ALE (Active Labeling Exploration) is to replace the long and arduous “data-collection, labeling, training and tuning, deploying” cycle by an interactive loop that runs in minutes or seconds.
ALE has three processes that run simultaneously. These are Sampling+Labeling, Training, and Scoring, as illustrated in Table 1:
The first process (Sampling+Labeling) is driven by the user. The user's task is to improve precision and recall by labeling items selected by the system. The user is oblivious to the training and scoring processes. From the user's point of view, the system simply chooses good patterns to label and the classifier increases its generalization capabilities with respect to an increasingly diverse set. The user may choose to label for precision or for recall, or that choice could be made by the system.
What happens behind the scenes is slightly more complex. When enough new labels have been collected, a family of classifiers (of different complexities) is retrained. The best classifier of the family becomes the latest scorer. Scoring is an intensive computation process. If the scoring from the previous scorer was not completed by the scoring process, the ongoing scoring is interrupted and the new scorer continues scoring items starting with the oldest scores first. Depending on the task and the size of the data, scoring could take minutes or hours. However, it is desirable that an operator should not have to wait for the querying process: At any point of time, every item should have a score (the scores may come from scorers with different versions), and all the scores should reside in memory. Since the querying is done by an independent process (distributed on several machines), a full linear scan over all the scores should be done in sub-second time (assuming one billion items and 100 machines). Training and scoring are run asynchronously by independent processes so they do not impact the querying response time. The quality of selection of which item should be labeled next degrades if too few items have been re-scored since the last scorer was produced. The ALE information flow is summarized in
Given new training data 420 and corresponding labels 418, the training 422 produces a new scorer 424. The new scorer produces new scores 426 which, after filtering 428, produce new training data 420. The filters 432 may include dictionaries, discussed below, and may also include previously created classifiers.
The cycle continues until the operator decides that the scorer's performance improvements are no longer worth the labeling costs. The result is a new classifier 430.
The “Feature Functions” input 410 depicted in
Coming back to
A. Interactive Problem Definition Refinements
The semantic meaning of the classification may change as a function of exploration. ALE provides the flexibility to evolve the task while it is being performed. For instance, one may start with the goal of building a “Home page” classifier. But as the system discovers candidates such as social media pages, obituaries, events, and other pages centered on a single individual during exploration, the definition of what is a home page needs to be refined. This is easily done interactively while running the ALE loop.
Building a classifier that performs well on data that is not known about when the task is started seems like an elusive goal. However, experience has shown that humans are trustworthy when it comes to labeling, even though they are ignorant when it comes to estimating the shape of a distribution. If humans are paired with a system that cleverly explores the distribution via exploration, very robust systems can be built. The ALE algorithm leverages both the scaling capability of computers and the human ability to provide semantic meaning through labeling.
Active learning has its challenges. Potential problems typically encountered in active learning algorithms include brittleness of uncertainty sampling, model selection (adapting capacity to the available data), exploration, active featuring, disjunctive classes, and cold start. The ALE system described herein does not have the brittleness of uncertainty sampling because it focuses away from the decision boundary. Automatic regularization (model selection) and cold start are discussed below. In a later section, active featuring and how it complements active labeling is described.
1. Lopsided Data and Reachability
Active learning is often viewed as a means to increase the efficiency of labeling on a fixed size set with a fixed number of features. In a typical machine-learning setting, the goal is to improve accuracy. The emphasis described herein is different in that it pertains to providing an exploration tool that will help the user add labels and features to produce a valuable classifier or schema extractor. With Big Data with lopsided classes, only a small fraction of the data will ever be observed and some nuggets of positive or negative may never be discovered. When they are discovered, one may as well assume that the distribution has changed. When the distribution is discovered on the fly, the basic assumptions on which machine learning relies—IID sampling for train and test set—are violated. If the number of positives is T and the size of the data is N, one cannot estimate recall without labeling a number of patterns that is proportional to N/T. If T<<N, one may never know what the recall is. Learning convergence on the overall distribution cannot be proven.
However, the overall classifier progress can be measured by means of a measure called reachability. As defined herein, reachability is the number of positives that are classified as positive by the classifier. Let S be the set of positives estimated by the classifier (depicted in ellipse 216 in
S={d: classifier output is positive}.
Let T be the set of true positives within the total data set (depicted in ellipses 214 in
T={d: d is positive}.
The reachability (R) is then the number of true positives within the set of positive estimated by the classifier (depicted as the intersection of the ellipses 216 and 214 in
R=|S∩T|.
Reachability can be represented in terms of either recall or precision, as p=r|T|=φ|S|, where r is the recall of the classifier and φ is the precision of the classifier. However, recall cannot be computed directly in this case as the set T is not known. However, because T is fixed, reachability is directly proportional to recall. To increase recall of the classifier, one can instead increase reachability. The goals of a classifier-building task can thus be formulated in terms of reachability and precision.
For example, let φ be the precision in S, i.e., the number of true positives inside S (the intersection of the ellipses 216 and 214 in
and let r be the recall in S, or the number of true positives inside S divided by the total number of true positives within the data set:
One can compute an estimate φ′ of φ by labeling a random subset (or all) of the examples in S. The number φ′|S| estimates the number of positives found by the system. The recall φ′|S| cannot be computed because T is not known. However, using an estimate φ′ of precision and an estimate φ′|S| that is proportional to recall, one can track the forward overall progress of the system. At a fixed (or non-decreasing) precision, increasing the reachability increases the recall. Increasing the precision at a fixed (or non-decreasing) reachability also increases precision for a constant (or increasing) recall.
There are other criteria that can also be used to measure progress. For instance, if most misclassified patterns that are discovered by exploration are ambiguous, then the classifier is doing well on precision; if most misclassified patterns are easily handled by adding features, then the classifier is exploring well.
a. Estimating Reachability
Reachability can be estimated based on the labeling strategy and the score distribution of the unlabeled examples. As an example of this, let L be the set of labels and U the universe, and let S be the patterns with score ≥τ, a threshold that one sets (the entire region in ellipse 216 in
Let
n
s
=|T∪{w: score(w)=s}|
be the number of positives with score s and let
and since ρ=|T∩S|=Σs≥τns, the reachability can be estimated by the following:
The expectation can be estimated, for instance, by sub-sampling the label set.
Note: The estimate above can be done in many different ways by covering the interval [τ . . . 1] by disjoint intervals. Not all decompositions are equal in that some will have smaller error bars in the estimation.
With large data sets with lopsided distribution, improving accuracy while assuming a uniformly sampled fixed distribution quickly reaches a state of diminishing returns. A more interesting problem is to view the distribution as a moving target and involve the operator in tracking it down. From a machine-learning theory standpoint, the two problems are very different. Both engineering challenges (scaling, process, user experience (UX)) and scientific challenges (exploration metrics, sampling strategies, revision training, among others) are encountered. The ALE algorithm addresses these challenges.
II. The ARCS (Automatic Regularization and Cold Start) Challenge
To work well, the ALE algorithm needs a few labels, a few features, and good generalization properties of the early classifiers. This requires solving two problems. First, both positive and negative examples are needed, as well as startup features. This is the cold start problem. It is difficult because in a lopsided distribution, the positive (or the negative) examples might be extremely rare. For instance, if the positives are less than one in a million, finding enough of them to get the classifier going could be time-consuming (using random sampling). Without features or a working classifier, the ALE algorithm is of no help. The second problem is automatic regularization. With only a few labels, the classifier needs to be heavily regularized to avoid over-training. Regularization needs to be adjusted automatically so that the complexity of the algorithm can be matched to the increasing number of labels. This could be called the “warm start” problem.
A. The Cold Start
The problem can be summarized as follows: Assume that a large database of generic examples of the same type T has been entered in the system, how does one distinguish them? To enable training, features (that distinguish the items from each other) are needed, and a means to find positive and negative examples is needed. This problem is addressed by providing modules that implement the IScorer <T> interface. The IScorer modules may be provided by the system or entered by an engineer (e.g., when the data is collected). A module that implements that interface can compute the function T→ScoreType, where ScoreType is a type understood by the system (e.g., a floating point number between 0 and 1) for all items in the database. The scores can then be computed on some or all the items, and be queried and sorted. This allows the operator to find the first examples of each class and to label them as such. IScorer modules can also be used as the first features of a classifier. The next cycle occurs through the ALE algorithm.
If the data type is known a-priori, one can provide some standard system features that are specific to the data. The data-specific features can even accept parameters from the operator. Such features can then be used to distinguish, filter, label, or explore the data. For instance, if the examples are web pages, a system IScorer <WebPageType> could be a module that computes the relevance of a web page with respect to a query. The query is the parameter of the feature and is provided by the operator. Once the query parameter is fixed, the module could run under the ALE algorithm, thus evaluating every web page for its relevance. Such implementation is very inefficient compared to a reverse index, but it has the advantage of being generic. Regardless of the data type T the operator can provide the following:
The system does not need to understand the type T. The module could be parameterized outside the system (the provided dll contains the query terms), or the system could provide means for the operator to set the parameters at run time (e.g., a query).
Given the ubiquitous need for text understanding, both a generic API (where the operator can input a module that implements IScorer <T>) and built-in text features may be supported.
The definition of a feature may be confusing. The strict definition of a feature is a function whose output is used as the input of a classifier (or schematizer). Since a query is a form of classifier, a feature can be used for querying. Since the output of a classifier can be used as the input of another classifier, classifiers are themselves features. Features come from three places: built-in, operator-generated (without training), and trained classifiers. Some built-in features can be parameterized by the operator (a hybrid). Some built-in features may only be available for certain data types.
For text features to be enabled, the type T of the items entered in the database must support the IWordCollection interface. This interface allows the automatic build of a reverse index, and enables an efficient query-like interface to the database. For databases that support this interface, the cold start problem is pretty much solved. When this is not enough, and for databases that do not support the IWordCollection, the operator can provide additional modules that support the IScorer <T> interface. Once the system has IScorer <T> modules that are powerful enough to effectively distinguish the items of the database, the cold start problem has been solved.
B. AR (Automatic Regularization)
In interactive machine learning, the number of labels and features varies over time, as labels and features are added. A classifier may be (re)trained successively with example counts of 10, 20, 40, 80, 160, as the labels are coming in. For each training session, the optimal regularization will be different. It is desirable that the system perform well even with very few examples because finding good examples to label next will help the system learn more quickly. Since this will in turn enable the system to select which examples to label next, the effect on generalization is compounded (each iteration increases the value of subsequent labels). The problem of performing well in the presence of few labels is referred to herein as the “warm start” problem.
Requiring the operator to manually adjust regularization introduces complexity and is unnecessary. For operators that are not familiar with machine learning, the concept of regularization is hopelessly confusing. Fortunately, given labels and sufficient computational power, one can train a small family of classifiers of different complexity and use cross validation to determine which one generalizes the best.
For instance, if the task is to recognize handwritten digits, one could have two classifiers: a linear classifier and a state-of-the-art, four-layer convolutional neural network (both take pixels as input and output a probability for each class). The second classifier does much better than the first when trained with 1000 examples per class, but it is comparatively terrible at scoring with fewer than 30 examples per class. The linear classifier produces a very decent classifier and scorer when trained with as few as one or two examples per class. It is remarkably easy to automatically decide which classifier to use if they are both trained and measured with cross validation. At the point where there are enough examples for both classifiers to be comparable, the operator cannot easily distinguish which classifier is better (they have the same generalization performance). This means that with proper timing, switching between classifiers with different regularization can be done transparently, automatically, and without the operator ever knowing.
Regularization is interpreted herein as constraining the family of learnable functions to a subset of functions more likely to generalize. This can be done at the output level, at the architecture level, or at the input level:
III. The Scaling Challenge
The ALE algorithm scales in two different directions. One is the ability to query, score, and train as a function of the number of items. The second is the ability to scale with the number of classifiers and schematizers provided by contributors. An exemplary summary of this is illustrated in
A. Scaling with the Number of Items
The leftmost column in
B. Scaling with the Number of Classifiers
The three rightmost columns in
Accessibility creates a large pool of people capable of building classifiers. Motivation increases the motivation of people in that pool to build classifiers. Efficiency multiplies the productivity. Motivation is described last below, because it encompasses the other two from a UX perspective.
1. Accessibility
Ordinary people do not understand machine learning. If the system requires machine learning expertise, then the number of available machine learning experts becomes a bottleneck. To circumvent this bottleneck, the interface may be restricted to only a few actions that require no engineering skills. The interface has guardrails that discourage behaviors that are not compatible with improving generalization. The actions of the operator may be limited to the following:
Note that “training,” “scoring,” and “regularizing” are not standard actions. These computations happen implicitly and transparently. As a result of these activities, the operator will observe a change in the types of errors presented to him or her. This is both an effect of improving precision, and what will contribute to the next precision improvement. Similarly, new patterns will be extracted for labeling. This is both an effect of improving recall (and in some case precision), and what will contribute to the next recall (respectively precision) improvement.
There will be some progress metrics like precision or estimators of the number of positive or negative examples found by the system, or the rate of improvement around the classifier's class boundaries. Metrics will be displayed with errors to encourage a data-focused approach to training. The use of automatic features is limited to encourage the operator to provide valuable concepts and labels instead. To explicitly discourage over-training, the test set is constantly recycled so there are no benefits to fixing a single error, but rather benefits manifest by fixing categories of errors. The operator may have no machine learning background to start with, but the UX is optimized to train him/her to improve generalization.
2. Efficiency
The efficiency could be measured in how much energy it takes for an operator to create a classifier with a given precision and recall. This definition can be problematic because one does not know what recall is (on a large data set with few positives, it may be very difficult to know how many positives there are). Even the class definition may not be well defined until some examples are discovered: Is an obituary a home page? Is a cocktail mix a cooking recipe? These questions are likely to arise only during the building of a classifier. Two assumptions are made: First, assume that it is possible to compare two classifiers and unambiguously determine that one is better than the other (better recall, better precision). Second, assume that improving a classifier may include having multiple “revision cycles.”
A revision cycle is defined as an operator input that is a function of a computation, followed by a computation that is a function of the operator's last input. At each cycle, the problem is revised in at least one of three ways: the class definition changes, the distribution of examples to label changes, or the input space changes. These quick and targeted revisions of the problem are different from traditional machine learning. In traditional machine learning, the distribution is usually constant (optimization of the features on a fixed training set). Even in active learning papers, progress is measured on a fixed distribution: the emphasis is on reducing the number of labels to achieve a given error rate on a fixed distribution, rather than exploring and discovering the distribution. A true cycle (or a revision) typically takes months. In contrast, the ability to have tens or hundreds of cycles in a single day radically changes the efficiency of classifier building. The cycle effects are compounded. For instance, when a classifier becomes better as a result of a cycle, it becomes better at finding positive or false positive for the next cycle.
In the system described herein, cycles come in three flavors: active labeling exploration (ALE), active featuring, and dictionary refining. The first, ALE, has been discussed in a previous section. Active featuring is the activity of creating a feature for the purpose of allowing a classifier to discriminate between positive (respectively negative) and false positive (respectively false negative). It is akin to curing the classifier of “color blindness.” Active featuring is the object of the next section. The last form of cycle is specific to the definition of a concept. A concept is defined herein as a group of words, or a dictionary, that defines a concept when the words are viewed as a group (e.g., the concept of car brand is defined by the list of words “Honda,” “Ford,” “Peugeot,” and so forth). The cycle of dictionary refinement results from an operator giving positive and negative examples, and computation provides concept generalization candidates from these examples. The operator can then correct the generalization (by striking out words or adding new ones) and so on. The dictionary refinement cycle is described in a later section.
Each cycle requires heavy computation followed by targeted semantic input from the operator. This might be inefficient from a computing point of view, but it is efficient from the operator's view point. The operator only needs to work when the system fails to generalize properly. The overall architecture (active labeling and active featuring) is organized to surface these failings early.
3. Motivation
Accessibility opens up the number of people that could write classifiers. However, that is not enough. Some sort of “magic” is necessary to generate viral adoption. Current machine learning tools are designed by engineers for engineers. They are devoid of magic. This section is about increasing motivation to build classifiers by carefully designing the UX.
To most people, machine learning is complicated and mysterious. Building a user interface that allows machine-learning-illiterate operators to teach a machine learning system to perform recognition and schematization tasks is a challenge. Described below are simple UX principles, which are designed to make the system understandable and trustworthy:
The transparency principle makes the system less mysterious and dangerous. The responsiveness principle allows the user to have immediate feedback on their action and learn the “derivatives” of their action. The progress principle identifies the direction to follow to reach the desired state.
To enable learning, labels and features are needed from the operator. If the labels and/or features change the state of the system, the first principle implies that the labels and features should be accessible and editable. This has several implications:
The first principle will be violated occasionally, but hopefully this will not affect the trust of the operator in the system. For instance, certain features may be automatically provided as system services, like synonyms, misspellings, click graph, and so on. One could freeze these functions, but it might be better to freeze their semantics and let the features be updated regularly and transparently (with a small cost to predictability). If a classifier learns to depend on the semantic meaning of the feature, then regular updates of the feature will improve the classifier. Surprisingly, one may even introduce artificial noise in the system to drive the concept that machine-learning only provides statistical guarantees, not single-pattern guarantees. The resulting non-determinism does not affect the overall performance, but it discourages novice users from over-training.
The responsiveness principle allows users to quickly learn how to operate the system (feedback). It also produces rewards by translating actions into progress. Every label and every feature should create a visibly better classifier. This is difficult for three reasons: retraining a classifier after every action is expensive. Rescoring all items with every new classifier is even more expensive. And finally, many operator interventions may be necessary for the classifier to show a visible and statistically significant improvement. If exploration changes the distribution significantly, the global metrics may be affected in unpredictable ways. These challenges are compounded by the fact that retraining and rescoring should be transparent. Without infinite resources, the immediacy and visibility aspects of the design principle will be compromised (for instance, by not retraining on every operator input). This can be alleviated by increasing the number of resources dedicated to training and scoring, retraining at regular and frequent intervals (e.g., every 50 labels), and taking advantage of partial scoring (in the ALE algorithm, the query/filtering returns without waiting for every item to be scored). Unsurprisingly, the responsiveness principle is best addressed by increasing the number of resources (compute power) and clever management (partial computation).
a. Error Categorization
The progress principle implies that the operator always knows when the job is done and what to do to make the system better. Neither of these two things is simple. When should one stop improving a classifier? How does one know how to improve a classifier? To help answer this question, the errors made by the system are categorized in three buckets:
One need not be concerned about this case because the learning problem can be simplified by adding good features, and for most machine-learning algorithms adding features increases capacity. Therefore, one could only encounter this error as a result of a feature limitation, which would make it a “Color-blindness” error. Conversely, there could be a case where the capacity is too high. In this case, the symptom would be that a large number of “ignorance errors” would be observed even after adding a large number of labels.
The choice of machine learning algorithm, the expressiveness of the features, and the quality of automatic regularization affect how long it takes to learn and what is the best result that the system can achieve. However, these can be modified and improved without having to redesign the user interface.
The error categorization helps us address the progress principle, e.g., the first type of error (ambiguity) suggests the desired state: If the majority of errors fall in the “ambiguity error” category, the operator is done. The system has little hope of surpassing the operator. If a large fraction of errors are due to color blindness or ignorance, the operator knows what to do: Color-blindness errors are fixed by adding features that distinguish positive from false positive or negative from false negative. One can design an interface to enable this (next section). Ignorance errors are fixed by adding labels. At any point in time, the system can suggest which type of errors should be addressed for maximum efficiency. If the training and testing error curves of the learning algorithm are close, more features are needed. Otherwise, more labels would be more effective.
b. Immutability
For the path from the present state to the desired state to be unambiguously clear, one should guarantee that progress is always going forward. This should earn the operator's trust. It requires some precautions. Once a classifier is trained, it can become a feature. Once it becomes a feature, it is not allowed to be retrained as part of a larger model. Retraining a feature as part of a larger classifier could have several negative consequences: First, it could change the semantic meaning of the feature. This could cause operator confusion and backward progress on other features. Second, the capacity of the feature when it was trained may be much higher than the number of labels available on the larger classifier. The unexpected infusion of capacity could cause a backward step. Machine-learning experts may object that freezing the parameters might be suboptimal from a machine-learning standpoint. However, as described herein, system stability and predictability trump optimality.
Progress can be measured with metrics. For instance, the number of positives found by the classifier multiplied by the precision can yield an estimate on the number of positives reached by the system. This metric is proportional to recall. The precision progress per label made on the boundary (e.g., all the patterns that had a probability of being X between 0.25 and 0.75) is an interesting measure of efficacy.
Motivation comes from magic. The magic comes from the system generating three things:
With accessibility, efficiency, and magic, building classifiers will produce both value and wonderment. This will allow classifiers and schematizers to be built at scale.
IV. Active Featuring
A. Featuring
A common activity in machine learning is to search for the right features. People typically do this in an ad hoc way: adding a feature via programming or processing the data, starting a completely independent process to retrain the system on the modified data, then they look at the errors, and so forth. None of it is typically integrated in a system where errors can be browsed and features can be shared and searched without exiting an application. As described herein, active featuring enables interactive feature creation, editing, and refinement.
Some methods for helping users select features to fine tune a system's performance either select features automatically (e.g., Bag of Words) or select from a number of pre-existing features (model selection, feature selection, and so forth). Active featuring encourages the user to interactively create useful features, and the complexity of the machine-learning algorithm is kept to a minimum. The idea is that it is better to fix errors interactively by adding features and labels than it is to avoid errors by adding complexity in the machine-language algorithm and the feature selection. Complex learning algorithms and a large number of features are likely to work well in an initial phase, but may quickly leave the practitioner with a complex system that no obvious decision can improve; in which case removing errors is prohibitively difficult. In contrast, an interactive loop that allows the user to add features and labels while relying on a simple learning algorithm may yield a more actionable system. When the user has contributed every label and every feature, the errors may become clearer and easy to fix (either by creating/editing/refining a feature or adding labels).
As described herein, features can come from 1) pre-existing system features, 2) pre-existing features created on the system by other users, and 3) features created on the fly by the user. For 3), two categories are distinguished: 3a) features that are themselves classifiers and entity extractors built interactively using active labeling, and 3b) word features that are created by entering a list of words (also called a dictionary) to capture a “concept.” For instance, a list of months (January, February . . . ) captures the concept of “Months.” The words in a dictionary together form a feature that can be utilized by computing statistics between a document and the given dictionary (how many words in the dictionary appear in the document, how many distinct words of the dictionary appear in the document, and so forth).
In one aspect, an integrated active learning system includes a browsing component, a training component, a scoring component, and a user-operated feature-creation component. The integrated active learning system may include one or more other aspects, such as where searchable features are classifiers created within the integrated active learning system, a search for features is guided by labels and classifier scores and validated by the operator, classification errors are organized and displayed to suggest and fix classification feature-blindness, or features are created and shared by multiple operators and stored on a commonly accessible system.
In another aspect, an integrated system includes a browsing component, a training component, a scoring component, and a feature-creation component based on user-provided dictionaries. The integrated system may include one or more other aspects, such as where the number of parameters for the feature dictionary is independent of the number of words in the dictionary, or the user can specify whether the parameters are common to the all the words in the dictionary or individual to each word in the dictionary.
By design, the interfaces described herein are agnostic to which learning algorithm is used. In this section, the creation of features is discussed.
Consider an input space D. For each data item dϵD, compute a classification value y from an output space O. To do this, a classification function g is used, which maps a point dϵD and a parameter vector w of the parameter space W to a vector yϵO. The space of such functions is denoted G:
G:D×W→O
g:d,w→g(d,w)=y
For instance, the data space could be the space of web pages, the parameter space W could be a vector of real values computed by a machine learning algorithm, and the output space O could be a number between 0 and 1 representing a probability of being of the desired class for each web page. One problem with this formalism is that the space D may be extremely complex and the set of function G that maps D×W to O could be too large to be trainable from a few labeled examples. For instance, if d is a web page that is truncated to, at most, 100K words, then given a dictionary of, at most, 10M words, the input space's dimension could still be 1012. To simplify the problem, the space D is projected to a lower dimensional space I, which herein is referred to as the “feature space.” The set of projections is denoted F. The projection ƒϵF: D→1 is fixed during the training of the parameters. One can now restrict the learnable function from G to a space G′ that verifies
G′(ƒ,h)={gϵG|∃wϵW,g(.,w)=h(ƒ(.),w)}
where h is a function that maps the feature space and the parameter vector to the output. The space of function H:1×W→0 is determined by the learning algorithm. The feature space I induced by F and the learnable function space H are chosen to make the learning of the parameters w easier and require as few examples as possible. For instance, for web page classification, the feature function ƒ could be extracting the term frequency ƒi normalized by the inverse document frequency (tf*idf) for the k most relevant terms (e.g., k=1000) to the classification task. In other words, given a web page of data d, the featurization function computes a feature vector x=ƒ(d)=(ƒ0, ƒ1, . . . , ƒk), where ƒi is the normalized number of occurrence of term i in document d and ƒ0=1. The classifier could use logistic regression to compute the classification function:
h(x,w)=logistic(wTx)
Once ƒ and h are defined, traditional machine-learning algorithms can be used to estimate the parameters w using a set of training examples (xj, lj) where xj=ƒ(di) and lj are respectively the jth featurized example and its label in the training set. Of interest here is a scenario where an operator building a classifier is allowed to contribute both labels 1 and feature function ƒ.
In previous sections, active labeling was discussed as a procedure for exploring and improving the classification space. Following is a discussion of the input side equivalent of active labeling: “active featuring.”
B. Color Blindness
There is a significant amount of literature related to the automatic selection of features. It is sometimes referred as “feature selection.” The implicit goal of automatic feature selection is to improve generalization given a training set. The goal as described herein is different: Provide the operator with a means to contribute the feature-equivalent to labels. This is following the principle described above that humans should contribute semantic meaning and computers should provide scale. In the previous section, three classes of errors were distinguished: ambiguity, ignorance, and color blindness. Ambiguity errors are beyond fixing (they come from the operator or the intrinsic noise of the problem). Ignorance errors are fixed by adding labels. Color blindness errors are fixed by using “color filters,” or following machine-learning terminology, by adding features that allow the system to “see” the difference between members of one class and members of a different class.
The interface for featuring may be problem specific. For instance, a feature could be a function of pixels in image recognition, a function of words in query classification, or a function of cepstral coefficients in speech recognition. The operator is not required to understand pixels, cepstra, or bag-of-words to build a classifier. But there is a need for someone that does to set up the problem. Two kinds of users are therefore distinguished:
Once the engineer has set the problem, operators can build multiple classifiers and schematizers. At the beginning, the inputs of the new classifiers are the generic feature(s) provided by the engineer or the system. Once some operators have built and trained some classifiers, they can be frozen into features. As described above, features are immutable. These new features then become available for input for building higher level classifiers, thus creating an eco-system.
An operator could build a classifier by selecting a few features and then turning to the ALE algorithm to add labels. Indeed, many systems in machine learning operate from a fixed set of features. For big data with lopsided distribution, however, one does not know a-priori which features will be needed. The need for new features is likely to manifest itself through exploration. For instance, while building a cooking recipe classifier, it may be useful to have a feature that identifies ingredients found in African recipes. The operator may not have known about the existence of African recipes and their specific ingredients until they are discovered through exploration. When building a car detector, having a wheel (or circular shape) detector as a feature would make the segmentation problem a lot easier. The operator may not have known that the problem was too hard without this additional feature until she attempted to build the classifier. To address this limitation, the operator should have the flexibility to add features as needed. In active featuring, an operator inspects the errors made by the classifier, and searches for features that enable the classifier to easily distinguish portions of positive from false positive or conversely, portions of negative from false negative. In other words, the operator is looking for “color blindness” on the part of the classifier. Once color blindness has been identified, the operator can focus on creating a feature to provide a “color filter” in order to cure the blindness.
The active featuring process is a loop in which the operator inspects errors, creates features and/or edits/refines features, retrains the system, and re-scores the labeled examples for the next iteration. However, creating new features often requires new labels. So the active featuring process is itself embedded in a large loop, which involves both active featuring and ALE, herein referred to as the RAFALE (Repeat Active Featuring Active Labeling Exploration) loop. This is summarized in Table 2:
To create a feature, the operator has 3 choices: 1) find a system feature or a feature created by another operator (using a search engine), 2) create a custom-made classifier to implement the desired feature, or 3) create a domain specific feature. The first choice leverages the power of a community. The second choice leverages the ability to quickly create a classifier using an integrated tool. This ability is not generally available because labeling, training, scoring, and featuring are typically done with different tools and often different people. The third choice depends on the domain. An interface is described below for entering domain-specific features for items containing lists of words.
C. Words and Dictionaries
In many applications of machine learning, the basic features are words, which may include individual words, stemmed versions of the words (e.g., words in which inflection denoting plural, past tense, and so forth have been removed) as well as n-grams (sequences of consecutive words or stems). Often, the representation of choice is bag-of-words. In this representation, the features are based on the frequency of each word (TF: term frequency) in a document with some normalization (IDF: inverse document frequency). While it is possible to get good results with these features, they lack the power of expressing and generalizing to concepts. For instance, while it is possible to count the frequencies of Honda and Toyota in a document, it is preferable to have features that generalize to all the car brands.
Described below is a tool for interactively building dictionaries that represent concepts, for the purpose of being used as features for classification or entity extraction. Concepts are created interactively as part of the active featuring loop to address the errors made by the machine-learning algorithm.
In this section, the items in a database are assumed to be documents made up of words. However, the concepts of documents and dictionaries as described herein are not limited to the use of words, and may include other kinds of data. The assumption is also made that the words inside a document have no inter-relationship (bag-of-words model), and a TF*IDF vector representation is used as the basic feature vector. Before the notion of dictionaries is introduced, this representation needs to be explicitly described.
Assume that C is a collection of documents in the database, and T is a set of terms that are relevant for the classifier that is to be built. For instance, T could be the set of all the words that appear in the corpus C. For each document d and term t, the term frequency tf (t, d) can be computed, which is the number of occurrences of word t in d divided by the length of the document. Intuitively, the term count represents a direction in the semantic space of words. It is normalized by the length of the document to be invariant to verbosity. All the terms do not carry the same amount of information. In particular, the number of bits communicated by the statement “the term t occurs in document d” is given by the formula:
where |C| is the cardinality of C and |{dϵC: tϵd}| is the number of documents where the term t appears. This quantity is also called the inverse document frequency. For each document d, the tf*idf feature vector representation of document d is defined as
x(d)=(tf(t,d)*idf(t,C))tϵT
and has two useful properties: it is invariant to the length of the document and the variance of each word feature is proportional to its information content. Table 3 summarizes how the tf*idf representation is computed:
3.1
2.3
6.8
0.5
The tf*idf value is computed by dividing the counts by the document length (last column) and multiplying the result by the inverse document frequency (the last row). The resulting row vectors are the feature representations of each document.
If logistic regression is used for classification, it is desirable to regularize the weights and to not rescale the input to adjust their variance. This is because in the word space, the problem is very high-dimensional and there are very few labels. For logistic regression, the classification function is:
where xp is the feature representation of pattern p, yp is the output of the classifier and i is an index over the terms of T. The objective function is:
where lp is the label for pattern p, and λ is a regularization parameter. One should realize that |T| may be several orders of magnitude larger than the number of labels. The regularizer could be |w|2 or |w|. If there were no regularizers (i.e., λ=0), the idf normalization could be absorbed into w during training.
If each word in a given dictionary is given its own weight, then the system becomes more equivalent to bag-of-words. The idea is that an operator could communicate invaluable information to the classifier by specifying features that capture semantic meaning. The operator is allowed to single out words in small groups and the individual small group can still have a shared weight, which might be important for additional regularization constraints. If all the words in the dictionary share the same parameter, then their semantic is also shared.
For instance, when building a classifier for automotive, a feature could be a dictionary of all the car brand names, such as {“Toyota,” “Ford,” “Peugeot,” . . . }. Another interpretation of featuring is that the operator is “tying” the parameters of the model. Imagine that the tf*idf representation is still being used, but that the parameters for the terms in the dictionary {“Toyota,” “Ford,” “Peugeot,” . . . } are tied to a common value. The generalization value is immediate: if the dictionary contains rare car brands (e.g., Maserati), the classifier can perform well on documents about that car brand even though no labeled document in the training made any reference to cars of that brand. For example, if both the words “Honda” and “Maserati” appear in a car brand dictionary and if the word “Honda” appears in many training examples, the system will be able to generalize to “Maserati” even though no examples of “Maserati” appear in the training set.
It is possible to have a system that is in between having a weight per word in a dictionary, and a single weight for the whole dictionary. This is done by having a weight per word, but by constraining the weights within a dictionary with a regularization constraint. As soon as a dictionary is entered, the corresponding weights have a common shared value (many gradient descent learning algorithms generalize easily to the weight sharing concept). The idf scaling of the term frequency contribution is desirable because terms that carry less information should not have an equal weighting on the value of the shared weight. After scaling, all the parameter wj contributions are comparable. The weight sharing constraint can be relaxed and one can induce groups of weights to be similar. As one example, one may constraint a group of weights to be close to their average. In that case, a regularizer may be used to tie the group of weights to their average, such that the weights of the words within the dictionary are constrained to not deviate too much from their average. An exemplary regularization constraint could have the form:
where E is the set of dictionaries, Jc is the set of indices for the terms in dictionary c,
The weight for each dictionary can be scaled as a function of document frequency or dictionary size prior to applying the regularization constraint, in order to keep each weight on comparable scale. In effect, in the previous example, this allows the word “Honda” to transfer its knowledge to the word “Maserati” through the regularization constraint, but it still allows the word “Maserati” to have a different weight if there is enough “Maserati” data to pull the weight in a different direction.
D. Interactive Concept Editing (Active Conceptualizing)
As an example of creating a classifier, assume the goal is to create a classifier for “home pages”:
The dictionaries might be created in this order (it is hard to guess until the tool is built):
The first four dictionaries help find positives (remove false negatives). The following two reduce the number of false positives. This process is highly interactive. It is difficult to know which dictionary will be useful without building the classifier. The user may decide to create a classifier for obituaries or for events on the fly. This process is recursive. The features/classifiers created on the fly are not required to be good. To be useful, they only need to be better than chance and bring new information.
1. Issues
In one aspect, an integrated system includes a component with means to display training patterns, a training component, a scoring component, and a dictionary-editing component. The four components are used in an active featuring loop. The dictionary-editing component contains an interactive loop to allow the operator to edit and refine concepts characterized by lists of words or group of n-grams.
In another aspect, a dictionary feature is provided in which each word or n-gram in the dictionary has its own weight. The weights of the dictionary can be rescaled by a function of frequency and dictionary size. The rescaled weights are tied by a regularization constraint that pulls the weights of the words that have less training data toward a default value determined by the words that have more training data.
In another aspect, a dictionary interface is provided for constructing the features of a classifier or entity extractor. The interface allows concepts, defined by a large list of words or n-grams, to be specified interactively by providing a small list of positive or negative word or n-gram examples. At each iteration, the concept list is automatically expanded using a collection of algorithms and editing by using input.
In another aspect, a dictionary interface is provided for constructing the features of a classifier or entity extractor. Each feature is composed of a list of words or n-grams. The interface allows the operator to specify options on how the feature is computed. The generalization effects of various options alternatives are computed on a validation set and previewed.
2. Dictionary Creation
A dictionary can be viewed as a concept. As a concept, it can be generalized. When an operator types a few positive examples for a dictionary, the system can provide suggestions for possible generalizations. If the generalization is too aggressive, the operator can provide feedback by adding negative examples. This becomes an iterative process where the operator provides positive and negative examples to guide the system toward the correct generalization of a targeted concept. This follows the philosophy described above: the operator provides semantic meaning, and the system provides computation at scale to refine the meaning. This section is divided into two parts: A user interface for active conceptualization, and a collection of algorithms for concept generalization.
a. Active Conceptualization Interface (ACI)
The goal of the interface is to help the operator communicate concepts to the system in order to create dictionaries. The dictionary creation and editing can be done in a feedback loop where the user provides a list of positive examples.
Words from the suggestion sets 810 may be added to a working set 812 by clicking on a corresponding Add button 814. Words clicked on, or selected, in the suggestion sets 810 are added to positives 816. Words selected in the working set 812 are added to a negative set 818. Other methods for adding positives 816 and negatives 818 may also be used, such as clicking on the suggestion set words 810 to add positives and shift-clicking on the suggestion set words 810 to add negatives. For large sets, the operator can copy an entire suggestion set 810 to the working set 812. The suggestion sets 810 are recomputed for each edit. Clicking on the Done button 820 submits the union of the positives 816 and the working set 812 as a new dictionary. Alternatively, clicking on the Clear button 824 clears the words from the working set 812.
The dictionary editing interface could present machine-learning options (e.g., check box, thresholds) that constrain how they are used as features. For instance, a dictionary interface could have checkboxes or dialog boxes for:
The dictionary option interface can preview the generalization effects of each option by training the classifier or entity extractor with or without the option and by measuring its performance on a validation set.
When the operator is finished, the union of the positive set and the working sets is saved as the new dictionary. This interface is very interactive in the sense that the system provides immediate feedback to the operator as to what it understood to be the concept. The operator can react and refine the system's interpretation.
There are many ways to generate valid concepts captured by a list of words. Some points are:
b. Active Conceptualization Algorithms
The ACI can be used to allow the operator to interact with different active conceptualization algorithms. For example:
Each of these algorithms provides a different form of generalization. It is fortunate that a common interface can be used for an operator to interface with all of them. The ACI allows an operator to enter concepts implemented by large dictionaries with relatively few interventions.
3. Dictionary Smoothing
One issue with using dictionaries to define a classifier is that a dictionary may be likely to misfire on a word that occurs in multiple, unrelated contexts. For example, suppose a dictionary for movies is built by inputting a list of movies found on the Web. However, the list includes a movie called “It.” The problem with a movie called “It” is that the word “it” may appear in almost every document in the database. This may significantly impact the dictionary's ability to measure the presence of the intended concept. As another example, suppose a dictionary is created for “months.” It misfires on sentences like “May I help you,” and “I had dinner with April.” The problem is that in the wrong context, the word misfires and introduces errors.
Such potential misfiring can be addressed by means of dictionary smoothing. The idea of dictionary smoothing is that the context of a particular word may be used to try to predict whether the dictionary should fire on that word or not. The context of a given word includes some number of words that immediately precede and follow the word. With regard to the “months” dictionary, for the word “May,” all the instances of “may” throughout the entire corpus might be considered. For each instance of “may,” the two words before and the two words after the word “may” might be examined, for example. Based on those four words, a prediction may be made as to whether the word in the middle (“may”) is a month or not.
Continuing with the example of using the two words before and the two words after the given word, suppose that one looks at every possible group of five words in a corpus. Suppose the corpus contains 100 million pages, and every page has an average of 2000 words. For every group of five words, one may predict whether the middle word is a month from the other four context words. This may be done by counting word occurrences over a large corpus. For each word, one may count the number of times it occurs in a group of five words in which the middle word belongs to the month dictionary. Similarly, one may count the number of times the word occurs in a group of five words in which the middle word does not belong to the month dictionary. With these counts, one may estimate the probability that a group of five words contains a dictionary word by looking only at the four context words.
For example, one might predict that “1998” is a good predictor of a month. So, the phrase “May 1998” helps to determine that the dictionary should fire on that occurrence of “May.” Every four-digit number may be good predictor of months. However, in the sentence “May I help you,” the word “I” might be a good predictor of “may” (as a non-month), but is not a good predictor of “February,” i.e., “February I help you” is not a phrase that would occur often, if at all.
Additionally, one may choose not to train the system on problematic words, e.g., don't train the system on the word “May.” In that case, the system is only trained to predict the desired concept without “may,” and so the word “I” will not contribute at all for “May I help you,” but “1998” will contribute because there are many examples of other months that occur in the context of “1998.”
Another way of describing dictionary smoothing is to look for word substitutability, i.e., whether other words in the dictionary can be substituted for a given word. In a text window (i.e., the context of the given word), one may determine whether the middle word can be alternatively replaced by some of the dictionary words. For that purpose, one may examine a probability estimate, for each substituted word, that the middle word belongs to the dictionary either using the counting technique defined above, or other language modeling techniques.
For instance, suppose a car brand dictionary includes the terms Honda, Toyota, and Ford, and the sentence “President Ford came into Office in 1973” is being evaluated. Without dictionary smoothing, the dictionary would misfire on “Ford.” But if other car brands are substituted for “Ford” in that sentence, e.g., “President Honda,” or “President Toyota,” one may determine that the phrases “President Honda” and “President Toyota” do not occur, or rarely occur, within the entire corpus, and can thus determine that a context of “President X” is very unlikely for a car brand. As a result, the dictionary no longer fires on the phrase “President Ford” because within that context the other words in the dictionary cannot be substituted for “Ford.” This eliminates a large number of misfirings.
A detailed discussion of Dictionary Smoothing follows. The notions of context and dictionary are defined, and then estimating the probability of words belonging to a dictionary as a function of contexts is described.
a. Context
Given a document a and a position p, a word extraction function is defined as
e:(a,p)→w
which returns the word at position p in document a. Given a set B=(b0, . . . , bl-1) of relative position to p, the context extraction function eB is defined as:
e
B:(a,p)→e(a,p+b0), . . . ,e(a,p+bl-1)
where e(a, p+br) is the word in document a at the r′th offset br with respect to position p. For example, for B=(−2, −1), eB(a, p) returns the two words in document a just before position p. If document a is “The quick brown fox jumps over the lazy dog”, then e(−2,−1)(a, 4)=(brown, fox). Note that for B=(0), eB=e.
Notations: B=(b0, . . . , bl-1) is used to denote an ordered list. Equality between ordered lists requires all the elements to be equal and the order to be respected. However, in b E B, B is treated like a set (bϵ{b0, . . . , bl-1}). The notation ei is used as a short form of eB
Given a context extraction function ei, the contextual predicate ciw is defined as:
c
i
w(a,p)=(wϵei(a,p))
which means that the observed word w is in the context i of position p in document a. This predicate assumes that the position of word w in the context is not important.
Similarly, the formula
c
i
w
, . . . ,w
(a,p)=((w0, . . . ,wl-1)=ei(a,p))
is defined to mean that the observed words w0, . . . , wl-1 are (exactly) the context i of position p in document a. To simplify computation, two assumptions are made: assume that position within a context is not important, and that the presence of each word within a context is independent of the presence of the other words. These assumptions lead to:
b. Dictionary
A dictionary D={d0, . . . , dk-1} is defined as a set of k words.
c. Probability
Given a dictionary D and a set of m context functions ci, it is desirable to compute:
P(e(a,p)ϵD|c0o
which is the probability that the word at position p in document a is in dictionary D, given that words o0, . . . , om-1 were observed in context 0, . . . , m−1. To simplify notation, cr is used as a short form for cro
Naïve Bayes: Using the Naïve Bayes assumption that the contexts are independent and the words within the context are independent, one can write:
where or=w0, . . . , wl-1. The result is:
where δ(predicate)=1 if predicate is true and 0 otherwise.
The counts can be pre-computed:
which then allows the efficient computation:
This computation is O(Σi|Bi|) where |Bi| is context i's size.
To compute K, one also needs to evaluate:
P(e(a,p)∈D|c0, . . . ,cm-1)=KP(c0, . . . ,cm|e(a,p)∈D)P(e(a,p)∈D)
Again, using Naïve Bayes:
where or=w0, . . . , wl-1. The result is:
The counts can be pre-computed:
Note that the quantity CountWordContextAll(j,i) is independent of the dictionary. This means that CountWordContextNot(j,i) does not actually require a table for this dictionary (it can be computed from CountWordContext(j,i) on the fly).
which then allows the efficient computation:
and from that, one can compute:
i) Probability at the Dictionary Word Level
It may be desirable to compute the probability that a word is a given word of the dictionary given context:
P(e(a,p)=wk|c0o
where wk is a specific word in the dictionary.
where δ(predicate)=1 if predicate is true and 0 otherwise.
The counts can be pre-computed:
which then allows the efficient computation:
Computing K also includes evaluating:
P(e(a,p)≠wk|c0, . . . ,cm-1)=KkP(c0, . . . ,cm|e(a,p)≠wk)P(e(a,p)≠wk)
Again, using Naïve Bayes:
where or=w0, . . . , wl-1. The result is:
For this, the following quantities are needed:
Note that the quantity CountWordContextAll(j,i) is independent of the dictionary. This means that CountWordContextKNot(k,j,i) does not actually require a table for this dictionary (it can be computed from CountWordContextK(k,j,i) on the fly). The following computation can then be performed efficiently:
ii) Probability with Word Left Out
It may be desirable to compute the probability that a word is in a dictionary minus word wk given context:
P(e(a,p)ϵD−{wk}|c0o
where wk is a specific word in the dictionary. Note that, if e(a,p)=wk, the probability above reflects the probability of all the other words in the dictionary. For instance, in the sentence “President Ford was the 38th president of United States,” the probability above will have been trained with all the words in the dictionary that are different from “Ford.” If the dictionary is {“Honda”, “Ford”, “Toyota”}, the probability would be very low since there are not many “President Honda” or “President Toyota” instances. So the probability would correctly predict that “Ford” in the sentence is not a car brand.
where δ(predicate)=1 if predicate is true and 0 otherwise.
The counts can be pre-computed:
CountWordContextDictMinusK(k,j,i)=CountWordContext(j,i)−CountWordContextK(k,j,i)
CountDictMinusK(k)=CountDict−CountK(k)
which then allows the efficient computation:
Computing K also requires evaluating:
P(e(a,p)∈D−{wk}|c0, . . . ,cm-1)=KkP(c0, . . . ,cm|e(a,p)∈D−{wk})P(e(a,p)∈D−{Mk})
Again, using Naïve Bayes:
where or=w0, . . . , wl-1. The result is:
For this, the following quantities are needed:
Note that the quantity CountWordContextAll(j,i) is independent of the dictionary. This means that CountWordContextDictMinusKNot(k,j,i) does not actually require a table for this dictionary (it can be computed from CountWordContextK(k,j,i) on the fly). The following computation can then be performed efficiently:
4. Feature Completion
Feature Completion is a more generalized approach to Dictionary Smoothing. Learning techniques to automatically classify documents infer a classifier from a set of labeled training instances. The inferred classifier is a function, which takes a set of input features, i.e., measurements that describe the document, and outputs a class label. One can mainly improve the accuracy of a classifier following two alternative paths, either by acquiring more labeled training instances, or by relying on better features. Feature completion is directed toward the second approach and aims at facilitating the design of better features.
A feature is a function that maps the raw representation of the document (e.g., sequence of characters for text, map of pixels for images . . . ) to an intermediate representation that the classifier relies on (e.g., the number of occurrences of a given word or the presence of a specific color in the image). Most features are built from a simple human intuition about the types of measurements that a classifier could rely on (e.g., a classifier that detects faces in images could use the presence of skin color as a feature). However, the conversion of an intuition to a function that maps the document representation is a complex, imperfect task.
Feature completion facilitates this conversion process. It takes as input the initial feature given by the human and provides a complementary feature that complements the first one, so that the combination of both features is closer to the initial intuited measurement. For that purpose, it relies on a large dataset of unlabeled documents. The raw representation of the unlabeled documents is divided into the part that the initial feature uses (representation A) and the rest (representation B). Given this set of paired representations on the unlabeled set, a learning algorithm is applied to infer a function that takes representation B and predicts the output of the initial feature on part A of the same document. This function is a complementary feature since it behaves similarly to the initial feature but relies on the complementary part of the raw representation (i.e., representation B). The combination of the initial feature and the complementary feature may be closer to the initial intuition since it uses the remainder of the document that the initial feature implementation did not manage to exploit. The combination of the two features is also more robust to noise since corruptions are unlikely to affect representation A and representation B in the same way.
One should note that the classifier determines how to combine the initial feature and its complementary counterpart. This means that the learning algorithm determines for the user whether a complementary feature should have little influence (since the initial feature was already high quality) or more influence (since the initial feature was poorer quality).
In one aspect, a system and method are provided to build complementary features. Each complementary feature is built from an initial feature and a large set of unlabeled data. A complementary feature is a function that takes as input the part of the raw representation the initial feature is not using. It is built by trying to predict the output of the initial feature from this complementary representation over the unlabeled data.
In another aspect, the system and method may include one or more additional features, such as where the initial feature measures the presence of a disjunction of words or n-grams (sequence of words) at each position in a text stream, while the complementary feature input consists of a window of text around the considered position in which the center words have been removed; where the initial feature is a regular expression operating over strings to predict matching position in text, while the complementary feature input consists of a window of text around the considered position in which the center words have been removed; or where the initial feature measures the presence of a disjunction of short nucleotide sequences at each position in a large nucleotide sequence (e.g., DNA), while the complementary feature input consists of a window of few nucleotides around the considered position in which the center nucleotides have been removed.
The following discussion describes exemplary algorithms for feature completion. Feature completion starts with an initial feature and a large unlabeled dataset. A complementary feature is built from these inputs. Once built, this complementary feature can then be used in conjunction with the initial feature in a supervised learning setting.
a. Definitions
b. Algorithms to Build a Complementary Feature
i) Generic Algorithm BuildComplementary
This algorithm computes an additional feature function g. It uses the dataset D and the function ƒ to generate (input, targets) pairs as training examples for g. It then uses a training algorithm to train g. The result is a new feature function g, which can then be used to complement ƒ.
If the features are computed on sliding windows, the algorithm can be modified as this:
ii) Specialization for the Binary Case
Assume that f is a binary feature and representation B is a set of n binary measurements. This means that for any item i, f(ai) is either 0 or 1, while bi can be denoted as a vector (bi1, . . . , bin) in which each bij is 0 or 1. Consider a class of supervised learning algorithms that relies only on the following counts from P, N(j, α, β), which denotes the number of pairs (bi, f(ai)) in P such that f(ai)=α and bij=β. In this case, the complementary feature building algorithm can be rewritten as
c. Complementary Features for Classification
Classification as used herein is the task of predicting a class label given an input item. For that purpose, use is made of a supervised learning algorithm, which can automatically infer a function that maps an input feature representation to a class label from a set of labeled items, i.e., items for which the correct class has been identified by a human labeler. A label item (x,y) is denoted, where x denotes its raw representation x and y denotes its label.
The following algorithm takes a set of labeled items, an unlabeled dataset and a set of initial features f1 . . . fn. It complements each feature and learns a classifier that relies both on the initial feature and its complementary feature.
v(x)=f1(x), . . . ,fn(x),g1(x) . . . gn(x)
As an example, consider the following collection of documents in Table 4:
Assume the initial feature is: Word belongs to the set {“February”, “May”}. The concept that the initial feature is trying to capture is the concept of Month. Unfortunately, it will not work well in documents 3 and 6 because the feature will fire even though those particular 2 instances of “May” are not referring to months. Any learning algorithm that depends on the initial feature will therefore be handicapped by the feature's “misfiring.”
To compensate for this problem, a simple complementary feature may be built. Please refer to the Generic algorithm “BuildComplementary” described above, regarding windows. Formally, the initial representation ai,p is a fixed length window of length one (single word) for item i centered on position p. The second representation bi,p is also a fixed length window of length one, but it is centered on the word at position p+1. This window is referred to herein as the “context” window.
In this example, the complementary feature g is trying to better predict the concept of month. To build this feature, a very simple Bayesian algorithm is used as the learning algorithm to compute g. The function g is defined as:
g(w)≡P(ƒ(word at p)=1|word at(p+1)is w)
where the word w is read from position p+1 where g is evaluated. In this case, it helps to think of the representation bi,p as being around position p.
Note that other representations could be used, rather than “word at position p+1” as input for g, and any other machine-learning algorithm could be used to train g to mimic the values of ƒ. In this case, a Bayesian model is used because a closed form version of g can be given and demystify the process by giving an explicit machine-learning algorithm. Using Bayes' rule, one can write:
As an example, g will be computed for the second document at position 3 (w=“24”). Looking at the corpus, one can infer: P(word in Dict)= 6/54= 1/9 because there are 54 words in the corpus and 6 of these are in the dictionary. For the second instance of May (in document 1),
P(following word is “24”|word in Dict)= 2/6=⅓
because there are six instances of the word in the dictionary and in two of these instances, the following word is “24.” Computing P(following word is X) is done by realizing that:
P(word in Dict|following word is X)+P(word not in Dict|following word is X)=1
This leads to
P(following word is “24”.)=P(following word is “24”.|word in Dict)P(word in Dict)+P(following word is “24”.|word not in Dict)P(word not in Dict)
of
P(following word is “24”.)=⅓ 1/9+ 1/48 8/9= 1/18
And finally:
P(word in Dict|following word is X)=⅓ 1/918/1=⅔
If this is done for all the instances, the result is:
Document 0: P(“May” in Dict|following word is “18”)=1.0
Document 1: P(“May” in Dict|following word is “24”.)=0.6666
Document 2: P(“February” in Dict|following word is “18”)=1.0
Document 3: P(“May” in Dict|following word is “Be”)=0.5
Document 4: P(“February” in Dict|following word is “24”.)=0.6666
Document 5: P(“May” in Dict|following word is “I”)=1.0
One can see that this complementary feature is better because if it uses a threshold of 0.6, it will detect that May in document 3 is a verb and not a month. But it is not perfect because it fails to detect that May in document 5 is also a verb rather than a month.
Below is an example where a more complex context function was computed on a large corpus of documents (500,000 web pages). The primary function looks at one word and is one if word belongs to (“January”, “February” . . . , “December”) and zero otherwise. The complementary feature looks at the two words before and the two words after and uses Naïve Bayes to compute the probability of being in the dictionary. For this, a variant of the algorithm above is used, which herein is referred to as “Leave One Out.” In this version, the function g used on a particular word is trained on all the instances of the data set except the instances that are defined by that word.
This is useful because when a word has a double meaning (e.g., like May, which can be a month or a verb), it may be trained only with instances that exclude its own double meaning. The double meaning of May could potentially pollute the other months, but that is often not a problem because the context for double meaning for different cases on which ƒ=1 are often not correlated. For instance if g(February, .) is trained with a set that excludes all instances of February but includes all the other months including May, the bad cases like “May I help you?” will do little damage to the February model because the context “I” is quite unlikely for February (“February I help you?”).
The listing in Table 5 below shows 100 instance examples taken at random from the data set, and sorted by the value of complementary feature g. The value is shown in the column with heading “Prob.” The following 4 columns are the “evidence” at position −2, −1, +1 +2 (relative to May being at position 0). Each evidence can be computed as:
The following column Label is the “concept” value or whether the particular occurrence is indeed a month. This value is computed by hand just for the purpose of evaluation. Inspection of the list in Table 5 shows that initial feature would produce 21% error rate. In contrast, the complementary feature using a threshold of p=0.0003 would only have a 2% error rate.
May (28)
April
May (9)
April
May (4) ▾ April
May (7)
April
V. Segmentation and Schematization
A. Segments
By construction, the bag-of-words representation ignores all relationships between words. This may be a limitation because ordering and grouping information can be valuable. For instance, decomposing a forum web page into a sequence of individual posts could be useful for finding posts that compare two products. In the bag-of-words representation, one would get a hit every time two posts mentioning the two products appear in the same page. Decomposing a schema into individual fields allows field-targeted search and pivoting. This could be useful for finding recipes that have less than 500 calories per serving and a cooking time under 20 minutes.
To enable these capabilities, assume that each item consists of an ordered sequence of tokens. This token-based representation is much richer than bag-of-words. The tokens' positions induce an ordering and a proximity metric between tokens. The distance between two tokens is the absolute difference between their positions. (In this section, a one-dimensional topology is assumed for simplicity. A two-dimensional topology is possible but more complicated (segments are replaced by rectangles.)) A segment is defined as a pair (b, e) of positions in the document. The first position b (for begin) points to the first token of the segment. The second position e (for end) points to the first token outside the segment. Each segment characterizes a group of adjacent tokens inside the document. A document segmentation is a collection (s0, . . . , sk-1) of k disjoint segments. More formally, the set of possible segmentations of a document of n tokens is defined by:
S={s: s=(s0, . . . ,sk-1): k≤n,∀iϵ0 . . . k−1,si=(bi,ei): 0≤b0,bi<ei,ei≤bi+1,ek-1≤n}
A feature fj(i, d) is a vector function of the document d, defined over each of the token position i. The featurization of the document is defined as ƒ(d)=(ƒ0(., d), . . . , ƒJ-1(., d)), where J is the number of individual features. Note that the feature value at position i may depend on the whole document. This definition of feature is general enough to encompass global features (constant over all tokens), token features (features whose value at position i only depend on the token at that position), or trellis (which will be introduced later in this section). A segment classifier h is a function that computes a probability:
h: d,s,w→h(ƒ(d),s,w)
where d is the original data, ƒ(d) is a featurization of the token data, s is a segmentation over the tokens, and w is a trainable parameter vector. Ideally, the segment classifier should verify:
The street address segmentation contains 3 segments 914 labeled as “street address” (however, the third segment is not shown because of space constraints on the page). A restaurant name segmentation would have returned ((0,3), (17,20), (36,39)). Ideally a street address segment classifier would return h(ƒ(d), s, w)=1 for s=(4,15), (21,34), (40,53)) and 0 for any other value of s. This would be the target signal, or segment label.
B. Modularity and Trellis
Schemas have a recursive structure. A schema's field can itself be a schema. For example, a StreetAddress schema can be made out of 5 sub-schemas:
As defined herein, the modularity constraint is the ability to build segmenters independently of the context in which they can be used. The benefit of modularity is that once a segmenter is built, it can be used as a feature for a higher level segmenter in a bottom fashion (similar to the features of a classifier). As described earlier, features are constrained to be immutable. This implies that once a segmenter is built, it will not be retrained inside a higher level segmenter to take advantage of contextual information. This at first appears to be a severe limitation. For instance, a street extractor would do a much better job if it knew about context. Is “Smith Lane, 1234” a street address or a name? If a lower level segmenter decides what is a street and what isn't, the higher level address segmenter is not likely to perform well.
Trellis:
To circumvent this problem, a constraint is imposed that the segmenter return not a segmentation, but a trellis. A trellis is a transition graph between the states of each token.
e
s
,s
,i
=g(ƒ(d)i,ws
where g is a fixed trainable function, ƒ(d)i is a token featurization window centered on i, and ws
An advantage of the trellis representation is that it allows a low level segmenter to communicate to a higher level segmenter the probability of every possible segmentation. In the absence of other constraints, the default segmentation is the optimal path to traverse the trellis. This can be computed in O(n) steps using dynamic programming. When a low level segmentation is used by a higher level segmenter, the higher level segmenter can output its segmentation, and then find the optimal lower level segmentation by finding the optimal transition path subject to constraints. For instance, for an address segmenter, the sub-segments (street, city, Zip code, state, and country) cannot cross the address boundaries (parent constraint) and a given token can only belong to one of the sub-segments (sibling constraint). In other words, the sub-segmenters do not make the final decisions for their own segment. They provide a probability for each possible segmentation for the level above where the decision is made. Computing the high level segmentation is a bottom up process. It is followed by a field filling pass (or back-segmentation) where new segmentation at each level are computed using the current trellis and constraints from parents and siblings.
For each sub-segmenter, the total number of possible segmentations and their corresponding probability is O(2n) for n tokens. Fortunately, the trellis representation carries all that information in O(n) space. To compute the probability of a particular segmentation from the trellis, one can simply determine which of the 3 states each token is in and sum all the edges while following the corresponding path on the trellis.
When a trellis is used as a feature for training a higher level segmenter, it becomes a token feature (every edge value is associated to the token to its left).
C. Labeling Segments
Labeling segments could be extremely tedious. Each word in a document requires a label. The trellis structure allows for interactive segment labeling. The main feature of a trellis is that it enables the search for the optimal path subject to constraints on the states. The default segmentation comes from the optimal trellis path without constraints. This segmentation can assign the default labels to each visible token. The labels can be made visible to the operator by highlighting the visual representations (e.g., words) of the corresponding tokens when they are either in the Begin or Continue state.
Each click on the bounding box of a visible token (e.g., word) toggles the state of the token. The distinction between Begin and Continue is a rather subtle one; it allows the distinction between a long segment and two adjacent ones. This is a UX challenge. Once a visible token has been clicked, it is constrained. Tokens that have never been clicked are unconstrained. For every operator click on a visible token, a constraint has been added/changed/removed. This triggers a dynamic programming optimization on the trellis to find the new resulting optimal path in O(n) steps. This will likely change the default labels of the remaining unconstrained tokens. In other words, the system is working with the operator to always display the best solution given the operator constraints. For instance, one click anywhere on a missed address is likely to trigger the whole address to be labeled as a segment correctly. This is because if any of the address token is part of an address segment, the likelihoods of the adjacent tokens to be part of an address are greatly increased. If the optimal trellis path is computed on every click, tokens tend to flip in logical groups. This makes labeling segments less tedious and requires less hand-eye coordination. Note that every click is forward progress because it results in an added constraint. A visual clue may be provided to indicate which visual tokens got their values by default and which got their values by labeling.
Confidence:
Similar to classification labels, it may be desirable to deemphasize the importance of labeling accuracy. It is desirable that the operator would only look at segments or missed segments that have a low confidence and label these first. An interesting UX challenge is: how should confidence be displayed?
Given a document with a few identified segments, the low confidence segments should visually pop out so that the operator could zoom in on these, make a decision, and submit the new labels without having to read the whole document. This is even more desirable for missed segments. On a given document, the most likely candidate for a segment should visually pop out so that the operator can zoom in on these and take the appropriate action. If there are no low-confidence candidates, the operator should be able to ignore the whole document without reading it.
Displaying segment confidence is not trivial. There are O(2n) possible segmentations. Displaying confidence at the token level would be misleading and the page would look like salt and pepper. For instance, every number or instance of the word “main” could be a candidate for a missed address.
This problem is solved by going back to the trellis representation. The default path provides a path score at the document level. Called this score the Default Optimal Path Score, or DOPS. This global score has no meaning at the token level. If a token is clicked, its label is changed and the new optimal path given this constraint provides a different score. Call this new score COPS (token), for constrained optimal path score. This new score by itself has no meaning at the token level. However, the difference
Conf(token)=DOPC−COPS(token)
is the system estimate of the effect of flipping the label of a given token. If the difference is close to 0, then the system is not confident that it has the right label (flipping it has not effect). Note that
0≤Conf(token)≤1
since path scores are probabilities and DOPC is the optimal path when no state is constrained. If the score is close to 0, then the system is not confident on whether the corresponding token belongs to a segment. From a UX perspective, confidence can be color-coded at the token level, or the low confidence tokens, which verify Conf(token)≤K, where K is a confidence threshold, can be highlighted. Since labels tend to flip in groups, adjacent tokens are likely to have the same score differences, so it is possible to indicate to the operator which tokens will flip together when one label is changed. It is at least plausible that an operator may label a document by just looking at the low confidence segments (or low confidence non-segments) and may take action only on these segments without having to read the entire document. This is a significant decrease of the segment labeling cost.
The optimal path given a constraint is computed in O(n) using dynamic programming. If Conf(token) is computed for every token, a naïve implementation would consume O(n2) steps. If a document has 100,000 tokens, this could become a problem. Fortunately, the whole function Conf(token) can be computed in O(n). The trick is to do two dynamic programming passes, one in each direction, to compute the optimal path in both directions from the current token to each end of the document. Both of these passes are done in O(n). The quantity Conf(token) is simply the sum of the scores of the two half paths.
To find the documents that are most likely to have a segment, the segment classifier can be turned into a regular classifier with the operation:
In other words, h′ is the sum of the probabilities of all segmentations that contain at least one segment. It returns the probability that there is at least one segment on the page.
VI. Segment Extraction
Segment extraction (AKA entity extraction or EE) is the process of identifying token segments in a document that correspond to a given concept. As an example, suppose a user is interested in automatically extracting addresses and their constituent parts (city, state, etc.) from a web page so that he or she can quickly look them up on a map.
Statistical methods for segment extraction typically use training data to build a finite state machine (FSM) that can be used to decode a document. An example finite state machine for extracting addresses is illustrated in
Given a document, the FSM is “rolled out” to create a corresponding trellis that can be used to calculate path probabilities in the document, as illustrated in
Each edge 1312 in trellis 1310 has a weight that is a function of features in the document. Using standard decoding algorithms (e.g., Viterbi), one can identify the highest-weight path through the trellis 1310 and output the corresponding labeling of the tokens 1316 and transitions (edges) 1312. One can also train the weight functions so that the probability of any given path can be extracted.
The edge-weight functions are typically functions of token features that are “near” the edge of interest, although this is not a requirement. In the example under discussion, and with reference to
With reference again to
Weight(Features)=θ1×IsNumber(token before)+θ2×IsStreetType(token before)+θ3×IsNumber(token after)+θ4×IsStreetType(token after).
The parameters θi are trained to maximize some loss function on a training set. The training set typically contains labels that correspond to paths along a trellis. Intuitively, the training algorithms try to learn weight functions such that the labeled paths in the training data have higher total weight than the non-labeled paths.
Training data can also specify constraints on the allowed set of paths through a trellis without uniquely identifying a single path. In the example described above, one could have a label indicating that “1401,” “THIRD,” and “AVENUE” are all addresss tokens; because of the structure of the trellis, this does not uniquely identify the path, but rather constrains the path to the dashed token-consuming edges on the middle three tokens.
A. Hierarchical State Machine
In most segment-extraction domains, the concepts of interest are hierarchical. In the address example, an address has sub-concepts such as street, and street can have sub-concepts as well. Such a domain can be represented as a “concept hierarchy,” where the root node represents the concept of interest, and children nodes correspond to mutually exclusive sub-components; by mutually exclusive is meant that a single token can belong to at most one of the sub-components (thus, “Third” can be part of a street or part of a zip code, but it cannot be part of both).
Finite state machines can be specified hierarchically in a number of different ways to simplify the representation. Consider a hierarchical finite state machine (HFSM) in which an FSM is defined recursively using modules; the transitions within a module can correspond to “normal” state transitions, or they can refer to transitions into sub-modules.
As an example,
B. Interactively Constructing Segment Extraction Models
To build a segment-extraction system for a domain, a machine-learning expert is typically needed to (1) define the structure of the underlying finite state machine, (2) define the feature functions for the edges, which requires tuning the size of the “window” to consider around each edge as well as which features to use, and (3) tune the resulting model so that it meets the performance requirements of the application. Also, the machine-learning expert usually starts with a fixed labeled training set and test set. Described below is a system that allows a domain expert to construct entity extraction models without the need for a machine-learning expert.
An interactive system for building segment extractors may include a means for the user to specify constraints governing whether a token belongs or not to a particular segment, and a means for storing these constraints as labels (labeling capability); a means for the system to re-compute and display the most plausible segments interactively using the latest user input, the current document information, and a trainable function (interactive propagation of labels, with no retraining); a means for the system to train the trainable function using all previously input labels (machine learning required, slow non-interactive training); and a means for the system to automatically select which example to label next, based on the score computed by the trainable function (active labeling).
C. Concept Hierarchy
With the technology described herein, domain experts can provide interactively a concept hierarchy corresponding to the domain of interest. In the address example, it does not take a machine-learning expert to be able to decompose an address into its constituent parts. By providing a user interface that allows the domain expert to specify the concept hierarchy, and then converting that hierarchy into an HFSM by using default structure within the modules, and/or by using labeled data to choose among candidate structures, sophisticated extraction models can be built without the domain expert knowing or caring about state machines.
Furthermore, the “language” that the domain expert uses can be extended to allow him to provide additional constraints within the machine. For example, the domain expert may want to state that an address can contain at most one zip code, or that any address must have a street portion present.
Additionally, a domain expert can build an extractor for some concept, and then “plug it in” as a sub-concept for another task. This corresponds to having modules in an HFSM correspond to previously trained HFSM. In the example, someone could build a zip-code extractor outside the context of addresses. Then, when specifying the concept hierarchy for addresses, the person could say that the zip-code sub-concept corresponds to the previous concept. When one does such a “plug in”, one may decide to freeze the weights of the sub-machine so that they do not need to be trained in the new domain.
An interactive system for building segment extractors may include one or more of: a user interface allowing the user to specify interactively a concept hierarchy, and it may be that no other information about the hierarchical state machine is provided by the user, and the system uses default strategies and/or model-selection strategies to complete the specification of the hierarchical state machine. An interactive system for building segment extractors may be such that the user can provide a concept hierarchy and one or more additional constraints about the domain that translate into constraints on the hierarchical state machine, and may also be such that an additional constraint is that a sub-concept instance can occur at most once in an instance of its parent concept (e.g., an address can contain at most one zip code). There may also be additional constraints including that a sub-concept instance must appear at least once in an instance of its parent concept (e.g., an address must contain a state), a partial order over the sub-concepts (e.g., city must precede state in an address), and that two sibling sub-concepts cannot both appear in an instance of their parent concept (an address cannot contain a U.S. postal code and a Canadian postal code).
An interactive system for building segment extractors may also be such that previously built models for concepts can be re-used (e.g., someone builds a zip-code extractor and you can tell the system that you want to use that same extractor but in the context of your address extractor). It may also be that the parameters of the re-used extractor are frozen (i.e., the edge-weight functions are fixed) for the edges contained within the module, but where the edge-weight functions on the in-coming and out-going transition edges to that module are trained for context.
D. Label Modularity/Binary Labeling
When labeling a hierarchical concept such as address, it can be tedious to label all constituent parts of an address for every document. It is much easier for the domain user to concentrate on one node in the hierarchy (“Address” or “Zip Code”) at a time, quickly labeling many documents.
Label modularity, as used herein with regard to labeling, refers to labeler focus, i.e., the ability to label/optimize for one module at a time. Note that because all modules are connected together in the HFSM, improvements and labels for one module can improve the other modules at the same time; label modularity is used specifically to mean modularity of user focus.
As used herein, a module in an HFSM is said to be binary if the labels to be elicited by the user are characterized by “in” or “out” labels on modules. In particular, a token labeled “in” is the restriction that the edge “consuming” the token must be contained with the given module or one of its descendants (e.g., if a token is labeled “Address,” it can be any one of its child concepts or an implicit “Address:other”). Similarly, a token labeled “out” is the restriction that the edge “consuming” the token cannot be contained within the given module or any of its descendants.
A non-binary HFSM would be one where additional labels are available. For example, suppose a “Street” module consumed two distinct labels that do not correspond to sub-modules: Street1 and Street2. Then a labeling tool might be able to elicit from the user which type of street a token is. Of course, this could be converted into an equivalent binary labeling of IsStreet1 and IsStreet2.
When each module in an HFSM is binary, then a binary labeling tool can be used to elicit labels for the HFSM on a per-module basis.
A concept hierarchy 1710 is shown on the left, having a root node 1712 (“Address”) and three children 1714 (“Street,” “City,” and “Zip Code”). As depicted, the user has the root node 1712 selected. In the corresponding HFSM, there is a child concept “Address:Other” not shown explicitly to the user that allows the machine to accept address tokens that do not belong to the three children (such as punctuation, filler text, etc.). A web page 1716 returned as a search result is displayed on the right. To label the tokens on the page 1716 that are part of an address, having first selected the root node 1712, the user clicks on the first token 1718 (“15710 NE 24TH ST. SUITE E”) and drags to the last token 1720 (“98008”) of the address, thereby selecting the entire address portion.
Note that knowing the tokens that are part of the address does not provide explicit labels about which tokens are Street, City or Zip Code. The user then clicks the Submit button 1722 of
After labeling a number of documents, the system trains a model that can be used to “pre label” addresses. Furthermore, the pre-label can take constraints into account to quickly elicit labels; if a proposed label is not correct, the user can click on a single token that has the wrong label, and this constraint can “propagate” to other tokens in the document.
The user can change which concept to label by clicking on the corresponding node in the concept hierarchy, such as “Street,” “City,” or “Zip Code.” Thus, if the user wants to label cities next, he can click on the city node and proceed to label cities within addresses on documents, as depicted in
A concept hierarchy 1910 is shown on the left, having a root node 1912 (“Address”) and three children nodes: child node 1914 (“Street”), child node 1916 (“City”), and child node 1918 (“Zip Code”). As depicted, the user has the “City” node 1916 selected. A web page 1920 returned as a search result is displayed on the right. As depicted, the user has selected a token 1922 (“BELLEVUE”) as a city. With reference to
An interactive system for building segment extractors may allow the domain expert to provide binary (in/out) labels associated with nodes in a concept hierarchy.
E. Segment Extraction Models and Classification Models as Features
Once an entity extraction model has been constructed, it can be used as input to the edge-weight functions in another entity extractor. For example, one could use an EE model to predict, for each token in a document, the probability that the token is part of an address. This probability, or some function of that probability, could then be used as one of the token feature values along with the other “standard” feature values.
Entity extraction models can also be used to create document-level features for classification models. For example, one could be building a restaurant-page classifier that has a feature that, with probability >0.5, an address exists on the page. Entity extraction models can also use classification models as features. An interactive system for building segment extractors may use pre-built segment-extraction models and/or pre-built classification models to generate input features for a segment-extraction model.
F. Segment Extraction Review Panel
When a segment-extraction model has been built, it is useful to see how that model predicts on a document that the user has already labeled. Mismatches between the predicted labels and the actual labels can indicate labeling errors or can suggest new features to add.
An interactive system for building segment extractors may have an interface to review labels with an existing model's predictions at the same time.
G. Mini-Documents
Documents such as web pages or book chapters can be very long. As a result, “labeling a document” can be tedious simply because the labeler needs to scan the entire document. To mitigate this problem, documents can be segmented into more manageable sub-documents, but without losing the context of the segment that is being labeled. With regard to
A minidoc may be initialized in a number of ways. For example, given an existing model, one can identify a likely (or perhaps uncertain) address of interest, and then define a minidoc that contains that token segment. An interactive system for building segment extractors may segment an input document into smaller sub-documents. Additionally, the sub-documents may be automatically initialized based on a pre-existing segment-extraction model or on proximity to specific tokens or token features.
This application is a continuation of U.S. application Ser. No. 14/075,679, filed Nov. 8, 2013, titled “Interactive Concept Editing in Computer-Human Interactive Learning,” which claims the benefit of priority to U.S. Provisional Application No. 61/845,844, filed Jul. 12, 2013, entitled “Computer-Human Interactive Learning,” each of which is incorporated by reference herein in its entirety. This application is related by subject matter to the following U.S. Patent Applications which were filed concurrently with U.S. patent application Ser. No. 14/075,679: U.S. application Ser. No. 14/075,708, entitled “Active Featuring in Computer-Human Interactive Learning,” U.S. application Ser. No. 14/075,701, entitled “Feature Completion in Computer-Human Interactive Learning,” U.S. application Ser. No. 14/075,690, entitled “Active Labeling for Computer-Human Interactive Learning,” and U.S. application Ser. No. 14/075,713, entitled “Interactive Segment Extraction in Computer-Human Interactive Learning.” The entireties of the aforementioned applications are incorporated by reference herein.
| Number | Date | Country | |
|---|---|---|---|
| 61845844 | Jul 2013 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 14075679 | Nov 2013 | US |
| Child | 16358261 | US |
