Como evito que meu agente de suporte de IA alucine?

O que "alucinação" realmente significa para um agente de suporte

Uma alucinação é quando o modelo afirma algo falso com a mesma confiança que afirma algo verdadeiro. Os grandes modelos de linguagem funcionam prevendo as palavras mais prováveis, então quando não têm uma resposta real à frente, não param. Produzem uma resposta fluente, plausível e completamente inventada. Isso não é um bug que você pode corrigir, é como a tecnologia subjacente funciona.

Em um chatbot genérico, uma alucinação é incômoda. No suporte, é cara. Seu software de atendimento ao cliente com IA está falando pela sua empresa, para um cliente, muitas vezes sobre dinheiro, contas ou promessas que agora você tem que cumprir. Já vi um bot com tom confiante dizer tranquilamente a um cliente algo que simplesmente não era nossa política, e o custo não era a frase errada, era o ticket de acompanhamento, o golpe na confiança e o humano que teve que desfazer o dano.

Um de nossos clientes, uma equipe dinamarquesa de telemática veicular que gerencia suporte no Zendesk, vivenciou a versão mais clara disso. Sua base de conhecimento dizia "suportamos todos os modelos", então quando um cliente perguntou sobre uma marca de carro que não estava em seu banco de dados, o agente confirmou alegremente. O modelo não estava quebrado. Ele leu o que lhe foi dado e respondeu com confiança. O problema estava em o que era permitido ler e se era obrigado a ser honesto sobre suas fontes.

É esse o jogo todo, e é por isso que o restante deste artigo é sobre a configuração, não sobre o modelo.

A resposta honesta: impeça que a resposta errada seja enviada, não que o modelo pense

Esta é a mudança de perspectiva que a maioria dos conselhos sobre "como parar alucinações de IA" perde. Você não vai conseguir um modelo que nunca gere um token errado. Perseguir isso é uma batalha perdida. O que você absolutamente pode fazer é construir uma série de portões para que uma resposta errada seja interceptada antes de ser enviada.

Pense nisso como defesa em profundidade. O modelo rascunha algo. Antes que esse rascunho se torne uma resposta que um cliente lê, ele passa por ancoragem, uma verificação de citação, uma verificação de confiança e, quando necessário, um humano. Basta um portão detectar o problema.

Por que isso importa: uma única resposta comprovadamente errada destrói a confiança do cliente em todas as outras respostas do agente, não importa quão boas sejam as demais. Portanto, o objetivo não é um modelo perfeito, é um sistema onde o pior caso é "a IA não diz nada" em vez de "a IA diz algo errado". Vamos construir isso.

A configuração que realmente evita que uma IA de suporte alucine

Alimente-o com suas respostas reais, não com a internet aberta

O primeiro e maior fator é a ancoragem: o agente deve responder apenas a partir do seu próprio conhecimento, não do que absorveu durante o pré-treinamento. Isso significa conectá-lo à sua central de ajuda, seus documentos internos, suas macros e idealmente seu histórico de tickets resolvidos, e então restringi-lo a esse material.

Tickets resolvidos são a fonte subestimada aqui. Uma central de ajuda diz ao agente o que seu produto deveria fazer; seus tickets resolvidos mostram como sua equipe realmente responde a clientes reais dentro do seu fluxo de trabalho de atendimento ao cliente, incluindo os casos extremos. Um chatbot de base de conhecimento com IA que aprende de ambos é muito mais difícil de desestabilizar do que um treinado apenas em páginas de marketing.

Você pode ver como é um agente sem ancoragem na prática. Um consultor da Salesforce avaliando o Agentforce foi direto ao ponto:

"Além disso, as alucinações são realmente ruins, já que não treinamos e funciona com um modelo geral, às vezes simplesmente fornece informações que não são nossas."

Arjun G., avaliação do Salesforce Agentforce no G2

"Informações que não são nossas" é o sinal revelador. A correção é garantir que as únicas informações disponíveis sejam as suas. O outro lado da ancoragem é a obsolescência, porém, então mantenha a fonte atualizada. Como outro avaliador da mesma família de ferramentas alertou:

