💡Ethan Mollick: empresas erram ao economizar usando IA mais burra
Ethan Mollick fez uma provocação que merece atenção de qualquer empresa usando IA: muitas companhias escolhem modelos mais fracos (e baratos) porque eles parecem bater as metas, mas podem estar deixando resultados muito melhores na mesa. A tentação de cortar custos com um modelo de IA mais barato é real, mas Mollick argumenta que a diferença de qualidade entre um modelo mediano e um de ponta pode ser maior do que os indicadores tradicionais conseguem captar. --- O conselho dele é prático: mesmo que a empresa já tenha escolhido um modelo mais barato, vale montar uma estrutura flexível que permita testar modelos mais inteligentes de tempos em tempos. Só assim dá para saber se a economia está, na verdade, custando oportunidades. É o tipo de armadilha clássica: otimizar pelo preço quando o verdadeiro diferencial é a qualidade.
Ethan Mollick fez uma provocação que merece atenção de qualquer empresa usando IA: muitas companhias escolhem modelos mais fracos (e baratos) porque eles parecem bater as metas, mas podem estar deixando resultados muito melhores na mesa. A tentação de cortar custos com um modelo de IA mais barato é real, mas Mollick argumenta que a diferença de qualidade entre um modelo mediano e um de ponta pode ser maior do que os indicadores tradicionais conseguem captar.
— @emollick View on X
Empresas que optam por modelos de linguagem mais baratos para reduzir custos de inferência podem estar sacrificando resultados de maior valor sem perceber. A advertência é do professor Ethan Mollick, da Wharton, que alerta para a armadilha de otimizar métricas de custo enquanto indicadores tradicionais falham em medir o ganho real de qualidade em modelos de ponta.
O custo oculto dos modelos mais baratos
A pressão por cortar despesas com IA é compreensível. Com a proliferação de LLMs — desde opções open source como Llama e Mistral até modelos proprietários como GPT-4 e Claude —, equipes de engenharia e produto enfrentam a tentação de escolher alternativas medianas que atingem benchmarks básicos a um custo por token inferior. O problema, segundo Mollick, é que a distância entre um modelo mediano e um de ponta frequentemente se manifesta em nuances que métricas automáticas não capturam: raciocínio em múltiplas etapas, menor taxa de alucinações em contextos longos, capacidade de seguir instruções complexas e geração de insights não óbvios.
Em pipelines de RAG ou automações críticas, um modelo mais fraco pode devolver uma resposta tecnicamente aceitável, mas omitir conexões relevantes ou exigir mais rodadas de refinamento humano. O custo de oportunidade se acumula silenciosamente.
Por que isso importa para o cenário brasileiro
No Brasil, onde startups e times de tecnologia frequentemente operam com capital limitado, a decisão de abrir mão de modelos mais robustos por questão de budget é comum. Contudo, builders e desenvolvedores precisam distinguir entre redução de custo eficiente e otimização prematura. Um sistema de IA que economiza dólares em API, mas demanda horas extras de revisão humana ou gera saídas genéricas para clientes, pode sair mais caro no balanço final.
A recomendação de Mollick é construir arquiteturas de IA desacopladas. Isso significa estruturar pipelines onde o provedor de LLM possa ser trocado sem reescrever a aplicação inteira. Com essa flexibilidade, é possível rodar testes A/B periódicos comparando modelos de diferentes classes — não apenas pelo preço, mas pela qualidade da saída em cenários reais de negócio.
Como testar sem quebrar o orçamento
- Implemente uma camada de abstração na sua stack de IA para alternar entre provedores com mudanças mínimas de código.
- Estabeleça avaliações humanas ou semiautomatizadas que vão além de acurácia simples, medindo utilidade da resposta, criatividade e redução de retrabalho.
- Programe ciclos de validação trimestrais ou semestrais com modelos de ponta, mesmo que o dia a dia rode em alternativas mais baratas.
- Monitore custos totais de operação, incluindo tempo de engenharia e revisão, não apenas o valor da API.
A escolha do modelo de linguagem não deve ser uma decisão definitiva feita no lançamento. Em um mercado onde a qualidade do output define a experiência do usuário, a economia na camada de inferência pode ser o primeiro passo para um produto medíocre.