Method and apparatus for improved semantic parser including coarse semantic parser and fine semantic parser

Abstract

The present disclosure relates to improved semantic parsers including a coarse semantic parser and a fine semantic parser. Techniques are described for improving a semantic parser of a dialog system by decomposing the semantic parser into a coarse semantic parser and a fine semantic parser. The methods described herein include accessing an utterance received in a dialog system. The utterance is a text-based natural language expression. The methods further include applying a coarse semantic parser to the utterance to determine an intermediate logical form for the utterance. The intermediate logical form indicates one or more intents in the utterance. The methods further include applying a fine semantic parser to the intermediate logical form to determine a logical form for the utterance. The logical form is a syntactic expression of the utterance according to an established grammar, and the logical form includes one or more parameters of the one or more intents. The logical form can be used to have a conversation with a user of the dialog system.

Description

[0001] This application is a divisional application of the invention patent application filed on September 7, 2020, with application number 202010928486.0, entitled "An Improved Semantic Parser Including a Coarse Semantic Parser and a Fine Semantic Parser".

[0002] Cross-reference to related applications

[0003] This disclosure claims priority to U.S. Provisional Application Serial No. 62 / 898,683, filed September 11, 2019, entitled “Techniques for an Improved Semantic Parser Including a Coarse Parser and a Fine Parser” and U.S. Non-Provisional Application Serial No. 16 / 992,343, filed August 13, 2020, entitled “IMPROVED SEMANTIC PARSERINCLUDING A COARSE SEMANTIC PARSER AND A FINE SEMANTIC PARSER”, the entire contents of which are incorporated herein by reference. Technical Field

[0004] This disclosure relates to dialogue systems, and more specifically to techniques for determining improved semantic parsers or for using improved semantic parsers in dialogue systems, the improved semantic parsers including coarse semantic parsers and fine semantic parsers used together to determine intermediate logical forms based on utterances, and to determine logical forms based on intermediate logical forms and utterances. Background Technology

[0005] Today, a growing number of devices enable users to interact with them directly using voice or spoken words. For example, users can speak to such devices in natural language, asking questions or making statements requesting certain actions. In response, the device performs the requested action or responds to the user's question using audio output. Because interacting directly with voice is a more natural and intuitive way for humans to communicate with their surroundings, the adoption of such voice-based systems is growing at an astronomical rate. Summary of the Invention

[0006] This disclosure relates to techniques for determining an improved semantic parser for a dialogue system and techniques for using the improved semantic parser in a dialogue system, wherein the improved semantic parser comprises a coarse semantic parser and a fine semantic parser in series. In some embodiments, the coarse semantic parser maps utterances to intermediate logical forms, and the fine semantic parser maps utterances and intermediate logical forms to logical forms representing utterances. The intermediate logical forms may serve as templates for the logical forms, or as some other intermediate state or intermediate expression between the utterances and the logical forms.

[0007] In some embodiments, one or both of the coarse semantic parser and the fine semantic parser are machine learning models. The coarse semantic parser can be trained using a first set of tuples, each such tuple comprising a utterance and a corresponding intermediate logical form. During training, the utterance is labeled as input, and the logical form is labeled as output. Given this training, the coarse semantic parser learns to map utterances to intermediate logical forms. The fine semantic parser can be trained using a second set of tuples, each such tuple comprising a utterance, an intermediate logical form, and a logical form. During training, the utterance and the intermediate logical form are labeled as input, and the logical form is labeled as output. Given this training, the fine semantic parser learns to map utterances and corresponding intermediate logical forms to logical forms.

[0008] During the operation of a dialogue system, a coarse semantic parser receives utterances representing speech input and determines intermediate logical forms based on the utterances. A fine semantic parser receives the utterances and the intermediate logical forms determined by the coarse parser, and determines the logical form representing the utterances based on this input. This logical form can be used to enable dialogue with a user who has provided speech input.

[0009] The foregoing and other features and embodiments will become more apparent upon reference to the following description, claims and drawings. Attached Figure Description

[0010] Figure 1 This is a diagram of a dialogue system that combines a coarse semantic parser and a fine semantic parser as an improved semantic parser, according to some embodiments described herein.

[0011] Figure 2 This is a diagram of an improved semantic parser for use in a dialogue system, based on some embodiments described herein.

[0012] Figure 3 This is a diagram of a training system configured to train coarse and fine semantic parsers to serve as an improved semantic parser for a dialogue system, according to some embodiments described herein.

[0013] Figure 4 This is a diagram illustrating a method for training an improved semantic parser in a dialogue system according to some embodiments described herein.

[0014] Figure 5 This is a diagram illustrating a method for training a coarse semantic parser in an improved semantic parser according to some embodiments described herein.

[0015] Figure 6 This is a diagram illustrating a method for training a fine-grained semantic parser in an improved semantic parser according to some embodiments described herein.

[0016] Figure 7 This is a diagram of a distributed system used to implement some of the embodiments described herein.

[0017] Figure 8 This is a diagram of a cloud-based system environment according to some embodiments described herein, in which training these two parsers to act as an improved semantic parser can be provided at least partially as a cloud service.

[0018] Figure 9 These are diagrams of example computer systems that can be used to implement some of the embodiments described herein. Detailed Implementation

[0019] In the following description, specific details are set forth for purposes of explanation in order to provide a thorough understanding of certain embodiments. However, it will be apparent, however, that various embodiments may be practiced without these specific details. The accompanying drawings and description are not intended to be limiting. The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment or design described herein as “exemplary” or “example” is not necessarily to be construed as being more preferred or advantageous than other embodiments or designs.

[0020] Voice-enabled systems capable of conversing with users via voice input and audio output (also referred to as voice output) can take various forms. For example, such systems can be provided as standalone devices, digital or virtual assistants, voice-enabled services, etc. In each of these forms, the system is capable of receiving voice input, understanding voice input, generating a response or taking an action in response to voice input, and outputting the response using audio output. In some embodiments, the conversational functionality in such a voice-enabled system is provided by a conversational system or infrastructure (“conversational system”). The conversational system is configured to receive voice input, interpret voice input, maintain conversation, possibly perform one or more actions based on the interpretation of the voice input, prepare appropriate responses, and output the responses to the user using audio output.

[0021] Traditionally, dialogue systems incorporate various machine learning (ML) models, requiring substantial training data to train these models. One such ML model is the semantic parser subsystem, also known as the semantic parser. Typically, the semantic parser receives utterances representing speech input provided by a user, where the utterances are textual representations of natural language. The semantic parser maps these utterances to logical forms, which are the syntactic expressions of the utterances (e.g., translated into logic-based language following an established grammar), and are therefore parsed by the dialogue manager subsystem of the dialogue system. The dialogue manager subsystem then parses and processes the logical forms to determine how to respond.

[0022] Traditional semantic parser subsystems are typically configured as neural networks that map utterances to corresponding logical forms. The task of a semantic parser is challenging because logical forms can be quite complex or detailed, especially for complex utterances. As utterances become more complex or less like the data used to train the semantic parser, the logical forms generated by the semantic parser during operation of the dialogue system may deviate from what is considered accurate logical forms. In other words, there is a data sparsity problem, meaning the amount of training data used may be insufficient for the semantic parser to learn to generate a sufficient distribution of logical forms. This can cause the dialogue manager subsystem to receive inaccurate input and thus determine responses that do not match the speech input represented by the utterance. As a result, the dialogue manager subsystem may fail to achieve a dialogue that is useful to the user.

[0023] However, according to some embodiments described herein, the improved semantic parser is implemented as a combination of a coarse semantic parser and a fine semantic parser. The coarse semantic parser maps utterances to corresponding intermediate logical forms (also referred to as templates), and the fine semantic parser maps utterances and intermediate logical forms to logical forms that can be adapted for input into a dialogue manager subsystem of a dialogue system. In some embodiments, during operation of the dialogue system, utterances are input into a coarse semantic parser, which outputs an intermediate logical form for input along with the utterances into a fine semantic parser, which outputs the logical form.

[0024] By combining coarse and fine semantic parsers, some embodiments described herein mitigate the data sparsity problem because each of the coarse and fine semantic parsers only needs to learn a smaller output distribution. For example, considering that intermediate logical forms may be more general than logical forms, there may be fewer possible intermediate logical forms than logical forms. Therefore, for a coarse semantic parser, it may be easier to learn a sufficient distribution of intermediate logical forms than to learn a sufficient distribution of logical forms. Similarly, the fine semantic parser also reduces the workload compared to a conventional semantic parser because the starting point (i.e., the intermediate logical forms) is closer to the expected output of the logical forms. More generally, the embodiments described herein decompose the arduous task of determining logical forms from utterances into two smaller tasks: determining intermediate logical forms from utterances and determining logical forms from intermediate logical forms and utterances. Thus, the work of the semantic parser is divided into two parsers, each of which can learn its corresponding output distribution more efficiently, resulting in better overall results.

[0025] Now refer to the attached diagram, Figure 1 This is a diagram illustrating an example of a dialogue system 100 using an improved semantic parser 150, comprising a coarse semantic parser 152 and a fine semantic parser 154, according to certain embodiments described herein. The dialogue system 100 is configured to receive voice input 104 (also referred to as speech input) from a user 102. The dialogue system 100 can then interpret the voice input 104. The dialogue system 100 can maintain a dialogue with the user 102 and can perform one or more actions or cause one or more actions to be performed based on the interpretation of the voice input 104. The dialogue system 100 can prepare appropriate responses and can output the responses to the user using speech output or audio output (also referred to as audio output). The dialogue system 100 is a dedicated computing system that can potentially use a large number of computer processing loops to process large amounts of data. Figure 1 The number of devices depicted is provided for illustrative purposes. Different numbers of devices may be used. For example, although... Figure 1 Each device, server, and system in the diagram is shown as a single device, but multiple devices can also be used instead.

