Claude vs GPT-4o vs Gemini para Análise de Dados: Testei os 3 com Dados Reais

Tenho usado IA para análise de dados praticamente todos os dias no último ano. E continuo a ouvir a mesma pergunta dos meus colegas: "Qual é que devo usar mesmo?" Por isso decidi parar de adivinhar e fazer uma comparação a sério.

Peguei em três tarefas do mundo real — o tipo de coisas com que os analistas de dados realmente lidam — e lancei-as ao Claude (3.5 Sonnet), ao GPT-4o e ao Gemini 1.5 Pro. Sem cherry-picking de prompts. Sem tentar de novo até obter uma boa resposta. Uma única tentativa por tarefa, mesmo prompt, mesmos dados.

Eis o que aconteceu.

Porque é que fiz este teste

Vou ser honesto: nenhuma destas empresas me patrocina. Pago as três subscrições do meu próprio bolso (20 $/mês cada, o que vai acumulando depressa). O motivo pelo qual fiz este teste é puramente egoísta — queria saber qual das subscrições podia cancelar.

A maioria dos artigos de "comparação de IAs" que li são ou muito superficiais ou claramente tendenciosos para o modelo que o autor prefere. Testam algo trivial como "escreve-me um haiku" e depois tiram conclusões arrojadas sobre a adequação empresarial. Isso não é útil.

Queria testar coisas que realmente importam para o trabalho com dados: lidar com dados reais e desordenados, gerar SQL correcto em múltiplas tabelas e extrair insights de documentos longos. São as tarefas que faço todas as semanas, e suspeito que a maioria dos profissionais de dados também.

A configuração

Antes de entrar nos resultados, eis como estruturei os testes:

• Mesmo prompt para os três modelos — escrevi cada prompt uma vez e copiei-o exactamente
• Sem system prompts ou instruções personalizadas — ponto de partida limpo para todos
• Configurações por defeito — sem ajustes de temperatura nem de top-p
• Tentativa única — o que saiu na primeira é o que avaliei
• Testado em Abril de 2026 — os modelos actualizam-se constantemente, por isso isto é uma fotografia num momento no tempo

Avaliei cada modelo numa escala de 1 a 10 em múltiplos critérios por tarefa e depois calculei a média. Não é perfeitamente científico, mas é muito mais rigoroso do que ir a instinto.

Teste 1: Análise de CSV com 50.000 linhas

O conjunto de dados

Usei um conjunto de dados real de transacções de e-commerce com 50.247 linhas e 23 colunas. Incluía IDs de encomendas, timestamps, categorias de produtos, dados demográficos de clientes, métodos de pagamento, detalhes de envio, estado de devoluções e valores de receitas. Os dados estavam propositadamente desordenados — havia 1.847 valores em falta dispersos por diferentes colunas, algumas entradas duplicadas, inconsistências nos formatos de data e alguns outliers óbvios (como uma encomenda de 99.999 $ que era claramente um erro de introdução de dados).

O meu prompt era directo: "Analisa este ficheiro CSV. Identifica as principais tendências, assinala problemas de qualidade de dados e fornece 5 recomendações de negócio accionáveis com evidência de suporte extraída dos dados."

A resposta do Claude

O Claude identificou imediatamente os problemas de qualidade dos dados — todos os 1.847 valores em falta, os duplicados e o outlier. O que me impressionou foi a profundidade da análise. Não se limitou a dizer "a electrónica é a sua categoria principal." Decompôs a receita por categoria, cruzou-a com as taxas de devolução e apontou que, embora a electrónica tivesse a maior receita bruta, o panorama da receita líquida era diferente por causa de uma taxa de devolução de 23%.

As cinco recomendações eram específicas e assentes em dados concretos. Por exemplo: "Considere reduzir o limiar de envio gratuito de 75 $ para 50 $ na categoria de artigos para o lar — as encomendas entre 50 $ e 75 $ nesta categoria mostram uma taxa de abandono de carrinho de 34%, e o custo médio de envio de 8,20 $ seria compensado pelo aumento de 12% na conversão." É o tipo de análise que realmente ajuda quem toma decisões.

O Claude também criou voluntariamente uma matriz de correlação e identificou um padrão sazonal que eu não tinha notado — as devoluções do terceiro trimestre eram 40% mais elevadas do que nos outros trimestres, concentradas na categoria de vestuário, provavelmente devido às compras de regresso às aulas com alta taxa de devoluções por erros de tamanho.

A resposta do GPT-4o

O GPT-4o adoptou uma abordagem mais estruturada. Organizou a análise em secções claras com cabeçalhos e gerou até código Python para cada passo da análise. O código era limpo, bem comentado e efectivamente executável — testei-o. Usava conceitos de pandas profiling e criou código de visualização com matplotlib e seaborn.

