Resumo Técnico: STEP-KTODER

Declaração do Problema

Embora a supervisão de processo — fornecer feedback sobre etapas intermediárias de raciocínio — tenha melhorado significativamente o raciocínio matemático em Grandes Modelos de Linguagem (LLMs), sua aplicação à geração de código permanece subexplorada. Em domínios matemáticos, as etapas são naturalmente definidas como cadeias de pensamento. Na geração de código, entretanto, não existe uma noção padrão de uma "etapa". Os alvos de supervisão podem variar amplamente (linhas, traços de raciocínio ou estados de programa), criando ambiguidade sobre o que rotular e otimizar.

Os métodos atuais de otimização de preferência, como a Otimização de Preferência Direta (DPO) e a Otimização Kahneman–Tversky (KTO), operam tipicamente ao nível do resultado, tratando um programa inteiro como uma única unidade de feedback. Esse sinal grosseiro falha em distinguir entre componentes corretos e incorretos dentro de um programa parcialmente bem-sucedido. Por exemplo, um programa que é majoritariamente correto, mas falha em um caso de borda estreito, é rotulado inteiramente como "indesejável", obscurecendo quais funções específicas contribuíram para o sucesso ou fracasso. Essa falta de granularidade limita a capacidade de reforçar código localmente correto enquanto se penalizam componentes defeituosos específicos.

Metodologia: STEP-KTODER

Os autores propõem o STEP-KTODER, um framework para otimização de preferência de código que define "etapas" como funções de nível de módulo em programas decompostos de múltiplas funções. O método combina supervisão de processo ao nível da função com feedback ao nível do resultado usando um pipeline de rotulagem baseado em execução.

1. Pipeline de Construção de Dados

O framework baseia-se em um processo automático de construção de dados consistindo em quatro estágios:

• Decomposição de Referência: Um modelo de código forte, ajustado por instrução, reescreve soluções de referência em programas decompostos de múltiplas funções, preservando a interface e o comportamento originais. Apenas as reescritas que passam no conjunto de testes original são retidas.
• Geração de Testes Unitários de Nível de Função: Para cada função decomposta, o modelo gera testes unitários direcionados cobrindo a interface da função e casos de borda. Esses testes são validados pela execução contra a implementação de referência; apenas os testes que passam e contêm asserções não triviais são mantidos.
• Geração de Candidatos On-Policy: O modelo alvo gera conclusões candidatas preenchendo esqueletos de funções (onde os corpos das funções são substituídos por pass) derivados das referências decompostas.
• Rotulagem:
  • Rótulo de Resultado ($o$): Determinado se o programa candidato completo passa no conjunto de testes fornecido pelo dataset.
  • Rótulos de Etapa ($z$): Determinado pela execução de cada função candidata contra seus testes unitários gerados. Um rótulo de $1$ indica correção local, $0$ indica falha e $\emptyset$ indica que nenhum teste válido estava disponível.

2. Função Objetivo

O STEP-KTODER estende o KTO introduzindo um objetivo conjunto que combina supervisão ao nível do resultado e ao nível da etapa.

• KTO de Nível de Resultado: Utiliza a perda KTO padrão ($L_{out}$) baseada na desejabilidade binária do programa completo.
• KTO de Nível de Etapa: Define uma perda por etapa ($L_{step}$) sobre os tokens de funções individuais. Para cada função $s_i$, uma razão de log local é computada, e uma função de valor é aplicada com base no rótulo de etapa $z_i$.
• Objetivo Conjunto: A perda final é $L_{STEP-KTODER} = L_{out} + \lambda_{step} L_{step}$.

Crucialmente, o framework emprega rótulos de preservação de conflito. Ele retém exemplos de treinamento onde o rótulo de resultado ($o$) e os rótulos de etapa ($z$) discordam (por exemplo, um programa que passa no conjunto de testes global, mas contém uma função localmente falha). Esses conflitos fornecem sinais de treinamento únicos que métodos apenas de resultado não conseguem capturar, permitindo que o modelo aprenda que componentes específicos podem estar corretos mesmo que o todo falhe, ou vice-versa.

3. Confiabilidade dos Rótulos

