Vendo bots com uma visão mais profissional, pude estudar muito e principalmente: experimentar muito. Fiz diversos testes implementando chatbots com C# e Microsoft Bot Framework, sob o .NET Framework, mas também fiz bots em NodeJS, e alguns construídos direto em plataformas web. Testei inúmeras plataformas, implementei diversos fluxos de negócio e apresentei diversos exemplos para comitês, fiz apresentações gerenciais e auxilio o time de vendas da Ebix Latin America no diálogo sobre Chatbots com nossos clientes. Aprendi sobre o que os gestores esperam, entendi o que eles querem, e quais são suas principais dúvidas e expectativas. Acho que posso ajudar quem pretende entender um pouco sobre chatbots e o que há de interessante no mercado para se fazer bots.

<update 03/Out/2017>Agora já tenho implantações com .NET Core também! Embora não seja possível usar o SDK, é possível usar a API REST para fazer a integração.</update>

<update 01/Out/2017>A propósito Bot pronuncia-s: bót, e chatbot pronuncía-se chet-bót: escute.

Boot/Bôt é outra coisa!</update>

Desde quando não conhecia nada sobre chatbots até agora, aprendi muita coisa. Desde dezembro cuido de Ofertas & Inovação na Ebix Latin America, como toda a empresa, atendo exclusivamente o mercado de seguros. Assim que entrei, um mês antes, fui introduzido ao projeto de chatbots, o Wbot, que já estava em andamento, ajudei na construção do produto (e primeiro bot) e assim que assumi a área no mês seguinte, herdei o projeto e passei a ser o responsável pelo produto, e a construção da plataforma que hoje com orgulho posso dizer que fizemos. Nessa dinâmica, tenho rodei o eixo Rio-São Paulo apresentando-o para seguradoras, corretoras e quem mais do ramo de seguros tenha se interessado. Foram algumas dezenas de apresentações para os mais variados perfis: Executivos, gestores, desenvolvedores e marketers, todos apresentaram dúvidas, muitas delas comuns,  e muitas destas são exatamente as mesmas dúvidas que tive assim que entrei no projeto.

Então tomei a liberdade de escrever um pouco sobre do que os Bots são feitos, detalhando cada elemento e sua responsabilidade. Espero que ajude a esclarecer alguma coisa!

Chatbot – Um novo conceito, passível de substituir qualquer site, qualquer app, qualquer sistema

Na medida que você consegue enviar mensagens complexas como fotos, cards, geolocalização e áudio, e consegue interagir, interpretar e responder aos mais variados estímulos de uma conversa, você dá vida ao mecanismo e consegue assim substituir aplicações, sites, telefonemas por um chatbot. Mas não se anime precipitadamente, há inúmeros desafios para tornar isso real. Definitivamente não é uma tarefa nem fácil, nem rápida, e exige muito esforço e muitos testes.

Seja em um ecommerce, ou uma padaria, tudo o que você oferta ou faz com um app, site ou sistema é factível de se fazer com um chatbot. Quer exemplos?

• Solicitação de assistência
  • “Comprei uma geladeira nas lojas XXX ano passado, e hoje ao acordar percebi que quebrou durante a noite, você pode mandar um técnico ou trocar o produto?”
  • “Saí de casa, e sem querer a porta fechou, você pode mandar um chaveiro?”
• Agendamentos
  • “Preciso de um clínico geral para próxima segunda-feira”
  • “Quero agendar uma consulta hoje, quais horários disponíveis depois das 18h?”
  • “Você tem um eletricista disponível para it até minha amanhã?”
• Obtenção de Informações
  • “Eu tenho um seguro de vocês, queria saber tem cobertura para viagem?”
• Compras
  • “Quero uma pizza grande, calabresa, e uma coca 2 lts”

Esses são diálogos que substituem a necessidade de iteração com um app, site, sistema ou mesmo uma ligação para seu Call Center.

Antes de prosseguirmos, vale lembrar que “IM” é o acrônimo para Instant Messenger, aplicativos de mensagens instantâneas. Facebook Messenger, Whatsapp, Telegram e Skype são exemplos de Instant Messengers.

Quando digo que um dos produtos que oferto é a plataforma de Chatbots e explico o que podemos fazer e como podemos fazer atendimentos, vejo o brilho nos olhos e ouço recorrentes relatos sob frustrações nas relações com diversos sistemas e apps. Pacientes querem agendar consultas por IM, clientes querem solicitar taxi e uber por IM, fazer pedidos, obter informações, enfim, todo mundo quer interagir com seus serviços do dia-a-dia da mesma forma como fala com amigos e combina um almoço, via instant messengers.

