HelpSteer3: Human-Annotated Feedback and Edit Data to Empower Inference-Time Scaling in Open-Ended General-Domain Tasks

生成日: 2026-05-24 02:20

# HelpSteer3: Human-Annotated Feedback and Edit Data to Empower Inference-Time Scaling in Open-Ended General-Domain Tasks

- HelpSteer3 は、自由記述のフィードバックと、それに基づく応答編集を人手で集めたデータセットである。
- 論文は、回答を一度出してから批評し、編集するという手順を、open-ended な一般領域タスクの inference-time scaling として扱う。
- Llama 3 系 70B モデルを用いた構成は Arena Hard で 92.7 を示し、単純な Best-of-N よりも、批評と編集を挟む方が難しいプロンプトで効きやすいことを示した。

## Abstract（日本語訳）

Inference-Time Scaling は、OpenAI o1 や DeepSeek R1 のような近年のモデルの成功において重要であった。しかし、inference-time scaling のためにモデルを訓練する多くの手法は、タスクに検証可能な答えがあることを必要とするため、数学、コーディング、論理推論のような領域への適用に限られる。著者らは、人間が広範な open-ended な営みにおいて、まず初稿を作り、他者から詳しいフィードバックを求め、そのフィードバックに基づいて改善する過程から着想を得た。このために、open-ended な一般領域タスクで inference-time scaling を行える専用の Feedback Model と Edit Model を訓練するため、HelpSteer3 データを収集した。著者らの設定では、あるモデルが最初の応答を生成し、第二のモデルがそれにフィードバックを与え、そのフィードバックを第三のモデルが応答の編集に用いる。Chatbot Arena Elo を強く予測するベンチマークである Arena Hard において、初期応答のドラフト、有効なフィードバック、編集後応答の数を増やすことで性能を高められることを示す。最適にスケールさせた場合、Llama 3 ファミリーの 70B モデルに基づく著者らの構成は、2025 年 3 月 5 日時点で Arena Hard において 92.7 の SoTA 性能に達し、90.4 の OpenAI o1-preview-2024-09-12 と 92.3 の DeepSeek R1 を上回った。

## 論文の面白いところ

この論文の中心は、「考えてから答える」だけが inference-time scaling ではない、という点にある。近年の推論モデルは、検証器や実行結果を使える数学・コード領域で成果を上げたが、文章作成、調査方針の立案、製品設計の相談のようなタスクでは、正解を一つに定めにくい。HelpSteer3 は、その空白に対して、人間の推敲に近い手続きを持ち込む。最初の応答を作り、自然言語の批評を与え、それに従って編集するという素朴な流れである。素朴ではあるが、論文はこれをデータ収集、モデル訓練、推論時のスケーリング、distillation まで一つの実験系として整理している。単に「自己批評させる」とは異なり、フィードバック生成と編集をそれぞれ専用モデルとして訓練した点も重要である。結果を見ると、簡単なプロンプトでは長く書くことが評価に見かけ上有利に働く場合がある一方、Arena Hard のような難しいプロンプトでは、的を絞ったフィードバックが編集の足場になっている。批評が人間に読める形で残るため、将来の個人化や選択的なアラインメントにも接続しやすい。

## 問題設定

対象は、検証可能な唯一の答えを持たない open-ended な一般領域タスクである。従来の inference-time scaling では、複数の推論経路を試し、報酬モデルや検証器で良いものを選ぶ方法が多い。これは数式の答え、テストを通るコード、選択式問題のように、正誤判定が比較的しやすい領域で扱いやすい。しかし、長い説明文の質、助言の妥当性、調査メモの読みやすさなどは、単純な正解照合では測りにくい。RLHF（Reinforcement Learning from Human Feedback）も人間の好みを使うが、多くの場合は選好や数個の評価軸に情報が圧縮される。長い応答のどこが不足し、どのように直すべきかまでは、スカラー評価だけでは残りにくい。論文は、こうしたタスクでは自然言語のフィードバックそのものを推論時の計算資源として使うべきだと位置づける。

## 提案手法

HelpSteer3 は、プロンプト、初期応答、人手による自由記述フィードバック、人手による編集後応答からなるデータである。プロンプトは General、STEM、Coding、Multilingual に分けられ、ShareGPT と WildChat などから収集される。応答は Nemotron、Mistral、Gemma、Phi、Granite など複数の商用利用可能なモデルで生成され、データの偏りを抑える。フィードバック注釈では、各応答に 3〜5 人の注釈者が付き、50〜250 語程度で有用性と改善点を記す。編集段階では、複数のフィードバックを別の注釈者に渡し、応答を実際に書き換えさせる。訓練用には、Feedback Demonstration、Edit Demonstration、Edit Preference の三種類のデータを作る。Feedback Model は応答への批評を生成し、Edit Model はプロンプト、元の応答、フィードバックを受け取って編集後応答を出す。Edit Preference は、フィードバックに従わない編集や、何も変更しない編集を悪い例として、編集の報酬モデルと強化学習に使われる。

