Verificadores passo a passo: o que demonstram os Process Reward Models e até onde generalizam

A pergunta: uma seleção melhor significa um raciocínio confiável?

Quando um modelo resolve um problema em várias etapas, há mais de uma maneira de avaliar sua resposta. É possível julgar apenas a conclusão ou inspecionar as etapas intermediárias e estimar se cada uma é válida. A segunda opção parece oferecer um diagnóstico mais detalhado: se for possível identificar onde um erro começa, em princípio seria possível descartar uma solução antes que esse erro comprometa o restante do raciocínio.

Um Process Reward Model (PRM) é um modelo treinado para atribuir pontuações às etapas de uma solução, geralmente com o objetivo de distinguir etapas corretas de incorretas, ou úteis de defeituosas. Já um Outcome Reward Model (ORM) avalia o resultado completo. Ambos são avaliadores: nenhum deles necessariamente gera a solução. Quando são usados para ordenar várias respostas candidatas, participam de uma busca; essa busca é uma operação adicional, não uma propriedade comprovada pela pontuação.

A tese que se pode sustentar com base nos trabalhos analisados é limitada: verificadores de processo podem ajudar a selecionar soluções em determinadas tarefas e condições experimentais. Isso não basta para concluir que cada etapa pontuada esteja correta, que uma explicação visível reproduza fielmente o processo interno do modelo ou que o verificador se comporte da mesma maneira em outro domínio. É importante separar o resultado de uma tarefa específica de afirmações mais amplas sobre confiabilidade.

Quatro elementos que não devem ser confundidos

A supervisão de processos fornece rótulos sobre etapas intermediárias. A supervisão de resultados fornece rótulos para soluções completas ou suas respostas finais. Um PRM aprende a utilizar sinais sobre o processo; um ORM aprende com sinais sobre o resultado. Um crítico generalista pode receber uma solução e emitir uma avaliação em linguagem natural, sem ser necessariamente um PRM treinado com rótulos de etapas.

Verificação e busca guiada tampouco são equivalentes. Verificar significa atribuir um julgamento ou uma pontuação a uma solução ou às suas etapas. Na busca, um gerador produz alternativas e uma regra de seleção decide quais manter ou explorar. Um PRM pode atuar como essa regra, mas o desempenho final também depende do gerador, do número de candidatos, do procedimento de busca e do orçamento computacional.

Essas distinções importam ao interpretar os resultados. Se uma configuração com PRM obtiver mais respostas corretas do que uma configuração com ORM, o achado pode sustentar que o PRM é útil naquela combinação de tarefa, modelo e busca. Isso não estabelece automaticamente que ele seja melhor na detecção de erros, nem que a melhora decorra exclusivamente da compreensão do raciocínio.

Let’s Verify Step by Step: evidências em problemas matemáticos

«Let’s Verify Step by Step» estuda a supervisão de processos em comparação com a supervisão de resultados no raciocínio matemático. O trabalho apresenta o PRM800K, um conjunto de dados com 800 mil rótulos de correção por etapa em soluções de modelos para problemas do MATH. A unidade de anotação é importante: os rótulos permitem treinar e avaliar julgamentos intermediários nesse tipo de material, mas não constituem uma coleção universal de regras de raciocínio.

O artigo relata que, em seus experimentos com problemas matemáticos, a supervisão de processos pode melhorar a seleção de soluções em comparação com a supervisão de resultados. Esse resultado deve ser interpretado dentro da configuração experimental do trabalho: problemas do MATH, soluções candidatas geradas por modelos e verificadores treinados com os dados e procedimentos descritos. Não equivale a demonstrar que qualquer PRM supera qualquer ORM, com qualquer gerador ou em qualquer tarefa.

Também há uma diferença entre acertar ao selecionar uma resposta e julgar corretamente cada etapa. Se um verificador ordena bem as soluções de um teste, isso mede sua utilidade como seletor naquele teste. Para afirmar que ele localiza erros de forma confiável, seria necessário avaliar diretamente a identificação de etapas corretas e incorretas, com referências adequadas. A pontuação agregada das respostas finais não substitui essa análise.

ProcessBench: avaliar onde aparece o primeiro erro