O artigo enfatiza que rótulos baseados em execução são essenciais. Os autores testaram a substituição de rótulos de etapa baseados em execução por anotações "LLM-as-a-judge" (usando GPT-5.4 mini). Embora o LLM tenha mostrado concordância geral moderada (73,2%), ele exibiu um viés sistemático: ele superexcedeu a previsão de falhas, identificando corretamente 94,1% das funções falhas, mas apenas 52,2% das funções bem-sucedidas. Esse viés corrompeu os rótulos positivos de etapa necessários para o treinamento, levando a um desempenho degradado, particularmente em benchmarks mais difíceis.

Principais Contribuições

1. Framework STEP-KTODER: Uma instanciação específica de código para o KTO passo-a-passo que define etapas como funções independentemente testáveis, preenchendo a lacuna entre a supervisão de processo e a geração de código.
2. Pipeline de Dados Automático: Um pipeline que decompõe soluções, gera testes unitários de nível de função e deriva rótulos de etapa baseados em execução, permitindo supervisão de granularidade fina sem anotação manual.
3. Validação Empírica: Experimentos demonstrando que rótulos baseados em execução são superiores aos julgamentos baseados em LLM para supervisão de etapa e que a preservação de conflitos locais/globais é crítica para o desempenho.

Resultados Experimentais

O método foi avaliado em HumanEval(+), MBPP(+), BigCodeBench e LiveCodeBench usando modelos ajustados por instrução (Qwen2.5-Coder e DeepSeek-Coder).

• Ganhos de Desempenho: O STEP-KTODER superou consistentemente o KTO de apenas resultado e o DPO, com as melhorias mais significativas observadas em benchmarks mais difíceis.
  • No Qwen2.5-Coder-1.5B, ele melhorou em mais de +11,5% em relação ao KTO no BigCodeBench Hard e +7,7% no LiveCodeBench.
  • No Qwen2.5-Coder-3B, os ganhos foram de +11,3% no BigCodeBench Hard e +9,5% no LiveCodeBench.
  • No DeepSeek-Coder-6.7B, alcançou um ganho de +4,9% sobre o KTO no BigCodeBench Hard.
• Comparação com Target-DPO: Embora o Target-DPO também foque em falhas localizadas, o STEP-KTODER alcançou resultados superiores nos benchmarks mais difíceis (por exemplo, +18,5% de melhoria sobre o Target-DPO no BigCodeBench Hard para o modelo 3B) usando significativamente menos amostras de treinamento (aprox. 11.400 pares vs. 59.000 pares).
• Estudos de Ablação:
  • Preservação de Conflito: Mascarar conflitos (remover exemplos onde $o \neq z$) reduziu o desempenho aos níveis do KTO, confirmando que esses descompassos fornecem sinais de treinamento essenciais.
  • Fonte de Rótulo: Substituir rótulos baseados em execução por anotações de "LLM-as-a-judge" causou quedas substanciais de desempenho (por exemplo, -25,8% no BigCodeBench Hard), validando a necessidade de feedback baseado em execução.

Significância e Alegações

O artigo afirma que o STEP-KTODER oferece um caminho prático para a supervisão de processo na geração de código ao alavancar a modularidade natural dos programas. Ao definir etapas como funções e supervisioná-las via execução, o método fornece feedback localizado que reforça componentes corretos e penaliza falhas específicas, uma capacidade ausente na supervisão apenas de resultado.

Os autores destacam que a eficácia do método depende fortemente de dois fatores:

1. Confiabilidade baseada em execução: Testes unitários automatizados fornecem a verdade fundamental necessária para os rótulos de etapa, enquanto juízes LLM introduzem vieses sistemáticos que degradam o aprendizado.
2. Preservação de conflito: A capacidade de aprender com exemplos onde a correção local e o sucesso global divergem é um diferencial chave em relação à otimização de preferência padrão.

O trabalho sugere que o feedback de execução ao nível da função é um mecanismo viável e eficaz para alinhar modelos de código, particularmente para tarefas complexas onde o feedback de granularidade grossa é insuficiente. Os autores observam limitações em relação ao requisito de que as soluções sejam decomponíveis em funções testáveis e ao custo de engenharia para gerar candidatos on-policy para novos modelos.