## 結果

小規模な Feedback + Edit 構成でも、Llama-3.1-Nemotron-70B-Instruct は MT Bench で 8.98 から 9.16、AlpacaEval 2.0 LC で 57.6 から 62.8、Arena Hard で 85.0 から 87.0 に上がった。Llama-3.3-70B-Instruct でも Arena Hard は 62.4 から 74.8 に上がり、元のモデルが弱い場合にも編集ループが効くことが示されている。単に同じ instruction model に自己批評・自己編集させる設定では、AlpacaEval では伸びるが Arena Hard は 85.0 から 84.6 へ下がった。これは、簡単な質問では長く丁寧に書くことが評価されやすい一方、難しい質問では一般的な自己批評が焦点を外しやすいことを示す。Edit Model から強化学習を外すと、SFT だけのモデルは明確な改善点があっても応答をそのままコピーすることがあり、論文では約 30% と報告されている。推論時に初期応答数、有効なフィードバック数、編集候補数を増やすと、Arena Hard はさらに伸びる。最終的に 8 個の初期応答と 16 個の有効フィードバックを使い、Llama-3.3-Nemotron-70B-Select で選択する構成は 92.7 に達した。人手評価でも、44 件の有効比較のうち改善 16 件、劣化 7 件、同等 21 件であり、主な改善理由は事実性、一貫性、簡潔さであった。

## 具体例

たとえば、ユーザーが「AWS Lambda 上の Node.js 関数で、メモリ割り当てを増やすと実行時間と料金がどう変わるか説明してほしい」と尋ねたとする。初期応答モデルは、メモリを増やすと CPU も増え、実行時間が短くなる場合がある、と一般的に説明する。Feedback Model は、その応答を読み、料金が「メモリ量 × 実行時間」で決まるため、メモリ増加が必ず高くつくとは限らない点を明示すべきだと指摘するかもしれない。また、Node.js では cold start、I/O 待ち、外部 API 呼び出しが支配的な場合には、CPU 増加の効果が限られることも補うよう述べる。Edit Model はそのフィードバックを受け、元の説明を残しつつ、計測すべき指標、AWS Lambda Power Tuning のような実務上の手段、誤解しやすい料金の見方を加えて書き直す。期待される出力は、単なる「メモリを増やすと速くなる」という答えではなく、どの条件で速くなり、どの条件で費用対効果が悪くなるかを分けた説明である。間違えやすい点は、メモリ、CPU、実行時間、課金単位の関係を一方向の因果として書いてしまうことである。この論文の手法は、そうした抜けを自然言語の批評で見つけ、編集で応答へ戻す。

HelpSteer3: Human-Annotated Feedback and Edit Data to Empower Inference-Time Scaling in Open-Ended General-Domain Tasks

HelpSteer3 は、自由記述のフィードバックと、それに基づく応答編集を人手で集めたデータセットである。
論文は、回答を一度出してから批評し、編集するという手順を、open-ended な一般領域タスクの inference-time scaling として扱う。
Llama 3 系 70B モデルを用いた構成は Arena Hard で 92.7 を示し、単純な Best-of-N よりも、批評と編集を挟む方が難しいプロンプトで効きやすいことを示した。

Abstract（日本語訳）

Inference-Time Scaling は、OpenAI o1 や DeepSeek R1 のような近年のモデルの成功において重要であった。しかし、inference-time scaling のためにモデルを訓練する多くの手法は、タスクに検証可能な答えがあることを必要とするため、数学、コーディング、論理推論のような領域への適用に限られる。著者らは、人間が広範な open-ended な営みにおいて、まず初稿を作り、他者から詳しいフィードバックを求め、そのフィードバックに基づいて改善する過程から着想を得た。このために、open-ended な一般領域タスクで inference-time scaling を行える専用の Feedback Model と Edit Model を訓練するため、HelpSteer3 データを収集した。著者らの設定では、あるモデルが最初の応答を生成し、第二のモデルがそれにフィードバックを与え、そのフィードバックを第三のモデルが応答の編集に用いる。Chatbot Arena Elo を強く予測するベンチマークである Arena Hard において、初期応答のドラフト、有効なフィードバック、編集後応答の数を増やすことで性能を高められることを示す。最適にスケールさせた場合、Llama 3 ファミリーの 70B モデルに基づく著者らの構成は、2025 年 3 月 5 日時点で Arena Hard において 92.7 の SoTA 性能に達し、90.4 の OpenAI o1-preview-2024-09-12 と 92.3 の DeepSeek R1 を上回った。

論文の面白いところ

