About tutorial knowledge_base

@Tanja Bergmann, thank you for the awesome knowledge graph + rasa tutorial. We also build kg for our bots. The two problems we encountered are: 1. as you see, the stories contains actions like query entities and query attributes, which are not very intuitive for bot designers (we involves all roles in our team, technical or non-technical to design bots together). Intents and actions, that are too abstract, would hinder our communication efficiency. 2. as the kg grows and becomes more complex, we end up in the situation when dialogue flows are controlled by both the policy models and the actions, which makes our project hard to maintain. Do you have some rules that would help us avoid those kind of problems.

@XufengXufengXufeng Thanks for your feedback and your interest!

  1. You could split the generic intents into multiple more specific intents, such as list_banks or list_accounts. This includes more maintenance work as you need to define a new intent per new entity in your knowledge base, but the intents might be easier to understand. However, I’m not sure how well our classifier can distinguish those intents as they might be very similar. But maybe something you can try out.
  2. What do you mean by dialogue flows are controlled by both the policy models and the actions? Can you maybe give an example?

Thank you @Tanja for you advice about the splitting intents. While it is very hard to distinguish from the intents, it is an option. We also applied your idea of doing regular expression prior to each knowledge query, compared with writing re before the interpreter (had to change the re every time when we retrained the interpreter), is much easier.

An example of the control issue, is that when we query entity like a bank, if it is a bank in list A, we act in one way (a dialogue turn) if it is one of the other banks we act in a different way (a different turn). We can represent the dialogue turns in stories, which may confuse the DM model, but when there are too many turns in different situation, we have to write some if statements with some slot altering in the action module, which means we have changed the dialogue flows through the action. And the most hard part in this case is the slot status management. Making some slots empty may suit a situation but gives weird response in the other situation. Just thinking about it makes my head hurt.

Sorry, for the late reply. It seems like a tricky situation. Unfortunately, I cannot recommend you how to handle such a situation. A colleague suggested, that forms might help to stay in one path. But not sure if that is what you want. Would be eager to know when you find a way how to deal with such situations.