Shopping cart

Subtotal $0.00

View cartCheckout

Building better devs

TnewsTnews
  • Home
  • IA
  • GPT-5.5 Não Sabe Lambda Calculus — e Um Brasileiro Provou
IA

GPT-5.5 Não Sabe Lambda Calculus — e Um Brasileiro Provou

Lambda calculus benchmark LamBench testando modelos de IA
Email : 15

A OpenAI gastou bilhões treinando o GPT-5.5. Prometeram o modelo mais avançado da história, um “super app” que faz de tudo. Só que quando um desenvolvedor brasileiro sentou e fez 120 perguntas de cálculo lambda — o fundamento mais básico da computação — o modelo mais caro do mercado tirou 78%. O GPT-5.4, mais velho e mais barato, tirou 91%.

Eu vou repetir: o modelo anterior é melhor em programação fundamental do que o sucessor.

Quem revelou isso foi Victor Taelin, criador do HVM e da linguagem Bend, com um benchmark chamado LamBench. E os resultados acenderam um debate que a indústria de IA preferia evitar: modelos maiores e mais caros não são necessariamente mais inteligentes.

Quem é Victor Taelin (e por que você deveria conhecê-lo)

Victor Taelin é um programador do Rio de Janeiro que trabalha com cálculo lambda há mais de uma década. Ele fundou a Higher Order Company e criou ferramentas que fazem gente séria em ciência da computação prestar atenção.

O HVM (Higher-order Virtual Machine) é um runtime que executa cálculo lambda de forma otimamente paralela. Enquanto a maioria dos runtimes funciona sequencialmente, o HVM explora uma técnica chamada interaction nets — criada pelo matemático francês Yves Lafont — para fazer cada redução de lambda de forma independente. Na prática, isso significa que programas funcionais escalam linearmente com o número de cores disponíveis.

Já o Bend é uma linguagem de programação que parece Python mas roda nativamente em GPUs. Sem CUDA, sem programação paralela manual. Você escreve código que parece sequencial e o compilador faz a mágica de distribuir o trabalho entre milhares de threads.

ProjetoO que fazLicença
HVMRuntime paralelo para cálculo lambdaApache 2.0
BendLinguagem Python-like que roda em GPUApache 2.0
KindLinguagem com tipos dependentes e provas formaisApache 2.0
Interaction CalculusModelo de computação baseado em redes de interaçãoOpen Source

Com esse histórico, quando Taelin cria um benchmark de lambda calculus, ele sabe exatamente o que está testando.

O que é o LamBench

O LamBench é um conjunto de 120 problemas de programação em lambda calculus puro. Não é um quiz de múltipla escolha. Não é um “complete o código”. Cada problema exige que o modelo escreva um programa completo em Lamb, uma linguagem minimalista de cálculo lambda, e o programa precisa passar em testes automatizados.

As questões vão do trivial ao absurdo:

Fáceis:

  • Implementar adição para números naturais de Church
  • Escrever uma função head para listas em lambda calculus
  • Criar um destrutor para um tipo algébrico customizado

Médias:

  • Derivar um fold genérico para tipos algébricos arbitrários
  • Implementar ordenação para listas codificadas em lambda
  • Calcular o MDC (maior divisor comum) usando números de Church

Difíceis:

  • Implementar FFT (Fast Fourier Transform) com numerais de Church
  • Fazer BFS em árvores codificadas em lambda puro
  • Calcular a função totiente de Euler em representação binária

As categorias são organizadas em famílias:

algo_*  → Algoritmos (brute force, recursão, DP, maze solving, TSP...)
cnat_*  → Operações com naturais de Church (add, multiply, GCD, primo...)
cbin_*  → Operações com binários customizados (raiz quadrada, log, totiente...)
clst_*  → Listas em lambda (sort, zip, dot product, fold...)
ctre_*  → Árvores (BFS, FFT, merge, rotação, scan...)
cadt_*  → Tipos algébricos customizados (fold, equality, serialization...)

O ponto crucial: nada disso envolve bibliotecas, frameworks ou APIs. É computação pura. Se uma IA realmente entende programação em um nível fundamental, ela deveria acertar a maioria dessas questões. Se ela só memorizou padrões do Stack Overflow, ela quebra aqui.

O ranking que ninguém esperava

Aqui está a tabela completa dos modelos testados. Prepara que os números são reveladores:

PosiçãoModeloScoreAcuráciaTempo Médio
1OpenAI GPT-5.4110/12091.7%357.5ms
2Anthropic Opus 4.6108/12090.0%423.6ms
3OpenAI GPT-5.3-codex107/12089.2%147.2ms
4Anthropic Opus 4.7106/12088.3%137.7ms
5Google Gemini 3.1 Pro106/12088.3%120ms
Anthropic Sonnet 4.699/12082.5%
OpenAI GPT-5.594/12078.3%
OpenAI GPT-5.293/12077.5%
Kimi K2-thinking34/12028.3%

Leia de novo: o GPT-5.5 ficou atrás do GPT-5.4 por quase 14 pontos percentuais. E não é um caso isolado — o Opus 4.7 também ficou ligeiramente atrás do Opus 4.6.

Isso destrói uma narrativa que a indústria adora vender: a de que cada nova versão é automaticamente melhor que a anterior.

Por que o GPT-5.5 fracassou (e o que isso revela)

Quando a OpenAI lançou o GPT-5.5, o marketing foi claro: um modelo generalista, o “super app” da IA, capaz de fazer de tudo — desde agendar reuniões até escrever código. E de fato, em benchmarks tradicionais como MMLU e HumanEval, o GPT-5.5 se saiu bem.

O problema é que generalismo e profundidade são trade-offs.

O GPT-5.4 foi otimizado como modelo de código. Ele entende padrões de programação em um nível mais profundo porque o treinamento priorizou esse tipo de raciocínio. Já o GPT-5.5 foi treinado para ser bom em tudo — atendimento ao cliente, escrita criativa, análise de dados, programação — e quando você tenta ser bom em tudo, inevitavelmente perde especificidade.

Lambda calculus é o caso perfeito para expor isso. Diferente de problemas de programação convencionais (onde o modelo pode se apoiar em milhões de exemplos de Stack Overflow, GitHub e documentações), lambda calculus puro aparece com frequência muito menor nos dados de treinamento. Um modelo que realmente “entende” computação deveria derivar soluções a partir de princípios fundamentais. Um modelo que decorou padrões vai travar.

-- Exemplo: adição em lambda calculus (Church numerals)
-- Parece simples, mas exige entender a representação

add = λm. λn. λf. λx. m f (n f x)

-- Agora tente multiplicação:
mul = λm. λn. λf. m (n f)

-- E exponenciação:
exp = λm. λn. n m

Para quem programa no dia a dia, isso parece um exercício acadêmico. Mas a questão vai muito além: se um modelo não consegue manipular abstrações fundamentais de computação, até que ponto ele realmente “entende” o código que gera? Ou está apenas combinando fragmentos de código que viu durante o treinamento?

O problema da FFT que nenhuma IA resolveu

De todos os 120 problemas do LamBench, os de FFT (Fast Fourier Transform) foram os que nenhum modelo — nenhum — conseguiu resolver.

A FFT é um algoritmo que normalmente opera sobre arrays mutáveis e números de ponto flutuante. Implementá-la usando numerais de Church e estruturas imutáveis em lambda calculus puro é um problema completamente diferente. Não existe um exemplo disso no GitHub. Não existe tutorial no Stack Overflow. O modelo precisa inventar a solução do zero.

Isso expõe uma limitação real dos LLMs: quando o problema exige criatividade algorítmica genuína — não adaptação de padrões conhecidos, mas invenção — todos falham. Sem exceção.

“A FFT com Church numerals é como pedir para alguém construir um avião usando apenas LEGO. Teoricamente possível, mas ninguém nunca fez isso na prática, então o modelo não tem referência.”

As críticas (e por que elas importam)

O LamBench não passou ileso pelo escrutínio do Hacker News. Duas críticas principais surgiram:

1. Teste de tentativa única

Cada modelo foi testado apenas uma vez por questão. Isso é um problema porque LLMs são não-determinísticos — a mesma pergunta pode gerar respostas diferentes a cada execução. Um comentarista argumentou que seria necessário rodar cada questão pelo menos 45 vezes para ter significância estatística.

Na prática, isso significa que o GPT-5.5 poderia ter se saído melhor (ou pior) em outra rodada. O gap de 14 pontos para o GPT-5.4 provavelmente não desapareceria, mas poderia diminuir.

2. Ambiguidade nos prompts

Alguns problemas usam sistemas de números e codificações específicas que não são óbvias só lendo o enunciado. Modelos que não estão familiarizados com essas convenções partem em desvantagem. A crítica aqui é válida: será que o benchmark testa conhecimento de lambda calculus ou familiaridade com as convenções do Victor Taelin?

Taelin respondeu a essas críticas no Twitter, argumentando que o benchmark foi desenhado para testar raciocínio fundamental, não memorização. E que os modelos que realmente entendem lambda calculus conseguem inferir as convenções a partir do contexto.

O que os comentários do Hacker News revelaram

