Pontuações de benchmarks mascaram falhas de LLMs em tarefas multietapas

A acurácia de primeira resposta dos grandes modelos de linguagem em tarefas procedurais cai de 61% em algoritmos de 5 etapas para 20% em algoritmos de 95 etapas, contradizendo diretamente a suposição de que pontuações fortes em benchmarks indicam execução confiável em fluxos de trabalho de produção.

O artigo "When LLMs Stop Following Steps: A Diagnostic Study of Procedural Execution in Language Models" de Sailesh Panda, Pritam Kadasi, Abhishek Upperwal e Mayank Singh avalia 14 modelos em 55 datasets. O benchmark é simples: modelos recebem um algoritmo aritmético passo a passo e dois inputs numéricos e devem retornar o valor final computado. A complexidade escala através do comprimento do algoritmo e dependências de look-back em variáveis intermediárias — o desafio estrutural que fluxos de trabalho corporativos impõem.

O design do benchmark expõe um intervalo que avaliações de raciocínio padrão obscurecem. Métricas de acurácia de resposta final dominam a cultura de leaderboards mas dizem nada sobre se um modelo executou fielmente cada etapa. Um modelo pode chegar a uma resposta correta via heurísticas de atalho ou cancelamentos de sorte e ainda falhar catastroficamente quando esses atalhos não estão disponíveis em traços mais longos e pesados em dependência. A análise de nível de geração revela os modos de falha: respostas prematuras, respostas ausentes, autocorreção após um erro inicial, traços sub-executados e etapas alucinadas além do que o algoritmo especifica.

Para arquitetos corporativos, as implicações são diretas. Qualquer implantação que usa um LLM para executar um processo multietapas determinístico — pipelines de ETL, listas de verificação de conformidade, runbooks de DevOps, fluxos de trabalho de reconciliação financeira — depende de um agente cuja confiabilidade degrada conforme o comprimento do procedimento aumenta. Com 20% de acurácia de primeira resposta em tarefas de 95 etapas em 14 modelos testados, este não é um caso extremo de modelo único. É um modo de falha em toda a classe. A queda de 61% para 20% abrange 90 etapas adicionais.

A exposição prática difere por caso de uso. Fluxos de trabalho curtos e limitados de cinco a dez etapas ficam em uma zona onde a acurácia permanece acima de 60%. Mas camadas de orquestração que encadeiam ferramentas, ramificações condicionais ou loops iterativos rapidamente empurram o comprimento de procedimento efetivo para faixas onde a probabilidade de falha domina. Pipelines de RAG com lógica de recuperação de múltiplos saltos, loops de geração de código agênticos e playbooks de resposta a incidentes automatizados são candidatos para confiabilidade de execução degradada.

Se estratégias de prompting — chain-of-thought, aplicação de scratchpad, rotulagem de etapas explícita — podem recuperar acurácia perdida em escala permanece aberto. Os autores atribuem falha parcialmente a "aparente habilidade de raciocínio mascarando fraquezas substanciais em execução fiel de instruções", apontando para dados de treinamento e funções objetivas em vez de engenharia de prompts como a correção mais durável.

Para equipes avaliando infraestrutura de LLM, a ação mínima é operacional: adicionar testes de execução procedural que combinem a contagem de etapas e estrutura de dependência de seus fluxos de trabalho reais antes de aprovar qualquer implantação agêntica. Pontuações de benchmark em MMLU ou GSM8K são o sinal errado para este problema.