Verificadores paso a paso: qué demuestran los Process Reward Models y hasta dónde generalizan

La pregunta: ¿mejor selección significa razonamiento fiable?

Cuando un modelo resuelve un problema en varios pasos, hay más de una manera de evaluar su respuesta. Se puede juzgar únicamente la conclusión, o inspeccionar los pasos intermedios y estimar si cada uno es válido. La segunda opción parece ofrecer un diagnóstico más detallado: si se identifica dónde empieza un error, en principio se podría descartar una solución antes de que ese error contamine el resto del razonamiento.

Un Process Reward Model (PRM) es un modelo entrenado para asignar puntuaciones a pasos de una solución, normalmente con el propósito de distinguir pasos correctos de incorrectos o útiles de defectuosos. Un Outcome Reward Model (ORM), en cambio, evalúa el resultado completo. Ambos son evaluadores: ninguno genera necesariamente la solución. Si se usan para ordenar varias respuestas candidatas, participan en una búsqueda; esa búsqueda es una operación adicional, no una propiedad que venga demostrada por la puntuación.

La tesis que se puede sostener a partir de los trabajos examinados es acotada: los verificadores de proceso pueden ayudar a seleccionar soluciones en determinadas tareas y condiciones experimentales. Eso no basta para concluir que cada paso puntuado sea correcto, que una explicación visible reproduzca fielmente el proceso interno del modelo o que el verificador se comporte igual en otro dominio. Es importante separar el resultado de una tarea concreta de afirmaciones más amplias sobre fiabilidad.

Cuatro piezas que conviene no confundir

La supervisión de procesos proporciona etiquetas sobre pasos intermedios. La supervisión de resultados proporciona etiquetas para soluciones completas o sus respuestas finales. Un PRM aprende a utilizar señales sobre el proceso; un ORM aprende de señales sobre el resultado. Un crítico generalista puede recibir una solución y emitir una evaluación en lenguaje natural, sin ser necesariamente un PRM entrenado con etiquetas de pasos.

Tampoco son equivalentes la verificación y la búsqueda guiada. Verificar significa asignar un juicio o una puntuación a una solución o a sus pasos. En búsqueda, un generador produce alternativas y una regla de selección decide cuáles conservar o explorar. Un PRM puede actuar como esa regla, pero el rendimiento final depende también del generador, del número de candidatos, del procedimiento de búsqueda y del presupuesto computacional.

Estas distinciones importan al leer resultados. Si una configuración con PRM obtiene más respuestas correctas que una configuración con ORM, el hallazgo puede apoyar que el PRM es útil para esa combinación de tarea, modelo y búsqueda. No establece automáticamente que sea mejor como detector de errores, ni que la mejora proceda exclusivamente de comprender el razonamiento.

Let’s Verify Step by Step: evidencia en problemas matemáticos

«Let’s Verify Step by Step» estudia la supervisión de procesos frente a la supervisión de resultados en razonamiento matemático. El trabajo presenta PRM800K, un conjunto de datos con 800.000 etiquetas de corrección a nivel de paso en soluciones de modelos a problemas de MATH. La unidad de anotación importa: las etiquetas permiten entrenar y evaluar juicios intermedios en ese tipo de material, pero no constituyen una colección universal de reglas de razonamiento.

El artículo informa que, en sus experimentos con problemas matemáticos, la supervisión de procesos puede mejorar la selección de soluciones frente a la supervisión del resultado. Ese resultado debe leerse dentro de la configuración experimental del trabajo: problemas de MATH, soluciones candidatas generadas por modelos y verificadores entrenados con los datos y procedimientos descritos. No equivale a mostrar que cualquier PRM supere a cualquier ORM, con cualquier generador o en cualquier tarea.

También hay una diferencia entre acertar al seleccionar una respuesta y juzgar correctamente cada paso. Si un verificador ordena bien las soluciones de una prueba, eso mide su utilidad como selector en esa prueba. Para afirmar que localiza errores con fiabilidad haría falta evaluar directamente la identificación de pasos correctos e incorrectos, con referencias adecuadas. La puntuación agregada de respuestas finales no sustituye ese análisis.

