Patent Application
20230135703
The present disclosure relates to computer-implemented methods, systems, and apparatuses, for enabling the use of machine learning models in a low latency environment and/or using fewer computing resources than required by traditional machine learning systems.
Machine learning systems are trained and invoked to predict occurrences of event. For example, machine learning systems can be trained using historical data and labelled outcomes to predict future outcomes based on newly acquired data. These systems can be useful in a variety of use cases, but the ability to utilize machine learning can be limited based on the computing resources available and/or time constraints in which a computer system must generate a result.
In general, one innovative aspect of the subject matter described in this specification can be embodied in methods including obtaining, by one or more computers, session records from each of one or more users, wherein the session records specify information indicative of behaviors by the one or more users over a period of time; identifying, by the one or more computers and across the session records, a set of behavior records indicative of at least a specified number of most frequent behaviors; generating, by the one or more computers and for each behavior record in the set of behavior records, an embedding; storing, by the one or more computers, the generated embeddings for the set of behavior records in a first database; obtaining, by the one or more computers and from the user, a current behavior record; matching, by the one or more computers, the current behavior record to a matching set of stored behavior records; selecting, by the one or more computers, the stored embedding of the matching set of stored behavior records as an embedding of the current behavior record based on the matching and within a real-time constraint following entry of the current behavior record by the user; and generating, by the one or more computers and based on the embedding of the matching set of stored behavior records, a predicted next action of the user after entry of a last token in the current behavior record by the user.
Embodiments can include one or any combination of two or more of the following features.
The method includes generating candidate behavior records, each indicative of the predicted next action following the last token in the current behavior record by the user; identifying, across the candidate behavior records, a set of candidate behavior records indicative of at least a specified number of most frequent candidate behaviors; generating, for each candidate behavior record in the set of candidate behavior records, an embedding; storing the generated embeddings for the set of candidate behavior records in a second database; obtaining, from the user, a current candidate behavior record; matching the current behavior record to a matching set of stored candidate behavior records; and selecting the stored embedding of the matching set of stored candidate behavior records as an embedding of the current candidate behavior record based on the matching and within a real-time constraint following generating the candidate behavior record. The method includes generating a ranker model that predicts a likelihood of each candidate behavior record leading to one or more actions by the user; obtaining the score, for each candidate behavior record, based on the ranker model and the embedding of the candidate behavior record; and providing, for output on a user interface, the candidate behavior record that exceeds a predefined threshold as a predicted next action, wherein the predicted next action is identified and outputted within a real-time constraint after entry of the last token in the current behavior record by the user.
Other embodiments of this aspect include corresponding systems, devices, apparatus, and computer programs configured to perform the actions of the methods. The computer programs (e.g., instructions) can be encoded on computer storage devices.
These and other embodiments can each optionally include one or more of the following features. Sessions records include an identifier of the user and one or more behaviors by the user, wherein behaviors comprise one or more tokens received from the user and one or more actions taken by the user within the period of time. Tokens include one or more query terms entered by the user. Generating an embedding includes creating a vector representation in a low dimensional space. Matching the current behavior record to a matching set of stored behavior records includes determining a measure of similarity between the current behavior record and each behavior record in the first database and identifying the matching set of behavior records based on the measure of similarity.
Particular embodiments of the subject matter described in this specification can be implemented so as to realize one or more of the following advantages. For example, the techniques discussed in this specification can be implemented to enable the use of machine learning in situations where traditional machine learning approaches may not be feasible. More specifically, the techniques discussed herein enable machine learning to be utilized in systems that do not have the processing resources required to implement traditional machine learning techniques. Also, the techniques discussed herein enable machine learning to be utilized in time constrained systems that require an output from the machine learning system more quickly than feasible by traditional machine learning techniques. For example, the techniques discussed herein enable complex machine learning to be implemented in real-time systems, some of which are required to provide answers in less than 15 milliseconds, whereas traditional machine learning techniques could take at least one second or longer.
As discussed throughout this document, the techniques that enable machine learning to be implemented in these low-latency and/or low computing resource environments include breaking the overall machine learning techniques into sub-parts and implementing each part in a way that still considers a long activity history, while also utilizing the most recent data. For example, one technique can be used to reduce the amount of processing required to identify and/or use the long activity history, while another technique can be used to ensure that the most recent data is obtained and used in the training and prediction.
An example system in which these techniques may be used is a real-time search suggest system that requires a historically-context-aware approach to making suggestions (e.g., based on historical query/action data) as well as a real-time-context-aware approach (e.g., the ability to use current user input, such as a last entered token to make an appropriate suggestion). However, any system that requires lower latency and/or lower computing resources can benefit from the techniques discussed herein.
The details of one or more embodiments of the subject matter of this specification are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages of the subject matter will become apparent from the description, the drawings, and the claims.
Like reference numbers and designations in the various drawings indicate like elements.
The present disclosure relates to approaches to implementing machine learning in a low latency environment. Implementing machine learning includes steps of training a predictive model using training data and applying a pre-trained model to new data to make predictions. A system that implements machine learning (also referred to as a machine learning system) is configured to meet a certain latency constraint, e.g., computational resources and time. In some implementations, the low latency environment is a time constrained system, where time or computational resources needed for providing predictions must meet an acceptable threshold. For example, the machine learning system that implements a real-time prediction of next action of the user after entry of a last token (e.g., a search query) in a current behavior record requires latency in a scale of milliseconds (or tens of milliseconds). The current behavior record indicates the (near) real-time user’s behavior interacting with the system, and can be represented by one or more tokens. To enable machine learning in such low latency environment, the present disclosure describes an architecture that includes sub-parts of the machine learning techniques, where each part of the system can be pre-trained, ran in parallel, or in combinations with other parts. Specifically, storing pre-processed data based on at least a specified number of most frequent data (e.g., behavior records, continuing above example) in a database enables real-time processing, for example, in response to a most recently entered token by the user.
A network interface circuit 116 is also connected to the bus 114 to provide wired and/or wireless connectivity to the network 106. A memory or other storage medium 120 is also connected to the bus 114. The memory 120 stores instructions executed by the processor 110. In particular, the memory 120 stores instructions for an application 122, such as an electronic commerce application, which communicates with the server 104. In some implementations, each client device 102 is a mobile device (e.g., smartphone, laptop, tablet, wearable device, digital assistant device, etc.) executing the application 122. Different client devices 102 are operated by different users that use the same application 122. The application 122 can include a mobile application and a web environment displayed by a browser program.
The server 104 includes a processor 130, bus 132, input/output devices 134 and a network interface circuit 136 to provide connectivity to the network 106. A memory 140 is connected to the bus 132. The memory 140 stores a machine learning engine 142 with instructions executed by the processor 130 to implement operations disclosed in connection with
The machine learning engine 142 implements machine learning techniques, e.g., predicting next action of the user (described in more details below). The database 144 can include user information (e.g., identifier of the user, demographic information) and session records of the user (e.g., tokens received from the user, actions taken by the user; collectively defined as user behaviors). As a particular example, tokens include queries (e.g., search terms) by the user, and actions taken by the user include interaction, by the user, with a user selectable element (e.g., clicking on a link for an item, or purchasing an item). In some implementations, the system 100 processes information in the database 144 (e.g., by generating fast-access identifiers or references) such that the access to the information is computationally efficient. For example, the system 100 can apply the filter of a particular user to the database 144 to obtain records associated with the particular user. In some implementations, the system 100 optimizes a structure of the database 144 based on a data processing bandwidth to facilitate load balancing.
The application 200 includes a search query entry field 204. In some implementations, the search query entry field 204 may be initially empty, allowing the user to enter a new search query. In some implementations, the search query entry field 204 may include “search for anything” to indicate the user to enter a new search query. The user may be an account holder of a user account, or an authorized user of an account on the application 200. The user may select “Search” button next to the search query entry field 204 or may press the keyboard button to complete a new search query. The text that the user enters into the search query entry field 204 (example tokens received from the user) may subsequently be used by the computer system (e.g., a web server) to generate a set of search results based on the search query using one or more search algorithms.
The application 200 can include a set of recommended queries 206a-206d. In some implementations, the set of recommended queries 206a-206d can be based on the user’s session records (e.g., search history for over a period of time). For example, the application 200 may show “party supplies” 206c to the user, based on the user’s search history related to party supplies. In some implementations, the recommended queries 206a-206d can be based on data pertaining to other users’ sessions. For example, the application 200 may show “furniture” 206b as the environment 200 identified “furniture” as a popular search query based on the session records of other users past week.
In some implementations, the set of recommended queries 206a-206d are based on actions taken by the user within a specified period of time. Actions taken by the user include selecting a user selectable element, e.g., related to a set of merchandise items 208 (clicking a link to browse a merchandise, adding a merchandise to a shopping cart; setting a merchandise as a favorite, selecting an advertisement), and viewing a particular screen of the application 200.
The set of merchandise items 208 may also be customized to the user. In some implementations, the set of merchandise items related to a latest (e.g., most recently submitted) token (e.g., a search term) by the user can be presented. In some implementations, the featured merchandise items, based on recent popularity of merchandise items or other users’ session records, can be presented to the user.
As an example of implementing machine learning in a low latency environment,
When the user selects one of the suggested queries, the selected search term is highlighted. For example, the term “80’s furniture” is highlighted upon the user’s selection. Then, the application 200 displays updated search results based on the selected query of “80’s furniture.” In some implementations, the recommended queries 206 can be displayed as one or more selectable elements. The machine learning system that utilizes the user session in predicting next action of the user (e.g., generating search terms that are predicted to be of interest to the user, predicting an user selectable element the user will select, predicting a merchandise the user will purchase) is discussed in more details below.
The architecture 300 includes a processing engine 302 that obtains a session record 352 from each of one or more users of the application 122 (e.g., the electronic commerce environment as illustrated in
The session record 352 specifies information indicative of behaviors by the one or more users over a period of time. As a particular example, the session record 352 includes an identifier of the user and a behavior record 354 that includes one or more tokens received from the user (e.g., “dining table”, “furniture”, “80’s furniture”, where “dining table” is the most recent token) by the user from a period of time (e.g., 14 days or any other appropriate timeframe). In some implementations, the behavior record 354 includes one or more actions taken (e.g., clicking a merchandise, purchasing a merchandise, or setting a merchandise or a seller as a favorite) by the user within a period of time (e.g., behavior record = [“dining table”, clicking a user selectable element, “furniture”, adding a merchandise to a shopping cart, ...]). In some implementations, the session record 352 includes corresponding timestamps of each tokens and each actions, e.g., 2:14PM when the user clicked a merchandise.
After obtaining the session record 352, the processing engine 302 identifies a set of behavior records indicative of at least a specified number (N) of most frequent behaviors (also referred to as frequent behavior records 356). For example, the frequent behavior records 356 can include a search token “furniture” that appears frequently among users’ queries in past 14 days. In some implementations, the processing engine 302 sorts the obtained behavior records 354 based on the number of occurrence within a period of time and selects the N most frequent behavior records, where N is a pre-determined constant (e.g., 100 million).
A Generate Embedding Engine 304 receives the frequent behavior records 356 and generates an embedding 358 for each behavior record in the frequent behavior records 356. In some implementations, the Generate Embedding Engine 304 creates a vector representation in a low dimensional space for each behavior record, e.g., converting the alphanumeric text to a 512-bit vector 360 to represent each token (e.g., “furniture”). A length of the vector is based on a predetermined size by the architecture 300. Upon generating the embedding for each behavior record, the Generate Embedding Engine 304 stores the generated embeddings in a database, e.g., database 144.
The pre-computed embeddings stored in the database 144 can reduce computational time and usage of computational resources such that the system (e.g., the machine learning engine 142) can generate an embedding of a new behavior record within a real-time constraint. For example, when the session record 352 includes millions of tokens even after restricting to behavior records from past 7 days, the database 144 that contains the pre-computed embeddings can enable the system to meet the latency requirement. For example, the system can look up the embedding in the database based on the new behavior record and generate an embedding of the new behavior based on the look up results or inference.
The architecture 300 includes a Match Engine 306 that obtains a current behavior record 362 and matches the current behavior record 362 to a matching set of stored behavior records in the database 144. The current behavior record 362 can include a last token by the user (e.g., when a user inputs a new search query).
The Match Engine 306 determines a measure of similarity between the current behavior record 362 and each behavior record in the database 144. In some implementations, the measure of similarity is a pairwise correlation between a pair of behavior records. In some implementations, the measure of similarity is based on a distance (e.g., in a low dimensional space) from the current behavior record 362 to each behavior record in the database 144. Based on the measure of similarity, the Match Engine 306 identifies the matching set of behavior records. In some implementations, the matching set of behavior records is the nearest neighbor of the current behavior record 362 in a low dimensional space.
The Match Engine 306 selects the stored embedding of the matching set of stored behavior records as an embedding of the current behavior record 364 based on the matching and within a real-time constraint followed entry of the current behavior record 362 by the user. In some implementations, the Match Engine 306 infers the embedding of the current behavior record 364 based on the measure of similarity.
A prediction system 308 receives the embedding of the current behavior record 364 and generates a predicted next action of the user 366. Referring to
In some implementations, the Generate Candidate Behavior Engine 310 generates the candidate behavior records 368, based on a co-occurrence-based algorithm. The co-occurrence-based algorithm uses a pre-trained model of how different behavior records interact, or co-occur in a given session record of the user, using the session record 352 as training data.
In some implementation, the Generate Candidate Behavior Engine 310 generates the candidate behavior records 368, based on a generative model. Training the generative model, analogous to a next sentence prediction task, involves predicting a next, or candidate, behavior in a user session. The generative model can be trained on the session record 352, where a most recent token is treated as a future token (held out as evaluation data), a second most recent token is treated as a current token, and rest of tokens are treated as past tokens. Using these training data, the generative model finds parameters such that it maximizes a given log probability. Based on evaluation metrics (e.g., BLEU and ROUGE scores), the generative model can be optimized (e.g., by varying one or more of training parameters) to achieve an acceptable level of performance.
The prediction system 308 transmits the candidate behavior records 368 to the processing engine 302 that identifies a set of candidate behavior records indicative of at least a specified number (N) of most frequent candidate behaviors (also referred to as frequent candidate behavior records 370). The Generate Embedding Engine 304 generates an embedding 372 for each candidate behavior record in the frequent candidate behavior records 370).
Upon generating the embedding for each candidate behavior record, the Generate Embedding Engine 304 stores the generated embeddings in a database, e.g., database 144. The database that stores the frequent candidate behavior records 370 may be same or different than the database that stores the frequent behavior records 356.
The Match Engine 306 obtains a current candidate behavior record 376 and matches the current candidate behavior record 376 to a matching set of stored candidate behavior records in the database 144. The current candidate behavior record 376 is real-time candidate behavior records generated after receiving a last token in the current behavior record 362 by the user.
The Match Engine 306 determines the measure of similarity between the current candidate behavior record 376 and each candidate behavior record in the database 144 (the measure of similarity was previously discussed above). The Match Engine 306 selects the stored embedding of the matching set of stored candidate behavior records as an embedding of the current candidate behavior record 374 based on the matching and within a real-time constraint followed entry of the current behavior record 362 by the user. In some implementations, the Match Engine 306 infers the embedding of the current candidate behavior record 374 based on the measure of similarity.
The architecture 300 includes a Rank Engine 312 that obtains the embedding of the current candidate behavior record 374 and outputs predicted next action of the user 366. The Rank Engine 312 generates a score for each candidate behavior record, where the score (e.g., ranging from 0 to 1) represents a likelihood of each candidate behavior record leading to one or more actions by the user.
In some implementations, the score is based on the predicted occurrence of one or more following actions following the last token in the current behavior record by the user: purchasing a merchandise, adding a merchandise to a shopping cart, setting a merchandise or a seller as favorite, selecting an advertisement, or similar behaviors.
In some implementations, the Rank Engine 312 generates the score for each candidate behavior record based on a context-aware ranker model. The context-aware ranker model takes account of multiple candidate behavior records (and their interactions amongst). The context-aware ranker model can be trained on the session record 352 or synthetic data, using series of encoder blocks, e.g., f(x) = FC(encoder(encoder(... (encoder(FC(x))))), where FC represents a fully connected layer, and x is an input. As an output of the context-aware ranker model, a list of scores, each score corresponding to each candidate behavior record, is returned to the Rank Engine 312.
After obtaining the score, the Rank Engine 312 provides the candidate behavior record that exceeds a predefined threshold as a predicted next action. The predicted next action is identified and outputted on a user interface of the application 122 within a real-time constraint after entry of the last token in the current behavior record by the user. For example, the recommended queries 206 from
The system obtains session records from each of one or more users (402). The session records specify information indicative of behaviors by the one or more users over a period of time. The users can be the users of the application 122. In some implementations, the session records include an identifier of the user and one or more behaviors by the user. The behaviors include one or more tokens received from the user (e.g., queries by the user) and one or more actions taken (e.g., selecting a user selectable element by the user) by the user within the period of time (e.g., past 7 days). In some implementations, the system obtains the tokens and the actions taken by the user as separate data.
For example, each token can represent a search term input by the user, and each search term can be obtained prior to submission of the search query (e.g., prior to a user interacting with a “submit search” button, or pressing an “enter” key). In a specific example, the search query “rocking chair” can be represented by a token corresponding to the term “rocking” and another token corresponding to the term “chair”. In this example, the first token can be received once the user has typed the work “rocking” into a search box, and the other token can be received once the user has typed the work “chair” into the search box, and receipt of the tokens is not dependent on the user taking any affirmative action to submit the search query for processing.
The system identifies a set of behavior records indicative of at least a specified number of most frequent behaviors across the session records (404). In some implementations, the system counts the number of occurrence of each unique behaviors from the session records. In some implementations, the system sorts each unique behaviors based on the number of occurrence within a period of time and selects the specified number of most frequent behaviors across the session records. Continuing with the specific example above, the unique behaviors can be submissions of specific tokens or combinations of tokens, interactions with links presented to the user, and/or post search activities, such as completing a transaction or requesting additional information about an item.
In some implementations, the system imposes filtering on the session records such that the set of behavior records include particular behaviors. For example, the system can impose filtering on the session records to obtain only queries by the user (e.g., search terms received by the user).
The system generates an embedding for each behavior record in the set of behavior records (406). In some implementations, each behavior record is an alphanumerical text (e.g., “furniture”). In some implementations, for each behavior record, the system generates an embedding by creating a vector representation in a low dimensional space, e.g., 512-bit vector consisting of floating values.
The system stores the generated embeddings for the set of behavior records in a first database (408). The database 144 that communicates the server 104 can include the first database. In some implementations, the system stores the generated embeddings and their corresponding keys based on corresponding behavior records such that the system can look up, or inference, the embedding in the first database based on a given behavior record.
The system obtains a current behavior record from the user (410). The current behavior record includes the (near) real-time user’s behavior interacting with the system (e.g., the application 122). For example, the token just received by the user (e.g., one or more search terms of the search query “vintage furniture”) is an example token represented by the current behavior record.
The system matches the current behavior record to a matching set of stored behavior records (412). In some implementations, the system determines a measure of similarity between the current behavior record and each behavior record in the first database and identifies the matching set of behavior records based on the measure of similarity. For example, the matching set of behavior records can be a set of the stored behavior records that include the same tokens as the current behavior record, or a set of the stored behavior records that has at least a specified portion of the same tokens as the current behavior record. In some situations, the tokens need not be the same between the two sets of behavior records if they are semantically similar.
The system selects the stored embedding of the matching set of stored behavior records as an embedding of the current behavior record based on the matching and within a real-time constraint following entry of the current behavior record by the user (414). In some implementations, the system infers the embedding of the current candidate behavior record for the case that the exact matching was not found, e.g., based on the nearest neighbors algorithm by comparing the current behavior record to the stored behavior records in the first database. By using the stored embeddings, the system does not have to regenerate the stored embeddings, and therefore, can operate more quickly on the embeddings.
The system generates a predicted next action of the user based on the embedding of the matching set of stored behavior records after entry of a last token in the current behavior record by the user (416). In some implementations, generating the predicted next action of the user includes suggesting tokens (e.g., query terms) likely to be of interest to the user. In some implementations, generating the predicted next action of the user includes predicting the user’s activity interacting with the system (e.g., clicking a particular user selectable element; viewing a particular page).
In some implementations, the system generates candidate behavior records. Each candidate behavior record indicates the predicted next action following the last token in the current behavior record by the user. The system identifies, across the candidate behavior records, a set of candidate behavior records indicative of at least a specified number of most frequent candidate behaviors. The system generates, for each candidate behavior record in the set of candidate behavior records, an embedding. The system stores the generated embeddings for the set of candidate behavior records in a second database. In some implementations, the database 144 that communicates the server 104 can include the second database. The system obtains, from the user, a current candidate behavior record. The system matches the current behavior record to a matching set of stored candidate behavior records. The system selects the stored embedding of the matching set of stored candidate behavior records as an embedding of the current candidate behavior record based on the matching and within a real-time constraint following generating the candidate behavior record.
In some implementations, the system generates a ranker model that predicts a likelihood of each candidate behavior record leading to one or more actions by the user. The system obtains the score, for each candidate behavior record, based on the ranker model and the embedding of the candidate behavior record. In some implementations, the ranker model is a context-aware ranker model trained on the session records (either synthetic or historical data). The system provides, for output on a user interface, the candidate behavior record that exceeds a predefined threshold as a predicted next action, where the predicted next action is identified and outputted within a real-time constraint after entry of the last token in the current behavior record by the user.
This specification uses the term “configured” in connection with systems and computer program components. For a system of one or more computers to be configured to perform particular operations or actions means that the system has installed on it software, firmware, hardware, or a combination of them that in operation cause the system to perform the operations or actions. For one or more computer programs to be configured to perform particular operations or actions means that the one or more programs include instructions that, when executed by data processing apparatus, cause the apparatus to perform the operations or actions.
Embodiments of the subject matter and the functional operations described in this specification can be implemented in digital electronic circuitry, in tangibly-embodied computer software or firmware, in computer hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible non-transitory storage medium for execution by, or to control the operation of, data processing apparatus. The computer storage medium can be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of them. Alternatively or in addition, the program instructions can be encoded on an artificially-generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus for execution by a data processing apparatus.
The term “data processing apparatus” refers to data processing hardware and encompasses all kinds of apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus can also be, or further include, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). The apparatus can optionally include, in addition to hardware, code that creates an execution environment for computer programs, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.
A computer program, which may also be referred to or described as a program, software, a software application, an app, a module, a software module, a script, or code, can be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages; and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A program may, but need not, correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data, e.g., one or more scripts stored in a markup language document, in a single file dedicated to the program in question, or in multiple coordinated files, e.g., files that store one or more modules, sub-programs, or portions of code. A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a data communication network.
In this specification the term “engine” is used broadly to refer to a software-based system, subsystem, or process that is programmed to perform one or more specific functions. Generally, an engine will be implemented as one or more software modules or components, installed on one or more computers in one or more locations. In some cases, one or more computers will be dedicated to a particular engine; in other cases, multiple engines can be installed and running on the same computer or computers.
The processes and logic flows described in this specification can be performed by one or more programmable computers executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows can also be performed by special purpose logic circuitry, e.g., an FPGA or an ASIC, or by a combination of special purpose logic circuitry and one or more programmed computers.
Computers suitable for the execution of a computer program can be based on general or special purpose microprocessors or both, or any other kind of central processing unit. Generally, a central processing unit will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a central processing unit for performing or executing instructions and one or more memory devices for storing instructions and data. The central processing unit and the memory can be supplemented by, or incorporated in, special purpose logic circuitry. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. However, a computer need not have such devices. Moreover, a computer can be embedded in another device, e.g., a mobile telephone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device, e.g., a universal serial bus (USB) flash drive, to name just a few.
Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.
To provide for interaction with a user, embodiments of the subject matter described in this specification can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input. In addition, a computer can interact with a user by sending documents to and receiving documents from a device that is used by the user; for example, by sending web pages to a web browser on a user’s device in response to requests received from the web browser. Also, a computer can interact with a user by sending text messages or other forms of message to a personal device, e.g., a smartphone that is running a messaging application, and receiving responsive messages from the user in return.
Data processing apparatus for implementing machine learning models can also include, for example, special-purpose hardware accelerator units for processing common and compute-intensive parts of machine learning training or production, i.e., inference, workloads.
Machine learning models can be implemented and deployed using a machine learning framework, e.g., a TensorFlow framework, a Microsoft Cognitive Toolkit framework, an Apache Singa framework, or an Apache MXNet framework.
Embodiments of the subject matter described in this specification can be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface, a web browser, or an app through which a user can interact with an implementation of the subject matter described in this specification, or any combination of one or more such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN) and a wide area network (WAN), e.g., the Internet.
The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In some embodiments, a server transmits data, e.g., an HTML page, to a user device, e.g., for purposes of displaying data to and receiving user input from a user interacting with the device, which acts as a client. Data generated at the user device, e.g., a result of the user interaction, can be received at the server from the device.
While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any invention or on the scope of what can be claimed, but rather as descriptions of features that can be specific to particular embodiments of particular inventions. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features can be described above as acting in certain combinations and even initially be claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination can be directed to a subcombination or variation of a subcombination.
Similarly, while operations are depicted in the drawings and recited in the claims in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing can be advantageous. Moreover, the separation of various system modules and components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.
Particular embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. For example, the actions recited in the claims can be performed in a different order and still achieve desirable results. As one example, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some cases, multitasking and parallel processing can be advantageous.