[0026] In some embodiments, the processing performed by the dialogue system 100 may be implemented by a pipeline of components or subsystems, including a voice input component 105, a wake word detection (WD) subsystem 106, an automatic speech recognition (ASR) subsystem 108, a natural language understanding (NLU) subsystem 110 including a named entity recognizer (NER) subsystem 112 and a semantic parser subsystem 150, a dialogue manager (DM) subsystem 116, a natural language generator (NLG) subsystem 118, a text-to-speech (TTS) subsystem 120, and a voice output component 124. The subsystems listed above may be implemented solely in software (e.g., using code, programs, or instructions executable by one or more processors or cores), in hardware, or a combination of hardware and software. In some embodiments, one or more subsystems may be combined into a single subsystem. Alternatively or additionally, in some embodiments, the functions described herein, such as those performed by a particular subsystem, may be implemented by multiple subsystems.

[0027] The voice input component 105 includes hardware and software configured to receive voice input 104. In some instances, the voice input component 105 may be part of a dialogue system 100. In other instances, the voice input component 105 may be decoupled from and communicatively coupled to the dialogue system 100. The voice input component 105 may, for example, include a microphone coupled to software configured to digitize the voice input 104 and transmit it to a wake-word detection subsystem 106.

[0028] A wake word detection (WD) subsystem 106 is configured to listen to and monitor an audio input stream to receive input corresponding to a specific sound or word or set of words (referred to as a wake word). Upon detecting a wake word from the dialogue system 100, the WD subsystem 106 is configured to activate the ASR subsystem 108. In some embodiments, the user may be provided with the ability to activate or deactivate the WD subsystem 106 (e.g., by pressing a button) to cause the WD subsystem 106 to listen to or stop listening for wake words. When activated or operating in activated mode, the WD subsystem 106 is configured to continuously receive an audio input stream and process the audio input stream to identify audio input (such as voice input 104) corresponding to the wake word. When audio input corresponding to the wake word is detected, the WD subsystem 106 activates the ASR subsystem 108.

[0029] As described above, the WD subsystem 106 activates the ASR subsystem 108. In some embodiments of the dialogue system 100, mechanisms other than wake word detection can be used to trigger or activate the ASR subsystem 108. For example, in some embodiments, a push button on the device can be used to trigger the ASR subsystem 108 without a wake word. In this embodiment, the WD subsystem 106 is not required. When the push button is pressed or activated, the voice input 104 received after button activation is provided to the ASR subsystem 108 for processing. Alternatively or additionally, in some embodiments, the ASR subsystem 108 can be activated upon receiving input to be processed.

[0030] The ASR subsystem 108 is configured to receive and monitor the voice input 104 after a trigger signal or wake-up signal (e.g., a wake-up signal may be sent by the WD subsystem 106 when a wake-up word is detected in the voice input 104, or a wake-up signal may be received when a button is activated), and convert the voice input 104 into text. As part of its processing, the ASR subsystem 108 performs the speech-to-text conversion. The voice input 104 may be in natural language form, and the ASR subsystem 108 is configured to generate corresponding natural language text in the language of the voice input 104. This corresponding natural language text is referred to herein as a utterance. For example, the voice input 104 received by the ASR subsystem 108 may include one or more words, phrases, clauses, sentences, questions, etc. The ASR subsystem 108 is configured to generate utterances for each spoken clause and feed the utterances to the NLU subsystem 110 for further processing.

[0031] NLU subsystem 110 receives utterances generated by ASR subsystem 108. The utterances received by NLU subsystem 110 from ASR subsystem 108 may include text utterances corresponding to spoken words, phrases, clauses, etc. NLU subsystem 110 translates each utterance (or a series of utterances) into its corresponding logical form.

[0032] In some implementations, the NLU subsystem 110 includes a Named Entity Recognizer (NER) subsystem 112 and a semantic parser subsystem 150. The NER subsystem 112 receives utterances as input, identifies named entities in the utterances, and tags the utterances using information associated with the identified named entities. The tagged utterances are then fed to the semantic parser subsystem 150, which is configured to generate a logical form for each tagged utterance, or for a series of tagged utterances. The logical form generated for an utterance can identify one or more intents corresponding to the utterance. The intent of an utterance identifies the purpose of the utterance. Examples of intents include “order pizza” and “find directions”. An intent can, for example, identify an action that is requested to be performed. In addition to intents, the logical form generated for an utterance can also identify slots (also referred to as parameters or arguments) of the identified intents. For example, for the voice input “I want to order a large pepperoni pizza with mushrooms and olives,” the NLU subsystem 110 can identify the intent—order pizza. The NLU subsystem can also identify and fill slots, such as pizza_size (filled with large) and pizza_toppings (filled with mushrooms and olives). The NLU subsystem 110 can generate a logical form using machine learning-based techniques, rules (which may be domain-specific), or a combination of machine learning techniques and rules. The logical form generated by the NLU subsystem 110 is then fed to the DM subsystem 116 for further processing.

[0033] In some embodiments, the semantic parser subsystem 150 of the NLU subsystem 110 includes a coarse semantic parser 152 and a fine semantic parser 154, which together map utterances to logical forms. The coarse semantic parser 152 receives utterances that may have been tagged by the NER subsystem 112 and generates an intermediate logical form corresponding to the utterance. The fine semantic parser 154 receives the utterance and the intermediate logical form and generates a logical form based on the utterance and the intermediate logical form. The logical form determined by the fine semantic parser 154 may correspond to the utterance, and therefore to the speech input 104, where the utterance of the speech input is a text representation.

[0034] The DM subsystem 116 is configured to manage dialogue with a user based on logical forms received from the NLU subsystem 110. As part of dialogue management, the DM subsystem 116 is configured to track dialogue states, initiate the execution of one or more actions or tasks, or perform one or more actions or tasks itself, and determine how to interact with the user. These actions may include, for example, querying one or more databases, generating execution results, or other actions. For example, the DM subsystem 116 is configured to interpret intents identified in the logical forms received from the NLU subsystem 110. Based on these interpretations, the DM subsystem 116 may initiate one or more actions that it interprets as requested by voice input 104 provided by the user. In some embodiments, the DM subsystem 116 performs dialogue state tracking based on current and past voice input 104 and on a set of rules (e.g., dialogue policies) configured for the DM subsystem 116. These rules may specify different dialogue states, conditions for transitions between states, actions to be performed when in a particular state, etc. These rules may be domain-specific. The DM subsystem 116 also generates responses to be transmitted back to the user involved in the dialogue. These responses can be based on actions initiated by the DM subsystem 116 and the results of those actions. The responses generated by the DM subsystem 116 are fed to the NLG subsystem 118 for further processing.

[0035] NLG subsystem 118 is configured to generate natural language text corresponding to the response generated by DM subsystem 116. The text may be generated in a form that allows it to be converted into speech by TTS subsystem 120. TTS subsystem 120 receives text from NLG subsystem 118 and converts each piece of text into speech or voice audio, which can then be output as audio to a user via audio or voice output component 124 of the dialogue system (e.g., a speaker or a communication channel coupled to an external speaker). In some instances, voice output component 124 may be part of dialogue system 100. In other instances, voice output component 124 may be decoupled from dialogue system 100 and communicatively coupled to it.

[0036] As described above, the various subsystems of the dialogue system 100 work collaboratively to provide the following functionality: enabling the dialogue system 100 to receive voice input 104, respond using voice output 122, and thereby maintain a dialogue with the user using natural language speech. These subsystems can be implemented using a single computer system or multiple computer systems working collaboratively. For example, for devices implementing voice-enabled systems, the subsystems of the dialogue system 100 can be implemented entirely on the device with which the user interacts. In some other embodiments, some components or subsystems of the dialogue system 100 can be implemented on the device with which the user interacts, while other components can be implemented remotely, possibly on other computing devices, platforms, or servers.

[0037] Figure 2 This is a diagram of a semantic parser 150 (also referred to herein as an improved semantic parser 150) for use in a dialogue system 100 according to some embodiments described herein. In some embodiments, the improved semantic parser 150 serves as a semantic parser subsystem of the dialogue system 100, potentially replacing a conventional semantic parser subsystem. Figure 2 As shown, the improved semantic parser 150 may include two ML models or two prediction models, which may be cascaded. Specifically, the semantic parser 150 may include a coarse semantic parser 152 and a fine semantic parser 154. According to some embodiments, after training the coarse and fine semantic parsers, the coarse semantic parser 152 maps utterance 215 to a corresponding intermediate logical form 225, and the fine semantic parser 154 maps the intermediate logical form 225 to a logical form 235. In some embodiments, such as Figure 2 As shown, the fine-grained semantic parser 154 takes utterance 215 along with intermediate logical form as additional input, and thus determines logical form 235 based on the combination of utterance 215 and intermediate logical form 225. Intermediate logical form 225 (also referred to herein as a template) is the framework or template of the corresponding logical form 235. In other words, intermediate logical form 225 is a more generalized version of logical form 235.

