Patent Application
20210192394
Machine learning (ML) techniques enable a machine to learn to automatically and accurately make predictions based on historical observation. Training an ML algorithm involves feeding the ML algorithm with training data to build an ML model. The accuracy of a ML model depends on the quantity and quality of the training data used to build the ML model.
An entire industry has developed around the preparation and labeling of training data. A number of companies provide platforms through which example data is distributed to human users for manual labelling. The customer may be charged for the labelling services based on the human expertise required to label the data, the number of rounds of human review used to ensure the accuracy of the labelled data and other factors. The need for people to label the training data can have significant costs, both in terms of time and money. A new paradigm for labeling data is therefore required.
The present disclosure details systems, methods and products for optimizing the performance of a labeling system to efficiently produce high-confidence labels. These embodiments include active learning components, high-confidence labeling components, and experimentation and training components which are used in combination to optimize the quality of labels generated by the system while reducing the cost of generating these labels.
One embodiment comprises a method for optimization of a machine learning (ML) labeler that receives a plurality of labeling requests, each of which includes a data item to be labeled. For each of the labeling requests, a corresponding inference result is generated by a current ML model of an iterative model training system. The inference result includes a label inference corresponding to the data item and one or more associated self-assessed confidence metrics. Based on the generated inference results, at least a portion of the labeling requests is selected. The generated inference results for the selected labeling requests are corrected using a directed graph of labelers having one or more labelers, where the directed graph generates an augmented result for each of the labeling requests in the selected portion based on associated quality and cost metrics. The augmented result includes a label corresponding to the data item, where the label meets a target confidence threshold. At least a first portion of the augmented results as training data to a training data storage. One or more trigger inputs are monitored to detect training triggers and, in response to detecting the one or more training triggers, the first portion of the augmented results are provided to an experiment coordinator, which iteratively trains the ML model using this portion of the augmented results. At least a second portion of the augmented results are provided as evaluation data to a model evaluator. The model evaluator evaluates the ML model using the second portion of the augmented results. In response to the evaluation, the model evaluator determines whether the ML model is to be updated. If the model evaluator determines that the ML model is to be updated, it updates the ML model.
An alternative embodiment comprises a method for optimization of a machine learning (ML) labeler in which labeling requests are received and corresponding label inferences are generated for each labeling request using a champion model. A portion of the labeling requests is selected for use as training data based on the generated label inferences, and corrected labels are generated to produce an augmented result for each of the selected requests. A first portion of the augmented results are provided as training data to an experiment coordinator which trains one or more challenger models using these augmented results. After the challenger models have been trained, a second portion of the augmented results is provided to a model evaluator which evaluates the performance of the challenger models and the champion model using this data. If it is determined that one of the challenger models has higher performance than the champion model (e.g., if the challenger model meets a set of evaluation criteria that indicate higher performance) the model evaluator promotes the challenger model to replace the champion model.
In some embodiments, the method further includes conditioning each of the labeling requests prior to generating the corresponding label inference and deconditioning the labeling request and corresponding label inference after the label inference is generated. Conditioning the labeling request may comprise translating the labeling request from a data domain associated with the labeling requests to a data domain associated with the champion model. Conversely, deconditioning the labeling request and corresponding inference may comprise translating the labeling request and inference from the champion model's data domain to the labeling requests' data domain.
In some embodiments, selecting the portion of the labeling requests for use as training data comprises applying an active learning strategy that identifies ones of the labeling requests that are more useful for training than a remainder of the labeling requests, according to the active learning strategy.
In some embodiments, the method further includes the champion model generating a confidence indicator for each of the labeling requests which is associated with the corresponding label inference, and selecting the portion of the labeling requests for use as training may comprises identifying a lower-confidence portion of the labeling requests and a higher-confidence portion of the labeling requests.
In some embodiments, the method further includes storing the first portion of the augmented results in a training data storage, monitoring one or more trigger parameters to detect a trigger event, and in response to detecting the trigger event, providing at least some of the augmented results as training data to an experiment coordinator.
The experiment coordinator may then generate one or more challenger models in response to detecting the trigger event, which may include configuring a corresponding unique set of hyper-parameters for each of the challenger models and training each of the uniquely configured challenger models with a portion of the augmented results. The trigger event may comprise an elapsed time since a preceding trigger event, an accumulation of a predetermined number of augmented results, or various other types of events. The trigger parameters may include one or more quality metrics.
The augmented results may be conditioned to translate them from a data domain associated with the labeling requests to a data domain associated with the experiment coordinator.
One alternative embodiment comprises a ML labeler which includes a record selector, a champion model, an experiment coordinator and a model evaluator. The record selector in this embodiment is configured to receive labeling requests and provide them to the champion model, which generates a corresponding label inference for each of the labeling requests. The record selector is configured to select a portion of the labeling requests for use as training data based on the generated label inferences. The ML labeler is configured to generate a corresponding high-confidence label for each of the labeling requests in the selected portion, thereby producing corresponding augmented results. The experiment coordinator is configured to receive a first portion of the augmented results as training data and trains one or more challenger models using this portion of the augmented results. The model evaluator is configured to receive a second portion of the augmented results as evaluation data and to evaluate the challenger models and the champion model using the second portion of the augmented results. Then, in response to determining that one of the one or more challenger models has better performance than the champion model (e.g., meets a set of performance evaluation criteria, the ML labeler is configured to promote the challenger model to replace the champion model. The ML labeler may components that perform functions as described above in connection with the exemplary method.
Another alternative embodiment comprises a computer program product comprising a non-transitory computer-readable medium storing instructions executable by one or more processors to perform as described above.
Numerous alternative embodiments may also be possible.
These, and other, aspects of the disclosure will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following description, while indicating various embodiments of the disclosure and numerous specific details thereof, is given by way of illustration and not of limitation. Many substitutions, modifications, additions, or rearrangements may be made within the scope of the disclosure without departing from the spirit thereof, and the disclosure includes all such substitutions, modifications, additions, or rearrangements.
The drawings accompanying and forming part of this specification are included to depict certain aspects of the disclosure. It should be noted that the features illustrated in the drawings are not necessarily drawn to scale. A more complete understanding of the disclosure and the advantages thereof may be acquired by referring to the following description, taken in conjunction with the accompanying drawings in which like reference numbers indicate like features and wherein:
Embodiments and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known starting materials, processing techniques, components and equipment are omitted so as not to unnecessarily obscure the embodiments in detail. It should be understood, however, that the detailed description and the specific examples are given by way of illustration only and not by way of limitation. Various substitutions, modifications, additions and/or rearrangements within the spirit and/or scope of the underlying inventive concept will become apparent to those skilled in the art from this disclosure.
Embodiments described herein provide a comprehensive data labelling platform for annotating data. The platform incorporates human and machine learning (ML) labelers to perform a variety of labeling tasks. Embodiments of the platform and its workflows are configurable to unique labeling requirements. The platform supports workflows in which machine learning augments human intelligence. The platform is extensible to a variety of machine learning domains, including image processing, video processing, natural language processing, entity resolution and other machine learning domains.
According to one aspect of the present disclosure, the labeling platform allows a user (a “configurer”) to configure use cases, where each use case describes the configuration of platform 102 for processing labeling requests. Use case configuration can include, for example, specifying labeler kernel core logic and conditioning components to use, configuring active learning aspects of the platform, configuring conditional logic (the ability to control the flow of judgements as they progress through stages), configuring labeling request distribution and configuring other aspects of platform 102.
According to another aspect of the present disclosure, the labeling platform provides a highly flexible mechanism to configure a labeling platform for a use case where the use case is used to implement a processing graph that includes one or more human labelers, ML labelers and/or other labelers. When a task is distributed to a human specialist, the platform can stop processing at a node of the graph to wait for a response from the human specialist and then continue processing based on the response. In some cases, a configuration can define a processing graph in which the labeled data provided by an ML labeler or human labeler (or other labeler in the processing graph) is looped back as training data into an ML labeler of the processing graph.
Configuration can be specified in any suitable format. In some embodiments, at least a portion of the configuration is expressed using a declarative Domain Specific Language (DSL). Thus, a configuration can be implemented using a declarative model that is human-readable and machine-readable, where the declarative model provides the definition of a processing system for a use case.
According to another aspect of the present disclosure, the labeling platform includes use case templates for various types of labeling problems (e.g., image classification, video classification, natural language processing, entity recognition, etc.). Use case templates make assumptions regarding what should be included in a configuration for a use case, and therefore require the least input from the human configurer. The platform can provide a more data driven and use case centric engagement with the end-user than prior labeling approaches. For example, according to one embodiment, the end-user selects the type of problem they have (e.g., image classification, natural language processing, or other problem class supported by the platform), provides information about the data they will provide, defines a small set of constraints (e.g., time, cost, quality) and specifies what data/labels they want back. According to one aspect of the present disclosure, the platform can store a declarative model for a use case, where the declarative model includes configuration assumptions specified by a use case template and the relatively small amount of configuration provided by the human user.
According to another aspect of the present disclosure, the platform includes task distribution functionality. Task distribution can include routing labeling requests/tasks to machine learning labelers or human labelers. The routing decisions for a labeling request/task can be based, in part, on the active learning configuration of the ML labelers and the qualifications of human specialists. Task distribution can also include dynamically distributing tasks to ML labelers and human labelers based on confidences.
According to another aspect of the present disclosure, the platform implements quality assessment mechanisms to score labeler instances.
According to another aspect of the present disclosure, the labeling platform implements workforce management, including scoring workers over time in one or more skill areas.
According to another aspect of the present disclosure the labeling platform may interact with reputation systems. Reputation systems measure and record the accuracy of labeler instances' work and generate scores for those labeler instances. The scoring approach may vary across reputation system implementations. Non-limiting example embodiments of scoring are described in related Provisional Application No. 62/950,699, Appendix 1, Section III.B.2 Scoring and Measuring Accuracy. The labeling platform interacts with such reputation systems to (1) provide information including, but not limited to, a labeler's unique identifier, a descriptor for the type of labeling task performed, the labeler's provided label, and a CORRECT label for comparison and (2) to consume information produced by the reputation system including scores for specific labeler instances and provenance descriptions for how those scores were calculated.
There are many platforms, frameworks, and algorithms available for ML model training and inference. By way of example, but not limitation, an ML model may be trained in a DOCKER container (e.g., a DOCKER container containing libraries to train a model, or on a platform such as AMAZON SAGEMAKER, GOOGLE AUTOML, KUBEFLOW (SAGEMAKER from Amazon Technologies, Inc., AUTOML from Google, DOCKER by Docker, Inc.). In addition, there are various model frameworks that can be used (e.g., TENSORFLOW by Google, PyTorch, and MXNet). Further there are many ML algorithms (e.g. K-Means, Logistic Regression, Support Vector Machines, Bayesian Algorithms, Perceptron, Convolutional Neural Networks). Finally, for each combination of platform, framework, and algorithm, there are many data transformations and configuration parameters that may be applied to the training process with the goal of increasing trained model quality, reducing the volume of labeled training data required, reducing the computational resources required to train, etc. These configuration options are commonly referred to as hyper-parameters, and experimentation is often used to find optimal values. Training a model typically requires in-depth knowledge of ML platforms, frameworks, algorithms, as well as data transformation options and techniques, and configuration options associated with all of the above.
Similarly, there are multiple platform options for using a model for inference. Further, there are multiple ways to interact with a model once it is trained. For example, some ML model APIs support submitting labeling requests one at a time, whereas other APIs support batches of labeling requests.
Thus, as will be appreciated, there are many options available for training ML models or using ML models for inference. Embodiments described herein provide a labeling platform that can leverage various ML integrations (platforms, frameworks or algorithms). The labeling platform abstracts the configuration process such that an end user may specify a training configuration for an ML model that is agnostic to the platform, framework or algorithm which will be used for training and inference.
As discussed above, the labeling platform may provide a set of use case templates, where each use case template corresponds to a labeling problem to be solved (e.g., “image classification,” “video frame classification,” etc.) and includes an ML labeler configuration. The end user of a labeling platform may select a labeling problem (e.g., select a use case template), provide a minimum amount of training configuration and provide data to be labeled according to the use case. The use case template can specify which ML platform, ML framework, ML algorithm, data transformations, and hyper-parameter values to use for training an ML model for a problem type. In some cases, the labeling platform specifies a priori the platforms, frameworks, algorithms, data transformations, and hyper-parameter values used to train ML models for a labeling problem. In other embodiments, the labeling platform may specify some number of platforms, frameworks, algorithms, data transformations, and hyper-parameter values to use and the labeling platform can experiment using data provided by the end user to find the best combination to use for a use case.
At runtime, the labeling platform sets up the specified ML platform, framework, algorithm, data transformations, and hyper-parameter values to train an ML model using the training data provided by the end user or produced by the platform. The end user does not need to know the details of those training elements. Instead, the labeling platform uses configuration provided by the use case template, as well as experimentation, to produce a high-quality trained model for that customer's use case.
Embodiments provide the advantage that the end user need only specify a small amount of configuration information for the labeling platform to train multiple models for a use case, potentially using multiple ML platforms, frameworks, algorithms, data transformations, and hyper-parameter values. The labeling platform may continually retrain the multiple models based on the configuration for the use case.
These and other aspects of a labeling platform may be better understood from the following description.
Labeling platform 102 executes on a computer—for example one or more servers—with one or more processors executing instructions embodied on one or more computer readable media where the instructions are configured to perform at least some of the functionality associated with embodiments of the present invention. These applications may include one or more applications (instructions embodied on a computer readable media) configured to implement one or more interfaces 101 utilized by labelling platform 102 to gather data from or provide data to ML platform systems 130, human labeler computer systems 140, client computer systems 150, or other computer systems. It will be understood that the particular interface 101 utilized in a given context may depend on the functionality being implemented by labeling platform 102, the type of network 175 utilized to communicate with any particular entity, the type of data to be obtained or presented, the time interval at which data is obtained from the entities, the types of systems utilized at the various entities, etc. Thus, these interfaces may include, for example web pages, web services, a data entry or database application to which data can be entered or otherwise accessed by an operator, APIs, libraries or other type of interface which it is desired to be utilized in a particular context.
In the embodiment illustrated, labeling platform 102 comprises a number of services including a configuration service 103, input service 104, directed graph service 105, confidence driven workflow (CDW) service 106, scoring service 107, ML platform service 108, dispatcher service 109 and output service 115. Labeling platform 102 further includes labeler core logic 111 for multiple types of labelers and conditioning components 112 for various types of data conditioning. As discussed below, labeler core logic 111 can be combined with conditioning components 112 to create labelers 110.
Labeling platform 102 utilizes a data store 114 operable to store obtained data, processed data determined during operation, and rules/models that may be applied to obtained data or processed data to generate further processed data. Data store 114 may comprise one or more databases, file systems, combinations thereof or other data stores. In one embodiment, data store 114 includes configuration data 116, which may include a wide variety of configuration data, including but not limited to configuration data for configuring directed graph service 105, labelers 110 and other aspects of labeling platform 102. Configuration data 116 may include “use cases”. In this context a “use case” is a configuration for a processing graph. In some embodiments, labeling platform 102 may provide use case templates to assist end-users in defining use cases. In the illustrated embodiment, labeling platform 102 also stores data to persist machine learning (ML) models (data 119), training data 122 used to train ML models 120, unlabeled data 124 to be labeled, confidence data 128, quality metrics data 129 (e.g., scores of labeler instances) and other data.
As discussed below, labeling platform can distribute data to human users to be labeled. To this end, data labeling environment 100 also comprises human labeler computer systems 140 that provide user interfaces (UI) that present data to be labeled to human users and receive inputs indicating the labels input by the human users.
Labeling platform 102 also leverages ML models 120 to label data. Labeling platform 102 may implement its own ML platform or leverage external or third-party ML platforms, such as commercially available ML platforms hosted on ML platform systems 130. As such, data labelling environment 100 includes one or more ML platforms in which ML models 120 may be created, trained and deployed. Labeling platform 102 can send data to be labeled to one or more ML platforms so that data can be labeled by one or more ML models 120.
Client computer systems 150 provide interfaces to allow end-users, such as agents or customers of the entity providing labeling platform 102, to create use cases and provide input data. According to one embodiment, end-users may define use cases, where a use case is a set of configuration information for configuring platform 102 to process unlabeled data 124. A use case may specify, for example, an endpoint for uploading records, an endpoint from which labelled records may be downloaded, an endpoint from which exceptions may be downloaded, a list of output labels, characteristics of the unlabeled data (e.g., media characteristics, such as size, format, color space), pipelines (e.g., data validation and preparation pipelines), machine learning characteristics (e.g., ML model types, model layer configuration, active learning configuration, training data configuration), confidence driven workflow configuration (e.g., target confidence threshold, constituent labelers, human specialist workforces, task templates for human input), cost and quality constraints or other information. According to some embodiments, at least a portion of a use case is persisted as a declarative model of the use case, where the declarative model describes a processing graph (labeling graph) for the use case at a logical level. Platform 102 may support a wide array of use cases.
In operation, labeling platform 102 implements a use case to label the data. For example, the use case may point to a data source (such as a database, file, cloud computing container, etc.) and specify configurations for labelers to use to label the data. Directed graph service 105 uses the configurations for labelers and implements a directed graph of labelers 110 (e.g., to implement the use case) to label the data. In some cases, the labelers are implemented in a CDW to label the data and produce labeled result data 126, where the workflow incorporates one or more ML models and one or more human users to label the data. The CDW may itself be implemented as a directed graph.
During execution of a graph, the same data item to be labeled (e.g., image, video, word document, or other discrete unit to be labeled) may be sent to one or more ML labeling platforms to be processed by one or more ML models 120 and to one or more human labeler computer systems 140 to be labeled by one or more human users. Based on the labels output for the data item by one or more labelers 110, the workflow can output a final labeled result.
The basic building blocks of the directed graph implemented by directed graph service 105 are “labelers.” As discussed below, some examples of labelers include, but are not limited to, executable code labelers, third-party hosted endpoint labelers, ML labelers and human labelers, and CDW labelers.
With reference to
The input is fed to the labeler over an input pipe 202, and the labeled output is placed in an output pipe 204. Inputs that the labeler fails to label are placed in an exception output pipe (exception pipe) 206. Some exceptions may be recoverable. These three pipes can pass both data and labeling flow control. Each of these pipes can have a configurable expected data schema.
A labeling request may have associated flow control data, such as constraints on allowable confidence and cost (time, monetary or other cost), a list of labeling instances to handle or not handle the request or other associated flow control information to control how the labeler 200 handles the request. Labeled results from a labeler 200 are the result of running a conditioned labeling request through a labeler 200.
The answer (output labeled result) is passed through an output conditioning pipeline if one is specified for the labeler. The label output by a labeler may have many forms, such as, but not limited to: value output based on a regression model, a class label, a bounding box around an object in an image, a string of words that characterize/describe the input (e.g., “alt text” for images), an identification of segmentation (e.g., “chunking” a sentence into subject and predicate). In some cases, a labeler may also output a self-assessed confidence measure for a label. Labeler 200 may also output various other information associated with the labeled result, such as the labeler instance that processed the labelling request.
One embodiment of the internal structure of a labeler, such as labeler 200, is illustrated in
In one embodiment, platform 102 includes human labelers and ML labelers. Human labelers and ML labelers may be combined into CDWs, which may also be considered a type of labeler. The kernel core logic 302 of a human labeler is configured to distribute labeling requests out to individual human specialists while the kernel core logic 302 of ML labelers is configured to leverage ML models to label data. As such, each human labeler and ML labeler may be considered an interface to a pool of one or more labeler instances behind it. A labeler is in charge of routing labelling requests to specific labeler instances within its pool. For a human labeler, the labeler instances are individual humans working through a user interface (e.g., human specialists). For an ML labeler, the labeler instances are ML models deployed in model platforms. The labeler instances may have different confidence metrics, time costs and monetary costs.
Translation by conditioning layer 304 may be required because the data domain external to the kernel core logic 302 may be different than the kernel's data domain. In one embodiment, for example, the external data domain may be use-case specific and technology agnostic, while the kernel's data domain may be technology-specific and use-case agnostic. The conditioning layer 304 may also perform validation on inbound data. For example, for one use case, a solid black image may be valid for training/inferring, while for other use cases, it may not. If it is not, the conditioning layer 304 may, for example, include a filter to remove solid black images. Alternatively, it might reject such input and issue an exception output.
The conditioning layer 304 of a labeler may include input conditioning, successful output conditioning, and exception output conditioning. Each of these can be constructed by arranging conditioning components into pipelines. Conditioning components perform operations such as data transformation, filtering, and (dis)aggregation. Similar to labelers, the conditioning component may have data input pipes, data output pipes, and exception pipes.
Multiple ML labelers, human labelers or other labelers can be composed together into directed graphs as needed, such that each individual labeler solves a portion of an overall classification problem, and the results are aggregated together to form the overall labeled output. The overall labeling graph for a use case can be thought of abstractly as a single labeler, and each labeler may itself be implemented as a directed graph. There may be branches, merges, conditional logic, and loops in a directed graph. Each directed graph may include a fan-in to a single output answer or exception per input element. The method of modeling the labeling in such embodiments can be fractal. The labeling graphs implemented for particular use cases may vary, with some graphs relying exclusively on ML labelers and other graphs relying solely on human labelers.
ML labelers and human labelers and/or other labelers may be implemented in a CDW, which can be considered a labeler that encapsulates a collection of other labelers. The encapsulated labelers are consulted in sequence until a configured threshold confidence on the answer is reached. A CDW can increase labeling result confidence by submitting the same labeling request to multiple constituent labelers and/or labeler instances. A CDW may include an ML labeler that can learn over time to perform some or all of a use case, reducing the reliance on human labeling, and therefore driving down time and monetary cost to label data.
Executable code labelers package up executable code with configurable parameters to be used as executable code labelers. The configuration for an executable code labeler includes any configuration information relevant to the executable code of the labeler. Other than the generic configuration information that is common to all labelers, the configuration for an executable labeler will be specific to the code. Examples of things that could be configured include, but are not limited to: S3 bucket prefix, desired frame rate, email address to be notified, batch size.
A third-party hosted endpoint labeler can be considered a special case of an executable code labeler, where the executable code calls out to a third-party hosted endpoint. The configuration of the third-party hosted endpoint can specify which endpoint to hit (e.g., endpoint URL), auth credentials, timeout, etc.
A human labeler acts as a gateway to a human specialist workforce. A human labeler may encapsulate a collection of human specialists with similar characteristics (cost/competence/availability/etc.) as well as encapsulating the details of routing requests to the individual humans and routing their results back to the labeling system. Human labelers package the inbound labeling request with configured specialist selection rules and a task UI specification into a task.
Human labeler 400 is configured according to a workforce selection configuration 410 and a task UI configuration 412. Workforce selection configuration 410 provides criteria for selecting human specialists to which a labeling request can be routed. Workforce selection configuration 410 can include, for example, platform requirements, workforce requirements and individual specialist requirements. In some embodiments, platform 102 can send tasks to human specialists over various human specialist platforms (e.g., Amazon Mechanical Turk marketplace and other platforms). Workforce selection configuration 410 can thus specify the platform(s) over which tasks for the labeler can be routed. Human specialist platforms may have designated workforces (defined groups of human specialists). Workforce selection configuration 410 can specify the defined groups of human specialists to which tasks from the labeler can be routed (i.e., groups of human labeler instances to whom labeling tasks can be routed). If a workforce is declared in configuration 410 for a use case, a human specialist must be a member of that workforce for tasks for the labeler 400 to be routed to that human specialist. Workforce selection configuration 410 may also specify criteria for the individual specialists to be routed a task for labeler 400. By way of example, but not limitation, workforce selection configuration 410 can include a skill declaration that indicates the skills and minimum skill scores that individual workers (human specialists) must have to be routed labeling tasks from the labeler. A quality monitoring subsystem (QMS) may track skills/skill scores for individual human specialists.
Task UI configuration 412 specifies a task UI to use for a labeling task and the options available in the UI. According to one embodiment, a number of task templates can be defined for human labeler specialists with each task template expressing a user interface to use for presenting a labeling request to a human for labeling and receiving a label assigned by the human to the labeling request. Task UI configuration 412 can specify which template to use and the labeling options to be made available in the task UI.
When labeler 400 receives a labeling request, labeler 400 packages the labeling request with the workforce selection configuration 410 and task UI template configuration 412 as a labeling task and sends the task to dispatcher service 409 (e.g., dispatcher service 109). Dispatcher service 109 is a highly scalable long-lived service responsible for accepting tasks from many different labelers and routing them to the appropriate endpoint for human specialist access to the task. Once a worker accepts a task, the platform (e.g., the dispatcher service) serves the configured browser-based task UI 420, then accepts the task result from the specialist and validates it before sending it back to the labeler.
The same labeling request may be submitted multiple times to a single human labeler. In some embodiments however, it is guaranteed not to be presented to the same human specialist (labeler instance) more than once. Human-facing tasks can also support producing an exception result, with a reason for the exception.
As discussed above, labeling platform 102 may implement ML labelers.
As illustrated in
At a high level, ML training and inference can be thought of as a pipeline of five functional steps: Input Data Acquisition, Input Data Conditioning, Training, Model Deployment, and Model Inference.
According to one embodiment, the acquisition of unlabeled data for labeling and labeled data for training is handled by platform 102, as opposed to within the labeler 500 itself. The data may be passed in directly over an endpoint, streamed in via a queue like SQS or Kafka, or provided as a link to a location in a blob store. The labeler can use simple standard libraries to access the data.
Data may be transformed to prepare the data for training and/or inference. Frequently some amount of transformation will be required from raw input data to trainable/inferable data. This may include validity checking, image manipulation, aggregation, etc. As would be appreciated by those in the art, the transformations can depend on the requirements of the ML model being trained or used for inference.
Training (and retraining) is the process by which conditioned training data is converted into an executable model or a model is retrained. The output of training is an ML model that represents the best model currently producible given the available training data. It can be noted that in some embodiments, such as embodiments utilizing ensemble approaches, an ML labeler may use multiple models produced from training.
Training data enters the ML labeler 500 through its training data input pipe 502. This pipe, according to one embodiment, transfers data only, not labeling flow control. The schema of the training data input pipe is the same as the labeled output pipe. As such, it may need conditioning in order to be consumable by the training process. In some embodiments, training data accumulates in a repository, but may be subject to configurable data retention rules.
In some cases, end user-provided data or a publicly available dataset may be used as a training dataset. New models can be trained as additional training data becomes available. In addition, or in the alternative, training data can come from an “oracle” labeler (e.g., an oracle ML labeler or oracle human labeler). The output of the oracle labeler is assumed to be correct, or at least the most correct to which platform 102 has access for a use case.
Training data augmentation may be used to bolster and diversify the training data corpus by adding synthetic training data. This synthetic training data can be based on applying various transforms to raw training data.
There are a variety of options for triggering training. The trigger may be as simple as a certain number of training data records accumulating, or a certain percentage change therein. A training trigger may also incorporate input from a quality control subsystem. Time since last training can also be considered.
Output labels from an ML labeler 500 are the result of running a conditioned label request through a deployed ML model to obtain an inferred answer. This inference may not be in a form that is directly consumable by the rest of the labeling graph (as specified by the output pipe schema), in which case it is passed through an output conditioning pipeline (e.g., in conditioning layer 304). According to one embodiment, the label result output by an ML labeler 500, includes the input label request, the inferred label, and a self-assessed confidence measure.
An ML labeler includes code to implement or utilize an ML model. In some embodiments, the ML labeler may be implemented as a wrapper for an ML model on a model runtime platform 650 running locally or on a remote ML platform system (e.g., an ML platform system 130). The ML labeler configuration (discussed in more detail below in connection with
The configuration for the ML labeler includes a general configuration and an ML labeler-type specific configuration. The ML labeler-type specific configuration can include an ML algorithm configuration, a training pipe configuration and a training configuration. The ML algorithm configuration specifies an ML algorithm or platform to use and other configuration for the ML algorithm or platform (layers to use, etc.). In some cases, a portion of the ML algorithm configuration may be specific to the ML algorithm or platform. The training configuration can include an active learning configuration, hyper-parameter ranges, limits and triggers. A portion of the training configuration may depend on the ML algorithm or platform declared. The ML labeler configuration can also specify conditioning pipelines for the input, output, training or exception pipes.
ML labeler 600 includes an active learning record selector 630 to select records for active learning. Configuring active learning record selector 630 may include, for example, specifying an active learning strategy (e.g., lowest accuracy, FIFO, or some other selection technique) and a batch size of records to pass along for further labeling and eventual use as training data for ML labeler 600.
According to one embodiment, active learning record selector 630 selects all unlabeled records (or some specified number thereof) for a use case (records that have not yet been labeled by the ML labeler) and has those labeled by the ML model 620. The ML model 620 evaluates its results (e.g., provides a confidence in its results). Active learning record selector 630 evaluates the results (for instance, it may evaluate the confidences associated with the results) and forwards some subset of the results to the other labelers in the graph and/or an oracle labeler for augmented labeling. The augmented labeling comprises generating labels for the associated images or other data which have confidences that meet specified criteria. The augmented labeling may result in a correction of the label associated with the images or other data, or the high-confidence label generated by the augmented labeling may be the same as the label generated by ML model 620. A subset of the results generated by ML model 620 may alternatively be determined to have sufficiently high confidences that no augmented labeling of these results is necessary. The selected records with their final, high-confidence (e.g., augmented) results are then provided as training data for the ML labeler (albeit potentially with a different result determined by the confidence-driven workflow than by ML model 620).
An ML labeler can include a conditioning layer that conditions data used by the ML labeler. Embodiments may include, for example, a request conditioning pipeline to condition input requests, an inference conditioning pipeline to condition labeled results and/or a training request and label conditioning pipeline for conditioning training data. Each conditioning pipeline, if included, may comprise one or more conditioning components. The ML labeler configuration can specify the conditioning components to be used for request conditioning, inference de-conditioning and training and request conditioning, and can specify how the components are configured (for example, the configuration can specify the size of image to which an image resizing component should resize images).
In the embodiment illustrated in
The deconditioned labeling requests and inferences may be provided on output pipe 604 to a directed graph (not shown in the figure) that will function to reach a threshold confidence, generating a label with high confidence. This may include, but are not limited to, executable code labelers, third-party hosted endpoint labelers, ML labelers and human labelers, and CDW labelers. While some of the inferences generated by the champion model may have sufficiently high self-assessed confidence that they may be provided to customers or provided back to the system as training data, others will have lower associated confidences. These lower-accuracy labeling requests and inferences are processed by the high-confidence labeler(s) to generate high-accuracy labels, and the records with their corresponding high-confidence labels (e.g., augmented results) are provided on training data input pipe 606 to training request conditioning pipeline 610 as training data.
Training request conditioning pipeline 610 is provided for conditioning training data so that it can be used to train to challenger ML models. Conditioned training data 612 is accumulated in a training data storage device, and is retrieved from this storage device when needed to train one or more ML models. In this embodiment, training request conditioning pipeline 610 is part of the conditioning layer that further includes request conditioning pipeline 632 which conditions input requests, and inference conditioning pipeline 634 which conditions results (inferences) from the champion model. Each conditioning pipeline, if included, may comprise one or more conditioning components as specified in the ML labeler's configuration.
ML labeler 600 includes a training component 615 which is executable to train an ML algorithm. Training component 615 may be configured to connect to the appropriate ML platform 650 to train an ML algorithm to create an ML model. In this embodiment, training component 615 includes an experiment coordinator 616 that interfaces with model runtime platform 650 to train multiple challenger models. Each challenger model is configured using a corresponding set of hyperparameters or other mechanisms in order to train multiple, different candidate models (challenger models), each of which has its own unique characteristics that affect the labeling of requests. The ML labeler configuration may specify hyper-parameter ranges and limits to be used during training. Each of the challenger models therefore represents an experiment to determine the labeling performance which results from the different ML model configurations. The types of hyperparameters and other mechanisms used to train the candidate models may include those known in the art.
The ML labeler configuration can specify training triggers (trigger events), such that when the training component 615 detects a training trigger, the training component 615 initiates (re)training of the ML algorithm to determine a current active model. Training triggers may be based on, for example, an amount of training data received by the labeler, quality metrics received by the labeler, elapsed time or other criteria.
After the experiment coordinator trains the different candidate ML models, a challenger model evaluator 618 evaluates the candidate ML models against each other and against the current active model (the champion model) to determine which should be the current active model for inferring answers to labeling requests. This determination may be made on the basis of various different evaluation metrics that measure the performance of the candidate models. The determination may also take into account the cost of replacing the champion model (e.g., in some embodiments a challenger model may not be promoted to replace the champion model unless the performance of the challenger model exceeds that of the champion model by a threshold amount, rather than simply being greater than the performance of the champion model). The output of training component 615 is a champion ML model that represents the “best” model currently producible given the available training data and experimental configurations. The training component 615 thus determines the ML model to use as the current active model (the champion model) for inferring answers to labeling requests.
As noted above, the ML labeler 600 operates to optimize the model that is used to generate inferences corresponding to the labeling requests. This process begins with labeling requests being received on the input pipe of the ML labeler (step 662). In this embodiment, the labeling requests are received by the active learning record selector, but this could be performed by another component in an alternative embodiment. The labeling requests can be characterized as defined by the configuration of the ML labeler, which is discussed in more detail below in connection with
The labeling requests are provided by the active learning record selector to the request conditioning pipeline of the conditioning layer so that the labeling requests can be conditioned before they are provided to the champion model (step 664). In one embodiment, the conditioning consists of translating the labeling request from an original data domain to the data domain of the champion model so that the champion model will “understand” the labeling request (see, e.g.,
The conditioned requests are processed by the champion model to generate a result (an inference) for the request (step 666). In this embodiment, the champion model is also configured to generate a self-assessed confidence indicator, which is a value indicating a confidence level associated with the inference. The confidence indicator may indicate that the champion model has a high level of confidence associated with the generated inference (i.e., the model assesses the inference to be highly likely to be accurate), or it may indicate that the model has a lower level of confidence (i.e., the model assesses the inference to be less likely to be accurate). The processed request and the associated inference are provided with the confidence indicator to the deconditioning pipeline so that they can be translated from the champion models data domain back to the data domain of the original labeling request (step 668). The deconditioned requests and inferences are then provided to the active learning record selector.
The active learning record selector is configured to select a subset of the processed records to be used for purposes of training the challenger models and evaluating their performance against the champion model (step 666). The labeling requests are selected according to an active learning strategy which is determined by the configuration of the ML labeler. In some embodiments, for example, the labeler may implement strategies in which the records that are deemed to have the lowest accuracy, the lowest self-assessed confidence, or the lowest distributional representation in the current training data set may be selected for training (see, e.g.,
The records selected by the active learning record selector are provided to one or more high-accuracy labelers that may be part of a confidence-driven labeling service (step 672). The high-confidence labelers may include automated labelers and human labelers. The high-accuracy labelers generate a high-confidence label result for each of the records. Since the records were selected in this example as those having the lowest accuracy, the labels generated by the high-confidence labelers may well be different than the inferences generated by the champion model, but if the accuracy of the champion model itself is high, the generated labels may match the inferences of the champion model. When the high-confidence labels have been generated for the selected records, the generated label results are provided to the training data input pipe 606 so that they can be used for training and evaluation purposes (step 674).
The high-confidence label results input via the training data input pipe are provided to a training conditioning pipeline 610, which performs substantially the same function as request conditioning pipeline 632 (step 676). The conditioned requests and corresponding labels are then stored in a training data storage 612, where they may be accumulated for use by the training component of the ML labeler (step 678). In this embodiment, the requests and corresponding labels are stored until a trigger event is detected. The trigger event is detected by a training trigger that monitors information which may include quality metrics, the amount of training data that has been accumulated, or various other parameters (step 680). When the monitored information meets one or more conditions that define a trigger event, a portion of the accumulated training data is provided to the experiment coordinator of the training component (step 682).
The trigger event is also used by the experiment coordinator of the training component to initiate one or more experiments, each of which uses a corresponding set of hyper-parameters to configure a corresponding challenger model (step 684). Each of the experimental challenger models is uniquely configured in order to develop unique challenger models which can be compared to the champion model to determine whether the performance of the champion model can be improved. Each of these experimental challenger models is trained using the same training data that is provided from the training data store to the experiment coordinator (step 686). The trained challenger models can then be evaluated to determine whether they should be promoted to replace the champion model.
After the experimental challenger models are trained using the first portion of the training data, they are evaluated using a second portion of training data which is reserved in the training data storage (688). Normally, the second portion of the data will not overlap with the first portion of the training data. Additionally, while the first portion of the data (which is used to train the challenger models) normally includes only recently stored training data, the second portion of the training data may include older, historical training data. The second portion of the training data is processed by each of the trained challenger models, as well as the champion model to generate corresponding results/inferences (step 688). The results of the different models are evaluated against each other to determine their respective performance. The evaluation may be multidimensional, with several different aspects of the performance of each model being separately compared using different metrics, rather than using only a single evaluation metric. The specific metrics that are used for the evaluation are configurable and may vary from one embodiment to another.
After comparing the performance of each of the models, it is determined whether any of the challenger models shows improved performance over that of the champion model. If so, the challenger model with the greatest performance may be promoted to replace the champion model. In some embodiments, it may be desirable to replace the champion model only if the performance of the challenger model exceeds that of the champion model by a predetermined amount. In other words, if the challenger model has only slightly greater performance than the champion model, the overhead cost associated with replacing the champion model may outweigh the performance improvement, in which case the challenger model may not be promoted.
A CDW is a labeler that encapsulates a collection of labelers of the same arity which are consulted in sequence until a configured confidence threshold on the answer is reached. At a high level, multiple agreeing judgments about the same labeling request drive up confidence in the answer. On the other hand, a dissenting judgment decreases confidence. Embodiments of CDW labelers are discussed in related Provisional Application No. 62/950,699, Appendix 1.
The configuration for a CDW labeler can include, for example, an indication of the constituent labelers. The CDW configuration for a constituent labeler may indicate if the labeler should be treated as a blind judgement labeler or an open judgement labeler. As will be appreciated, the same labeling request may be resubmitted to a labeler as part of a CDW. For example, the same labeling request may be submitted to a human labeler for labeling by two different labeler instances. The CDW configuration of a constituent labeler may limit the number of times the same labeling request can be submitted to the labeler as part of a CDW.
The CDW configuration may thus be used to configure the workflow orchestrator of a CDW labeler.
As discussed above, labelers can be composed internally of a core processing kernel surrounded by a conditioning layer, which can include input conditioning, successful output conditioning, and exception output conditioning. The conditioning layer can be constructed by arranging conditioning components (e.g., conditioning components 112) into pipelines according to a labeler's configuration. An example image classification input conditioning pipeline and kernel core logic for an image classification labeler is illustrated in
Conditioning components perform operations such as data transformation, filtering, and (dis)aggregation. Similar to labelers, the conditioning component may have data input pipes, data output pipes, and exception pipes, but while labelers produce a labeling result from a labeling request, conditioning components simply perform input conditioning, output conditioning, or interstitial conditioning.
In some cases, conditioning components can be used to decompose an input request. For example, in some use cases, the overall labeling request can be decomposed into a collection of smaller labeling requests, all of the same type. This type of decomposition can be achieved within a single labeler using transformers in the conditioning layer. An example of this is classifying frames in a video. It is generally much easier to train a model to classify a single frame image than to classify all the frames in a variable-length video in a single shot. In this case, the data conditioning layer can be configured with a splitter to decompose the video into frames, run each frame through an ML image classification kernel, and combine the output per video.
The splitter can be implemented in the conditioning layer on the input pipe and training pipe of the labeler and is configured to split the video into individual frames. The label+confidence aggregator is implemented in the conditioning layer on the output pipe and aggregates the labels and confidences for the individual frames to determine a label and confidence for the video.
In addition, or in the alternative, it may be desirable to decompose the output label space. For example, when the output label space is too large to feasibly train a single ML model on the entire problem, the label space can be broken into shards, and a more focused ML labeler assigned to each shard. Consider a use case for localizing and classifying retail products in an image where there are hundreds of possible product types. In such a case, the label space may be carved up by broader product category.
Thus, a conditioning component may result in fan-in and fan-out conditions in a directed graph. For example,
Splitting or slicing can be achieved by label splitter components implemented in the respective conditioning pipelines. Fan-out can be configured by linking several labelers' request pipes to a single result pipe of a conditioning component. Fan-in can be achieved by linking multiple output pipes to a single input pipe of an aggregator conditioning component. The aggregator can be configured with an aggregation key identifier identifying which constituent data should be aggregated, a template specifying how to combine the inferences from multiple labelers and an algorithm for aggregating the confidences.
Platform 102 includes a configuration service 103 that allows a user (a “configurer”) to create a configuration for a use case. Configuration service 103 bridges the gap between a use case and labeling graph. According to one embodiment, configuration service 103 attempts to adhere to several principles:
With reference to
In the embodiment of
Platform 102 can include use case templates. Use case templates make assumptions regarding what should be included in a use case, and therefore require the least input from the human configurer. Using a use case template, the human user can enter a relatively small amount of configuration. The platform can store a declarative model for a use case, where the declarative model includes configuration assumptions specified by a use case template and the relatively small amount of configuration provided by the human user.
The DSL describes the logical architecture for the use case in a way that is agnostic to which specific set of infrastructure/tools are used at runtime. That is, the DSL specifies the labeling graph at the logical level. While DSL aims to be runtime-agnostic, it will be appreciated that different runtime platforms and tools have different capabilities and the DSL may be adapted to support some runtime-specific configuration information. Runtime specific configuration in the DSL can be encapsulated into named sections to make the runtime-specificity easily identifiable.
The DSL is expressed in a human and machine-friendly format. One such format, YAML, is used for the sake of example herein. It will be appreciated, however, that a declarative model may be expressed using other formats and languages.
DSL output from the system is in a canonical form. Although order doesn't typically matter for elements at the same level of indentation in a YAML document, a canonical DSL document will have predictable ordering and spacing. One advantage of producing such a canonical representation is to support comparison between different configurations.
Platform 102 can be configured to check DSL (or other configuration format) for correctness. By way of example, but not limitation, configuration service 103 checks for the following errors:
To support data provenance, versions of versionable components can be called out explicitly. According to one embodiment, version macros like “latest” are not supported. In such an embodiment, the system can proactively alert an operator when new versions are available.
According to one embodiment, a declarative model defines a configuration for each labeler such that each labeler can be considered self-contained (i.e., the entire logical configuration of the labeler is specified in a single block of DSL (or other identifiable structure) that specifies what data the labeler consumes, how the labeler operates and what data the labeler produces).
The configuration for a labeler may be specified as a collection of key-value pairs (field-value pairs, attribute-value pairs, name-value pairs). According to one embodiment, platform 102 is configured to interpret the names, in context of the structure of the declarative model to configure the labeling graph.
At a high level, the configuration of a labeler in a declarative model may include general labeler configuration (e.g., configuration keys that are not specific to the labeler type). For example, a declarative model may specify the following configuration information for each labeler of a labelling graph:
The declarative model may also specify labeler-type specific configuration (e.g., configuration keys that are specific to the labeler type). Labelers may have additional configuration, which varies by type.
For example, other than the generic configuration information that is common to all labelers, the configuration for an executable labeler will be specific to the code. Examples of things that could be configured include, but are not limited to: S3 bucket prefix, desired frame rate, email address to be notified, batch size. The configuration for an executable labeler can include any configuration information relevant to the executable code of the labeler. The configuration of the third-party hosted endpoint can specify which endpoint to hit (e.g., endpoint URL), auth credentials, timeout, etc.
As discussed above, the configuration for an ML labeler can provide the configuration for various functional components of the ML labeler. One example of a DSL block for an ML labeler is illustrated in
At label space declaration 1308, the DSL block declares the label space for the ML labeler. In this case, the value of the “labels” key-value pair is expressed as a list of classes.
At input pipe declaration 1310, the DSL block declares the labelling request input pipe for the labeler, assigning the input pipe a name. The DSL block further declares the input pipe schema. For example, the DSL block may include a JSON schema (e.g., according to the JSON Schema specification by the Internet Engineering Task Force, available at https://json-schema.org). The JSON schema may specify, for example, expected fields, field data types, whether a particular field is required (nullable), etc.
At runtime, the directed graph service 105 is aware of the input pipe of the first labeler in the labeling graph for a use case and pushes labeling requests onto that input pipe. The input pipes of subsequent labelers in the graph can be connected to the output pipes of other labelers.
At result pipe declaration 1312, the DSL block declares the output pipe name and schema. For example, the DSL block may include a JSON schema. The JSON schema may specify, for example, expected fields, field data types, whether a particular field is required (nullable), etc. In general, the output pipe of a labeler can be connected to the input pipe of another labeler. For the last labeler in a labeling graph, however, the output pipe is not connected to the input pipe of another labeler.
It can be noted that, in some cases, the connections between output pipes and input pipes are determined dynamically at runtime and are not declared in the declarative model. In other cases, the connections between input pipes and output pipes are declared in the declarative model.
An ML labeler may use training data to train an ML algorithm and, as such, a training pipe can be declared. In the example DSL of
ML labelers can be configured with a number of conditioning pipelines, where each conditioning pipeline comprises one or more conditioning components that transform data on the pipeline. Input conditioning declaration 1316 declares the transforms that are performed on data received on the input pipe and training pipe of the ML labeler. In the example of
Target conditioning declaration 1318 declares transforms to be applied to the labels specified at 1308. In the example of
Target de-conditioning declaration 1320 declares transforms to be applied to the output of the ML model. For example, an index value 0-4 output by the ML algorithm for an image can be transformed to the label space declaration at 1308. Thus, if platform 102 implements the “scene-classification-ml” labeler according to the configuration of
ML type labelers encapsulate or represent an ML platform, ML framework, and/or ML algorithm. As such, an ML algorithm declaration 1350 declares the ML platform, ML framework, and/or ML algorithm to be used by the ML labeler. Any type of ML algorithm supported by platform 102 (e.g., any ML algorithm supported by the model frameworks of ML platform systems 130 can be specified). Examples of ML algorithms include, but are not limited to: K-Means, Logistic Regression, Support Vector Machines, Bayesian Algorithms, Perceptron, and Convolutional Neural Networks. In the example illustrated, a tensorflow-based algorithm is specified. Thus, an ML labeler created based on the configuration of
Further, ML algorithms may have configurations that can be declared in the DSL block for the ML labeler via named data elements. For example, machine learning models in TensorFlow are expressible as the composition and stacking of relatively simple layers. Thus, a number of layers for the tensorflow-based algorithm is declared at 1352. It will be appreciated, however, that layers may be pertinent to some machine learning models, but not others. As such, a DSL block for an ML labeler using an algorithm that does not use layers may omit the layers data element. Moreover, other ML algorithms may have additional or alternative configuration that can be expressed via appropriately named data elements in DSL.
Training configuration for algorithms can include active learning, hyper-parameter ranges, limits, and triggers. Active learning declaration 1322 is used to configure the active learning records selector of the ML labeler. Active learning attempts to train the machine learning model of the ML labeler to obtain high accuracy as quickly as possible and an active learning strategy is a strategy for selecting records to be labeled (e.g., by an oracle labeler, by the rest of the graph for use as training data for the ML labeler), where the records will be used to train the ML labeler.
Platform 102 may support multiple strategies, such as random, lowest accuracy or other strategies. In the example of
Key-value pairs 1353 declare hyper-parameter ranges define the space for experimental hyper-parameter tuning. The hyper-parameter ranges can be used for example to configure experimentation/candidate model evaluation. As will be appreciated, the hyper-parameters used for training an ML algorithm may depend on the ML algorithm.
Training limits 1354 can be declared to constrain the resources consumed by the training process. Training limits may be specified as a limit on the amount of training data or training time limits.
Training trigger declaration 1356 declares triggers that cause platform 102 to train/retrain a model. Examples include, but are not limited to: a sufficient amount of training data has arrived, a specified period of time has passed, quality monitoring metrics dropping below a threshold or drifting by more than a specified amount (e.g., the ML algorithm score determined by the QMS is decreasing).
One example of a block of DSL for a human labeler is illustrated in
A task template declaration 1402 specifies a task template. The task template expresses a user interface to use for presenting a labeling request to a human for labeling and receiving a label assigned by the human to the labeling request. One example of a task template is included in related Provisional Application No. 62/950,699, Appendix 2.
Marketplace declaration 1404 specifies the platform(s) to which tasks from the labeler can be routed. For example, “mturk” represents the Amazon Mechanical Turk marketplace and “portal” represents a workforce portal provided by labeling platform 102. For some types of labeling (e.g. 3D point cloud labeling), highly specialized labeling tools may exist in the marketplace. For various reasons (e.g. cost, time to market), we may opt to integrate those tools into labeling platform 102 as a distinct marketplace as opposed to embedding the tool into our own portal.
Workforce declaration 1406 specifies the defined groups of human specialists to which tasks from the labeler can be routed (i.e., groups of human labeler instances to whom labeling tasks can be routed). If a workforce is declared for a use case, a human specialist must be a member of that workforce for labeling requests associated with the use case to be routed to that human specialist.
Skill declaration 1408 indicates the skills and minimum skill scores that individual workers (human specialists) must have to be routed labeling tasks from the labeler. The QMS may track skills/skill scores for individual human specialists.
A confidence-driven workflow configuration includes a list of constituent labelers that participate in the CDW. Each member of the list specifies an alias to the labeler definition, as well as CDW-specific metadata (e.g., previous result injection, max requests, and cost).
One example of a block of DSL for a CDW labeler is illustrated in
Portion 1508 lists the constituent labelers. The CDW configuration for a constituent labeler may indicate if the labeler should be treated as a blind judgement labeler or an open judgement labeler. In the illustrated embodiment, for example, the CDW configuration includes an inject-previous results key-value pair (e.g., key-value pair 1510). If the value is false, this indicates that the labeler will be treated as a blind judgement labeler. If the value is true, the labeler will be treated as an open judgement labeler.
As will be appreciated, the same labeling request may be resubmitted to a labeler as part of a CDW. For example, the same labeling request may be submitted to a human labeler for labeling by two different labelers. The CDW configuration of a constituent labeler may limit the number of times the same labeling request can be submitted to the labeler as part of a CDW. For example, key-value pair 1512 indicates that each labeling request is to be submitted only once to the labeler scene-classification-ml, whereas key-value pair 1514 indicates that the same labeling request may be submitted up to two times to the labeler scene-classification-hl-blind. The CDW configuration may thus be used to configure the workflow orchestrator of a CDW labeler.
It can be noted that the foregoing examples of DSL blocks for labelers are provided by way of example, but not limitation. Moreover, DSL blocks can be specified for other labelers or conditioning components.
As discussed above, platform 102 may include use case templates to simplify configuration for end users. Use case templates can make assumptions regarding what should be included in a declarative model for a use case, and thus require minimum input from the human configurer. The platform can store a declarative model for a use case, where the declarative model includes configuration assumptions specified by a use case template and the relatively small amount of configuration provided by the human user.
For common use cases, there are three main categories of configuration: elements that are always configured, elements that are commonly configured, and elements that are rarely configured. According to one embodiment, use case templates define default values for commonly or rarely configured elements including (but not limited to):
Example use case templates include, but are not limited to: image classification, object localization and classification within images, video frame classification, object localization and classification within videos, natural language processing and entity recognition. According to one embodiment, the always and commonly configured elements are supported with rich UI for customer or customer service reps, while other elements remain hidden.
In cases in which a use case template does not fit an end-user's requirements, a configurer can modify the use case configuration at the DSL level.
The definition and use of use case templates support reuse of common configurations. Config changes can be revision controlled, and the UI can support change history browsing and diff. By constraining the elements that can be changed at this level, the internal consistency of the configuration is much easier to verify.
In this example, a declarative model for “My_Use_Case” is populated with configuration information from the use case template “image-classification” and the additional configuration information provided by the user (e.g., the labels) and stored for the use case. At runtime, the declarative model is used to configure the labeling graph for labeling data or training an ML model associated with “My_Use_Case”.
The use of DSL and use cases is provided by way of example and configurations for labeling graphs can be provided through any suitable mechanism.
Returning to
When an end-user selects to execute a use case, configuration service 103 interacts with input service 104, directed graph service 105, confidence-driven workflow service 106, scoring service 107, ML platform 108 and dispatcher service 109 to create a workflow as configured by the use case. The workflow may be assigned a workflow id.
With respect to the input service 104, there may be several mechanisms for providing data to be labeled to platform 102, such as a web API, an S3 bucket, a KAFKA topic, etc. Configuration service 103 provides input service 104 with the end point information for the end point to use for receiving records to be labeled. The configuration information may include authentication information for the end point and other information.
Directed graph service 105 creates directed graphs for the labelers of the use case. According to one embodiment, all the directed graphs terminate in a success node or a failure node. When the directed graph terminates at success, the result is sent to the output service 115. The directed graph service 105 creates directed graphs of components to compose labelers (e.g., labelers 110). As discussed above, a given labeler can comprise a number of components conditioning components (e.g., filters, splitters, joiners, aggregators) and functional components (e.g., active record selectors, ML training component, ML model, human labeler instance to which a task interface is to be provided). Directed graph service 105 determines the directed graph of components and their order of execution to create labelers according the configuration. It can be noted that some labelers can include other labelers. Thus, a particular labeler may itself be a graph inside another labeler graph.
Configuration service 103 passes directed graph service 105 the configurations for the individual human, ML and other labelers of a use case so that directed graph service 105 can compose the various components into the specified labelers. According to one embodiment, configuration service 103 passes labeler DSL blocks to directed graph service 105.
A CDW may include various constituent labelers. For a use case that uses a CDW labeler, directed graph service 105 creates directed graphs for each of the constituent labelers of the CDW and CDW service 106 determines the next constituent labeler to which to route an input request—that is, CDW service 106 provides the workflow orchestrator for a CDW labeler. Configuration service 103 passes CDW service 106 the pool of labelers in a CDW, including static characteristics of those labelers like what their input and output pipes are, constraint information (time, price, confidence). It also passes configuration about where to get non-static information for the labelers, e.g. current consultation cost, current latency and throughput, and current quality. According to one embodiment, configuration service 103 passes the DSL block for a CDW labeler to CDW service 106.
Scoring service 107 can implement the quality monitoring subsystem (QMS) for the use case. In some embodiments, the algorithms used to score labeler instances are configurable as part of a use case. For example, for a use case to label images, where multiple labels can be applied, configuration service 103 may provide the configurer the option to select how results are scored if a labeler instance is partially correct (e.g., if any correct labels are wrong the entire judgement is considered wrong, if at least one label is correct the result is considered correct, etc.). Configuration service 103 can configure scoring service 107 with an indication of the scoring mechanism to use for the use case.
If a labeler for a use case is an ML labeler, configuration service 103 passes model specific information to model platform service 108 with, for example, the ML algorithm etc. The ML model platform service 108 can connect to the appropriate ML model platform.
Dispatcher service 109 is responsible for interacting with human specialists. Dispatcher service 109 routes tasks and task interfaces to human specialists and receives the human specialist labeling output. Configuration service 103 provides configuration information for human labelers to dispatcher service 109, such as the task template, labeler platforms, worker groups, worker skills, and minimum skill scores. For example, configuration service 103 can provide the DSL blocks for human labelers to dispatcher service 109 so that dispatcher service 109 can route tasks appropriately.
Turning to
As discussed above, scoring service 107 can provide a quality monitoring subsystem. Scoring service 107 is responsible for maintaining the current scores for the labeler instances (e.g., individual models or human specialists). Thus, as illustrated in
Although the invention has been described with respect to specific embodiments thereof, these embodiments are merely illustrative, and not restrictive of the invention. The description herein (including the disclosure of related U.S. Provisional Application No. 62/950,699) is not intended to be exhaustive or to limit the invention to the precise forms disclosed herein (and in particular, the inclusion of any particular embodiment, feature or function is not intended to limit the scope of the invention to such embodiment, feature or function). Rather, the description is intended to describe illustrative embodiments, features and functions in order to provide a person of ordinary skill in the art context to understand the invention without limiting the invention to any particularly described embodiment, feature or function. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes only, various equivalent modifications are possible within the spirit and scope of the invention, as those skilled in the relevant art will recognize and appreciate. As indicated, these modifications may be made to the invention in light of the foregoing description of illustrated embodiments of the invention and are to be included within the spirit and scope of the invention.
Thus, while the invention has been described herein with reference to particular embodiments thereof, a latitude of modification, various changes and substitutions are intended in the foregoing disclosures, and it will be appreciated that in some instances some features of embodiments of the invention will be employed without a corresponding use of other features without departing from the scope and spirit of the invention as set forth. Therefore, many modifications may be made to adapt a particular situation or material to the essential scope and spirit of the invention.
Reference throughout this specification to “one embodiment”, “an embodiment”, or “a specific embodiment” or similar terminology means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment and may not necessarily be present in all embodiments. Thus, respective appearances of the phrases “in one embodiment”, “in an embodiment”, or “in a specific embodiment” or similar terminology in various places throughout this specification are not necessarily referring to the same embodiment. Furthermore, the particular features, structures, or characteristics of any particular embodiment may be combined in any suitable manner with one or more other embodiments. It is to be understood that other variations and modifications of the embodiments described and illustrated herein are possible in light of the teachings herein and are to be considered as part of the spirit and scope of the invention.
Additionally, any examples or illustrations given herein are not to be regarded in any way as restrictions on, limits to, or express definitions of, any term or terms with which they are utilized. Instead, these examples or illustrations are to be regarded as being described with respect to one particular embodiment and as illustrative only. Those of ordinary skill in the art will appreciate that any term or terms with which these examples or illustrations are utilized will encompass other embodiments which may or may not be given therewith or elsewhere in the specification and all such embodiments are intended to be included within the scope of that term or terms. Language designating such nonlimiting examples and illustrations includes, but is not limited to: “for example,” “for instance,” “e.g.,” “in one embodiment.”
In the description herein, numerous specific details are provided, such as examples of components and/or methods, to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that an embodiment may be able to be practiced without one or more of the specific details, or with other apparatus, systems, assemblies, methods, components, materials, parts, and/or the like. In other instances, well-known structures, components, systems, materials, or operations are not specifically shown or described in detail to avoid obscuring aspects of embodiments of the invention. While the invention may be illustrated by using a particular embodiment, this is not and does not limit the invention to any particular embodiment and a person of ordinary skill in the art will recognize that additional embodiments are readily understandable and are a part of this invention.
Those skilled in the relevant art will appreciate that embodiments can be implemented or practiced in a variety of computer system configurations including, without limitation, multi-processor systems, network devices, mini-computers, mainframe computers, data processors, and the like. Embodiments can be employed in distributed computing environments, where tasks or modules are performed by remote processing devices, which are linked through a communications network such as a LAN, WAN, and/or the Internet. In a distributed computing environment, program modules or subroutines may be located in both local and remote memory storage devices. These program modules or subroutines may, for example, be stored or distributed on computer-readable media, stored as firmware in chips, as well as distributed electronically over the Internet or over other networks (including wireless networks). Example chips may include Electrically Erasable Programmable Read-Only Memory (EEPROM) chips.
Embodiments described herein can be implemented in the form of control logic in software or hardware or a combination of both. The control logic may be stored in an information storage medium, such as a computer-readable medium, as a plurality of instructions adapted to direct an information processing device to perform a set of steps disclosed in the various embodiments. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods to implement the invention. Steps, operations, methods, routines or portions thereof described herein be implemented using a variety of hardware, such as CPUs, application specific integrated circuits, programmable logic devices, field programmable gate arrays, optical, chemical, biological, quantum or nanoengineered systems, or other mechanisms.
Software instructions in the form of computer-readable program code may be stored, in whole or in part, temporarily or permanently, on a non-transitory computer readable medium. The computer-readable program code can be operated on by a processor to perform steps, operations, methods, routines or portions thereof described herein. A “computer-readable medium” is a medium capable of storing data in a format readable by a computer and can include any type of data storage medium that can be read by a processor. Examples of non-transitory computer-readable media can include, but are not limited to, volatile and non-volatile computer memories, such as RAM, ROM, hard drives, solid state drives, data cartridges, magnetic tapes, floppy diskettes, flash memory drives, optical data storage devices, compact-disc read-only memories. In some embodiments, computer-readable instructions or data may reside in a data array, such as a direct attach array or other array. The computer-readable instructions may be executable by a processor to implement embodiments of the technology or portions thereof.
A “processor” includes any, hardware system, mechanism or component that processes data, signals or other information. A processor can include a system with a general-purpose central processing unit, multiple processing units, dedicated circuitry for achieving functionality, or other systems. Processing need not be limited to a geographic location, or have temporal limitations. For example, a processor can perform its functions in “real-time,” “offline,” in a “batch mode,” etc. Portions of processing can be performed at different times and at different locations, by different (or the same) processing systems.
Different programming techniques can be employed such as procedural or object oriented. Any suitable programming language can be used to implement the routines, methods or programs of embodiments of the invention described herein, including R, Python, C, C++, Java, JavaScript, HTML, or any other programming or scripting code, etc. Communications between computers implementing embodiments can be accomplished using any electronic, optical, radio frequency signals, or other suitable methods and tools of communication in compliance with known network protocols. Any particular routine can execute on a single computer processing device or multiple computer processing devices, a single computer processor or multiple computer processors. Data may be stored in a single storage medium or distributed through multiple storage mediums. In some embodiments, data may be stored in multiple database, multiple filesystems or a combination thereof.
Although the steps, operations, or computations may be presented in a specific order, this order may be changed in different embodiments. In some embodiments, some steps may be omitted. Further, in some embodiments, additional or alternative steps may be performed. In some embodiments, to the extent multiple steps are shown as sequential in this specification, some combination of such steps in alternative embodiments may be performed at the same time. The sequence of operations described herein can be interrupted, suspended, or otherwise controlled by another process, such as an operating system, kernel, etc. The routines can operate in an operating system environment or as stand-alone routines. Functions, routines, methods, steps and operations described herein can be performed in hardware, software, firmware or any combination thereof.
It will be appreciated that one or more of the elements depicted in the drawings/figures can also be implemented in a more separated or integrated manner, or even removed or rendered as inoperable in certain cases, as is useful in accordance with a particular application. Additionally, any signal arrows in the drawings/figures should be considered only as exemplary, and not limiting, unless otherwise specifically noted.
As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having,” or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, product, article, or apparatus that comprises a list of elements is not necessarily limited only those elements but may include other elements not expressly listed or inherent to such process, product, article, or apparatus.
Furthermore, the term “or” as used herein is generally intended to mean “and/or” unless otherwise indicated. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present). As used herein, a term preceded by “a” or “an” (and “the” when antecedent basis is “a” or “an”) includes both singular and plural of such term, unless clearly indicated within the claim otherwise (i.e., that the reference “a” or “an” clearly indicates only the singular or only the plural). Also, as used in the description herein and throughout the meaning of “in” includes “in” and “on” unless the context clearly dictates otherwise.
Although the foregoing specification describes specific embodiments, numerous changes in the details of the embodiments disclosed herein and additional embodiments will be apparent to, and may be made by, persons of ordinary skill in the art having reference to this disclosure. In this context, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of this disclosure.
This application claims a benefit of priority from U.S. Provisional Application No. 62/950,699, filed Dec. 19, 2019, which is incorporated by reference herein as if set forth in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 62950699 | Dec 2019 | US |
