A Asana anunciou que, numa avaliação da IA da StackAI que automatiza a interação com o browser, reduziu o custo estimado dos modelos para 1/76 do valor da configuração de produção anterior e multiplicou a velocidade de processamento por cinco. Com o GPT‑6.1 Sol e uma configuração otimizada para gerir o histórico de navegação, cada execução demorou, em média, cerca de 4 minutos e custou 0,47 dólares.
A redução para 1/76 não se deveu apenas à mudança de modelo
O aspeto essencial destes números é que a comparação não diz respeito ao desempenho isolado dos modelos, mas ao resultado da combinação entre o modelo e a forma como o processamento é organizado. Um agente de browser é uma IA que lê páginas Web e executa tarefas como recolher informação ou preencher formulários. A Asana disponibiliza a automatização deste tipo de trabalho através da StackAI, que adquiriu.
Na avaliação, foram recolhidas seis informações sobre cada um de 32 livros do catálogo público de demonstração. Foram realizados 144 testes no total, com quatro modelos e várias configurações. Com o modelo B, utilizado inicialmente, o custo estimado por execução era de, pelo menos, 36,21 dólares. A simples revisão da forma de processamento reduziu-o para 1,24 dólares. Com a configuração otimizada que utiliza o GPT‑6.1 Sol, o valor desceu ainda mais, para 0,47 dólares.
Ou seja, mesmo mantendo o modelo B, foi possível reduzir os custos para cerca de 1/29. Por detrás do valor de 1/76 anunciado está, em grande medida, a melhoria da conceção do processamento, anterior à escolha do modelo.
O segredo da poupança estava no histórico de navegação enviado à IA
Na configuração anterior, elementos como as instruções fixas eram armazenados em cache, mas não o histórico acumulado de texto das páginas e capturas de ecrã. A cache permite reutilizar dados de entrada que já foram processados. Se o histórico não puder ser reutilizado, é necessário voltar a enviar informações anteriores sempre que se chama a IA, o que gera custos adicionais.
Além disso, em quase todas as etapas eram eliminadas imagens antigas e encurtado o texto. Como o histórico era alterado frequentemente, a simples introdução de uma cache dificilmente produziria resultados. Eliminar demasiada informação também pode levar a que sejam visitadas novamente páginas já consultadas.
A solução foi aumentar o limite de retenção do histórico de 120 mil para 480 mil caracteres e incluir o histórico de navegação na cache. As capturas de ecrã passaram a ser acumuladas até 20 imagens, mantendo-se depois apenas a mais recente. Em vez de reorganizar o histórico a cada passo, passou a ser reorganizado em blocos, prolongando o período em que podia ser reutilizado sem alterações.
Manter mais informação também pode reduzir os custos
Reduzir a informação enviada à IA permite poupar. Os resultados desta avaliação mostram que esta ideia, por si só, não explica os custos de um agente. Em alguns casos, manter e reutilizar informação, reduzindo verificações desnecessárias, pode tornar o processamento global mais barato.
Com o GPT‑6.1 Sol, a revisão da cache e da gestão de imagens, numa configuração com um limite de retenção do histórico mais elevado, reduziu o custo estimado por execução de 1,97 para 0,47 dólares. Após a otimização, 89% dos dados de entrada foram fornecidos pela cache, e o custo dessa parte correspondeu a 5% do que teria custado sem recorrer à cache.
A quantidade de histórico também influencia a conclusão das tarefas. Com o GPT‑6.1 Sol, foi possível gerar uma resposta em apenas três de 18 execuções quando o limite de retenção era baixo, mas em todas as 18 quando o limite era mais elevado. Na avaliação, as 18 respostas estavam corretas.
A IA também foi utilizada para testar propostas de melhoria
O GPT‑6.1 Sol foi o modelo que controlou efetivamente o browser. Para investigação e otimização, foi utilizado o GPT‑6 Astra do Codex. Este analisou a estrutura do código, identificou problemas na gestão do histórico e reorganizou o código para os testes, permitindo avaliar em paralelo várias configurações.
Isso não significa que não tenha havido intervenção humana. Frank Hidalgo, CTO da StackAI, analisou as propostas e selecionou as alterações a testar. Os registos e resultados das experiências foram também revistos noutra sessão do modelo e guardados no Command, a plataforma de desenvolvimento da Asana. As alterações passaram por tickets e pull requests antes de serem implementadas em produção.
Hidalgo afirmou que uma investigação que, segundo a sua estimativa, levaria um a dois meses se fosse feita manualmente ficou concluída em cerca de uma semana. Esta diferença de duração é uma comparação com a estimativa de Hidalgo, não o resultado de uma experiência de controlo em que a mesma tarefa tenha sido realizada apenas por pessoas.
Na decisão de implementação, é preciso considerar em conjunto os custos e a taxa de conclusão
Os 0,47 dólares são o custo estimado dos modelos, não o custo total, que incluiria mão de obra e operação dos sistemas. Além disso, algumas das configurações utilizadas na comparação atingiram o limite de execuções sem concluir o processamento, pelo que os valores de, pelo menos, 36,21 dólares e de mais de 22,5 minutos são limites mínimos. Os principais valores comparativos correspondem à média de três execuções por configuração, e a mesma percentagem de redução não pode ser aplicada a todas as tarefas na Web.
Entre as configurações otimizadas, o modelo C custou 0,66 dólares e demorou 3,5 minutos; o GPT‑6.1 Sol custou 0,47 dólares e demorou cerca de 4 minutos. Nesta tarefa, o Sol foi mais barato, mas o modelo C foi mais rápido: a classificação varia consoante se considere o custo ou a velocidade.
A Asana aplicou estas alterações à funcionalidade de controlo do browser da StackAI. No futuro, pretende integrar a avaliação na plataforma, permitindo que os clientes e as equipas internas comparem o custo, o tempo de execução e a qualidade das respostas de cada configuração.
コメント