O blog da AWS
Analisando avaliações de clientes com Amazon Comprehend
Por Kevin Cortés Rodríguez, Arquiteto de Soluções AWS
Quando um aplicativo ou serviço é lançado em produção, sempre pensamos em melhorias e novos recursos. Esse processo iterativo de melhoria contínua pode ser acionado pelo feedback do cliente. É importante entender o que ele não gosta, para ser capaz de melhorá-lo, e o que está agregando valor a eles para fortalecê-lo.
Às vezes, é impossível analisar os critérios e feedback de absolutamente todos os clientes, e mais quando temos milhares deles. É por isso que as empresas precisam analisar o coletivo das mensagens. E eles não só analisam tendências, mas também o “sentimento” da mensagem. Isso é uma mensagem positiva? É negativo? Qual é a percepção do usuário?
Para dizer que uma mensagem tem uma conotação positiva ou negativa, palavras e contexto devem ser analisados na linguagem apropriada. Mas não basta apenas fazer comparações e analisar se uma frase contém uma palavra “positiva”. É por isso que nos últimos anos, diferentes técnicas de aprendizado de máquina foram criadas para ter um valor mais preciso. A desvantagem é que criá-lo desde o início geralmente leva tempo, pode ser impreciso (estas são inferências que exigem treinamento prévio e um grande conjunto de dados), e até difícil para aqueles que não conhecem o assunto em profundidade.
Para evitar o atrito das desvantagens acima mencionadas, a AWS lançou o Amazon Comprehend. Este é um serviço de processamento de linguagem natural (NPL por sua sigla em inglês) que usa aprendizado de máquina para encontrar informações e relacionamentos em textos.
Nesta seção, veremos como usar o serviço Amazon Comprehend para analisar o sentimento de feedback dos clientes e graficá-los em tempo real em um painel criado com o Amazon ElasticSearch Service.
O projeto consiste em uma API Rest configurada anteriormente onde somente usuários válidos com um token podem comentar.
Se você não tiver uma API Rest configurada com o API Gateway, você pode optar por seguir o procedimento descrito no blog “Criação de aplicativos nativos no Android com a AWS”. Esse informe detalha como criar um aplicativo nativo para Android com vários serviços, incluindo Amazon API Gateway, Amazon Cognito e AWS Amplify.
O Amazon API Gateway é um serviço totalmente gerenciado que facilita a os desenvolvedores criar, publicar, manter, monitorar e proteger APIs em qualquer escala. As APIs atuam como o “gateway” para que os aplicativos acessem os dados, a lógica de negócios ou a funcionalidade de seus serviços de back-end. Com o API Gateway, você pode criar APIs RESTful e APIs WebSocket que permitem aplicativos de comunicação bidirecional em tempo real. O API Gateway oferece suporte a cargas de trabalho em contêiner e sem servidor, bem como aplicativos da Web.
A API REST terá um um método POST a /comment. É necessário para o nosso caso que o método seja autenticado, portanto, devemos configurar o Authorizer correspondente com o grupo de usuários do Amazon Cognito. Faremos isso da mesma forma que no blog para criar aplicativos nativos em Android. O Amazon Cognito permite que você incorpore com rapidez e facilidade o controle de acesso, o registro e o login do usuário.
O endpoint criado recentemente deve chamar uma função Lambda. AWS Lambda é um serviço serverless que permite executar código sem provisionar ou gerenciar servidores; criar lógica de escalabilidade de cluster baseado na carga de trabalho; manter integrações de eventos; e gerenciar tempos de execução. Esta função deve invocar 2 serviços:
- Amazon Comprehend
- Amazon Kinesis Data Firehose
Amazon Comprehend usa o aprendizado automático para ajudá-lo a descobrir as informações e os relacionamentos entre seus dados não estruturados. O serviço identifica o idioma do texto; extrai frases, nomes de lugares, pessoas, marcas e eventos chave; compreende o grau de positividade ou negatividade do texto; analisa o texto usando tokenização e categorias gramaticais; e organiza automaticamente uma coleção de arquivos de texto por tópico.
Por outro lado, Amazon Kinesis Data Firehose oferece a maneira mais fácil de fazer upload confiável de dados de streaming em data lakes, data warehouses e serviços de análise. Este é um serviço totalmente gerenciado, que é dimensionado automaticamente para se adequar ao nível de processamento de seus dados. Além disso, não requer administração contínua. Você também pode processar por lotes, compactar, transformar e criptografar fluxos de dados antes de carregá-los. Isso pode ser feito para minimizar o volume de armazenamento usado e aumentar o nível de segurança.
O objetivo final é obter métricas de positividade ou negatividade para um comentário, no nosso caso em português, utilizando o SDK do Amazon Comprehend. Depois, usando um stream do Kinesis, podemos persistir dados no Amazon ElasticSearch Service e graficar essas métricas com Kibana.
A função Lambda foi escrita em Python, embora você também possa escolher entre uma variedade de linguagens nativamente suportadas, como Java, Go, PowerShell, Node.js, C#, Python e Ruby. Para Python, você deve importar a biblioteca boto3, o SDK da AWS para esta linguagem.
import json
import boto3
client_comprehend = boto3.client('comprehend')
client_kinesis = boto3.client('firehose')
kinesis_stream_name = 'comments-sentiment-analisys-kinesis'
default_response_message = "Thanks for your review."
default_error_message = "An error happened. Please, try again later."
def lambda_handler(event, context):
post_data = json.loads(event["body"])
user_comment = post_data["comment"]
user_words = user_comment.split(" ")
user_data = event["requestContext"]["authorizer"]["claims"]
response_comprehend = client_comprehend.detect_sentiment(
Text=user_comment,
LanguageCode='pt'
);
json_response = {
"sentiment" : response_comprehend["Sentiment"],
"positive" : response_comprehend["SentimentScore"]["Positive"],
"negative" : response_comprehend["SentimentScore"]["Negative"],
"mixed" : response_comprehend["SentimentScore"]["Mixed"],
"neutral" : response_comprehend["SentimentScore"]["Neutral"],
"username" : user_data["cognito:username"],
"email" : user_data["email"],
"log_in_date" : user_data["iat"],
"comment" : user_comment,
"tags" : user_words
}
try:
response_kinesis = client_kinesis.put_record(
DeliveryStreamName=kinesis_stream_name,
Record={
'Data': json.dumps(json_response)
}
)
except:
return {
'statusCode': 502,
'body': json.dumps({
"message" : default_error_message
})
}
return {
'statusCode': 200,
'body': json.dumps({
"message" : default_response_message
})
}
A função de execução de uma função do Lambda é uma função do AWS Identity and Access Management (IAM) que concede permissão para acessar serviços e recursos da AWS. Essa função é fornecida quando uma Lamda é criada e assume a função quando ela é chamada. Como a função precisa acessar outros recursos da AWS (Comprehend e Kinesis, respectivamente), devemos conceder as permissões necessárias a esses serviços. Ao clicar no Role Name da função, você será redirecionado para o serviço IAM.
Quando esteja nas permissões de execução da função atribuída à função Lambda, você deve adicionar duas permissões: uma de gravação no Kinesis Data Firehose e uma de consulta para o Amazon Comprehend. As políticas de permissões podem ser gerenciadas pela AWS ou você pode optar por criar uma personalizada que se adapte ao seu caso de uso.
Depois que o recurso Lambda é criado, a partir do dashboard da console AWS, criamos um stream de dados usando o Amazon Kinesis Data Firehose.
Primeiro você deve definir o nome do delivery stream e, em segundo lugar, a origem dos dados. Essa fonte pode ser: fazer solicitações PUT de outros recursos; ou do Kinesis Data Stream (KDS é um serviço de streaming de dados em tempo real com alto nível de escalabilidade e durabilidade). Dado o cenário proposto, não é necessário usar o último serviço.
Outra opção a ser ativada é a criptografia do lado do servidor para registros de origem no fluxo de entrega. Você pode usar AWS Key Management Service (KMS) para criar e gerenciar chaves de cliente (CMK) e controlar o uso da criptografia em uma ampla variedade de serviços da AWS e seus aplicativos.
O Kinesis Data Firehose pode invocar uma nova função do Lambda para transformar, filtrar, descompactar, converter e processar dados de origem recebidos antes de entregá-los ao destino: Amazon ElasticSearch Service.
No nosso caso, não é necessário ter uma função de transformação, pois no ElasticSearch faremos inserções diretas no JSON que construímos na função Lambda descrita anteriormente. Por outro lado, precisamos criar um bucket S3 para processar as solicitações que, por algum motivo, não puderam ser adicionadas ao cluster do ElasticSearch.
Finalmente, precisamos adicionar o domínio de saída ElasticSearch já criado, o nome do índice e sua rotação. Se você não tiver um cluster configurado, você pode seguir o seguinte procedimento na documentação oficial. Também é importante selecionar quanto tempo uma solicitação de índice deve ser repetida em caso de falha. Documentos com falha são enviados para o bucket S3.
Kinesis é um serviço gerenciado pela AWS que não exige que você configure uma VPC, ao contrário do ElasticSearch. Este último serviço reside em uma Virtual Private Cloud (VPC), portanto, você deve configurar o fluxo de entrega para enviar dados para essa VPC e associá-lo a um security group.
Finalmente, você deve configurar as condições do buffer. Kinesis Data Firehose armazena os dados recebidos antes de enviá-los para o destino especificado. Para o Amazon Elasticsearch como destino escolhido, você pode escolher um tamanho de buffer de 1 a 100 MiB e um intervalo de buffer de 60 a 900 segundos.
Finalmente, o stream de dados está pronto para ser criado. Para testar o rastreamento da mensagem até finalmente chegar ao ElasticSearch, primeiro deve fazer um POST no endpoint da API semelhante ao seguinte:
curl --location --request POST <API-GATEWAY-ENDPOINT> \ --header 'Authorization: <JWT-TOKEN>' \ --header 'Content-Type: application/json' \ --data-raw \ '{ "comment": "É um comentário positivo!." }'
Se o resultado foi bem-sucedido, a API responderá a uma mensagem como:
{ "message": "Mensagem recebida corretamente." }
Se a mensagem chegou ao ElasticSearch com sucesso, na seção Dev Tools veremos que um índice chamado Comments-AAAA-MM-DD foi criado.
E assim que os padrões de índice forem criados, os comentários dos usuários serão visualizados na seção Discover do Kibana
Finalmente, a partir do painel esquerdo na seção Kibana, podemos criar visualizações diferentes e adicioná-las a Dashboards.
Por exemplo:
- Você pode fazer 4 visualizações mostrando os sentimentos mixed, positive, negative e neutral. Você também pode executar uma visualização em estilo nuvem de palavras, na qual o tamanho representa as ocorrências dessas palavras em comentários diferentes ou um pie chart com quantidades de mensagens também por sentimentos
Inserindo mais detalhes, você pode criar gráficos de mensagens em forma de tabela
A mesma análise pode ser feita dividida pelo usuário, dados que obtemos diretamente do token fornecido pelo usuário no momento de fazer o método POST na API. Desta forma, também podemos analisar a perspectiva da nossa aplicação segmentada pelo usuário
Uma vez que ja temos os gráficos, podemos compartilhar o URL do Amazon ElasticSearch Service para analisar em tempo real a sensação de feedback de nossos usuários para criar uma melhor experiência de usuário nas próximas versões.
Por outro lado, podemos prestar atenção personalizada a cada um dos usuários com o display segmentado por sentimento e usuário com comentários denotando uma experiência ruim.
Com os dados consolidados no Amazon ElasticSearch Service, você também pode fazer uma análise de como foi a tendência em relação as melhorias lançadas: isso aumentou a taxa de feedback positivo ou negativo, ou se as recalmações dos usuários foram ouvidas. Neste último exemplo, com a nuvem de palavras você pode encontrar tendências e filtrando por comentários negativos, você pode evidenciar pontos de falha na aplicação para fazer as melhorias necessárias. Se ao longo do tempo a palavra deixa de aparecer, de alguma forma podemos garantir que o problema foi corrigido.
O objetivo do blog é apenas destinado a receber mensagens usando a API Rest. Ao fazer as alterações necessárias, as mensagens também podem ser obtidas de diferentes fontes.
Este artigo foi traduzido do Blog da AWS em Espanhol
Sobre o autor
Kevin Cortés Rodríguez é arquiteto de soluções na AWS. Ele trabalha auxiliando e apoiando clientes do setor público em sua jornada na nuvem, trabalhando em projetos que envolvem arquiteturas escaláveis e serverless. Ele tem grande interesse nas áreas de desenvolvimento mobile, web, IOT e análise de dados.
Revisores
Cristian Castellanos é arquiteto de soluções para Amazon Web Services para o setor público. Cristian ajudou várias instituições educacionais e governamentais a adotar novas tecnologias e implementar soluções analíticas.
Lucas Vidal Claypole é gerente de contas na AWS com sede na Argentina. Atualmente trabalha com vários clientes do setor público (governo, educação e organizações sem fins lucrativos), dando suporte na implementação de soluções na nuvem e accelerando sua adoção.