O que é necessário para criar uma IA que funciona realmente no apoio ao cliente (Perspetivas do responsável de IA da Hiver)

Perspetivas do responsável pela AI da Hiver

A maioria das pessoas parte do princípio de que criar funcionalidades de AI para uma plataforma de atendimento ao cliente se resume a planeamento, execução e lançamento.

Mas, se falar com as pessoas que trabalham nos bastidores, perceberá como a realidade é verdadeiramente diferente.

Anurag Maherchandani, responsável pela AI na Hiver, é uma dessas pessoas. Na Hiver, uma plataforma de atendimento ao cliente com tecnologia de AI utilizada por mais de 10 000 equipas de suporte para gerir conversas com clientes em grande escala, a pressão para "adicionar AI" surgiu cedo e com grande intensidade. Cada caixa de entrada, cada pedido e cada interação com o cliente pareciam candidatos naturais à automatização.

Anurag lidera todas as iniciativas de AI da Hiver, o que significa que é responsável por decidir o que criar, como o criar e por que motivo isso deve ser importante para os clientes. Eis a sua perspetiva sobre o que é realmente necessário para criar funcionalidades de AI que funcionem.

Comece pelo resultado, não pelo modelo

O princípio fundamental por detrás de todas as decisões relacionadas com AI na Hiver é o seguinte: A AI não é o produto. O resultado é o produto.

Na prática, isto significa que o ponto de partida para qualquer funcionalidade de AI nunca é "o que pode este modelo fazer?" É antes "onde estão os seres humanos a passar tempo a tomar decisões que não deveriam ter de tomar?"

Essa distinção molda tudo o que se segue, desde a seleção do problema até à forma como a funcionalidade é apresentada na interface de utilizador.

"Quando as equipas dizem que estão a 'criar um produto de AI', normalmente querem dizer que integraram um modelo, o disponibilizaram através de uma interface de utilizador e alcançaram elevados níveis de precisão. Mas nada disso garante valor. Os utilizadores não compram inteligência. Compram alívio: do trabalho repetitivo, da incerteza e da fricção operacional," afirma Anurag.

Mesmo que um modelo pareça excelente nos testes, o verdadeiro teste decisivo é saber se tem ou não impacto na forma como os utilizadores trabalham.

Inferência ou regras: escolha primeiro a ferramenta certa 

Antes de qualquer problema chegar à fase de seleção do modelo ou avaliação dos dados, há uma questão mais fundamental: Isto requer realmente inferência?

Inferência significa que o sistema precisa de generalizar a partir de padrões que não viu explicitamente, tomando decisões que não podem ser totalmente previstas antecipadamente.

As regras significam que a lógica pode ser escrita explicitamente: se X, então Y. As duas abordagens não são intercambiáveis e recorrer à inferência quando as regras seriam suficientes acrescenta custos, latência e imprevisibilidade sem qualquer benefício.

Quando a equipa da Hiver precisou de configurar o encaminhamento de e-mails provenientes de segmentos específicos de clientes, como contas VIP, determinados setores ou domínios específicos, o impulso inicial foi criar um modelo de AI capaz de os identificar automaticamente.

Em vez disso, a Hiver criou objetos de regras configuráveis. Estes utilizam lógica explícita baseada em domínios, palavras-chave e metadados. O resultado é previsível, fácil de depurar e configurável pelos utilizadores finais, sem envolver a equipa de AI da Hiver.

Por exemplo, se uma empresa quiser que todos os e-mails provenientes de @enterprise.com ou as mensagens que contenham a palavra “contrato” sejam encaminhados para uma caixa de entrada prioritária, pode configurar uma regra em poucos minutos. Isto não requer AI e não existe qualquer ambiguidade na forma como os e-mails são tratados.

Como afirma Anurag: "Se consegue escrever as regras, escreva as regras. Reserve a AI para problemas em que seria impossível enumerar as regras, em que precisa que o sistema generalize a partir de padrões que não viu explicitamente."

Avaliar problemas que requerem realmente inferência 

Quando um problema requer genuinamente inferência, a Hiver avalia-o segundo quatro critérios antes de avançar com a sua criação:

