はじめに
はじめまして．松尾研GeniacプロジェクトにTeam天元突破のリーダーとして参加させて頂いたOzakiといいます．
東京大学松尾研究室にて、経済産業省によるGENIACの国産大規模言語モデル(Large Language Model: LLM)開発が行われており，執筆現在(2024年6月下旬)，フェーズ2ということで，50B級のLLMをフェーズ1優勝チームが開発しています．
我々の開発チーム「天元突破」は、当初より，ハルシネーション低減を目標にLLM開発に取り組んでいました．私が元来ハルシネーションという現象に興味があり，直近でRefinedWebという論文を読んでいたことが起因の一つです．
本記事では、当プロジェクトの簡単な概要(特に人事的な側面)とリーダーとしてのマネジメント関連について書いていきます．今後，様々な団体でLLM開発に取り組まれるはずです．そういった団体をマネジメントする方々に少しでも参考になればと思っています．
本プロジェクトについて
GENIACのもと、NEDOの助成事業に採択されました。
GENIACに採択された企業として、日本を代表する技術力のある企業が集結しています。
プロジェクトの説明・紹介
松尾研では下記を目的として本企画を推進していきます。
- 日本国内に100名規模のLLM開発経験者を育成する。
- 透明性の高い情報公開やコミュニティの運用により開発メンバー以外にもデータや開発ノウハウを普及させる。
- 50Bの日本語LLMを開発、公開する事で社会貢献および国内のLLM実装を加速させる。
詳しくはこちらをご覧ください。
フェーズ１について
本プロジェクトは経産省から計算リソースを与えられている期間を二分し，フェーズ1と2に分けられています．
フェーズ1では，参加開発メンバーは7チームに分かれ，10B級のLLMを開発します.
各チームにはそれぞれリーダーとサブリーダーに当たるコアメンバーが存在します．各チーム約30名ほどの開発メンバーが参加していました．
私のチームは，立ち上げ時にほとんどのメンバーがアサインされていましたが，加えて2回ほどメンバー補充がなされました．
したがって，メンバーのプロジェクト理解度には一定差がありました．またそれぞれ得意とするドメインが異なるメンバーで，ほぼ全員がLLMのフルスクラッチ開発は初めてというチームでした．
LLM開発の大まかな流れを理解する．
まずすべきことはLLMとはどう開発されるのか知ることです．
私が参考にしたのは，東大のGeniacプロジェクトのメンバー選考中に上がっていたNECのNLPチームを指揮する小山田さんの以下のスライドです．
(ただどうやらNECとしてではなく，小山田さん個人の見解としているようです)
このスライドは大変に参考になります．単純なLLM開発のみならずいろいろな知見をまとめてくださっています．
加えて以下のLLMの評価でお馴染みのNejumiリーダーボードを作っているW&Bさんの「LLMをゼロからトレーニングするためのベストプラクティス」という資料も拝見しました．
この二つの資料は私にとって金言的なものでした．
さて，これらの資料を読むとわかる通り，LLMの開発はモデルに知識と推論能力を与える「事前学習」とモデルに機能を与える「事後学習」に分かれます．(もちろんそのあとに評価等も行う必要があるわけですが．．．)
その二つのフェーズも以下のように細分化できます．
細分化されても，各タスクは非常に大きく，複数人で当たるのが一般的だと認識しています．(最近はツヨツヨな人が数人で全部やっちゃうパターンも考えられるようですが．．．)
加えて面倒なのが，各タスクが相互に関係し合っており，それぞれのタスクで何が行われているかによって，また別のタスクの方針に影響が出てしまいます．
LLMの開発とは斯くも複雑なんです．
(といっても一般の機械学習・深層学習屋さんからしてみれば，普通といえば普通なんでしょうが．．．LLMを作るうえでは一つ一つの作業が”大規模”なのでそう簡単ではありません．．．)
チーム作り
開発する上で，必要最低限のフローが分かったところで，実際にチームの組織図を考え始めました．
結論から言うとまず事前学習という大きなタスクに向かって，以下のように組成しました．
事前学習には３つのサブタスクがあります．
- Webや文献などから学習データの素となるテキストデータを収集してくるデータコレクション作業
- 収集したテキストデータを成型し実際に学習される"コーパス"を作るデータキュレーション作業
- 学習を行うモデルとトークナイザーを用意し完成したコーパスを学習させるモデル構築・学習作業
これらの各サブタスクに沿ってサブチームを用意しました．
- データコレクションチーム
- データキュレーションチーム
- モデルチーム
の３チームです．役割は画像の通りです．
サブチーム作り
これらのチームに人員を振っていくわけですが，その時にもいくつか注意したことがあります．
モデルチーム
今回はプロジェクト期間が短く，既存のモデルやトークナイザーの知識を既に持っている方々，シンプルにコードリーディング・ライティングの高い方々など，かなり少数精鋭チームを作りました．
データキュレーションチーム
一般にテキストのキュレーションはルールベースで行われるので，作業内容的にテキストデータを処理するアルゴリズムを考える必要があります．
データコレクションチーム
今回はプロジェクト期間が短く，既存のモデルやトークナイザーの知識を既に持っている方々，シンプルにコードリーディング・ライティングの高い方々など，かなり少数精鋭チームを作りました．
メンバー選びについて
前述の通り，今回のプロジェクトの参加者の得意ドメインのバリエーションが非常に多いという問題がありました．従って，まずは一人一人と個人的に話をしてどの人がどのタスクに最適か検討することに時間をとりました．
チームマネジメントにおいて，一人一人と話しをして，タスク振りをうまくやりましょうなんて，よく聞く謳い文句だと思いますが，殊LLM開発においては重要度を再認識したほうがいいと今回考えました．
というのは，
- コードが書けません．
- 初心者です．
みたいな人でもできるタスク(メタ的には"その人しかできないタスク"になるんですが)も多く存在するからでして，LLM開発経験者やツヨツヨエンジニアだけで最大速度を出して，初心者を切り捨てる行為は金銭面以外でももったいない行為です(大体のPJそうか笑)．
役職的なものについて
前述の通り，各チームにはリーダーとコアメンバーが存在しています．まず各サブチームのリーダーをコアメンバーに任せることとしました．
コアメンバーは実績能力ともに十分な方々ばかりでしたので，細かなタスク決めやサブチームのマネジメントも含めて，ざっくり振ってしまったのを覚えています(すみません)
ただコアメンバー以外にも能力が高く，ぜひとも各サブチームの中核を担ってほしい人が複数存在したので，アシスタントリーダーとして，サブチームリーダーを支える存在を用意しました．
アシスタントリーダーは，単純に補佐的な役割ではなく，自らアイデアを提案し，実装までしてくれるような牽引力も発揮できるように，できるだけチームの中でも立場を高く保ってもらいました．
そして前述の意識を持っていたため，役職を持った人にはLLM開発初心者のサポート受付窓口としての役割も担ってもらいました．
👌(問い合わせ口を増やして，それがコアメンバーを経由してリーダーまで吸い上げられる構造を作れたのは大きかったですね)
目的の設定について
どんなチームマネジメントでも大切だと思うんですが，目的設定はとても重要な事項です．
LLMの開発においては，まだまだ実験的な開発が主だと思うので，やりたいこと試したいことが発散しがちです．
前述の通り，我々のチームの目標は
ハルシネーション現象を最大限低減することです．全員にこの目標を共有して，ベースラインを作り，その上で得られる知見が最大化するように努めました．
なぜこの目標にしたかみたいな話はあまり中身がなくて，個人的に私が当時興味があったからです()
偶然直近でRefinedWebというデータキュレーションに関する論文を読んでいたことが影響しました笑
LLMに関する知見はまだ論文ベースで語られることが多いです．よって，ハルシネーションを抑えに行くぞと決まったら，まず最低限知識として持っておいてほしい知識を，参考論文として共有しました．
実際に全員に読むよう共有したのは以下の3本です．
・RefinedWeb
・Swallowコーパス
・コーパスクリーニング
どれもキュレーションに関する内容になっており，ハルシネーションの逓減にとりわけ事前学習データの高品質化の観点から取り組んだものになっています．
(中でもSB institutionさんがNLP2024で発表されたコーパスクリーニングの論文は非常に教科書的で，一読すべき内容だと思いました．)
開発したいLLMのタイプが決まったら，その開発においてチーム全体に共有すべき論文を調査し，事前にまとめておくことがリーダーには求められると思います．
ただ随分日本語論文解説記事も増えてきたので，積極的に利用するとよいと思います．たとえばRefinedWEBの論文は解説が既にありまして，以下などを共有していました．
👀情報のスピードが速いので，できるだけ最新の文献からチーム開発の足掛かりをつくるべきでしょうね・・・
LLM開発でかなり機能した作戦３選
サテライトコアメンバー(通称:遊撃部隊)
おそらくしばらくの間はLLM開発経験者は貴重な人材ですし，それに準ずる言語モデルの構築経験，大規模VMを使った開発経験も貴重なままでしょう．
従って，作業の進捗に個人差が出てくることは避けられません．
そこでチーム開発でよくある遊撃部隊(Geniac開発ではサテライトコアメンバーと呼称)の導入をしてみました．前述の通り，開発は基本サブチームでの役割をベースにしていたのですが，各サブチームを横断して作業したり，発言したりできる立場の人を用意しました．
効果はかなり大きかったと振り返っています．
以下の二つが特にLLM開発では大きかったと思います．
- 「個々人の余力に頼ってはこなせないタスクが減っていった」
「余裕があったらメイン文献のレファレンスの論文の内容もまとめておいて頂けませんか？」
「余裕があったらhuggingfaceに学習データを上げておいてもらえますか？」
「Transformer以外にMoEやMambaの手法が導入できるか検討頂けませんか？」
など，LLM開発には”ちょっとこっちも試せないかな？”みたいな細々したタスクが起こりがちです．そういった検討事項を，ちょっと手の空いている別のサブチームのサテライトコアメンバーの方に振って，比較的短い時間で取捨を決定してもらうみたいなことはよくありました．
- 「困り事が起こったときのフローが整理された」
遊撃部隊のメンバー間でも強みがいろいろあって，「このタスクは○○さんに振ればいいな」みたいなタスク振りの初動が自分の中では結構固まっていました．
逆にいうと何か試したい手法があって，その人たちができないなら，今回はスケジュール的にもタイトだったので，素直に見送る決断ができました．
試したいことは無限に出てくるので，どれをやって，どれをやらないみたいなのは，リーダーが決定しなければならないわけですが，なんらかの基準を用意しておくと決定しやすいでしょう．
サポートチーム
今回のプロジェクトは，メンバーが本業や学業と並行して参加するという特殊な環境下で進行していました．日々の進捗やSlack上の議論を追跡することが困難で，チーム全体の状況把握や個々のメンバーの貢献度にばらつきが生じるリスクがありました．
これらの課題に対処するため、「サポートチーム」という新たなサブチームを設置しました．
このチームの主な役割は，各サブチームの活動状況を集約し，プロジェクトの全体的な方向性を明確化すること，そして重要な情報をNotionで一元管理することでした．(蛇足ですが，うちのNotionはサポートチームの皆さんやメンバーの尽力により，結構綺麗に出来上がりました．以下で公開中です．)
サポートチームには，各サブチームの現在の作業内容を可視化し，進行中の実験などを記録し，意思決定プロセス，検討事項や今後の方針をまとめてもらいました．これらの情報を整理し，全員が素早くキャッチアップできるページを作成・更新し続けました．
これによって，一時的に離脱していたメンバーも素早くプロジェクトに再参加できるようになりましたし，マネジメント視点でも，全体像を把握しやすくなり，意思決定が迅速化されました．さらに，状況を俯瞰できることで、必要に応じて機動的にタスク割り当てができたかなと思います．
プロジェクトマネジメントにおいて，情報の透明性と共有はやはり重要です．特に、メンバーが常時コミットできない環境下では，サポートチームのような仕組みが，一体感を維持してくれますし，目標達成への道筋を明確にする上で大きな役割を果たしてくれますね．
データやモデルの共有はやはりhuggingfaceで
チーム開発においてはコードの管理といえば，Githubですが，AI，とりわけLLMにおいてはデータやモデルの管理はhuggingfaceで行うのが鉄板です．
今回においても，チーム全体用のhuggingfaceコミュニティを用意しておきました．(Githubも)
プロジェクトの中で使った事前・事後学習データ，各学習段階でのチェックポイントにおける完成前のLLM(LLM開発は学習が長いので，途中でセーブすることが主です．その途中段階のモデルという意味です)など，基本huggingface上で管理を行いました．
ローカルよりも見やすく管理しやすいですし，簡単にプライベートにもできるので，おすすめです．
また今回はGCPのVM上で開発を行っていましたが，リソースの関係から，小実験をVM外部で行うこともありました．たとえば個々人のローカルや，個別に契約した他社クラウド，それから多いのがGoogle Colabですかね．
このように作業環境が個々人で変わることも多い開発なので，huggingfaceにできたものから上げておくと，楽でした．
結局本番作業するのは，VM上だしいちいち上げておかなくていいかなと思わずに，積極利用したほうがいいのかなと思う派です．
まとめ
ここまでつらつらと書いてきましたが，結局何が言いたかったかというと，LLM開発においても，他の開発と同様に，チームワークとコミュニケーション，そして適切なツールを使いこなすことが重要だということです．
特に，今回のプロジェクトのように，短期間で，かつ経験値の異なる多様なメンバーが集まる場合は，リーダーが全体を俯瞰し，それぞれの個性や強みを最大限に活かせるようなチーム作り，環境作りが求められます．
そして，これは私自身も常に心がけている(プロジェクト中も心がけた)ことですが、メンバー一人ひとりと向き合いながら，できるだけ潤滑油的に振る舞い，その上で，重要事項を決定することがリーダーとして重要な責務だと考えています。
最後に
最後まで読んで頂きありがとうございました．
まだまだLLM開発は発展途上であり，我々も手探りで進めていました．今回のプロジェクトで得られた経験や教訓は，今後のLLM開発の現場で必ず活かされると信じています．
本記事が，これからLLM開発に携わる方々，特にチームを率いる立場になる方々の参考になれば幸いです。
謝辞
この成果は、NEDO（国立研究開発法人新エネルギー・産業技術総合開発機構）の助成事業
「ポスト５Ｇ情報通信システム基盤強化研究開発事業」（JPNP20017）の結果得られたものです。
![東大松尾・岩澤研究室 | LLM開発 プロジェクト[GENIAC]](https://storage.googleapis.com/zenn-user-upload/avatar/f9404760b8.jpeg)
東京大学 松尾・岩澤研究室が運営する松尾研LLMコミュニティのLLM開発プロジェクト[GENIAC] の開発記録、情報発信になります。 各種リンクはこちら linktr.ee/matsuolab_community
Discussion