LLM開発における公開データの利用法

0. はじめに

　松尾研LLM開発コンペ2025に参加し、チームPromptiaのデータ班にサブリーダーとして所属して推論型LLMの開発を行いました。初心者が個人で参加して学んだこと、こうすれば良かったと思うことなどを、文献検索も交えながらまとめました。

1. データの準備

1) データの種類

　LLMの事後学習のためのデータとしては、1) 公開データ、2) 自作/自験データ、3) 合成データがあります。コンペでは、誰でもアクセスできる公開データの利用が基本で、公認された100種類以上の学習済みのOSS(Open Source Software)のLLMモデルを活用した合成データも利用可能でした。チームPromptiaでは、RLT(Reinforcement Learning Teacher)という手法で生成した合成データを利用することになりました。これは、LLMの教師モデルに、{問題、回答}からなる学習データを与えて途中の思考過程(教師が生徒に説明する文章)を生成させ、それを聞いた生徒モデルの理解度に基づく報酬によって教師モデルを強化学習させるものです。そして、{質問、説明、回答}からなるより良い合成データを生成出来る教師モデルから大量の合成データを生成させ、それで学習済みのOSSのLLMにSFT(Supervised Fine Tuning)を行い、それを成果物とする手法です。強化学習の過程では、学習途上の教師モデルが生成した合成データで繰り返し教師モデルを学習させますが、その際に新たな学習データを付け加えることも可能です。これまで、自身の専門分野における自験例のデータを用いて統計計算や機械学習を行ったことはありましたが、LLMに合成データを生成させることは初めてだったため、どの様にして公開データを検索して収集するか、どの様なデータが強化学習に良いデータかが手探りでした。
　自験例のデータであれば、データの成り立ちや不完全さについてよく分かっているため、データの中身を考えながら前処理ができました。しかし、公開データは第三者が収集・作製したもののため、最初は中身が不明です。Hugging FaceやGitHubには多くの公開データが存在し、一見よく整った"綺麗な"データに見えます。確かにそうしたデータも存在しますが、完全に整えられたデータというより雑多に収集したデータも少なくありません。つまり公開データは玉石混交のため、事前の前処理が重要です。更に、自作データではないため、自分達の目的に適ったデータに出会う確率は低く、5〜6個のデータに当たってみて使えるものが1つあればよい方です。更に、公開データにはLicenseが付与されており、商用利用の可否、改変の可否、License継承義務の有無、License表示義務の有無などにより、いくつもの種類があります。コンペでは将来の商用利用も視野に入れ、商用利用可能な公開データを収集しました(表1参照)。また、MITやApache 2.0、BSD、GPL(v3)など、公開コードに関するLicenseもあります。

表1 コンテンツ(データ/文章/図)に関する Creative Commons License と Public Domain Tool

ライセンス名	商用利用 [NC]	改変禁止 [ND]	継承義務 [SA]	表示義務 [BY]	備考
CC BY	○	○	なし	✓	帰属さえ守れば自由に利用可
CC BY-SA	○	○	✓	✓	改変しても同一ライセンスで
CC BY-ND	○	×	―	✓	改変禁止
CC BY-NC	×	○	なし	✓	非営利利用のみ
CC BY-NC-SA	×	○	✓	✓	非営利＋ライセンス継承
CC BY-NC-ND	×	×	―	✓	最も強い制限
CC0 *	○	○	なし	なし	権利放棄（public domain 相当）
PDM **	○	○	なし	なし	Public Domain を示す Mark

　* Creative Commons の Public Domain Tool
　** Public Domain の作品につけるマーク

2) データの前処理

