hynky HF staff commited on
Commit
d85f05e
·
2 Parent(s): dd17a04 891aa98

Merge branch 'main' of hf.co:spaces/HuggingFaceFW/blogpost

Browse files
Files changed (2) hide show
  1. bibliography.bib +128 -107
  2. index.html +49 -53
bibliography.bib CHANGED
@@ -1,108 +1,129 @@
1
- @article{gregor2015draw,
2
- title={DRAW: A recurrent neural network for image generation},
3
- author={Gregor, Karol and Danihelka, Ivo and Graves, Alex and Rezende, Danilo Jimenez and Wierstra, Daan},
4
- journal={arXiv preprint arXiv:1502.04623},
5
- year={2015},
6
- url ={https://arxiv.org/pdf/1502.04623.pdf}
7
- }
8
- @article{mercier2011humans,
9
- title={Why do humans reason? Arguments for an argumentative theory},
10
- author={Mercier, Hugo and Sperber, Dan},
11
- journal={Behavioral and brain sciences},
12
- volume={34},
13
- number={02},
14
- pages={57--74},
15
- year={2011},
16
- publisher={Cambridge Univ Press},
17
- doi={10.1017/S0140525X10000968}
18
- }
19
-
20
- @article{dong2014image,
21
- title={Image super-resolution using deep convolutional networks},
22
- author={Dong, Chao and Loy, Chen Change and He, Kaiming and Tang, Xiaoou},
23
- journal={arXiv preprint arXiv:1501.00092},
24
- year={2014},
25
- url={https://arxiv.org/pdf/1501.00092.pdf}
26
- }
27
-
28
- @article{dumoulin2016adversarially,
29
- title={Adversarially Learned Inference},
30
- author={Dumoulin, Vincent and Belghazi, Ishmael and Poole, Ben and Lamb, Alex and Arjovsky, Martin and Mastropietro, Olivier and Courville, Aaron},
31
- journal={arXiv preprint arXiv:1606.00704},
32
- year={2016},
33
- url={https://arxiv.org/pdf/1606.00704.pdf}
34
- }
35
-
36
- @article{dumoulin2016guide,
37
- title={A guide to convolution arithmetic for deep learning},
38
- author={Dumoulin, Vincent and Visin, Francesco},
39
- journal={arXiv preprint arXiv:1603.07285},
40
- year={2016},
41
- url={https://arxiv.org/pdf/1603.07285.pdf}
42
- }
43
-
44
- @article{gauthier2014conditional,
45
- title={Conditional generative adversarial nets for convolutional face generation},
46
- author={Gauthier, Jon},
47
- journal={Class Project for Stanford CS231N: Convolutional Neural Networks for Visual Recognition, Winter semester},
48
- volume={2014},
49
- year={2014},
50
- url={http://www.foldl.me/uploads/papers/tr-cgans.pdf}
51
- }
52
-
53
- @article{johnson2016perceptual,
54
- title={Perceptual losses for real-time style transfer and super-resolution},
55
- author={Johnson, Justin and Alahi, Alexandre and Fei-Fei, Li},
56
- journal={arXiv preprint arXiv:1603.08155},
57
- year={2016},
58
- url={https://arxiv.org/pdf/1603.08155.pdf}
59
- }
60
-
61
- @article{mordvintsev2015inceptionism,
62
- title={Inceptionism: Going deeper into neural networks},
63
- author={Mordvintsev, Alexander and Olah, Christopher and Tyka, Mike},
64
- journal={Google Research Blog},
65
- year={2015},
66
- url={https://research.googleblog.com/2015/06/inceptionism-going-deeper-into-neural.html}
67
- }
68
-
69
- @misc{mordvintsev2016deepdreaming,
70
- title={DeepDreaming with TensorFlow},
71
- author={Mordvintsev, Alexander},
72
- year={2016},
73
- url={https://github.com/tensorflow/tensorflow/blob/master/tensorflow/examples/tutorials/deepdream/deepdream.ipynb},
74
- }
75
-
76
- @article{radford2015unsupervised,
77
- title={Unsupervised representation learning with deep convolutional generative adversarial networks},
78
- author={Radford, Alec and Metz, Luke and Chintala, Soumith},
79
- journal={arXiv preprint arXiv:1511.06434},
80
- year={2015},
81
- url={https://arxiv.org/pdf/1511.06434.pdf}
82
- }
83
-
84
- @inproceedings{salimans2016improved,
85
- title={Improved techniques for training gans},
86
- author={Salimans, Tim and Goodfellow, Ian and Zaremba, Wojciech and Cheung, Vicki and Radford, Alec and Chen, Xi},
87
- booktitle={Advances in Neural Information Processing Systems},
88
- pages={2226--2234},
89
- year={2016},
90
- url={https://arxiv.org/pdf/1606.03498.pdf}
91
- }
92
-
93
- @article{shi2016deconvolution,
94
- title={Is the deconvolution layer the same as a convolutional layer?},
95
- author={Shi, Wenzhe and Caballero, Jose and Theis, Lucas and Huszar, Ferenc and Aitken, Andrew and Ledig, Christian and Wang, Zehan},
96
- journal={arXiv preprint arXiv:1609.07009},
97
- year={2016},
98
- url={https://arxiv.org/pdf/1609.07009.pdf}
99
- }
100
-
101
- @misc{openai2018charter,
102
- author={OpenAI},
103
- title={OpenAI Charter},
104
- type={Blog},
105
- number={April 9},
106
- year={2018},
107
- url={https://blog.openai.com/charter},
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
108
  }
 
1
+ @inproceedings{barbaresi-2021-trafilatura,
2
+ title = {Trafilatura: A Web Scraping Library and Command-Line Tool for Text Discovery and Extraction},
3
+ author = "Barbaresi, Adrien",
4
+ 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",
5
+ pages = "122--131",
6
+ publisher = "Association for Computational Linguistics",
7
+ url = "https://aclanthology.org/2021.acl-demo.15",
8
+ year = 2021,
9
+ }
10
+ @misc{penedo2023refinedweb,
11
+ title={The RefinedWeb Dataset for Falcon LLM: Outperforming Curated Corpora with Web Data, and Web Data Only},
12
+ 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},
13
+ year={2023},
14
+ eprint={2306.01116},
15
+ archivePrefix={arXiv},
16
+ primaryClass={cs.CL}
17
+ }
18
+ @article{joulin2016fasttext,
19
+ title={FastText.zip: Compressing text classification models},
20
+ author={Joulin, Armand and Grave, Edouard and Bojanowski, Piotr and Douze, Matthijs and J{\'e}gou, H{\'e}rve and Mikolov, Tomas},
21
+ journal={arXiv preprint arXiv:1612.03651},
22
+ year={2016}
23
+ }
24
+ @article{joulin2016bag,
25
+ title={Bag of Tricks for Efficient Text Classification},
26
+ author={Joulin, Armand and Grave, Edouard and Bojanowski, Piotr and Mikolov, Tomas},
27
+ journal={arXiv preprint arXiv:1607.01759},
28
+ year={2016}
29
+ }
30
+ @misc{penedo2024datatrove,
31
+ author = {Penedo, Guilherme and Kydlíček, Hynek and Cappelli, Alessandro and Wolf, Thomas and Sasko, Mario},
32
+ title = {DataTrove: large scale data processing},
33
+ year = {2024},
34
+ publisher = {GitHub},
35
+ journal = {GitHub repository},
36
+ url = {https://github.com/huggingface/datatrove}
37
+ }
38
+ @misc{chiang2024chatbot,
39
+ title={Chatbot Arena: An Open Platform for Evaluating LLMs by Human Preference},
40
+ 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},
41
+ year={2024},
42
+ eprint={2403.04132},
43
+ archivePrefix={arXiv},
44
+ primaryClass={cs.AI}
45
+ }
46
+ @misc{rae2022scaling,
47
+ title={Scaling Language Models: Methods, Analysis & Insights from Training Gopher},
48
+ 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},
49
+ year={2022},
50
+ eprint={2112.11446},
51
+ archivePrefix={arXiv},
52
+ primaryClass={cs.CL}
53
+ }
54
+ @misc{lee2022deduplicating,
55
+ title={Deduplicating Training Data Makes Language Models Better},
56
+ author={Katherine Lee and Daphne Ippolito and Andrew Nystrom and Chiyuan Zhang and Douglas Eck and Chris Callison-Burch and Nicholas Carlini},
57
+ year={2022},
58
+ eprint={2107.06499},
59
+ archivePrefix={arXiv},
60
+ primaryClass={cs.CL}
61
+ }
62
+ @misc{carlini2023quantifying,
63
+ title={Quantifying Memorization Across Neural Language Models},
64
+ author={Nicholas Carlini and Daphne Ippolito and Matthew Jagielski and Katherine Lee and Florian Tramer and Chiyuan Zhang},
65
+ year={2023},
66
+ eprint={2202.07646},
67
+ archivePrefix={arXiv},
68
+ primaryClass={cs.LG}
69
+ }
70
+ @misc{raffel2023exploring,
71
+ title={Exploring the Limits of Transfer Learning with a Unified Text-to-Text Transformer},
72
+ 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},
73
+ year={2023},
74
+ eprint={1910.10683},
75
+ archivePrefix={arXiv},
76
+ primaryClass={cs.LG}
77
+ }
78
+ @misc{touvron2023llama,
79
+ title={LLaMA: Open and Efficient Foundation Language Models},
80
+ 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},
81
+ year={2023},
82
+ eprint={2302.13971},
83
+ archivePrefix={arXiv},
84
+ primaryClass={cs.CL}
85
+ }
86
+ @article{dolma,
87
+ title = {Dolma: an Open Corpus of Three Trillion Tokens for Language Model Pretraining Research},
88
+ author={
89
+ Luca Soldaini and Rodney Kinney and Akshita Bhagia and Dustin Schwenk and David Atkinson and
90
+ Russell Authur and Ben Bogin and Khyathi Chandu and Jennifer Dumas and Yanai Elazar and
91
+ Valentin Hofmann and Ananya Harsh Jha and Sachin Kumar and Li Lucy and Xinxi Lyu and
92
+ Nathan Lambert and Ian Magnusson and Jacob Morrison and Niklas Muennighoff and Aakanksha Naik and
93
+ Crystal Nam and Matthew E. Peters and Abhilasha Ravichander and Kyle Richardson and Zejiang Shen and
94
+ Emma Strubell and Nishant Subramani and Oyvind Tafjord and Pete Walsh and Luke Zettlemoyer and
95
+ Noah A. Smith and Hannaneh Hajishirzi and Iz Beltagy and Dirk Groeneveld and Jesse Dodge and Kyle Lo
96
+ },
97
+ year = {2024},
98
+ journal={arXiv preprint},
99
+ }
100
+ @article{gao2020pile,
101
+ title={The {P}ile: An 800{GB} dataset of diverse text for language modeling},
102
+ 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},
103
+ journal={arXiv preprint arXiv:2101.00027},
104
+ year={2020}
105
+ }
106
+ @misc{cerebras2023slimpajama,
107
+ author = {Soboleva, Daria and Al-Khateeb, Faisal and Myers, Robert and Steeves, Jacob R and Hestness, Joel and Dey, Nolan},
108
+ title = {SlimPajama: A 627B token cleaned and deduplicated version of RedPajama},
109
+ month = {June},
110
+ year = 2023,
111
+ url = {https://huggingface.co/datasets/cerebras/SlimPajama-627B},
112
+ }
113
+ @software{together2023redpajama,
114
+ author = {Together Computer},
115
+ title = {RedPajama: an Open Dataset for Training Large Language Models},
116
+ month = {October},
117
+ year = 2023,
118
+ url = {https://github.com/togethercomputer/RedPajama-Data}
119
+ }
120
+ @article{jaccard1912distribution,
121
+ title={The distribution of the flora in the alpine zone. 1},
122
+ author={Jaccard, Paul},
123
+ journal={New phytologist},
124
+ volume={11},
125
+ number={2},
126
+ pages={37--50},
127
+ year={1912},
128
+ publisher={Wiley Online Library}
129
  }
index.html CHANGED
@@ -55,7 +55,7 @@
55
  border-right-color: rgba(0, 0, 0, 0.1);
56
  position: -webkit-sticky; /* For Safari */
57
  position: sticky;
58
- top: 0; /* Adjust this value if needed */
59
  }
60
  }
61
 
@@ -150,7 +150,7 @@
150
  </script>
151
  </d-front-matter>
152
  <d-title>
153
- <figure style="grid-column: page; mix-blend-mode: multiply;">
154
  <img src="banner.png" alt="FineWeb">
155
  </figure>
156
  </d-title>
@@ -171,7 +171,7 @@
171
  recipe, why more deduplication is not always better and some interesting findings on the difference in
172
  quality of CommonCrawl dumps.</p>
173
 
174
- <h2>Preamble</h2>
175
  <h3>Sourcing the data</h3>
176
  <p>A common question we see asked regarding web datasets used
177
  to train LLMs is “where do they even get all that data?” There are generally two options:</p>
@@ -191,14 +191,14 @@
191
  every 1 or 2 months, which can be freely downloaded. </p>
192
  <p>As an example, their latest crawl (2024-10) contains 3.16
193
  billion web pages, totaling 424.7 TiB of uncompressed content (the size changes from dump to dump). There
194
- are 95 dumps since 2013 and 3 dumps from 2008 to 2012, which are in a different (older) format. </p>
195
  <h3>Processing at scale</h3>
196
  <p>Given the sheer size of the data involved, one of the main
197
  challenges we had to overcome was having a modular, scalable codebase that would allow us to quickly iterate
198
  on our processing decisions and easily try out new ideas, while appropriately parallelizing our workloads
199
  and providing clear insights into the data. </p>
200
  <p>For this purpose, we developed <a
201
- href="https://github.com/huggingface/datatrove"><code>datatrove</code></a>, an open-source data
202
  processing library that allowed us to seamlessly scale our filtering and deduplication setup to thousands of
203
  CPU cores. All the data processing steps involved in the creation of FineWeb used this <a
204
  href="https://github.com/huggingface/datatrove">library</a>.</p>
@@ -215,7 +215,7 @@
215
  choose a diverse set of tasks and try not to overfit to any one individual benchmark.</p>
216
  <p>Another way to evaluate different datasets would be to
217
  train a model on each one and have humans rate and compare the outputs of each one (like on the <a
218
- href="https://chat.lmsys.org/">LMSYS Chatbot Arena</a>). This would arguably provide the most
219
  reliable results in terms of representing real model usage, but getting ablation results this way is too
220
  expensive and slow.</p>
221
  <p>The approach we ultimately went with was to train small
@@ -250,17 +250,19 @@
250
  (should not be too noisy)
251
  </li>
252
  </ul>
253
- <p>You can find the full list of tasks and prompts we used <a
254
- href="https://huggingface.co/datasets/HuggingFaceFW/fineweb/blob/main/lighteval_tasks.py">here</a>. To
255
  have results quickly we capped longer benchmarks at 1000 samples (wall-clock evaluation taking less than 5
256
  min on a single node of 8 GPUs - done in parallel to the training).</p>
 
 
257
  <h2>The FineWeb recipe</h2>
258
  <p>In the next subsections we will explain each of the steps
259
- taken to produce the FineWeb dataset. You can find a full reproducible <code>datatrove</code> config <a
260
- href="https://github.com/huggingface/datatrove/blob/main/examples/fineweb.py">here</a>.</p>
261
  <figure class="l-body">
262
  <img src="plots/fineweb-recipe.png"/>
263
  </figure>
 
 
264
  <h3>Starting point: text extraction</h3>
265
  <p>CommonCrawl data is available in two main formats: WARC
266
  and WET. <strong>WARC </strong>(Web ARChive format) files contain the raw data from the crawl, including the
@@ -270,8 +272,7 @@
270
  starting point. In our experience the default text extraction (extracting the main text of a webpage from
271
  its HTML) used to create these WET files is suboptimal and there are a variety of open-source libraries that
272
  provide better text extraction (by, namely, keeping less boilerplate content/navigation menus). We extracted
273
- the text content from the WARC files using the <a href="https://trafilatura.readthedocs.io/en/latest/">trafilatura</a>
274
- library. It is important to note, however, that text extraction is one of the most costly steps of our
275
  processing, so we believe that using the readily available WET data could be a reasonable trade-off for
276
  lower budget teams.</p>
277
  <p>To validate this decision, we processed the 2019-18 dump
@@ -287,7 +288,7 @@
287
  removes part of the data (be it words, lines, or full documents) that would harm performance and is thus
288
  deemed to be “lower quality”.</p>
289
  <p>As a basis for our filtering we used part of the setup
290
- from <a href="https://arxiv.org/abs/2306.01116">RefinedWeb</a>. Namely, we:</p>
291
  <ul>
292
  <li>Applied URL filtering using a <a
293
  href="https://dsi.ut-capitole.fr/blacklists/">blocklist</a> to remove adult content
@@ -295,13 +296,12 @@
295
  </ul>
296
  <ul>
297
  <li>Applied a <a
298
- href="https://fasttext.cc/docs/en/language-identification.html">fastText language classifier</a> to
299
  keep only English text with a score ≥ 0.65
300
  </li>
301
  </ul>
302
  <ul>
303
- <li>Applied quality and repetition filters from the <a
304
- href="https://arxiv.org/abs/2112.11446">Gopher</a> paper (using the default thresholds)
305
  </li>
306
  </ul>
307
  <p>After applying this filtering to each of the text
@@ -315,9 +315,7 @@
315
  <p>The web has many aggregators, mirrors, templated pages or
316
  just otherwise repeated content spread over different domains and webpages. Often, these duplicated pages
317
  can be introduced by the crawler itself, when different links point to the same page. </p>
318
- <p>Removing these duplicates (deduplicating) has been <a
319
- href="https://arxiv.org/abs/2107.06499">linked to an improvement in model performance</a> and a <a
320
- href="https://arxiv.org/abs/2202.07646">reduction in memorization of pretraining data</a>, which might
321
  allow for better generalization. Additionally, the performance uplift can also be tied to increased training
322
  efficiency: by removing duplicated content, for the same number of training tokens, a model will have seen
323
  more diverse data.</p>
@@ -326,14 +324,14 @@
326
  efficient data structures to index the data (like suffix arrays). Methods can also be “fuzzy”, by using some
327
  similarity metric to mark documents as duplicates, or “exact” by checking for exact matches between two
328
  documents (or lines, paragraphs, or whatever other granularity level being used).</p>
329
- <h3>Our deduplication parameters</h3>
330
  <p>Similarly to RefinedWeb, we decided to apply MinHash, a
331
  fuzzy hash based deduplication technique. We chose to compute minhashes on each document’s 5-grams, using
332
  112 hash functions in total, split into 14 buckets of 8 hashes each — targeting documents that are at least
333
  75% similar. Documents with the same 8 minhashes in any bucket are considered a duplicate of each other.</p>
334
  <p>This would mean that for two documents with a similarity (<code>s</code>)
335
  of 0.7, 0.75, 0.8 and 0.85, the probability that they would be identified as duplicates would be 56%, 77%,
336
- 92% and 98.8% respectively (<code>1-(1-s^8)^14</code>). See the plot below for a match probability
337
  comparison between our setup with 112 hashes and the one from RefinedWeb, with 9000 hashes, divided into 450
338
  buckets of 20 hashes (that requires a substantially larger amount of compute resources):</p>
339
  <figure><img src="plots/minhash_parameters_comparison.png"/>
@@ -341,7 +339,7 @@
341
  <p>While the high number of hash functions in RefinedWeb
342
  allows for a steeper, more well defined cut off, we believe the compute and storage savings are a reasonable
343
  trade off.</p>
344
- <h3>More deduplication is always better, right?</h3>
345
  <p>Our initial approach was to take the entire dataset (all
346
  95 dumps) and deduplicate them as one big dataset using MinHash.</p>
347
  <p>We did this in an iterative manner: starting with the most
@@ -385,7 +383,7 @@
385
  <p>These results show that, for this older dump where we were
386
  removing over 90% of the original data, the data that was kept was actually <em>worse</em> than the data
387
  removed (considered independently of all the other dumps).</p>
388
- <h3>Taking a step back: individual dump dedup</h3>
389
  <p>We then tried an alternative approach: we deduplicated
390
  each dump with MinHash individually (without considering the other dumps). This resulted in 20 trillion
391
  tokens of data.</p>
@@ -482,8 +480,7 @@
482
  <figure><img src="plots/Untitled.png"/></figure>
483
  <h3>Additional filtering</h3>
484
  <p>By this point we had reached the same performance as
485
- RefinedWeb, but on our aggregate of tasks, another heavily filtered dataset, <a
486
- href="https://arxiv.org/abs/1910.10683">the C4 dataset</a>, still showed stronger performance (with
487
  the caveat that it is a relatively small dataset for current web-scale standards).</p>
488
  <p>We therefore set out to find new filtering steps that
489
  would, at first, allow us to match the performance of C4 and eventually surpass it. A natural starting point
@@ -496,8 +493,8 @@
496
  <p>Despite its age and limited size (around 175B gpt2
497
  tokens), models trained on this dataset have strong performance, excelling in particular on the Hellaswag
498
  benchmark, one of the benchmarks in our “early signal” group with the stronger signal and highest
499
- signal-over-noise ratio. As such, it has stayed a common sub-set of typical LLM training, for instance in in
500
- <a href="https://arxiv.org/abs/2302.13971">the relatively recent Llama1 model</a>. We experimented applying
501
  each of the different filters used in C4 to a baseline of the independently deduped FineWeb 2019-18 dump
502
  (plot smoothed with a 3 checkpoints sliding window):</p>
503
  <figure><img src="plots/c4_filters.png"/></figure>
@@ -596,28 +593,28 @@
596
  <p>We compared 🍷 FineWeb with the following datasets:</p>
597
  <ul>
598
  <li><a
599
- href="https://huggingface.co/datasets/tiiuae/falcon-refinedweb">RefinedWeb</a>
600
  </li>
601
  </ul>
602
  <ul>
603
- <li><a href="https://huggingface.co/datasets/allenai/c4">C4</a></li>
604
  </ul>
605
  <ul>
606
  <li><a href="https://huggingface.co/datasets/allenai/dolma">Dolma v1.6</a> (the
607
- CommonCrawl part)
608
  </li>
609
  </ul>
610
  <ul>
611
- <li><a href="https://huggingface.co/datasets/EleutherAI/pile">The Pile</a></li>
612
  </ul>
613
  <ul>
614
  <li><a
615
- href="https://huggingface.co/datasets/cerebras/SlimPajama-627B">SlimPajama</a>
616
  </li>
617
  </ul>
618
  <ul>
619
  <li><a
620
- href="https://huggingface.co/datasets/togethercomputer/RedPajama-Data-V2">RedPajama2</a>
621
  (deduplicated)
622
  </li>
623
  </ul>
@@ -677,7 +674,7 @@
677
  <h3>Changes in the most frequent URLs [HAVE TO RECHECK]</h3>
678
  <p>For each crawl from 2021-10 onwards, we gathered a list of
679
  the 60k most frequent <strong>FQDNs</strong> (fully qualified domain name). We then calculated the <a
680
- href="https://en.wikipedia.org/wiki/Jaccard_index">Jaccard similarity</a> between consecutive
681
  crawls. A high value means that a crawl/dump has many of the same FQDNs as the dump immediately preceding
682
  it, while a small value means that a considerable number of top 60k FQDNs were downsampled or removed, or
683
  that alternatively new FQDNs were added to the top 60k.</p>
@@ -736,12 +733,6 @@
736
  </d-article>
737
 
738
  <d-appendix>
739
-
740
- <h3>Contributions</h3>
741
- <p>Some text describing who did what.</p>
742
- <h3>Reviewers</h3>
743
- <p>Some text with links describing who reviewed the article.</p>
744
-
745
  <d-bibliography src="bibliography.bib"></d-bibliography>
746
  </d-appendix>
747
 
@@ -749,10 +740,10 @@
749
  const article = document.querySelector('d-article');
750
  const toc = document.querySelector('d-contents');
751
  if (toc) {
752
- const headings = article.querySelectorAll('h2, h3');
753
  let ToC = `<nav role="navigation" class="l-text figcaption"><h3>Table of contents</h3>`;
 
754
 
755
- let elements = [];
756
  for (const el of headings) {
757
  // should element be included in TOC?
758
  const isInTitle = el.parentElement.tagName == 'D-TITLE';
@@ -760,20 +751,25 @@
760
  if (isInTitle || isException) continue;
761
  el.setAttribute('id', el.textContent.toLowerCase().replaceAll(" ", "_"))
762
  const link = '<a href="' + '#' + el.getAttribute('id') + '">' + el.textContent + '</a>';
763
- if (el.tagName === 'H2')
764
- elements.push([link, []]);
765
- else {
766
- if (elements.length === 0)
767
- elements.push([null, []])
768
- elements[elements.length - 1][1].push(link)
 
 
 
769
  }
 
 
 
 
770
  }
771
 
772
- for (const topLevel of elements) {
773
- ToC += '<div>' + topLevel[0] + '</div><ul>';
774
- for (const subLevel of topLevel[1])
775
- ToC += '<li>' + subLevel + '</li>';
776
- ToC += '</ul>';
777
  }
778
  ToC += '</nav>';
779
  toc.innerHTML = ToC;
 
55
  border-right-color: rgba(0, 0, 0, 0.1);
56
  position: -webkit-sticky; /* For Safari */
57
  position: sticky;
58
+ top: 10px; /* Adjust this value if needed */
59
  }
60
  }
61
 
 
150
  </script>
151
  </d-front-matter>
152
  <d-title>
153
+ <figure class="l-page">
154
  <img src="banner.png" alt="FineWeb">
155
  </figure>
156
  </d-title>
 
171
  recipe, why more deduplication is not always better and some interesting findings on the difference in
172
  quality of CommonCrawl dumps.</p>
173
 
174
+ <h2>General considerations on web data</h2>
175
  <h3>Sourcing the data</h3>
176
  <p>A common question we see asked regarding web datasets used
177
  to train LLMs is “where do they even get all that data?” There are generally two options:</p>
 
191
  every 1 or 2 months, which can be freely downloaded. </p>
192
  <p>As an example, their latest crawl (2024-10) contains 3.16
193
  billion web pages, totaling 424.7 TiB of uncompressed content (the size changes from dump to dump). There
194
+ are 95 dumps since 2013 and 3 dumps from 2008 to 2012, which are in a different (older) format.<d-footnote>We have not processed these 3 older dumps.</d-footnote> </p>
195
  <h3>Processing at scale</h3>
196
  <p>Given the sheer size of the data involved, one of the main
197
  challenges we had to overcome was having a modular, scalable codebase that would allow us to quickly iterate
198
  on our processing decisions and easily try out new ideas, while appropriately parallelizing our workloads
199
  and providing clear insights into the data. </p>
200
  <p>For this purpose, we developed <a
201
+ href="https://github.com/huggingface/datatrove"><code>datatrove</code></a><d-cite bibtex-key="penedo2024datatrove"></d-cite>, an open-source data
202
  processing library that allowed us to seamlessly scale our filtering and deduplication setup to thousands of
203
  CPU cores. All the data processing steps involved in the creation of FineWeb used this <a
204
  href="https://github.com/huggingface/datatrove">library</a>.</p>
 
215
  choose a diverse set of tasks and try not to overfit to any one individual benchmark.</p>
216
  <p>Another way to evaluate different datasets would be to
217
  train a model on each one and have humans rate and compare the outputs of each one (like on the <a
218
+ href="https://chat.lmsys.org/">LMSYS Chatbot Arena</a>)<d-cite bibtex-key="chiang2024chatbot"></d-cite>. This would arguably provide the most
219
  reliable results in terms of representing real model usage, but getting ablation results this way is too
220
  expensive and slow.</p>
221
  <p>The approach we ultimately went with was to train small
 
250
  (should not be too noisy)
251
  </li>
252
  </ul>
253
+ <p>To
 
254
  have results quickly we capped longer benchmarks at 1000 samples (wall-clock evaluation taking less than 5
255
  min on a single node of 8 GPUs - done in parallel to the training).</p>
256
+ <aside>You can find the full list of tasks and prompts we used <a
257
+ href="https://huggingface.co/datasets/HuggingFaceFW/fineweb/blob/main/lighteval_tasks.py">here</a>.</aside>
258
  <h2>The FineWeb recipe</h2>
259
  <p>In the next subsections we will explain each of the steps
260
+ taken to produce the FineWeb dataset.</p>
 
261
  <figure class="l-body">
262
  <img src="plots/fineweb-recipe.png"/>
263
  </figure>
264
+ <aside>You can find a fully reproducible <code>datatrove</code> config <a
265
+ href="https://github.com/huggingface/datatrove/blob/main/examples/fineweb.py">here</a>.</aside>
266
  <h3>Starting point: text extraction</h3>
267
  <p>CommonCrawl data is available in two main formats: WARC
268
  and WET. <strong>WARC </strong>(Web ARChive format) files contain the raw data from the crawl, including the
 
272
  starting point. In our experience the default text extraction (extracting the main text of a webpage from
273
  its HTML) used to create these WET files is suboptimal and there are a variety of open-source libraries that
274
  provide better text extraction (by, namely, keeping less boilerplate content/navigation menus). We extracted
275
+ the text content from the WARC files using the trafilatura library<d-cite bibtex-key="barbaresi-2021-trafilatura"></d-cite>. It is important to note, however, that text extraction is one of the most costly steps of our
 
276
  processing, so we believe that using the readily available WET data could be a reasonable trade-off for
277
  lower budget teams.</p>
278
  <p>To validate this decision, we processed the 2019-18 dump
 
288
  removes part of the data (be it words, lines, or full documents) that would harm performance and is thus
289
  deemed to be “lower quality”.</p>
290
  <p>As a basis for our filtering we used part of the setup
291
+ from RefinedWeb<d-cite bibtex-key="penedo2023refinedweb"></d-cite>. Namely, we:</p>
292
  <ul>
293
  <li>Applied URL filtering using a <a
294
  href="https://dsi.ut-capitole.fr/blacklists/">blocklist</a> to remove adult content
 
296
  </ul>
297
  <ul>
298
  <li>Applied a <a
299
+ href="https://fasttext.cc/docs/en/language-identification.html">fastText language classifier</a><d-cite bibtex-key="joulin2016bag"></d-cite><d-cite bibtex-key="joulin2016fasttext"></d-cite> to
300
  keep only English text with a score ≥ 0.65
301
  </li>
302
  </ul>
303
  <ul>
304
+ <li>Applied quality and repetition filters from the Gopher<d-cite bibtex-key="rae2022scaling"></d-cite> paper (using the default thresholds)
 
305
  </li>
306
  </ul>
307
  <p>After applying this filtering to each of the text
 
315
  <p>The web has many aggregators, mirrors, templated pages or
316
  just otherwise repeated content spread over different domains and webpages. Often, these duplicated pages
317
  can be introduced by the crawler itself, when different links point to the same page. </p>
318
+ <p>Removing these duplicates (deduplicating) has been linked to an improvement in model performance<d-cite bibtex-key="lee2022deduplicating"></d-cite> and a reduction in memorization of pretraining data<d-cite bibtex-key="carlini2023quantifying"></d-cite>, which might
 
 
319
  allow for better generalization. Additionally, the performance uplift can also be tied to increased training
320
  efficiency: by removing duplicated content, for the same number of training tokens, a model will have seen
321
  more diverse data.</p>
 
324
  efficient data structures to index the data (like suffix arrays). Methods can also be “fuzzy”, by using some
325
  similarity metric to mark documents as duplicates, or “exact” by checking for exact matches between two
326
  documents (or lines, paragraphs, or whatever other granularity level being used).</p>
327
+ <h4>Our deduplication parameters</h4>
328
  <p>Similarly to RefinedWeb, we decided to apply MinHash, a
329
  fuzzy hash based deduplication technique. We chose to compute minhashes on each document’s 5-grams, using
330
  112 hash functions in total, split into 14 buckets of 8 hashes each — targeting documents that are at least
331
  75% similar. Documents with the same 8 minhashes in any bucket are considered a duplicate of each other.</p>
332
  <p>This would mean that for two documents with a similarity (<code>s</code>)
333
  of 0.7, 0.75, 0.8 and 0.85, the probability that they would be identified as duplicates would be 56%, 77%,
334
+ 92% and 98.8% respectively ($$1-(1-s^8)^{14}$$). See the plot below for a match probability
335
  comparison between our setup with 112 hashes and the one from RefinedWeb, with 9000 hashes, divided into 450
336
  buckets of 20 hashes (that requires a substantially larger amount of compute resources):</p>
337
  <figure><img src="plots/minhash_parameters_comparison.png"/>
 
339
  <p>While the high number of hash functions in RefinedWeb
340
  allows for a steeper, more well defined cut off, we believe the compute and storage savings are a reasonable
341
  trade off.</p>
342
+ <h4>More deduplication is always better, right?</h4>
343
  <p>Our initial approach was to take the entire dataset (all
344
  95 dumps) and deduplicate them as one big dataset using MinHash.</p>
345
  <p>We did this in an iterative manner: starting with the most
 
383
  <p>These results show that, for this older dump where we were
384
  removing over 90% of the original data, the data that was kept was actually <em>worse</em> than the data
385
  removed (considered independently of all the other dumps).</p>
386
+ <h4>Taking a step back: individual dump dedup</h4>
387
  <p>We then tried an alternative approach: we deduplicated
388
  each dump with MinHash individually (without considering the other dumps). This resulted in 20 trillion
389
  tokens of data.</p>
 
480
  <figure><img src="plots/Untitled.png"/></figure>
481
  <h3>Additional filtering</h3>
482
  <p>By this point we had reached the same performance as
483
+ RefinedWeb, but on our aggregate of tasks, another heavily filtered dataset, the C4 dataset<d-cite bibtex-key="raffel2023exploring"></d-cite>, still showed stronger performance (with
 
484
  the caveat that it is a relatively small dataset for current web-scale standards).</p>
485
  <p>We therefore set out to find new filtering steps that
486
  would, at first, allow us to match the performance of C4 and eventually surpass it. A natural starting point
 
493
  <p>Despite its age and limited size (around 175B gpt2
494
  tokens), models trained on this dataset have strong performance, excelling in particular on the Hellaswag
495
  benchmark, one of the benchmarks in our “early signal” group with the stronger signal and highest
496
+ signal-over-noise ratio. As such, it has stayed a common sub-set of typical LLM training, for instance in
497
+ the relatively recent Llama1 model<d-cite bibtex-key="touvron2023llama"></d-cite>. We experimented applying
498
  each of the different filters used in C4 to a baseline of the independently deduped FineWeb 2019-18 dump
499
  (plot smoothed with a 3 checkpoints sliding window):</p>
500
  <figure><img src="plots/c4_filters.png"/></figure>
 
593
  <p>We compared 🍷 FineWeb with the following datasets:</p>
594
  <ul>
595
  <li><a
596
+ href="https://huggingface.co/datasets/tiiuae/falcon-refinedweb">RefinedWeb</a><d-cite bibtex-key="penedo2023refinedweb"></d-cite>
597
  </li>
598
  </ul>
599
  <ul>
600
+ <li><a href="https://huggingface.co/datasets/allenai/c4">C4</a><d-cite bibtex-key="raffel2023exploring"></d-cite></li>
601
  </ul>
602
  <ul>
603
  <li><a href="https://huggingface.co/datasets/allenai/dolma">Dolma v1.6</a> (the
604
+ CommonCrawl part) <d-cite bibtex-key="dolma"></d-cite>
605
  </li>
606
  </ul>
607
  <ul>
608
+ <li><a href="https://huggingface.co/datasets/EleutherAI/pile">The Pile</a> <d-cite bibtex-key="gao2020pile"></d-cite></li>
609
  </ul>
610
  <ul>
611
  <li><a
612
+ href="https://huggingface.co/datasets/cerebras/SlimPajama-627B">SlimPajama</a> <d-cite bibtex-key="cerebras2023slimpajama"></d-cite>
613
  </li>
614
  </ul>
615
  <ul>
616
  <li><a
617
+ href="https://huggingface.co/datasets/togethercomputer/RedPajama-Data-V2">RedPajama2</a> <d-cite bibtex-key="together2023redpajama"></d-cite>
618
  (deduplicated)
619
  </li>
620
  </ul>
 
674
  <h3>Changes in the most frequent URLs [HAVE TO RECHECK]</h3>
675
  <p>For each crawl from 2021-10 onwards, we gathered a list of
676
  the 60k most frequent <strong>FQDNs</strong> (fully qualified domain name). We then calculated the <a
677
+ href="https://en.wikipedia.org/wiki/Jaccard_index">Jaccard similarity</a><d-cite bibtex-key="jaccard1912distribution"></d-cite> between consecutive
678
  crawls. A high value means that a crawl/dump has many of the same FQDNs as the dump immediately preceding
679
  it, while a small value means that a considerable number of top 60k FQDNs were downsampled or removed, or
680
  that alternatively new FQDNs were added to the top 60k.</p>
 
733
  </d-article>
734
 
735
  <d-appendix>
 
 
 
 
 
 
736
  <d-bibliography src="bibliography.bib"></d-bibliography>
737
  </d-appendix>
738
 
 
740
  const article = document.querySelector('d-article');
741
  const toc = document.querySelector('d-contents');
742
  if (toc) {
743
+ const headings = article.querySelectorAll('h2, h3, h4');
744
  let ToC = `<nav role="navigation" class="l-text figcaption"><h3>Table of contents</h3>`;
745
+ let prevLevel = 0;
746
 
 
747
  for (const el of headings) {
748
  // should element be included in TOC?
749
  const isInTitle = el.parentElement.tagName == 'D-TITLE';
 
751
  if (isInTitle || isException) continue;
752
  el.setAttribute('id', el.textContent.toLowerCase().replaceAll(" ", "_"))
753
  const link = '<a href="' + '#' + el.getAttribute('id') + '">' + el.textContent + '</a>';
754
+
755
+ const level = el.tagName === 'H2' ? 0 : (el.tagName === 'H3' ? 1 : 2);
756
+ while (prevLevel < level) {
757
+ ToC += '<ul>'
758
+ prevLevel++;
759
+ }
760
+ while (prevLevel > level) {
761
+ ToC += '</ul>'
762
+ prevLevel--;
763
  }
764
+ if (level === 0)
765
+ ToC += '<div>' + link + '</div>';
766
+ else
767
+ ToC += '<li>' + link + '</li>';
768
  }
769
 
770
+ while (prevLevel > 0) {
771
+ ToC += '</ul>'
772
+ prevLevel--;
 
 
773
  }
774
  ToC += '</nav>';
775
  toc.innerHTML = ToC;