Huggy Lingo：利用机器学习改进 Hugging Face Hub 上的语言元数据
Huggy Lingo：利用机器学习改进 Hugging Face Hub 上的语言元数据
要点速览：我们正在使用机器学习来检测 Hub 上没有语言元数据的数据集的语言，并使用 librarian-bots 来创建拉取请求以添加这些元数据。
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 上数据集数量的增长。
许多人希望能够找到特定语言的数据集。为特定语言训练高质量的开源 LLM 的主要障碍之一是缺乏高质量的训练数据。
如果我们转向查找相关机器学习模型的任务，了解模型训练数据中包含哪些语言可以帮助我们找到我们感兴趣的语言的模型。这依赖于数据集指定此信息。
最后，了解 Hub 上有哪些语言（以及哪些没有），有助于我们理解 Hub 的语言偏差，并有助于指导社区努力解决特定语言的空白。
使用机器学习预测数据集的语言
我们已经看到 Hugging Face Hub 上的许多数据集没有包含所用语言的元数据。然而，由于这些数据集已经公开共享，我们或许可以查看数据集并尝试使用机器学习来识别语言。
获取数据
获取数据集示例的一种方法是使用数据集库下载数据集，例如：
from datasets import load_dataset
dataset = load_dataset("biglam/on_the_books")
然而，对于 Hub 上的某些数据集，我们可能不希望下载整个数据集。我们可以尝试加载数据集的样本。但是，根据数据集的创建方式，我们最终可能仍然会在我们工作的机器上下载比我们所需更多的数据。
幸运的是，Hub 上的许多数据集可以通过数据集查看器 API 访问。它允许我们在不本地下载数据集的情况下访问 Hub 上托管的数据集。该 API 为您将在 Hub 上许多数据集上看到的数据集查看器提供支持。
对于预测数据集语言的首次实验，我们定义了一个列名和数据类型列表，这些列名和数据类型很可能包含文本内容，例如 text 或 prompt 列名和 string 特征很可能相关，而 image 则不相关。这意味着我们可以避免预测语言信息不太相关的数据集的语言，例如图像分类数据集。我们使用数据集查看器 API 获取 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) 的 ISO 693-3 语言代码 + 韩文字符 (Hang)，一个表示语言脚本的 ISO 15924 代码。
我们丢弃了脚本信息，因为它目前并未在 Hub 上作为元数据一致捕获，并且在可能的情况下，我们将模型返回的语言预测从 ISO 639-3 转换为 ISO 639-1 语言代码。这主要是因为这些语言代码在 Hub UI 中对导航数据集有更好的支持。
对于某些 ISO 639-3 代码，没有相应的 ISO 639-1 代码。对于这些情况，如果我们认为有意义，我们会手动指定映射，例如标准阿拉伯语 (arb) 映射到阿拉伯语 (ar)。如果无法进行明显的映射，我们目前不建议为此数据集提供元数据。在未来迭代的工作中，我们可能会采取不同的方法。重要的是要认识到这种方法确实存在缺点，因为它降低了可能建议的语言的多样性，并且也依赖于对哪些语言可以映射到其他语言的主观判断。
但过程并没有就此止步。毕竟，如果我们无法与社区其他成员分享这些信息，预测数据集的语言又有什么用呢？
使用 Librarian-Bot 更新元数据
为了确保这些有价值的语言元数据被重新整合到 Hub 中，我们求助于 Librarian-Bot！Librarian-Bot 接收由 Meta 的 facebook/fasttext-language-identification fastText 模型生成的语言预测，并打开拉取请求，将这些信息添加到各个数据集的元数据中。
该系统不仅可以更新数据集的语言信息，而且速度快、效率高，无需人工操作。如果仓库所有者决定批准并合并拉取请求，那么语言元数据将对所有用户可用，从而显著增强 Hugging Face Hub 的可用性。您可以在此处跟踪 librarian-bot 的活动！
后续步骤
随着 Hub 上数据集数量的增长，元数据变得越来越重要。特别是语言元数据，对于识别适合您用例的正确数据集而言，可能非常有价值。
借助数据集查看器 API 和 Librarian-Bots 的帮助，我们可以以手动方式无法实现的规模更新数据集元数据。因此，我们正在丰富 Hub，使其成为全球数据科学家、语言学家和人工智能爱好者更强大的工具。
作为 Hugging Face 的机器学习图书馆员，我将继续探索对 Hub 上托管的机器学习工件进行自动元数据丰富化的机会。如果您有任何想法或想在此项工作中进行协作，请随时联系（daniel at thiswebsite dot co）！