1. Frequência. A IA implica custos adicionais reais: custo de inferência, latência acrescida e modos de falha imprevisíveis. Esses custos só fazem sentido quando a tarefa é suficientemente frequente para que a automatização se acumule. Uma tarefa que ocorre algumas vezes por semana raramente justifica a complexidade. Uma tarefa que os agentes executam centenas de vezes por dia justifica-a.
2. Previsibilidade. Algumas classificações dependem de informações presentes nos dados de entrada (conteúdo do e-mail, linha de assunto, metadados), em vez de aprenderem com os dados disponíveis. Outras dependem de contexto que o modelo simplesmente não possui: nível do cliente, políticas internas de encaminhamento, discernimento dos agentes desenvolvido ao longo do tempo. Antes de se comprometerem com o desenvolvimento, as equipas realizam verificações de viabilidade com base em dados históricos para determinar se uma previsão é sequer possível com um nível de confiança útil. Se o sinal não estiver presente, nenhuma decisão de arquitetura altera esse facto.
3. Procura dos clientes. Isto resolve um problema que os clientes identificaram ou um problema que a equipa presumiu que tinham? A primeira opção tem uma probabilidade de adoção muito maior. A segunda tende a produzir funcionalidades que funcionam bem, mas que são ignoradas quando chega o momento de as adotar.
4. Riscos e reversibilidade. O que acontece quando o modelo erra? Uma etiqueta classificada incorretamente, que um agente corrige com um clique, tem um perfil de risco muito diferente de uma resposta enviada por engano a um cliente ou de um encaminhamento não efetuado. As previsões de baixo risco e facilmente reversíveis são fortes candidatas à automatização. As decisões de alto risco precisam de revisão humana ou de limiares de confiança significativamente mais elevados antes de serem acionadas.

A funcionalidade de etiquetagem automática do Hiver funciona porque cumpre os quatro critérios. Utiliza um modelo para inferir a etiqueta mais relevante para uma conversa recebida. Os agentes não têm de categorizar manualmente cada pedido.

As equipas definem um conjunto de etiquetas no painel de administração, como “Faturação” ou “Suporte técnico.” Estas funcionam como alvos de previsão. O modelo aprende padrões a partir do conteúdo do e-mail, da linha de assunto e dos metadados. Só são incluídas etiquetas com sinais claros.

Os agentes executam esta tarefa em praticamente todas as conversas, o que faz dela uma tarefa de alta frequência. O sinal está presente no conteúdo do e-mail relativamente às etiquetas incluídas, o que a torna previsível. Os clientes do Hiver pediram explicitamente a redução da triagem manual, o que impulsiona a adoção. Quando o modelo erra, a etiqueta pode ser corrigida com um clique, mantendo os riscos baixos e tornando o processo reversível.

A análise de sentimentos segue o mesmo padrão. Analisa o tom de cada conversa para identificar se um cliente está frustrado, neutro ou positivo. As equipas observam este aspeto em todas as conversas, pelo que é uma tarefa de alta frequência. O tom está presente no texto, o que o torna previsível.

As equipas querem ter visibilidade antecipada sobre os clientes frustrados, o que cria uma procura clara. Se o modelo errar, os agentes podem substituí-lo sem afetar o resultado, mantendo o risco baixo.

Testes de viabilidade antes do desenvolvimento

Uma das partes que exige mais disciplina no processo do Hiver: realizar testes de viabilidade da precisão antes de escrever qualquer código de produção.

A funcionalidade de sugestão de etiquetas é um exemplo elucidativo. Por exemplo, se um e-mail disser “Foi-me cobrado duas vezes,”, o modelo deverá escolher “Faturação.” Mas também estava a tentar escolher etiquetas como “Cliente VIP” ou “Encaminhar para o gestor,” que não podem ser inferidas apenas a partir do e-mail. A precisão era baixa e os agentes deixaram de confiar no resultado.

O problema subjacente era a incapacidade de distinguir entre tipos de etiquetas previsíveis e imprevisíveis. As etiquetas de categoria, como "Faturação," "Suporte técnico," e "Devoluções", correspondem a padrões linguísticos no conteúdo dos e-mails. São suscetíveis de aprendizagem.

As etiquetas operacionais, como "Cliente VIP," "A aguardar o departamento jurídico," e "Encaminhar para o gestor", dependem de contexto externo aos dados de entrada: histórico da conta, regras empresariais internas e coordenação entre equipas. Nenhum modelo treinado com e-mails de clientes conseguirá prevê-las de forma fiável.

A solução foi estrutural: antes de qualquer tipo de etiqueta ser incluído como alvo de previsão, passa por uma verificação de viabilidade. Os dados históricos permitem prever este resultado de forma fiável? Caso contrário, é excluído do âmbito do modelo, independentemente da utilidade teórica da automatização dessa etiqueta.

"A disciplina de dizer 'este tipo de etiqueta não é um bom candidato à automatização' foi mais difícil do que desenvolver o modelo. Mas isso significou que só disponibilizámos previsões em que os agentes podiam confiar."

Integrar a IA no fluxo de trabalho, não colocá-la por cima dele

A posição da IA no produto é tão importante como aquilo que faz. 

