太長不看版: Hub 上有不少數據集沒有語言元數據，我們用機器學習來檢測其語言，并使用 librarian-bots 自動向這些數據集提 PR 以添加其語言元數據。

Hugging Face Hub 已成為社區共享機器學習模型、數據集以及應用的存儲庫。隨著 Hub 上的數據集越來越多，元數據，作為一種能幫助用戶找到所需數據集的工具，變得越來越重要。

我們很高興能夠通過本文與大家分享我們的一些早期實驗，這些實驗旨在利用機器學習來改進 Hugging Face Hub 上托管的數據集的元數據。

Hub 上數據集的語言元數據

目前 Hugging Face Hub 上約有 5 萬個公開數據集。用戶可以通過 數據集卡 頂部的 YAML 字段設定其語言元信息。

我們目前支持 1716 種語言標簽，所有的公開數據集都可以在其語言元信息中指定其一。請注意，有些語言會有多個不同的語言標簽，如 en 、eng 、english 、English 都是英語。

舉個例子，IMDB 數據集 的 YAML 元數據中的語言標簽為 en :

IMDB 數據集的 YAML 元數據部分

迄今為止，Hub 上數據集上最常見的語言是英語，有大約 19% 的數據集將其語言標注為 en (這還沒把 en 的其他變體統計在內，因此實際百分比可能會比 19% 要高得多)。這個現象符合我們的預期。

Hugging Face Hub 上的數據集的頻率及占比

如果排除掉英語，語言分布又如何呢？我們可以看到，有幾種語言相對占主導，隨后的其他語言的頻率則出現了平穩下降。

Hub 上數據集的語言標簽分布情況 (除英語外)

這里，我們發現一個重大問題，那就是大多數數據集 (約 87%) 沒有指明其所使用的語言，只有大約 13% 的數據集在其元數據中指明了語言信息。

具有語言元數據的數據集占比。True 表示指明了語言元數據，False 表示未列出語言元數據。No card data 意味著沒有任何元數據，抑或是`huggingface_hub` Python 庫無法加載它。

為什么語言元數據很重要？

語言元數據是查找相關數據集的重要工具。Hugging Face Hub 允許用戶按語言過濾數據集。例如，如果想查找荷蘭語數據集，我們可以在 Hub 上用 過濾器 過濾出僅包含荷蘭語的數據集。

目前，此過濾器返回 184 個數據集。但是，Hub 上其實還有別的一些數據集中包含荷蘭語，但其未在元數據中指明語言，因此就很難被過濾器找到。隨著 Hub 上數據集越來越多，這種現象會愈發嚴重。

許多人希望能夠找到特定語言的數據集。而當前，為特定語言訓練出優秀的開源 LLM 的主要障礙之一就是缺乏相應語言的高質量訓練數據。

在為某些任務搜尋相關的機器學習模型時，了解模型的訓練數據中包含哪些語言有助于我們找到能夠支持我們想要的語言的模型。而這又依賴于相應的訓練數據集中是否含有相關語言信息。

最后，了解 Hub 上有哪些語言 (以及沒有哪些語言)，有助于我們了解 Hub 在語種支持上的偏差，并為社區解決特定語言上的數據差距提供信息支持。

利用機器學習預測數據集的語言

我們已經看到 Hugging Face Hub 上的許多數據集并未包含語言元數據。然而，由于這些數據集已經公開，也許我們可以嘗試利用機器學習來識別其語言。

獲取數據

我們可以使用 datasets 庫下載數據集并獲取它的一些樣本，代碼如下:

from datasets import load_dataset

dataset = load_dataset("biglam/on_the_books")

對于 Hub 上的某些數據集，我們可能不希望下載整個數據集。我們可以嘗試加載數據集的部分樣本。然而，根據數據集的創建方式不同，對某些數據集，我們最終下載到機器上的數據可能仍比我們實際需要的多。

幸運的是，Hub 上的許多數據集都可以通過 datasets server 獲得。Datasets server 是一個 API，其允許我們無需下載到本地即可訪問 Hub 上托管的數據集。Datasets server 已被應用于數據集查看器預覽功能，Hub 上托管的許多數據集都支持數據集查看器預覽功能。

為了給語言檢測實驗準備數據，我們首先定義了一個白名單，其中包含了可能包含文本的列名及數據類型，如名字為 text 或 prompt 的列以及數據類型為 string 的特征可能包含文本，但名字為 image 的列大概率是不相關的。這意味著我們可以避免為不相關的數據集預測其語言，例如為圖像分類數據集預測語言。我們用 datasets server 獲取 20 行文本數據并傳給機器學習模型 (具體用多少行數據可以根據實際情況修改)。

這么做的話，我們可以對 Hub 上的大多數數據集，快速獲取它們前 20 行數據的文本內容。

預測數據集的語言

獲取到文本樣本后，我們就需要預測其語言。這里有多種方法，目前，我們使用了由 Meta 為 “一個語言都不能少” 項目而開發的 facebook/fasttext-language-identification fastText 模型。該模型可以檢測 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-3 代碼并沒有對應的 ISO 639-1 代碼。此時，如有必要，我們會手動指定映射，例如將標準阿拉伯語 ( arb ) 映射到阿拉伯語 ( ar )。如果無法進行顯式映射，我們索性就放棄配置該數據集的語言元數據。我們會在后續工作中繼續改進我們的方法。我們已經意識到，當前的方法確實是有缺點的，它人為減少了語言的多樣性，并依賴于對某些語言映射關系的主觀判斷。

我們會持續改進，但當前我們并不會因為被問題絆住而停在原地。畢竟，如果我們無法與社區其他成員共享這些信息，那么預測數據集的語言又有什么用呢？有缺陷的信息總比沒有信息好。

使用 Librarian-Bot 更新元數據

為了確保將這些有價值的語言元數據上傳至 Hub，我們使用了 Librarian-Bot！ Librarian-Bot 會采納 Meta 的 facebook/fasttext-language-identification fastText 模型預測的語言信息，并自動生成 PR 以將此信息添加至各數據集的元數據中。

該系統可以快速高效地更新各數據集的語言信息，無需人類手動操作。一旦數據集的所有者批準并合并相應 PR，所有用戶就都可以使用該語言元數據，從而顯著增強 Hugging Face Hub 的可用性。你可以在 此處 跟蹤 Librarian-Bot 的一舉一動！

下一步

隨著 Hub 上的數據集越來越多，元數據變得越來越重要，而其中語言元數據可以幫助用戶甄別出合適自己場景的數據集。

在 Datasets server 和 Librarian-Bots 的幫助下，我們可以大規模地自動更新數據集元數據，這是手動更新無法企及的。我們正在用這種方法不斷豐富 Hub，進而使 Hub 成為服務世界各地的數據科學家、語言學家和人工智能愛好者的強大工具。

---

英文原文: https://hf.co/blog/huggy-lingo

原文作者: Daniel van Strien

譯者: Matrix Yao (姚偉峰)，英特爾深度學習工程師，工作方向為 transformer-family 模型在各模態數據上的應用及大規模模型的訓練推理。

總結

以上是生活随笔為你收集整理的Huggy Lingo: 利用机器学习改进 Hugging Face Hub 上的语言元数据的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。