Muitas pessoas acreditam que o desenvolvimento de um assistente virtual é algo complexo e demorado. Te provamos neste artigo que é possível fazê-lo em 3 dias.
Em uma terça-feira fria, umas 15:00h, eu e a Vivian (Product Owner do Colab) estávamos conversando sobre como poderíamos integrar o Asana no Slack, vendo se haviam formas mais fáceis de fazer integrações etc.
Foi aí que pensamos: E se nós não tivéssemos uma integração só com o Asana, mas fizéssemos algo que pudesse ser integrado com qualquer API e de qualquer forma para os times do Colab? Nossa mente fez isso:
Um mundo de possibilidades se desenrolava na nossa frente. Era a relação ganha-ganha perfeita:
Calma, se você não entendeu como poderíamos (e como você também pode!) fazer isso e está mais perdido que o John Travolta na casa da Mia em Pulp Ficton, vem comigo!
Ok, hora da sopa de letrinhas de tech! Primeiro numa visão macro da arquitetura, pensamos em algo simples com uma capacidade alta de escalabilidade e integrabilidade.
Senhoras e senhores, lhes apresento a arquitetura hexagonal.
Com isso em mente já tínhamos ideia de como iríamos fazer e o que usar para alcançar o objetivo.
Nós queríamos algo fluído, como se as pessoas estivessem pedindo algo para um ser real, queríamos que o quick win pudesse mostrar para a galera o potencial de uma integração mais humana com a máquina e que déssemos poder para as pessoas, mas ao mesmo tempo a máquina seria inteligente o suficiente para entender esse empoderamento da nossa equipe.
A forma mais simples que encontramos para fazer isso é juntando a API do Slack (que é nossa ferramenta básica de comunicação no Colab) com o dialogFlow. O dialogFlow é uma plataforma para a implementação de NLP (Natural Language Processing), uma das mais robustas plataformas que temos hoje no mercado, e tem implementação 100% para português - BR 💜
Dentro do NLP temos o que chamamos de intenções, que são o core do machine learning por trás do NLP, nela treinamos o modelo para dizer quais frases devem fazer quais ações, e, por trás dos panos, o dialogflow aplica o algoritmo com nome mais legal do mundo, a distância Levenshtein que retorna quanto de confiabilidade o usuário está digitando baseado nas intenções cadastradas.
Por isso, disponibilizamos alguns conteúdos mais completos que falam sobre gestão pública. Deixe o seu melhor e-mail para recebê-los!
Agora que estamos na mesma página, vamos destrinchar essas camadas para entendermos o que acontece:
Cada camada aqui é responsável por uma coisa específica:
Claro que existem outros pontos aí no meio, como as autenticações entre as camadas, mas isso é coisa simples, mais uma burocracia tech do que de fato algo legal.
A parte cool mesmo do negócio é conseguirmos integrar inputs dos usuários com a máquina e ela conseguir entender o que está sendo solicitado, captando todas as informações necessárias para executar determinada ação.
Além de tudo isso, o mais legal é que criamos somente o “miolo“ da aplicação, o que quer dizer que como os usuários chegam em nosso sistema (input) e o que ele vai fazer (output) estão em níveis abstratos da arquitetura, não precisam ser definidos agora, e podem ser definidos como sendo qualquer coisa, mais ou menos isso:
Além de aceitar qualquer canal de entrada e possibilidade de qualquer tipo de saída por se tratar de uma API estruturada, a aplicação ainda pode agir como fluxo pró-ativo para o usuário.
O que o nosso “Barackinho” (nome do nosso bot 🙃) pode fazer depende somente da imaginação, necessidade e criatividade da equipe, porque pela tecnologia transacional da qual dispomos, não temos limites.
Agora que estamos na mesma página, vamos destrinchar essas camadas para entendermos o que acontece:
Cada camada aqui é responsável por uma coisa específica:
Claro que existem outros pontos aí no meio, como as autenticações entre as camadas, mas isso é coisa simples, mais uma burocracia tech do que de fato algo legal.
A parte cool mesmo do negócio é conseguirmos integrar inputs dos usuários com a máquina e ela conseguir entender o que está sendo solicitado, captando todas as informações necessárias para executar determinada ação.
Além de tudo isso, o mais legal é que criamos somente o “miolo“ da aplicação, o que quer dizer que como os usuários chegam em nosso sistema (input) e o que ele vai fazer (output) estão em níveis abstratos da arquitetura, não precisam ser definidos agora, e podem ser definidos como sendo qualquer coisa, mais ou menos isso:
Além de aceitar qualquer canal de entrada e possibilidade de qualquer tipo de saída por se tratar de uma API estruturada, a aplicação ainda pode agir como fluxo pró-ativo para o usuário.
O que o nosso “Barackinho” (nome do nosso bot 🙃) pode fazer depende somente da imaginação, necessidade e criatividade da equipe, porque pela tecnologia transacional da qual dispomos, não temos limites.
