EP3535664A1 - Collecte de données destinée à un nouveau système de dialogue conversationnel - Google Patents

Collecte de données destinée à un nouveau système de dialogue conversationnel

Info

Publication number
EP3535664A1
EP3535664A1 EP17867628.4A EP17867628A EP3535664A1 EP 3535664 A1 EP3535664 A1 EP 3535664A1 EP 17867628 A EP17867628 A EP 17867628A EP 3535664 A1 EP3535664 A1 EP 3535664A1
Authority
EP
European Patent Office
Prior art keywords
canonical
user
list
utterances
utterance
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP17867628.4A
Other languages
German (de)
English (en)
Other versions
EP3535664A4 (fr
Inventor
Percy Shuo LIANG
Daniel Klein
Laurence Gillick
Jordan Cohen
Linda Kathleen ARSENAULT
Joshua CLAUSMAN
Adam PAULS
David Hall
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Technology Licensing LLC
Original Assignee
Semantic Machines Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Semantic Machines Inc filed Critical Semantic Machines Inc
Priority claimed from PCT/US2017/060134 external-priority patent/WO2018085760A1/fr
Publication of EP3535664A1 publication Critical patent/EP3535664A1/fr
Publication of EP3535664A4 publication Critical patent/EP3535664A4/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/20—Natural language analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0481—Interaction techniques based on graphical user interfaces [GUI] based on specific properties of the displayed interaction object or a metaphor-based environment, e.g. interaction with desktop elements like windows or icons, or assisted by a cursor's changing behaviour or appearance
    • G06F3/0482—Interaction with lists of selectable items, e.g. menus
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/166—Editing, e.g. inserting or deleting
    • G06F40/169—Annotation, e.g. comment data or footnotes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/20—Natural language analysis
    • G06F40/205—Parsing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/30—Semantic analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F7/00—Methods or arrangements for processing data by operating upon the order or content of the data handled
    • G06F7/06—Arrangements for sorting, selecting, merging, or comparing data on individual record carriers
    • G06F7/08—Sorting, i.e. grouping record carriers in numerical or other ordered sequence according to the classification of at least some of the information they carry
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00—Machine learning
    • G—PHYSICS
    • G10—MUSICAL INSTRUMENTS; ACOUSTICS
    • G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
    • G10L15/00—Speech recognition
    • G10L15/06—Creation of reference templates; Training of speech recognition systems, e.g. adaptation to the characteristics of the speaker's voice
    • G10L15/063—Training
    • G—PHYSICS
    • G10—MUSICAL INSTRUMENTS; ACOUSTICS
    • G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
    • G10L15/00—Speech recognition
    • G10L15/22—Procedures used during a speech recognition process, e.g. man-machine dialogue
    • G—PHYSICS
    • G10—MUSICAL INSTRUMENTS; ACOUSTICS
    • G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
    • G10L15/00—Speech recognition
    • G10L15/06—Creation of reference templates; Training of speech recognition systems, e.g. adaptation to the characteristics of the speaker's voice
    • G10L15/063—Training
    • G10L2015/0638—Interactive procedures

Definitions

  • Fluent conversational systems are difficult to design.
  • such a system which is capable of all the tasks in a particular topic is very difficult to use because it cannot analyze the variety of sentences spoken by the user, nor does it capture the possibilities for actions and language produced by the system.
  • the problem is a chicken-and-egg problem - a system could use a Wizard of Oz (WOZ) system to create a model of the conversational system, and then persuade large numbers of human users to interact with the system.
  • WOZ Wizard of Oz
  • This is expensive, as the "conversational system” must be represented by a human operator, and it will be likewise constrained to operate in the space of human operator utterances (each operator has idiosyncratic utterances which constrain the WOZ data unnaturally).
  • FIGURE 1 is a block diagram of a system that collects and uses annotated data.
  • FIGURE 2 is a block diagram of a data generation system.
  • FIGURE 3 is a method for generating annotated data.
  • FIGURE 4 is a method for annotating data through a user interface.
  • FIGURE 5 illustrates another user interface provided by the present system.
  • FIGURE 6 illustrates another user interface provided by the present system.
  • FIGURE 7 illustrates another user interface provided by the present system.
  • FIGURE 8 illustrates another user interface provided by the present system.
  • FIGURE 9 illustrates another user interface provided by the present system.
  • FIGURE 10 illustrates another user interface provided by the present system.
  • FIGURE 11 illustrates another user interface provided by the present system.
  • FIGURE 12 illustrates another user interface provided by the present system.
  • FIGURE 13 illustrates another user interface provided by the present system.
  • FIGURE 14 illustrates another user interface provided by the present system.
  • FIGURE 15 illustrates another user interface provided by the present system.
  • FIGURE 16 illustrates another user interface provided by the present system.
  • FIGURE 17 illustrates another user interface provided by the present system.
  • FIGURE 18 illustrates another user interface provided by the present system.
  • FIGURE 19 illustrates another user interface provided by the present system.
  • FIGURE 20 illustrates another user interface provided by the present system.
  • FIGURE 21 illustrates another user interface provided by the present system.
  • FIGURE 22 illustrates another user interface provided by the present system.
  • FIGURE 23 illustrates another user interface provided by the present system.
  • FIGURE 24 is a block diagram of an exemplary device for implementing the present technology.
  • a data collection system is based on a general set of dialogue acts which are derived from a database schema. Crowd workers or other users perform two types of tasks: (i) identification of sensical dialogue paths and (ii) performing context-dependent paraphrasing of these dialogue paths into real dialogues.
  • the end output of the system is a set of training examples of real dialogues which have been annotated with their logical forms. This data can be used to train all three components of the dialogue system: (i) the semantic parser for understanding context-dependent utterances, (ii) the dialogue policy for generating new dialogue acts given the current state, and (iii) the generation system for both deciding what to say and how to render it in natural language.
  • the data generation system of the present technology may generate a plurality of canonical utterances from logical forms and associate annotation with the plurality of canonical utterances.
  • the annotated canonical utterance data inherently includes information about dialog flow and utterance transition, which can be used to train dialog systems.
  • a method for generating annotated dialogue system training data.
  • a data generation application receives a first input from a user as a step in a multi-step dialog.
  • the data generation application generates a first list of a plurality of canonical utterances from a plurality of logical forms, wherein the plurality of logical forms generated in response to the input received from the user.
  • a selection is received, from a user, of one of the plurality of canonical utterances from the first list.
  • a second list of a plurality of canonical utterances is generated from a plurality of logical forms, wherein the plurality of logical forms generated in response to the user selection from the first list.
  • a selection is received, from a user, of one of the plurality of canonical utterances from the second list.
  • a natural language paraphrase can be received from the user, wherein the natural language paraphrase is associated with the first selected canonical utterance and the second selected canonical utterance.
  • the natural language paraphrase, first selected canonical utterance, and the second selected canonical utterance are then stored.
  • a system can generate annotated dialogue system training data.
  • the system can include a processor, memory, and one or more modules stored in memory and executable by the processor.
  • the modules can receive, by a data generation application executing on a machine, a first input from a user as a step in a multi-step dialog, generate, by the data generation application, a first list of a plurality of canonical utterances from a plurality of logical forms, the plurality of logical forms generated in response to the input received from the user, receive from the user a selection of one of the plurality of canonical utterances from the first list, generate a second list of a plurality of canonical utterances from a plurality of logical forms, the plurality of logical forms generated in response to the user selection from the first list, receive from the user a selection of one of the plurality of canonical utterances from the second list, receive a natural language paraphrase from the user, the natural language paraphrase associated with the first selected canonical utterance and the second selected canonical utterance, and store the natural language paraphrase, first selected canonical utterance, and the second selected canonical
  • the present technology is a data collection system based on a general set of dialogue acts which are derived from a database schema. Crowd workers perform two types of tasks: (i) identification of sensical dialogue paths and (ii) performing context-dependent paraphrasing of these dialogue paths into real dialogues.
  • the end output of the system is a set of training examples of real dialogues which have been annotated with their logical forms. This data can be used to train all three components of the dialogue system: (i) the semantic parser for understanding context-dependent utterances, (ii) the dialogue policy for generating new dialogue acts given the current state, and (iii) the generation system for both deciding what to say and how to render it in natural language.
  • the data generation system of the present technology may generate a plurality of canonical utterances from logical forms and associate annotation with the plurality of canonical utterances.
  • the annotated canonical utterance data inherently includes information about dialog flow and utterance transition, which can be used to train dialog systems.
  • the modified data collection system of the present technology is based on a general set of dialogue acts which is derived from a database schema. Crowd workers can perform two types of tasks in the present system: (i) identification of sensical dialogue paths and (ii) performing context-dependent paraphrasing of these dialogue paths into real dialogues.
  • the end output of the system is a set of training examples of real dialogues which have been annotated with their logical forms. This data can be used to train all three components of the dialogue system: (i) the semantic parser for understanding context-dependent utterances, (ii) the dialogue policy for generating new dialogue acts given the current state, and (iii) the generation system for both deciding what to say and how to render it in natural language.
  • the framework defines the complete tree of possible dialogues, where each path is a sequence of actions (dialogue act), and each node is a state of the dialogue. Actions are rendered as canonical utterances, which is a pseudocode way of showing the underlying logical form.
  • each path is a sequence of actions (dialogue act)
  • each node is a state of the dialogue.
  • Actions are rendered as canonical utterances, which is a pseudocode way of showing the underlying logical form.
  • canonical utterances which is a pseudocode way of showing the underlying logical form.
  • TextMessage request recipient_phone_number to be 617-123-4567 o user: TextMessage: request contents to be "buy groceries"
  • Crowdworkers rate each action coming out of a state as either good or bad.
  • the database schema created in step 1 above is a rule-based description of elements and actions which can be taken. Unlike a rule-based bot or a full dialogue system, the rules govern the creation and concatenation of logical elements of a conversation, which are not necessarily the actual words which a user/system would utter in a real conversation. While the rules are expected to capture much of the logical description of the conversational system, the natural language paraphrases provided by the crowd workers, when fed to a machine learning system, will learn the relevant nuances of natural language interchanges in the new domain.
  • FIGURE 1 is a block diagram of a system that collects and uses annotated data.
  • System 100 of FIGURE 1 includes client 110, mobile device 120, computing device 130, network 140, network server 150, application server 160, and data store 170.
  • Client 110, mobile device 120, and computing device 130 communicate with network server 150 over network 140.
  • Network 140 may include a private network, public network, the Internet, and intranet, a WAN, a LAN, a cellular network, or some other network suitable for the transmission of data between computing devices of FIGURE 1.
  • Client 110 includes application 112.
  • Application 112 may provide automatic speech recognition, speech synthesis, paraphrase decoding, transducing and/or translation, paraphrase translation, partitioning, an automated assistant, and other functionality discussed herein.
  • Application 112 may be implemented as one or more applications, objects, modules or other software.
  • Application 112 may communicate with application server 160 and data store 170, through the server architecture of FIGURE 1 or directly (not illustrated in FIGURE 1) to access the large amounts of data.
  • Mobile device 120 may include a mobile application 122.
  • the mobile application may provide automatic speech recognition, speech synthesis paraphrase decoding, transducing and/or translation, paraphrase translation, partitioning, an automated assistant, and other functionality discussed herein.
  • Mobile application 122 may be implemented as one or more applications, objects, modules or other software.
  • Computing device 130 may include a network browser 132.
  • the network browser may receive one or more content pages, script code and other code that when loaded into the network browser provides automatic speech recognition, speech synthesis paraphrase decoding, transducing and/or translation, paraphrase translation, partitioning, an automated assistant, and other functionality discussed herein.
  • Network server 150 may receive requests and data from application 112, mobile application 122, and network browser 132 via network 140. The request may be initiated by the particular applications or browser applications. Network server 150 may process the request and data, transmit a response, or transmit the request and data or other content to application server 160.
  • Application server 160 includes application 162.
  • the application server may receive data, including data requests received from applications 112 and 122 and browser 132, process the data, and transmit a response to network server 150. In some implementations, the responses are forwarded by network server 152 to the computer or application that originally sent the request.
  • Application's server 160 may also communicate with data store 170. For example, data can be accessed from data store 170 to be used by an application to provide automatic speech recognition, speech synthesis, paraphrase decoding, transducing and/or translation, paraphrase translation, partitioning, an automated assistant, and other functionality discussed herein.
  • Application server 160 includes application 162, which may operate similar to application 112 except implemented all or in part on application server 160.
  • Data generation system 190 may generate data that can be used to train semantic language models.
  • the data generated by system 190 may be stored in annotated training data 180, which can be accessed by application 162.
  • the data may include logical form data and canonical data for a path of utterances, as well as annotations for a plurality of paths with the dialogue.
  • Data generation system 190 is discussed in more detail with respect to FIGURE 2 and elsewhere herein.
  • FIGURE 2 is a block diagram of a data generation system.
  • the data generation system 200 of FIGURE 2 provides more detail for generation system 190 of FIGURE 1 and includes canonical utterance generator 210, utterance ranking module 220, GUI manager 230, policy 240, cards datastore 250 and actions datastore 260.
  • Canonical utterance generator 210 generates canonical utterances from logical forms retrieved from a datastore.
  • the Canonical utterances can be ranked by utterance ranking module 220 and displayed by an interface which is populated, rendered and managed by GUI manager 230.
  • Policy 240 maintains policy information used and applied by the data generation system 200.
  • Cards data store 250 stores card data and handles queries for card information.
  • Actions data store 250 stores action data and handles queries for action information. Cards, actions and policies are discussed in more detail below.
  • the present system has a simple, declarative representation of the dialogue state.
  • CardType analogous to a class, or the schema of a database table
  • H a list of fields, where each field has a name, an arity (either 1 or 1+), and a CardType.
  • each day can only have one high temperature
  • H TextMessage ⁇ contents:Message, phone_number: Phone Number ⁇
  • H BaseballGame ⁇ Activity ⁇ teaml:BasebaiiTeam, team2:BaseballTeam / location:Stadium ⁇
  • a Schema is a collection of CardTypes, and is a full specification of the universe of things that can exist.
  • a Card is not an instance of CardType.
  • H Mode can either be create (a new database record under this CardType) or query (for an existing database record)
  • An expression can refer to a Path, which refers to any subcard in the system.
  • H A sort field (increasing or decreasing): which field to sort by H A cursor (integer) into the list of result.
  • H Contains a list of records, where each record has a subset of its fields, which has been reported by the agent.
  • H Contains values of fields across multiple records (e.g., min and max, count).
  • each sub-card can be accessed by a path
  • H agent set origin to BOS # for setting defaults
  • H agent set origin to BOS?
  • H agent currently, departure date is departure time is ...
  • O db_cursor(path, direction) write card, by user or agent
  • H False or True (applicable only to actions that change the state) H For user, submits true when write to card (represents shared mental state) H For agent, submit is true when write to DB (represents world state) ple
  • O dialogue history list of actions (not used by actions)
  • the present system first defines a generator, which takes a state and an action and produces a canonical utterance for this action.
  • This is a simple rule- based system that maps the underlying logical form to an English-like pseudocode.
  • the present system attempted to use more pure natural language (e.g., "For the create TextMessage task, what would you like the contents to be?”), but this turned out to a lot harder for crowd workers to read than to have a shorthand that's more concise (e.g., "TextMessage: request contents?”)
  • a policy is used to map a state to a ranking over actions. Given a state, the present system first generates the possible set of actions (there can be a few hundred depending on the complexity of the state). Then the present system defines a parametrized score for each (state, action) pair.
  • the features include indicators on various abstractions of the (state, action). For example, one feature captures the identity of the last two actions not including the arguments. Another feature would capture the equivalence structure of the arguments (e.g., to capture that if the agent requests a field, then the user will likely reply with that field).
  • the weights of the model are learned from the user ratings.
  • the model is instantiated in a user interface where a crowd worker is presented with logical forms which make up the sentences in a dialogue in sequential order. His/her task is to paraphrase the utterances (could be text strings) of the system in natural language, and where the system offers more than one possible response to a "user" utterance, to choose one of the possibilities as the extension of the conversation, and again to provide at least one paraphrase of the logical form.
  • the user utterance cannot be understood by the system. In that case, either the system might lack a fundamental analysis element, or the system capabilities do not extend to this type of utterance. In any case, these will be analyzed for possible extension of either the model system itself or of the domain which the system covers.
  • the dialogue creator paraphrases the system states and utterances into natural languages
  • the user interface may operate to create dialogues where each system action, utterance, or combination of these is paired with a natural language paraphrase. These paraphrases and system actions and/or states automatically create training data for the actual system, since the system states are now paired with natural language utterances which together create a natural language dialogue which the system could have had.
  • the user interface comes with general instructions for the dialogue creator, as follows:
  • the user can, in some instances, have two primary goals:
  • the MGU is the machine generated utterance that the system generated and the crowd worker chose.
  • the Action is the internal action the system took which corresponds with that MGU.
  • the Paraphrase is the natural language description, provided by the crowd worker, of all MGUs since the last Paraphrase. Rows where the User is the actor and where the Agent is the actor are labeled as such in the first column.
  • TextMessage task 1 e_number,expr:[get,[[task,0],[r sister.
  • TextMessage task 1 $ ⁇ contents:Text ⁇ ,path:[[task,0] dinner tonight would like the contents ] ⁇ )
  • TextMessage task 1 get, [[task,0], [contents, 0]]], pat the same thing.
  • FIGURE 3 is a method for generating annotated data.
  • a database schema is accessed at step 305.
  • a first selection in a dialogue path is received from a user (crowd worker) at step 310.
  • the first selection will correspond to a root node in the overall state of the dialogue.
  • a data store may be queried for actions at step 315.
  • the query for actions may be generated based on the received selection at step 310.
  • the datastore receives the query, prepares a response, and transmits the response back to the requesting module.
  • the actions in the response can be performed, resulting in a number of logical forms being created.
  • the logical forms can be ranked at step 320. In some instances, the logical forms may be ranked based on a model score, which may incorporate weightings based on previous user rankings, confidence levels, and other data.
  • Canonical utterances are generated from the logical forms and output at step 325. In some instances, only a subset of the logical forms is used to generate canonical utterances, such as for example the top ranked five or ten logical forms, those meeting a minimum score, or some other subset of the retrieved logical forms. In any case, a canonical utterance can be considered a pseudo-English translation of a computer form, which can be considered closer to a computer code format. The canonical utterances are output in an interface, which is discussed in more detail with respect to figures 4 through 23.
  • a selection is then received for a particular canonical utterance at step 330.
  • One or more cards are generated, modified, updated, deleted, or otherwise processed at step 335.
  • the updated state made up of one or more cards, is used to generate a query for a set of actions.
  • a data store may be queried for the actions based on the current state, and the retrieved actions can be executed to generate logical forms at step 340.
  • Canonical utterances may then be generated for each or a subset of the logical forms, and the canonical utterances may be output at step 345.
  • a selection of a generated and output canonical utterance is received at step 350.
  • One or more cards are generated or processed in response to the selection, a query is generated based on the current state (based at least in part on the updated cards), actions are performed and logical forms are generated at step 355.
  • a natural language utterance is received at step 360.
  • the natural language utterance may correlate to a plurality of canonical utterances in the current dialogue path.
  • the natural language utterance may be context -dependent and may be associated with multiple steps in the dialogue within the overall dialogue path.
  • the selected path of the dialogue, actions, the natural form, and the natural language utterance, as well as logical form from which the canonical utterances are generated, are stored at step 365.
  • FIGURE 4 is a method for annotating data through a user interface.
  • an interface is instantiated with state data, a research mechanism, and an initial dialogue choice.
  • State data may include the path taken so far, or a root node if no path has developed yet.
  • the search mechanism may include a search box, selectable buttons, or other interface elements that enable a user to perform a search.
  • a selection may be received for an initial dialogue at step 410.
  • the initial dialogue choices in an embodiment, are illustrated in the interface of FIGURE 5.
  • state data is updated at step 415.
  • state data including a root node is updated to include additional nodes within the dialogue path.
  • the previous dialogue selection is added to a dialogue history portion of the interface at step 420. Referring to FIGURE 6, the selected dialogue portion of "I would like to create a restaurant reservation as task" is added to the dialogue history.
  • a ranked list of selectable canonical utterances is provided to the user through the interface at step 425.
  • six selectable canonical utterances are provided to the user.
  • a selection is received for a canonical utterance at step 440.
  • the state data is updated at step 445 and the previous selection of the canonical utterance is added to the dialogue history at step 440.
  • a new ranked list of selectable canonical utterances is then provided to user at step 445.
  • a selection is received for one of the new canonical utterances at step 450.
  • Data associated with the recent selection may be received at step 455.
  • data in the form of a date - 'October 25" - for a restaurant reservation is received within a popup box or window provided by the interface.
  • the type of data received may depend on the particular cards, action, and canonical utterance within the context of the present dialogue.
  • a natural language utterance is received for a series of canonical utterances at step 460.
  • the natural language utterance received from a user may be associated with a plurality of canonical utterances.
  • the natural language utterance serves as an annotation for the series of canonical utterances generated by the system and may be used to train other language generation models.
  • FIGURE 5 illustrates an initial interface. This interface displays a list of possible dialogues topics for a user (e.g., dialog creator or creator) to explore. Positioning a cursor, for example with a touch screen input or mouse input device, over one topic or otherwise providing input to select a particular topic results in a yellow highlight 510 for that topic.
  • a user e.g., dialog creator or creator
  • the yellow line indicates a choice by the creator, made by moving the mouse to that line. If the creator then provides another input to select the highlighted topic line, an interface such as that of FIGURE 6 is displayed by a device implementing the present technology.
  • FIGURE 6 illustrates another interface provided by the present system.
  • FIGURE 6 illustrates the result of receiving input of an element of the display of FIGURE 5.
  • the logic implemented in code by the present technology indicate the selection of a Restaurant Reservation task.
  • a current state interface portion 610 indicates the current state of the dialog - including the root node and subsequent dialog paths.
  • the dialog history is displayed within the interface at interface portion 620. Note that the restaurant reservation task is now part of the dialogue history, and has a box into which one may put a paraphrase. The Creator is not forced to select a paraphrase, however, and may instead choose to specify yet more of the system state visited by the user.
  • a series of seven canonical utterances are displayed below the dialog history.
  • a first utterance in the seven canonical utterances is currently highlighted as being selected by the user.
  • the creator has selected the specification of a date for the restaurant reservation as part of the dialog.
  • FIGURE 7 illustrates another display provided by the present system.
  • FIGURE 7 illustrates a display provided after receiving input in the display of FIGURE 6.
  • the creator can provide input to specify the date for which the user is requesting the reservation. In this instance, the user has provided input of 'October 25" in the pop-up box 710.
  • a user provides input, e.g. a button click, that is received by the present system, the user is provided with a screen such as that displayed in FIGURE 8.
  • FIGURE 8 illustrates another display provided by the present system.
  • FIGURE 8 illustrates a display after the creator, acting for the user, provides an input.
  • the creator may provide an input by selecting a date for the reservation. Note that the date appears both in the dialogue history, and in the "dialogue state" found in the upper left of the display.
  • the creator may now extend the actions of the user by picking a line from the possible system actions which specify the time for the reservation, highlighted in FIGURE 8 in yellow. Clicking on that time activity, the click input is received by the system which in return provides the display of FIGURE 9.
  • FIGURE 9 illustrates another display provided by the present system.
  • FIGURE 9 illustrates a screen after the creator has provided input.
  • the input may include a click on the Time system action for the user, and has filled in 7:30 in the pop-up box which is created.
  • the creator may then cause the system to provide a display as shown in FIGURE 10.
  • FIGURE 10 illustrates another display provided by the present system.
  • FIGURE 10 illustrates a display provided by the present system.
  • the display of FIGURE 10 may be provided after receiving input clicking on the time. Note that the time has been posted to the history and to the internal state.
  • the creator has now selected three system actions to be done in behalf of the user, but has yet to offer a paraphrase. He may now paraphrase all the user actions, resulting in FIGURE 11.
  • FIGURE 11 illustrates another display provided by the present system.
  • FIGURE 11 illustrates that the creator has paraphrased all of the user actions in a single sentence on the right of the yellow line.
  • the creator should pick an action for the agent (representing the system explicitly in the dialog).
  • the agent could be thought of as a person, but in present system it should be considered a virtual person which knows the constraints of the conversational system.
  • the Creator can find system actions for the agent by using the search box, as in FIGURE 12.
  • FIGURE 12 illustrates another display provided by the present system.
  • FIGURE 12 illustrates that the Creator has filled in the word "agent" in the search box, and the top of the list of agent actions are now displayed below the search box. An agent action may be picked using the mouse, creating FIGURE 13.
  • FIGURE 13 illustrates another display provided by the present system.
  • FIGURE 13 illustrates that the action of the agent is now selected by mouse, and highlighted in yellow. Clicking on the selected agent task of asking for the restaurant name results in FIGURE 14.
  • FIGURE 14 illustrates another display provided by the present system.
  • FIGURE 14 illustrates the user interface after clicking on the agent action to request a restaurant name.
  • the creator has provided a paraphrase for the agent's action, implying that present system will now be requesting a user action.
  • the present system has offered a context-dependent selection of possible user actions. One may be picked with the mouse, resulting in a highlighted next dialogue action as shown in FIGURE 15.
  • FIGURE 15 illustrates another display provided by the present system.
  • FIGURE 15 illustrates that the creator is selecting a next action to be taken by the user in the dialogue by directing a cursor, for example using a mouse or other input device, over a possibility which is then highlighted in yellow.
  • the next task for the user is to provide a restaurant name. Clicking on the yellow line in FIGURE 15, the present system get FIGURE 16.
  • FIGURE 16 illustrates another display provided by the present system.
  • FIGURE 16 illustrates the result of clicking on the highlighted line in FIGURE 15, then filling in the pop-up box asking for a restaurant name.
  • the present system Upon clicking OK in the dialogue box, filling in the paraphrase, and writing "agent" in the search box, the present system get FIGURE 17.
  • FIGURE 17 illustrates another display provided by the present system.
  • FIGURE 17 illustrates the system interface after selecting a restaurant name. The creator has asked for possible actions for the agent, and has highlighted a request by the agent for the location of the restaurant.
  • FIGURE 17 illustrates another display provided by the present system.
  • the agent has requested the location of the restaurant, and the creator has selected the user action of providing the name. A shown, the creator has highlighted the next dialogue step, where the user will provide the location of the restaurant. Clicking on the user action noted in FIGURE 18, the present system then provides FIGURE 19.
  • FIGURE 19 illustrates another display provided by the present system.
  • FIGURE 19 illustrates that the user has specified the restaurant location in the pop up box. After the user has specified the restaurant, the creator would like to find an appropriate action for the agent, but it is somewhat lower in the list than the top screen. The creator thus scrolls down his screen to select an action for the agent, creating FIGURE 20.
  • FIGURE 20 illustrates another display provided by the present system.
  • FIGURE 20 illustrates the party-size request for the agent in the list of possible actions.
  • the creator could put a request for party size in the search box, and the party-size action would be at the top of the action list, as in FIGURE 21.
  • FIGURE 21 illustrates another display provided by the present system.
  • FIGURE 21 illustrates selecting a party size request from a list which has been reordered by the search box. Clicking on the party size action results in FIGURE 22.
  • FIGURE 22 illustrates another display provided by the present system.
  • FIGURE 22 illustrates that the creator has filled in a party size of 4 into the pop up box from clicking on the user activity of defining the party size. Clicking on OK, and then clicking on a completion action by the agent, the present system transit to FIGURE 23. Note that whenever the present system changes the imaginary actor from user to agent or vice versa, the creator fills in the paraphrase box for that action or series of actions.
  • FIGURE 23 illustrates another display provided by the present system.
  • FIGURE 23 illustrates the final FIGURE for the dialogue between the user and the agent which is created by the creator. Note that the "system" knows some information from the
  • the annotated conversation may be created in a few minutes by an unskilled creator. As noted above, if the creator has to use free text phrases rather than specific present system actions, then it is a flag that the system might be lacking some essential ingredients.
  • the system described herein may be implemented in several ways and include additional and fewer features while still within the intended scope of the present technology.
  • the possible actions may be sorted in order of decreasing policy model score. This is like an autocomplete, suggesting actions which the model thinks are more likely. The creator can always reject the top options and scroll down to the desired choice. This adds additional training data, which trains the policy in an online fashion.
  • the possible actions can also be sorted by order of increasing absolute value of the model score. This favors scores which are close to 0, for which the policy is most uncertain about. This allows the creator to provide information explore unexpected activities or new actions, analogous to an active learning system.
  • the possible actions may be restricted to model a particular implementation of a conversational system to reduce the search space.
  • the conversation which is paraphrased in this example may be provided to the creator, thus making the task to choose system actions which match the conversation. This can be used to verify the system.
  • the series of system actions may be provided to the creator, thus making the task to write paraphrases which match the system actions rather than choosing actions.
  • the creator may be asked to evaluate some or all of the potential conversation extension activities as appropriate or inappropriate, or to grade them on some appropriate.
  • the creator can be asked to either rate the actions exhaustively or to simply choose the 5-10 most likely actions.
  • the creator can be asked to mark only the actions which are possible or the actions which are probable.
  • FIGURE 24 is a block diagram of a computer system 2400 for implementing the present technology.
  • System 2400 of FIGURE 24 may be implemented in the contexts of the likes of client 110, mobile device 120, computing device 130, network server 150, application server 160, data store 170, annotated training datastore 180, and data generation system 190.
  • the computing system 2400 of FIGURE 24 includes one or more processors 2410 and memory 2420.
  • Main memory 2420 stores, in part, instructions and data for execution by processor 2410.
  • Main memory 2410 can store the executable code when in operation.
  • the system 2400 of FIGURE 24 further includes a mass storage device 2430, portable storage medium drive(s) 2440, output devices 2450, user input devices 2460, a graphics display 2470, and peripheral devices 2480.
  • the components shown in FIGURE 24 are depicted as being connected via a single bus 2490. However, the components may be connected through one or more data transport means.
  • processor unit 2410 and main memory 2420 may be connected via a local microprocessor bus, and the mass storage device 2430, peripheral device(s) 2480, portable or remote storage device 2440, and display system 2470 may be connected via one or more input/output (I/O) buses.
  • I/O input/output
  • Mass storage device 2430 which may be implemented with a magnetic disk drive or an optical disk drive, is a non-volatile storage device for storing data and instructions for use by processor unit 2410. Mass storage device 2430 can store the system software for implementing embodiments of the present invention for purposes of loading that software into main memory 620.
  • Portable storage device 2440 operates in conjunction with a portable non-volatile storage medium, such as a compact disk, digital video disk, magnetic disk, flash storage, etc. to input and output data and code to and from the computer system 2400 of FIGURE 24.
  • a portable non-volatile storage medium such as a compact disk, digital video disk, magnetic disk, flash storage, etc.
  • the system software for implementing embodiments of the present invention may be stored on such a portable medium and input to the computer system 2400 via the portable storage device 2440.
  • Input devices 2460 provide a portion of a user interface.
  • Input devices 2460 may include an alpha-numeric keypad, such as a keyboard, for inputting alpha-numeric and other information, or a pointing device, such as a mouse, a trackball, stylus, or cursor direction keys.
  • a pointing device such as a mouse, a trackball, stylus, or cursor direction keys.
  • the system 2400 as shown in FIGURE 24 includes output devices 2450. Examples of suitable output devices include speakers, printers, network interfaces, and monitors.
  • Display system 2470 may include a liquid crystal display (LCD), LED display, touch display, or other suitable display device.
  • Display system 2470 receives textual and graphical information, and processes the information for output to the display device.
  • Display system may receive input through a touch display and transmit the received input for storage or further processing.
  • Peripherals 2480 may include any type of computer support device to add additional functionality to the computer system.
  • peripheral device(s) 2480 may include a modem or a router.
  • the components contained in the computer system 2400 of FIGURE 24 can include a personal computer, hand held computing device, tablet computer, telephone, mobile computing device, workstation, server, minicomputer, mainframe computer, or any other computing device.
  • the computer can also include different bus configurations, networked platforms, multi-processor platforms, etc.
  • Various operating systems can be used including Unix, Linux, Windows, Apple OS or iOS, Android, and other suitable operating systems, including mobile versions.
  • the computer system 300 of FIGURE 3 may include one or more antennas, radios, and other circuitry for communicating via wireless signals, such as for example communication using Wi-Fi, cellular, or other wireless signals.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Artificial Intelligence (AREA)
  • Health & Medical Sciences (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Computational Linguistics (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Computer Interaction (AREA)
  • Software Systems (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Data Mining & Analysis (AREA)
  • Evolutionary Computation (AREA)
  • Medical Informatics (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Acoustics & Sound (AREA)
  • Multimedia (AREA)
  • Machine Translation (AREA)

Abstract

La présente invention concerne un système de collecte de données basé sur un ensemble général d'actes de dialogue qui sont dérivés d'un schéma de base de données. Les collaborateurs à la production participative exécutent deux types de tâches : (i) l'identification de trajets de dialogue sensitifs et (ii) la réalisation de paraphrase dépendant du contexte de ces trajets de dialogue en dialogues réels. La sortie d'extrémité du système est un ensemble d'exemples de formation de dialogues réels qui ont été annotés avec leurs formes logiques. Ces données peuvent être utilisées afin de former les trois composants du système de dialogue : (i) l'analyseur sémantique destiné à comprendre des énoncés dépendants du contexte, (ii) la politique de dialogue destinée à générer de nouveaux actes de dialogue en fonction de l'état actuel, et (iii) le système de génération destiné aussi bien à décider quoi dire que comment le rendre en langage naturel.
EP17867628.4A 2016-11-04 2017-11-06 Collecte de données destinée à un nouveau système de dialogue conversationnel Withdrawn EP3535664A4 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201662418035P 2016-11-04 2016-11-04
PCT/US2017/060134 WO2018085760A1 (fr) 2016-11-04 2017-11-06 Collecte de données destinée à un nouveau système de dialogue conversationnel

Publications (2)

Publication Number Publication Date
EP3535664A1 true EP3535664A1 (fr) 2019-09-11
EP3535664A4 EP3535664A4 (fr) 2020-06-17

Family

ID=66925032

Family Applications (1)

Application Number Title Priority Date Filing Date
EP17867628.4A Withdrawn EP3535664A4 (fr) 2016-11-04 2017-11-06 Collecte de données destinée à un nouveau système de dialogue conversationnel

Country Status (2)

Country Link
EP (1) EP3535664A4 (fr)
CN (1) CN109891410B (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110442701B (zh) * 2019-08-15 2022-08-05 思必驰科技股份有限公司 语音对话处理方法及装置
US11508359B2 (en) 2019-09-11 2022-11-22 Oracle International Corporation Using backpropagation to train a dialog system

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2427512C (fr) * 2000-10-31 2011-12-06 Unisys Corporation Outil de developpement d'interpreteur de flux de dialogue
US7933774B1 (en) * 2004-03-18 2011-04-26 At&T Intellectual Property Ii, L.P. System and method for automatic generation of a natural language understanding model
CN101287042A (zh) * 2008-05-17 2008-10-15 李东方 语言声音信息服务
CN112270925B (zh) * 2014-09-14 2024-05-10 谷歌有限责任公司 用于创建可定制对话系统引擎的平台
US20160202957A1 (en) * 2015-01-13 2016-07-14 Microsoft Technology Licensing, Llc Reactive agent development environment

Also Published As

Publication number Publication date
EP3535664A4 (fr) 2020-06-17
CN109891410A (zh) 2019-06-14
CN109891410B (zh) 2023-06-23

Similar Documents

Publication Publication Date Title
US10824798B2 (en) Data collection for a new conversational dialogue system
US10217462B2 (en) Automating natural language task/dialog authoring by leveraging existing content
Raj et al. Building chatbots with Python
US20170337261A1 (en) Decision Making and Planning/Prediction System for Human Intention Resolution
CN106471570B (zh) 多命令单一话语输入方法
US10088972B2 (en) Virtual assistant conversations
US20220129556A1 (en) Systems and Methods for Implementing Smart Assistant Systems
US20210097140A1 (en) System and method for generation of conversation graphs
CN113728341A (zh) 对机器人系统的性能的洞察
US11972095B2 (en) Voice assistant-enabled client application with user view context and multi-modal input support
CN107636648A (zh) 基于情绪标识来构造响应
US10467345B2 (en) Framework for language understanding systems that maximizes reuse through chained resolvers
US10713288B2 (en) Natural language content generator
US10474439B2 (en) Systems and methods for building conversational understanding systems
Kong et al. Conversational AI with Rasa: Build, test, and deploy AI-powered, enterprise-grade virtual assistants and chatbots
EP4381440A1 (fr) Reconnaissance et capture d'entité d'observation sensibles au contexte
Sabharwal et al. Developing Cognitive Bots Using the IBM Watson Engine: Practical, Hands-on Guide to Developing Complex Cognitive Bots Using the IBM Watson Platform
US11789696B2 (en) Voice assistant-enabled client application with user view context
CN112835860B (zh) 共享文档的处理方法、装置、设备及计算机可读存储介质
CN116888661A (zh) 用于辅助系统的包括非拉丁或不可解析内容项的通信内容的读出
CN109891410B (zh) 用于新的会话对话系统的数据收集
US20230401031A1 (en) Voice assistant-enabled client application with user view context
CN110249326B (zh) 自然语言内容生成器
CN110447026B (zh) 用于在新的域中提供自动化助理的开发人员平台
Pathak Artificial Intelligence for .NET: Speech, Language, and Search

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20190423

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
A4 Supplementary search report drawn up and despatched

Effective date: 20200515

RIC1 Information provided on ipc code assigned before grant

Ipc: G10L 15/22 20060101ALI20200512BHEP

Ipc: G06F 40/35 20200101AFI20200512BHEP

Ipc: G10L 15/06 20130101ALI20200512BHEP

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20210901

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20211202