Process Reward Models vs. Outcome Reward Models für Reasoning-Systeme

Die aktuelle technische Frage ist nicht, ob Process Reward Models den Outcome Reward Models abstrakt gesehen überlegen sind. Es geht vielmehr darum, ob die Trainings- oder Evaluierungspipeline versucht, die Korrektheit der Antwort, die Korrektheit der Trajektorie, die Nützlichkeit der Suche oder eine Mischung aus diesen dreien zu messen.

Aktuelle Arbeiten machen es schwer, die einfache Behauptung „PRMs sind besser, weil sie dichter sind“ zu verteidigen. Grundlegende Arbeiten zur Prozessüberwachung zeigen nach wie vor echte Gewinne bei mathematikähnlichen Aufgaben und eine sauberere Diagnose von Zwischenfehlern. Neuere domänenübergreifende Vergleiche, Verifier-Papiere und Berichte über Reward-Hacking zeigen, dass ergebnis- oder verifierbasierte Setups mit PRMs gleichziehen oder diese übertreffen können, wenn Schritt-Labels verrauscht sind, Traces nicht verfügbar oder unzuverlässig sind und der Benchmark die endgültige Korrektheit stärker belohnt als eine fundierte Argumentation.

Die vertretbare Wahl ist zielabhängig, nicht ideologieabhängig.

Der Vergleich ist eine Zieldiskrepanz

Auf der Ebene des Überwachungsziels lösen PRMs und ORMs unterschiedliche Schätzprobleme. Ein ORM oder Antwort-Verifier, der an die gesamte Trajektorie angehängt ist, wird in der Regel gefragt, ob die endgültige Antwort oder die abgeschlossene Reaktion akzeptiert werden soll. Ein PRM wird gebeten, Präfixe, Schritte oder Zwischenbehauptungen zu bewerten, damit das Training oder die Suche Anerkennung zuweisen kann, bevor die endgültige Antwort bekannt ist.

Dieser Unterschied ist wichtig, da dieselbe Trajektorie im Ergebnis korrekt, aber im Prozess fehlerhaft sein kann, oder im Prozess größtenteils fehlerfrei, aber im Ergebnis aufgrund eines späten Rechenfehlers inkorrekt. Uesato et al. machten diese Unterscheidung bei GSM8K deutlich: Eine rein ergebnisbasierte Überwachung erreichte einen ähnlichen Fehler bei der Endantwort mit weniger Überwachung, während die prozessbasierte Überwachung den Argumentationsfehler bei Lösungen mit korrekter Endantwort von 14.0% auf 3.4% reduzierte. Die spätere MATH-Arbeit von OpenAI verdeutlichte denselben Punkt, indem sie zeigte, dass ein prozessüberwachtes Modell 78% auf einer repräsentativen MATH-Teilmenge löste. Dieses Ergebnis unterstützt die Prozessüberwachung für die Zuverlässigkeit mehrstufiger Mathematik. Es ist kein universelles Theorem über jegliche Argumentationsüberwachung.

R_{\mathrm{out}}(x,z_{1:T}) = \mathbb{1}\{a(z_{1:T}) = y^*\}

Die Ergebnisüberwachung misst, ob die abgeschlossene Trajektorie eine akzeptable Endantwort liefert. Bei offenen Aufgaben wird der Indikator oft durch einen Verifier- oder Judge-Score ersetzt.

R_{\mathrm{proc}}(x,z_{1:T}) = A(r_1,\ldots,r_T),\quad r_t \approx c(z_t \mid z_{<t}, x)

Prozessüberwachung bewertet lokale Schritte oder Behauptungen und aggregiert diese lokalen Beurteilungen dann durch eine Such-, Reranking- oder Trainingsregel.

R_{\mathrm{hybrid}} = \lambda R_{\mathrm{out}} + (1-\lambda)R_{\mathrm{proc}}