[0038] More specifically, in some embodiments, a coarse semantic parser 152 determines an intermediate logical form 225 that indicates each intent in the corresponding utterance 215 and indicates one or more slots of parameters that will refine the details of each intent. In such embodiments, a fine semantic parser 154 determines values ​​of such parameters to refine the intent and thus refine the overall logical form 235 based on the intermediate logical form 225. Therefore, the resulting logical form 235 includes one or more intents, and the parameters required to fully express the corresponding utterance 215 represented by such intents.

[0039] Traditionally, the semantic parser subsystem must learn the mapping from utterance 215 to logical form 235. Some embodiments described herein divide this mapping into multiple stages (specifically, two stages) so that each of the coarse semantic parser 152 and the fine semantic parser 154 performs only a portion of the task. In the dialogue system 100, the coarse semantic parser 152 and the fine semantic parser 154 are located in the semantic parser subsystem, specifically between the ASR subsystem 108 and the dialogue manager subsystem 116. For example, the utterance 215 input to the coarse semantic parser 152 may have already been determined by the ASR subsystem 108 and potentially labeled by the NER subsystem 112, and the logical form 235 output by the fine semantic parser 154 may be input to the dialogue manager subsystem 116 for processing.

[0040] In some embodiments, each of the coarse semantic parser 152 and the fine semantic parser 154 is implemented as hardware, software, or a combination of both. For example, each of the coarse semantic parser 152 and the fine semantic parser 154 may be implemented as one or more software functions, or dedicated hardware devices, or a combination of such software functions and dedicated hardware devices. In some embodiments, the coarse semantic parser 152 is an ML model; for example, the coarse semantic parser 152 may be a neural network such as a sequence-to-sequence (seq2seq) model. Further, in some embodiments, the fine semantic parser 154 is an ML model; for example, the fine semantic parser 154 may be a neural network such as a seq2seq model.

[0041] Figure 3 This is a diagram of a training system 300 configured, according to certain embodiments, to train two parsers to act as an improved semantic parser 150 for use in a dialogue system. Specifically, the training system 300 may train a coarse semantic parser 152 and a fine semantic parser 154, which together form the improved semantic parser 150. In some embodiments, the training system 300 is implemented as a computing device (such as a server) or part thereof. The training system 300 may be implemented as hardware, software, or a combination of both; more specifically, the training system 300 may be implemented as a dedicated hardware device, or program code, or a combination of both. Although the training system 300 is illustrated as... Figure 3 While the training system 300 may be a single box within a larger dataset, in some embodiments, the training system 300 is distributed across one or more functionalities, devices, or computing systems. For example, a first computing system of the training system 300 may train a coarse semantic parser 152, and a second computing system of the training system 300 may train a fine semantic parser 154.

[0042] By using training data 305 including utterance 215, intermediate logical form 225, and logical form 235, training system 300 can train coarse semantic parser 152 and fine semantic parser 154. Specifically, training system 300 can train coarse semantic parser 152 to map utterance 215 to its corresponding intermediate logical form 225, and training system 300 can train fine semantic parser 154 to map intermediate logical form 225 to its corresponding logical form 235, or in some embodiments, map a combination of utterance 215 and intermediate logical form 225 to its corresponding logical form 235.

[0043] The table below provides several examples of utterance 215, its corresponding intermediate logical form 225, and its corresponding logical form 235. It will be understood that these examples are for illustrative purposes only and do not limit the various embodiments.

[0044]

[0045] Typically, intermediate logic form 225 may conform to a first language that is less detailed (i.e., coarser) than the second language followed by logic form 235. In the example above, X, X1, and X2 are characters output by coarse semantic parser 152 to represent parameters or arguments, the values ​​of which are generated by fine semantic parser 154 and thus shown in logic form 235. Therefore, the first language may be a subset of the second language, such that variables are used in the first language to replace details that cannot be expressed in the first language. Such details can then be determined by fine semantic parser 154 and incorporated into the resulting logic form 235.

[0046] More specifically, in some embodiments, a coarse semantic parser 152 is trained to determine an intermediate logical form 225, which indicates each intent in the corresponding utterance 215 and indicates one or more slots for parameters that will refine the details of each such intent. Thus, in such embodiments, the intermediate logical form 225 indicates one or more intents and provides slots for a fine semantic parser 154 to fill with parameter values. The fine semantic parser 154 is then trained to determine the values ​​of such parameters in order to refine the logical form 235 based on the intermediate logical form 225. Therefore, the resulting logical form 235 includes one or more intents, and the parameters required to fully express the corresponding utterance 215 represented by such intents.

[0047] Figure 4This is a diagram of a method 400 for training an improved semantic parser 150, or in other words, a coarse semantic parser 152 and a fine semantic parser 154, according to some embodiments described herein. In some embodiments, the training system 300 uses this method 400 or a similar method to train the improved semantic parser 150 prior to the operation of the coarse semantic parser 152 and the fine semantic parser 154 in the dialogue system 100.

[0048] Figure 4 The method 400 described herein, as well as other methods described herein, can be implemented in software (e.g., code, instructions, or programs) executed by one or more processing units (e.g., processors, processor cores), in hardware, or in a combination thereof. The software can be stored on a non-transitory storage medium, such as a memory device. This method 400 is intended to be illustrative and non-limiting. Although Figure 4 Various activities that occur in a specific sequence or order are described, but this is not intended to be limiting. In some embodiments, for example, the activities may be performed in different orders, or one or more activities of method 400 may be performed in parallel. In some embodiments, method 400 may be performed by training system 300.

[0049] like Figure 4 As shown, at box 405, the training system 300 accesses a set of training data 305, which can be used to train the coarse semantic parser 152 and the fine semantic parser 154. The training data 305 may include a set of tuples, each tuple including a utterance 215, an intermediate logical form 225 corresponding to the utterance 215, and a logical form 235 corresponding to both the utterance 215 and the intermediate logical form 225. Various techniques exist for accessing this training data 305, and the training system 300 may use one or more of these techniques.

[0050] For example, training data 305 can be generated at least partially manually (e.g., through crowdsourcing). In one example, a set of logical forms 235 is automatically generated based on the grammar of logical forms 235, or a set of logical forms 235 is manually generated by a team based on the grammar of logical forms 235. As described above, in some embodiments, intermediate logical forms 225 specify one or more intents, and one or more slots to be filled for each intent. Because logical forms 235 are designed to be easily parsed to enable processing by the dialogue manager subsystem 116, an automated process can be used to identify the intents and slots in the logical forms 235. Thus, the automated process can remove parameter values ​​from the slots, thereby generating a corresponding intermediate logical form 225 for each logical form 235. Each logical form 235 is then paired with its corresponding intermediate logical form 225.

[0051] In some embodiments, pairs of logical forms 235 and intermediate logical forms 225 are then provided to a group of people (i.e., a crowd), who manually determine one or more utterances 215 corresponding to each pair of intermediate logical forms 225 and logical forms 235. The crowd may be useful for determining utterances 215 rather than logical forms 235, as people may be more familiar with natural language than with the grammar of logical forms 235; however, it is expected that members of the crowd are sufficiently accustomed to the grammar of logical forms 235 to be able to interpret the provided logical forms 235.

[0052] Because natural language provides multiple ways to convey information, a group of people may, in some situations, determine multiple utterances for a pair of intermediate logical forms 225 and logical forms 235. In the tuples included in the training data 305, each utterance 215 can be combined with its corresponding intermediate logical form 225 and logical form 235. If multiple utterances 215 are generated for a pair, each such utterance 215 can be combined with its corresponding pair in its own corresponding tuple.

[0053] The various tuples of utterance 215, intermediate logical form 225, and logical form 235 can be saved as training data 305. The training system 300 can then access the generated training data 305. For example, an administrator can copy the training data 305 to a memory device accessible by the training system 300.

[0054] At box 410, training system 300 trains coarse semantic parser 152 based on training data 305. In some embodiments, training system 300 trains coarse semantic parser 152 for each pair of utterances and intermediate logic forms 225 in a tuple, using utterances 215 labeled as inputs and intermediate logic forms 225 labeled as outputs. Additional details of training coarse semantic parser 152 are provided in [the following text is missing from the original extract]. Figure 5 It is shown in the figure and described further below.

[0055] At box 415, the training system 300 trains a fine-grained semantic parser 154 based on training data 305. In some embodiments, the training system 300 trains the fine-grained semantic parser 154 for each tuple using utterances 215 labeled as input, intermediate logical forms, and logical forms 235 labeled as output. Additional details regarding the training of the fine-grained semantic parser 154 are provided in [the following text is missing from the original extract]. Figure 6 It is shown in the figure and described further below.

[0056] Although box 410 is executed before box 415 in this example, it will be understood that this order is for illustrative purposes only. In some embodiments, for example, training system 300 may train fine semantic parser 154 before training coarse semantic parser 152, or may train coarse semantic parser 152 and fine semantic parser 154 in parallel.

[0057] At box 420, training system 300 provides a coarse semantic parser 152 and a fine semantic parser 154 in dialogue system 100. For example, if training system 300 and dialogue system 100 execute on the same computing system, training system 300 updates coarse semantic parser 152 and fine semantic parser 154 during training, making the trained coarse semantic parser 152 and fine semantic parser 154 accessible to dialogue system 100. Alternatively, an administrator can copy coarse semantic parser 152 and fine semantic parser 154 to a memory device accessible to dialogue system 100, thereby enabling dialogue system 100 to use coarse semantic parser 152 and fine semantic parser 154. In the dialogue system, coarse semantic parser 152 and fine semantic parser 154 can be used in series to replace traditional semantic parsers.