　前処理の具体的な例を少し挙げてみます。公開データはjosn、josnl、parquet、csvなど様々な形式で保存されています。ストリーミング処理や大規模データセットにはjsonl(JSON Lines)が適しているため、Hugging Face(HF)やGitHubからdownloadしてjsonlに変換します。HFからdownloadする場合、HFが提供しているsnapshot_downloadという関数を使うと、平行downloadでリポジトリ全体を高速で取得できます。josnlは{"key": "value"}という辞書形式を基本にしたもので、{"question": 質問、"thinking": 推論過程、"answer": 最終回答}などにようにタグを統一します。
　そして、データの欠損、重複、短文などを除去してゆきます。短文というのは、たとえばthinkingタグの内容として、[WIP](work in progress:処理中)、Coming soon(近日公開)、See page 11 of this PDF: https//...(この文献参照)などの場合があり、欠損ではないのですがデータとしては不適切です。そのため、本来なら数百〜数千tokenあるべきなのに数〜数十tokenしかない短文の場合、こうしたケースが有り得るため、token数が少ない方からデータの内容を目視すると発見出来ます。

3) データ構築の文献考察

　LLMのデータセットをどのように構築するのがよいかを調査した報告から、高品質データの特性、前処理法、品質評価法などについて、「What makes a high-quality training dataset for Large Language Models」という論文から述べてみます¹。
　それは第１段階としてMicrosoft、Alibaba、DeepSeekなどに属する経験豊富なLLMの専門家13名にインタビューし、高品質なLLMのデータの18の特性、10の前処理、6つの品質評価法を特定し、第２段階としてそれらを23ヶ国の219名のLLM実務者に依頼してオンラインで評価したものです。
　最終的に重要と評価されたデータの特性は以下の13個でした。

◆ 重要なデータの特性
・Reliability(信頼性): データソースの信頼性
・Relevance(関連性): 関連するドメインの知識
・Accuracy(正確性): 汎化能力や性能に直結
・Compliance(法令遵守): 著作権に抵触しない
・Accessibility(アクセス性): 再現性の担保
・Privacy Protection(プライバシー保護): 訴訟リスクの回避
・Documentation(文書化): ドメインや用途の明確化
・Large-Scale Data(大規模性): 多様なパターンを含む
・Diversity(多様性): 汎化能力の向上
・Knowledge Content(知識含有量): 複雑なタスクへの対応
・Wide Range of Sources(多様なソース): 幅広い下流タスクへの対応
・Absence of Low-Quality Documents(低品質文書の排除): 出力精度/学習能力の向上
・Absence of Toxic Data(有害データの排除): 安全で倫理的なAIの実現

　最も重要とされた特性は正確性で、続いて信頼性、関連性、コンプライアンスです。
　また、最優先ではないが、ある程度重要性と評価された特性は以下の５個でした。

◆ ある程度重要な特性
・Completeness(完全性): 現実のデータは不完全で、LLMはそれに対応可能
・Balance(データのバランス): 実現困難で、自然な分布も損ねる
・Absence of Duplicate Data(重複の排除): LLMは重複に耐性があり情報損失のリスクもある
・Consistency(一貫性): LLMは多少の不整合に耐えられ、多様な形式に対応可となる
・Timeliness(適時性): 最新情報は外部データやRAGで補える

　このことから、無理にデータの整合性を取る必要はないことが分かります。
　次に10の前処理は以下のものでした。括弧内は何％の実務者が行っているかを示します。

◆ 前処理

1. 低品質の文章の除去 (59.5%): ノイズを除き、品質を向上
2. 重複データの削除 (48.6%): 冗長例を減らし、計算コストを減らす
3. 欠損・外れ値・誤謬の削除 (45.9%): 異常値を除去
4. 低品質、不完全、脆弱なコードの削除 (43.2%): バグの除去
5. 有害データの削除 (40.5%): 毒性発言を除去
6. センシティブなデータの削除 (35.1%): 機密情報や個人識別情報を除去
7. 未許可データの削除 (27.0%): 権利不明なデータを除去
8. データの形式や構文の標準化 (27.0%): 形式差をなくして一貫性確保
9. データのバランスを取る (21.6%): 偏った分布をならす
10. 低perplexity(混乱度)データの削除 (16.2%): 単純すぎる文を減らす