O ProcessBench aborda uma questão mais direta sobre a avaliação de etapas: diante de um raciocínio com erros, o avaliador consegue identificar a primeira etapa incorreta? O benchmark reúne 3.400 casos e utiliza anotações humanas de especialistas para indicar o primeiro erro. Seu desenho permite estudar algo diferente da simples seleção de uma resposta final: a localização do erro em uma sequência de raciocínio.

O artigo compara PRMs com modelos críticos e apresenta resultados em tarefas de raciocínio matemático. Essas comparações oferecem um teste comum para os sistemas incluídos no benchmark, mas seu alcance é delimitado pelas tarefas, soluções e critérios de anotação que ele contém. Uma boa pontuação no ProcessBench sustentaria o desempenho nessa avaliação; não demonstraria uma capacidade idêntica em programação, ciência ou outros tipos de raciocínio.

A anotação do primeiro erro também não esgota todas as perguntas possíveis sobre uma solução. Pode haver divergência razoável quanto ao nível de detalhe de uma etapa, erros de transcrição ou casos em que uma etapa parece incorreta, mas a conclusão posterior está correta por outro caminho. Por isso, além de citar a pontuação geral, convém verificar como as unidades avaliadas são definidas, quais instruções os anotadores recebem e como as divergências são resolvidas.

O repositório oficial do projeto documenta o acesso ao benchmark e aos seus recursos. Para reproduzir o experimento, não basta conhecer o nome do benchmark: é preciso registrar qual versão dos dados, formato de entrada, modelo, instruções e configuração foram usados.

Rewarding Progress e ThinkPRM: outras maneiras de construir e testar verificadores

«Rewarding Progress» apresenta os Process Advantage Verifiers e estuda seu uso em tarefas de raciocínio, incluindo busca guiada e aprendizado por reforço com verificadores. Sua relevância para esta discussão é deslocar a atenção da pergunta «qual solução tem a melhor pontuação?» para a maneira como um sinal de progresso pode ser usado em procedimentos que geram ou selecionam soluções. O artigo compara configurações com verificadores de processo e de resultado, mas essa comparação corresponde aos modelos, às tarefas e aos orçamentos definidos em seus experimentos.

Um resultado de busca guiada combina várias decisões: quais candidatos o modelo produz, qual sinal o verificador utiliza, quantas iterações são realizadas e quanto processamento é permitido. Se a taxa de soluções corretas aumentar, essa melhora pertence à configuração completa. Para atribuí-la especificamente ao verificador, o experimento deve controlar as demais variáveis e explicitar os custos, não apenas a qualidade final.

ThinkPRM estuda verificadores de processo que geram raciocínios sobre a avaliação das etapas. O artigo relata avaliações no ProcessBench, no MATH-500 e no AIME ’24, além de testes fora de domínio no GPQA e no LiveCodeBench. Isso amplia o tipo de evidência em relação a um único teste matemático, mas não transforma alguns resultados em uma garantia de generalização irrestrita. Cada conjunto representa uma cobertura específica, e o desempenho pode variar conforme a tarefa, a distribuição e a forma como as etapas são apresentadas.

O nome de um método não determina, por si só, o volume ou o tipo de supervisão necessário, nem qual baseline é apropriado. Para comparar esses trabalhos, é preciso extrair de cada artigo o conjunto de treinamento, os rótulos utilizados, os modelos geradores e avaliadores, as instruções, os orçamentos e as métricas. Quando esses dados não são idênticos, uma classificação simples de «vencedores» seria enganosa.

Limites: rótulos caros, erros de julgamento e sobreajuste ao proxy

A supervisão por etapa pode ser mais informativa do que um rótulo final, mas obtê-la exige decidir o que conta como etapa e se ela está correta. O PRM800K mostra a escala de um recurso dedicado a rótulos de etapas em problemas matemáticos; essa escala não elimina o custo de produzir, revisar e manter rótulos confiáveis. Além disso, uma convenção de anotação para soluções matemáticas não é automaticamente transferível para tarefas com critérios menos discretos.