"Se seus arquivos de Content Version (Artigos de Conhecimento) não foram atualizados desde 2021, o agente de IA fornecerá aos clientes informações desatualizadas com total confiança."

Muhammad O., avaliação do Agentforce Service no G2

Ancorado mas desatualizado é seu próprio tipo de resposta errada. É exatamente por isso que treinar IA em sua base de conhecimento é um trabalho contínuo, não uma importação única, e por que uma base de conhecimento bem mantida compensa muito além da IA.

Faça cada resposta citar sua fonte

A ancoragem limita o que o agente pode ler. As citações o obrigam a provar que realmente leu algo. Se o agente tiver que anexar o documento ou ticket específico do qual sua resposta veio, duas coisas boas acontecem: um revisor pode verificar a resposta com um clique, e o agente não tem onde se esconder quando está improvisando.

O padrão em que eu insistiria: sem fonte, sem resposta. Se o agente não consegue apontar uma passagem que suporte sua resposta, não deve enviá-la, deve escalar. Um cofundador de uma empresa de tecnologia jurídica com quem trabalhamos explicou por que isso não é negociável no mundo deles: há uma linha tênue entre ser útil e cruzar para o aconselhamento jurídico, e a única forma de deixar a IA perto de clientes era com salvaguardas exatas sobre as fontes e uma citação transparente em cada resposta. Esse é um padrão alto, mas é o padrão correto para todos, não apenas para setores regulados.

Defina um limite de confiança e roteie por ele

Este é o que mais importa, e é o portão que transforma "confie em mim" em um mecanismo de segurança real. É a diferença entre uma ferramenta de deflexão que você pode deixar funcionando e uma que precisa ser monitorada constantemente, e vale a pena acertar isso antes de escalar a deflexão de nível 1. O agente deve responder automaticamente apenas quando está confiante e tem uma fonte. Todo o resto é rascunhado para um humano ou transferido.

Um líder de CX em uma marca DTC de suplementos que gerencia cerca de 7.000 tickets do Gorgias por mês explicou a lógica melhor do que eu poderia:

A IA nunca responderá 100% das perguntas, ele nos disse, mas se ela tentar em tudo e simplesmente escrever "desculpe, não sei" para um cliente, ele não pode revisar milhares de tickets para ver se fez um bom trabalho. Ele precisava de uma IA que só lidasse com os tickets em que estava confiante, e deixasse o resto em paz. Isso é roteamento baseado em confiança em uma frase, e foi o fator decisivo em sua avaliação.

A versão prática: escolha um limite de confiança, envie tudo abaixo dele para uma pessoa como rascunho em vez de uma resposta automática, e comece com o limite alto. Você sempre pode baixá-lo quando confiar no agente em um determinado tipo de ticket. É também aqui que uma boa escalação de chat com IA vale seu custo, porque um "vou chamar um humano" confiante supera uma resposta errada confiante toda vez. Se você está comparando isso com tecnologia mais antiga, é a linha mais clara entre um agente de IA e um chatbot baseado em regras.

Bloqueie os tópicos que nunca deve tocar

Alguns tickets não devem chegar perto da automação de suporte, e isso é um recurso, não uma limitação. Reembolsos acima de um limite, exclusões de conta, qualquer coisa jurídica, qualquer coisa com um cliente irritado em meio a uma escalação. Você quer controle explícito para manter essas categorias apenas com humanos.

Isso aparece constantemente em como as pessoas realmente querem implantar. Um líder de suporte nos disse diretamente que há certos tickets que não quer passar pela IA de forma alguma. A principal preocupação de um gerente de eCommerce não era a IA estar errada nos fatos, era a IA fazer promessas demais: "pare de dizer aos clientes que vamos resolvê-los, você não sabe disso". Ambas são na verdade o mesmo pedido, que é controle sobre o que o agente pode fazer, não apenas quão bem ele faz. Um bom agente de helpdesk de IA permite definir essas exclusões desde o início e estabelecer limites firmes sobre o que pode prometer, como a abordagem de escalação e salvaguardas do Breeze.