　どれも直ぐに想定されるもので、特殊な処理はないようです。
　６つの品質評価法とは以下のもので、括弧内は何％の実務者が行っているかを示します。

◆ 品質評価法

1. 目視評価 (51.4%)
2. 定量的品質評価 (45.9%)　欠損率、正確性、完全性、一貫性などの定量評価
3. データの可視化 (37.8%)
4. 小規模LLMで試す (27.0%)　前処理済みデータvs未処理データで性能比較
5. 品質評価LLMで試す (24.3%)　高品質データと低品質データを分類できるLLMを構築する
6. Open Sourceの品質評価toolの利用 (18.9%)　Apache Griffin、Deequ、Qualitisなど

　人間による目視や可視化が上位に来ていることが印象的で、やはり"Eye ball評価"(目視による確認)が最重要なようです。human-in-the-loopという観点からも、人手による評価は欠かせない作業と言えます。
　最後に、前処理や品質評価における課題にも触れられています。

◆ 前処理や品質評価の課題

1. 前処理には統一された手法が存在しない。
2. どこまで削除や変換をすべきかの基準がない。
   　(毒性データを削除しすぎるとモデルがそれを認識出来なくなる可能性もある)
3. 目視も必要なため非効率的で主観的である。
4. セマンティックな品質の定量化の困難さ。
   (ドメインに依存しない不変的な品質評価の数値指標がない)
5. 非構造データに対する標準的評価法がない。
6. 小規模LLMな評価モデルを作っても誤分類が多い。
7. 小規模LLMの結果が大規模モデルに転用できる保証がない。

　データの収集や処理は、人為や人知に頼る部分が多く、それでいてLLMの性能向上に重要な部分です。標準化が難しい工程ですが、LLMの作成者の知恵の出し所でもあると思います。また最終的には、いろいろなデータセットでLLMを学習させてみて、最も性能がよいデータを選ぶしかないかも分かりません。
　実務者の90%以上が前処理を行い、70%以上が品質評価を実施していました。今後は、標準化された前処理や品質評価のワークフローの開発、前処理がモデルの性能に及ぼす影響の評価、小規模モデルでの実験が大規模モデルにも適用可能かどうかの理論的検証などが課題と考えられています。

2. 事後学習データのスケール則

1) 事後学習データの文献考察

　事前学習においてデータ量とパラメーター数と計算量にスケール則が成り立つことは言うまでもありませんし、推論時に1問当たりに使う計算量(思考token数)にもスケール則が成り立つことがOpenAIのo1モデルで示されました^2,3。更に最近では、事後学習における推論データの長さにもスケール則が成り立つという報告もあります。「Long Is More Important Than Difficult for Training Reasoning Models」という論文では、事後学習のSupervised Fine Tuning(SFT)において、問題の難易度よりも推論の長さの方がモデルの性能向上により影響を与えたと報告しています⁴。困難な問題はより複雑な推論連鎖を誘発し、事前学習された知識をより効果的に活用できると考えられてきましたが、事後学習におけるモデルの性能向上において鍵となるのは、問題の難易度ではなく、推論の長さそのものであるという新たな視点を提案しています。
　まず、彼らは同程度の推論長を持つが難易度が異なるデータセットでQwen2.5-7B-InstructとQwen2.5-32B-Instructを学習させ、AIME2024とMATH500で性能評価を行いました。一つ目のデータセットは、複数の比較的易しい小問からなる包括的な問題 vs.難易度の高い1つの問題でそれぞれ構成されており、データの長さはどちらも同等です。もし問題の難易度が本質的に重要なら、難易度の高い問題で訓練した方が高い性能を示すはずです。しかし、学習後の性能評価ではどちらの問題群で訓練しても性能はほぼ同一でした。二つ目のデータセットは、問題の難易度よりも推論時の推論長の方が性能向上に影響を及ぼすことを示すため、関連性のない独立した2つの設問を連結しただけの問題vs.単一の複雑な問題でそれぞれ構成されており、前者では単純に２つの問題を解くために推論長が長くなり、後者では問題の複雑さから推論長が長くなるように設定され、結果的に両データの難易度は異なるが推論長は同等になるよう調整されました。学習後の性能評価では、どちらの問題群で訓練しても性能は同等で、性能向上は推論長の影響が大きいことが示唆されました。
　次に、彼らは問題の難易度を一定に保ち、推論時のtoken長を指数関数的に増やすことがモデルの性能にどういう影響を与えるかを調べました。推論時のtoken長は、1.5K、3K、6K、12K、つまり、1.5×2n-1と設定されました。データ数は300セットで、モデルはQwen2.5-32B-Instructを用い、ベンチマークはMATH500とGPQA Diamondが使われました。その結果、横軸に推論時のtoken長を対数目盛でとり、縦軸にAccuracyをとって図示すると、Accuracyは直線的に向上し、MATH500では87.6%から93%に(+5.4%)、GPQA Diamondでは56.9%から63%へ(+6.1%)と線形に向上しました。つまり、SFTにより5〜6%もの性能向上が見られています。
　また、彼らは性能向上の要因を調べるため、1.5Kと12Kの推論長で訓練されたモデルの推論過程を分析しました。それぞれの成功した推論と失敗した推論において、平均推論token長と頻出したtokenのTop 10を比較したのが表２です。ここでは、頻出tokenの内、転換語の頻度のみ掲載します。