Um verificador também pode errar. Um falso positivo aceita uma etapa defeituosa; um falso negativo rejeita uma etapa válida. Quando o sistema seleciona entre muitas respostas, os erros não necessariamente têm efeitos simétricos: uma pontuação alta, mas equivocada, pode promover uma solução incorreta. Por isso, convém medir as duas classes de erro e revisar exemplos, em vez de se limitar a uma métrica média.

O sobreajuste ao proxy é outro risco prático. Se o gerador for otimizado repetidamente para obter pontuações altas de um verificador, poderá aprender padrões que o avaliador recompensa sem melhorar a correção real. Isso não prova que o fenômeno ocorra sempre, mas é uma possibilidade que precisa ser investigada: compare a pontuação do PRM com verificações independentes, audite as soluções selecionadas e procure casos em que uma sequência convincente ou uma formulação superficial receba uma nota alta apesar de ser defeituosa.

Por fim, pontuar um raciocínio escrito não demonstra que esse texto seja uma transcrição fiel dos cálculos internos do modelo. Experimentos sobre seleção ou localização de erros avaliam comportamentos observáveis em tarefas definidas. Não bastam para estabelecer transparência interna, nem para afirmar que incorporar um PRM torna uma aplicação segura.

Protocolo prático para avaliar um PRM próprio

Uma equipe que considere incorporar um PRM pode começar com um teste pequeno e controlado, sem confundir a comparação entre avaliadores com uma avaliação completa do produto. O objetivo deve ser definido antes de executar o experimento: a equipe quer escolher respostas melhores, detectar o primeiro erro, reduzir chamadas a um modelo crítico ou melhorar uma busca? Cada objetivo exige dados e métricas diferentes.

Para comparar sistemas, é necessário ter um conjunto de tarefas congelado, com casos que não tenham sido usados para ajustar as instruções, e referências verificadas por pessoas ou métodos independentes. É preciso fixar os mesmos modelos geradores e candidatos quando o objetivo for comparar avaliadores, além de manter constante o orçamento de seleção. Se o PRM consumir mais chamadas ou permitir mais exploração do que o baseline, a comparação deve informar essa diferença.

O conjunto de sistemas deve incluir pelo menos um PRM, um juiz generalista e um verificador de resultado. O juiz generalista avalia a solução usando uma instrução em linguagem natural; o verificador final confere apenas a conclusão, quando a tarefa permitir uma verificação confiável. Nenhum deles é um controle universal: servem para entender se a informação sobre as etapas melhora o critério em relação a alternativas específicas.

Além da métrica principal, devem ser registrados acertos e erros separadamente, a qualidade da localização do primeiro erro quando aplicável, o custo por candidato, o número de candidatos e a taxa de soluções corretas à medida que o orçamento varia. Convém reservar parte das tarefas para mudanças de domínio ou dificuldade e auditar manualmente uma amostra dos casos em que o PRM e os baselines divergem.

Conclusões defensáveis

A pesquisa sobre PRMs oferece evidências de que avaliar etapas intermediárias pode ser útil para selecionar soluções e, em benchmarks concebidos para isso, estudar a detecção de erros. «Let’s Verify Step by Step» documenta a supervisão de processos em problemas matemáticos; o ProcessBench formaliza uma avaliação centrada na localização do primeiro erro; «Rewarding Progress» explora verificadores em procedimentos de busca e aprendizado; ThinkPRM amplia os testes para conjuntos matemáticos e avaliações específicas fora de domínio.

A conclusão não é que exista um vencedor universal. As tarefas, os dados, os rótulos, os modelos, os orçamentos e os critérios de sucesso variam. A afirmação mais rigorosa é condicional: um PRM pode agregar valor em uma configuração avaliada, e esse valor deve ser medido em comparação com baselines comparáveis e com uma análise explícita de custos e erros.

Para decidir se um PRM serve em um fluxo de trabalho próprio, não basta perguntar se o modelo atribui pontuações convincentes. É preciso medir se essas pontuações melhoram o objetivo operacional, verificar em quais casos falha, testar mudanças na distribuição e manter separadas a correção da resposta, a validade das etapas e a fidelidade do raciocínio visível. Essa separação torna a evidência mais modesta, mas também mais útil.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.