Simule em tickets anteriores antes de falar com um único cliente

Cada portão acima é uma hipótese até você testá-la. O erro que as equipes cometem é ativar o agente em clientes reais e esperar pelos problemas. O movimento muito mais seguro é executá-lo em simulação contra milhares de seus tickets históricos primeiro.

Uma simulação reproduz como o agente teria respondido tickets para os quais você já sabe o resultado correto. Você obtém cobertura por tópico, vê exatamente onde ele teria alucinado ou escalado, e corrige as lacunas de conhecimento antes que qualquer coisa toque uma conversa ao vivo. Depois você vai ao ar gradualmente, um tipo de ticket por vez.

Esta é a etapa que não entregaremos a um cliente sem ela, porque é a diferença entre esperar que o agente seja preciso e saber seu número de cobertura antes do lançamento. Foi também assim que a equipe de telemática veicular que mencionei encontrou seu problema de "suportamos todos os modelos" antes dos clientes, não depois.

Feche o ciclo: cada correção é dado de treinamento

O último portão funciona após o lançamento. Quando um humano edita ou rejeita um rascunho, esse sinal deve alimentar diretamente o agente para que o mesmo erro não recorra. Os avaliadores nos perguntam sobre isso o tempo todo, geralmente em alguma variação de "vocês realmente rastreiam quando aprovo ou rejeito uma resposta?" A resposta deve ser sempre sim, porque um agente que aprende com correções fica mais preciso a cada semana, e um que não aprende comete a mesma alucinação na sexta-feira que você identificou na segunda-feira. Combine isso com uma avaliação regular do desempenho do agente e você terá um sistema que melhora ao longo do tempo em vez de derivar.

Como saber se está realmente funcionando

Salvaguardas que você não mede são apenas boas intenções. Alguns números dizem se o agente é honesto:

• Taxa de contenção ou resolução nos tickets que ele respondeu. Alta resolução com baixa escalação é bom. Alta resolução com uma taxa crescente de reabertura significa que está fechando tickets com confiança quando não deveria. Veja como pensar na taxa de contenção e qualidade de escalação juntas em vez de isoladamente.
• Taxa de escalação por tópico. Um agente saudável escala mais em categorias ambíguas e menos nas simples. Se a escalação é plana em tudo, seu limite de confiança provavelmente não está fazendo nada.
• Reabertura e CSAT em tickets tratados por IA versus tratados por humanos, rastreados como parte de suas métricas de atendimento ao cliente com IA mais amplas.

O objetivo de observar isso é encontrar o momento em que a confiança ultrapassou a precisão, e ajustar o limite para baixo. Feito corretamente, a taxa de "não sei" do agente é um recurso do qual você se orgulha, não um que tenta esconder.

Experimente a eesel

Sou parcial porque ajudo a construí-la, mas esta é exatamente a configuração em torno da qual o agente de helpdesk de IA da eesel foi projetado. Ele aprende com seus tickets anteriores e documentos de ajuda no primeiro dia, cita suas fontes e usa roteamento baseado em confiança para que só responda automaticamente quando está seguro e passe silenciosamente o resto para sua equipe. O recurso para o qual eu apontaria primeiro é a simulação: você pode executá-la em milhares de seus tickets históricos e ver sua cobertura e precisão reais antes de um único cliente estar envolvido, em vez de descobrir ao vivo.

Essa cautela compensa. Para um cliente de logística, resolvemos 73% de suas solicitações de nível 1 no primeiro mês (agente de helpdesk de IA da eesel), e funciona porque o agente deixa em paz os tickets que não deve tocar. Ele se conecta ao Zendesk, Freshdesk, Gorgias e outros, e com preços baseados em uso você não paga uma taxa por assento para manter um humano no ciclo. Você pode experimentar gratuitamente e começar em simulação.