Embora esteja entranhado no discurso o mindset de que os chatbots substituirão todos os demais canais, na prática isso nunca irá acontecer. Mas é bom causar esse impacto para para chamar a atenção para as possibilidades, e apresentar a realidade de que há uma gama crescente de consumidores que utilizarão unica e exclusivamente os chatbots para realizar transações e interagir com o seu negócio. Seja para agendar um banho para o seu cachorro, realizar a compra de ração, até o alerta de que seu clubinho está vencendo e precisa ser renovado.

Os Instant Messengers assumiram um espaço novo no dia-a-dia das pessoas, e passou a ser um canal otimizado para quem sabe o que quer e deseja agilidade no processo. Mas em contrapartida, chatbots serão péssimos para apresentar catálogos, pois embora não haja limitação tecnológica, há desafios de UX ainda não resolvidos. Como apresentar seu catálogo de 100 produtos em uma tela de chat? Como refinar uma pesquisa? Chatbots não entregarão uma navegação interessante para quem não sabe o que quer, mas é essencial para quem sabe. Por essas e outras que os aplicativos, sites e sistemas nunca deixarão de existir, mas os chatbots passam a ser uma alternativa muito atraente e diferencial competitivo que simplifica e descomplica algumas atividades rotineiras.

Acredito que em algum momento nos próximos anos, você encontre ecommerces que irão te mostrar o catálogo no site, e em vez de passar por um “carrinho de compras” e fechamento, te direcionem para fechar a compra no chatbot. Em vez de “Add to cart” você encontraria “Add to chatbot cart”. E então todo o resto do fluxo é finalizado em uma conversa via Facebook Messenger por exemplo.

De que é feito um chatbot?

Abaixo vou listar todos os elementos que geralmente irão compor um chatbot. Todos esses elementos são necessários para a construção de um chatbot que interaja com um negócio real, seja ele digital ou virtual. Vale lembrar que já nasceram muitas plataformas que nos ajudam a construir bots de forma mais rápida e com maior eficiência, essas plataformas assumem uma, duas ou até três dessas necessidades, então não se assuste se você encontrar em uma única plataforma 3 dos elementos que vou mostrar abaixo. A intenção é diagnosticar e dissecar os bots.

Usuário

Embora não faça parte do chatbot, é importante detalhar quem pode ser o usuário do bot. Por isso estou revisando o texto todo para reduzir a utilização do termo cliente, substituindo por usuário, pois o usuário do chatbot é aquele que conversará com o bot. Ele pode ser o cliente da sua empresa, mas pode também ser um funcionário, ou prestador de serviços, um gerente, um vendedor, e não necessariamente o cliente do seu negócio.

Canal

Um canal é uma interface de iteração com o usuário. Todo IM é um canal: Facebook Messenger, Skype, Slack, Microsoft Teams. Mas não somente de instant messengers os canais são feitos, ainda podemos usar email, sms, chats em websites, e até mesmo chats em mobile apps são considerados canais. Um canal, seja ele qualquer, possui um SDK que define o protocolo e esquema de dados suportado. Esses elementos são necessários para expressar como o dado chegará ao seu chatbot, e te informar como e o que você poderá responder.

Framework/Plataforma de Chatbot

Com os diversos canais, surge um dilema: Cada canal possui um protocolo e um esquema de dados próprio. Isso significa que para cada canal (Facebook Messenger, Telegram, Skype, Slack, Kik, Microsoft Teams) há uma forma diferente de integração. Cada um possui um SDK próprio, que define as estruturas de dados que representarão as mensagens, anexos, geolocalização e tudo mais que o canal suportar, até cards, botões, etc. O resumo desse caos é:

• Você precisa de uma integração específica para cada canal
• Você precisa ficar atento às mudanças na integração com cada canal, para que uma mudança de protocolo não te cause downtime.

Como meio de simplificar a vida de quem desenvolve, os Frameworks e Plataformas de Chatbots abstraem essa complexidade oferecendo modelos unificados e consistentes para trabalhar com diversos canais. Assim você deixa de se preocupar com os diversos canais e passa a desenvolver uma só vez, uma só integração para qualquer canal suportado por seu framework ou plataforma. Isso reduz o custo do desenvolvimento, e simplifica a gestão. O resultado é que você, com um único backend, consegue se integrar com os mais diversos canais.

