Utilizamos o OpenAI o1 para maximizar a precisão da correspondência dos endereços logísticos, mas encontramos 3 problemas inesperados.

Logo após o pico do Black Friday da semana passada, nossa equipe de backend de 3 pessoas na Europa finalmente pôde suspirar aliviada: no ano passado, 13% das solicitações de resolução de endereços sofreram com limitações de tráfego devido a um único modelo, resultando em erros 429; este ano, não houve nenhum caso de limitação de tráfego, e a taxa de erros na correspondência de endereços caiu em 82%. A principal mudança foi a substituição do nosso modelo de inferência principal pelo o1.

Para quem não tem conhecimento sobre o assunto, vamos esclarecer: o que é exatamente o “o1”?

É o grande modelo de raciocínio reforçado lançado pela OpenAI, que é diferente do GPT-4o anterior. Ele leva mais tempo para “pensar” em problemas lógicos complexos, e a pontuação no teste de capacidade de raciocínio básico fornecida oficialmente é 87% mais alta do que a do GPT-4o. Foi por esse critério que escolhemos inicialmente.

Para equipes pequenas e médias como a nossa, as vantagens do o1 são realmente significativas.

O primeiro benefício resolve diretamente o problema mais complicado que tínvamos: a correspondência de endereços. Antes, ao usar o GPT-4o, era comum confundir ruas com o mesmo nome e códigos postais de diferentes países na Europa, especialmente quando os usuários inseriam endereços com erros de ortografia. Isso exigia que aplicássemos três níveis de verificações para alcançar uma taxa de acerto de apenas 92%. Agora, com o o1, essa taxa de acerto aumentou para 98,7%, e já eliminamos todo o código de regras que usávamos na semana passada.

O segundo ponto é que não é mais necessário desenvolver projetos de prompts complexos. Antes, para fazer com que o modelo produzisse resultados de análise de acordo com o formato do nosso backend, escrevemos um prompt de quase 2000 palavras, e frequentemente ocorriam problemas com o formato da saída. Agora, basta uma única instrução para resolver o problema, o que reduziu drasticamente o custo de manutenção do prompt para zero.

O terceiro ponto é que a estabilidade das solicitações concorrentes é melhor do que esperávamos. Estávamos preocupados com o fato de que o longo tempo de processamento das solicitações poderia causar filas, mas os dados de monitoramento mostram que a maioria das solicitações é concluída em menos de 15 milissegundos. Apenas um número muito pequeno de consultas de endereços internacionais complexas leva mais de 200 milissegundos, o que está completamente dentro do nosso intervalo aceitável.

Mas as armadilhas que ele contém também podem realmente te pegar de surpresa.

O primeiro problema é que o consumo de tokens é muito maior do que no GPT-4o. Nos primeiros 3 dias em que mudamos para o GPT-4o, o custo de inferência aumentou em 2,3 vezes. Mais tarde, descobrimos que o GPT-4o também incluía automaticamente o processo de pensamento no consumo de tokens. Se você não precisa ver a lógica de inferência, é essencial desativar a saída desse processo de pensamento nos parâmetros da chamada. Depois de desativá-lo, o custo caiu para 1,2 vezes o valor anterior, o que é completamente aceitável.

O segundo problema é que o método não é adequado para solicitações simples e de alta frequência. No início, para facilitar as coisas, todas as solicitações de consulta de endereços foram direcionadas para o o1. Mais tarde, descobrimos que para endereços sem erros de ortografia e em formato padrão, não havia diferença na precisão entre usar o o1 e o GPT-4o; além disso, gastávamos mais dinheiro. Agora adicionamos uma verificação prévia simples, e apenas as solicitações que não seguem o formato padrão são direcionadas para o o1, o que reduziu os custos em mais 30%.

O terceiro problema é que o suporte para entradas em línguas não latinas, como chinês e árabe, ainda não é estável o suficiente. Temos um pequeno número de usuários no Oriente Médio, e ocasionalmente ocorrem erros de análise em endereços inseridos em árabe. Após relatarmos esse problema para a OpenAI, ainda estamos aguardando a correção. Por enquanto, estamos utilizando regras locais para realizar verificações adicionais.

Quem deve usar o o1? Quem não deve tocar nele agora?

Se você está lidando com tarefas que exigem raciocínio lógico — como correspondência de regras complexas, verificação de múltiplas condições, ou geração de código simples — e já encontrou um limite de precisão ao usar o GPT-4o, então trocar para o o1 pode ser uma ótima opção, já que o custo-benefício será muito alto.

Mas se o que você está fazendo é simples classificação de texto, geração de conteúdo ou solicitações de padronização frequentes, então não há absolutamente nenhuma necessidade de usar o o1; é pura perda de dinheiro. O GPT-4o, ou até mesmo o GPT-3.5, é mais do que suficiente para isso.

2 dicas para quem usa pela primeira vez

• Primeiro, use os 1000 dados históricos que você processou com o modelo antigo para fazer um teste. Não faça a mudança de modelo de uma só vez; assim, você poderá ver rapidamente se o aumento da precisão compensa o aumento dos custos. Nós testamos por 2 dias e decidimos que era necessário trocar o modelo.
• Ao fazer a chamada, dê preferência à versão o1-mini. Para 90% dos casos de equipes de pequeno e médio porte, as funcionalidades da o1-mini são mais do que suficientes, e o preço é 60% mais baixo do que o da versão completa o1.

Por fim, vamos responder a uma das perguntas mais frequentes: o1 será substituído em breve por outros modelos? Pelo menos no cenário de resolução de endereços que estamos trabalhando, testamos todos os grandes modelos de inferência disponíveis no mercado e nenhum deles conseguiu superar a precisão do o1. Pelo menos nos próximos seis meses, ele continuará sendo a nossa primeira escolha.