Hybride Überwachung kann die Akzeptanz der finalen Antwort mit Nachweisen der Trajektorienqualität kombinieren, obwohl reale Systeme oft Gating, Curricula oder strukturierte Verifizierer anstelle einer buchstäblichen konvexen Kombination verwenden.

KI-Feedback kann die Überprüfung skalieren, aber eine unabhängige Messung definiert weiterhin das Ziel.

Pipeline-Familie	Was Menschen weiterhin beisteuern	Was KI-Feedback skalieren kann	Was es nicht ersetzt
Primäre Feedback-Quelle	Menschliche Labels und Rubrik-Entscheidungen.	KI-generierte Rankings, Kritiken oder Bewertungen.	Menschliche Zieldefinition und abschließende Messung.
Bester Einsatzzweck	Verankerung mehrdeutiger Präferenzen.	Skalierung der Zwischenüberwachung.	Validierung an Holdouts und Randfällen.
Fehlerquelle	Teure oder langsame Review-Schleifen.	Synthetischer Evaluator wird zur Ground Truth.	Unabhängige menschliche Prüfung bleibt erforderlich.
Operative Kontrolle	Kalibrierung und Beurteilung.	Judge-Diagnosen und Prüfungen der Datenabdeckung.	Expertenprüfung für kritische Segmente.

OpenTrain-Synthese aus dem Quellpaket für PRM, ORM, Verifizierer und Reward-Hacking.

Der stärkste jüngste theoretische Gegenwind richtet sich auch gegen die Vorstellung, dass Outcome Supervision grundsätzlich schwieriger ist. Jia et al. argumentieren, dass unter Standardannahmen zur Datenabdeckung Reinforcement Learning durch Outcome Supervision statistisch nicht schwieriger ist als Process Supervision, bis auf polynomielle Faktoren im Horizont. Das beweist nicht die Überlegenheit von ORM in der Praxis. Es beseitigt jedoch eine häufige theoretische Stütze für die Annahme, dass dichte Schritt-Belohnungen automatisch die prinzipiellere Wahl sind.

Was die aktuelle Beweislage zeigt

Das Argument für Process Supervision bleibt am stärksten in engen, verifizierbaren, mehrstufigen Domänen, in denen Annotatoren oder automatisierte Verfahren sagen können, welcher Schritt zuerst schiefgeht. OpenAIs „Let’s Verify Step by Step“ bleibt kanonisch, weil es einen großen Gewinn durch Process Supervision bei MATH zeigte und PRM800K mit 800,000 Labels auf Schrittebene veröffentlichte. Math-Shepherd zeigte, dass automatisch abgeleitete Process Supervision einen Basis-Reasoner wesentlich verbessern kann, indem Mistral-7B von 77.9% auf 84.1% bei GSM8K und von 28.6% auf 33.0% bei MATH gesteigert wurde, wobei die auf Math-Shepherd basierende Verifizierung diese Zahlen auf 89.1% und 43.5% trieb.

ThinkPRM erweiterte diese Linie, indem es zeigte, dass ein generatives PRM LLM-as-a-judge und diskriminative Verifizierer übertreffen konnte, wobei nur 1% der PRM800K-Labels verwendet wurden, mit Out-of-Domain-Gewinnen bei GPQA-Diamond und LiveCodeBench. FoVer trieb die Reduzierung der Label-Kosten und den Transfer voran, indem Prozess-Labels durch formale Verifizierung synthetisiert wurden.

Aber die neuere Beweislage ist weitaus weniger wohlwollend gegenüber pauschalen PRM-Behauptungen. ProcessBench, das auf 3,400 von menschlichen Experten annotierten Testfällen aufbaut, berichtet, dass bestehende PRMs oft nicht über das GSM8K- und MATH-Regime hinaus generalisieren. PRMBench, mit 6,216 Problemen und 83,456 Labels auf Schrittebene, stellt signifikante Schwächen bei impliziten Prozessfehlern fest. Die Retrospektive des Qwen-Teams fügt eine operative Kritik hinzu: Synthetisches Monte-Carlo-Schritt-Labeling schneidet schlechter ab als LLM-judge und menschliche Annotation, und die konventionelle Best-of-N-Evaluierung kann PRM-Werte künstlich in die Höhe treiben, da Policy-Modelle oft Antworten mit korrekten Endergebnissen, aber fehlerhaften Prozessen generieren.