■ 表２　SFT用のデータの推論長がモデル出力の長さや転換語に及ぼす影響

データのサイズ	成功/失敗	平均token長	転換語の頻度
1.5K	成功	2147.7	Wait(1.07%), But(0.91%)
1.5K	失敗	8247.2	Wait(3.78%), But(5.05%)
12K	成功	4716.3	But(1.19%), Wait(0.81%)
12K	失敗	15694.5	But(1.27%), Wait(0.80%)

・Shen et al., "Long Is More Important Than Difficult for Training Reasoning Models", arXiv:2503.18069⁴のTable 2 より(改変)

　学習データのtoken数を８倍にすると、推論の成功や失敗にかかわらず、推論過程のtoken数は約２倍になっています。また、「待て」や「しかし」という転換語は、1.5Kのデータで学習した場合、失敗すると3〜5倍に増えていますが、12Kでは失敗してもほとんど増えていません。これは12Kのデータで学習した場合、推論が失敗しても推論過程がより構造的で安定していることが示唆されます。つまり、長い推論長のデータでSFTを行うと、モデルはより安定した推論の枠組みを獲得し、精度向上の一因になったと推測されます。
　最後に、彼らは推論長の長いデータを作成するための簡潔な手法を導入し、推論長が長い合成データによるモデルの訓練が有効であることを示しています。既存の公開データでは、15,000tokenを超える推論長を持つデータセットは少なく、推論モデルの性能向上を制限しています。そこで、彼らはopen-thoughts/OpenThoughts-114kという公開データに対し、DeepSeek-R1を用いて推論過程を生成させ、それからランダムに2つの数学の問題を選択し、それらの問題・推論過程・回答をそれぞれ接続するという簡潔な方法で推論過程の長いデータを800件作成しました。具体的には以下のようなPromptを用いた手法です。

・System Prompt
A conversation between User and Assistant. The User asks a question, and the Assistant solves it. The assistant first thinks about the reasoning process in the mind and then provides the user with the answer. The reasoning process and answer are enclosed within <|begin_of_thought|> <|end_of_thought|> and <|begin_of_solution|> <|end_of_solution|> tags, respectively, i.e., <|begin_of_thought|> reasoning process here <|end_of_thought|> <|begin_of_solution|> answer here <|end_of_thought|>.

・User Prompt
I need help with two problems.
The first one is PROBLEM1, and the second one is PROBLEM2.