A identificação de problemas de qualidade de dados foi boa, mas não tão completa. Detectou os valores em falta e o outlier, mas falhou as entradas duplicadas (havia 23). As recomendações de negócio eram sólidas mas mais genéricas — coisas como "foca o investimento em marketing nas categorias de maior desempenho", sem a análise de limiares específicos que o Claude forneceu.

Onde o GPT-4o realmente brilhou foi no código gerado. Se precisasse de construir um pipeline automatizado com base nesta análise, o GPT-4o deu-me uma enorme vantagem de partida. O código era modular, tinha tratamento de erros e até docstrings.

A resposta do Gemini

O Gemini 1.5 Pro processou o ficheiro rapidamente e forneceu uma visão geral abrangente. Lidou com o tamanho do ficheiro sem problemas (o que nem sempre acontecia com versões anteriores). A análise cobriu bem os aspectos básicos — categorias principais, tendências de receita, segmentos de clientes.

Mas a profundidade não estava ao nível dos outros dois. As recomendações eram superficiais: "Melhorar a retenção de clientes" e "Optimizar o mix de produtos." Não estão erradas, mas também não são accionáveis. Um responsável de negócio que as lesse perguntaria imediatamente "Como?" — e a resposta não estava no output do Gemini.

O Gemini fez algo interessante: criou automaticamente uma tabela resumo comparando as taxas de crescimento mês a mês que era fácil de analisar. E foi o único modelo que sinalizou uma potencial inconsistência de moeda em 12 linhas onde os valores sugeriam que podiam estar noutra moeda.

Pontuações do Teste 1

Teste 2: Geração de SQL em 3 tabelas relacionadas

O esquema

Dei a cada modelo um esquema com três tabelas: customers (customer_id, name, email, signup_date, plan_type, region), orders (order_id, customer_id, product_id, order_date, quantity, unit_price, discount_pct, status) e products (product_id, name, category, subcategory, cost_price, list_price, supplier_id, is_active).

Depois fiz cinco perguntas de complexidade crescente:

1. Mostra-me os 10 melhores clientes por gasto total nos últimos 90 dias, incluindo o tipo de plano e o número de encomendas
2. Calcula a taxa de crescimento de receita mês a mês para cada categoria de produto, mas apenas para categorias com pelo menos 100 encomendas por mês
3. Encontra clientes que fizeram downgrade do plano (de premium para básico) E cuja frequência de encomendas caiu mais de 50% em comparação com os seus primeiros 3 meses
4. Gera uma análise de coortes mostrando as taxas de retenção por mês de registo, onde "retido" significa pelo menos uma encomenda em cada mês subsequente
5. Identifica produtos onde a percentagem de desconto está a consumir mais de 30% da margem, agrupado por fornecedor, com um total acumulado

O SQL do Claude

O Claude produziu SQL correcto para todas as cinco queries à primeira tentativa. As queries estavam bem estruturadas, usando CTEs (Common Table Expressions) que tornavam a lógica fácil de seguir. Para a query de análise de coortes, que é notoriamente complicada, o Claude usou uma abordagem limpa com CROSS JOIN para gerar a grelha completa de coortes e LEFT JOIN para preencher os números reais de retenção. Isto significou que o output mostrou correctamente zeros para os meses em que não havia clientes retidos, em vez de simplesmente omitir essas linhas.

O Claude também adicionou comentários a explicar a lógica de negócio por detrás de cada passo, algo que aprecio sempre. Também assinalou casos extremos — por exemplo, indicou que a query de desconto-margem assume que discount_pct se aplica a list_price e não a cost_price, e perguntou se isso estava correcto.

A única ressalva: uma query usou uma sintaxe de função de janela específica do PostgreSQL que não funcionaria no MySQL sem modificação. O Claude não especificou o dialecto que estava a usar.

O SQL do GPT-4o

O GPT-4o também acertou em todas as cinco queries, e a qualidade do código foi possivelmente a melhor dos três. Cada query veio com o dialecto SQL especificado (usou PostgreSQL por defeito mas ofereceu alternativas para MySQL), notas de desempenho sobre que índices ajudariam, e planos de execução estimados para tabelas grandes.

A query de análise de coortes era elegante — usou uma abordagem ligeiramente diferente com date_trunc e generate_series que era mais concisa do que a do Claude, sendo igualmente correcta. O GPT-4o também apresentou os resultados da query numa tabela formatada a mostrar o aspecto que o output teria, o que foi útil para validação.

O GPT-4o foi além ao sugerir uma vista materializada para a query de crescimento de receita: "Se vai executar isto regularmente, considere criar uma vista materializada que se refresca diariamente. Aqui está o DDL..." É o tipo de pensamento orientado para produção que distingue o bom do excelente.

