2025-01-28 機械学習勉強会
今週のTOPIC[blog] 50B以下で高性能なABEJA Qwen2.5 32B-Japanese v0.1の公開[blog]大規模言語モデル PLaMo 2 のためのトークナイザ性能改善[blog] DeepSeek-R1の論文読んだ？【勉強になるよ】[論文] UI-TARS: Pioneering Automated GUI Interaction with Native Agents | Papers With Code[blog] LLMOps in Production: 457 Case Studies of What Actually Works - ZenML BlogメインTOPICDEPT: Decoupled Embeddings for Pre-training Language Models背景提案手法評価結果
今週のTOPIC
@Naoto Shimakoshi
[blog] 50B以下で高性能なABEJA Qwen2.5 32B-Japanese v0.1の公開
- Apache2.0
- Qwen2.5 32b-Instructをベースに継続事前学習を行っている。
- QwenはKaggleとかでも使われているやつ
- gpt-4oとclaude-3.5-sonnet-v2には及ばないが、gpt-4o-miniなどよりは性能が良い。
- 課題として、まれに中国語の出力が混ざることがある。
- 実際に使ってみた
- A100ギリ載るくらい
- 普通にやったら全く推論が終わらない。
- 量子化
- max_new_tokens = 512で0.5minuteくらいの推論時間
- 以下のような見積書に対して、取引先名などを抽出させてみる。
- 割と素早く推論できる。
@Yuya Matsumura
[blog]大規模言語モデル PLaMo 2 のためのトークナイザ性能改善
- PFNさんのLLM PLaMo 2 で利用されているトークナイザについての紹介記事
- 他のトークナイザと比較してもトークン効率（1トークンで平均何文字表現できるか）が大きく改善している。
- 以下のような観点を「LLMにとって都合の良い分割」として設計
- 例: 語彙中に空白を持つことを許すことで、定型句（「part of the」「In other words」など）も語彙になるようにし、トークン効率を向上しました。
- 例: 数字は必ず分割し、LLM が苦手とされる計算タスクの難易度が極端に上がらないようにしました。
- 例: （数トークン先の情報によって分割が変わるような）先読みを必要としないようにしました。
- 例: 頻度が同程度であっても、複合語（分割しても意味が通じる語彙）は積極的に分割し、トークン効率とモデル性能の両立を狙いました。具体的には「新車」という語は「新」と「車」に分けることで意味が通りますが、より頻度の低い「キャベツ」は「キャ」と「ベツ」に分けても情報が得られないことから、後者を優先して語彙に入れています（＝前者を優先して分割しています）。
- 例: トークン効率を極端に追求すると、「ンは」のような一見意味の通らない語彙が追加されます。これは、ひとつひとつは頻度が低い多数のカタカナ名詞が分割されて発生した末尾の「ン」と頻度の非常に高い助詞「は」が連なる頻度が、しきい値を超えるために発生します。このような文脈によって同一名詞が異なるトークン列になる問題が生じるため避けています。他にも「郎さん」という語彙も同様で、ひとつひとつの名前（例：一郎、三郎）はしきい値よりも頻度が低いですが、分割された「郎」と頻度の高い接尾辞である「さん」の組み合わせがしきい値を超えるということがあります。
各トークンの生成難易度が偏らないこと
モデルの重みが共有しやすいこと
同じ単語は同じトークンIDからなること
@Shun Ito
[blog] DeepSeek-R1の論文読んだ？【勉強になるよ】
- DeepSeek-R1の論文について概説している記事
- DeepSeek-V3-Base → DeepSeek-R1-Zero → DeepSeek-R1 の道すじを紹介
- 関連するGRPOについても紹介されている
- ルールベースの報酬設計 + 数学の問題を使った強化学習で精度改善されているのは面白い
@qluto (Ryosuke Fukazawa)
[論文] UI-TARS: Pioneering Automated GUI Interaction with Native Agents | Papers With Code
ByteDance Seed, Tsinghua University のインターン生と開発者らによる論文。
Computer Useのように GUI を通じてLLM Agentによる問題解決の性能改善を図ったもの。
工夫点は以下の4つ。2があるため、AndroidWorldでの性能が他のものと比べて大きく向上していると言えそう。
- 強化された知覚能力: 大規模なGUIスクリーンショットデータセットを活用し、UI要素のコンテキスト認識や正確なキャプション生成を実現。
- 統一的なアクションモデリング: プラットフォームを跨いでアクションを統一された空間で標準化し、大規模なアクショントレースを通じて正確なグラウンディングと操作を達成。
- システム2の推論: タスク分解、内省的思考、マイルストーン認識など、複数の推論パターンを活用した多段階の意思決定プロセスを組み込み。
- 反復的なオンライントレーニング: 数百台の仮想マシンで自動的に新しいインタラクショントレースを収集、フィルタリング、内省的に改良することで、データ不足を解消。
[blog] LLMOps in Production: 457 Case Studies of What Actually Works - ZenML Blog
LLMOpsの実践例をデータベース化し、そのサマリーをまとめたブログ記事。
実践例は各社のブログポストや登壇などから構造化しデータベース化している模様。（中身よりこの仕組みをよく作ったことのほうがえらいかもしれない）
メインTOPIC
DEPT: Decoupled Embeddings for Pre-training Language Models
ICLR2025 submitted (accepted?)
背景
- 言語モデルの事前学習は、様々なドメイン・言語のデータを混ぜ込んで学習させるのが一般的
- 課題: 異質なデータが存在するとモデル性能の低下につながる
- Negative Interference、Curse of Multilinguality
- 既存の多言語モデル（BERT, XLM, mT5など）は、データの言語比率を調整したり、ハイパラチューニングが必要
- 語彙を増やしていくことで、低リソース言語での性能悪化もみられる
提案手法
- 発想
- （Rust, 2021）How Good is Your Tokenizer? On the Monolingual Performance of Multilingual Language Models
- Multilingual BERTよりもMonolingual BERTの方が様々なタスクで性能が良い
- 言語ごとに適切なtokenizerを使うことでMultilingual BERTの性能が上げられる
- （Chen, 2023）Improving language plasticity via pretraining with active forgetting.
- 別言語に適応させる時に、embeddingをリセットして再学習すると柔軟性が向上する
- ドメイン・言語ごとに埋め込み空間の更新を分ける（別ドメインを混ぜない）と良い？
- DEPT (Decoupled Embeddings for Pre-Training)
- 言語モデルの埋め込み層を、トランスフォーマー本体とは異なる仕方で学習させる
- 学習の流れに関する既存との違い
- 既存: 全てのデータソース（ドメイン）からランダムサンプリングし、単一のモデルで共通のembeddingを学習
- 提案: ランダムにデータソースを選んでそれぞれで更新 → 集約を繰り返す
- 更新・集約の仕方が、トランスフォーマー本体と埋め込み部分とで変わる
- 連合学習的な学習方法を採用
- 参考: 連合学習 (Federated Averaging)
- 3種類の学習戦略を用意（それぞれ対応する部分だけ実行する）
- Spec: データソース k ごとに完全に独立した埋め込み学習
- transformer blocks → 各 k の更新を集約して反映
- token, positional embedding → 各 k の更新をそのまま使う
- Trim: データソース k の語彙に含まれるtokenだけ更新
- transformer blocks → 各 k の更新を集約して反映
- token embedding → k の語彙に含まれる部分だけ切り出して更新・集約
- 切り出しは指示行列を利用（Outerで戻すときは逆行列を当てる）
- positional embedding → 各 k の更新を集約して反映
- Glob: データソースごとに更新量は計算するが、埋め込み表現自体は単一
- transformer blocks → 各 k の更新を集約して反映
- token, positional embedding → 各 k の更新を集約して反映
評価
4つのResearch Questionsについて検証
- RQ1: 多様なドメインを持つデータセットで安定して学習できるか
- RQ2: DEPTはメモリ使用量や訓練時間を効率化するか
- RQ3: DEPTのゼロショット汎化性能
- RQ4: DEPTモデルの柔軟性
データセット
- マルチドメインデータ → The Pile
- 16ドメイン: GitHub (GH), DeepMind Mathematics (DM), Wikipedia (WK), Common Crawl (CC), PubMed Abstracts (PA), PubMed Central (PC), USPTO Backgrounds (UO), NIH Exporter (NH), FreeLaw (FL), Enron Emails (ENR), EuroParl (EP), Stack Exchange (SE), Philosophy Papers (PP), ArXiv (AR), Project Gutenberg (GU), Hacker News (HN)。
- 分布外データ（out-of-distribution dataset）として Ubuntu IRC (UI) を使用。
- 多言語データ → MC4
- 高リソース言語：英語 (EN)、イタリア語 (IT)、中国語 (ZH)。
- 中リソース言語：セルビア語 (SR)、マレー語 (MS)。
- 低リソース言語：スワヒリ語 (SW)、ウルドゥー語 (UR)、ラテン語 (LA)。
汎化性能・柔軟性の評価
- 汎化性能
- in-domainへの性能: 訓練データに存在するデータソースのテストデータで検証
- out-of-domainへの性能: OODデータで検証
- 柔軟性: より少ないステップの学習である程度の性能に到達できるか
結果
RQ1
- 既存のモデルだと、Activationの値のばらつきが大きくなったり、L2 normの値が大きくなったりする（perplexity改善が止まる原因になる）
- DEPTではそういった急激な変化が発生せず、安定して学習できている
RQ2
- TRIM, SPECは、更新されるtoken embeddingのパラメータが抑えられるため、コストも低い
RQ3
- すべての言語でDEPT系がより良い性能を示している → embeddingだけでなくtransformer本体もうまく学習されている
- embeddingが他のデータソースと情報を共有していないSPECでもほぼ同じくらいの精度が出ている
RQ4
- MC4全体、一部言語での学習のいずれでも、DEPTが最も早く高い性能に到達している