・Output ☜ 教師データによりモデルに学習させる部分
<|begin_of_thought|>
I will handle these two problems one by one.
I will start with the first problem. THINKING1.
Now I will turn to the second problem. THINKING2.
<|end_of_thought|>

<|begin_of_solution|>
The solution for the first problem is as follows. SOLUTION1.
The solution for the second problem is as follows. SOLUTION2.
<|end_of_solution|>
Shen et al., "Long Is More Important Than Difficult for Training Reasoning Models"3, arXiv:2503.18069のAppendix B. Prompt for synthesizing Long1kより(改変)

　この中にあるPROBLEM1やSOLUTION1などには、基本的にはOpenThoughts-114kからランダムに選んだ質問や回答を持ってくるだけのため、合成データ作成の手法としては簡単なものです。更に、この800問の問題に対するoverfittingを防ぐため、これとは別にs1kというデータセットからランダムに200問の数学の問題を抽出したものも加え、合計1000問からなるLong1Kが作成されました4。そして、8枚のNVIDIA A800-SXM4-80GBを用いてLong1KをOpenThoughts-114kに学習させてLong1K-32Bというモデルを作成し、AIME2024/2025、MATH500、GPQA Diamondをそれぞれ5回解かせました。推論時の最大出力長は32K tokenに設定されました。このLong1K-32Bを、問題数で同規模の1,000問程度のデータセットや遙かに大規模なデータセットで訓練されたモデルと比較しました。比較対象のデータセットのtoken数は数千程度ですが、Long1Kは最大32Kあります。

■ 表３　Long1Kデータとその他のデータによるSFT後の各種ベンチマークの比較

Model	データのサンプル数	MATH500	AIME2025	GPQA Diamond
s1-32B	1K	92.6%	26.7%	56.6%
s1.1-32B	1K	89.0%	49.3%	60.1%
LIMO	0.8K	94.8%	49.3%	66.7%
OpenThinker-32B	114K	90.6%	53.3%	61.6%
DeepSeek-R1-Distill-Qwen-32B	800K	93.0%	55.9%	62.1%
Long1K-32B	1K	95.6%	53.3%	71.1%

・Shen et al., "Long Is More Important Than Difficult for Training Reasoning Models", arXiv:2503.18069⁴のTable 3 より(改変)

　同程度の問題数のデータでSFTを行ったモデルと比較すると、Long1Kはどのベンチマークでも上回っています。また、問題数が114〜800倍の大規模データによるSFTと比較しても、Long1Kは遜色ない優れた性能を示しています。複数の問題文の質問・推論過程・回答を接続詞で繋ぐという簡単な方法で作成した合成データが、推論長を効果的に拡張し、モデルの推論性能を高め得ることが示唆されました。問題の難易度を上げるためにはデータフィルタリングなどが必要になりますが、それが回避出来るため実用的です。
　もちろん、これらの提案が本当に有効かどうかは、第三者による追実験で再現性を確認することが不可欠ですが、類似の報告は他にも散見されます^5,6,7。一般的に、SFTで用いるデータの推論長を長くしたとしても、モデルが新たな知識を獲得するわけではなく、根本的に新しい推論手法を身につけるわけでもありません。SFTのベースモデルはすでに十分な事前学習と事後学習を経ているため、長い推論過程(Chain-of-Thought)が含まれているデータで微調整することで、単に「これまで推論に必要なトークンが足りずに解けなかった」ことに対し、十分な長さの推論フォーマットを獲得した、つまり、トークン長の制約が外れた、ということによる性能向上が大半を占めているのではないかと思われます。つまり、言語タスクが改善されたのではなく、学習ダイナミクスが改善されたことによる性能向上ではないかと推測されます。

2) RLTによる合成データ

