Huggy Lingo 使用机器学习改善Hugging Face Hub上的语言元数据
Huggy Lingo 改善Hugging Face Hub上的语言元数据
Huggy Lingo：使用机器学习改进Hugging Face Hub上的语言元数据
tl;dr：我们正在使用机器学习来检测Hub数据集的语言，以及图书管理员机器人来创建拉取请求以添加这些元数据。
Hugging Face Hub已成为社区共享机器学习模型、数据集和应用的仓库。随着数据集数量的增长，元数据作为找到适合使用场景的正确资源的工具变得越来越重要。
在本博文中，我很高兴分享一些早期实验，旨在使用机器学习来改进Hugging Face Hub上托管的数据集的元数据。
Hub上数据集的语言元数据
Hugging Face Hub目前有大约5万个公共数据集。可以使用数据集卡片顶部的YAML字段指定数据集中使用的语言的元数据。
所有公共数据集通过元数据中的语言标签指定1,716种独特的语言。值得注意的是，其中一些是由于以不同的方式指定语言，例如en与eng与english与English。
例如，IMDB数据集在YAML元数据中指定en（表示英语）：
IMDB数据集的YAML元数据部分
毫不奇怪，英语是Hub上数据集中最常见的语言，约有19%的数据集将其语言列为en（不包括任何en的变体，实际百分比可能更高）。
Hugging Face Hub上数据集的频率和百分比频率
如果我们排除英语，语言的分布会是怎样的？我们可以看到有少数几种主导语言的聚集，然后其他语言的频率呈较平滑的下降。
Hub上数据集语言标签的分布（不包括英语）
然而，这里有一个重要的限制。大多数数据集（约87%）没有指定使用的语言；只有大约13%的数据集在其元数据中包含语言信息。
具有语言元数据的数据集的百分比。True表示已指定语言元数据，False表示未列出语言数据。没有卡片数据表示没有任何元数据或无法由”huggingface_hub” Python库加载。
为什么语言元数据很重要？
语言元数据可以是查找相关数据集的重要工具。Hugging Face Hub允许您按语言过滤数据集。例如，如果我们想找到包含荷兰语的数据集，我们可以在Hub上使用过滤器仅包括包含荷兰语数据的数据集。
目前，此过滤器返回184个数据集。然而，Hub上有一些包含荷兰语但没有在元数据中指定的数据集。这些数据集变得更难找到，特别是随着Hub上数据集数量的增长。
许多人希望能够找到特定语言的数据集。训练特定语言的良好开源LLMs的主要障碍之一是缺乏高质量的训练数据。
如果我们转向查找相关的机器学习模型的任务，了解模型的训练数据中包含的语言可以帮助我们找到我们感兴趣的语言的模型。这依赖于数据集指定此信息。
最后，了解Hub上代表的语言（以及未代表的语言）帮助我们了解Hub的语言偏见，并有助于指导社区努力解决特定语言的差距。
使用机器学习预测数据集的语言
我们已经看到，Hugging Face Hub上的许多数据集没有包含语言使用的元数据。然而，由于这些数据集已经以开放方式共享，也许我们可以通过使用机器学习来查看数据集并尝试识别语言。
获取数据
我们可以通过使用datasets库来下载数据集的一些示例。例如：
from datasets import load_dataset
dataset = load_dataset("biglam/on_the_books")然而，对于Hub上的某些数据集，我们可能不想下载整个数据集。我们可以尝试加载数据集的一部分。然而，根据数据集的创建方式，我们可能仍然会下载比我们所需的更多的数据到我们正在使用的机器上。
幸运的是，Hub上的许多数据集可以通过datasets服务器获得。datasets服务器是一个API，允许我们访问托管在Hub上的数据集，而无需在本地下载数据集。数据集服务器为Hub上托管的许多数据集提供了数据集预览的功能。
对于这个用于预测数据集语言的第一个实验，我们定义了一个包含文本内容的列名称和数据类型的列表，例如text或prompt列名称和string特征可能是相关的，而image则不是。这意味着我们可以避免对语言信息不那么相关的数据集进行语言预测，例如图像分类数据集。我们使用数据集服务器获取20行文本数据，以供机器学习模型使用（我们可以根据需要修改此值以获取更多或更少的数据集示例）。
这种方法意味着对于Hub上的大多数数据集，我们可以快速请求数据集中前20行可能包含文本的列的内容。
预测数据集的语言
一旦我们有了数据集中的一些文本示例，我们就需要预测语言。这里有各种选择，但是对于这项工作，我们使用了Meta创建的facebook/fasttext-language-identification fastText模型作为No Language Left Behind工作的一部分。该模型可以检测到217种语言，这很可能代表了Hub上托管的数据集的大多数语言。
我们将20个示例传递给模型，表示数据集中的行。这将导致每个数据集的20个单独的语言预测（每行一个）。
一旦我们获得了这些预测结果，我们需要进行一些额外的过滤，以确定是否将这些预测结果作为元数据建议。这大致包括：
- 按语言对每个数据集的预测进行分组：某些数据集返回多个语言的预测。我们按预测的语言对这些预测进行分组，例如，如果一个数据集返回了对英语和荷兰语的预测，我们将英语和荷兰语的预测分组在一起。
- 对于预测出多种语言的数据集，我们计算每种语言的预测次数。如果一种语言的预测次数少于总次数的20%，我们将丢弃该预测结果。例如，如果我们对英语有18个预测结果，而对荷兰语只有2个预测结果，我们将丢弃荷兰语的预测结果。
- 我们计算每种语言的所有预测结果的平均分数。如果与某种语言的预测结果关联的平均分数低于80%，我们将丢弃该预测结果。
显示如何处理预测结果的图示。
完成这些过滤后，我们还需要进一步决定如何使用这些预测结果。fastText语言预测模型将预测结果返回为ISO 639-3代码（一种国际语言代码标准），以及脚本类型。例如，kor_Hang是韩语（kor）+ 汉字脚本（Hang）的ISO 693-3语言代码，ISO 15924代码表示一种语言的脚本。
我们丢弃脚本信息，因为目前在Hub上不一致地捕获这些信息作为元数据，并且在可能的情况下，我们将模型返回的语言预测从ISO 639-3转换为ISO 639-1语言代码。这主要是因为ISO 639-1语言代码在Hub用户界面中对于浏览数据集有更好的支持。
对于某些ISO 639-3代码，没有ISO 639-1的等效代码。对于这些情况，如果我们认为有意义，我们会手动指定一个映射，例如标准阿拉伯语（arb）被映射为阿拉伯语（ar）。对于无法进行明显映射的情况，我们目前不会为该数据集建议元数据。在这项工作的未来迭代中，我们可能会采取不同的方法。需要认识到这种方法的缺点是，它减少了可能被建议的语言的多样性，并且依赖于关于哪些语言可以映射到其他语言的主观判断。
但是过程并不会止步于此。毕竟，如果我们不能与社区的其他成员共享这些数据集的语言预测信息，那么这些预测有什么用呢？
使用图书管理员机器人更新元数据
为了确保这些有价值的语言元数据能够整合回 Hub，我们转向图书管理员机器人！图书管理员机器人使用 Meta 的 facebook/fasttext-language-identification fastText 模型生成的语言预测，并打开拉取请求，将这些信息添加到每个相应数据集的元数据中。
这个系统不仅能够更新数据集的语言信息，而且还能够快速高效地完成，不需要人工操作。如果一个仓库的所有者决定批准并合并拉取请求，那么语言元数据就会对所有用户可用，大大增强了 Hugging Face Hub 的可用性。你可以在这里跟踪图书管理员机器人的工作！
下一步
随着 Hub 上数据集的数量增长，元数据变得越来越重要。特别是语言元数据对于识别适合你使用场景的正确数据集非常有价值。
借助数据集服务器和图书管理员机器人的帮助，我们可以以无法人工完成的规模更新数据集的元数据。因此，我们正在丰富 Hub，并将其打造成为全球数据科学家、语言学家和人工智能爱好者更强大的工具。
作为 Hugging Face 的机器学习图书管理员，我将继续探索自动元数据增强机器学习艺术品的机会，这些艺术品托管在 Hub 上。如果您有想法或希望参与这个工作，请随时与我联系（daniel at thiswebsite dot co）！
