Utilizando a API da OpenAI para a verificação de endereços logísticos na Europa: economizamos 32% dos custos de mão de obra e também evitamos 2 erros fatais.

A promoção de fim de semana “Black Week” acabou de terminar, e durante a reunião de análise do nosso time técnico, descobrimos que a taxa de sucesso da verificação automática de endereços aumentou 41% este ano em comparação com o ano passado. Além disso, dos três funcionários temporários que antes eram contratados especificamente para lidar com endereços anormais, este ano só é necessário manter um deles.

Ninguém queria falar sobre o problema com o erro 429 que aconteceu no mês passado – durante as 3 horas mais movimentadas do primeiro dia da grande promoção…13% dos pedidos de resolução de endereços são diretamente devolvidos.O suporte ao cliente explodiu, e o grupo de operações quase veio aqui para derrubar nossas mesas.

Para quem nunca ouviu falar, vou ser direto: o que é exatamente a API da OpenAI?

Você não precisa treinar modelos grandes por conta própria; basta chamar as APIs dos modelos já treinados pela OpenAI, como GPT-4o e GPT-3.5-turbo, enviar uma solicitação e receber o resultado. O custo é calculado com base na quantidade de tokens utilizados. A versão que suporta até 128k de contexto por solicitação já está totalmente disponível.

A razão pela qual escolhemos isso no início foi muito simples: os formatos de endereços nos países europeus eram muito desordenados. O código postal do Reino Unido é completamente diferente do da Alemanha, e havia também muitos erros de ortografia em diferentes idiomas. A biblioteca de regras que criamos sozinhos foi atualizada 8 vezes em seis meses, mas ainda assim continha falhas. Ao usar uma API para análise semântica e fornecer o prompt correto, a taxa de acerto aumentou para mais de 96%.

Os 3 benefícios reais que recebemos não são falsos.

• Não foi necessário manter uma equipe de algoritmos dedicada para ajustar os modelos; três servidores de backend completaram a integração das interfaces em uma semana. No primeiro mês de operação, economizamos 32% dos custos de mão de obra dos três funcionários temporários anteriores.
• Erros de ortografia e endereços abreviados que não eram reconhecidos pelo banco de regras anteriormente agora são corrigidos automaticamente em mais de 90% dos casos. Como resultado, a taxa de cancelamentos de pedidos devido a endereços incorretos fornecidos pelos usuários caiu diretamente em 28%.
• Suporte para a entrada mista de várias línguas: endereços preenchidos em polonês por usuários poloneses ou em espanhol por usuários espanhóis podem ser processados diretamente pelo sistema sem necessidade de adaptação localizada. Basta enviá-los para a interface, e eles serão convertidos no formato padrão de logística.

Não olhe apenas para os benefícios; esses dois problemas quase nos custaram a vida.

O primeiro problema foi o limite de taxa de solicitações (throttling) padrão para um único modelo. Antes, estávamos usando apenas o GPT-4o-mini, e o limite de taxa de solicitações definido por minuto era suficiente para o uso normal. No entanto, no dia de uma promoção, o número de solicitações aumentou em três vezes, o que imediatamente desencadeou o mecanismo de limitação. 13% das solicitações receberam o erro 429. Para resolver esse problema, adicionamos uma lógica de downgrade, direcionando as solicitações fora dos horários de pico para o GPT-3.5-turbo, o que permitiu que o serviço voltasse a funcionar normalmente.

O segundo problema é o erro na identificação de endereços sensíveis. Uma vez, um usuário inseriu um endereço que continha palavras relacionadas a “bases militares”, e esse endereço foi imediatamente bloqueado pelo sistema de revisão de conteúdo da API. Como não implementamos nenhuma solução de fallback para falhas, o pedido ficou parado por 2 dias sem ser enviado, o que levou o usuário a dar uma avaliação negativa.

Quem deve usá-lo? Quem realmente não deve desperdiçar dinheiro?

Se você, assim como nós, trabalha com negócios que envolvem o processamento semântico de múltiplas línguas e situações em que as regras são infinitas (como verificação de endereços, respostas automáticas a consultas de usuários, geração de conteúdo em várias línguas), e não tem uma equipe especializada em algoritmos dentro da equipe, usar a API da OpenAI é muito mais econômico do que treinar modelos próprios.

Mas se o que você está fazendo é um negócio onde os dados críticos não podem ser compartilhados com terceiros, como o processamento de dados financeiros essenciais, a análise de dados de privacidade médica, ou cenários simples com um volume de solicitações estável e regras claras, então não vale a pena se envolver nisso. É mais barato e seguro escrever suas próprias regras ou implantar pequenos modelos localmente.

3 dicas para quem usa pela primeira vez, todas baseadas em erros que nós cometemos

• Não se limite a usar apenas um modelo; tenha pelo menos dois modelos de diferentes níveis de qualidade para uso em situações de downgrade. Para solicitações de alta prioridade, utilize o modelo com maior precisão, e para solicitações de baixa prioridade ou durante períodos de pico, use o modelo mais barato. Isso pode economizar pelo menos 40% dos custos e também evitar problemas de limitação de taxa de solicitações devido ao uso de apenas um modelo.
• Todos os pedidos devem ter lógicas de tentativa reiterada e de fallback (resolução de falhas); planos de ação para situações como bloqueio de conteúdo, limitação de taxa de solicitações e timeouts devem ser preparados com antecedência, para que não se espere até que a interface fique indisponível para começar a lidar com esses problemas manualmente.
• Não é necessário usar o modelo mais avançado desde o início; comece com o mais barato, o GPT-3.5-turbo, para testar o desempenho. Se o resultado não for satisfatório, então passe para um modelo mais avançado. Para a maioria das situações simples, modelos menores são mais do que suficientes.

Finalmente, vamos responder a duas perguntas que muitas pessoas fazem com frequência.

Pergunta: Haverá um atraso significativo nas chamadas na região da Europa?
A resposta é: Nós utilizamos o nó de Frankfurt, e a maioria das solicitações é concluída em menos de 15 milissegundos. Apenas uma pequena porcentagem delas pode aumentar de repente para mais de 200 milissegundos, mas adicionar um cache pode resolver esse problema sem afetar o negócio de forma alguma.

Pergunta: Será que pode haver casos em que o resultado da análise esteja incorreto?
Sim, agora estamos encaminhando os resultados com uma confiança inferior a 80% para revisão manual. Com a adição dessa regra, a taxa de erros pode ser praticamente ignorada.