Além das críticas técnicas, a discussão no HN trouxe um insight importante sobre o mercado de IA:

Modelos baratos vs. modelos caros não é a comparação certa.

Vários comentaristas notaram que modelos menores e mais baratos frequentemente superam modelos grandes em tarefas específicas. O Kimi K2-thinking, por exemplo, que marketing agressivo posicionou como “melhor que o Claude e GPT em código”, tirou míseros 28% no LamBench. O modelo com melhor marketing nem sempre é o melhor em fundamentos.

Outro ponto interessante: o Gemini 3.1 Pro empatou com o Opus 4.7 (106/120) mas com o menor tempo médio de resposta (120ms contra 137ms). Se velocidade importa para sua aplicação, o modelo do Google é uma escolha surpreendentemente boa.

A conclusão que a comunidade do HN chegou é sóbria: benchmarks tradicionais mascaram diferenças fundamentais entre modelos. Um modelo pode tirar nota alta em HumanEval (gerando funções Python típicas) e fracassar completamente quando o problema exige raciocínio abstrato.

Por que lambda calculus importa para programadores “normais”

“Tá, mas eu nunca vou escrever lambda calculus no meu dia a dia.” Verdade. Mas a relevância não é direta — é o que o teste revela sobre a capacidade da IA.

Se você usa Copilot, Cursor ou Claude Code para programar, o que o LamBench mostra é que a IA que te ajuda pode estar combinando padrões sem entender por que o código funciona. Na maioria das vezes, isso não importa — se o código gerado passa nos testes, quem liga se a IA “entende” ou não?

O problema aparece quando o bug é sutil. Quando o edge case não está nos dados de treinamento. Quando você precisa de uma solução que ninguém implementou antes. Nesses momentos, a diferença entre um modelo que entende fundamentos e um que decora padrões fica gritante.

Lambda calculus é o canário na mina de carvão. Se um modelo falha aqui, ele vai falhar em qualquer problema que exija raciocínio computacional genuíno.

A mensagem de Taelin para a indústria

Victor Taelin não criou o LamBench para provar que IAs são ruins. Ele criou porque acredita que a indústria está otimizando para os benchmarks errados.

Os benchmarks mais usados hoje — MMLU, HumanEval, MATH — foram criados para medir habilidades gerais. E os modelos se saem cada vez melhor neles porque… são treinados especificamente para isso. É o equivalente de estudar a prova em vez de estudar o conteúdo.

O LamBench é diferente porque:

  1. As questões são originais — não existem nos dados de treinamento
  2. Não há atalho — ou o modelo entende lambda calculus, ou não
  3. Os testes são automatizados — o programa precisa rodar e dar o resultado correto, não basta parecer certo

Isso cria uma pressão evolutiva saudável. Se os labs de IA levarem benchmarks como o LamBench a sério, os modelos futuros vão precisar de raciocínio real, não apenas memorização em escala.

Como rodar o LamBench nos seus modelos

O projeto é completamente open source. Se você quer testar seu modelo favorito:

# Clone o repositório
git clone https://github.com/VictorTaelin/LamBench
cd LamBench

# Instale as dependências
npm install

# Rode o benchmark com um modelo específico
node run.js --model openai/gpt-5.5

# Ou com um modelo local via API compatível
node run.js --model local/llama-70b --api-url http://localhost:8080

Os resultados são gerados em JSON e podem ser comparados com os scores oficiais no site do projeto.

Uma observação: se você for rodar múltiplas vezes para verificar variância (o que eu recomendo), o custo em tokens pode subir rápido com modelos pagos. Cada rodada completa usa cerca de 120 prompts, cada um com contexto substancial.

O benchmark como espelho da indústria

O LamBench chegou num momento perfeito. A indústria de IA está numa corrida armamentista onde cada empresa anuncia que seu novo modelo é “o melhor de todos” — baseado em benchmarks que, como acabamos de ver, nem sempre medem o que importa.

O GPT-5.5 é um modelo impressionante. Ele faz coisas que pareciam ficção há dois anos. Mas ele não é melhor que o GPT-5.4 em tudo, e benchmarks como o LamBench ajudam a entender onde cada modelo realmente se destaca.

Se você é desenvolvedor e usa IA como ferramenta, a lição prática é: não assuma que o modelo mais novo é o melhor para sua tarefa. Teste. Meça. E quando encontrar um benchmark que testa fundamentos, preste atenção — porque é ali que as máscaras caem.

O código do LamBench está em github.com/VictorTaelin/LamBench e os resultados atualizados ficam em victortaelin.github.io/lambench.


Fonte de inspiração: LamBench — Lambda Calculus Benchmark for AI (Hacker News)

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts