Antes de trocar o assistente, audite a base de conhecimento

Quando um assistente responde errado, a primeira providência costuma ser trocar de modelo. Contratar outro fornecedor, subir a versão, aumentar o contexto. Na maioria dos casos que a gente auditou, o modelo tinha pouca culpa. O material que ele consulta é que não respondia.

O sintoma é sempre o mesmo: o assistente responde em segundos, com texto bem formatado, e o passo três manda o cliente para um menu que não existe. O analista confere, percebe o erro, e a partir daí deixa de usar a ferramenta. Não por causa de um erro, mas porque perdeu a confiança no conjunto.

O que uma auditoria costuma encontrar

Numa base em produção, com milhares de verbetes e busca em funcionamento:

• 83% dos verbetes sem a seção que resolve o problema, aquele “como resolver” que transforma informação em ação.
• Um terço dos assuntos com duas ou três versões ligeiramente diferentes do mesmo texto.
• Cerca de 300 verbetes vazios e 122 com mais de 40 KB, grandes demais para caber numa consulta.
• Resíduo de conversa de atendimento dentro do conteúdo, e às vezes um dado que não devia estar ali.

Nada disso aparece num painel. O painel mostra volume de consultas, tempo de resposta, uptime. A base tem bom aspecto, e o bom aspecto é o disfarce.

Por que a base fica assim

Raramente é descuido de quem escreve. Aparece por decisões que, quando são tomadas, parecem as mais sensatas.

O caminho mais natural é pedir à IA para gerar conhecimento a partir dos chamados resolvidos. Faz sentido, porque o caso tem pergunta e resposta. O problema é o que acontece quando o chamado não traz o caminho completo. A IA completa com o que o sistema costuma ser, e o que o sistema costuma ser está quase sempre certo. Isso produz uma resposta plausível, que passa numa revisão rápida e só aparece quando o cliente reclama.

Outro hábito que parece organizado é agrupar o conhecimento depois de gerar, em vez de antes. A duplicação parece um problema de arrumação. Na prática, estraga a recuperação. O assistente traz os cinco ou dez trechos mais parecidos com a pergunta, não a base inteira. Se cinco deles são variações do mesmo assunto, sobra pouca vaga para o texto que tem o caminho. E a fragmentação costuma cortar justamente a parte útil: uma versão tem o sintoma, outra tem a causa, a terceira tem o passo a passo, e o que entra no contexto é a que mais se parece com a pergunta, quase sempre a do sintoma.

Sobra a etapa de limpeza, que remove saudação, assinatura e repetição, e que precisa de existir. O problema é quando não distingue ruído de contexto: numa amostra de perguntas reais, 72,7% traziam a identificação do cliente no corpo do texto, e em 98% desses casos a limpeza apagava essa identificação. Para a rotina era sujeira. Para quem responde era o dado que define a resposta, porque muda o plano, a integração e a configuração.

O resultado é o comportamento que mais irrita qualquer equipe de suporte: o assistente pede de volta o que a pessoa acabou de colar.

O que o modelo faz com uma base assim

O assistente busca os trechos parecidos e responde a partir do que recebeu. Se o trecho traz o sintoma e não o caminho, ele tem duas saídas: dizer que não sabe, ou preencher. Preencher é o que o texto pede, e é o que qualquer pessoa faria ao escrever uma resposta completa.

A invenção, na prática, é uma lacuna da base preenchida com conhecimento geral do domínio. Por isso trocar de modelo melhora pouco: o novo também vai preencher. O que muda o resultado é a lacuna deixar de existir.

O teste de meia hora

Dá para saber em que ponto está a sua base sem projeto, sem integração e sem fornecedor novo.

Sorteie 20 verbetes de módulos diferentes. Para cada um, tente responder qual problema ele resolve, onde está o passo que resolve e qual é a fonte de cada passo. Se não conseguir dizer o problema em uma frase, é sinal. Se o passo não existe, é enfeite por melhor que seja o título. Se existe mas você não sabe de onde veio, foi inventado em algum momento.

Abaixo de 50% de aprovação, a base precisa ser reconstruída, porque remendar mantém o método que produziu o defeito. Entre 50% e 80%, dá para operar por módulo, refazendo os piores assuntos. Acima de 80%, o conteúdo está bom e o problema está na recuperação: filtro, duplicação, contexto do chamado.

O que a gente faz com isso

Numa base que auditamos em setembro, a reconstrução levou a 4.397 verbetes aprovados a partir de 44 mil fontes, com agrupamento antes da geração e um crivo automático como porteiro: verbete que não passa é refeito, nunca corrigido à mão. Tamanho de base não diz nada sozinho.

A diferença entre um verbete de enfeite e um que trabalha vê-se em duas linhas. O de enfeite diz “verifique as configurações do sistema e tente novamente; se persistir, fale com o suporte”. O outro diz que a rejeição 610 acontece quando um campo específico vem com o valor errado, que valores ele aceita e o que fazer antes de reenviar. O primeiro pode ser escrito por qualquer pessoa do ramo sem olhar chamado nenhum. O segundo só existe se alguém foi buscar o que o chamado dizia.

A recuperação foi o que mais melhorou: o verbete certo apareceu em primeiro lugar em 94% das perguntas de origem, e em 100% entre os três primeiros depois do agrupamento por assunto.

Depois disso, o copiloto que consome essa base passou a ser avaliado caso a caso pelos próprios analistas, e a fatia de respostas que eles consideraram usáveis subiu de 14% para 33% em quatro meses. Nenhuma dessas duas coisas aconteceu por causa de um modelo melhor.

Se o assistente responde e ninguém confia nele, comece por aqui

Antes de contratar ferramenta nova, meça a base que você já tem. É o que a gente faz no diagnóstico: trinta dias de conversas ou uma amostra dos chamados encerrados, o mapa das lacunas da base e a lista do que dá para automatizar primeiro. Você fica com os números, mesmo que não siga com a gente.

Se a base estiver acima de 80%, a boa notícia é que o problema é mais barato do que parecia.

Para a equipe de suporte que pergunta por dentro, o caminho é o Copiloto N1.