Routing Microsoft LUIS Queries and the Bot Platform — Desirable in the Enterprise Reference Application

Question

My colleagues and I are working on creating a very large application using the Microsoft bot framework and Microsoft LUIS. Essentially, we are trying to create a bot where people from all over the organization can report to the bot (through slack) and receive relevant information. Different types of queries relate to different areas of the subject area (sales, marketing, logistics and R&D). How to combine several LUIS models, entities and entities so that the query does not request every object before getting into the correct object?

Right now, if a user asks: "How much did we spend a year on research?" he first requests the sales entity, then the marketing organization, then the logistics organization, and finally requests the R&D object before he receives a response. I am trying to limit the number of API requests. Currently, I know of three possible solutions that address this routing problem, and none of them rely on LUIS to route to the appropriate object.

Solution 1 includes the inclusion of a bot in the UI selector corresponding to each domain.

Solution 2 includes connecting the NLP library to extract the object from the sentence, and then matching the object using a weighted dictionary library.

Solution 3 involves setting up a clean RegEx. This is my least favorite decision for obvious reasons.

Linking to an enterprise-level reference application using the Microsoft bot framework and Microsoft LUIS would be the perfect answer.

Answer 1

Here is a new set of samples, including some cross-cutting demos, such as ContosoFlowers , which should shed light on how the current BOT project will be structured.

• Samples are task oriented, demonstrating specific structural features.
• Cross-cutting demos will be more consistent with what you are looking for, as you will see concepts such as dependency injection, using IScorable features, how to separate components, how to create reusable bot assets and how the project is organized / archived.

Another public bot is Azure Bot , where you will find a real implementation. Interesting refactoring also occurs in the addextensibility branch; where you can also see how architecture is evolving.

From the docs:

AzureBot was created to improve the performance of any developer, administrator or team working with Azure. It is currently available to the public and you can also follow our Developer Set Up to launch it yourself and contribute.

This first implementation focuses on Azure user authentication subscription, selecting and switching a subscription, starting and stopping RM-based virtual machines, and listing and starting Azure Automatic runbooks.