ProcessBench: evaluar dónde aparece el primer error

ProcessBench aborda una pregunta más directa sobre la evaluación de pasos: dado un razonamiento con errores, ¿puede el evaluador identificar el primer paso incorrecto? El benchmark reúne 3.400 casos y utiliza anotaciones humanas de especialistas para señalar el primer error. Su diseño permite estudiar algo distinto de la mera selección de una respuesta final: la localización del error en una secuencia de razonamiento.

El artículo compara PRM con modelos críticos y presenta resultados en tareas de razonamiento matemático. Esas comparaciones ofrecen una prueba común para los sistemas incluidos en el benchmark, pero su alcance está delimitado por las tareas, las soluciones y los criterios de anotación que contiene. Una buena puntuación en ProcessBench respaldaría el desempeño en esa evaluación; no demostraría una capacidad idéntica en código, ciencia u otros tipos de razonamiento.

La anotación del primer error tampoco agota todas las preguntas posibles sobre una solución. Puede haber desacuerdo razonable sobre el nivel de detalle de un paso, errores de transcripción o casos en los que un paso parece incorrecto pero la conclusión posterior es correcta por otra vía. Por ello, además de citar la puntuación general, conviene comprobar cómo se definen las unidades evaluadas, qué instrucciones reciben los anotadores y cómo se resuelven discrepancias.

El repositorio oficial del proyecto documenta el acceso al benchmark y sus recursos. Para una reproducción, no basta con disponer del nombre del benchmark: hay que registrar qué versión de los datos, formato de entrada, modelo, instrucciones y configuración se utilizaron.

Rewarding Progress y ThinkPRM: otras formas de construir y probar verificadores

«Rewarding Progress» presenta Process Advantage Verifiers y estudia su uso en tareas de razonamiento, incluida la búsqueda guiada y el aprendizaje por refuerzo con verificadores. Su interés para esta discusión es que desplaza la atención de la pregunta «¿qué solución tiene la mejor puntuación?» hacia cómo una señal de progreso puede utilizarse dentro de procedimientos que generan o seleccionan soluciones. El artículo compara configuraciones con verificadores de proceso y de resultado, pero la comparación corresponde a los modelos, tareas y presupuestos definidos por sus experimentos.

Un resultado de búsqueda guiada combina varias decisiones: qué candidatos produce el modelo, qué señal utiliza el verificador, cuántas iteraciones se realizan y cuánto cómputo se permite. Si aumenta la tasa de soluciones correctas, esa mejora pertenece a la configuración completa. Para atribuirla al verificador en particular, el experimento debe controlar las demás variables y exponer los costes, no solo la calidad final.

ThinkPRM estudia verificadores de proceso que generan razonamientos sobre la evaluación de los pasos. El artículo informa evaluaciones en ProcessBench, MATH-500 y AIME ’24, además de pruebas fuera de dominio en GPQA y LiveCodeBench. Esto amplía el tipo de evidencia respecto de una única prueba matemática, pero no convierte unos resultados en una garantía de generalización abierta. Cada conjunto representa una cobertura concreta y el desempeño puede variar según la tarea, la distribución y la forma de presentar los pasos.

El nombre de un método no determina por sí solo qué volumen o tipo de supervisión requiere ni qué baseline es adecuado. Para comparar estos trabajos se deben extraer de cada artículo el conjunto de entrenamiento, las etiquetas utilizadas, los modelos generadores y evaluadores, las instrucciones, los presupuestos y la métrica. Cuando esos datos no son idénticos, una clasificación simple de «ganadores» sería engañosa.

Límites: etiquetas costosas, errores de juicio y sobreajuste al proxy

La supervisión a nivel de paso puede ser más informativa que una etiqueta final, pero obtenerla requiere decidir qué cuenta como paso y si es correcto. PRM800K muestra la escala de un recurso dedicado a etiquetas de pasos en problemas matemáticos; esa escala no elimina el coste de producir, revisar y mantener etiquetas fiables. Además, una convención de anotación para soluciones matemáticas no se traslada automáticamente a tareas con criterios menos discretos.