O SQL do Gemini

O Gemini acertou nas queries 1, 2 e 5. A query 3 tinha um erro lógico — comparou as alterações de plano olhando para o campo plan_type actual, mas não teve em conta que o esquema apenas armazena o plano actual, não o histórico. Assumiu que existia uma tabela plan_history que não existia. Quando lho apontei, corrigiu-se, mas recorde-se — este era um teste de tentativa única.

A query 4 (análise de coortes) era funcionalmente correcta, mas tinha um problema de desempenho: usava subconsultas correlacionadas em vez de joins, o que num conjunto de dados grande seria significativamente mais lento. A lógica estava certa, mas não quereria executá-la numa tabela com milhões de linhas.

O Gemini destacou-se na explicação do contexto de negócio de cada query. As suas explicações sobre o que é a análise de coortes e porque é que a análise de margem importa foram as mais claras dos três, tornando-o uma boa ferramenta de aprendizagem.

Pontuações do Teste 2

Teste 3: Resumo de PDF de 47 páginas

O documento

Usei um documento real (anonimizado) de revisão trimestral de negócio — 47 páginas com tabelas financeiras, iniciativas estratégicas, avaliações de risco, KPIs departamentais e uma apresentação ao conselho de administração incorporada no final. O documento tinha cerca de 28.000 palavras com 14 tabelas e 8 gráficos descritos em texto.

O meu prompt: "Resume este documento de forma a que um executivo de topo possa lê-lo em 5 minutos e entrar numa reunião do conselho completamente preparado. Destaca os 3 maiores riscos, as 2 oportunidades mais promissoras e quaisquer números que pareçam inconsistentes com a narrativa."

O resumo do Claude

O Claude produziu um resumo conciso e bem organizado de cerca de 800 palavras — genuinamente legível em 5 minutos. Os três riscos que identificou eram exactamente os certos: concentração da cadeia de abastecimento (72% de uma única região), a tendência do custo de aquisição de clientes (34% mais elevado trimestre a trimestre enquanto o LTV estava estagnado), e um prazo de conformidade que a narrativa mencionava casualmente na página 38, mas que era na verdade um risco regulatório importante.

A secção de oportunidades também foi boa, destacando uma jogada de expansão de mercado e um acordo de parceria com condições favoráveis. Mas onde o Claude realmente ganhou a sua pontuação foi na secção de "números que não batem certo". Detectou que a cifra de receita na página 12 (14,2 M$) não correspondia à soma dos desdobramentos regionais na página 23 (13,8 M$), e sinalizou que os números de efectivo na secção de RH implicavam uma taxa de rotatividade de 18% que contradizia a narrativa de "forte retenção" na página 7.

Esse tipo de cruzamento de referências ao longo de um documento extenso é exactamente o que preciso que uma IA faça. Tinha estado a ler esse documento durante uma hora e não tinha reparado em nenhuma dessas discrepâncias.

O resumo do GPT-4o

O resumo do GPT-4o era bem estruturado e profissional. Usou os pontos de lista de forma eficaz e organizou a informação por departamento. A identificação de riscos foi sólida — detectou o problema da cadeia de abastecimento e o problema do CAC, mas falhou o prazo de conformidade na página 38.

O resumo era mais longo do que o do Claude (cerca de 1.200 palavras), o que comprometia o requisito de "leitura de 5 minutos". Incluiu mais detalhe sobre o desempenho departamental, o que é útil mas não era o que pedi. O GPT-4o tende para a exaustividade em vez da concisão quando lida com documentos longos.

No pedido de "números que não batem certo", o GPT-4o detectou a discrepância de receitas, mas não a contradição na taxa de rotatividade. Detectou algo que os outros não viram — notou que a taxa de crescimento projectada para o terceiro trimestre assumia um padrão de sazonalidade de 2024, mas os dados de 2025 mostravam que o padrão sazonal tinha mudado cerca de 6 semanas, tornando a projecção do terceiro trimestre potencialmente demasiado optimista em 8-12%.

O resumo do Gemini

É aqui que a grande janela de contexto do Gemini se revelou vantajosa. Processou todas as 47 páginas sem qualquer segmentação ou artefactos de resumo. O resumo era abrangente e preciso, cobrindo todas as principais secções do documento. Lidou particularmente bem com as tabelas financeiras, extraindo métricas-chave e apresentando-as num formato limpo.

O Gemini identificou o risco da cadeia de abastecimento e um risco de concorrência de mercado que os outros dois não enfatizaram. No entanto, tratou o documento mais como um resumo capítulo a capítulo do que como um briefing estratégico. Um executivo de topo obteria toda a informação, mas teria de fazer ele próprio a síntese do "e então?".

