Resumo Técnico: O Código é Melhor que a Linguagem para o Raciocínio Algorítmico?

Declaração do Problema

Em sistemas de modelos de linguagem (LLM) aumentados por ferramentas, é bem estabelecido que traduzir problemas em código executável por um solver (delegando a execução a uma ferramenta externa) frequentemente supera o raciocínio de linguagem natural (NL) de ponta a ponta em tarefas algorítmicas complexas. No entanto, a origem desse ganho de desempenho permanece ambígua. Comparações anteriores confundem dois fatores distintos:

1. Representação Intermediária: A mudança de traços de linguagem natural para traços de código.
2. Mecanismo de Execução: A mudança da simulação baseada em LLM (passagem direta/forward pass) para a execução externa determinística (ex: runtime de Python).

Como estudos anteriores compararam "raciocínio em NL" diretamente contra "Código + Execução Externa", eles não puderam isolar se a melhoria decorreu da natureza estruturada do código, da confiabilidade do executor externo ou de ambos. Este artigo aborda a seguinte questão de pesquisa: A representação em código é inerentemente superior à linguagem natural para o raciocínio algorítmico, ou a vantagem é impulsionada principalmente pela execução externa confiável?

Metodologia: O Framework de Três Rotas

Para desmembrar a representação da execução, os autores propõem um Framework de Três Rotas sistemático que decompõe o pipeline de raciocínio em dois estágios: Geração de Traço e Execução.

• Rota 1 (NL Direta): O LLM gera um traço de Cadeia de Pensamento (Chain-of-Thought) em linguagem natural e, subsequentemente, utiliza o mesmo LLM para simular o raciocínio e produzir uma resposta.
  • Traço: Linguagem Natural.
  • Executor: LLM (Simulação em NL).
• Rota 2 (Código + Simulação em NL): O LLM gera um traço de código (ex: Python), mas em vez de executá-lo externamente, o mesmo LLM simula a execução do código em linguagem natural para produzir uma resposta.
  • Traço: Código.
  • Executor: LLM (Simulação de código).
• Rota 3 (Código + Execução por Solver): O LLM gera o mesmo traço de código da Rota 2, mas o código é executado por um runtime Python externo e determinístico.
  • Traço: Código.
  • Executor: Solver Externo (Determinístico).

Configuração Experimental:

• Benchmark: Um benchmark algorítmico verificável de 40 tarefas cobrindo aritmética, programação dinâmica, algoritmos de grafos, manipulação de strings, geometria, ordenação e otimização NP-difícil.
• Dados: 1.113 instâncias de problemas únicas através de 3 sementes aleatórias, avaliadas em 6 modelos (incluindo modelos de código fechado como GPT-4o-mini e de código aberto como Mixtral-8x22b).
• Métricas: Precisão da tarefa final sob perda 0–1, analisada via testes estatísticos pareados (McNemar) e intervalos de confiança de cluster-bootstrap.

Contribuições Principais

1. Desmembramento Empírico de Fatores

O framework permite comparações pareadas que isolam variáveis específicas:

• Rota 1 vs. Rota 2 (Isolando a Representação): Mantendo o executor LLM constante e alterando apenas a modalidade do traço (NL vs. Código), os autores testam se a representação em código oferece, por si só, alguma vantagem.
• Rota 2 vs. Rota 3 (Isolando a Execução): Mantendo o traço de código constante e alterando apenas o executor (simulação de LLM vs. runtime Python), os autores testam se o mecanismo de execução é o motor do desempenho.

2. Formalização Teórica (Modelo Teórico de Decisão)

Os autores formalizam a intuição de que o código é uma "canonicalização" da linguagem natural. Eles propõem um modelo linear onde:

