lewtun HF staff commited on
Commit
8ff664b
1 Parent(s): f44258c

Add citations

Browse files
Files changed (2) hide show
  1. app/src/bibliography.bib +102 -361
  2. app/src/index.html +12 -12
app/src/bibliography.bib CHANGED
@@ -1,398 +1,139 @@
1
- @misc{penedo2024finewebdatasetsdecantingweb,
2
- title={The FineWeb Datasets: Decanting the Web for the Finest Text Data at Scale},
3
- author={Guilherme Penedo and Hynek Kydlíček and Loubna Ben allal and Anton Lozhkov and Margaret Mitchell and Colin Raffel and Leandro Von Werra and Thomas Wolf},
4
- year={2024},
5
- eprint={2406.17557},
6
- archivePrefix={arXiv},
7
- primaryClass={cs.CL},
8
- url={https://arxiv.org/abs/2406.17557},
9
- }
10
- @article{hendryckstest2021,
11
- title={Measuring Massive Multitask Language Understanding},
12
- author={Dan Hendrycks and Collin Burns and Steven Basart and Andy Zou and Mantas Mazeika and Dawn Song and Jacob Steinhardt},
13
- journal={Proceedings of the International Conference on Learning Representations (ICLR)},
14
- year={2021}
15
- }
16
- @inproceedings{zellers2019hellaswag,
17
- title={HellaSwag: Can a Machine Really Finish Your Sentence?},
18
- author={Zellers, Rowan and Holtzman, Ari and Bisk, Yonatan and Farhadi, Ali and Choi, Yejin},
19
- booktitle ={Proceedings of the 57th Annual Meeting of the Association for Computational Linguistics},
20
- year={2019}
21
- }
22
- @misc{madaan2024quantifyingvarianceevaluationbenchmarks,
23
- title={Quantifying Variance in Evaluation Benchmarks},
24
- author={Lovish Madaan and Aaditya K. Singh and Rylan Schaeffer and Andrew Poulton and Sanmi Koyejo and Pontus Stenetorp and Sharan Narang and Dieuwke Hupkes},
25
  year={2024},
26
- eprint={2406.10229},
27
  archivePrefix={arXiv},
28
  primaryClass={cs.LG},
29
- url={https://arxiv.org/abs/2406.10229},
30
- }
31
- @misc{open-llm-leaderboard-v2,
32
- author = {Clémentine Fourrier and Nathan Habib and Alina Lozovskaya and Konrad Szafer and Thomas Wolf},
33
- title = {Open LLM Leaderboard v2},
34
- year = {2024},
35
- publisher = {Hugging Face},
36
- howpublished = "\url{https://huggingface.co/spaces/open-llm-leaderboard/open_llm_leaderboard}",
37
  }
38
- @misc{biderman2024lessonstrenchesreproducibleevaluation,
39
- title={Lessons from the Trenches on Reproducible Evaluation of Language Models},
40
- author={Stella Biderman and Hailey Schoelkopf and Lintang Sutawika and Leo Gao and Jonathan Tow and Baber Abbasi and Alham Fikri Aji and Pawan Sasanka Ammanamanchi and Sidney Black and Jordan Clive and Anthony DiPofi and Julen Etxaniz and Benjamin Fattori and Jessica Zosa Forde and Charles Foster and Jeffrey Hsu and Mimansa Jaiswal and Wilson Y. Lee and Haonan Li and Charles Lovering and Niklas Muennighoff and Ellie Pavlick and Jason Phang and Aviya Skowron and Samson Tan and Xiangru Tang and Kevin A. Wang and Genta Indra Winata and François Yvon and Andy Zou},
41
- year={2024},
42
- eprint={2405.14782},
43
- archivePrefix={arXiv},
44
- primaryClass={cs.CL},
45
- url={https://arxiv.org/abs/2405.14782},
46
- }
47
- @misc{li2024datacomplmsearchgenerationtraining,
48
- title={DataComp-LM: In search of the next generation of training sets for language models},
49
- author={Jeffrey Li and Alex Fang and Georgios Smyrnis and Maor Ivgi and Matt Jordan and Samir Gadre and Hritik Bansal and Etash Guha and Sedrick Keh and Kushal Arora and Saurabh Garg and Rui Xin and Niklas Muennighoff and Reinhard Heckel and Jean Mercat and Mayee Chen and Suchin Gururangan and Mitchell Wortsman and Alon Albalak and Yonatan Bitton and Marianna Nezhurina and Amro Abbas and Cheng-Yu Hsieh and Dhruba Ghosh and Josh Gardner and Maciej Kilian and Hanlin Zhang and Rulin Shao and Sarah Pratt and Sunny Sanyal and Gabriel Ilharco and Giannis Daras and Kalyani Marathe and Aaron Gokaslan and Jieyu Zhang and Khyathi Chandu and Thao Nguyen and Igor Vasiljevic and Sham Kakade and Shuran Song and Sujay Sanghavi and Fartash Faghri and Sewoong Oh and Luke Zettlemoyer and Kyle Lo and Alaaeldin El-Nouby and Hadi Pouransari and Alexander Toshev and Stephanie Wang and Dirk Groeneveld and Luca Soldaini and Pang Wei Koh and Jenia Jitsev and Thomas Kollar and Alexandros G. Dimakis and Yair Carmon and Achal Dave and Ludwig Schmidt and Vaishaal Shankar},
50
- year={2024},
51
- eprint={2406.11794},
52
  archivePrefix={arXiv},
53
  primaryClass={cs.LG},
54
- url={https://arxiv.org/abs/2406.11794},
55
  }
56
- @misc{gu2024olmesstandardlanguagemodel,
57
- title={OLMES: A Standard for Language Model Evaluations},
58
- author={Yuling Gu and Oyvind Tafjord and Bailey Kuehl and Dany Haddad and Jesse Dodge and Hannaneh Hajishirzi},
59
- year={2024},
60
- eprint={2406.08446},
61
- archivePrefix={arXiv},
62
- primaryClass={cs.CL},
63
- url={https://arxiv.org/abs/2406.08446},
64
- }
65
- @article{radford2019language,
66
- title={Language Models are Unsupervised Multitask Learners},
67
- author={Radford, Alec and Wu, Jeff and Child, Rewon and Luan, David and Amodei, Dario and Sutskever, Ilya},
68
- year={2019}
69
- }
70
- @inproceedings{barbaresi-2021-trafilatura,
71
- title = {Trafilatura: A Web Scraping Library and Command-Line Tool for Text Discovery and Extraction},
72
- author = "Barbaresi, Adrien",
73
- booktitle = "Proceedings of the Joint Conference of the 59th Annual Meeting of the Association for Computational Linguistics and the 11th International Joint Conference on Natural Language Processing: System Demonstrations",
74
- pages = "122--131",
75
- publisher = "Association for Computational Linguistics",
76
- url = "https://aclanthology.org/2021.acl-demo.15",
77
- year = 2021,
78
- }
79
- @misc{penedo2023refinedweb,
80
- title={The RefinedWeb Dataset for Falcon LLM: Outperforming Curated Corpora with Web Data, and Web Data Only},
81
- author={Guilherme Penedo and Quentin Malartic and Daniel Hesslow and Ruxandra Cojocaru and Alessandro Cappelli and Hamza Alobeidli and Baptiste Pannier and Ebtesam Almazrouei and Julien Launay},
82
  year={2023},
83
- eprint={2306.01116},
84
- archivePrefix={arXiv},
85
- primaryClass={cs.CL}
86
- }
87
- @article{joulin2016fasttext,
88
- title={FastText.zip: Compressing text classification models},
89
- author={Joulin, Armand and Grave, Edouard and Bojanowski, Piotr and Douze, Matthijs and J{\'e}gou, H{\'e}rve and Mikolov, Tomas},
90
- journal={arXiv preprint arXiv:1612.03651},
91
- year={2016}
92
- }
93
- @article{joulin2016bag,
94
- title={Bag of Tricks for Efficient Text Classification},
95
- author={Joulin, Armand and Grave, Edouard and Bojanowski, Piotr and Mikolov, Tomas},
96
- journal={arXiv preprint arXiv:1607.01759},
97
- year={2016}
98
- }
99
- @misc{penedo2024datatrove,
100
- author = {Penedo, Guilherme and Kydlíček, Hynek and Cappelli, Alessandro and Sasko, Mario and Wolf, Thomas},
101
- title = {DataTrove: large scale data processing},
102
- year = {2024},
103
- publisher = {GitHub},
104
- journal = {GitHub repository},
105
- url = {https://github.com/huggingface/datatrove}
106
- }
107
- @misc{chiang2024chatbot,
108
- title={Chatbot Arena: An Open Platform for Evaluating LLMs by Human Preference},
109
- author={Wei-Lin Chiang and Lianmin Zheng and Ying Sheng and Anastasios Nikolas Angelopoulos and Tianle Li and Dacheng Li and Hao Zhang and Banghua Zhu and Michael Jordan and Joseph E. Gonzalez and Ion Stoica},
110
- year={2024},
111
- eprint={2403.04132},
112
  archivePrefix={arXiv},
113
- primaryClass={cs.AI}
114
- }
115
- @misc{rae2022scaling,
116
- title={Scaling Language Models: Methods, Analysis & Insights from Training Gopher},
117
- author={Jack W. Rae and Sebastian Borgeaud and Trevor Cai and Katie Millican and Jordan Hoffmann and Francis Song and John Aslanides and Sarah Henderson and Roman Ring and Susannah Young and Eliza Rutherford and Tom Hennigan and Jacob Menick and Albin Cassirer and Richard Powell and George van den Driessche and Lisa Anne Hendricks and Maribeth Rauh and Po-Sen Huang and Amelia Glaese and Johannes Welbl and Sumanth Dathathri and Saffron Huang and Jonathan Uesato and John Mellor and Irina Higgins and Antonia Creswell and Nat McAleese and Amy Wu and Erich Elsen and Siddhant Jayakumar and Elena Buchatskaya and David Budden and Esme Sutherland and Karen Simonyan and Michela Paganini and Laurent Sifre and Lena Martens and Xiang Lorraine Li and Adhiguna Kuncoro and Aida Nematzadeh and Elena Gribovskaya and Domenic Donato and Angeliki Lazaridou and Arthur Mensch and Jean-Baptiste Lespiau and Maria Tsimpoukelli and Nikolai Grigorev and Doug Fritz and Thibault Sottiaux and Mantas Pajarskas and Toby Pohlen and Zhitao Gong and Daniel Toyama and Cyprien de Masson d'Autume and Yujia Li and Tayfun Terzi and Vladimir Mikulik and Igor Babuschkin and Aidan Clark and Diego de Las Casas and Aurelia Guy and Chris Jones and James Bradbury and Matthew Johnson and Blake Hechtman and Laura Weidinger and Iason Gabriel and William Isaac and Ed Lockhart and Simon Osindero and Laura Rimell and Chris Dyer and Oriol Vinyals and Kareem Ayoub and Jeff Stanway and Lorrayne Bennett and Demis Hassabis and Koray Kavukcuoglu and Geoffrey Irving},
118
- year={2022},
119
- eprint={2112.11446},
120
- archivePrefix={arXiv},
121
- primaryClass={cs.CL}
122
  }
123
- @misc{lee2022deduplicating,
124
- title={Deduplicating Training Data Makes Language Models Better},
125
- author={Katherine Lee and Daphne Ippolito and Andrew Nystrom and Chiyuan Zhang and Douglas Eck and Chris Callison-Burch and Nicholas Carlini},
126
- year={2022},
127
- eprint={2107.06499},
 
128
  archivePrefix={arXiv},
129
- primaryClass={cs.CL}
 
130
  }
131
- @misc{carlini2023quantifying,
132
- title={Quantifying Memorization Across Neural Language Models},
133
- author={Nicholas Carlini and Daphne Ippolito and Matthew Jagielski and Katherine Lee and Florian Tramer and Chiyuan Zhang},
134
- year={2023},
135
- eprint={2202.07646},
 
136
  archivePrefix={arXiv},
137
- primaryClass={cs.LG}
 
138
  }
139
- @misc{raffel2023exploring,
140
- title={Exploring the Limits of Transfer Learning with a Unified Text-to-Text Transformer},
141
- author={Colin Raffel and Noam Shazeer and Adam Roberts and Katherine Lee and Sharan Narang and Michael Matena and Yanqi Zhou and Wei Li and Peter J. Liu},
142
- year={2023},
143
- eprint={1910.10683},
 
144
  archivePrefix={arXiv},
145
- primaryClass={cs.LG}
 
146
  }
147
- @misc{touvron2023llama,
148
- title={LLaMA: Open and Efficient Foundation Language Models},
149
- author={Hugo Touvron and Thibaut Lavril and Gautier Izacard and Xavier Martinet and Marie-Anne Lachaux and Timothée Lacroix and Baptiste Rozière and Naman Goyal and Eric Hambro and Faisal Azhar and Aurelien Rodriguez and Armand Joulin and Edouard Grave and Guillaume Lample},
 
150
  year={2023},
151
- eprint={2302.13971},
152
  archivePrefix={arXiv},
153
- primaryClass={cs.CL}
154
- }
155
- @article{dolma,
156
- title = {Dolma: an Open Corpus of Three Trillion Tokens for Language Model Pretraining Research},
157
- author={
158
- Luca Soldaini and Rodney Kinney and Akshita Bhagia and Dustin Schwenk and David Atkinson and
159
- Russell Authur and Ben Bogin and Khyathi Chandu and Jennifer Dumas and Yanai Elazar and
160
- Valentin Hofmann and Ananya Harsh Jha and Sachin Kumar and Li Lucy and Xinxi Lyu and
161
- Nathan Lambert and Ian Magnusson and Jacob Morrison and Niklas Muennighoff and Aakanksha Naik and
162
- Crystal Nam and Matthew E. Peters and Abhilasha Ravichander and Kyle Richardson and Zejiang Shen and
163
- Emma Strubell and Nishant Subramani and Oyvind Tafjord and Pete Walsh and Luke Zettlemoyer and
164
- Noah A. Smith and Hannaneh Hajishirzi and Iz Beltagy and Dirk Groeneveld and Jesse Dodge and Kyle Lo
165
- },
166
- year = {2024},
167
- journal={arXiv preprint},
168
- }
169
- @article{gao2020pile,
170
- title={The {P}ile: An 800{GB} dataset of diverse text for language modeling},
171
- author={Gao, Leo and Biderman, Stella and Black, Sid and Golding, Laurence and Hoppe, Travis and Foster, Charles and Phang, Jason and He, Horace and Thite, Anish and Nabeshima, Noa and others},
172
- journal={arXiv preprint arXiv:2101.00027},
173
- year={2020}
174
- }
175
- @misc{cerebras2023slimpajama,
176
- author = {Soboleva, Daria and Al-Khateeb, Faisal and Myers, Robert and Steeves, Jacob R and Hestness, Joel and Dey, Nolan},
177
- title = {SlimPajama: A 627B token cleaned and deduplicated version of RedPajama},
178
- month = {June},
179
- year = 2023,
180
- url = {https://huggingface.co/datasets/cerebras/SlimPajama-627B},
181
- }
182
- @software{together2023redpajama,
183
- author = {Together Computer},
184
- title = {RedPajama: an Open Dataset for Training Large Language Models},
185
- month = {October},
186
- year = 2023,
187
- url = {https://github.com/togethercomputer/RedPajama-Data}
188
- }
189
- @article{jaccard1912distribution,
190
- title={The distribution of the flora in the alpine zone. 1},
191
- author={Jaccard, Paul},
192
- journal={New phytologist},
193
- volume={11},
194
- number={2},
195
- pages={37--50},
196
- year={1912},
197
- publisher={Wiley Online Library}
198
  }
199
- @misc{albalak2024survey,
200
- title={A Survey on Data Selection for Language Models},
201
- author={Alon Albalak and Yanai Elazar and Sang Michael Xie and Shayne Longpre and Nathan Lambert and Xinyi Wang and Niklas Muennighoff and Bairu Hou and Liangming Pan and Haewon Jeong and Colin Raffel and Shiyu Chang and Tatsunori Hashimoto and William Yang Wang},
202
- year={2024},
203
- eprint={2402.16827},
 
204
  archivePrefix={arXiv},
205
- primaryClass={cs.CL}
 
206
  }
207
- @misc{longpre2023pretrainers,
208
- title={A Pretrainer's Guide to Training Data: Measuring the Effects of Data Age, Domain Coverage, Quality, & Toxicity},
209
- author={Shayne Longpre and Gregory Yauney and Emily Reif and Katherine Lee and Adam Roberts and Barret Zoph and Denny Zhou and Jason Wei and Kevin Robinson and David Mimno and Daphne Ippolito},
210
- year={2023},
211
- eprint={2305.13169},
 
212
  archivePrefix={arXiv},
213
- primaryClass={cs.CL}
 
214
  }
215
- @misc{wenzek2019ccnet,
216
- title={CCNet: Extracting High Quality Monolingual Datasets from Web Crawl Data},
217
- author={Guillaume Wenzek and Marie-Anne Lachaux and Alexis Conneau and Vishrav Chaudhary and Francisco Guzmán and Armand Joulin and Edouard Grave},
218
- year={2019},
219
- eprint={1911.00359},
 
220
  archivePrefix={arXiv},
221
- primaryClass={cs.CL}
 
222
  }
223
- @misc{soldaini2024dolma,
224
- title={Dolma: an Open Corpus of Three Trillion Tokens for Language Model Pretraining Research},
225
- author={Luca Soldaini and Rodney Kinney and Akshita Bhagia and Dustin Schwenk and David Atkinson and Russell Authur and Ben Bogin and Khyathi Chandu and Jennifer Dumas and Yanai Elazar and Valentin Hofmann and Ananya Harsh Jha and Sachin Kumar and Li Lucy and Xinxi Lyu and Nathan Lambert and Ian Magnusson and Jacob Morrison and Niklas Muennighoff and Aakanksha Naik and Crystal Nam and Matthew E. Peters and Abhilasha Ravichander and Kyle Richardson and Zejiang Shen and Emma Strubell and Nishant Subramani and Oyvind Tafjord and Pete Walsh and Luke Zettlemoyer and Noah A. Smith and Hannaneh Hajishirzi and Iz Beltagy and Dirk Groeneveld and Jesse Dodge and Kyle Lo},
 
226
  year={2024},
227
- eprint={2402.00159},
228
- archivePrefix={arXiv},
229
- primaryClass={cs.CL}
230
- }
231
- @misc{ouyang2022training,
232
- title={Training language models to follow instructions with human feedback},
233
- author={Long Ouyang and Jeff Wu and Xu Jiang and Diogo Almeida and Carroll L. Wainwright and Pamela Mishkin and Chong Zhang and Sandhini Agarwal and Katarina Slama and Alex Ray and John Schulman and Jacob Hilton and Fraser Kelton and Luke Miller and Maddie Simens and Amanda Askell and Peter Welinder and Paul Christiano and Jan Leike and Ryan Lowe},
234
- year={2022},
235
- eprint={2203.02155},
236
  archivePrefix={arXiv},
237
- primaryClass={cs.CL}
 
238
  }
239
- @misc{hoffmann2022training,
240
- title={Training Compute-Optimal Large Language Models},
241
- author={Jordan Hoffmann and Sebastian Borgeaud and Arthur Mensch and Elena Buchatskaya and Trevor Cai and Eliza Rutherford and Diego de Las Casas and Lisa Anne Hendricks and Johannes Welbl and Aidan Clark and Tom Hennigan and Eric Noland and Katie Millican and George van den Driessche and Bogdan Damoc and Aurelia Guy and Simon Osindero and Karen Simonyan and Erich Elsen and Jack W. Rae and Oriol Vinyals and Laurent Sifre},
242
- year={2022},
243
- eprint={2203.15556},
 
244
  archivePrefix={arXiv},
245
- primaryClass={cs.CL}
 
246
  }
247
- @misc{muennighoff2023scaling,
248
- title={Scaling Data-Constrained Language Models},
249
- author={Niklas Muennighoff and Alexander M. Rush and Boaz Barak and Teven Le Scao and Aleksandra Piktus and Nouamane Tazi and Sampo Pyysalo and Thomas Wolf and Colin Raffel},
 
250
  year={2023},
251
- eprint={2305.16264},
252
- archivePrefix={arXiv},
253
- primaryClass={cs.CL}
254
- }
255
- @misc{hernandez2022scaling,
256
- title={Scaling Laws and Interpretability of Learning from Repeated Data},
257
- author={Danny Hernandez and Tom Brown and Tom Conerly and Nova DasSarma and Dawn Drain and Sheer El-Showk and Nelson Elhage and Zac Hatfield-Dodds and Tom Henighan and Tristan Hume and Scott Johnston and Ben Mann and Chris Olah and Catherine Olsson and Dario Amodei and Nicholas Joseph and Jared Kaplan and Sam McCandlish},
258
- year={2022},
259
- eprint={2205.10487},
260
  archivePrefix={arXiv},
261
- primaryClass={cs.LG}
 
262
  }
263
- @article{llama3modelcard,
264
-
265
- title={Llama 3 Model Card},
266
-
267
- author={AI@Meta},
268
-
269
- year={2024},
270
-
271
- url = {https://github.com/meta-llama/llama3/blob/main/MODEL_CARD.md}
272
 
273
- }
274
- @misc{jiang2024mixtral,
275
- title={Mixtral of Experts},
276
- author={Albert Q. Jiang and Alexandre Sablayrolles and Antoine Roux and Arthur Mensch and Blanche Savary and Chris Bamford and Devendra Singh Chaplot and Diego de las Casas and Emma Bou Hanna and Florian Bressand and Gianna Lengyel and Guillaume Bour and Guillaume Lample and Lélio Renard Lavaud and Lucile Saulnier and Marie-Anne Lachaux and Pierre Stock and Sandeep Subramanian and Sophia Yang and Szymon Antoniak and Teven Le Scao and Théophile Gervet and Thibaut Lavril and Thomas Wang and Timothée Lacroix and William El Sayed},
277
  year={2024},
278
- eprint={2401.04088},
279
- archivePrefix={arXiv},
280
- primaryClass={cs.LG}
281
- }
282
- @article{yuan2024self,
283
- title={Self-rewarding language models},
284
- author={Yuan, Weizhe and Pang, Richard Yuanzhe and Cho, Kyunghyun and Sukhbaatar, Sainbayar and Xu, Jing and Weston, Jason},
285
- journal={arXiv preprint arXiv:2401.10020},
286
- year={2024}
287
- }
288
- @article{verga2024replacing,
289
- title={Replacing Judges with Juries: Evaluating LLM Generations with a Panel of Diverse Models},
290
- author={Verga, Pat and Hofstatter, Sebastian and Althammer, Sophia and Su, Yixuan and Piktus, Aleksandra and Arkhangorodsky, Arkady and Xu, Minjie and White, Naomi and Lewis, Patrick},
291
- journal={arXiv preprint arXiv:2404.18796},
292
- year={2024}
293
- }
294
- @article{abdin2024phi,
295
- title={Phi-3 technical report: A highly capable language model locally on your phone},
296
- author={Abdin, Marah and Jacobs, Sam Ade and Awan, Ammar Ahmad and Aneja, Jyoti and Awadallah, Ahmed and Awadalla, Hany and Bach, Nguyen and Bahree, Amit and Bakhtiari, Arash and Behl, Harkirat and others},
297
- journal={arXiv preprint arXiv:2404.14219},
298
- year={2024}
299
- }
300
- @misc{meta2024responsible,
301
- title = {Our responsible approach to Meta AI and Meta Llama 3},
302
- author = {Meta},
303
- year = {2024},
304
- url = {https://ai.meta.com/blog/meta-llama-3-meta-ai-responsibility/},
305
- note = {Accessed: 2024-05-31}
306
- }
307
- @inproceedings{talmor-etal-2019-commonsenseqa,
308
- title = "CommonsenseQA: A Question Answering Challenge Targeting Commonsense Knowledge",
309
- author = "Talmor, Alon and
310
- Herzig, Jonathan and
311
- Lourie, Nicholas and
312
- Berant, Jonathan",
313
- booktitle = "Proceedings of the 2019 Conference of the North {A}merican Chapter of the Association for Computational Linguistics: Human Language Technologies, Volume 1 (Long and Short Papers)",
314
- month = jun,
315
- year = "2019",
316
- address = "Minneapolis, Minnesota",
317
- publisher = "Association for Computational Linguistics",
318
- url = "https://aclanthology.org/N19-1421",
319
- doi = "10.18653/v1/N19-1421",
320
- pages = "4149--4158",
321
- archivePrefix = "arXiv",
322
- eprint = "1811.00937",
323
- primaryClass = "cs",
324
- }
325
- @inproceedings{zellers-etal-2019-hellaswag,
326
- title = "HellaSwag: Can a Machine Really Finish Your Sentence?",
327
- author = "Zellers, Rowan and
328
- Holtzman, Ari and
329
- Bisk, Yonatan and
330
- Farhadi, Ali and
331
- Choi, Yejin",
332
- editor = "Korhonen, Anna and
333
- Traum, David and
334
- M{\`a}rquez, Llu{\'\i}s",
335
- booktitle = "Proceedings of the 57th Annual Meeting of the Association for Computational Linguistics",
336
- month = jul,
337
- year = "2019",
338
- address = "Florence, Italy",
339
- publisher = "Association for Computational Linguistics",
340
- url = "https://aclanthology.org/P19-1472",
341
- doi = "10.18653/v1/P19-1472",
342
- pages = "4791--4800",
343
- abstract = "Recent work by Zellers et al. (2018) introduced a new task of commonsense natural language inference: given an event description such as {``}A woman sits at a piano,{''} a machine must select the most likely followup: {``}She sets her fingers on the keys.{''} With the introduction of BERT, near human-level performance was reached. Does this mean that machines can perform human level commonsense inference? In this paper, we show that commonsense inference still proves difficult for even state-of-the-art models, by presenting HellaSwag, a new challenge dataset. Though its questions are trivial for humans ({\textgreater}95{\%} accuracy), state-of-the-art models struggle ({\textless}48{\%}). We achieve this via Adversarial Filtering (AF), a data collection paradigm wherein a series of discriminators iteratively select an adversarial set of machine-generated wrong answers. AF proves to be surprisingly robust. The key insight is to scale up the length and complexity of the dataset examples towards a critical {`}Goldilocks{'} zone wherein generated text is ridiculous to humans, yet often misclassified by state-of-the-art models. Our construction of HellaSwag, and its resulting difficulty, sheds light on the inner workings of deep pretrained models. More broadly, it suggests a new path forward for NLP research, in which benchmarks co-evolve with the evolving state-of-the-art in an adversarial way, so as to present ever-harder challenges.",
344
- }
345
- @inproceedings{OpenBookQA2018,
346
- title={Can a Suit of Armor Conduct Electricity? A New Dataset for Open Book Question Answering},
347
- author={Todor Mihaylov and Peter Clark and Tushar Khot and Ashish Sabharwal},
348
- booktitle={EMNLP},
349
- year={2018}
350
- }
351
- @misc{bisk2019piqa,
352
- title={PIQA: Reasoning about Physical Commonsense in Natural Language},
353
- author={Yonatan Bisk and Rowan Zellers and Ronan Le Bras and Jianfeng Gao and Yejin Choi},
354
- year={2019},
355
- eprint={1911.11641},
356
- archivePrefix={arXiv},
357
- primaryClass={cs.CL}
358
- }
359
- @misc{sap2019socialiqa,
360
- title={SocialIQA: Commonsense Reasoning about Social Interactions},
361
- author={Maarten Sap and Hannah Rashkin and Derek Chen and Ronan LeBras and Yejin Choi},
362
- year={2019},
363
- eprint={1904.09728},
364
  archivePrefix={arXiv},
365
- primaryClass={cs.CL}
366
- }
367
- @misc{sakaguchi2019winogrande,
368
- title={WinoGrande: An Adversarial Winograd Schema Challenge at Scale},
369
- author={Keisuke Sakaguchi and Ronan Le Bras and Chandra Bhagavatula and Yejin Choi},
370
- year={2019},
371
- eprint={1907.10641},
372
- archivePrefix={arXiv},
373
- primaryClass={cs.CL}
374
- }
375
- @misc{clark2018think,
376
- title={Think you have Solved Question Answering? Try ARC, the AI2 Reasoning Challenge},
377
- author={Peter Clark and Isaac Cowhey and Oren Etzioni and Tushar Khot and Ashish Sabharwal and Carissa Schoenick and Oyvind Tafjord},
378
- year={2018},
379
- eprint={1803.05457},
380
- archivePrefix={arXiv},
381
- primaryClass={cs.AI}
382
- }
383
- @misc{hendrycks2021measuring,
384
- title={Measuring Massive Multitask Language Understanding},
385
- author={Dan Hendrycks and Collin Burns and Steven Basart and Andy Zou and Mantas Mazeika and Dawn Song and Jacob Steinhardt},
386
- year={2021},
387
- eprint={2009.03300},
388
- archivePrefix={arXiv},
389
- primaryClass={cs.CY}
390
- }
391
- @misc{mitchell2023measuring,
392
- title={Measuring Data},
393
- author={Margaret Mitchell and Alexandra Sasha Luccioni and Nathan Lambert and Marissa Gerchick and Angelina McMillan-Major and Ezinwanne Ozoani and Nazneen Rajani and Tristan Thrush and Yacine Jernite and Douwe Kiela},
394
- year={2023},
395
- eprint={2212.05129},
396
- archivePrefix={arXiv},
397
- primaryClass={cs.AI}
398
  }
 
1
+ @misc{gdm,
2
+ title={Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters},
3
+ author={Charlie Snell and Jaehoon Lee and Kelvin Xu and Aviral Kumar},
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
4
  year={2024},
5
+ eprint={2408.03314},
6
  archivePrefix={arXiv},
7
  primaryClass={cs.LG},
8
+ url={https://arxiv.org/abs/2408.03314},
 
 
 
 
 
 
 
9
  }
10
+
11
+ @misc{prm,
12
+ title={Solving math word problems with process- and outcome-based feedback},
13
+ author={Jonathan Uesato and Nate Kushman and Ramana Kumar and Francis Song and Noah Siegel and Lisa Wang and Antonia Creswell and Geoffrey Irving and Irina Higgins},
14
+ year={2022},
15
+ eprint={2211.14275},
 
 
 
 
 
 
 
 
16
  archivePrefix={arXiv},
17
  primaryClass={cs.LG},
18
+ url={https://arxiv.org/abs/2211.14275},
19
  }
20
+
21
+ @misc{lightman2023letsverifystepstep,
22
+ title={Let's Verify Step by Step},
23
+ author={Hunter Lightman and Vineet Kosaraju and Yura Burda and Harri Edwards and Bowen Baker and Teddy Lee and Jan Leike and John Schulman and Ilya Sutskever and Karl Cobbe},
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
24
  year={2023},
25
+ eprint={2305.20050},
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
26
  archivePrefix={arXiv},
27
+ primaryClass={cs.LG},
28
+ url={https://arxiv.org/abs/2305.20050},
 
 
 
 
 
 
 
29
  }
30
+
31
+ @misc{dbs,
32
+ title={Diverse Beam Search: Decoding Diverse Solutions from Neural Sequence Models},
33
+ author={Ashwin K Vijayakumar and Michael Cogswell and Ramprasath R. Selvaraju and Qing Sun and Stefan Lee and David Crandall and Dhruv Batra},
34
+ year={2018},
35
+ eprint={1610.02424},
36
  archivePrefix={arXiv},
37
+ primaryClass={cs.AI},
38
+ url={https://arxiv.org/abs/1610.02424},
39
  }
40
+
41
+ @misc{repairtrees,
42
+ title={Is Self-Repair a Silver Bullet for Code Generation?},
43
+ author={Theo X. Olausson and Jeevana Priya Inala and Chenglong Wang and Jianfeng Gao and Armando Solar-Lezama},
44
+ year={2024},
45
+ eprint={2306.09896},
46
  archivePrefix={arXiv},
47
+ primaryClass={cs.CL},
48
+ url={https://arxiv.org/abs/2306.09896},
49
  }
50
+
51
+ @misc{math,
52
+ title={Measuring Mathematical Problem Solving With the MATH Dataset},
53
+ author={Dan Hendrycks and Collin Burns and Saurav Kadavath and Akul Arora and Steven Basart and Eric Tang and Dawn Song and Jacob Steinhardt},
54
+ year={2021},
55
+ eprint={2103.03874},
56
  archivePrefix={arXiv},
57
+ primaryClass={cs.LG},
58
+ url={https://arxiv.org/abs/2103.03874},
59
  }
60
+
61
+ @misc{cot,
62
+ title={Self-Consistency Improves Chain of Thought Reasoning in Language Models},
63
+ author={Xuezhi Wang and Jason Wei and Dale Schuurmans and Quoc Le and Ed Chi and Sharan Narang and Aakanksha Chowdhery and Denny Zhou},
64
  year={2023},
65
+ eprint={2203.11171},
66
  archivePrefix={arXiv},
67
+ primaryClass={cs.CL},
68
+ url={https://arxiv.org/abs/2203.11171},
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
69
  }
70
+
71
+ @misc{minerva,
72
+ title={Solving Quantitative Reasoning Problems with Language Models},
73
+ author={Aitor Lewkowycz and Anders Andreassen and David Dohan and Ethan Dyer and Henryk Michalewski and Vinay Ramasesh and Ambrose Slone and Cem Anil and Imanol Schlag and Theo Gutman-Solo and Yuhuai Wu and Behnam Neyshabur and Guy Gur-Ari and Vedant Misra},
74
+ year={2022},
75
+ eprint={2206.14858},
76
  archivePrefix={arXiv},
77
+ primaryClass={cs.CL},
78
+ url={https://arxiv.org/abs/2206.14858},
79
  }
80
+
81
+ @misc{scalinglaws,
82
+ title={Scaling Laws for Neural Language Models},
83
+ author={Jared Kaplan and Sam McCandlish and Tom Henighan and Tom B. Brown and Benjamin Chess and Rewon Child and Scott Gray and Alec Radford and Jeffrey Wu and Dario Amodei},
84
+ year={2020},
85
+ eprint={2001.08361},
86
  archivePrefix={arXiv},
87
+ primaryClass={cs.LG},
88
+ url={https://arxiv.org/abs/2001.08361},
89
  }
90
+
91
+ @misc{codex,
92
+ title={Evaluating Large Language Models Trained on Code},
93
+ author={Mark Chen and Jerry Tworek and Heewoo Jun and Qiming Yuan and Henrique Ponde de Oliveira Pinto and Jared Kaplan and Harri Edwards and Yuri Burda and Nicholas Joseph and Greg Brockman and Alex Ray and Raul Puri and Gretchen Krueger and Michael Petrov and Heidy Khlaaf and Girish Sastry and Pamela Mishkin and Brooke Chan and Scott Gray and Nick Ryder and Mikhail Pavlov and Alethea Power and Lukasz Kaiser and Mohammad Bavarian and Clemens Winter and Philippe Tillet and Felipe Petroski Such and Dave Cummings and Matthias Plappert and Fotios Chantzis and Elizabeth Barnes and Ariel Herbert-Voss and William Hebgen Guss and Alex Nichol and Alex Paino and Nikolas Tezak and Jie Tang and Igor Babuschkin and Suchir Balaji and Shantanu Jain and William Saunders and Christopher Hesse and Andrew N. Carr and Jan Leike and Josh Achiam and Vedant Misra and Evan Morikawa and Alec Radford and Matthew Knight and Miles Brundage and Mira Murati and Katie Mayer and Peter Welinder and Bob McGrew and Dario Amodei and Sam McCandlish and Ilya Sutskever and Wojciech Zaremba},
94
+ year={2021},
95
+ eprint={2107.03374},
96
  archivePrefix={arXiv},
97
+ primaryClass={cs.LG},
98
+ url={https://arxiv.org/abs/2107.03374},
99
  }
100
+
101
+ @misc{processbench,
102
+ title={ProcessBench: Identifying Process Errors in Mathematical Reasoning},
103
+ author={Chujie Zheng and Zhenru Zhang and Beichen Zhang and Runji Lin and Keming Lu and Bowen Yu and Dayiheng Liu and Jingren Zhou and Junyang Lin},
104
  year={2024},
105
+ eprint={2412.06559},
 
 
 
 
 
 
 
 
106
  archivePrefix={arXiv},
107
+ primaryClass={cs.AI},
108
+ url={https://arxiv.org/abs/2412.06559},
109
  }
110
+
111
+ @misc{score,
112
+ title={Training Language Models to Self-Correct via Reinforcement Learning},
113
+ author={Aviral Kumar and Vincent Zhuang and Rishabh Agarwal and Yi Su and John D Co-Reyes and Avi Singh and Kate Baumli and Shariq Iqbal and Colton Bishop and Rebecca Roelofs and Lei M Zhang and Kay McKinney and Disha Shrivastava and Cosmin Paduraru and George Tucker and Doina Precup and Feryal Behbahani and Aleksandra Faust},
114
+ year={2024},
115
+ eprint={2409.12917},
116
  archivePrefix={arXiv},
117
+ primaryClass={cs.LG},
118
+ url={https://arxiv.org/abs/2409.12917},
119
  }
120
+
121
+ @misc{rest,
122
+ title={Reinforced Self-Training (ReST) for Language Modeling},
123
+ author={Caglar Gulcehre and Tom Le Paine and Srivatsan Srinivasan and Ksenia Konyushkova and Lotte Weerts and Abhishek Sharma and Aditya Siddhant and Alex Ahern and Miaosen Wang and Chenjie Gu and Wolfgang Macherey and Arnaud Doucet and Orhan Firat and Nando de Freitas},
124
  year={2023},
125
+ eprint={2308.08998},
 
 
 
 
 
 
 
 
126
  archivePrefix={arXiv},
127
+ primaryClass={cs.CL},
128
+ url={https://arxiv.org/abs/2308.08998},
129
  }
 
 
 
 
 
 
 
 
 
130
 
131
+ @misc{vstar,
132
+ title={V-STaR: Training Verifiers for Self-Taught Reasoners},
133
+ author={Arian Hosseini and Xingdi Yuan and Nikolay Malkin and Aaron Courville and Alessandro Sordoni and Rishabh Agarwal},
 
134
  year={2024},
135
+ eprint={2402.06457},
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
136
  archivePrefix={arXiv},
137
+ primaryClass={cs.LG},
138
+ url={https://arxiv.org/abs/2402.06457},
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
139
  }
app/src/index.html CHANGED
@@ -61,11 +61,11 @@
61
  </d-contents>
62
 
63
  <!-- INTRODUCTION -->
64
- <p>Over the last few years, the scaling of <em><strong>train-time compute</strong></em> has dominated the progress of large language models (LLMs).<d-footnote>Here, train-time compute refers to increasing model size, dataset size, and compute budgets in line with <a href="https://huggingface.co/papers/2001.08361">scaling laws</a>.</d-footnote>Although this paradigm has proven to be remarkably effective, the resources needed to pretrain ever larger models are becoming prohibitively expensive, with <a href="https://youtu.be/WXhikNA5PIc?feature=shared">billion-dollar clusters</a> already on the horizon.<d-footnote>Aside from compute resources, Ilya Sutskever has made the <a href="https://www.youtube.com/watch?feature=shared&t=475&v=1yvBqasHLZs">provocative analogy</a> that pretraining data is the “fossil fuel of AI” and that pretraining as we know it will end once this resource is exhausted in the near future.</d-footnote> This trend has sparked significant interest in a complementary approach: <em><strong>test-time compute scaling</strong></em>. Rather than relying on ever-larger pretraining budgets, test-time methods use dynamic inference strategies that allow models to “think longer” on harder problems. A prominent example is <a href="https://openai.com/index/learning-to-reason-with-llms/">OpenAI’s o1 model</a>, which shows consistent improvement on difficult math problems as one increases the amount of test-time compute:</p>
65
 
66
  <figure id="1581384e-bcac-805f-8c2b-dff4509f45cb" class="image"><a href="https://huggingface.co/datasets/HuggingFaceH4/blogpost-images/resolve/main/compute.png.webp"><img style="width:672px" src="https://huggingface.co/datasets/HuggingFaceH4/blogpost-images/resolve/main/compute.png.webp"/></a></figure>
67
 
68
- <p id="1591384e-bcac-80ce-a40c-cf00e5a73720" class="">Although we don’t know how o1 was trained, <a href="https://huggingface.co/papers/2408.03314">recent research from DeepMind</a> shows that <em><strong>test-time compute can be scaled</strong></em> <em><strong>optimally</strong></em> through strategies like iterative self-refinement or using a reward model to perform search over the space of solutions. By adaptively allocating test-time compute per prompt, smaller models can rival—and sometimes even outperform—their larger, more resource-intensive counterparts. Scaling test-time compute is especially advantageous when memory is constrained and the available hardware is not sufficient to run a larger model. However, this promising approach was demonstrated with closed-source models, and no implementation details or code were released 😢.</p>
69
 
70
  <p id="1591384e-bcac-80c1-82a7-cc9a41f9fdc4" class="">Over the past months we’ve been diving deep in trying to reverse engineer and reproduce several of these results and are finally happy to share some of our knowledge. More precisely, in this blog post we’ll cover:</p>
71
 
@@ -94,12 +94,12 @@
94
  <p id="1591384e-bcac-801d-82e3-d2dc50cf2b24" class="">In this blog post, we’ll concentrate on search-based methods as they represent a practical and scalable solution for test-time compute optimization. In particular, we’ll examine the three strategies illustrated below:</p>
95
 
96
  <figure id="15b1384e-bcac-80df-a57e-e08ddb80ec8c" class="image"><a href="https://huggingface.co/datasets/HuggingFaceH4/blogpost-images/resolve/main/search-strategies.png"><img style="width:900px" src="https://huggingface.co/datasets/HuggingFaceH4/blogpost-images/resolve/main/search-strategies.png"/></a>
97
- <figcaption>Illustration of various search strategies used in test-time compute scaling. Figure adapted from the <a href="https://huggingface.co/papers/2408.03314">DeepMind paper.</a></figcaption>
98
  </figure>
99
 
100
  <ul>
101
  <li><strong>Best-of-N: </strong>Generate multiple responses per problem and assign scores to each candidate answer, typically using a reward model. Then select the answer with the highest reward (or a weighted variant discussed later). This approach emphasizes answer quality over frequency.</li>
102
- <li><strong>Beam search: </strong>A systematic search method that explores the solution space, often combined with a <em><a href="https://huggingface.co/papers/2211.14275">process reward model (PRM)</a></em> to optimise both the sampling and evaluation of intermediate steps in problem-solving. Unlike conventional reward models that produce a single score on the final answer, PRMs provide a <em>sequence </em>of scores, one for each step of the reasoning process. This ability to provide fine-grained feedback makes PRMs a natural fit for search methods with LLMs.</li>
103
  <li><strong>Diverse verifier tree search (DVTS):</strong> An extension of beam search we developed that splits the initial beams into independent subtrees, which are then expanded greedily using a PRM.<d-footnote>DVTS is similar to <a href="https://huggingface.co/papers/1610.02424">diverse beam search (DBS)</a> with the main difference that beams share a common prefix in DBS and no sampling is used. DVTS is also similar to <a href="https://huggingface.co/papers/2306.09896">code repair trees</a>, although it is not restricted to code generation models and discrete verifiers.</d-footnote> This method improves solution diversity and overall performance, particularly with larger test-time compute budgets.</li>
104
  </ul>
105
 
@@ -122,7 +122,7 @@
122
  <ul>
123
  <li><strong>Model:</strong> We used <code>meta-llama/Llama-3.2-1B-Instruct</code> as our primary model for scaling test-time compute. With 1B parameters, its lightweight nature enables fast iterations, and its unsaturated performance on math benchmarks makes it an ideal choice for highlighting the benefits of scaling.</li>
124
  <li><strong>Process reward model: </strong>To guide our search strategies, we used <code>RLHFlow/Llama3.1-8B-PRM-Deepseek-Data</code>, an 8B reward model that has been trained using <em>process supervision</em>. Process supervision is a training approach where models receive feedback on each step of their reasoning process, not just the final outcome. We picked this model since it belongs to the same model family as our policy and gave better results than other PRMs like <a href="https://huggingface.co/peiyi9979/math-shepherd-mistral-7b-prm">Math-Shepherd</a> we tested in this weight class.</li>
125
- <li><strong>Dataset: </strong>We evaluated on the<a href="https://huggingface.co/datasets/HuggingFaceH4/MATH-500"> MATH-500 subset</a> of the <a href="https://huggingface.co/papers/2103.03874">MATH benchmark</a>, a dataset released by OpenAI as part of their <a href="https://huggingface.co/papers/2305.20050">research</a> on process supervision. These math problems span seven subjects and are challenging for both humans and most LLMs. Take a look at the dataset viewer below to get a taste for the problem difficulty!</li>
126
  </ul>
127
 
128
  <iframe src="https://huggingface.co/datasets/HuggingFaceH4/MATH-500/embed/viewer/default/test" frameborder="0" width="100%" height="560px"></iframe>
@@ -136,7 +136,7 @@
136
  <!-- SECTION 2 -->
137
  <h2 id="1591384e-bcac-801a-9201-cd4f3b8dfe96" class="">Majority voting: a simple baseline</h2>
138
 
139
- <p>Majority voting—or <a href="https://huggingface.co/papers/2203.11171">self-consistency decoding</a> if you want to be fancy—is the most straightforward method to aggregate an LLM’s outputs.<d-footnote>It’s also the most common sampling method used in the literature and is usually referred to as “maj@X” in tables and results.</d-footnote> As the name suggests, for a given math problem we generate \(N\) candidate solutions and pick the most frequent answer. For all our experiments we sampled up to \(N=256\) candidates with temperature \(T=0.8\) and generated up to 2048 tokens per problem.<d-footnote>We found that sampling with \(T=1.0\) would cause the model to generate Chinese characters midway through a solution and hurt performance.</d-footnote></p>
140
 
141
  <p id="15c1384e-bcac-8086-a0e7-e0ca93b5ea94" class="">One quirk with the MATH benchmark is that answers must be formatted in a LaTeX box like <code>\boxed{answer}</code> . We initially tried the following simple system prompt for Llama 3.2 1B</p>
142
 
@@ -168,7 +168,7 @@
168
 
169
  Where [answer] is just the final number or expression that solves the problem.</code></pre>
170
 
171
- <p id="15c1384e-bcac-8076-9664-caa1b098c89c" class="">One subtlety with evaluating answers to math problems is that strings like \(1/\sqrt{3}\) and \(\sqrt{3}/3\) are distinct, but represent mathematically equivalent answers. The standard <a href="https://huggingface.co/papers/2206.14858">way</a> to handle this is to convert the a pair of answers to SymPy objects and then check whether subtracting the two objects and applying <code>sympy.simplify</code> gives zero. </p><p id="15c1384e-bcac-8043-a1d3-ffa0c5c3406e" class="">While this approach works well when comparing a small number of candidate answers, we found it was terribly slow when comparing many pairs in a list of \(N\) candidates; in some cases, slower than generating the candidates in the first place! To deal with this, we first reduced each answer to its <a href="https://en.wikipedia.org/wiki/Canonical_form">canonical form</a> and then computed the frequency of each form to determine the majority vote. Expand the detail below if you’re curious about how the code looks.</p>
172
 
173
  <details><summary style="font-weight:600;font-size:1.25em;line-height:1.3;margin:0"><strong>Implementation detail</strong></summary><div class="indented"><p id="15d1384e-bcac-8080-b676-e09848694520" class="">To obtain the canonical form of an algebraic expression, we first convert the LaTeX string to SymPy, apply <code>sympy.simplify</code>, and finally convert back to LaTeX: </p>
174
  <script src="https://cdnjs.cloudflare.com/ajax/libs/prism/1.29.0/prism.min.js" integrity="sha512-7Z9J3l1+EYfeaPKcGXu3MS/7T+w19WtKQY/n+xzmw4hZhJ9tyYmcUS+4QqAlzhicE5LAfMQSF3iFTK9bQdTxXg==" crossorigin="anonymous" referrerPolicy="no-referrer"></script><link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/prism/1.29.0/themes/prism.min.css" integrity="sha512-tN7Ec6zAFaVSG3TpNAKtk4DOHNpSwKHxxrsiw4GHKESGPs5njn/0sMCUMl2svV4wo4BK/rCP7juYz+zx+l6oeQ==" crossorigin="anonymous" referrerPolicy="no-referrer"/><pre id="15b1384e-bcac-80c0-96c2-feba0d1cc92e" class="code"><code class="language-Python">from latex2sympy2 import latex2sympy
@@ -257,7 +257,7 @@
257
  </details>
258
  <br><br>
259
 
260
- <p id="15d1384e-bcac-80e9-8e65-e1b58080b94c" class="">In our experiments, we followed <a href="https://huggingface.co/papers/2408.03314">DeepMind’s hyperparameter choices</a> and ran beam search with the following:</p>
261
 
262
  <ul>
263
  <li>\(N\) beams in compute scalings of 4, 16, 64, 256</li>
@@ -278,7 +278,7 @@
278
  </ul>
279
 
280
  <details><summary style="font-weight:600;font-size:1.25em;line-height:1.3;margin:0">Implementation detail</summary><div class="indented">
281
- <p>The pass@k metric measures the probability, computed over a set of problems, that at least one of the top \(k\) generated outputs for each problem contains the correct solution. In practice, computing pass@k naively leads to high variance; for example, if we compute pass@1 from a single completion per problem, we can get significantly different values from repeated evaluations due to sampling. To combat this, OpenAI's <a href="https://huggingface.co/papers/2107.03374">Codex paper</a> introduced an unbiased estimator that accounts for the total number of generated samples \(n\), the number of correct samples \(c\), and the desired \(k\) value. The estimator is formulated as:
282
 
283
  $$\text{pass@k} = \mathbb{E}_{\text{problems}} \left[ 1 - \frac{\binom{n - c}{k}}{\binom{n}{k}} \right]$$
284
 
@@ -352,10 +352,10 @@
352
  <h2 id="15a1384e-bcac-809c-b5e7-eb92dadaebb4" class="">Where to go from here?</h2><p id="15b1384e-bcac-8052-91d7-d6e1f6f66e09" class="">This exploration of test-time compute scaling has revealed both the potential and the challenges of leveraging search-based methods. As we look ahead, several exciting directions emerge:</p>
353
 
354
  <ol>
355
- <li><strong>The Power of Strong Verifiers:</strong> Strong verifiers play a critical role in enhancing performance. However, their current limitations are apparent, as highlighted in benchmarks like <em>ProcessBench</em>. Improving the robustness and generalization of verifiers will be crucial for advancing these methods.</li>
356
- <li><strong>The Challenge of Self-Verification:</strong> The ultimate goal—or &quot;holy grail&quot;—is achieving self-verification, where models can validate their own outputs autonomously. This approach appears to be what models like o1 are doing, but remains difficult to implement in practice. Unlike standard supervised fine-tuning (SFT), self-verification demands more nuanced strategies. The recent DeepMind paper on self-verification and <em>Score</em> sheds light on this challenge and offers a pathway for future research.</li>
357
  <li><strong>Integrating “Thoughts” into the Process:</strong> Incorporating explicit intermediate steps or “thoughts” during generation could further enhance reasoning and decision-making. By integrating structured reasoning into the search process, we may unlock better performance on complex tasks.</li>
358
- <li><strong>Search as a Data Generation Tool:</strong> This method can also serve as a powerful data generation process, creating high-quality training datasets. For example, fine-tuning models like Llama 1B on correct traces produced by search could yield significant gains. This on-policy approach resembles techniques like ReST or V-StaR but with the added benefits of search, offering a promising direction for iterative improvement.</li>
359
  <li><strong>A Call for More PRMs:</strong> Open process reward models (PRMs) are relatively rare, limiting their broader application. Developing and sharing more PRMs for different domains is a critical area where the community can contribute significantly.</li>
360
  <li><strong>Expanding Beyond Verifiable Domains:</strong> While current methods excel in domains like math and code, where solutions are inherently verifiable, extending these techniques to other areas remains a major challenge. How can we adapt these strategies for less structured or subjective tasks? This is a vital question for future exploration.</li>
361
  </ol>
 
61
  </d-contents>
62
 
63
  <!-- INTRODUCTION -->
64
+ <p>Over the last few years, the scaling of <em><strong>train-time compute</strong></em> has dominated the progress of large language models (LLMs).<d-footnote>Here, train-time compute refers to increasing model size, dataset size, and compute budgets in line with <a href="https://huggingface.co/papers/2001.08361">scaling laws.</d-footnote>Although this paradigm has proven to be remarkably effective, the resources needed to pretrain ever larger models are becoming prohibitively expensive, with <a href="https://youtu.be/WXhikNA5PIc?feature=shared">billion-dollar clusters</a> already on the horizon.<d-footnote>Aside from compute resources, Ilya Sutskever has made the <a href="https://www.youtube.com/watch?feature=shared&t=475&v=1yvBqasHLZs">provocative analogy</a> that pretraining data is the “fossil fuel of AI” and that pretraining as we know it will end once this resource is exhausted in the near future.</d-footnote> This trend has sparked significant interest in a complementary approach: <em><strong>test-time compute scaling</strong></em>. Rather than relying on ever-larger pretraining budgets, test-time methods use dynamic inference strategies that allow models to “think longer” on harder problems. A prominent example is <a href="https://openai.com/index/learning-to-reason-with-llms/">OpenAI’s o1 model</a>, which shows consistent improvement on difficult math problems as one increases the amount of test-time compute:</p>
65
 
66
  <figure id="1581384e-bcac-805f-8c2b-dff4509f45cb" class="image"><a href="https://huggingface.co/datasets/HuggingFaceH4/blogpost-images/resolve/main/compute.png.webp"><img style="width:672px" src="https://huggingface.co/datasets/HuggingFaceH4/blogpost-images/resolve/main/compute.png.webp"/></a></figure>
67
 
68
+ <p id="1591384e-bcac-80ce-a40c-cf00e5a73720" class="">Although we don’t know how o1 was trained, recent research from DeepMind<d-cite key="gdm"></d-cite> shows that <em><strong>test-time compute can be scaled</strong></em> <em><strong>optimally</strong></em> through strategies like iterative self-refinement or using a reward model to perform search over the space of solutions. By adaptively allocating test-time compute per prompt, smaller models can rival—and sometimes even outperform—their larger, more resource-intensive counterparts. Scaling test-time compute is especially advantageous when memory is constrained and the available hardware is not sufficient to run a larger model. However, this promising approach was demonstrated with closed-source models, and no implementation details or code were released 😢.</p>
69
 
70
  <p id="1591384e-bcac-80c1-82a7-cc9a41f9fdc4" class="">Over the past months we’ve been diving deep in trying to reverse engineer and reproduce several of these results and are finally happy to share some of our knowledge. More precisely, in this blog post we’ll cover:</p>
71
 
 
94
  <p id="1591384e-bcac-801d-82e3-d2dc50cf2b24" class="">In this blog post, we’ll concentrate on search-based methods as they represent a practical and scalable solution for test-time compute optimization. In particular, we’ll examine the three strategies illustrated below:</p>
95
 
96
  <figure id="15b1384e-bcac-80df-a57e-e08ddb80ec8c" class="image"><a href="https://huggingface.co/datasets/HuggingFaceH4/blogpost-images/resolve/main/search-strategies.png"><img style="width:900px" src="https://huggingface.co/datasets/HuggingFaceH4/blogpost-images/resolve/main/search-strategies.png"/></a>
97
+ <figcaption>Illustration of various search strategies used in test-time compute scaling. Figure adapted from the DeepMind paper.<d-cite key="gdm"></d-cite></figcaption>
98
  </figure>
99
 
100
  <ul>
101
  <li><strong>Best-of-N: </strong>Generate multiple responses per problem and assign scores to each candidate answer, typically using a reward model. Then select the answer with the highest reward (or a weighted variant discussed later). This approach emphasizes answer quality over frequency.</li>
102
+ <li><strong>Beam search: </strong>A systematic search method that explores the solution space, often combined with a <em>process reward model (PRM)</em><d-cite key="prm"></d-cite> to optimise both the sampling and evaluation of intermediate steps in problem-solving. Unlike conventional reward models that produce a single score on the final answer, PRMs provide a <em>sequence </em>of scores, one for each step of the reasoning process. This ability to provide fine-grained feedback makes PRMs a natural fit for search methods with LLMs.</li>
103
  <li><strong>Diverse verifier tree search (DVTS):</strong> An extension of beam search we developed that splits the initial beams into independent subtrees, which are then expanded greedily using a PRM.<d-footnote>DVTS is similar to <a href="https://huggingface.co/papers/1610.02424">diverse beam search (DBS)</a> with the main difference that beams share a common prefix in DBS and no sampling is used. DVTS is also similar to <a href="https://huggingface.co/papers/2306.09896">code repair trees</a>, although it is not restricted to code generation models and discrete verifiers.</d-footnote> This method improves solution diversity and overall performance, particularly with larger test-time compute budgets.</li>
104
  </ul>
105
 
 
122
  <ul>
123
  <li><strong>Model:</strong> We used <code>meta-llama/Llama-3.2-1B-Instruct</code> as our primary model for scaling test-time compute. With 1B parameters, its lightweight nature enables fast iterations, and its unsaturated performance on math benchmarks makes it an ideal choice for highlighting the benefits of scaling.</li>
124
  <li><strong>Process reward model: </strong>To guide our search strategies, we used <code>RLHFlow/Llama3.1-8B-PRM-Deepseek-Data</code>, an 8B reward model that has been trained using <em>process supervision</em>. Process supervision is a training approach where models receive feedback on each step of their reasoning process, not just the final outcome. We picked this model since it belongs to the same model family as our policy and gave better results than other PRMs like <a href="https://huggingface.co/peiyi9979/math-shepherd-mistral-7b-prm">Math-Shepherd</a> we tested in this weight class.</li>
125
+ <li><strong>Dataset: </strong>We evaluated on the<a href="https://huggingface.co/datasets/HuggingFaceH4/MATH-500"> MATH-500 subset</a> of the MATH benchmark,<d-cite key="math"></d-cite> a dataset released by OpenAI as part of their research<d-cite key="lightman2023letsverifystepstep"></d-cite> on process supervision. These math problems span seven subjects and are challenging for both humans and most LLMs. Take a look at the dataset viewer below to get a taste for the problem difficulty!</li>
126
  </ul>
127
 
128
  <iframe src="https://huggingface.co/datasets/HuggingFaceH4/MATH-500/embed/viewer/default/test" frameborder="0" width="100%" height="560px"></iframe>
 
136
  <!-- SECTION 2 -->
137
  <h2 id="1591384e-bcac-801a-9201-cd4f3b8dfe96" class="">Majority voting: a simple baseline</h2>
138
 
139
+ <p>Majority voting—or self-consistency decoding<d-cite key="cot"></d-cite> if you want to be fancy—is the most straightforward method to aggregate an LLM’s outputs.<d-footnote>It’s also the most common sampling method used in the literature and is usually referred to as “maj@X” in tables and results.</d-footnote> As the name suggests, for a given math problem we generate \(N\) candidate solutions and pick the most frequent answer. For all our experiments we sampled up to \(N=256\) candidates with temperature \(T=0.8\) and generated up to 2048 tokens per problem.<d-footnote>We found that sampling with \(T=1.0\) would cause the model to generate Chinese characters midway through a solution and hurt performance.</d-footnote></p>
140
 
141
  <p id="15c1384e-bcac-8086-a0e7-e0ca93b5ea94" class="">One quirk with the MATH benchmark is that answers must be formatted in a LaTeX box like <code>\boxed{answer}</code> . We initially tried the following simple system prompt for Llama 3.2 1B</p>
142
 
 
168
 
169
  Where [answer] is just the final number or expression that solves the problem.</code></pre>
170
 
171
+ <p id="15c1384e-bcac-8076-9664-caa1b098c89c" class="">One subtlety with evaluating answers to math problems is that strings like \(1/\sqrt{3}\) and \(\sqrt{3}/3\) are distinct, but represent mathematically equivalent answers. The standard way<d-cite key="minerva"></d-cite> to handle this is to convert the a pair of answers to SymPy objects and then check whether subtracting the two objects and applying <code>sympy.simplify</code> gives zero. </p><p id="15c1384e-bcac-8043-a1d3-ffa0c5c3406e" class="">While this approach works well when comparing a small number of candidate answers, we found it was terribly slow when comparing many pairs in a list of \(N\) candidates; in some cases, slower than generating the candidates in the first place! To deal with this, we first reduced each answer to its <a href="https://en.wikipedia.org/wiki/Canonical_form">canonical form</a> and then computed the frequency of each form to determine the majority vote. Expand the detail below if you’re curious about how the code looks.</p>
172
 
173
  <details><summary style="font-weight:600;font-size:1.25em;line-height:1.3;margin:0"><strong>Implementation detail</strong></summary><div class="indented"><p id="15d1384e-bcac-8080-b676-e09848694520" class="">To obtain the canonical form of an algebraic expression, we first convert the LaTeX string to SymPy, apply <code>sympy.simplify</code>, and finally convert back to LaTeX: </p>
174
  <script src="https://cdnjs.cloudflare.com/ajax/libs/prism/1.29.0/prism.min.js" integrity="sha512-7Z9J3l1+EYfeaPKcGXu3MS/7T+w19WtKQY/n+xzmw4hZhJ9tyYmcUS+4QqAlzhicE5LAfMQSF3iFTK9bQdTxXg==" crossorigin="anonymous" referrerPolicy="no-referrer"></script><link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/prism/1.29.0/themes/prism.min.css" integrity="sha512-tN7Ec6zAFaVSG3TpNAKtk4DOHNpSwKHxxrsiw4GHKESGPs5njn/0sMCUMl2svV4wo4BK/rCP7juYz+zx+l6oeQ==" crossorigin="anonymous" referrerPolicy="no-referrer"/><pre id="15b1384e-bcac-80c0-96c2-feba0d1cc92e" class="code"><code class="language-Python">from latex2sympy2 import latex2sympy
 
257
  </details>
258
  <br><br>
259
 
260
+ <p id="15d1384e-bcac-80e9-8e65-e1b58080b94c" class="">In our experiments, we followed DeepMind’s hyperparameter choices<d-cite key="gdm"></d-cite> and ran beam search with the following:</p>
261
 
262
  <ul>
263
  <li>\(N\) beams in compute scalings of 4, 16, 64, 256</li>
 
278
  </ul>
279
 
280
  <details><summary style="font-weight:600;font-size:1.25em;line-height:1.3;margin:0">Implementation detail</summary><div class="indented">
281
+ <p>The pass@k metric measures the probability, computed over a set of problems, that at least one of the top \(k\) generated outputs for each problem contains the correct solution. In practice, computing pass@k naively leads to high variance; for example, if we compute pass@1 from a single completion per problem, we can get significantly different values from repeated evaluations due to sampling. To combat this, OpenAI's Codex paper<d-cite key="codex"></d-cite> introduced an unbiased estimator that accounts for the total number of generated samples \(n\), the number of correct samples \(c\), and the desired \(k\) value. The estimator is formulated as:
282
 
283
  $$\text{pass@k} = \mathbb{E}_{\text{problems}} \left[ 1 - \frac{\binom{n - c}{k}}{\binom{n}{k}} \right]$$
284
 
 
352
  <h2 id="15a1384e-bcac-809c-b5e7-eb92dadaebb4" class="">Where to go from here?</h2><p id="15b1384e-bcac-8052-91d7-d6e1f6f66e09" class="">This exploration of test-time compute scaling has revealed both the potential and the challenges of leveraging search-based methods. As we look ahead, several exciting directions emerge:</p>
353
 
354
  <ol>
355
+ <li><strong>The Power of Strong Verifiers:</strong> Strong verifiers play a critical role in enhancing performance. However, their current limitations are apparent, as highlighted in benchmarks like ProcessBench.<d-cite key="processbench"></d-cite> Improving the robustness and generalization of verifiers will be crucial for advancing these methods.</li>
356
+ <li><strong>The Challenge of Self-Verification:</strong> The ultimate goal—or &quot;holy grail&quot;—is achieving self-verification, where models can validate their own outputs autonomously. This approach appears to be what models like o1 are doing, but remains difficult to implement in practice. Unlike standard supervised fine-tuning (SFT), self-verification demands more nuanced strategies. The recent DeepMind paper on self-verification and <em>SCoRe</em> sheds light on this challenge and offers a pathway for future research.<d-cite key="score"></d-cite></li>
357
  <li><strong>Integrating “Thoughts” into the Process:</strong> Incorporating explicit intermediate steps or “thoughts” during generation could further enhance reasoning and decision-making. By integrating structured reasoning into the search process, we may unlock better performance on complex tasks.</li>
358
+ <li><strong>Search as a Data Generation Tool:</strong> This method can also serve as a powerful data generation process, creating high-quality training datasets. For example, fine-tuning models like Llama 1B on correct traces produced by search could yield significant gains. This on-policy approach resembles techniques like ReST<d-cite key="rest"></d-cite> or V-STaR<d-cite key="vstar"></d-cite> but with the added benefits of search, offering a promising direction for iterative improvement.</li>
359
  <li><strong>A Call for More PRMs:</strong> Open process reward models (PRMs) are relatively rare, limiting their broader application. Developing and sharing more PRMs for different domains is a critical area where the community can contribute significantly.</li>
360
  <li><strong>Expanding Beyond Verifiable Domains:</strong> While current methods excel in domains like math and code, where solutions are inherently verifiable, extending these techniques to other areas remains a major challenge. How can we adapt these strategies for less structured or subjective tasks? This is a vital question for future exploration.</li>
361
  </ol>