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.
| Projeto | O que faz | Licença |
|---|---|---|
| HVM | Runtime paralelo para cálculo lambda | Apache 2.0 |
| Bend | Linguagem Python-like que roda em GPU | Apache 2.0 |
| Kind | Linguagem com tipos dependentes e provas formais | Apache 2.0 |
| Interaction Calculus | Modelo de computação baseado em redes de interação | Open 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
headpara 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ção | Modelo | Score | Acurácia | Tempo Médio |
|---|---|---|---|---|
| 1 | OpenAI GPT-5.4 | 110/120 | 91.7% | 357.5ms |
| 2 | Anthropic Opus 4.6 | 108/120 | 90.0% | 423.6ms |
| 3 | OpenAI GPT-5.3-codex | 107/120 | 89.2% | 147.2ms |
| 4 | Anthropic Opus 4.7 | 106/120 | 88.3% | 137.7ms |
| 5 | Google Gemini 3.1 Pro | 106/120 | 88.3% | 120ms |
| — | Anthropic Sonnet 4.6 | 99/120 | 82.5% | — |
| — | OpenAI GPT-5.5 | 94/120 | 78.3% | — |
| — | OpenAI GPT-5.2 | 93/120 | 77.5% | — |
| — | Kimi K2-thinking | 34/120 | 28.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:
- As questões são originais — não existem nos dados de treinamento
- Não há atalho — ou o modelo entende lambda calculus, ou não
- 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)