• Ambos os traços compartilham um núcleo ($B$) contendo informações algorítmicas relevantes para a decisão (ex: relações de recorrência).
• Traços de linguagem natural contêm variação de ruído adicional ($\eta_N$), como paráfrases, verbosidade e escolhas estilísticas que não alteram a resposta.
• Teorema: Sob este modelo, o código é não-inferior em representação à linguagem natural. O ruído adicional na linguagem natural aumenta o risco (erro) para aprendizes de amostra finita sem fornecer sinal adicional. Assim, mudar a representação sozinha não deve gerar ganhos significativos se o núcleo da informação for preservado.

3. Intervenção de Reconstrução

Para validar a teoria empiricamente, os autores realizam uma "intervenção de reconstrução". Eles pegam traços de código gerados pelo modelo e os traduzem de volta para linguagem natural usando uma transformação fixa. Eles descobrem que esses traços de NL traduzidos recuperam um desempenho comparável aos traços de NL nativos. Isso confirma que o código retém toda a informação relevante para a decisão e que a "perda" no raciocínio em NL não se deve à falta de conteúdo algorítmico, mas sim à presença de variação de ruído.

Resultados

Comparação de Desempenho

No benchmark de 40 tarefas, os resultados são os seguintes:

• Rota 1 (NL + NL): 17,21% de precisão.
• Rota 2 (Código + Simulação em NL): 17,37% de precisão.
• Rota 3 (Código + Execução Python): 48,84% de precisão.

Achados Estatísticos:

• Rota 1 vs. Rota 2: A diferença é de +0,15 pontos percentuais (pp), com um intervalo de confiança de 95% de $[-0,30, +0,61]$ pp ($p=0,39$). Isso indica que não há diferença estatisticamente significativa entre o raciocínio em linguagem natural e a simulação de código quando o executor é o mesmo LLM.
• Rota 2 vs. Rota 3: A diferença é de +31,47 pp, com um IC de 95% de $[+29,20, +33,71]$ pp ($p < 0,001$). Isso indica uma vantagem massiva e estatisticamente significativa para a execução externa determinística sobre a simulação por LLM, mesmo quando o traço de código é idêntico.

Escalonamento de Dificuldade

À medida que a dificuldade da tarefa aumenta (controlada por parâmetros como comprimento de dígitos ou tamanho de matriz), a Rota 3 mantém alta precisão enquanto as Rotas 1 e 2 degradam significativamente.

Análise de Recuperação

Os autores analisam casos em que a Rota 2 (simulação) tem sucesso, mas a Rota 3 (execução) falha ("massa de recuperação").

• Massa de Recuperação: 1,61% (Casos onde o LLM simula corretamente códigos falhos ou ignora falhas de execução).
• Massa de Vitória da Execução: 33,08% (Casos onde a execução tem sucesso, mas a simulação do LLM falha).
  Isso confirma que o LLM raramente compensa erros de execução; inversamente, o solver externo supera consistentemente a capacidade do LLM de simular o código.

Significância e Alegações

O artigo afirma que, no cenário avaliado de raciocínio algorítmico:

1. A representação não é o gargalo: A intervenção intermediária de usar traços de código não melhora significativamente o desempenho sobre os traços de linguagem natural quando o mecanismo de execução permanece um LLM. A lacuna de desempenho entre a Rota 1 e a Rota 2 é negligenciável.
2. A execução é o gargalo: O principal motor dos ganhos de desempenho observados em sistemas aumentados por ferramentas é a confiabilidade do executor externo, e não a natureza estruturada da própria representação de código.
3. Mecanismo de Uso de Ferramentas: A vantagem do uso de código baseia-se no fato de que ele permite a transferência de um traço gerado para um solver determinístico. A representação em código serve primariamente como um veículo para permitir essa execução confiável, em vez de atuar como um substrato de raciocínio superior para o próprio LLM.

Os autores concluem que, para tarefas algorítmicas com respostas verificáveis, a principal vantagem do uso de ferramentas é a capacidade de delegar a execução a um ambiente determinístico, e não a superioridade inerente do formato de código sobre a linguagem natural para o raciocínio.