[0058] Figure 5 This is a diagram of a method 500 for training an improved semantic parser 150, specifically a coarse semantic parser 152, according to some embodiments described herein. In some embodiments, the training system 300 utilizes this method 500 or a similar method at block 410 of the above method 400. Figure 5 The method 500 described herein, as well as other methods described herein, can be implemented in software (e.g., code, instructions, or programs) executed by one or more processing units (e.g., processors, processor cores), in hardware, or in a combination thereof. The software can be stored on a non-transitory storage medium, such as a memory device. This method 500 is intended to be illustrative and non-limiting. Although Figure 5 Various activities that occur in a specific sequence or order are described, but this is not intended to be limiting. In some embodiments, for example, the activities may be performed in different orders, or one or more activities of method 500 may be performed in parallel. In some embodiments, method 500 may be performed by training system 300.

[0059] At box 505, training system 300 initializes coarse semantic parser 152. Typically, training a neural network (as in some embodiments, such as coarse semantic parser 152) involves updating the weights of nodes in the neural network using a training dataset (such as training data 305) to produce a good input-to-output mapping. For this purpose, a loss function is used during training to compare the output from the neural network with the expected output. The weights in the neural network are updated using the output from the loss function, thereby training the neural network, or in other words, causing the neural network to learn the desired mapping. In this case, the desired mapping for coarse semantic parser 152 is the mapping from utterance 215 to intermediate logical form 225. To initialize coarse semantic parser 152 for training, in some embodiments, training system 300 may select appropriate initial weights for each node in the neural network acting as coarse semantic parser 152.

[0060] At box 510, training system 300 accesses training data 305. As described above, training data 305 may include tuples, each tuple including utterance 215 and intermediate logical form 225. Although training data 305 may also include logical form 235 in tuples, in some embodiments, training of coarse semantic parser 152 does not require logical form 235, and training system 300 may ignore logical form 235 when training coarse semantic parser 152.

[0061] At box 515, the training system 300 selects tuples from the training data 305, wherein the selected tuples have not been considered during training or, in the case of multiple epochs (i.e., multiple restarts). Box 515 initiates an iterative loop in which each tuple of the training data 305 is considered, wherein one selected tuple is considered in each iteration of the loop.

[0062] At box 520, the training system 300 uses a coarse semantic parser 152 to determine the intermediate logical form of the prediction based on input equal to the utterance 215 in the selected tuple. In other words, in some embodiments, the training system 300 provides the utterance 215 from the selected tuple as input to the coarse semantic parser 152, which predicts the intermediate logical form of the prediction based on the utterance 215.

[0063] At box 525, training system 300 updates coarse semantic parser 152 based on a comparison of the predicted intermediate logical form with intermediate logical form 225 in the selected tuple. For example, comparing the predicted intermediate logical form with intermediate logical form 225 may include applying a loss function to both the predicted intermediate logical form and intermediate logical form 225, such that the output of the loss function represents the variance between the two values. In some embodiments, intermediate logical form 225 in the selected tuple is the expected output for the input utterance 215, and therefore, training system 300 modifies coarse semantic parser 152 based on the variance between the predicted intermediate logical form as predicted by coarse semantic parser 152 and the intermediate logical form 225 as the correct output.

[0064] At decision box 530, training system 300 determines whether any tuples remain in training data 305 for consideration. If such tuples remain, method 500 returns to box 515 to select another tuple. However, if no such tuples remain, method 500 proceeds to box 535. At box 535, this training ends, and coarse semantic parser 152 is ready for use in dialogue system 100. Coarse semantic parser 152 has learned the mapping from utterance 215 to its corresponding intermediate logical form 225.

[0065] The method 500 described above is a simplified approach for training the coarse semantic parser 152, and various modifications can be made to the techniques therein. For example, the training system 300 can update the coarse semantic parser 152 based on multiple batches of tuples, instead of updating it after processing each tuple. Furthermore, the training system 300 can implement one or more restarts during training, wherein each restart includes reinitializing the weights of the coarse semantic parser 152 to new initial values ​​to determine whether the learned mapping can be improved by using different weights at initialization. Additionally or alternatively, various other changes can be made to these aspects.

[0066] Figure 6 This is a diagram of a method 600 for training a refined semantic parser 154 in an improved semantic parser 150 according to some embodiments described herein. In some embodiments, the training system 300 utilizes this method 600 or a similar method at block 415 of the above method 400. Figure 6 The method 600 described herein, as well as other methods described herein, can be implemented in software (e.g., code, instructions, or programs) executed by one or more processing units (e.g., processors, processor cores), in hardware, or in a combination thereof. The software can be stored on a non-transitory storage medium, such as a memory device. This method 600 is intended to be illustrative and non-limiting. Although Figure 6 Various activities that occur in a specific sequence or order are described, but this is not intended to be limiting. In some embodiments, for example, activities may be performed in different orders, or one or more activities of method 600 may be performed in parallel. In some embodiments, method 600 may be performed by training system 300.

[0067] At box 605, the training system 300 initializes the fine-grained semantic parser 154. Typically, training a neural network (in some embodiments, such as the fine-grained semantic parser 154) involves updating the weights of nodes in the neural network using a training dataset (such as training data 305) to produce a good input-to-output mapping. For this purpose, a loss function is used during training to compare the output from the neural network with the expected output. The weights in the neural network are updated using the output from the loss function, thereby training the neural network, or in other words, causing the neural network to learn the desired mapping. In this case, the desired mapping for the fine-grained semantic parser 154 is the mapping from utterance 215 to intermediate logical form 225. To initialize the fine-grained semantic parser 154 for training, in some embodiments, the training system 300 may select appropriate initial weights for each node in the neural network that acts as the fine-grained semantic parser 154.

[0068] At box 610, training system 300 accesses training data 305. As described above, training data 305 may include tuples, each tuple including intermediate logical form 225 and logical form 235. Training data 305 may also include utterances 215 in the tuples, and training of fine semantic parser 154 may or may not use these utterances 215. Some implementations of fine semantic parser 154 are configured, for example, based on the training described herein, to map a pair of utterances 215 and intermediate logical forms 225 to corresponding logical forms 235, and in this case, training system 300 may use utterances 215, intermediate logical forms 225, and logical forms 235 to train fine semantic parser 154. However, some implementations of fine semantic parser 154 are configured, for example, based on the training described herein, to map intermediate logical forms 225 to corresponding logical forms 235, and in this case, in some embodiments, training system 300 may use intermediate logical forms 225 and logical forms 235 without using utterances 215 to train fine semantic parser 154.

[0069] At box 615, the training system 300 selects tuples from the training data 305, wherein the selected tuples have not been considered during training or, in the case of multiple epochs (i.e., multiple restarts). Box 615 initiates an iterative loop in which each tuple of the training data 305 is considered, wherein one selected tuple is considered in each iteration of the loop.

[0070] At box 620, the training system 300 uses a fine-grained semantic parser 154 to determine the predicted logical form based on input equal to the intermediate logical form 225 from the selected tuple (and in some embodiments, utterance 215). In other words, in some embodiments, the training system 300 provides the fine-grained semantic parser 154 with the intermediate logical form 225 from the selected tuple, or utterance 215 and intermediate logical form 225, as input, based on which the fine-grained semantic parser predicts the predicted logical form.

[0071] At box 625, training system 300 updates fine semantic parser 154 based on a comparison of the predicted logical form with logical form 235 in the selected tuple. For example, comparing the predicted logical form with logical form 235 may include applying a loss function to the predicted logical form and logical form 235, such that the output of the loss function represents the variance between the two values. In some embodiments, logical form 235 in the selected tuple is the expected output for a given input (i.e., intermediate logical form 225, or alternatively, utterance 215 and intermediate logical form 225). Therefore, training system 300 modifies fine semantic parser 154 based on the variance between the predicted logical form, as predicted by fine semantic parser 154, and logical form 235 as the correct output.

[0072] At decision box 630, training system 300 determines whether any tuples remain in training data 305 for consideration. If such tuples remain, method 600 returns to box 615 to select another tuple. However, if no such tuples remain, method 600 proceeds to box 635. At box 635, this training ends, and fine-grained semantic parser 154 is ready for use in dialogue system 100. Fine-grained semantic parser 154 has learned the mapping from utterance 215 and intermediate logical form 225 to their corresponding logical form 235.

[0073] The method 600 described above is a simplified approach for training the fine-grained semantic parser 154, and various modifications can be made to the techniques therein. For example, the training system 300 can update the fine-grained semantic parser 154 based on multiple batches of tuples, instead of updating it after each tuple is processed by the fine-grained semantic parser 154. Furthermore, the training system 300 can implement one or more restarts during training, wherein each restart includes reinitializing the weights of the fine-grained semantic parser 154 to new initial values ​​to determine whether the learned mapping can be improved by using different weights at initialization. Additionally or alternatively, various other changes can be made to these aspects.

[0074] Figure 7 This is a simplified diagram of a distributed system 700 for implementing certain embodiments. In the illustrated embodiment, the distributed system 700 includes one or more client computing devices 702, 704, 706, and 708 coupled to a server 712 via one or more communication networks 710. The client computing devices 702, 704, 706, and 708 can be configured to execute one or more applications.

