Resumo Técnico: Raciocínio Guiado por Código para Modelos de Linguagem Pequenos

Declaração do Problema

Modelos de Linguagem Pequenos (SLMs) são frequentemente implantados em sistemas práticos não como respondedores isolados, mas como componentes dentro de estruturas que envolvem ferramentas externas, execução de código e chamadas repetidas ao modelo. No entanto, benchmarks padrão de Resposta a Questões de Múltipla Escolha (MCQA) avaliam os SLMs principalmente por meio de interações diretas de prompt-resposta, falhando em capturar o desempenho sob essas condições "estruturadas".

A questão central abordada por este trabalho é: O mesmo solucionador pequeno comporta-se de maneira diferente quando movido de um prompt de opção em linguagem natural direto para uma estrutura executável em Python, e essa diferença pode ser auditada? Os autores observam que, embora o código sozinho não garanta confiabilidade, os LLMs atuais funcionam como geradores de código e raciocinadores de domínio. Fluxos de trabalho implantados frequentemente combinam esses papéis, mas os protocolos de avaliação raramente distinguem entre a capacidade direta de um modelo e seu desempenho quando mediado por um controlador executável gerado.

Metodologia: Raciocínio Guiado por Código (CGR)

O artigo introduz o Raciocínio Guiado por Código (CGR), um protocolo de avaliação e pacote de rastreamento projetado para medir o impacto de estruturas de raciocínio executáveis em SLMs.

O Protocolo CGR

Para cada item de MCQA, o sistema gera uma saída de três canais:

1. Linha de Base Direta: O solucionador alvo responde à pergunta diretamente, emitindo uma única letra de opção.
2. Solucionador Assistido: Um LLM gerador escreve uma estrutura Python específica para o item. Esta estrutura armazena variáveis, ramifica a lógica, chama o helper do solucionador alvo múltiplas vezes, extrai respostas e aplica desempates. A "resposta assistida" final é a opção selecionada por essa lógica executável.
3. Resposta do Lado do Gerador: O LLM gerador também seleciona uma resposta dentro da lógica da estrutura (independentemente da saída do solucionador). Isso serve como um canal de diagnóstico para distinguir entre a melhoria do solucionador estruturado e o conhecimento do lado do gerador.

Fluxo de Execução

• Entrada: Um item de MCQA (pergunta, opções, rótulo dourado).
• Geração: Um LLM gerador produz uma função Python com um contrato de retorno fixo: (solverLLM_answer, genLLM_answer, genLLM_difficulty).
• Execução: A estrutura é executada, chamando o solucionador alvo por meio de uma interface helper (llm_model). Pode fazer múltiplas chamadas (por exemplo, para análise e verificação) e usa um extrator para analisar a primeira letra maiúscula independente (A–Z) das respostas.
• Pontuação: Os três canais (Direto, Assistido, Lado do Gerador) são pontuados separadamente contra o rótulo dourado.

Conjuntos de Dados e Modelos

A avaliação utiliza um pacote de MCQA normalizado e preparado localmente contendo 20.498 linhas de resultados retidas em nove configurações de conjunto de dados (incluindo MMLU-Pro, OpenBookQA, SuperGPQA, MedQA, Time-MQA, AIME e outros). Seis modelos solucionadores distintos foram avaliados, variando de modelos recentes compactos (Gemma 4 E2B, Nemotron-3-Nano-4B) a modelos anteriores ajustados para instruções e orientados a código (Granite 4H Small, Granite 8B Code, Llama 3.2 11B, Mistral Small 3.1 24B).

Estratégia de Particionamento

Para garantir a interpretabilidade, os autores definem uma partição de linha de base não nula. Esta inclui apenas pares de conjunto de dados–solucionador onde o solucionador alcançou pelo menos uma resposta correta na linha de base direta. Pares com precisão direta zero são tratados como uma "partição de diagnóstico de linha de base zero" separada, pois grandes ganhos ali podem refletir resgate de formato de prompt ou incompatibilidades de extração, em vez de melhoria genuína do solucionador.

