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）！
