Utilizamos o Claude 3 para aumentar em três vezes a eficiência do processamento dos pedidos de pós-venda dos clientes, mas acabamos tropeçando em dois problemas que não deveríamos ter encontrado.

Quando terminamos de coletar os relatórios no último Black Friday, três desenvolvedores da nossa equipe de SaaS para comércio eletrônico no Sudeste Asiático ficaram atônitos diante dos dados do backend: em anos anteriores, toda a equipe de atendimento ao cliente precisava trabalhar incansavelmente por três dias para processar todos os pedidos de pós-venda, mas neste ano, a maioria deles foi processada automaticamente, e o número de reclamações dos clientes caiu diretamente em 42%. A única alteração fundamental foi a substituição da lógica de reconhecimento semântico dos pedidos antigos pelo Claude 3 Opus.

Para quem nunca teve contato com isso, vou ser direto:

É o terceiro modelo de linguagem grande lançado pela Anthropic em 2024, e os parâmetros centrais que utilizamos são bastante simples: com uma janela de contexto de cerca de 200k palavras, conseguimos processar pedidos de pós-venda que contêm 3 screenshots de produtos, alcançando uma taxa de acerto 18% maior do que os modelos com o mesmo nível de parâmetros que usávamos anteriormente.

Para uma equipe pequena como a nossa, esses três benefícios representam um valor real em dinheiro.

O primeiro ponto é que não é mais necessário realizar um processamento prévio de múltiplos modais de forma separada. Antes, para os produtos danificados e as capturas de tela da logística enviados pelos usuários, tínhamos que primeiro usar um modelo OCR para converter as imagens em texto e, em seguida, combinar esse texto com os pedidos de suporte para alimentar o modelo principal. A manutenção dessa cadeia de processamento consumia metade dos recursos do backend. Com a adoção do Claude 3, as imagens e o texto são enviados diretamente juntos, o que reduziu significativamente o número de erros e omissões no reconhecimento.

O segundo ponto é que a taxa de rejeição é tão baixa que quase pode ser ignorada. Os modelos anteriores, ao se depararem com solicitações de usuários escritas de forma muito confusa (por exemplo, misturando inglês com o idioma local e abreviaturas da internet), frequentemente retornavam uma resposta indicando que não era possível reconhecer o conteúdo, o que forçava a transferência do caso para um operador humano. Nós fizemos as contas e, naquela época, a proporção de casos transferidos para o suporte humano era de 27%; agora, esse número é de 4%.

O terceiro ponto é que o custo da chamada foi muito menor do que esperávamos. Pagamos de acordo com o uso real; no pico do Black Friday, processamos em média 12 mil pedidos por dia, e o custo total foi de menos de 800 dólares, o que representa uma economia de 90% em relação ao custo de contratar 10 atendentes temporários.

Mas não se apresse em agir; os dois erros que cometemos são suficientes para fazer você trabalhar em vão por uma semana inteira.

O primeiro problema foi o alinhamento de conteúdo em várias línguas. Metade dos nossos usuários fala indonésio, e quando lançamos o produto sem fazer nenhum ajuste inicial, o modelo frequentemente confundia expressões locais populares, como “o produto foi enviado na cor errada”, com “o usuário quer trocar o endereço de entrega”, o que resultou em 17 reclamações em uma semana. Mais tarde, após fornecermos 3000 exemplos de tickets de suporte em indonésio com etiquetas de treinamento, o problema foi resolvido.

O segundo problema é a omissão de informações em contextos mais longos. Se um ticket contiver mais de 5 imagens, o modelo pode ocasionalmente perder informações de alguma delas. Por exemplo, se o usuário enviar fotos da embalagem danificada e do produto danificado, o modelo pode reconhecer apenas o problema com a embalagem. Mais tarde, adicionamos uma regra de verificação simples: se houver mais de 3 imagens, fazemos com que o modelo exiba os resultados da reconhecimento uma por uma antes de processá-las de forma agregada, e desde então não tivemos mais esse problema.

Para ser honesto, nem todos os times são adequados para usar isso.

Circunstâncias em que você deve usá-lo:

• Seu negócio precisa lidar simultaneamente com texto e imagens/áudios curtos, e você não deseja criar múltiplos conjuntos de modelos para isso.
• Você tem requisitos muito altos em relação à precisão da tradução, como em cenários onde o erro pode custar muito, como no processamento de pedidos de suporte ou na revisão de contratos.
• A sua equipe está com falta de recursos humanos e não tem energia para manter os complexos processos de pré-processamento dos modelos.

Situações em que você não deve desperdiçar dinheiro:

• Você só precisa fazer respostas com palavras-chave simples, gerar textos de marketing e outros tipos de tarefas leves; modelos pequenos e baratos são suficientes para isso.
• Os seus dados de negócios têm requisitos estritos de armazenamento localizado e não é possível transferir os dados para interfaces de modelos de terceiros.
• O volume de suas solicitações é muito baixo, com menos de 1000 por mês, e o custo de desenvolvimento para trocar de modelo é maior do que o benefício.

Duas dicas práticas para quem está começando

Primeiro, testamos as situações de borda por 7 dias antes de implementar no link principal. No início, utilizamos os pedidos de trabalho históricos dos últimos 3 meses para realizar testes off-line; a taxa de acurácia atingiu mais de 95% antes de começarmos a direcionar 10% do tráfego online. Gradualmente, aumentamos essa proporção até atingir o volume total, sem nenhum grande problema ocorrer em ambiente online.

O segundo ponto é não escolher desde o início a versão mais cara do Opus. Nós testamos e vimos que, para o processamento de típicos pedidos de suporte sem imagens, a precisão da versão Sonnet é quase a mesma que a do Opus (com uma diferença de menos de 2%), e o custo é apenas metade. Isso é mais do que suficiente.

Finalmente, uma pergunta que muitos fazem: devemos esperar pelo próximo modelo? Nossa resposta é que, se o seu negócio já está sendo prejudicado pela falta de eficiência devido ao processamento multimodal e à baixa precisão dos modelos atuais, é melhor começar a usá-los agora. Afinal, economizar custos de mão de obra desde cedo compensa muito mais do que o pequeno aumento nos custos de chamada que será gerado pela espera pelo próximo modelo.