Contribuições Principais

1. Configuração de Avaliação: O estudo estabelece a estruturação de MCQA executável como uma condição de avaliação distinta, observando o mesmo solucionador alvo sob promptagem direta e dentro de uma estrutura Python gerada, com pontuação separada para respostas diretas, assistidas e do lado do gerador.
2. Pacote de Rastreamento: Os autores lançam o pacote de rastreamento CGR, um recurso contendo 20.498 linhas de resultados, programas gerados, metadados de resposta e campos de auditoria. Isso permite a inspeção de contratos de estrutura, contagens de chamadas, falhas de extração e discrepâncias de canais de resposta.
3. Resultados Quantitativos: O artigo relata uma melhoria quantitativa específica e delimitada: na partição de linha de base não nula, a precisão macro assistida aumenta de 38,11% (direta) para 66,21% (assistida), uma diferença de +28,10 pontos percentuais. Sob um limite mais estrito (precisão direta > 30%), o ganho é de +14,11 pontos.

Resultados e Observações

• Ganhos de Desempenho: O caminho assistido supera significativamente a linha de base direta na partição de linha de base não nula. A melhoria é mais pronunciada quando a precisão da linha de base direta é baixa, mas não nula (por exemplo, MedQA, AIME, MMLU-Pro).
• Disparidade de Orçamento: O caminho de inferência assistido utiliza aproximadamente 7,36 vezes o orçamento de tokens do solucionador da linha de base direta (média de 7,23 chamadas vs. 1,01 chamada por item).
• Fragilidade de Extração: A extração de respostas é um ponto de falha significativo. O caminho assistido tem uma taxa de falha de extração de 15,67% (retornando 'X' para nenhuma letra válida) em comparação com 0,44% para a linha de base direta.
• Casos Negativos (Time-MQA): O conjunto de dados Time-MQA exibe regressões para solucionadores diretos mais fortes. Para modelos com alta precisão direta no Time-MQA, a abordagem estruturada às vezes reduz o desempenho, sugerindo que a decomposição de perguntas de séries temporais pode introduzir inconsistência ou distrair de sinais relevantes.
• Achados de Auditoria:
  • Alguns programas gerados violam a instrução "sem codificação rígida", contendo atribuições literais de respostas.
  • O limite de prompt de 10 chamadas ao solucionador não é aplicado em tempo de execução; algumas linhas excedem esse limite.
  • Respostas do lado do gerador frequentemente diferem das respostas do solucionador assistido, confirmando a necessidade de manter os canais separados.

Significado e Alegações

O artigo posiciona o CGR não como um método de melhoria universal ou uma nova arquitetura de modelo, mas como um protocolo de avaliação que torna a condição estruturada mensurável e auditável.

• Alegações Modestas: Os autores afirmam explicitamente que os resultados são descritivos, não causais. Os ganhos observados estão associados a um orçamento de inferência maior e comportamentos específicos de extração, não necessariamente à estrutura executável sozinha. O artigo não afirma que o CGR é de custo igual, universalmente benéfico ou seguro para implantação clínica/operacional sem validação de especialistas.
• Interpretabilidade: O valor primário do CGR é o "registro emparelhado" que ele fornece. Permite que os pesquisadores determinem por que uma pontuação mudou: foi devido a uma decomposição útil, reparo de formato de resposta, chamadas extras ou conhecimento do lado do gerador?
• Direções Futuras: Os autores identificam a necessidade de trabalhos futuros incluírem linhas de base com orçamento correspondido (por exemplo, consistência direta), validação de opções mais estrita, execução em ambiente isolado (sandbox) e amostragem repetida para isolar o efeito causal da estrutura do orçamento de inferência extra.

Em resumo, o CGR demonstra que mover um SLM para uma estrutura executável pode produzir ganhos substanciais de precisão em tarefas de MCQA, mas esses ganhos vêm com custos computacionais aumentados, fragilidade de extração e variabilidade específica de domínio que devem ser cuidadosamente auditados.