[0075] In various embodiments, server 712 may be adapted to run one or more services or software applications that enable the training of coarse semantic parser 152 or fine semantic parser 154 as described herein, or enable the use of coarse semantic parser 152 or fine semantic parser 154 in dialogue system 100. For example, server 712 may perform training of some or all aspects of system 300 or dialogue system 100.

[0076] In some embodiments, server 712 may also provide other services or software applications that may include non-virtual and virtual environments. In some embodiments, these services may be provided as web-based services or cloud services (such as under a Software as a Service (SaaS) model) to users of client computing devices 702, 704, 706, and / or 708. Users operating client computing devices 702, 704, 706, and / or 708 may then use one or more client applications to interact with server 712 to utilize the services provided by these components. More specifically, for example, each of client computing devices 702, 704, 706, and / or 708 may be an embedded device configured to execute dialogue system 100 and further configured to communicate with server 712 such that server 712 can train coarse semantic parser 152 or fine semantic parser 154, or be able to use coarse semantic parser 152 or fine semantic parser 154 in dialogue system 100.

[0077] exist Figure 7 In the depicted configuration, server 712 may include one or more components 718, 720, and 722 that implement the functions performed by server 712. These components may include software components that can be executed by one or more processors, hardware components, or a combination thereof. It should be understood that various different system configurations, different from distributed system 700, are possible. Therefore, Figure 7 The illustrated embodiment is an example of a distributed system for implementing the system of the embodiment and is not intended to be limiting.

[0078] According to the teachings of this disclosure, a user can interact with aspects of the dialogue system 100 provided by server 712 using client computing devices 702, 704, 706, and / or 708. The client devices can provide an interface (e.g., a voice interface) that enables a user of the client device to interact with the client device. The client device can also output information to the user through this interface. Although Figure 7 It describes only four client computing devices, but can support any number of client computing devices.

[0079] Client devices can include various types of computing systems, such as PA devices, portable handheld devices, general-purpose computers such as personal computers and laptops, workstation computers, wearable devices, gaming systems, thin clients, various messaging devices, sensors, or other sensing devices. These computing devices can run various types and versions of software applications and operating systems (e.g., Microsoft Windows®, Apple Macintosh®, UNIX® or UNIX-like operating systems, Linux or Linux-like operating systems (such as Google Chrome™ OS)), including various mobile operating systems (e.g., Microsoft Windows Mobile®, iOS®, Windows Phone®, Android™, BlackBerry®, Palm OS®). Portable handheld devices can include cellular phones, smartphones (e.g., iPhone®), tablet computers (e.g., iPad®), personal digital assistants (PDAs), etc. Wearable devices can include Google Glass® head-mounted displays and other devices. Gaming systems can include various handheld gaming devices, Internet-enabled gaming devices (e.g., Microsoft Xbox® game consoles with or without Kinect® gesture input devices, Sony PlayStation® systems, various gaming systems provided by Nintendo®, and others), etc. Client devices can run a variety of different applications, such as various Internet-related applications, communication applications (e.g., email applications, short message service (SMS) applications), and can use various communication protocols.

[0080] The (multiple) networks 710 can be any type of network familiar to those skilled in the art that supports data communication using any of a variety of available protocols, including but not limited to TCP / IP (Transmission Control Protocol / Internet Protocol), SNA (System Network Architecture), IPX (Internet Packet Switching), AppleTalk®, etc. By way of example only, the (multiple) networks 710 can be a local area network (LAN), an Ethernet-based network, a token ring, a wide area network (WAN), the Internet, a virtual network, a virtual private network (VPN), an intranet, an extranet, a public switched telephone network (PSTN), an infrared network, a wireless network (e.g., a network operating under the IEEE 802.11 protocol suite, Bluetooth®, and / or any other wireless protocol) and / or any combination of these and / or other networks.

[0081] Server 712 may comprise one or more general-purpose computers, special-purpose server computers (including, by way of example, PC (personal computer) servers, UNIX® servers, mid-range servers, mainframe computers, rack servers, etc.), server clusters, server groups, or any other suitable arrangement and / or combination thereof. Server 712 may include one or more virtual machines running a virtual operating system or other computing architectures involving virtualization (such as one or more flexible pools of virtual storage devices that can be virtualized to maintain the server). In various embodiments, server 712 may be adapted to run one or more services or software applications that provide the functionality described in the foregoing disclosure.

[0082] The computing system in server 712 can run one or more operating systems, including any of the operating systems discussed above and any commercially available server operating system. Server 712 can also run any of a variety of additional server applications and / or middleware applications, including HTTP (Hypertext Transport Protocol) servers, FTP (File Transfer Protocol) servers, CGI (Common Gateway Interface) servers, JAVA® servers, database servers, etc. Exemplary database servers include, but are not limited to, those commercially available from Oracle®, Microsoft®, Sybase®, IBM®, etc.

[0083] In some implementations, server 712 may include one or more applications to analyze and merge data feeds and / or event updates received from users of client computing devices 702, 704, 706, and 708. As an example, data feeds and / or event updates may include, but are not limited to, Twitter® feeds, Facebook® updates, or real-time updates received from one or more third-party information sources and continuous data streams. These real-time updates may include real-time events related to sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, vehicle traffic monitoring, and the like. Server 712 may also include one or more applications to display data feeds and / or real-time events via one or more display devices of client computing devices 702, 704, 706, and 708.

[0084] The distributed system 700 may also include one or more data repositories 714, 716. In some embodiments, these data repositories may be used to store data and other information. For example, one or more of data repositories 714, 716 may be used to store training data 305, or other data required for training the coarse semantic parser 152 or the fine semantic parser 154, or for use in the dialogue system 100 with the coarse semantic parser 152 or the fine semantic parser 154. Data repositories 714, 716 may reside in various locations. For example, the data repository used by server 712 may be local to server 712 or may be located remotely to server 712 and communicate with server 712 via a network-based or dedicated connection. Data repositories 714, 716 may be of different types. In some embodiments, the data repository used by server 712 may be a database, such as a relational database, such as a database provided by Oracle Corporation® and other vendors. One or more of these databases may be adapted to respond to SQL-formatted commands to store, update, and retrieve data from the database.

[0085] In some embodiments, one or more of the data repositories 714, 716 may also be used by an application to store application data. The data repository used by the application may be of different types, such as, for example, a key value repository repository, an object repository repository, or a general-purpose storage repository supported by a file system.

[0086] In some embodiments, all or part of the coarse semantic parser 152 or fine semantic parser 154 used to train or use the dialogue system 100 as described herein may be provided as a service via a cloud environment. Figure 8 This is a simplified block diagram of a cloud-based system environment according to certain embodiments, in which training a semantic parser 130 as described herein can be provided at least partially as a cloud service. Figure 8 In the depicted embodiments, cloud infrastructure system 802 can provide one or more cloud services that can be requested by a user using one or more client computing devices 804, 806, and 808. Cloud infrastructure system 802 may include one or more computers and / or servers, which may include those computers and / or servers described above with respect to server 712. The computers in cloud infrastructure system 802 may be organized as general-purpose computers, dedicated server computers, server clusters, server groups, or any other suitable arrangement and / or combination.

[0087] Multiple networks 810 can facilitate data communication and exchange between client computing devices 804, 806, and 808 and cloud infrastructure system 802. Multiple networks 810 may include one or more networks. The networks may be of the same or different types. Multiple networks 810 may support one or more communication protocols (including wired and / or wireless protocols) to facilitate communication.

[0088] Figure 8 The described embodiments are merely one example of a cloud infrastructure system and are not intended to be limiting. It should be understood that in some other embodiments, the cloud infrastructure system 802 may have more... Figure 8 The depicted components may have more or fewer components, may combine two or more components, or may have different component configurations or arrangements. For example, although... Figure 8 Three client computing devices are depicted, but in alternative embodiments, any number of client computing devices can be supported.

[0089] The term cloud service is generally used to refer to services that become available to users on demand through a service provider's systems (e.g., cloud infrastructure systems 802) and via communication networks such as the Internet. Typically, in a public cloud environment, the servers and systems that make up the cloud service provider's systems are different from the customer's own on-premises servers and systems. The cloud service provider's systems are managed by the cloud service provider. Therefore, customers can utilize cloud services provided by the cloud service provider without having to purchase separate licenses, support, or hardware and software resources for the services. For example, the cloud service provider's systems can host applications, and users can subscribe to and use the applications on demand via the Internet without having to purchase the infrastructure resources to run the applications. Cloud services are designed to provide easy, scalable access to applications, resources, and services. Several providers offer cloud services. For example, Oracle Corporation® of Redwood Shores, California, offers several cloud services such as middleware services, database services, Java Cloud services, and others.

[0090] In some embodiments, cloud infrastructure system 802 may provide one or more cloud services using different models, such as Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS), and other models (including hybrid service models). Cloud infrastructure system 802 may include a set of applications, middleware, databases, and other resources that enable the provisioning of various cloud services.

[0091] The SaaS model enables applications or software to be delivered as a service to customers via communication networks such as the Internet, without requiring customers to purchase the underlying application's hardware or software. For example, the SaaS model can be used to provide customers with access to on-demand applications hosted by cloud infrastructure systems. Examples of SaaS services offered by Oracle Corporation® include, but are not limited to, a variety of services for human resources / capital management, customer relationship management (CRM), enterprise resource planning (ERP), supply chain management (SCM), enterprise performance management (EPM), analytics services, social applications, and others.

