The slot types are the valid values a user can respond with, which can be either custom-defined or one of Amazon’s pre-built types. Slots: This represents a piece of data needed for the chatbot to fulfill the user’s intent. In the case of Winston, text phrases are used to recognize the user’s intention and trigger the proper intent. Utterances: Speech or text phrases that trigger the intent.
In our case, most intents are simple questions with direct answers. Intent: Think of this as a conversation it represents the goal of the chatbot user. This allows developers to create conversational interactions by using the same deep learning technologies that power Amazon Alexa. In April 2017, Amazon Lex was introduced to the developer community it provides the advanced deep learning functionalities for automatic speech recognition (ASR) to convert speech into text, and natural language understanding (NLU) to recognize the intent of the text. “Lex” is a key technological component of our project. This functionality makes Winston a useful Slack-integrated application without limiting its ability to one day be integrated it into a speech interface such as Amazon Alexa. While Amazon Lex provides both speech recognition and natural language understanding, our scope for this project was to create a text-based chatbot using only Lex’s natural language understanding. We decided to name our assistant chatbot “Winston.” Our use of servers was limited, as we wanted to keep the cost of the project to a minimum. The chatbot was implemented using Amazon Web Services Lex, and the final solution only incorporated AWS and Slack-provided services. In response to this issue, a few of us at Gorilla Labs decided to create a Slack-integrated chatbot. As the resources within the company increase, the need to place them in an easily-accessible repository becomes critical. This information comprises HR policies, administrative and technical processes, company benefits and IT know-how. AMAZON.Number(slot name - “Passengers”, slot type- :AMAZON.Number) and takes number for passenger slot and street name for address slot(Custom slot type -Address, slot name:“PickUpLocation”).Īlthough the slot priority is defined.As a company grows, more and more information is generated. Using custom slot for taking addresses or AMAZON.StreetName, when user utters an address in format of "street number street name", the number in the beginning of the utterance also triggers the wrong slot i.e. We also have problems with some non english names like "Ifti", bot takes it as "b50" or "if the" or "Momal" which it takes as "Nom"etc.
Performance of the bot is similar for a custom slot type "Address", we have defined for taking pickup or drop off addresses.ĭo we need to make any custom vocabulary with corresponding pronunciation in S3, for fine tuning the AWS lex transcribe, if yes, how can we do that?īot is also not able to understand AMAZON.number slot utterance for "one” which is transcribed as "juan"/"jone". Although, slow and clear user utterances improves transcription quality but bot still captures some noise in input, and also we cannot expect our users to be articulating words to the bot all the time.
When talking to bot over call, using the number claimed in connect, the bot's transcribe / Speech to text performance gets really bad and it is not able to transcribe anything user utters for addresses, except for yes/no confirmations.For complex addresses like user said "tesco kirkdale" bot takes as "has girl deal"(sample attached - 6). We have tried using it for our bot, and it seems to work fine with user address utterances like "eight chapel hill" or "fifteen cross lane" but only in the lex testbot console. Lex provides a built- in slot called Amazon.StreetName for getting street addresses from users. One of the requirements is to get an address from the user using a single prompt. We are making a Lex bot V1 integrated with Amazon connect for the purpose of booking a cab.
0 kommentar(er)
