Em setembro eu abri um verbete ao acaso na base do nosso assistente. Era sobre erro de emissão de CT-e. Título bom, resposta clara em quatro passos.
O quarto passo mandava abrir um menu que não existe. Eu sei que não existe porque procurei aquele menu num chamado, meses antes, e foi o analista da ESL que me corrigiu.
Naquele dia a base tinha 4.397 verbetes e eu estava orgulhoso dela. Zero duplicados, todos passando no crivo automático que eu mesmo escrevi.
Duas semanas depois a auditoria mostrou o resto: 83% dos verbetes não tinham a seção que resolve o problema. No material de origem, aquela seção existia em 99,8% dos casos. Havia também um terço dos assuntos duplicado, cerca de 300 verbetes vazios, 122 com mais de 40 KB (grandes demais para caber numa consulta), resíduo de conversa de helpdesk dentro do conteúdo e um token de acesso esquecido.
A base tinha volume, a busca funcionava, o assistente respondia em três segundos.
Debaixo do capô
A leva inicial saiu de um pedido simples: pegar o chamado resolvido e transformar em verbete. Fizemos com 18 casos e 6 passaram no crivo.
Os 12 reprovados não tinham problema de forma. Tinham problema de conteúdo. Quando o chamado não trazia o caminho completo, a IA completava com o que o sistema costuma ser. E o que o sistema costuma ser está quase sempre certo, o que torna o erro difícil de ver numa revisão rápida.
Depois disso, o que mudou foi o material que chegava até a IA: texto já revisado por gente, para arrumar num formato único. Quando faltava um pedaço, o verbete saía com o buraco à vista. Nos mesmos 18 casos, com o mesmo modelo e o mesmo crivo, passaram os 18.
A duplicação veio do mesmo lugar: agrupar o conhecimento depois de gerar, em vez de antes. Um terço dos assuntos com duas ou três versões ligeiramente diferentes do mesmo texto. Para quem lê, parece bagunça. Para quem busca, é pior.
Quando alguém pergunta, o sistema traz os cinco ou dez trechos mais parecidos. Se cinco deles são variações do mesmo assunto, sobra pouca vaga para o artigo que tem o caminho. E a fragmentação costuma cortar justamente a parte útil: uma versão tem o sintoma, outra tem a causa, uma terceira tem o passo a passo, e o assistente traz a que mais se parece com a pergunta. Quase sempre a do sintoma, e a resposta sai pela metade.
A última peça é a etapa de limpeza, aquela que tira saudação, assinatura e tudo o que se repete em toda mensagem. Ela precisa 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: nome da empresa, subdomínio, documento. Em 98% desses casos a limpeza apagava essa identificação. Para a rotina de limpeza era sujeira, porque nome de empresa não é pergunta. Para quem responde era o dado mais importante da frase, porque a resposta depende de saber de qual cliente se fala: qual plano, qual integração, qual configuração.
O resultado é o comportamento que mais irrita qualquer analista de suporte. O assistente pede de volta exatamente o que a pessoa acabou de colar.
O modelo preenche o que falta
Quando o trecho recuperado traz o sintoma e não o caminho, o modelo 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.
Ele não inventa do zero: completa o que o material deixou em branco. A invenção é uma lacuna da base preenchida com conhecimento geral do domínio. Trocar de modelo melhora pouco, porque o novo também vai preencher.
Um verbete reprovado sobre erro de emissão dizia: “Verifique as configurações do sistema e tente novamente. Caso o erro persista, entre em contato com o suporte.” Quatro linhas, bem escritas, e nenhuma chance de resolver.
O mesmo assunto, reconstruído a partir do chamado, ficou assim: “Rejeição 610: o campo cIndOp veio com 000. O campo aceita 1 (sim) ou 2 (não). Ao gerar o XML, ajuste o campo e reenvie.”
Uma frase. O refeito serve porque o chamado dizia o campo e o valor; o outro poderia ter sido escrito por qualquer pessoa do ramo, sem olhar chamado nenhum.
Congelar, reconstruir, provar
Remendar era possível: acrescentar a seção que faltava, apagar duplicados, limpar resíduos. O problema é que remendar mantém o método que produziu o defeito. Então a produção foi congelada, com backup completo e roteiro de rollback escrito antes de começar, e a base foi refeita a partir dos chamados.
O que entrou no lugar foi uma regra simples: nada é publicado sem passar no crivo, e verbete que não passa é gerado de novo, nunca corrigido à mão. Corrigir à mão parece mais rápido na primeira semana e vira gargalo humano permanente, além de esconder o problema real.
A conta final: 44 mil fontes, agrupadas em 4.426 assuntos, que viraram 4.397 verbetes aprovados. Sem duplicados por construção, porque o agrupamento acontece antes da geração e não depois.
Tamanho de base não diz nada sozinho. O que interessa é o que ela devolve: nas perguntas de origem, o verbete certo apareceu em primeiro lugar em 94% dos casos; com agrupamento por assunto e verbetes complementares, 97% em primeiro e 100% entre os três primeiros.
O teste de meia hora
Dá para saber em que ponto está a sua base sem projeto, sem integração e sem fornecedor.
Sorteie 20 verbetes de módulos diferentes. Sorteio, não escolha. Para cada um, tente responder qual problema ele resolve, onde está o passo que resolve e de onde veio 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, ele foi inventado em algum momento.
Conte quantos passam. Abaixo de 50%, 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 e deixando o resto. Acima de 80%, o conteúdo está bom e o problema está na recuperação.
O que acontece depois
Se dois terços do material não respondem à pergunta que dizem responder, nenhum ajuste de prompt salva a resposta final. O assistente vai citar com confiança um passo que não existe.
O custo aparece onde ninguém mede. A ferramenta não é desligada: é abandonada aos poucos, o time volta a perguntar ao colega do lado, e a confiança de quem usa não volta com uma atualização.
Se você tem uma base hoje, feita à mão, por IA ou herdada de quem saiu da empresa, esse teste leva meia hora e diz mais sobre o futuro do seu assistente do que qualquer demonstração de fornecedor.
Isto é o tipo de problema que eu resolvo na Assistentia: auditoria da base, reconstrução com crivo e o assistente a responder de verdade. Se quiseres ver a versão comercial deste texto, ela está lá.