A auditoria de números foi a mais fraca dos três. O Gemini confirmou os números do documento sem os cruzar entre secções. Disse essencialmente que "as cifras financeiras são consistentes com a narrativa" — o que não era verdade, como o Claude demonstrou.

Mas quero reconhecer algo ao Gemini: o seu tratamento dos gráficos incorporados. Embora não pudesse ver as imagens reais, referenciou as descrições textuais dos gráficos e assinalou correctamente que dois gráficos descreviam tendências contraditórias (um mostrava quota de mercado crescente enquanto outro mostrava uma posição competitiva relativa em declínio). É uma observação subtil.

Pontuações do Teste 3

Resultados globais

A minha opinião honesta: quando usar cada um

Use o Claude quando: precisar de raciocínio analítico profundo, cruzamento de referências em documentos extensos, ou insights prontos para o negócio que vão além das observações superficiais. O Claude forneceu consistentemente a análise mais matizada e detectou detalhes que os outros falharam. Se é um analista de dados a apresentar a stakeholders, o Claude dá-lhe o "e então?" que transforma dados em decisões.

Use o GPT-4o quando: precisar de código de qualidade para produção, SQL bem documentado, ou uma análise pronta para pipelines. O código do GPT-4o foi consistentemente o mais limpo e o mais pronto para produção. Se está a construir algo, e não apenas a analisar, o GPT-4o é a sua melhor aposta. As sugestões de optimização de desempenho foram um bónus bem-vindo.

Use o Gemini quando: trabalhar com documentos massivos ou precisar de processar muito contexto de uma vez. A grande janela de contexto do Gemini é genuinamente útil para documentos muito longos, e lidou com as 47 páginas completas sem dificuldade. É também o melhor em explicações e ensino, o que o torna valioso para aprender novos conceitos.

E o custo?

Os três oferecem planos de consumo a 20 $/mês. Para uso de API, a coisa fica mais complexa:

O Gemini ganha no preço por uma margem significativa. Se o custo é a sua principal preocupação e a diferença de profundidade não importa para o seu caso de uso, é difícil argumentar contra a proposta de valor do Gemini.

Limitações deste teste

Quero ser transparente sobre o que este teste não lhe diz:

• Estes modelos actualizam-se constantemente. O que é verdade hoje pode não o ser daqui a três meses. Tentarei repetir esta comparação trimestralmente.
• Enviesamento da tentativa única. Os modelos de IA podem dar resultados diferentes com o mesmo prompt. Executar cada teste 10 vezes e calcular a média seria mais rigoroso, mas não era prático.
• A minha avaliação é subjectiva. Outro analista pode valorizar mais a qualidade do código do que a profundidade analítica e chegar a conclusões diferentes.
• Não testei capacidades multimodais. Se a sua análise de dados envolve imagens, gráficos ou vídeo, essa é uma comparação completamente diferente.
• Os limites da janela de contexto importam mais em alguns fluxos de trabalho. Se processa habitualmente documentos de mais de 100 páginas, a vantagem do Gemini torna-se muito mais significativa.

Com o que fico

Após este teste, fico com as três subscrições — mas uso-as de forma diferente de antes. O Claude é a minha ferramenta principal para análise e revisão de documentos. O GPT-4o trata das minhas tarefas de programação e construção de pipelines. O Gemini entra em acção quando preciso de processar algo massivo ou quando estou a aprender um novo domínio e preciso de explicações claras.

São 60 $/mês muito dinheiro? Sim. Mas tendo em conta que estou a substituir o que antes eram horas de trabalho manual por semana, é provavelmente o melhor ROI de qualquer subscrição de ferramentas que tenho.

Se tivesse de ficar apenas com uma, seria o Claude para trabalho de análise de dados. A profundidade analítica e a capacidade de cruzamento de referências salvou-me de apresentar números incorrectos a um cliente — uma vez. Só isso pagou um ano de subscrição.

Mas, honestamente, a diferença entre o Claude e o GPT-4o é suficientemente pequena para que a sua experiência possa variar. Experimente os três nas SUAS tarefas específicas antes de se comprometer. O que funciona para o meu fluxo de trabalho pode não corresponder ao seu.

O que vem a seguir

Planeio realizar testes semelhantes sobre geração de visualizações (conseguem estes modelos criar bons gráficos directamente?), análise de dados em tempo real (cenários de streaming) e processamento de dados em múltiplos idiomas. Se tiver cenários específicos que gostaria que eu testasse, deixe um comentário ou contacte-me.

O panorama da análise de dados com IA está a mover-se a uma velocidade incrível. O modelo que é o melhor hoje pode não o ser no próximo trimestre. Mas agora mesmo, para o trabalho que faço, é aqui que as coisas estão.