Treinamento GRPO & RLVR

Esta habilidade assume que finetuning-method-selection já foi roteado para cá porque o comportamento alvo tem um sinal verificável de sucesso/falha — não demonstrações (lora-qlora-recipes) ou pares de preferência (preference-optimization). O que se segue é quando RL é a ferramenta certa, a receita de referência, o portão obrigatório de inspeção de recompensa, e como escolher uma variante GRPO quando a receita base se comporta mal.

Entrada: uma decisão de roteamento (RLVR via GRPO) mais um verificador (executor de código, suíte de testes, verificador de esquema ou avaliador) para a tarefa alvo. Formato de saída: uma configuração GRPO validada — os valores de kwarg em references/grpo-memory.md e as funções de recompensa em references/reward-functions.md, não conselhos em formato livre — que llm-finetuning-training-engineer consome diretamente.

Quando RL se Aplica

GRPO+RLVR só compensa quando o sucesso da tarefa é verificável algoritmicamente — um teste unitário passa, um parser aceita a saída, uma chamada de ferramenta corresponde a um esquema esperado, uma resposta matemática corresponde a uma verdade fundamental. Se a avaliação da saída requer julgamento humano ou uma rubrica subjetiva, isso é um problema de "eval-harness" e calibração de juiz primeiro — veja eval-harness-first — não um motivo para pular direto para RL.

Antes de iniciar uma execução GRPO, confirme que o modelo pode às vezes ter sucesso na tarefa alvo já. RL aprimora uma capacidade existente, reponderando em direção às amostras que já funcionam; ele não instala uma capacidade do zero.

• O modelo nunca tem sucesso, mesmo em baixa temperatura em várias amostras: a lacuna é formato ou compreensão da tarefa, não refinamento de política. Roteie de volta para SFT primeiro (lora-qlora-recipes) e retorne a esta habilidade apenas quando a taxa de sucesso base for não zero.
• O modelo tem sucesso às vezes, inconsistentemente: este é o ponto ideal do GRPO — prossiga para A Receita abaixo.

A regra permanente para todo o plugin: DPO para gosto, GRPO para raciocínio. Se o sinal for uma preferência entre duas saídas aceitáveis, isso é preference-optimization, não esta habilidade.

A Receita

A receita de referência é GRPOTrainer da TRL com geração baseada em vLLM:

from trl import GRPOConfig, GRPOTrainer

grpo_args = GRPOConfig(
    output_dir="./outputs-grpo",
    use_vllm=True,
    vllm_mode="colocate",       # single GPU; "server" for multi-GPU
    num_generations=8,          # floor — fewer starves the group-relative baseline
    learning_rate=5e-7,         # settled range for GRPO
    beta=0.01,                  # KL coefficient vs the reference policy
    per_device_train_batch_size=8,
    gradient_accumulation_steps=4,
    bf16=True,
    logging_steps=10,
    seed=3407,
)

trainer = GRPOTrainer(
    model=SFT_CHECKPOINT,
    args=grpo_args,
    reward_funcs=[format_reward, correctness_reward],   # references/reward-functions.md
    train_dataset=prompts,       # prompt-only — GRPO generates its own completions
    processing_class=tokenizer,
)

trainer.train()

• vllm_mode="colocate" executa a geração e o treinamento na mesma GPU — o padrão para uma máquina de GPU única.
• vllm_mode="server" aponta para um processo servidor vLLM separado e é o caminho multi-GPU — geração e treinamento não competem pelo mesmo dispositivo.
• num_generations ≥ 8 é um piso, não uma sugestão: a estimativa de vantagem do GRPO é relativa à média do grupo, e menos de 8 amostras por prompt produz uma linha de base ruidosa.
• A recompensa é composta — uma recompensa de formato (a saída foi parseada / correspondeu à estrutura necessária) mais uma recompensa de correção (a resposta verificou). Uma resposta bem formada, mas errada, e uma malformada não devem pontuar identicamente; a correção sozinha perde esse sinal.
• learning_rate=5e-7 e beta=0.01 são o ponto de partida estabelecido; desvie apenas após a execução base estar estável e a recompensa ter sido inspecionada (abaixo).

Dimensionamento de memória para esta receita por classe de tamanho alvo: references/grpo-memory.md.

A Regra de Inspeção

Execute a função de recompensa contra 50–100 saídas amostradas e leia manualmente os resultados antes de iniciar a execução de treinamento real. Este é um portão, não uma verificação de sanidade única.

Se o julgamento da função de recompensa discordar de uma leitura humana dessa amostra, corrija a função de recompensa primeiro. Treinar contra uma recompensa não inspecionada, ou ajustar hiperparâmetros para compensar uma que silenciosamente pontua a coisa errada, é como uma execução "reward-hacks": o modelo otimiza limpamente em direção ao alvo errado, e isso não surge como um bug no loop de treinamento.

…