Um framework de chatbot geralmente estará embarcado junto com seu backend, enquanto uma plataforma, geralmente estará hospedada na nuvem e estabelecerá um contrato para que você construa uma API para receber as iterações no seu backend. O Microsoft Bot Framework é um bom exemplo de plataforma de bots, enquanto o BotPress é um exemplo de framework.

API, Bot API ou  Backend, chame como quiser

Seu bot já está apto para trabalhar com diversos canais, mas você precisa dar vida a ele. Precisa realizar operações de negócio, executar efetivamente o que o usuário pediu em um comando, ou entregar uma informação solicitada. O backend é responsável por responder às diversas iterações do usuário. Para isso você precisa criar uma API, hospedar em qualquer lugar público e configurar a plataforma ou canal para que ao receber uma iteração do usuário, sua API receba uma requisição HTTP contendo os detalhes da iteração. Nessa requisição todos os dados da conversa e da nova iteração estarão presentes.

O backend é quem dá vida ao bot. Em bots complexos, essa camada tem papel de integra-se com diversos sistemas da companhia, executar tarefas complexas.

Algumas plataformas exigem que a resposta à iteração seja síncrona (modelo passivo), então no Response HTTP você precisa devolver um objeto, json, no formato esperado pela plataforma ou canal em questão. Essa resposta pode representar uma mensagem de texto, e será enviada para o chat do usuário, mas também pode conter algo mais complexo, como um card, uma imagem, uma coordenada. Tudo depende do que o canal, framework e/ou plataforma suporta.

Outras plataformas oferecem suporte a respostas assíncronas, onde em vez de determinar a resposta a uma iteração no Response HTTP, você pode fazer um Post HTP para um endpoint, passando um objeto json em um formato pré-estabelecido, que possibilitará que a mensagem chegue à janela de conversação do usuário. Nesse modelo, chamado de ativo, você consegue enviar mensagens a qualquer momento, o que é um diferencial relevante dependendo da estratégia de negócio.

Fica a cargo do backend analisar o que o usuário disse com o texto/imagem/coordenada que enviou, e acessar serviços externos para isso. Também é responsabilidade dela analisar o que fazer com a informação, se é um comando, ou uma resposta a uma pergunta. Os frameworks de conversation ajudam nessa tarefa. Em geral, plataforma de NLP oferecem também conversation, é o modelo mais comum, presentes em WIT.AI e API.AI, respectivamente do Facebook e Google.

Serviços de Negócio

Seu backend recebeu uma mensagem, e uma vez que sua API(backend) descobriu a tarefa de negócio a ser realizada, você precisa consumir serviços de sua empresa. Seja para descobrir se um CPF está na sua base de clientes, ou obter dados de uma apólice, até validar os 4 dígitos de um cartão de crédito. Sua empresa precisa fornecer API’s para que o Backend possa percorrer os fluxos de negócio que dependem de informações que não estão sob o domínio do chatbot.

Por incrível que pareça, muitas vezes gestores esquecem dessa necessidade, ou consideram responsabilidade do desenvolvimento do bot. E não é. Não é pois exigem conhecimento e compreensão das tecnologias, padrões e toda a complexidade da empresa que deseja implantar o bot. É papel da TI do cliente, fornecer as API’s de negócio que suportem o bot. Quando não, esse é um mini projeto, contratado em conjunto com o bot, ou separado, mas implica em horas adicionais exclusiva para a criação das API’s.

Serviços Tecnológicos

No tópico anterior mostrei os serviços de negócio, aqueles que entregam funcionalidade, mas em algum momento precisamos de serviços que entreguem melhor compreensão sobre os dados enviados pelo usuário. Desde usar as api’s do google para analisar um endereço informado, e determinar se aquilo é detalhado o suficiente para enviar um reboque para o local, por exemplo, ou para analisar uma imagem e determinar se há um veículo nela, no caso de um aviso de sinistro. Todos esses são cenários em que você precisa de ajuda tecnológica para chegar a alguma conclusão. É difícil não encontrarmos nenhuma necessidade dessas em um bot. Seja uma análise cognitiva, sob uma imagem, uma análise de sentimento, ou compreensão de dados complexos, sempre usamos um ou mais serviços desses em nos chabots.

NLP

Processamento de Linguagem Natural ou NLP (do inglês Natural Language Processing) é uma tecnologia que analisa escrita em linguagem natural e transforma em estruturas tecnologicamente utilizáveis. Transforma uma sentença textual (dado) em informação (intenção e entidades). Parece complexo mas não é tão complexo assim, mas é diferente do que conhecemos habitualmente.