Uma funcionalidade que faz com que os utilizadores parem, escrevam um comando e verifiquem o resultado antes de agir acrescentou um passo ao fluxo de trabalho, em vez de remover um. Isso tem um efeito líquido negativo, mesmo quando a IA é precisa. Os utilizadores que trabalham rapidamente, tratando de pedidos sucessivos, contornarão tudo o que interrompa esse ritmo. 

A direção de design que funciona: uma IA que atua antes de o utilizador precisar de pensar nisso. Com o Hiver: 

• Os e-mails são etiquetados antes de os agentes os abrirem.
• O sentimento é calculado e assinalado antes de um agente abrir a conversa: um cliente frustrado já apareceu no topo da fila.
• A ordenação da fila reflete os sinais de prioridade sem que os agentes tenham de configurar nada.
• Os rascunhos de resposta aparecem integrados como sugestões.
• Os casos em que a confiança do modelo fica abaixo de um determinado limiar são encaminhados para análise humana, em vez de ser tomada automaticamente qualquer medida.

A interface não foi concebida em torno de pedir ajuda à IA. Os agentes não precisam de a ativar. Os e-mails são etiquetados e priorizados antes de os abrirem. A IA elimina o esforço antes de o agente ter de pensar nisso. 

A medida interna para avaliar se isto está a funcionar: "Se os utilizadores repararem na IA, provavelmente concebeu-a mal." 

Quando funciona, os utilizadores deixam de mencionar a funcionalidade de IA. Falam de tempos de resolução mais rápidos, de uma menor acumulação de pedidos e de uma integração mais fácil dos novos agentes. A IA deixou de ser visível para passar a ser estrutural.

A precisão e a confiança são problemas diferentes

Um sistema pode atingir 95% de precisão e, ainda assim, falhar em produção se os utilizadores não tiverem uma noção mental fiável de quando irá errar.

A confiança nasce da previsibilidade e do controlo. Os utilizadores precisam de compreender suficientemente bem o comportamento do sistema para saberem quando podem confiar nele e quando devem substituí-lo. Se não conseguirem desenvolver esse modelo, deixarão de utilizar a funcionalidade ou deixarão de verificar os resultados, sendo ambas situações de falha.

A abordagem do Hiver consiste em tornar a correção uma parte fundamental do design, em vez de uma solução de recurso para os erros. Os agentes podem substituir qualquer previsão com um único clique. O sistema regista as edições como sinais de feedback. Os limiares baseados no nível de confiança determinam o que é aplicado automaticamente e o que é encaminhado para análise.

Nas palavras de Anurag, "Em vez de tratarmos as substituições como falhas, concebemo-las como funcionalidades. Isto mantém os agentes no controlo e cria um ciclo de aprendizagem sem nunca treinarmos com dados dos clientes. O sistema melhora ao observar os resultados."

Isto também resolve um problema relacionado com os dados. Como as correções regressam sob a forma de sinais de feedback, o modelo melhora através dos resultados observados, sem exigir acesso aos dados brutos dos clientes.

O limite de privacidade mantém-se intacto enquanto o sistema se torna mais preciso ao longo do tempo.

Duas perguntas antes de lançar qualquer funcionalidade de IA

Antes de aprovar qualquer nova funcionalidade de IA, há duas perguntas:

"Se esta funcionalidade fosse removida amanhã, os utilizadores iriam reclamar?"

Se a resposta for não, a funcionalidade é útil, mas não essencial. Ainda não alterou a forma como as pessoas trabalham. É esse o objetivo que vale a pena atingir.

"Esta funcionalidade reduz uma decisão ou cria uma nova?"

Se os utilizadores tiverem de decidir se devem confiar na IA, configurá-la ou interpretar os seus resultados antes de poderem agir, a IA acrescentou carga cognitiva em vez de a remover.

Isso é uma falha, independentemente do desempenho técnico.

O verdadeiro trabalho por detrás das funcionalidades de IA

Criar uma IA que funcione em produção tem menos a ver com a seleção do modelo e mais com a seleção do problema, os testes de viabilidade e a conceção tendo em conta a forma como as pessoas realmente trabalham. A própria IA é a parte mais pequena do problema. 

"O produto nunca foi a classificação, a análise de sentimentos, a criação de rascunhos ou o resumo. O produto consistia em menos decisões por agente, resultados mais rápidos, menor carga cognitiva e operações escaláveis. A IA era o mecanismo, e um mecanismo só funciona quando é aplicado ao problema certo, com dados que sustentam efetivamente a solução."

Se está a pensar onde é que a IA se enquadra nas suas operações de apoio ao cliente, fale connosco no Hiver. Mostramos-lhe como podemos ajudá-lo a prestar um apoio empático.