　こうした考え方に照らし、私たちのチームでRLTのために収集したデータを振り返ってみました。コンペのテーマはHumanity's Last Exam(HLE)という最高難易度のclosedな問題を解くことでした。データ収集の方針は、商用利用可能な公開データから、出来るだけ難易度が高く、Token数も多いものを選ぶことでした。チームの戦略は、まずRLTを行って優れた教師モデルを作製し、それから合成データを生成し、それでSFTを行うことでした。そこで、データ班ではRLT用のデータ収集を中心に行い、数学系、物理系、医学生物学系の問題を集めました。図１は、Hugging Faceで公開されている医学生物学系のデータであるqiaojin/PubMedQAから、21万件ほどのPQA-Aというデータセットをdownloadし、その単語数の分布を示したものです。

■ 図１　RLT用の生物医学系のデータセットにおける単語数の分布

　RLT用のデータの単語数の分布の平均は1,726単語で、英語単語1つが1.3tokenに相当すると仮定すると、平均Token数は2,244程度と推測されました。多くの公開データは1つのサンプル当りせいぜい数千単語のため、もしSFTのためにより長い単語数のデータを準備するには何らかの形で合成データを生成する必要があると言えます。RLTのための学習データは難易度が高いことを期待して、単語数が多いものを選ぶようにしましたが、極端に長い外れ値のようなものは省きました。
　次に、図１の医学生物学のデータでQwen2.5-7Bモデルを用いてRLTを行い、教師データが生成した合成データの単語数の分布は図２のようになりました。平均単語数が3,551で、平均token数なら約4617程度と推測され、RLT前のデータより2.7倍程度に増えましたが、今回のコンペの課題であったHLEのような超難問を解く推論モデルを開発するには、事後学習のデータ長としてはまだまだ短いと言えます。

■ 図２　RLTの教師モデルが出力した医学生物学の合成データにおける単語数の分布

　RLTによる教師モデルが生成した合成データのうち単語数が3K〜4Kのものからランダムに20個を取り出し、質問と回答に対して教師モデルが生成した推論過程の論理性、焦点維持、専門性、結論到達性について、AnthropicのSonnet4.5で1〜5のスコアで評価したところ、表４のようになり、総合評価は平均4.88 (97.5%)でトレーニングデータとしての品質は高かったと言えます。しかし、「事後学習データのスケール則」という観点から見るとデータ長が短いため、何らかのデータ合成によってToken長を増やすことか望ましく、特に、長い推論過程を要する問題を解くためには留意すべきと思われます。

■ 表４　RLTによる合成データ: Token数3K〜4Kからランダムに20個抽出しSonnet4.5で評価

評価項目	平均スコア	百分率スコア
論理性	4.90/5.00	98.0%
焦点維持	4.90/5.00	98.0%
専門性	4.90/5.00	98.0%
結論到達性	4.80/5.00	96.0%
総合評価	4.88/5.00	97.6%

　次に、RLTの教師モデルが作った合成データ(図２)において、単語数が20K以上の所にごく小さなpeakがあります。それらのデータの品質を調べるため、その領域からランダムに20個取り出し、先ほどと同様に質問と回答に対する推論過程を評価してみました(表５)。

■ 表５　RLTによる合成データ20個の評価：単語数が20K以上の外れ値の場合

評価項目	平均スコア	百分率スコア
論理性	2.20/5.00	44.0%
焦点維持	1.80/5.00	36.0%
専門性	4.85/5.00	97.0%
結論到達性	5.00/5.00	100.0%
総合評価	3.46/5.00	69.2%

　抽出した合成データの平均単語数は26,989語と多く、Token数では約35,000程度と推測されました。表５から、それらのデータは医学的な専門用語を扱い、結論にも到達していましたが、個々の内容を見ると大きな問題が認められました。18のサンブルにおいて同一の文節が何度も反復されており、１つのサンプルでは中国語が混入したり、複数のサンブルで内容が環境問題に逸脱したりしていました。医学的知識は適切でしたが、生成プロセスの制御が出来なくなった結果と考えられ、学習データとしては不適切なものでした。つまり、合成データの適格性はデータ長だけでは判断できず、内容の妥当性とデータの長さの両面からの評価が必要です。特に、極端に長い合成データは学習データとして不適格な可能性を疑う必要があると言えます。