Se as intenções expressam funcionalidades, entidades expressam parâmetros para a execução de uma funcionalidade. Assim vamos dizer que eu queira fazer um bot que possibilite a realização de pedidos de uma pizzaria. Eu preciso cadastrar na plataforma de NLP, todas as Entidades usadas nas diversas Intenções possíveis, e as principais desse caso são, tamanho da pizza, sabor e tipo de massa.

Entidades:

TamanhoPizza: brotinho, média, grande e gigante

SaborPizza: mussarela, calabresa, presunto

Massa: fina, normal

Essas entidades precisam ser cadastradas, de forma a servir à base de conhecimento do bot. Depois criamos as intenções, onde determinamos frases e sentenças que usarão essas entidades para expressar essas intenções.

Intenções:

Eu quero uma pizza calabresa, média, massa fina.

Eu quero uma pizza calabresa, média

você tem pizza calabresa

me dá uma pizza massa fina, calabresa, média.

Na intenção, cadastramos variações da forma de pedir, variações de linguagem, formas, sentenças completas, parciais, tudo o que podemos alimentar a NLP sobre as variadas formas de realizar um pedido. Entregamos para a NLP quais são as Entidades de cada uma dessas sentenças. Assim ensinamos a NLP e começamos a conseguir interpretar textos completos, textos simples e incompletos. No caso das sentenças incompletas, precisamos levar em conta quais são os requisitos da intenção (intent). No nosso exemplo de pedido de pizza, todas as 3 entidades são obrigatórias, e portanto quando a sentença não apresentar alguma dessas entidades, é necessário realizar uma pergunta que faça o usuário informar qual é o valor para a Entidade que não está preenchida. Esse fluxo é chamado de Conversação (Conversation), e abordarei a seguir.

Um dos pontos interessantes para a compreensão da intenção está na linguagem utilizada. A inteligência artificial entra na compreensão semântica das suas intenções, permitindo que sentenças diferentes e nunca vistas por sua plataforma sejam reconhecidas nas suas intenções correspondentes, assim como nós humanos fazemos:

Exemplo:

Eu quero pedir uma pizza

Me vê uma pizza por favor

Eu quero uma pizza

Todas as sentenças acima expressam a mesma intenção: realizar um pedido de pizza. É importante não usar NLP’s em outra linguagem para que você não tenha uma NLP ignorante a respeito da sua língua. As sentenças acima representam uma única intenção, no entanto, no dia-a-dia de conversação podemos encontrar milhares de variações e a compreensão sobre a língua em questão faz toda a diferença para que você não precise apresentar todas as sentenças possíveis, o que é humanamente impossível. Assim, a escolha da NLP tem total relação com a assertividade no processo de compreensão de linguagem natural, que pode ser boa ou ruim.

Conversation

Como intenções expressam funcionalidades e entidades, parâmetros, precisamos nos preocupar com alguns aspectos de uma conversa, como o não preenchimento de uma entidade obrigatória para uma determinada intenção. No nosso cenário de exemplo como lidar com ter somente 2 dos 3 dados necessários para realizar o pedido da pizza. Nas plataformas ou frameworks de conversation você define requisitos (quais entities são obrigatórias para uma intent) e como você irá “Perguntar/Pedir” o preenchimento de cada dado faltante ao usuário. Como Conversation e NLP andam lado-a-lado, praticamente todos as plataformas de NLP oferecem a feature de conversation, e é essa feature que torna a dinâmica mais fluida, pois na mesma interface onde você definiu as intents e entities obrigatórias você encontra locais para cadastrar quais perguntas devem ser feitas para cada entity não preenchida.

Abstrato? Um pouco, mas vamos supor que seu bot de pedido de pizza receba a mensagem “Eu quero uma pizza calabresa, média“. Até onde vimos é possível inferir que falta descobrir o tipo de massa. Ao repassar a mensagem para o o serviço de NLP/Conversation, o serviço deverá responder com uma pergunta: “Qual é a massa?” (você cadastrou essa pergunta), então basta encaminhar isso de volta para o chat. Simples assim. Na hora que o usuário responder, “massa fina” você reenvia essa mensagem para o serviço de NLP/Conversation que recordará (por causa da feature de conversation) das duas outras opções escolhidas segundos antes. Agora, com a intenção e todas as entidades obrigatórias preenchidas, o Conversation Framework lhe responderá e com o resultado que expressa a Intent e as Entities preenchidas, prontas para fazer o que você quiser. A resposta será um conjunto de dados contendo Intent e valores de Entity em formado de chave/valor.