Un verificador también puede equivocarse. Un falso positivo acepta un paso defectuoso; un falso negativo rechaza uno válido. Si el sistema selecciona entre muchas respuestas, los errores no tienen necesariamente un efecto simétrico: una puntuación alta y equivocada puede promover una solución incorrecta. Por ello conviene medir ambas clases de error y revisar ejemplos, no limitarse a una métrica media.

El sobreajuste al proxy es otro riesgo práctico. Si el generador se optimiza repetidamente para obtener puntuaciones altas de un verificador, puede aprender patrones que el evaluador recompensa sin mejorar la corrección real. Esto no prueba que ocurra siempre, pero es una posibilidad que debe investigarse: comparar la puntuación del PRM con verificaciones independientes, auditar soluciones seleccionadas y buscar casos en que una traza persuasiva o una formulación superficial obtenga una nota elevada pese a ser defectuosa.

Por último, puntuar un razonamiento escrito no demuestra que ese texto sea una transcripción fiel de los cálculos internos del modelo. Los experimentos sobre selección o localización de errores evalúan conductas observables bajo tareas definidas. No bastan para establecer transparencia interna, ni para afirmar que incorporar un PRM vuelva segura una aplicación.

Protocolo práctico para evaluar un PRM propio

Un equipo que considere incorporar un PRM puede empezar con una prueba pequeña y controlada, sin confundir la comparación de evaluadores con una evaluación completa del producto. El objetivo debería definirse antes de ejecutar el experimento: ¿se quiere elegir mejores respuestas, detectar el primer error, reducir llamadas a un modelo crítico o mejorar una búsqueda? Cada objetivo exige datos y métricas distintos.

Para comparar sistemas, se necesita un conjunto de tareas congelado, casos que no se hayan utilizado para ajustar las instrucciones y referencias verificadas por personas o métodos independientes. Hay que fijar los mismos modelos generadores y candidatos cuando el objetivo sea comparar evaluadores, y mantener constante el presupuesto de selección. Si el PRM consume más llamadas o permite más exploración que el baseline, la comparación debe informar esa diferencia.

El conjunto de sistemas debería incluir al menos un PRM, un juez generalista y un verificador de resultado. El juez generalista evalúa la solución mediante una instrucción en lenguaje natural; el verificador final comprueba únicamente la conclusión, cuando la tarea permita una comprobación fiable. Ninguno es un control universal: sirven para entender si la información de pasos mejora el criterio respecto de alternativas concretas.

Además de la métrica principal, se deben registrar aciertos y errores por separado, calidad de localización del primer error cuando proceda, coste por candidato, número de candidatos y tasa de soluciones correctas al variar el presupuesto. Conviene reservar una parte de las tareas para cambios de dominio o de dificultad y auditar manualmente una muestra de los casos en que PRM y baselines discrepan.

Conclusiones defendibles

La investigación sobre PRM aporta evidencia de que evaluar pasos intermedios puede ser útil para seleccionar soluciones y, en benchmarks diseñados para ello, para estudiar la detección de errores. «Let’s Verify Step by Step» documenta la supervisión de procesos en problemas matemáticos; ProcessBench formaliza una evaluación centrada en localizar el primer error; «Rewarding Progress» explora verificadores dentro de procedimientos de búsqueda y aprendizaje; ThinkPRM amplía las pruebas a conjuntos matemáticos y a evaluaciones fuera de dominio concretas.

La conclusión no es que exista un ganador universal. Cambian las tareas, los datos, las etiquetas, los modelos, los presupuestos y los criterios de éxito. La afirmación más rigurosa es condicional: un PRM puede aportar valor en una configuración evaluada, y su valor debe medirse frente a baselines comparables y con un análisis explícito de costes y errores.

Para decidir si sirve en un flujo propio, no basta con preguntar si el modelo asigna puntuaciones convincentes. Hay que medir si esas puntuaciones mejoran el objetivo operativo, comprobar qué casos falla, probar cambios de distribución y mantener separadas la corrección de la respuesta, la validez de los pasos y la fidelidad del razonamiento visible. Esa separación hace que la evidencia sea más modesta, pero también más útil.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.