3. まとめ

　本稿では、松尾研LLM開発コンペ2025への参加を通じ、推論型LLMの事後学習における公開データの利用法について述べました。
　データの準備においては、公開データが玉石混交であることから適切な前処理が不可欠で、高品質データとして正確性・信頼性・関連性・コンプライアンスなどが重視されており、実務者の多くが目視による評価を実施していました¹。標準化された前処理手法が確立していない以上、"Eye Ball評価"(目視)による人間の介入が重要な工程と言えます。
　事後学習のデータ長のスケール則に関しては、「Long is More Important Than Difficult」が報告しているように、問題の難易度より推論過程の長さがモデルの性能向上に寄与する、という知見は重要だと思います⁴。コンペの予選において、どのチームもモデルの性能向上に苦戦した理由の１つとも推測できます。また、Long1Kの作成で利用された複数の問題を連結するという単純な手法で推論長を伸ばすことで、大規模データセットに匹敵する性能向上が得られたことは示唆的です。更に、RLTによる合成データの分析で、推論長が極端に長い合成データには品質が劣化したデータが混入していたことから、合成データの適格性の評価には、データ長と内容の妥当性の両面の評価が必要と言えます。
　今後の課題としては、データの品質を維持しながらデータの推論長を効果的に伸ばす手法の確立が望まれます。LLMの学習データの準備は、標準化が難しく人為に頼るところが多い工程ですが、同時に、モデル作成者の知恵の出し所でもあります。本稿がこれからLLM開発に取り組む方々の一助となれば幸いです。

謝辞

　松尾研LLM開発コンペ2025で共に戦ったチームPromptiaの田口リーダーを始めメンバーの方々、他のチームの方々、またコンペの運営に携わって下さった全ての方々に心より感謝申し上げます。なお、本プロジェクトは、国立研究開発法人新エネルギー・産業技術総合開発機構(以下「NEDO」)の「日本語版医療特化型LLMの社会実装に向けた安全性検証・実証」における基盤モデルの開発プロジェクトの一環として行われます。

参考文献

1. Xiao Yu, Zexian Zhang, Feifei Niu, Xing Hu, Xin Xia, John Grundy. What makes a high-quality training dataset for Large Language Models: A practitioners' Perspective. Proceedings ASE 2024. https://nzjohng.github.io/publications/papers/ase2024_1.pdf
2. Kaplan J, McCandelish S, Henighan T, Brown TB, Chess B, Child R, et al. Scaling Laws for Neural Language Models. arXiv:2001.08361v1 cs.LG 2020 https://arxiv.org/pdf/2001.08361
3. Niklas Muenninghoff, Zitong Yang, Weijia Shi, Xiang Lisa Li, et al. s1: Simple test-time scaling. arXiv:2501.19393v3 cs.CL 2025 https://arxiv.org/pdf/2501.19393
4. Si Shen, Fei Huang, Zhixiao Zhao, Chang Liu, Tiansheng Zheng, Danhao Zhu. Long Is More Important Than Difficult for Training Reasoning Models. arXiv:2503.18069v1 cs.CL 2025 https://arxiv.org/pdf/2503.18069
5. Mosh Levy, Alon Jacoby, Joav Goldberg. Same Task, More Tokens: the Impact of Input Length on the Reasoning Performance of Large Language Models. arXiv:2402.14848v2 cs.CL 2024 https://arxiv.org/pdf/2402.14848
6. Liao Bingli, Danilo Vasconcellos Vargas. Extending Token Computation for LLM Reasoning. arXiv:2403.14932V3 cs.CL 2024 https://arxiv.org/pdf/2403.14932
7. Linyu Ou, Yuyang Yin. Empowering Lightweight MLLMs with Reasoning via Long CoT SFT. arXiv:2509.03321v2 cs.CV 2025 https://arxiv.org/pdf/2509.03321