[0092] The IaaS model is typically used to provide customers with infrastructure resources (such as servers, storage, hardware, and networking resources) as cloud services to offer elastic computing and storage capabilities. Various IaaS services are provided by Oracle Corporation®.

[0093] The PaaS model is typically used to provide a platform and environment of resources as a service that enables customers to develop, run, and manage applications and services without requiring them to purchase, build, or maintain such resources. Examples of PaaS services provided by Oracle Corporation® include, but are not limited to, Oracle Java Cloud Service (JCS), Oracle Database Cloud Service (DBCS), Data Management Cloud Service, various application development solutions, and other services.

[0094] Cloud services are typically delivered in an on-demand, self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. For example, a customer can subscribe to one or more services provided by cloud infrastructure system 802 via a subscription order. Cloud infrastructure system 802 then performs processing to deliver the services requested in the customer's subscription order. For instance, a customer can subscribe to information services or other services provided by conversation system 100 on a session basis. Cloud infrastructure system 802 can be configured to provide one or more cloud services.

[0095] Cloud infrastructure system 802 can provide cloud services through different deployment models. In a public cloud model, cloud infrastructure system 802 may be owned by a third-party cloud service provider, and cloud services are provided to any general public customer, which may be an individual or a business. In some other embodiments, under a private cloud model, cloud infrastructure system 802 may operate within an organization (e.g., within a business organization), and services are provided to customers within the organization. For example, customers may be various departments within the organization, such as human resources or payroll departments, or even individuals within the organization. In some other embodiments, under a community cloud model, cloud infrastructure system 802 and the services provided may be shared by several organizations in the relevant community. Various other models, such as hybrids of the models mentioned above, may also be used.

[0096] Client computing devices 804, 806, and 808 can be of different types (e.g. Figure 7 The client computing devices 702, 704, 706, and 708 depicted may be capable of operating one or more client applications. Users can use the client computing devices to interact with the cloud infrastructure system 802, such as requesting services provided by the cloud infrastructure system 802. An attacker may use the client devices to send malicious requests.

[0097] In some embodiments, the processing performed by the cloud infrastructure system 802 may involve big data analytics. This analytics may involve using, analyzing, and manipulating large datasets to detect and visualize various trends, behaviors, relationships, etc., within the data. This analytics may be performed by one or more processors, potentially processing the data in parallel, performing simulations using the data, etc. For example, big data analytics may be performed by the cloud infrastructure system 802 to provide training or use for a coarse semantic parser 152 or a fine semantic parser 154 as described herein. The data used for this analytics may include structured data (e.g., data stored in a database or structured according to a structured model) and / or unstructured data (e.g., data blocks (binary large objects)).

[0098] like Figure 8 As depicted in the embodiments, the cloud infrastructure system 802 may include infrastructure resources 830 used to facilitate the provision of various cloud services offered by the cloud infrastructure system 802. Infrastructure resources 830 may include, for example, processing resources, storage or memory resources, networking resources, etc.

[0099] In some embodiments, to facilitate efficient provisioning of these resources to support various cloud services provided by the cloud infrastructure system 802 to different customers, infrastructure resources 830 may be bundled into resource groups or resource modules (also referred to as "pods"). Each resource module or pod may include a pre-integrated and optimized combination of one or more types of resources. In some embodiments, different pods may be pre-provisioned for different types of cloud services. For example, a first pod may be provisioned for a database service, and a second pod may be provisioned for a Java service (the second pod may include a different combination of resources than the pods in the first pod), etc. For some services, resources allocated for provisioning the service may be shared between services.

[0100] The cloud infrastructure system 802 itself can internally use services 832 shared by different components of the cloud infrastructure system 802 and that facilitate the provision of services by the cloud infrastructure system 802. These internal shared services may include, but are not limited to, security and identity services, integration services, enterprise repository services, enterprise manager services, virus scanning and whitelisting services, high availability, backup and recovery services, services for enabling cloud support, email services, notification services, file transfer services, etc.

[0101] Cloud infrastructure system 802 may include multiple subsystems. These subsystems may be implemented in software or hardware, or a combination thereof. Figure 8 The depicted subsystem may include a user interface subsystem 812 that enables users or customers of the cloud infrastructure system 802 to interact with the cloud infrastructure system 802. The user interface subsystem 812 may include various interfaces, such as a web interface 814, an online store interface 816 (where advertisements are displayed and customers can purchase cloud services provided by the cloud infrastructure system 802), and other interfaces 818. For example, a customer may use a client device to request (service request 834) one or more services provided by the cloud infrastructure system 802 using one or more of the interfaces 814, 816, and 818. For example, a customer may access an online store, browse cloud services provided by the cloud infrastructure system 802, and place a subscription order for one or more services provided by the cloud infrastructure system 802 that the customer wishes to subscribe to. A service request may include information identifying the customer and the one or more services the customer wishes to subscribe to.

[0102] In some embodiments (such as) Figure 8In the depicted embodiment, cloud infrastructure system 802 may include an order management subsystem (OMS) 820 configured to process new orders. As part of this process, OMS 820 may be configured to: create an account for a customer (if not already created); receive billing and / or billing information from the customer to be used to bill the customer for the requested services; verify customer information; place an order for the customer after verification; and plan various workflows to prepare the order for supply.

[0103] Once correctly verified, OMS 820 can invoke the Order Provisioning Subsystem (OPS) 824, which is configured as order provisioning resources (including processing resources, storage resources, and networking resources). Provisioning may include allocating resources for an order and configuring resources to facilitate the service requested by the customer's order. The manner in which resources are provisioned for an order and the type of resources provided may depend on the type of cloud service the customer has already subscribed to. For example, according to a workflow, OPS 824 may be configured to determine the specific cloud service being requested and identify the number of groups that may have been pre-configured for that specific cloud service. The number of groups allocated to an order may depend on the size / volume / tier / scope of the requested service. For example, the number of groups to be allocated may be determined based on the number of users the service is to support, the duration of the requested service, etc. The allocated groups can then be customized for a specific requesting customer to provide the requested service.

[0104] The cloud infrastructure system 802 can send a response or notification 844 to the requesting customer to indicate when the requested service is now ready for use. In some instances, information (e.g., a link) enabling the customer to begin using and taking advantage of the benefits of the requested service can be sent to the customer.

[0105] Cloud infrastructure system 802 can provide services to multiple customers. For each customer, cloud infrastructure system 802 is responsible for managing information related to one or more subscription orders received from the customer, maintaining customer data related to the orders, and providing the requested services to the customer. Cloud infrastructure system 802 can also collect usage statistics about customers' use of subscribed services. For example, it can collect statistics such as storage usage, data transfer volume, number of users, system uptime, and system downtime. This usage information can be used to issue bills to customers. Billing can be done, for example, on a monthly basis.

[0106] Cloud infrastructure system 802 can provide services to multiple customers in parallel. Cloud infrastructure system 802 can store information about these customers (potentially including proprietary information). In some embodiments, cloud infrastructure system 802 includes an Identity Management Subsystem (IMS) 828 configured to manage customer information and provide separation of the managed information such that information associated with one customer cannot be accessed by another customer. IMS 828 can be configured to provide various security-related services, such as identity services, information access management, authentication and authorization services, and services for managing customer identities, roles, and related capabilities.

[0107] Figure 9 This is a block diagram of an example computer system 900 that can be used to implement certain embodiments. For example, in some embodiments, computer system 900 can be used to implement any of the systems, subsystems, and components described herein. For example, multiple hosts can provide and implement training or use of a coarse semantic parser 152 or a fine semantic parser 154 of a dialogue system 100 as described herein. Computer systems such as computer system 900 can be used as hosts. Figure 9 As shown, the computer system 900 includes various subsystems, including a processing subsystem 904 that communicates with multiple other subsystems via a bus subsystem 902. These other subsystems may include a processing acceleration unit 906, an I / O subsystem 908, a storage subsystem 918, and a communication subsystem 924. The storage subsystem 918 may include non-transitory computer-readable storage media, including storage medium 922 and system memory 910.

[0108] Bus subsystem 902 provides a mechanism for enabling the various components and subsystems of computer system 900 to communicate with each other as intended. While bus subsystem 902 is schematically shown as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. Bus subsystem 902 may be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, a local bus using any of a variety of bus architectures, etc. For example, such architectures may include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus (which may be implemented as a mezzanine bus manufactured to the IEEE P1386.1 standard), etc.

[0109] Processing subsystem 904 controls the operation of computer system 900 and may include one or more processors, application-specific integrated circuits (ASICs), or field-programmable gate arrays (FPGAs). Processors may include single-core or multi-core processors. The processing resources of computer system 900 may be organized into one or more processing units 932, 934, etc. A processing unit may include one or more processors, one or more cores from the same or different processors, a combination of cores and processors, or other combinations of cores and processors. In some embodiments, processing subsystem 904 may include one or more dedicated coprocessors such as graphics processors or digital signal processors (DSPs). In some embodiments, some or all of the processing units of processing subsystem 904 may be implemented using custom circuitry such as ASICs or FPGAs.

[0110] In some embodiments, the processing units in the processing subsystem 904 can execute instructions stored in system memory 910 or on computer-readable storage medium 922. In various embodiments, the processing units can execute various program or code instructions and can maintain multiple concurrently executing programs or processes. At any given time, some or all of the program code to be executed can reside in system memory 910 and / or on computer-readable storage medium 922 (potentially including residing on one or more storage devices). With suitable programming, the processing subsystem 904 can provide the various functions described above. In an instance where the computer system 900 is executing one or more virtual machines, one or more processing units can be assigned to each virtual machine.

[0111] In some embodiments, a processing acceleration unit 906 may optionally be provided for performing custom processing or for offloading some of the processing performed by the processing subsystem 904, thereby accelerating the overall processing performed by the computer system 900.

[0112] I / O subsystem 908 may include devices and mechanisms for inputting information to and / or outputting information from or via computer system 900. Generally, the term input device is intended to include all possible types of devices and mechanisms for inputting information to computer system 900. User interface input devices may include, for example, keyboards, pointing devices such as mice or trackballs, touchpads or touchscreens incorporated into a display, scroll wheels, click wheels, dial pads, buttons, switches, keypads, audio input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices may also include motion sensing and / or gesture recognition devices, such as the Microsoft Kinect® motion sensor that enables users to control and interact with input devices, the Microsoft Xbox® 360 game controller, and devices that provide an interface for receiving input using gestures and spoken commands. User interface input devices may also include eye gesture recognition devices, such as the Google Glass® blink detector that detects eye movements from the user (e.g., “blinking” when taking a picture and / or making menu selections) and translates the eye gestures into input to an input device (such as Google Glass®). Additionally, the user interface input device may include a voice recognition sensing device that enables users to interact with a voice recognition system (e.g., the Siri® navigator) via voice commands.

[0113] Other examples of user interface input devices include, but are not limited to, 3D mice, joysticks or pointing sticks, game controllers and graphics tablets, and audio / visual devices such as speakers, digital cameras, digital camcorders, portable media players, webcams, image scanners, fingerprint scanners, barcode readers, 3D scanners, 3D printers, laser rangefinders, and eye-tracking devices. Additionally, user interface input devices may include, for example, medical imaging input devices such as computed tomography (CT), magnetic resonance imaging (MRI), positron emission tomography (PET), and medical ultrasound examination equipment. User interface input devices may also include, for example, audio input devices such as MIDI keyboards, digital musical instruments, etc.

[0114] Generally, the term "output device" is intended to encompass all possible types of devices and mechanisms for outputting information from a computer system 900 to a user or other computer. User interface output devices may include display subsystems, indicator lights, or non-visual displays such as audio output devices. Display subsystems may be cathode ray tubes (CRTs), flat panel devices (such as those using liquid crystal displays (LCDs) or plasma displays), projection devices, touchscreens, etc. For example, user interface output devices may include, but are not limited to, various display devices that visually convey text, graphics, and audio / video information, such as monitors, printers, speakers, headsets, car navigation systems, plotters, voice output devices, and modems.

[0115] Storage subsystem 918 provides a repository or data storage device for storing information and data used by computer system 900. Storage subsystem 918 provides a tangible, non-transitory, computer-readable storage medium for storing basic programming and data constructs that provide the functionality of some embodiments. Storage subsystem 918 may store software (e.g., programs, code modules, instructions) that provides the above-described functionality when executed by processing subsystem 904. The software may be executed by one or more processing units of processing subsystem 904. Storage subsystem 918 may also provide a repository for storing data used, in accordance with the teachings of this disclosure.

[0116] The storage subsystem 918 may include one or more non-transitory memory devices, which may include volatile memory devices and non-volatile memory devices. For example... Figure 9 As shown, the storage subsystem 918 includes system memory 910 and computer-readable storage medium 922. System memory 910 may include multiple memories, including volatile main random access memory (RAM) for storing instructions and data during program execution and non-volatile read-only memory (ROM) or flash memory where fixed instructions are stored. In some embodiments, a basic input / output system (BIOS) containing basic routines, such as those that help transfer information between elements within the computer system 900 during startup, may typically be stored in ROM. RAM typically contains data and / or program modules currently being operated and executed by processing subsystem 904. In some embodiments, system memory 910 may include various different types of memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM).

