• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Building Conversational Agents In Oz
 

Building Conversational Agents In Oz

on

  • 346 views

 

Statistics

Views

Total Views
346
Views on SlideShare
346
Embed Views
0

Actions

Likes
0
Downloads
8
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Building Conversational Agents In Oz Building Conversational Agents In Oz Presentation Transcript

    • The C URRENT Platform: Building Conversational Agents in Oz * Torbjörn Lager Fredrik Kronlid Department of Linguistics University of Göteborg
    • Conversational Software Agents
      • Software we can ‘talk’ with, in natural language
      • Examples
        • Eliza (Weizenbaum 1966)
        • Question-answering systems (e.g. on the web)
        • Spoken dialog systems (for reserving train tickets, etc.)
        • Intelligent homes / cars / appliances
        • HAL (in the movie 2001)
    • We want to build agents that are…
      • able to ‘perceive’, ‘think’ and ‘act’ at the same time
      • capable of incremental processing of natural language
      • sensitive to the presence of other conversational software agents
      • making use of sophisticated, state-of-the-art methods for NLP
      • Question: Can Oz be of any help here?
    • The C URRENT Platform
      • An abstract characterization of what it means to be a conversational agent.
      • A ‘visual’ IDE supporting the building of conversational agents by constructing a graphical representation of a network of NLP components on a canvas.
      • A number of ready-made NLP components such as lexica, taggers and parsers for a variety of languages, and dialogue managers for a variety of tasks.
      • A number of libraries supporting the implementation of other such NLP components.
    • An Abstract Characterization of Conversational Agents
      • Simplifying considerably, a conversational agent is an interactive and incremental transducer of an input stream of words into an output stream of words, accompanied by an evolving internal state.
      • Clarifications
        • Interactive means that the transducer is able to accept external input, as well as output (intermediate) responses, during the course of a transduction
        • One agent – one transduction
      • Inspiration
        • Peter Wegner’s work on Turing machines vs. Interaction machines
    • Very abstract indeed…
      • … but can be directly implemented in Oz, since
        • Streams are provided as basic building blocks,
        • transducers working on streams are no harder to implement than transducers working on lists or strings,
        • and if transducers are run in their own thread(s), incrementality, and thus interactivity, comes for free!
      • Declarative concurrency – “… gives the same results as a sequential program but can give them incrementally… ” (van Roy and Haridi, Chapter 4)
    • C URRENT Agent = Network of Components
      • An agent is a network of components – sources, sinks, transducers, splitters and mergers – connected by streams.
      • Each component runs in its own thread(s)
      • Since each component is incremental, so is the whole network.
    • Component Technologies
      • Form-based dialogue management
      • Transformation-based tagging
      • Pattern-matching over streams of records
      • Deep parsing + compositional logical semantics
      • The information-state approach to dialogue management (Larsson, 2002)
    • Form-Based Dialogue Management
      • Script specifies forms consisting of form items such as input fields and blocks of executable content
      • Input fields may be associated with grammars that specify what the user can say
      • Prompts specify the system’s response. Prompts may be tapered .
      • When a script is interpreted (by the FIA) the user is prompted for values of fields in order. But mixed initiative dialogue, as well as task switching, is also supported.
      • FIA raises events e.g. in case of no input, or input that does not match the grammar associated with the field.
      • Events may be handled , e.g. by jumping to another form that initiates (say) a clarification dialogue. (‘Jumping’ in the ‘state machine’ sense.)
      • The assignment of values to fields may trigger actions , e.g. a database lookup.
    • Example VoiceXML Script
      • <form id=&quot;get_from_and_to_cities&quot;>
      • <grammar src=&quot;http://www.directions.example.com/grammars/from_to.grxml&quot;
      • type=&quot;application/srgs+xml&quot;/>
      • <block>
      • Welcome to the Driving Directions By Phone.
      • </block>
      • <initial name=&quot;bypass_init&quot;>
      • <prompt>
      • Where do you want to drive from and to?
      • </prompt>
      • <nomatch count=&quot;1&quot;>
      • Please say something like &quot;from Atlanta Georgia to Toledo Ohio&quot;.
      • </nomatch>
      • <nomatch count=&quot;2&quot;>
      • I'm sorry, I still don't understand.
      • I'll ask you for information one piece at a time.
      • <assign name=&quot;bypass_init&quot; expr=&quot;true&quot;/>
      • <reprompt/>
      • </nomatch>
      • </initial>
      • <field name=&quot;from_city&quot;>
      • <grammar src=&quot;http://www.directions.example.com/grammars/city.grxml&quot;
      • type=&quot;application/srgs+xml&quot;/>
      • <prompt>From which city are you leaving?</prompt>
      • </field>
      • <field name=&quot;to_city&quot;>
      • <grammar src=&quot;http://www.directions.example.com/grammars/city.grxml&quot;
      • type=&quot;application/srgs+xml&quot;/>
      • <prompt>Which city are you going to?</prompt>
      • </field>
      • </form>
    • Corresponding CURRENT FIA Script
      • class $ from DM.form
      • feat
      • id: getFromAndToCities
      • test: match(con([opt(sym('from')) sym(nil label:fromCity) sym(to) sym(nil label:toCity)]))
      • items: [class $ from DM.block
      • feat
      • todo: prompt('Welcome to the Driving Distance Service.')
      • end
      • class $ from DM.initial
      • feat
      • name: bypassInit
      • todo: prompt('Where do you want to drive from and to?')
      • meth nomatch()
      • if {self nomatchCount($)}==1 then
      • {self prompt('Please say something like &quot;from Oslo to Kiel&quot;.')}
      • else
      • {self prompt('I'm sorry, I still don't understand. '#
      • 'I'll ask you for info one piece at a time.')}
      • {self assign(name:bypassInit expr:true)}
      • {self reprompt()}
      • end
      • end
      • end
      • class $ from DM.field
      • feat
      • name: fromCity
      • todo: prompt('From which city are you leaving? ')
      • test: match(sym(nil label:fromCity))
      • end
      • class $ from DM.field
      • feat
      • name: toCity
      • todo: prompt('Which city are you going to? ')
      • test: match(sym(nil label:toCity))
      • end
      • ]
      • end
    • Demo
    • Transformation-Based Tagging
      • Rule-based disambiguation method invented by Eric Brill (1995)
      • Rules may be machine learned
      • For part-of-speech tagging, unknown-word guessing, phrase chunking, word sense disambiguation, dialogue act recognition, etc.
      • Useful also in a dialogue system setting? Yes, but only if it can be made to process input in an incremental fashion
    • Incremental Part-of-Speech Tagging
      • The part-of-speech tagging problem
        • The light went off, so I will light a candle. Pass me the light bag, please. No, the light blue one.
      • Incremental part-of-speech tagging
        • At t 1 : The/DET …
        • At t 2 : The/DET light/? …
        • At t 3 : The/DET light/ADJ bag/NOUN …
      • Word-by-word incremental POS tagging is not possible, but nearly word-by-word incremental POS tagging is, and that’s sufficient.
    • Implementation
      • Each rule is compiled into a stream transducer, running in a separate thread
      • Incremental but with accuracy as if run in batch
      • Several hundred rules  several hundred streams and several hundred threads... Performance still OK.
    • Pattern Matching over Streams of Records
      • Condition–action rules
        • Conditions: Labelled regular expression pattern matching over the input stream of records
        • Actions: Update out-stream with records
      • Method inspired by Appelt’s CPSL and by JAPE (part of the GATE NLP platform - Cunningham et al.).
        • Rules are interpreted rather than compiled into FSMs
        • Works on streams and in an incremental fashion
      • For keyword spotting, phrase chunking, named entity recognition, ‘semantic parsing’
    • Implementation
      • Regular expression matcher implemented LP-style, using the choice construct in combination with a search engine
      • Roughly 200 lines of code
      • Slow, but sufficient for dialogue processing
    • Demo
    • Summary: Important Oz Features
      • Concurrency , for building agents that are able to ‘perceive’, ‘think’ and ‘act’ at the same time
      • Concurrency + streams , for building agents that are capable of incremental processing of natural language
      • Concurrency + streams + ports, for allowing us to specify the `toplevel' transducer as a network of components, e.g. for building multi-modal conversational agents (modality fusion/fission)
      • All kinds of Oz features , for building agents using sophisticated, state-of-the-art methods for NLP
      • Network-transparent distribution , for building multi-party dialogue systems