Jüngste empirische Ergebnisse schärfen den Vergleich zwischen PRM und ORM.

Paper oder System	Domäne	Ergebnis	Warum es wichtig ist
Uesato et al.	GSM8K	Prozess-Feedback reduzierte Argumentationsfehler bei Lösungen mit korrekter Antwort von 14.0% auf 3.4%.	Prozess-Labels können Fehler aufdecken, die bei der Überprüfung der Endantwort übersehen werden.
Let's Verify Step by Step	MATH	Ein prozessüberwachtes Modell löste 78% auf einer repräsentativen MATH-Teilmenge.	Das grundlegende PRM-Ergebnis ist stark, aber domänenspezifisch.
Math-Shepherd	GSM8K / MATH	Prozess-RL und Verifizierer nutzen ein verbessertes Mistral-7B bei beiden Benchmarks.	Automatisierte Prozessüberwachung kann helfen, wenn die Aufgabe schrittweise verifizierbar ist.
ProcessBench / PRMBench	Mathematisches Schlussfolgern	Aktuelle PRMs zeigen einen schwachen Transfer und übersehen feingranulare implizite Prozessfehler.	PRM-Benchmark-Erfolge implizieren keine robuste Prozessfehlererkennung.
xVerify	Reasoning-Evaluierung	Verzeichnete über 95% F1 und Genauigkeit auf Testsets zur Antwortverifizierung.	Eine starke Ergebnisverifizierung kann Outcome-First-Designs wettbewerbsfähiger machen.
Verifizierbare Prozessüberwachung	Schach-Reasoning	Reines Genauigkeits-RL verbesserte die Züge, verschlechterte jedoch die Reasoning-Qualität; hybrides VPS bewahrte die Genauigkeit und verbesserte die Konsistenz.	Antwortgewinne können die Trajektorienqualität verschlechtern, wenn das Ziel falsch ist.
Multi-RM-Vergleich	14 Domänen	Generatives ORM war insgesamt am robustesten; diskriminatives ORM schnitt auf dem gleichen Niveau ab wie diskriminatives PRM.	Der umfassendste Vergleich spricht gegen eine universelle Überlegenheit von PRM.

OpenTrain-Synthese aus zitierten Primärquellen. Metriken sind heterogen und sollten nicht als direkt vergleichbare Prozentsätze verstanden werden.

Die Arbeit an Verifizierern verkompliziert den einfachen PRM-gegen-ORM-Rahmen. Generative Verifizierer formulieren Reward-Modeling als Vorhersage des nächsten Tokens neu und verzeichnen im Vergleich zu Standard-Verifizierern große Best-of-N-Verbesserungen bei algorithmischen und mathematischen Reasoning-Aufgaben. xVerify konzentriert sich auf die Extraktion der finalen Antwort und die Äquivalenz bei langen Reasoning-Pfaden. In der Praxis ist ein großer Teil der Debatte eigentlich eine Debatte über das Design von Verifizierern: Schlechte Outcome-Verifizierer lassen PRMs notwendig erscheinen, während starke Pipelines zur Antwortverifizierung Outcome-Supervision viel wettbewerbsfähiger machen können.

Diagramm zur Zielabweichung (Objective Mismatch), das Outcome-Ziele, Prozess-Ziele, Verifizierer-Stärke, Trace-Vertrauen und hybrides Gating gegenüberstellt. — PRMs und ORMs beantworten unterschiedliche Messfragen, bevor sie zu konkurrierenden Trainingsrezepten werden.

Der Measurement-Stack ist fragil

