Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Tutorial on Chatbot Development with Xatkit

484 views

Published on

Learn how to use the open-source & low-code chatbot development platform Xatkit to create all kinds of advanced chatbots and voicebots able to connect to a myriad of external platforms

Published in: Software
  • Be the first to comment

Tutorial on Chatbot Development with Xatkit

  1. 1. Tutorial on Chatbot Development with Xatkit Easiest way to create advanced (chat)bots and digital assistants - #OSS #low-code @xatkit – xatkit.com
  2. 2. Why Chatbots
  3. 3. “Business Insider experts predict that by 2020, 80% of enterprises will use chatbots. … by 2022, banks can automate up to 90% of their customer interaction using chatbots … 40% of large companies employing more than 500 people plan to implement one or more intelligent assistant…” - https://chatbotsmagazine.com/chatbot-report- 2019-global-trends-and-analysis-a487afec05b Chatbot market to surpass 1B USD by 2021
  4. 4. But what is exactly a Chatbot? • Chatbot = Bot + Conversational Interface CI = Chat interface OR voice interface • Chatbot = Digital Assistant
  5. 5. Challenges in building Chatbots
  6. 6. Let’s create a chatbot to help newcomers to write issues on Github! Alright! It’s just a set of questions & answers, this will be pretty simple! Narrator It wasn’t. Once upon a time (when we were naïve enough to think that creating a chatbot would be easy)
  7. 7. Chatbot applications Our idea of the kind of rules we were hoping to write User Intent Action Parameters If the User Wants To Open Issue Reply « In which repository? » on Slack Platform
  8. 8. What went wrong? – Many pieces to put together Input/Output Messaging channels External Platforms NLU Engine
  9. 9. Chatbots are complex systems Conversation Logic Text Processing External Services Messaging Platforms Deployment Evolution Maintenance Tests
  10. 10. At the core: NLP/NLU component • NLP: Natural Language Processing. NLU: Natural Language Understanding. In theory, NLU is a more sophisticated version of NLP. In practice they are both used mostly indistinctintly • Two key missions • Classify the user utterance in one of the intents defined in the bot • Identify the parameters (called « entities ») from the utterance
  11. 11. NLU approaches • Regular expressions • Require an almost exact match. Not used • Grammar-based approaches • Useful for small domains with a very specific vocabulary and constructs • E.g. Stanford Parser • Neural Networks - Multiclass classifiers • You provide some training sentences for each intent (the "classes" ). The classifier learns from these sentences and tries to assign any new input text to one of the classes. • It’s most common approach nowadays
  12. 12. Common tricks in NLUs • Tokenizers split the sentences into words • Stemmers identify the lemma of the word (e.g. to focus on the verb, not on the tense of the verb for matching purposes) • Synonyms are an automatic way to expand the training sentences • Entity augmentation also generalize training sentences • E.g. What’s the weather in Barcelona -> What’s the weather in @city (the intent will match no matter what city the user asks for, no need to train the classifier with all the cities of the world as it will already know the list of cities itself). • Augmentation is possible for a large number of data types and common concepts (measures, countries, dates,…) https://medium.com/@jseijas/how-to-build-your-own-nlp-for-chatbots-9b4c08eb03a9
  13. 13. Chatbot Development Platforms
  14. 14. The AI ecosystem is huge
  15. 15. >100 chatbot platforms • Rasa, BotPress, Chatfuel, Inbenta, Botsify, Flow XO,… • And quite a few NLU providers: DialogFlow, Lex, LUIS, Watson, NLP.js
  16. 16. … but • Only around 15% are open source • Not flexible (i.e. difficult to integrate other platforms) • Not interoperable • Low-level (as soon as you need the bot to do some action you end up programming in JS)
  17. 17. • Grady Booch – history of softwre engineering The entire history of software engineering is that of the rise in levels of abstraction - Grady Booch Also true for AI/chatbots -> Chatbot Modeling to the rescue!
  18. 18. The Xatkit solution
  19. 19. Xatkit – Key Concepts
  20. 20. Xatkit Framework • Raise the level of abstraction at what chatbots are defined • Focus on the core logic of the chatbot • Conversation and user interactions • Action computations • Independent from specific implementation technologies • Automatize the deployment and execution of the modeled chatbot • Deploy over multiple platforms • Execute the chatbot logic
  21. 21. Xatkit is • A model-based & low-code chatbot development platform • Where chatbots are defined using a couple of external DSLs • And with a runtime engine that deploys and executes the bots over the desired platforms
  22. 22. In Xatkit, platforms are • An abstraction of any input/output messaging tool and any external service. Platform interfaces are also defined with a DSL • Platforms offer actions (that the bot can execute) and events (whom the bot can subscribe to) • PIM/PSM : Bots can be defined using generic platforms that are then concretely instantiated during the deployment. No need to change the bot • Any new platform becomes immediately available to any existing bot
  23. 23. Voice support • Voice interfaces (like Alexa) are just another platform • Voice is translated into text (speech2text tools) and then processed as if the user had written it.
  24. 24. Xatkit Architecture
  25. 25. Xatkit Framework Chatbot Designer Intent Recognition NLU Providers (platform-specific) Platform Package Intent Package Xatkit Modeling Language Chatbot User Instant Messaging Platforms Xatkit Runtime Execution Package uses uses Platform-independent chatbot definition External Services Deployment Configuration Platform Designer
  26. 26. Intent Language (example bot to create new issues in a GH repo) Library Example intent OpenNewIssue { inputs { ‘’I want to create an issue’’ ‘’Open an issue’’ } } intent SpecifyRepository follows OpenNewIssue { inputs { ‘’In repository MyRepo’’ } creates context Repository { sets value name from fragment ‘’MyRepo’’ (entity any) } } • Inputs defines the set of training sentences for the intent • Follows defines a partial order among intents. SpecifyRepository will be only considered a potential match if we have matched OpenNewIssue before • A context records variables to be used later on in the execution model. Here we store the name of the repo in the name attribute of the Repository context.
  27. 27. Execution Language Import library Example Import platform Slack Import platform Github Listen to Slack on intent OpenNewIssue do Slack.Reply(‘’Sure, I’ll help you to write your issue! Which repository would you like to report an issue for?’’) on intent SpecifyRepository do Github.OpenIssue(context(Repository).get(name), context(Issue).get(title), context(Issue).get(content)) Slack.PostMessage(‘’A new issue has been opened in ’’ context(Repository).get(name)) • The import platform allows you to easily interact with any existing platform, e.g. replying on Slack or asking GH to create the issue • On intent defines what needs to be done after the intent is matched. Several actions can be executed
  28. 28. Platform definition • The execution model can directly refer to all predefined platforms in Xatkit. 10+ right now: Slack, Zapier, Alexa, UML, Giphy, GitHub, Neo4j,… • Chatbot designers only need to define a new platform if they have special needs. This implies: • Declaring the platform interface • Implementing the platform itself as a Java class in the proper place in the platform hierarchy • Plenty of auxiliary classes and boilerplate code facilitate this implementation
  29. 29. Platform Language Abstract platform Chat actions { PostMessage(message, channel) Reply(message) } } Platform Slack extends Chat Platform Discord extends Chat Platform Github actions { OpenIssue(repository, title, content) GetIssue(user, repository, issueNumber) … } event Issue_Opened event Issue_Edited … • Platforms are also declaratively defined • Platform hierarchy facilitates reusability and genericity • Platforms offer actions to be executed and events to subscribe to
  30. 30. The compute method shows how we implemented the PostMessage action in Slack
  31. 31. Xatkit Framework Intent Recognition Providers (platform-specific) Platform Package Intent Package Xatkit Modeling Language Instant Messaging Platforms Xatkit Runtime Execution Package uses uses Platform-independent chatbot definition External Services Deployment Configuration Chatbot Designer Chatbot User Platform Designer
  32. 32. Runtime Component • Generic event-based execution engine • Loads the platform-specific connectors referenced in the bot definition • Automatic deployment • Execution life-cycle • Inputs • Chatbot model (defined with the Xatkit modeling language) • Configuration file (Oauth tokens, API keys, platform-specific parameters,…)
  33. 33. Runtime configuration example // Intent Recognition Provider Configuration xatkit.intent.recognition = DialogFlow xatkit.dialogflow.project = dialogflow_project_id xatkit.dialogflow.credentials = key.json // Platform configuration xatkit.slack.credentials = slack_oauth_token xatkit.discord.credentials = discord_credentials xatkit.github.credentials = github_oauth_token
  34. 34. Xatkit Tool
  35. 35. Tool Support • Available on GitHub as an independent organization: https://github.com/xatkit-bot-platform/ to facilitate external contributions • Open source (EPL v2) • Some numbers about the development activity (as of today) • 22 code repositories • 1154 commits • 6 contributors • 13 platforms + 2 NLU providers • Xatkit Development Toolkit (XDK) to ease onboarding of new contributors (To Extend)
  36. 36. Eclipse Editor – Xtext-based
  37. 37. Care to contribute? • With your own examples • Improving our platform support • Extensions to the current platforms with new actions or events • New platforms • Our own NLP connectors • Adding support for new providers • Or in any of the many other ways you can help an OSS project https://livablesoftware.com/5-ways-to-thank-open-source- maintainers/
  38. 38. Chatbot examples
  39. 39. The Greetings bot
  40. 40. A bot that says Hi intent HowAreYou { inputs { "How are you?" "What's up?" "How do you feel?" } } import platform "ReactPlatform" use provider ReactPlatform.ChatProvider on intent HowAreYou do action ReactPlatform.Reply(message : "Hi! I am good, and you?") • It doesn’t require any additional configuration. • Matching is done with regular expression so you need to enter the exact text. We use it for testing the correct installation of the platofrm
  41. 41. UML Bot
  42. 42. A bot to model together in Slack intent HowAreYou { inputs { "How are you?" "What's up?" "How do you feel?" } } intent CreateClass { inputs { "create class MyClass" } creates context Class { sets parameter name from fragment "MyClass" (entity any) } } intent AddAttribute { inputs { "add attribute MyAttribute" "add attribute MyAttribute with type MyType" } creates context Attribute { sets parameter name from fragment "MyAttribute" (entity any) sets parameter type from fragment "MyType" (entity any) } }
  43. 43. • The model is created as an instance of the Eclipse UML metamode • Save renders a graphical depiction of the UML model with PlantUML import platform "UmlPlatform" use provider SlackPlatform.ChatProvider on intent CreateClass do def class = action UmlPlatform.CreateClass(name : context(Class).get("name")) session.store("class", class) action SlackPlatform.Reply(message : "Created class " + context(Class).get("name")) on intent AddAttribute do def attribute = action UmlPlatform.AddAttribute(class : session.get("class"), name : context(Attribute).get("name"), type : context(Attribute).get("type")) action SlackPlatform.Reply(message : "Created attribute " + context(Attribute).get("name")) on intent Save do def saved = action UmlPlatform.Save action SlackPlatform.ReplyFileMessage(message : "here you go", file : saved)
  44. 44. The Bug Report bot
  45. 45. A bidirectional GitHub <-> Slack bot
  46. 46. • We force the user to tell us all the info we’ll need later on to reproduce the bug intent DescribeBug follows OpenBug { inputs { "My error is Error" "The problem is Error" … "I get the error Error" } creates context bug { sets parameter title from fragment Error (entity any) } } intent TellWPVersion follows DescribeBug { requires context bug inputs { "My version number is WPVersion" "I use number WPVersion" "It's version WPVersion" } creates context bug { sets parameter wpversion from fragment WPVersion (entity number) } } …
  47. 47. • We use all the info we collected to open the issue • We can even assign the new issue as a bug and even to a user if we want on intent TellPHPVersion do action SlackPlatform.Reply(message : "Thanks for your detailed info") def newissue = action GithubPlatform.OpenIssue(user : "jcabot", repository : "xatkit-tests", issueTitle : context(bug).get("title") , issueContent : "WP version is " + context(bug).get("wpversion") + " PHP version is " + context(bug).get("phpversion") ) action GithubPlatform.SetLabel(issue : newissue, label : "bug")
  48. 48. A bidirectional GitHub <-> Slack bot The bot now alerts us when somebody open an issue in a repo we are monitoring
  49. 49. • The bot reacts to the Issue_Opened event by alerting us on Slack. • The info provided by the event is processed and saved for a later use as part of the conversation the bot just triggered on event Issue_Opened do action SlackPlatform.PostMessage(message : "An issue has been opened with the title " + context(issue).get("issue->title"), channel: config(slack.channel)) def issue = action GithubPlatform.GetIssue(user : config(github.repository.username), repository : config(github.repository.name), issueNumber : context(issue).get("issue->number")) session.store("issue", issue)
  50. 50. More examples
  51. 51. Full set of examples • Go to: https://github.com/xatkit-bot-platform/xatkit- examples • Examples on: – Twitter to Slack – Slack to Trello via Zapier – Alexa – Giphy
  52. 52. Appendix: Basic concepts on model- driven engineering & DSLs
  53. 53. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Teaching material for the book Model-Driven Software Engineering in Practice by Marco Brambilla, Jordi Cabot, Manuel Wimmer. Morgan & Claypool, USA, 2012. www.mdse-book.com INTRODUCTION Chapter #1
  54. 54. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Abstraction and human mind • The human mind continuously re-works reality by applying cognitive processes • Abstraction: capability of finding the commonality in many different observations: • generalize specific features of real objects (generalization) • classify the objects into coherent clusters (classification) • aggregate objects into more complex ones (aggregation) • Model: a simplified or partial representation of reality, defined in order to accomplish a task or to reach an agreement
  55. 55. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Models What is a model? Mapping Feature A model is based on an original (=system) Reduction Feature A model only reflects a (relevant) selection of the original‘s properties Pragmatic Feature A model needs to be usable in place of an original with respect to some purpose ModelrepresentsSystem Purposes: • descriptive purposes • prescriptive purposes
  56. 56. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Motivation What is Model Engineering? ▪ Model as the central artifact of software development ▪ Related terms ▪ Model Driven Engineering (MDE), ▪ Model Driven [Software] Development (MDD/MDSD), ▪ Model Driven Architecture (MDA) ▪ Model Integrated Computing (MIC) Model Rapid prototyping Static analysis Code generation Automated testing Refactoring/ Transformation Documentation [Illustration by Bernhard Rumpe]
  57. 57. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Motivation Why Model Engineering? ▪ Increasing complexity of software ▪ Increasing basic requirements, e.g., adaptable GUIs, security, network capabilities, … ▪ Complex infrastructures, e.g., operating system APIs, language libraries, application frameworks ▪ Software for specific devices ▪ Web browser, mobile phone, navigation system, video player, etc. ▪ Technological progress … ▪ Integration of different technologies and legacy systems, migration to new technologies ▪ … leads to problems with software development ▪ Software finished too late ▪ Wrong functionality realized ▪ Software is poorly documented/commented ▪ and can not be further developed, e.g., when the technical environment changes, business model/ requirements change, etc.
  58. 58. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Motivation Application area of modeling ▪ Models as drafts ▪ Communication of ideas and alternatives ▪ Objective: modeling per se ▪ Models as guidelines ▪ Design decisions are documented ▪ Objective: instructions for implementation ▪ Models as programs ▪ Applications are generated automatically ▪ Objective: models are source code and vice versa t
  59. 59. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Concepts Principles and objectives ▪ Abstraction from specific realization technologies ▪ Requires modeling languages, which do not hold specific concepts of realization technologies (e.g., Java EJB) ▪ Improved portability of software to new/changing technologies – model once, build everywhere ▪ Interoperability between different technologies can be automated (so called Technology Bridges) ▪ Automated code generation from abstract models ▪ e.g., generation of Java-APIs, XML Schemas, etc. from UML ▪ Requires expressive und precise models ▪ Increased productivity and efficiency (models stay up-to-date) ▪ Separate development of application and infrastructure ▪ Separation of application-code and infrastructure-code (e.g., Application Framework) increases reusability ▪ Flexible development cycles as well as different development roles possible
  60. 60. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Teaching material for the book Model-Driven Software Engineering in Practice by Marco Brambilla, Jordi Cabot, Manuel Wimmer. Morgan & Claypool, USA, 2012. www.mdse-book.com MODELING LANGUAGES AT A GLANCE Chapter #6
  61. 61. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Anatomy of a Modeling Language • Abstract syntax: Describes the structure of the language and the way the different primitives can be combined together, independently of any particular representation or encoding. • Concrete syntax: Describes specific representations of the modeling language, covering encoding and/or visual appearance. • Semantics: Describing the meaning of the elements defined in the language and the meaning of the different ways of combining them.
  62. 62. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Anatomy of a Modeling Language
  63. 63. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. DSL vs. GPL First distinction is between • General Purpose languages (GPL or GPML) and • Domain Specific languages (DSL or DSML) (already discussed in Chapter 2) • We take UML as an exemplary case of GPL
  64. 64. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Principles for Domain Specific Languages • The language must provide good abstractions to the developer, must be intuitive, and make life easier, not harder • The language must not depend on one-man expertise for its adoption and usage. Its definition must be shared and agreed upon • The language must evolve and must be kept updated based on the user and context needs, otherwise it is doomed to die. • The language must come together with supporting tools and methods • The language should be open for extensions and closed for modifications (open-close principle)
  65. 65. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Classification of DSLs (1): FOCUS. Horizontal vs. Vertical • Vertical DSLs aim at a specific industry or field. • Examples: configuration languages for home automation systems, modeling languages for biological experiments, analysis languages for financial applications. • Horizontal DSLs have a broader applicability and their technical and cover concepts that apply across a large set of fields. They may refer to a specific technology but not to a specific industry. • Examples: SQL, Flex, WebML.
  66. 66. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Classification of DSLs (2): NOTATION. Graphical vs. Textual SAY THAT XATKIT IS TEXTUAL • Graphical DSLs: the outcomes of the development are visual models and the development primitives are graphical items such as blocks, arrows and edges, containers, symbols, and so on. • Textual DSLs comprise several categories, including XML-based notations, structured text notations, textual configuration files, and so on.
  67. 67. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Classification of DSLs (3): INTERNALITY. Internal vs. External SAY THAT XATKIT IS EXTERNAL • External DSLs have their own custom syntax, with a full parser and self-standing, independent models/programs. • Internal DSLs consist in using a host language and give it the feel of a particular domain or objective, either by embedding pieces of the DSL in the host language or by providing abstractions, structures, or functions upon it.
  68. 68. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. For more on MDE…. https://mdse-book.com Free Bonus materials on the website: • Over 500 slides • GH Project with plenty of modeling examples

×