Verificações retidas no ajuste fino por reforço

O que eles são

Em modelos abertos, a Scalata pode mostrar os grupos reais de respostas que o avaliador pontuou. Em modelos de raciocínio hospedados, o próprio provedor executa o avaliador e não compartilha as respostas pontuadas durante o treinamento. O que ele compartilha é um conjunto de verificações retidas: a cada poucas etapas, ele faz um punhado de perguntas de validação nas quais o modelo nunca é treinado, e avalia essas respostas com o mesmo avaliador.

Como a primeira verificação ocorre na etapa 0, antes de qualquer treinamento, cada pergunta de validação se torna uma pequena linha do tempo: como a resposta à mesma pergunta mudou à medida que o treinamento avançou. Isso faz das verificações a melhor evidência disponível de que os ganhos se transferem para perguntas que o modelo não viu, e não apenas para aquelas em que praticou.

Lendo a linha do tempo

• Baixa na etapa 0, depois aumentando: o sinal mais claro de um aprendizado que se transfere para novas perguntas.
• 1,00 da etapa 0 em diante: um teto. O modelo já respondeu bem o suficiente, então esta pergunta não pode mostrar melhoria. Muitas destas significam que o avaliador é muito fácil, ou as perguntas são.
• Uma queda no meio: ruído normal. Cada verificação é uma resposta amostrada, e uma amostra infeliz pode ter uma pontuação baixa. Observe a tendência ao longo das verificações e das perguntas, não em apenas um cartão.
• Estagnada em todos os pontos abaixo do teto: o modelo não está encontrando respostas melhores. A causa comum é um modelo inicial que raramente acerta essas perguntas; uma execução supervisionada prévia ajuda.

Recompensa de validação vs recompensa de treinamento

O provedor relata duas recompensas. A recompensa de treinamento é a pontuação média do avaliador nas perguntas em que o modelo está sendo treinado naquela etapa; essas perguntas mudam de etapa para etapa, então o número oscila, e um modelo pode aumentá-lo melhorando exatamente naqueles prompts. A recompensa de validação é a média das verificações retidas: as mesmas perguntas todas as vezes, nunca usadas no treinamento. Confie mais nela, pelo mesmo motivo que a perda de validação supera a perda de treinamento. A documentação da OpenAI a descreve da mesma forma: os valores da recompensa de treinamento “podem flutuar drasticamente de etapa para etapa”, enquanto a recompensa de validação é “uma métrica mais estável”.

Verificações e checkpoints

Os provedores geralmente salvam um checkpoint nas mesmas etapas das verificações. Portanto, se as verificações pararem de melhorar na metade do caminho, o checkpoint correspondente pode ser tão bom quanto o modelo final, e uma execução mais curta teria custado menos. O ajuste fino por reforço hospedado é cobrado por hora de treinamento e os modelos de raciocínio escrevem respostas longas, de modo que cada etapa é lenta: observar onde as verificações estagnam é uma economia direta na próxima execução.

No que o modelo é treinado

O ajuste fino por reforço usa os mesmos chats do treinamento supervisionado, transformados em uma linha por resposta, terminando nessa resposta. A conversa até a resposta é o prompt; a própria resposta se torna uma referência que apenas o avaliador vê. Um chat com três respostas gera três linhas, e a referência de cada linha é apenas a sua última resposta, com as respostas anteriores mantidas no prompt como contexto.

chat:  system · user 1 · reply 1 · user 2 · reply 2 · user 3 · reply 3

row 1  prompt: developer · user 1                                   reference: reply 1
row 2  prompt: developer · user 1 · reply 1 · user 2                reference: reply 2
row 3  prompt: developer · user 1 · reply 1 · user 2 · reply 2 · user 3   reference: reply 3

Modelos de raciocínio hospedados (a série o) não aceitam uma mensagem system em exemplos de reforço. As mesmas instruções vão em uma mensagem developer, que esses modelos tratam da mesma forma que outros modelos tratam system; um arquivo de treinamento com uma mensagem de sistema nesse local falha na validação.

{"messages": [
   {"role": "developer", "content": "You are Scalata's support assistant. Be brief."},
   {"role": "user",      "content": "How do I share a report with a client?"}],
 "reference": "Open the report → Share → pick the client. They get an email link."}

Métricas

Erros comuns

• Ler apenas um cartão. Uma única verificação é uma resposta amostrada; avalie a tendência ao longo das verificações e perguntas.
• Confiar em uma recompensa de treinamento crescente quando a recompensa de validação está estagnada. O modelo pode estar se ajustando aos prompts de treinamento ou burlando o avaliador.
• Ignorar os tetos. Perguntas com 1,00 do início ao fim inflam a média e ocultam se houve alguma mudança.
• Sempre usar o modelo final. Se as verificações estagnaram na metade do caminho, o checkpoint correspondente é igualmente bom e a próxima execução pode ser mais curta.
• Escrever uma mensagem de sistema em arquivos de reforço criados manualmente para modelos da série o. Em vez disso, use uma mensagem de desenvolvedor.

Referências e leitura complementar

Fontes externas abrem em uma nova aba.

1. 01Reinforcement fine-tuning↗OpenAI API docs · developers.openai.comO serviço RFT hospedado: arquivos de validação, recompensa de treinamento e validação, e checkpoints.
2. 02Graders↗OpenAI API docs · developers.openai.comComo os avaliadores do provedor são definidos e o que eles leem de cada linha.
3. 03Fine-tune a model with reinforcement fine-tuning in Microsoft Foundry↗Microsoft Learn · learn.microsoft.comAjuste fino por reforço de modelos de raciocínio no Azure, incluindo dados de validação.
4. 04Scaling Laws for Reward Model Overoptimization↗Gao, Schulman & Hilton, 2022 · arXiv · arxiv.orgPor que uma pontuação contra a qual o modelo é otimizado pode aumentar enquanto a verdadeira qualidade cai.

Conceitos relacionados