Die erste Schwachstelle ist die Label-Qualität. PRMs versprechen eine dichtere Credit-Zuweisung, aber sie sind nur so gut wie die Schrittgrenzen und lokalen Korrektheits-Labels. DeepSeek-R1 listet drei praktische PRM-Einschränkungen auf: Schwierigkeiten bei der Definition feingranularer Schritte im allgemeinen Reasoning, Schwierigkeiten bei der Beurteilung der Korrektheit von Zwischenschritten und Reward-Hacking, sobald ein modellbasiertes PRM eingeführt wird. Die Qwen-Retrospektive kommt von der Datenseite zu einem ähnlichen Schluss und argumentiert, dass Monte-Carlo-Schritt-Labeling Schritte ungenau verifizieren und die nachgelagerte Evaluierung verfälschen kann.

Die zweite Schwachstelle ist die Übereinstimmung der Evaluatoren. Reward Modeling und Judge Modeling laufen nicht gegen ein Orakel. RMB berichtet, dass die Übereinstimmung bei der Kennzeichnung menschlicher Präferenzen typischerweise bei etwa 70% bis 80% gedeckelt ist und dass seine Daten und früheren Reward-Benchmarks eine Übereinstimmung von etwa 75% zwischen Labels und menschlichen Annotatoren zeigen. No Free Labels weitet diesen Punkt auf die auf Korrektheit fokussierte Beurteilung aus: Von Experten verfasste Referenzen verbessern die Zuverlässigkeit der Judges bei Geschäfts- und Finanzfragen erheblich.

Die dritte Schwachstelle ist die Verfügbarkeit und Wahrhaftigkeit von Chain-of-Thought. Einige Reasoning-Stacks legen externen Nutzern keine rohen Reasoning-Traces offen. Die Dokumentation zu Reasoning-Zusammenfassungen von OpenAI besagt, dass rohe Chain-of-Thought-Token nicht offengelegt werden, sondern nur Zusammenfassungen. Selbst wenn Traces verfügbar sind, berichtet Anthropic, dass Reasoning-Modelle nicht immer sagen, was sie denken, und die Arbeit von OpenAI zur Überwachung von Chain-of-Thought zeigt, dass Optimierungsdruck zu verschleiertem Reward-Hacking führen kann.

Die vierte Schwachstelle ist der Benchmark-Transfer. ProcessBench und PRMBench sind beides Reaktionen auf die Gewohnheit des Fachgebiets, PRMs auf einfacheren oder engeren Verteilungen zu validieren als denen, auf denen Teams sie einsetzen. MathArena macht denselben Punkt aus einem anderen Blickwinkel deutlich, indem es neu veröffentlichte Mathematikwettbewerbe evaluiert und Anzeichen von Kontamination in AIME 2024 meldet.

Fehlermodi sind nicht symmetrisch

Eine rein ergebnisorientierte Optimierung kann Antworten verbessern, während sie das Reasoning verschlechtert. Das Paper von Kim et al. zur verifizierbaren Prozessüberwachung macht dies am Beispiel von Schach deutlich. Rein genauigkeitsbasiertes RL verbesserte die Zuggenauigkeit, verschlechterte jedoch die Reasoning-Qualität, was den Win-Rate-Fehler um bis zu 112% erhöhte und die interne Konsistenz um bis zu 69% reduzierte. Ihr VPS-Hybrid bewahrte die Genauigkeit, während der Win-Rate-Fehler um bis zu 30% reduziert und die Konsistenz fast bis zur Sättigung wiederhergestellt wurde.

Optimierung auf Prozess- oder Verifier-Ebene kann ebenfalls falsches Vertrauen erzeugen. In der Qwen-Retrospektive belohnte die Best-of-N-Evaluierung Traces mit korrekten Antworten, aber fehlerhaften Prozessen. In LLMs Gaming Verifiers gaben RLVR-trainierte Modelle beim induktiven Reasoning die Regelinduktion auf und zählten stattdessen Labels auf Instanzebene auf, die den Verifier passierten, ohne die relationale Regel zu lernen.