Nesse ponto, você sabe que pode chamar o serviço de negócio que realizará efetivamente o pedido da pizza.

O diagrama de seqüência abaixo tem o papel de demonstrar todo esse fluxo:

Variações

O fluxo que apresento acima é um fluxo completo, um dos modelos mais profissionais, pois te dá autonomia e flexibilidade, embora seja mais extenso. Há bons motivos para isso, principalmente por seu Backend estar posicionado antes das API de NLP e Conversação. Mas os motivos, eu vou falar somente no hangout do Canal.NET.

A forma como apresentamos acima, eu tenho usado com o Google API.AI, Facebook WIT.AI, IBM Watson e Microsoft LUIS.  É um modelo flexível em que posso escolher a plataforma de Convesation/NLP que mais me interessar, caso a caso. Mas existem modelos mais simples, bons para aprender.

Há outras perspectivas e fluxos disponíveis com diversas plataformas. Um deles é excelente para criar bots pessoais, acadêmicos ou mesmo para avaliação da tecnologia. Por exemplo, com o API.AI é possível você integrar NLP e Conversation direto com os canais, sem a necessidade de uma plataforma de bots externa, nesse modelo, você ainda precisa de uma Backend API, mas ela só recebe um Request HTTP quando uma intent tem todos as suas entities obrigatórias preenchidas. Todo o fluxo de mensagens é controlado pelo API.AI, e você só fica responsável por implementar o endpoint que recebe a chamada final que realizará a tarefa de negócio e dará uma resposta json no response da requisição. Simples né. No API.AI isso é chamado de FullFilment, onde você define o webhook, e precisa ter apenas um endpoint REST para tudo funcionar. Outra feature do API.AI é a capacidade de você mesmo processar a compreensão do texto do usuário, fazendo um bypass sobre a NLP. Isso é útil quando você recebe um CPF, ou um número de nota fiscal, por exemplo. São features muito interessantes e estão aí para nos ajudar a criar bots realmente reais e funcionais.

Conclusão

Esse não foi um tutorial, foi uma apresentação dos elementos necessários para a construção de Bots reais, e uma série de elementos que serão necessários para você aprender a criar bots. Há diversas plataformas que assumem uma, duas ou mais responsabilidades, deixando sua vida mais simples. Não ignore features importantes! Muitas vezes dá mais trabalho fazer da forma certa, e fazer escolhas erradas geralmente custam caro.

Se for fazer algo profissional use o Microsoft Bot Framework para interação com os canais, há segredos nessa escolha, features que hoje são praticamente exclusivas dele. Você não vai se arrepender, mesmo que seu bot não seja Node ou .NET (para esses dois, tem sdk) e use API REST com algum esforço manual de configuração. Se estiver curioso, entra no Telegram do Grupo Arquitetura de Software | .NET, que te respondo.

Update 28/01/2019

 

https://www.facebook.com/gcp/videos/401886870618567/

 

 

Convites

Gostou do post? Gostou do conteúdo?

Então tenha assistir ao bate papo sobre Bots “Desenvolvendo Bots” no Canal.NET.

 

O evento já passou mas o hangout está aqui, disponível para você assistir a qualquer momento.

 

Conheça o WBOT

Em novembro de 2016 começamos um projeto chamado WBOT que consiste em uma plataforma de chatbots dedicada ao mercado de seguros. Entrei no projeto quando ainda se tratava de um único chatbot, e ao longo de 2017 transformei o projeto em uma plataforma de relacionamento repleta de recursos interessantes entre eles:

• NLP Agnóstica
  • Google Api.ai
  • Microsoft LUIS
  • Microsoft QnA
  • IBM Watson
  • Facebook Wit.ai
• Computer Vision Agnostic
  • Google Cloud Computer Vision
  • IBM Watson
  • Microsoft Cognitive Services
• Location Services
• Multiplos Chatbots em múltiplos canais
• Interface Web de Atendimento
• Redirecionamento automático
• Filas de atendimento
• Geração Ativa ou Passiva de Protocolos de atendimento
• Webhooks
• API’s
• Custom & Complex Flows
• Fácil de implementar, fácil de customizar
• Histórico de Conversação (rico)
• Suporte nativo a iterações não textuais:
  • Cards
  • Botões
  • Carrousel
  • Adaptative Cards
• Escalável e Confiável
  • HA Always On com RabbitMQ, .NET Core e Docker
• Container First design com Docker
• Diversos modelos de contratação:
  • SaaS
  • IaaS
    • Public Cloud
    • Private Cloud
    • On Premise

Saiba mais sobre o wbot