この論文の中心は、「考えてから答える」だけが inference-time scaling ではない、という点にある。近年の推論モデルは、検証器や実行結果を使える数学・コード領域で成果を上げたが、文章作成、調査方針の立案、製品設計の相談のようなタスクでは、正解を一つに定めにくい。HelpSteer3 は、その空白に対して、人間の推敲に近い手続きを持ち込む。最初の応答を作り、自然言語の批評を与え、それに従って編集するという素朴な流れである。素朴ではあるが、論文はこれをデータ収集、モデル訓練、推論時のスケーリング、distillation まで一つの実験系として整理している。単に「自己批評させる」とは異なり、フィードバック生成と編集をそれぞれ専用モデルとして訓練した点も重要である。結果を見ると、簡単なプロンプトでは長く書くことが評価に見かけ上有利に働く場合がある一方、Arena Hard のような難しいプロンプトでは、的を絞ったフィードバックが編集の足場になっている。批評が人間に読める形で残るため、将来の個人化や選択的なアラインメントにも接続しやすい。

問題設定

対象は、検証可能な唯一の答えを持たない open-ended な一般領域タスクである。従来の inference-time scaling では、複数の推論経路を試し、報酬モデルや検証器で良いものを選ぶ方法が多い。これは数式の答え、テストを通るコード、選択式問題のように、正誤判定が比較的しやすい領域で扱いやすい。しかし、長い説明文の質、助言の妥当性、調査メモの読みやすさなどは、単純な正解照合では測りにくい。RLHF（Reinforcement Learning from Human Feedback）も人間の好みを使うが、多くの場合は選好や数個の評価軸に情報が圧縮される。長い応答のどこが不足し、どのように直すべきかまでは、スカラー評価だけでは残りにくい。論文は、こうしたタスクでは自然言語のフィードバックそのものを推論時の計算資源として使うべきだと位置づける。

提案手法

HelpSteer3 は、プロンプト、初期応答、人手による自由記述フィードバック、人手による編集後応答からなるデータである。プロンプトは General、STEM、Coding、Multilingual に分けられ、ShareGPT と WildChat などから収集される。応答は Nemotron、Mistral、Gemma、Phi、Granite など複数の商用利用可能なモデルで生成され、データの偏りを抑える。フィードバック注釈では、各応答に 3〜5 人の注釈者が付き、50〜250 語程度で有用性と改善点を記す。編集段階では、複数のフィードバックを別の注釈者に渡し、応答を実際に書き換えさせる。訓練用には、Feedback Demonstration、Edit Demonstration、Edit Preference の三種類のデータを作る。Feedback Model は応答への批評を生成し、Edit Model はプロンプト、元の応答、フィードバックを受け取って編集後応答を出す。Edit Preference は、フィードバックに従わない編集や、何も変更しない編集を悪い例として、編集の報酬モデルと強化学習に使われる。

結果

小規模な Feedback + Edit 構成でも、Llama-3.1-Nemotron-70B-Instruct は MT Bench で 8.98 から 9.16、AlpacaEval 2.0 LC で 57.6 から 62.8、Arena Hard で 85.0 から 87.0 に上がった。Llama-3.3-70B-Instruct でも Arena Hard は 62.4 から 74.8 に上がり、元のモデルが弱い場合にも編集ループが効くことが示されている。単に同じ instruction model に自己批評・自己編集させる設定では、AlpacaEval では伸びるが Arena Hard は 85.0 から 84.6 へ下がった。これは、簡単な質問では長く丁寧に書くことが評価されやすい一方、難しい質問では一般的な自己批評が焦点を外しやすいことを示す。Edit Model から強化学習を外すと、SFT だけのモデルは明確な改善点があっても応答をそのままコピーすることがあり、論文では約 30% と報告されている。推論時に初期応答数、有効なフィードバック数、編集候補数を増やすと、Arena Hard はさらに伸びる。最終的に 8 個の初期応答と 16 個の有効フィードバックを使い、Llama-3.3-Nemotron-70B-Select で選択する構成は 92.7 に達した。人手評価でも、44 件の有効比較のうち改善 16 件、劣化 7 件、同等 21 件であり、主な改善理由は事実性、一貫性、簡潔さであった。

具体例

たとえば、ユーザーが「AWS Lambda 上の Node.js 関数で、メモリ割り当てを増やすと実行時間と料金がどう変わるか説明してほしい」と尋ねたとする。初期応答モデルは、メモリを増やすと CPU も増え、実行時間が短くなる場合がある、と一般的に説明する。Feedback Model は、その応答を読み、料金が「メモリ量 × 実行時間」で決まるため、メモリ増加が必ず高くつくとは限らない点を明示すべきだと指摘するかもしれない。また、Node.js では cold start、I/O 待ち、外部 API 呼び出しが支配的な場合には、CPU 増加の効果が限られることも補うよう述べる。Edit Model はそのフィードバックを受け、元の説明を残しつつ、計測すべき指標、AWS Lambda Power Tuning のような実務上の手段、誤解しやすい料金の見方を加えて書き直す。期待される出力は、単なる「メモリを増やすと速くなる」という答えではなく、どの条件で速くなり、どの条件で費用対効果が悪くなるかを分けた説明である。間違えやすい点は、メモリ、CPU、実行時間、課金単位の関係を一方向の因果として書いてしまうことである。この論文の手法は、そうした抜けを自然言語の批評で見つけ、編集で応答へ戻す。