[0117] By using examples rather than restrictions, such as Figure 9As depicted, system memory 910 can load an executing application program 912 (which may include various applications such as web browsers, middleware applications, relational database management systems (RDBMS), etc.), program data 914, and operating system 916. By way of example, operating system 916 may include various versions of Microsoft Windows®, Apple Macintosh® and / or Linux operating systems, various commercially available UNIX® or UNIX-like operating systems (including but not limited to various GNU / Linux operating systems, Google Chrome® OS, etc.) and / or mobile operating systems such as iOS, Windows® Phone, Android® OS, BlackBerry® OS, Palm® OS, etc., and other operating systems.

[0118] In some embodiments, software instructions or code that implement training or use of the coarse semantic parser 152 and fine semantic parser 154 of the dialogue system 100 as described herein may be executed in system memory 910.

[0119] Computer-readable storage medium 922 may store programming and data structures that provide functionality for some embodiments. Computer-readable storage medium 922 may provide storage for computer-readable instructions, data structures, program modules, and other data for computer system 900. Software (programs, code modules, instructions) that provides the above-described functionality when executed by processing subsystem 904 may be stored in storage subsystem 918. By way of example, computer-readable storage medium 922 may include non-volatile memory such as hard disk drives, disk drives, optical disc drives (such as CD ROMs, DVDs, Blu-ray® discs, or other optical media). Computer-readable storage medium 922 may include, but is not limited to, Zip® drives, flash memory cards, Universal Serial Bus (USB) flash memory drives, Secure Digital (SD) cards, DVD discs, digital videotapes, etc. The computer-readable storage medium 922 may also include, for example, a flash memory-based solid-state drive (SSD), an enterprise-class flash memory drive, a non-volatile memory-based SSD such as a solid-state ROM, a volatile memory-based SSD such as a solid-state RAM, dynamic RAM, static RAM, a DRAM-based SSD, a magnetoresistive RAM (MRAM) SSD, and a hybrid SSD using a combination of DRAM and a flash memory-based SSD.

[0120] In some embodiments, the storage subsystem 918 may further include a computer-readable storage medium reader 920 that can be further connected to the computer-readable storage medium 922. The reader 920 may receive data from a storage device such as a disk, flash memory drive, etc., and is configured to read data from said storage device.

[0121] In some embodiments, computer system 900 may support virtualization technologies, including but not limited to virtualization of processing and memory resources. For example, computer system 900 may provide support for executing one or more virtual machines. In some embodiments, computer system 900 may execute programs such as hypervisors that facilitate the configuration and management of virtual machines. Each virtual machine may be allocated memory, computing (e.g., processor, core), I / O, and networking resources. Each virtual machine typically runs independently of other virtual machines. Virtual machines typically run their own operating system, which may be the same as or different from the operating systems executed by other virtual machines executed by computer system 900. Therefore, multiple operating systems may potentially be run simultaneously by computer system 900.

[0122] The communication subsystem 924 provides an interface to other computer systems and networks. The communication subsystem 924 serves as an interface for receiving data from other systems and sending data from computer system 900 to other systems. For example, the communication subsystem 924 enables computer system 900 to establish communication channels via the Internet to one or more client devices for receiving and sending information to client devices.

[0123] The communication subsystem 924 may support both wired and / or wireless communication protocols. For example, in some embodiments, the communication subsystem 924 may include radio frequency (RF) transceiver components, global positioning system (GPS) receiver components, and / or other components for accessing wireless voice and / or data networks, such as using cellular telephone technologies, advanced data network technologies like 3G, 4G, or EDGE (Global Evolution Enhanced Data Rate), WiFi (IEEE 802.XX Home Standard), or other mobile communication technologies, or any combination thereof. In some embodiments, in addition to or as an alternative to a wireless interface, the communication subsystem 924 may provide wired network connectivity (e.g., Ethernet).

[0124] The communication subsystem 924 can receive and transmit data in various forms. For example, in some embodiments, the communication subsystem 924 can also receive input communications in the form of structured and / or unstructured data feeds 926, event streams 928, event updates 930, etc., among others. For example, the communication subsystem 924 can be configured to receive (or transmit) data feeds 926 in real time from users of social media networks and / or other communication services, such as Twitter® feeds, Facebook® updates, web feeds (such as Rich Site Summary (RSS) feeds), and / or real-time updates from one or more third-party information sources.

[0125] In some embodiments, the communication subsystem 924 may be configured to receive data in the form of a continuous data stream, which may include an event stream 928 and / or event updates 930 of real-time events (which may be inherently continuous or unbounded and may not have an explicit end). Examples of applications that generate continuous data may include, for example, sensor data applications, financial reporting machines, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, vehicle traffic monitoring, etc.

[0126] The communication subsystem 924 can also be configured to transmit data from computer system 900 to other computer systems or networks. Data can be transmitted in various forms, such as structured and / or unstructured data feeds 926, event streams 928, event updates 930, etc., to one or more databases that can communicate with one or more streaming data source computers coupled to computer system 900.

[0127] The computer system 900 can be of a variety of types, including handheld portable devices (e.g., iPhone® cellular phones, iPad® tablet computers, PDAs), wearable devices (e.g., Google Glass® head-mounted displays), personal computers, workstations, mainframes, self-service kiosks, server racks, or any other data processing systems. Due to the constantly evolving nature of computers and networks, [the following text appears to be incomplete and requires further context: "for..."] Figure 9 The description of the computer system 900 is intended only as a concrete example. It has a higher... Figure 9 Many other configurations with more or fewer components are possible for the system depicted. Based on the disclosure and teachings provided herein, those skilled in the art will understand other ways and / or methods for implementing the various embodiments.