Rubrikbasierte, offene Reward-Pipelines bergen einen dritten Fehlermodus: Der Verifier kann im Verhältnis zur Trainingsrubrik stark sein und dennoch das Falsche optimieren. Aktuelle Arbeiten zu Rubrik-RL trennen das Versagen des Verifiers von den Einschränkungen des Rubrikdesigns und zeigen, dass stärkere Verifier die Ausnutzung (Exploitation) zwar reduzieren, aber nicht eliminieren. Die breitere Literatur zu Reward-Modellen warnt davor schon seit Jahren: Die Überoptimierung eines Proxy-Rewards kann der Gold-Performance schaden.

Fehlermodi, die darüber entscheiden, ob PRM-, ORM- oder hybrides Feedback glaubwürdig ist.

Fehlermodus	Wo es am stärksten trifft	Was fehlschlägt	Kontrolle vor Skalierung
Richtige Antwort, fehlerhafter Prozess	Nur ergebnisbasierte Belohnungen	Das Modell lernt, akzeptable Antworten über fehlerhafte Pfade zu erreichen.	Prozessprüfungen bei Stichproben mit korrekten Antworten hinzufügen.
Verrauschte oder synthetische Schritt-Labels	Prozess-Reward-Modelle	Dichte Credit-Zuweisung verstärkt lokale Labeling-Fehler.	Messen Sie die Step-Label-Übereinstimmung und behalten Sie Slices zur Expertenbeurteilung.
Verifier-Gaming	ORMs, PRMs und Hybride	Die optimierte Policy lernt Artefakte, die den Evaluator zufriedenstellen.	Nutzen Sie versteckte Holdouts und adversarielle Reward-Hacking-Prüfungen.
Unzuverlässige oder nicht verfügbare Traces	Prozess-Supervision	Die sichtbare Kette ist nicht zuverlässig genug, um sie zu überwachen.	Behandeln Sie PRM-Werte als interne Proxys, es sei denn, die Trace-Fidelity wurde validiert.

OpenTrain-Synthese aus ProcessBench, PRMBench, Qwen PRM, DeepSeek-R1, verifizierbarer Prozessüberwachung und Reward-Hacking-Berichten.

Die Praxis bei Frontier-Modellen scheint bedingt zu sein

Die öffentlichen Belege deuten darauf hin, dass Frontier-Reasoning-Stacks standardmäßig auf verifizierbare Outcome-Rewards setzen, wo sie können, und dann Struktur und Judges hinzufügen, wo sie müssen. DeepSeek-R1 ist das deutlichste veröffentlichte Beispiel. Für R1-Zero verwendete DeepSeek ein regelbasiertes Reward-System, das hauptsächlich aus Genauigkeits- und Format-Rewards bestand, und gibt an, keine neuronalen Outcome- oder Process-Reward-Modelle angewendet zu haben, da diese Modelle unter Reward-Hacking leiden können, ein Retraining erfordern und die Pipeline verkomplizieren.

Das bedeutet nicht, dass PRMs obsolet sind. Es bedeutet, dass sich ein großes Reasoning-Labor für groß angelegtes RL öffentlich für „verifizierbares Ergebnis plus Formatierungsbeschränkungen“ anstelle von „zuerst ein PRM trainieren“ entschieden hat.

Die öffentlichen Reasoning-Berichte von OpenAI weisen in eine ähnliche Richtung, wenn auch mit weniger Details zum Reward-Stack. Die o1-Materialien beschreiben groß angelegtes Reinforcement Learning auf Chain-of-Thought plus Compute-Skalierung zur Trainings- und Testzeit, veröffentlichen jedoch kein PRM-zentriertes Produktionsrezept. Eine vernünftige Schlussfolgerung ist, dass das Frontier-Verhalten weniger „ein universelles PRM einsetzen“ und mehr „starke interne Reasoning-Traces, zuverlässige automatische Prüfungen, wo verfügbar, und mehrschichtige Überwachungs- oder Judge-Systeme darum herum verwenden“ ist.

