Se você está acompanhando nosso TechBlog, chegou o momento de construir o seu primeiro assistente conversacional com uso de IA no ambiente Salesforce. 👏

💡 Se você ainda não conseguiu configurar o Einstein Copilot, dá uma olhada no nosso último post, que apresenta um quick-start para o EC.

No setup da org correspondente, procure por Copilots, selecione o Copilot disponível (Einstein Copilot), e na sequência clique em “Open in Builder”.

O Builder já vem pré-configurado com algumas ações que são a base para o funcionamento out-of-the-box do Einstein Copilot. Só de bater o olho nos nomes das ações, você já consegue ver que o EC oferece um conjunto poderoso de ações que podem ser vistas de forma genérica como blocos versáteis para diversas aplicações, especialmente com o uso da IA generativa.

Por exemplo, a ação de “Draft or Revise Email” trata da geração de conteúdo personalizado; a de “Summarize Record” permite consolidar informações complexas em resumos; e a de “Query Records” consegue traduzir perguntas em linguagem natural para consultas específicas ao CRM, permitindo o acesso rápido a dados estruturados.

Já as ações “Identify Object by Name” e “Identify Record by Name” envolvem a interpretação da linguagem natural, permitindo que o EC reconheça o objeto ou o registro informado pelo usuário com base em nomes ou descrições. Essa capacidade de identificação, alimentada pelas outras ações de IA generativa, garantem que os dados certos sejam acessados de forma precisa e eficiente.

Como funciona na prática

Na área do Builder, como é possível testar as habilidades de conversação do EC e ver as etapas seguidas pela IA, é fácil observar que, num primeiro momento em que é realizada a pergunta pelo usuário, o EC vai tentar nativamente “traduzir” os dados apresentados. Isto é, num primeiro momento, o EC busca identificar se o usuário está perguntando sobre um registro/objeto. Caso ele encontre algum tipo de impasse, automaticamente chama a ação de “Identify Object by Name” ou “Identify Record by Name”. No exemplo abaixo, o EC não conseguiu identificar a oportunidade a qual me referi na pergunta, por isso, vemos que ele ativa a ação de “Identify Record By Name” e me pede para explicitar o registro numa caixa de texto.

Uma vez que o EC identifica a quais dados estruturados o usuário está se referindo, ele parte para a etapa de identificar a intenção da pergunta. Neste exemplo, ele chama a ação de “Draft Or Revise Email” para criar o plano de fechamento solicitado. Como esta ação está relacionada à intenção de criação de conteúdo, da mesma forma que pode ser aplicada para escrita de um e-mail, pode ser usada para gerar planos de fechamento.

E aí você deve estar se perguntando: beleza, mas como o EC sabe a intenção da pergunta? Bem, é aí que entram as instruções das ações do Copilot Builder. Estas instruções orientam o modelo de linguagem a identificar a intenção, e executar a ação correta solicitada pelo usuário. Para isso, cada ação configurada no Copilot conta com uma série de instruções, tanto do que a ação executa, quanto das entradas e saída.

Uma boa dica é que você pode visualizar como foram configuradas nas ações nativas para referência; e o ponto chave é garantir que as instruções sejam bem testadas e otimizadas para oferecer respostas precisas e relevantes com base nas consultas dos usuários.

O help da Salesforce oferece um guia de melhores práticas na construção de instruções Best Practices for Einstein Copilot Action Instructions (salesforce.com). Em resumo, podemos dizer que:

  • A descrição da ação deve ser direta e em linguagem natural, geralmente com uma a três frases, explicando o objetivo da ação, os casos de uso e os objetos ou registros envolvidos:
    • Exemplos de perguntas do usuário também podem ajudar na descrição da ação; fornecer exemplos com variação de escolhas de palavras também são recomendadas para cobrir diferentes formas de solicitação;
    • Dependendo da ação, podem ser necessários exemplos e ações dependentes, para garantir a execução correta em sequência.
  • Instruções dos parâmetros de entradas e saída devem ser detalhadas para esclarecer o tipo de dado esperado, os campos e valores relevantes, e como os dados devem ser obtidos ou gerados.

Algumas restrições

É claro que, com as ações que comentamos acima, já é possível cobrir uma variedade imensa de perguntas que surgem numa corporação. No entanto, quando começamos a introduzir consultas relacionadas a objetos customizados, automatização de tarefas específicas, ou até mesmo definição de alguns jargões para que o EC identifique registros ou objetos conforme a linguagem da área, iniciamos o processo de customização de ações.

Você pode adicionar facilmente uma ação, clicando no “+” do painel de Actions do Copilot Builder. A criação da ação consiste em: (1) determinar qual flow/apex/prompt template será usado para o EC processar os dados do usuário e gerar a saída esperada; e (2) descrever as instruções da ação, entradas e saída para que o EC possa identificar a intenção relacionada à ação customizada.

Observe que falei “entradas” e “saída”, isto porque, já num primeiro aprendizado da nossa equipe, descobrimos que o EC não suporta mais de uma saída para uma mesma ação. Da mesma forma, ele também não suporta ações sem saída, ou seja, mesmo que você crie uma ação de automatização de uma tarefa, é importante retornar algum resultado para que o EC siga o fluxo corretamente. Então já pega essa dica, para não errar na hora de customizar seu EC. 😉

Mas vamos supor que você cometeu este erro, alterou seu flow para ajustar, e agora? Como faz para mudar na Action? A princípio achávamos que no próprio Copilot Builder já seria possível editar o registro, no entanto, nesse caso, como teve mudança na estrutura de parâmetros, você vai precisar remover a Action do Copilot Builder, e também do Copilot Actions (você encontra a tela do Copilot Actions na área de Setup). Só assim você vai conseguir remover a Action por completo e recriar uma nova a partir do mesmo flow. Pronto, já temos mais uma dica, um flow/apex/prompt builder só pode estar associado a uma ação do EC, relacionamento 1:1 de action type para action.

Além das restrições dos parâmetros, o EC também não consegue renderizar saídas que apresentem valores nulos (mesmo que seja uma lista que contém um item nulo), nem consegue rodar caso o seu flow contenha uma variável com fórmula.

E bem, por fim, o EC tem um limite de 16 ações, o que acaba restringindo a opção de ações caso você procure por um EC altamente customizável. É claro que sabemos que a Salesforce está em constante desenvolvimento, e sempre tem funcionalidade nova saindo do forno ou limites sendo quebrados. No próximo post traremos as novidades do Dreamforce. 💙

Nas referências deste post você encontra links para as documentações da Salesforce que mais nos apoiaram nessa jornada! Esperamos que possam ser úteis para você também! E se quiser compartilhar algum aprendizado, ou tiver alguma dúvida, comenta aqui no post que vamos ter o prazer de poder apoiá-lo.

Referências