(NLP2024) ワークショップ
気になってたお店にギリギリ間に合った pic.twitter.com/riLTVHXtjA
— Naruaki TOMA 温泉旅行... (@naltoma) March 15, 2024
お疲れモードなので今日はホテルからオンライン参加することに。机があるって素晴らしい。(会場はほとんど椅子のみ)
NLP最終日はワークショップ: 生成AI時代の自然言語処理における産学官の役割と課題に参加してました。セッションの中身としては「それぞれ尖った部分で活躍してる人の活動紹介や問題共有」という感じで、普段聞いたことない内容が多かったという点で面白かった。
全日程を通して心に残ったことは、、
- (1) 認知科学ドメインとの連携楽しそう
- 事前学習された言語モデルが内部でどのように言語的特徴や知識を符号化しているかを理解しようとする試みをプロービング(probing)と呼んでいるらしい。
- 今となっては小さなモデルだけども十分汎化能力があるBERT系を中心に模索が進んでいるらしく、その一例としてBabyBERTaがどのように知識を獲得しているか、幼児との共通点・差異に基づいた新たな仮説と拡張検討等が既に多く出ているらしい。公開されてるデータも多いようなので、まずは再現実験やってみたいな。
- (2) LLM-jpで共有・公開していくの良いな
- 並列処理周りは藤井さん追いかけると良さげ
- (3) データ構築大事、それと同じぐらい solution-driven も大事
- ただし過度に一般化しない(実世界は複雑)
- 能力を図るためとか用途に応じたデータも必要なのは理解できるけど、同じぐらい「全く異なるアプローチによる評価」が必要な気がする。ベンチマーク増やしまくっても実情にそぐわないみたいなのはどこでもある話なので。LLM時代の評価方法を検討すべきだな。
- それはそれとして、対象問題に対してどのようにデータを収集しアノテーションするかというのを既存事例整理して教える授業あっても良さそう。
- (4) 生成AI前提とした教育の検討
- 研究者として、学生として、社会として包括的な倫理も考える必要あり
- (5) 解釈の難しさは研究の積み重ねで考えるべし
以下ワークショップメモ。
生成AI時代の自然言語処理における産学官の役割と課題
生成AIのための自然言語処理技術
- 大規模言語モデル開発の展望と今後の課題
- PLaMo-13B: PFNのマルチモーダル基盤モデル
- A100, 480GPUで1ヶ月弱利用。日本語、英語の1.4兆トークンを使って学習
- 学習時の実行効率は41%で世界の他の学習基盤と比べても高い
- 100B/1Tパラメータからなる大規模マルチモーダル基盤モデル構築(に向けて行動中 by Preferred Elements)
- 100B: 安全性検証した上で事前学習済モデルや開発ノウハウを公開予定
- 産官学で安全性検証
- LLM開発における課題
- 学習データ: 影響評価が困難。小規模実験でうまく言っても大規模にするとうまくいかないことも。Perplexity Filteringが有効と言われているが理由不明。再現性。個別用途。
- アーキテクチャ:MoE (Mixture of Expert)。状態空間モデル(注意機構の置き換え)、Mamba [Gu 2023], Griffin [De 2024]。ただしICL、、、
- 状態空間モデルは有望だが、記憶容量が固定でありrecallに優れない(ので部分的な利用にとどまる?)
- Long Context: 数百万トークンに (Gemini1.5, list)。Context内で複数の異なるモーダルを統一的に扱うことができるように。
- 推論コストの削減: Transformerは推論効率が非常に悪い。工夫無しでは実行効率が数%(工夫次第で40%程度)。量子化、疎化、kvキャッシュの構造化(prefix-tree),,,
- マルチモーダル対応: 事前学習時から複数モーダルをまとめて学習 [Flamingo, Gemini]。その逆の影響は?
- 今後の展望
- モデル大規模化は1〜2T程度で頭打ち(学習→検証のスパンが半年〜1年。小さなモデルはその間に膨大な検証)
- QA
- Long Contextは本当に役に立つのか?
- RAGとの棲み分け。RAGは予め決めた指標に基づいて抽出。Long Contextは全入でkey,valueに基づいて抽出。最終的に精度はLong contextが高くなりそうだが、コスト大なので棲み分け。
- contextから見落とさないようにする技術が発展中。
- アーキテクチャ
- 画像等でもデータ規模、モデルサイズ増やしていくと他モデル(拡散モデル, Unet,,,)の性能が頭打ちになってきてるが、Transformerはなかなかサチらない。
- LLM安全性
- 包括的に考えることが大事。
- Long Contextは本当に役に立つのか?
- PLaMo-13B: PFNのマルチモーダル基盤モデル
生成AIによる社会環境の変化
-
言語教育分野における生成AIの影響と可能性
- 教育では評価が重要
- 従来の評価に対する考え方: 内容や方法で実力を図る。実力以上の成果物は作ることができない。思考力・判断力・表現力。
- 生成AIの登場でこれらの常識が通用しなくなった == 学習者の能力差(違い)が見えない。学習前後での発達、成長も見えない。
- 教育応用(英語学習)の例
- 訳し方がわからない場合のヒント。回答に辿り着くまでの手順を分解して入力。授業で扱えないことも自分で学べる。
- 教育内容を見直す必要性
- これまでの教材や授業が成立しなくなる
- AIを上手に活用できる要因あることが重要に(4技能の過度な習熟は不要に)
- 語学教育は人文科学、自然科学とは別枠になっているが継続する必要性は?
- 英語教育でなく国語教育を充実させることが有益なのか?
- 英語の位置づけの変化
- ELFとESPの時代
- 「第2言語として英語を用いる層」が多いのだから、教養英語 => 実用英語 => AI支援英語
- 英語能力を高める方向から活用する方向へ
- 英語を学ぶのは「実用」のためか「教養」のためか
- ELFとESPの時代
- 英語教育はどうなる?
- 基本的な知識はこれからも必要
- 単語や文法などをAIだけで学ぶのは非効率(?)
- 生成AIの出力を判断できる英語力は必要
- 実践型授業も注意が必要
- 学習者が自分で読んだり、書いたりするかどうかをしっかりと確認しなければいけない(区別困難)
- 学習者の主体性を引き出し、脅威氏は裏方に徹する
- できないことが試行錯誤でできるようになる成功体験
- 生徒や学生の自己実現と持続的な成長を可能にする教育
- 「誰が」「何を」「どこまで」学ぶ必要があるのか?
- 使いこなすためにはどのような知識がどのぐらい必要?
- プロンプト共有が中心になりがちだが、同じものが出力されない(どう学ぶ?)
- 基本的な知識はこれからも必要
- 教育では評価が重要
-
SF作家の命乞い
- AIキャラがかきにくい
- AIネタも書きにくい(皆使い方詳しくなった、ネタが被る)
個別タスクに対する生成AIの影響
-
言語間転移学習で大規模言語モデルを賢くする
- 資料: 言語間転移学習で大規模言語モデルを賢くする
- 言語間転移学習
- 多言語コーパスで学習した言語モデルは「言語に依存しない表現」を内部的に獲得
- 言語間転移を促進するには?
- 人間が新しい言語を習得する際には、辞書や例文から言語同士の対応関係を学ぶ
- LEIA: Wikipediaエンティティを使ったデータ拡張による言語間転移の促進
- 言語間リンクを利用してデータ拡張
火
=>火<translate>Fire</translate>
- 推論時に英語名を出力する挙動を抑制
- エンティティの英語名を入力系列に挿入することで、「英語で学習したエンティティの知識をLLM内部で抽出」しているようにみえる
- データ拡張なのでアーキテクチャを問わない
- 言語間リンクを利用してデータ拡張
-
弊社取り組み=特に要約=に対するLLMの影響
- 自動要約生成API TSUNA
- 文字数制限した上で要約
- 今回のタスクにおいては、ClaudeよりもChatGPT-4が良さそう
生成AIに関する産学官の役割
- 生成AIに関する産学官の役割 〜生成AI関連政策についての私見〜
- 1〜2年で起こること(産業界)
- 計算資源不足、日本語基盤モデル、オープン化 => 原理・現象解明
- API利活用、マルチモーダル化、小型、軽量化
- 5〜10年先で起こること(アカデミア=>産業界)
- 情報通信以外の分野での積極的活用
- ポイント
- インフラ整備と利用の分離
- ビジネス支援と、共通の知識基盤の並走
- 優秀人材の抜擢と流動性向上
- 1〜2年で起こること(産業界)
生成AIのための自然言語処理技術
- 大規模言語モデル(自然言語処理のための)の分散並列学習
- Kotoba Recipes
- 30B未満のモデル学習用。PyTorch FSDP backend
- Kazuki Fujii / Zenn
- 言語モデル学習とGPUメモリ(肌感覚)
- Adam FP16/FP32 Mixed Precision
- p = parameter数
- FP16 (2byte): parameters (2p), gradients (2p)
- FP32 (4byte): optimizer states (4*p * 3)
- total = 16p. ただしactivation, 中間層出力, パッチデータ, memory fragmentationなどの影響でこれ以上必要。
- GPT-2 1.3B
- 14 * 1.3B = 18.2GB +α
- backward: 20.8GB +α
- A100 (40GB): メモリに乗るギリギリのサイズ
- ZeRO
- d = GPU数
- Stage 1: optimizer statesを分割。
- 2p + 2p + (12p/d)
- forwardは普通にできる。通信も発生しない。重み更新後(1step毎)は all gather でparameterを全体に行き渡らせる。
- Stage 2: optimizer states, gradientsを分割。
- 2p + (2p+12p)/d
- 通信量は、ZeRO DP = ZeRO 1 = Zero 2
- Zero DPだけ利用するなら、ZeRO 2 を使えばメモリ上お得。Stage 1は 3D Parallelismと併用するときに都合が良い。
- Stage 3: optimizer states, gradients, prametersを分割。
- (2p + 2p + 14p)/d
- 通信量1.5倍(積み重なる)
- Zero3で遅い場合
- batch per device を ZeRO2から増加させていない(メモリ空いてるはずなのにバッチ増やしてない)
- ノード間の通信が遅い
- 肌感覚
- 7B: A100, 8枚で学習できる
- 13B: A100もぎりぎり乗る。学習時間的には2ノードったほうが良い。
- CPUは10%〜多くて15%程度。学習時にはほぼ無視できる。
- メモリはcheckpointsに変換するところでネックになる。
- Kotoba Recipes