Not lex but Comprehend?

[aparna]

for the below question, i think it is comprehend to identify sentiment but the correct answer says it’s lex…can someone help why

9. QUESTION

Category: CSAP – Continuous Improvement for Existing Solutions

A retail company runs its customer support call system on its in-house data center. The Solutions Architect was tasked to migrate the call system to AWS and leverage the use of managed services to reduce management overhead. The solution must be able to handle the current tasks such as receiving calls and creating contact flows. It must be able to scale to handle more calls as the customer base grows. The company also wants to add deep learning capabilities to the call system to reduce the need to speak to an agent. It must be able to recognize the intent of the caller based on certain keywords and handle basic tasks, as well as provide information to the call center agents.

Which combination of actions should the Solutions Architect implement to meet the company’s requirements? (Select TWO.)

<ul data-question_id=”11063″ data-type=”multiple”>

[Kenneth-Samonte-Tutorials-Dojo]

Hi aparna,

Thank you for the feedback.

Amazon Lex—Let you create a chatbot to use as an Interactive Voice Response (IVR).

Amazon Polly—Provides text-to-speech in all contact flows.

Amazon Transcribe—Grabs conversation recordings from Amazon S3 and transcribes them to text so you can review them.

Amazon Comprehend—Takes the transcription of recordings and applies speech analytics machine learning to the call to identify sentiment, keywords, adherence to company policies, and more.

The correct answer is Lex, because Comprehend only works with Text based input. The question says they are receiving calls – thus voice based input.

Hope this helps.

Let us know if you need further assistance. The Tutorials Dojo team is dedicated to helping you pass your AWS exam!

Regards,

Kenneth Samonte @ Tutorials Dojo

[kaws8902]

Hello Tutorial Dojo, “Buffer the incoming customer calls to an Amazon SQS queue” is incorrect. Streamer audio uses SIP and RTP and those are not supported over SQS. There is no reference architecture showing audio packets being processed through SQS.

[ccatchings]

While you can technically store the output of an audio in an SQS message in binary format, it would most likely be limited to 15 seconds per message since SQS messages have a max size of 256kB. I’d like to see a reference architecture for this as well. How many SQS queues do you use? One per Lex bot? How do the audio packets get sent to Lex? Lambda? I’d like to see sample code for that too.

AWS Documentation actually recommends using Kinesis Video Streams to manage live audio streaming in Amazon Connect. Maybe then you could pass the streaming audio data to the Lex bot?

https://docs.aws.amazon.com/connect/latest/adminguide/access-media-stream-data.html

I think this question needs to be re-visited as the explanation contains multiple architectural gaps and creates more confusion than clarifying a solution.

[kaws8902]

Thanks @ccatchings, your explanation of 256 kB per binary packet makes sense. But it would be difficult for consumers to to reassemble the packets in the correct sequence, especially since typically SQS may have multiple consumers in parallel. At least SQS FIFO queue should be mentioned in the question. I agree that sample code/reference architecture is needed.

[Neil-TutorialsDojo]

Hi @Aparna-Bl, @ccatchings , @kaws8902

Thank you for raising your question, aparna. Following up Kenneth’s response Amazon Lex is the preferred choice for recognizing caller intent based on voice input. Amazon Comprehend, on the other hand, is more suited for text-based input. In the context of receiving calls and creating contact flows, the voice-based capabilities of Amazon Lex make it the correct solution for this scenario.

To kaws8902 and ccatchings, your concerns about SQS limitations for streaming audio data are valid. Thanks for pointing this out. In a call center setup where someone is talking directly to a Lex bot and getting immediate responses, you don’t really need SQS. Amazon Lex has its own API that you can use to facilitate the conversation between the caller and the bot. Though here’s how I imagine SQS can be used with Amazon Lex. Instead of putting the audio itself in the SQS message, we can store the audio somewhere like in Amazon S3, and just reference its URL in the message. Then, a Lambda function can pick up this message from SQS, process the audio file from S3, and subsequently invoke the Lex API for further actions.

With all that said, we apologize for any confusion this question might have caused. We really appreciate your input and will make sure to refine and improve this question based on your feedback.