[0128] While specific embodiments have been described, various modifications, alterations, alternative constructions, and equivalents are possible. The embodiments are not limited to operation within a particular data processing environment, but are free to operate within multiple data processing environments. Furthermore, although certain embodiments have been described using specific series of transactions and steps, it will be apparent to those skilled in the art that this is not intended to be restrictive. While some flowcharts describe operations as sequential processes, many operations may be performed in parallel or simultaneously. Additionally, the order of operations can be rearranged. Processes may have additional steps not included in the figures. Various features and aspects of the embodiments described above can be used individually or in combination.

[0129] Furthermore, while certain embodiments have been described using specific combinations of hardware and software, it should be recognized that other combinations of hardware and software are also possible. Some embodiments may be implemented solely in hardware, solely in software, or using a combination thereof. The various processes described herein may be implemented on the same or different processors in any combination.

[0130] When a device, system, component, or module is described as being configured to perform certain operations or functions, this configuration can be accomplished, for example, by designing electronic circuitry to perform operations, by programming programmable electronic circuitry (such as a microprocessor) to perform operations (such as by executing computer instructions or code), or by a processor or core programmed to execute code or instructions stored on a non-transitory memory medium, or any combination thereof. Processes can communicate using a variety of techniques, including but not limited to conventional techniques for inter-process communication, and different pairs of processes may use different techniques, or the same pair of processes may use different techniques at different times.

[0131] Specific details are set forth in this disclosure to provide a thorough understanding of the embodiments. However, embodiments may be practiced without these specific details. For example, well-known circuits, processes, algorithms, structures, and techniques have been shown without unnecessary detail to avoid obscuring the embodiments. This description provides only exemplary embodiments and is not intended to limit the scope, applicability, or configuration of other embodiments. Rather, the foregoing description of the embodiments will provide those skilled in the art with an enabling description for implementing various embodiments. Various changes can be made to the function and arrangement of the elements.

[0132] Therefore, the specification and drawings should be viewed in an illustrative rather than restrictive sense. However, it will be apparent that additions, omissions, deletions, and other modifications and changes may be made without departing from the broader spirit and scope set forth in the claims. Thus, while specific embodiments have been described, these examples are not intended to be limiting. Various modifications and equivalents are within the scope of the following claims.

Claims

1. A training method, comprising: Access training data including utterances, intermediate logical forms, and logical forms, wherein the logical forms of the training data are generated based on a grammar defined for the logical forms, and the logical forms are converted into corresponding intermediate logical forms from which parameter values ​​are automatically removed from slots in the logical forms; A coarse semantic parser is trained using the utterance as training input and the intermediate logical form as training output, wherein the coarse semantic parser learns to map the utterance to the intermediate logical form. as well as A fine-grained semantic parser is trained using the intermediate logical form as training input and the logical form as training output, wherein the fine-grained semantic parser learns to map the intermediate logical form to the logical form and determines the parameter values ​​to refine the logical form based on the intermediate logical form. The coarse semantic parser and the fine semantic parser are configured for integration with a dialogue system.

2. The method of claim 1, wherein the coarse semantic parser is a sequence-to-sequence neural network, and wherein the fine semantic parser is an additional sequence-to-sequence neural network.

3. The method of claim 1, wherein training the fine semantic parser further comprises using the utterance as training input.

4. The method of claim 3, further comprising: The coarse semantic parser in the dialogue system maps utterances to intermediate logical forms. as well as The utterances and intermediate logical forms are mapped to logical forms by the fine semantic parser in the dialogue system.

5. The method of claim 1, further comprising: The coarse semantic parser in the dialogue system maps utterances to intermediate logical forms. as well as The intermediate logical form is mapped to the logical form by the fine semantic parser in the dialogue system.

6. The method according to claim 5, wherein: The discourse is a text-based natural language expression; The intermediate logical form indicates one or more intentions in the discourse; as well as The logical form is a syntactic expression of the discourse according to an established grammar, and the logical form includes one or more parameters of the one or more intentions.

7. The method of claim 1, further comprising: The coarse semantic parser is used to determine intermediate logical forms for utterances in a dialogue system, wherein the utterances are text-based natural language expressions, and wherein the intermediate logical forms indicate one or more intentions in the utterances. as well as The fine-grained semantic parser is used to determine a logical form for the utterance and the intermediate logical form, wherein the logical form is a syntactic expression of the utterance according to an established grammar, and wherein the logical form includes one or more parameters of the one or more intentions; and Use the aforementioned logical form to conduct dialogue through the dialogue system.

8. The method of claim 1, further comprising generating the training data, wherein generating the training data comprises: For each pair of logical forms and corresponding intermediate logical forms, the corresponding utterances in the utterances are received via crowdsourcing.

9. A training system, comprising: Memory components; and A processing unit, coupled to the memory component, is configured to perform operations including the following: Access training data including utterances, intermediate logical forms, and logical forms, wherein the logical forms of the training data are generated based on a grammar defined for the logical forms, and the logical forms are converted into corresponding intermediate logical forms from which parameter values ​​are automatically removed from slots in the logical forms; A coarse semantic parser is trained using the utterance as training input and the intermediate logical form as training output, wherein the coarse semantic parser learns to map the utterance to the intermediate logical form. as well as A fine semantic parser is trained using the intermediate logic form as training input and the logic form as training output, wherein the fine semantic parser learns to map the intermediate logic form to the logic form and determines the parameter values ​​to refine the logic form based on the intermediate logic form. The coarse semantic parser and the fine semantic parser are configured for integration with a dialogue system.

10. The system of claim 9, wherein the coarse semantic parser is a sequence-to-sequence neural network, and wherein the fine semantic parser is an additional sequence-to-sequence neural network.

11. The system of claim 9, wherein training the fine semantic parser further includes using the utterance as training input.

12. The system of claim 11, wherein the operation further comprises: The coarse semantic parser in the dialogue system maps utterances to intermediate logical forms. as well as The utterances and intermediate logical forms are mapped to logical forms by the fine semantic parser in the dialogue system.

13. The system of claim 9, wherein the operation further comprises: The coarse semantic parser in the dialogue system maps utterances to intermediate logical forms. as well as The intermediate logical form is mapped to the logical form by the fine semantic parser in the dialogue system.

14. The system of claim 13, wherein: The discourse is a text-based natural language expression; The intermediate logical form indicates one or more intentions in the discourse; as well as The logical form is a syntactic expression of the discourse according to an established grammar, and the logical form includes one or more parameters of the one or more intentions.

15. The system of claim 9, wherein the operation further comprises: The coarse semantic parser is used to determine intermediate logical forms for utterances in a dialogue system, wherein the utterances are text-based natural language expressions, and wherein the intermediate logical forms indicate one or more intentions in the utterances. as well as The fine-grained semantic parser is used to determine a logical form for the utterance and the intermediate logical form, wherein the logical form is a syntactic expression of the utterance according to an established grammar, and wherein the logical form includes one or more parameters of the one or more intentions; and Use the aforementioned logical form to conduct dialogue through the dialogue system.

16. The system of claim 9, wherein generating the training data further includes: For each pair of logical forms and corresponding intermediate logical forms, the corresponding utterances in the utterances are received via crowdsourcing.

17. A training method, comprising: Access training tuples of training data, the training tuples including utterances, intermediate logical forms corresponding to the utterances, and logical forms corresponding to the utterances, wherein the logical forms of the training data are generated based on the grammar defined for the logical forms, and the logical forms are converted into intermediate logical forms in which parameter values ​​are automatically removed from the slots in the logical forms. The coarse semantic parser of the dialogue system is used to determine the intermediate logical form of the prediction based on the utterance of the training tuple; The coarse semantic parser is trained by comparing the predicted intermediate logical form with the logical form of the training tuple, and the coarse semantic parser learns to map utterances to intermediate logical forms. Based on the utterance and intermediate logical form of the training tuple, the fine-grained semantic parser of the dialogue system is used to determine the predicted logical form. as well as The fine semantic parser is trained by comparing the predicted logical form with the logical form of the training tuple, wherein the fine semantic parser learns to map the intermediate logical form to the logical form and determines the parameter values ​​to refine the logical form based on the intermediate logical form.

18. The method of claim 17, further comprising generating the training data, wherein generating the training data includes: For each pair of logical forms and corresponding intermediate logical forms, the corresponding utterances in the utterances are received via crowdsourcing.

19. The method of claim 17, further comprising: The coarse semantic parser is used to determine intermediate logical forms for utterances in a dialogue system, wherein the utterances are text-based natural language expressions, and wherein the intermediate logical forms indicate one or more intentions in the utterances. as well as The fine-grained semantic parser is used to determine a logical form for the utterance and the intermediate logical form, wherein the logical form is a syntactic expression of the utterance according to an established grammar, and wherein the logical form includes one or more parameters of the one or more intentions; and Use the aforementioned logical form to conduct dialogue through the dialogue system.

20. The method of claim 17, further comprising operating the coarse semantic parser and the fine semantic parser in series in the dialogue system by: Receive input speech during the operation of the dialogue system; This enables the coarse semantic parser to output an intermediate logical form based on the input utterance; as well as The input utterance and the intermediate logical form output by the coarse semantic parser are provided as input to the fine semantic parser.

Images