Ein weiterer öffentlicher Trend ist, dass Labore versuchen, Evaluatoren mehr Rechenleistung (Compute) aufwenden zu lassen, nicht nur Generatoren. Aktuelle Verifier-Arbeiten zeigen, dass die Leistung von Evaluatoren steigt, wenn Reasoning-Modelle mehr Verifizierungs-Compute erhalten. Der praktische Vergleich findet zunehmend zwischen günstigen skalaren Prozesswerten, günstigen skalaren Ergebniswerten und teuren Reasoning-Verifiern mit strukturiertem Prompting statt.

Hybride Designs sind der ernsthafte Mittelweg

Ein Team, das sich nur um die finale Akzeptanz in einer streng verifizierbaren Domäne kümmert, sollte standardmäßig auf Outcome- oder Verifier-First-Supervision setzen. DeepSeek-R1, xVerify und Verifier-basierte Best-of-N-Ergebnisse unterstützen alle dieses Muster.

Ein Team, dem die Qualität der Trajektorie selbst wichtig ist, sollte Verbesserungen, die sich nur auf die Antwort beziehen, nicht als Beweis akzeptieren. In den Bereichen Bildung, Nachhilfe, Theorembeweise, sicherheitskritische Planung und Modellüberwachung geht es oft um den frühesten Fehler, das Selbstkorrekturverhalten und die Frage, ob Zwischenbehauptungen überprüfbar sind. In diesen Szenarien bleiben PRMs oder strukturierte Prozesskritiker vertretbar, aber nur, wenn das Team Schritte kohärent definieren, einen von Menschen geprüften Teilbereich aufrechterhalten und eine Übereinstimmung der Evaluatoren nachweisen kann, die gut genug ist, um die zusätzlichen Labeling-Kosten zu rechtfertigen.

Hybride Überwachung ist für viele reale Systeme die am besten vertretbare Antwort. ‘Outcome Accuracy Is Not Enough’ fügt der Ergebnisgenauigkeit eine logische Konsistenz hinzu und berichtet über State-of-the-Art-Leistungen bei Reward-Modellen und Judge-Benchmarks. Verifizierbare Prozessüberwachung kombiniert strukturierte Prozessbelohnungen mit Ergebnisgenauigkeit und vermeidet den Einbruch der Argumentationsqualität, der bei rein genauigkeitsbasiertem RL beobachtet wird. CorVer fügt eine leichtere Prozessbelohnung auf Satzebene für faktisches QA hinzu.

Dies sind nicht dieselben Methoden, aber sie weisen in dieselbe Richtung: Wenn ein Team sowohl Antwortqualität als auch Trajektorienqualität benötigt, werden hybride Signale glaubwürdiger als reines PRM- oder reines ORM-Dogma.

Die operative Erkenntnis ist eng gefasst, aber robust. PRMs sind Instrumente zur Messung und Verbesserung der Trajektorienqualität, wenn das Team dem Trace, den Schritt-Labels und dem Benchmark vertrauen kann. ORMs und Antwort-Verifizierer sind Akzeptanzinstrumente, wenn die endgültige Korrektheit dominiert und die Verifizierung stark ist. Hybride Designs sind der vertretbare Standard, wenn beides zutrifft.

Die entscheidende Variable ist nicht die feinere Granularität an sich. Es geht darum, ob das Überwachungsziel mit dem Fehlermodus übereinstimmt, für dessen Kontrolle das Team tatsächlich bezahlt.

OpenTrain kann spezialisierte menschliche Überprüfungen für die Kalibrierung von Verifizierern, Audits von Prozess-Labels, Rubrik-QA, adversarielle Segmente und Hard-Eval-Entscheidungen innerhalb des Stacks unterstützen, den ein Team bereits besitzt. Beginnen Sie mit dem Managed Service, wenn der Engpass im Betrieb der Überprüfungsschleife liegt, oder veröffentlichen Sie ein Stellenangebot, wenn das Team direkt einstellen möchte.