\documentclass[japanese,other]{jnlp_3.7}
\usepackage{jnlpbbl_2.2}
\usepackage[dvipdfmx]{graphicx}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{url}
\usepackage{hangcaption_jnlp}
\usepackage{array}
%%%%\usepackage{udline}
%%%%\setulminsep{1.2ex}{0.2ex}
%%%%\let\underline=\ul
\allowdisplaybreaks


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%% author's definition

%%%%%\usepackage[dvipdfmx,hidelinks]{hyperref}
%%%%%\usepackage{pxjahyper}
%%%%%\renewcommand\UrlFont{\rmfamily}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\Volume{31}
\Number{1}
\Month{March}
\Year{2024}
%%%%\Issuetitle{「　　　　」特集号}


\setcounter{page}{266}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\jsubject{学会記事}
\jtitle{LLM-jp: 日本語に強い大規模言語モデルの研究開発を行う\\組織横断プロジェクト}
\jauthor{河原　大輔\affiref{Author_1} \and 空閑　洋平\affiref{Author_2} \and 黒橋　禎夫\affiref{Author_3} \and 鈴木　　潤\affiref{Author_4} \and 宮尾　祐介\affiref{Author_5}}

\etitle{LLM-jp: Inter-organizational Project for the Development of Japanese Large Language Models}
\eauthor{Daisuke Kawahara\affiref{Author_1} \and Yohei Kuga\affiref{Author_2} \and Sadao Kurohashi\affiref{Author_3} \and Jun Suzuki\affiref{Author_4} \and Yusuke Miyao\affiref{Author_5}} 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\headauthor{河原，空閑，黒橋，鈴木，宮尾}
\headtitle{LLM-jp: 日本語に強い大規模言語モデルの研究開発を行う組織横断プロジェクト}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\affilabel{Author_1}{早稲田大学}{Waseda University}
\affilabel{Author_2}{東京大学}{The University of Tokyo}
\affilabel{Author_3}{国立情報学研究所/京都大学}{National Institute of Informatics / Kyoto University}
\affilabel{Author_4}{東北大学/理化学研究所}{Tohoku University/RIKEN}
\affilabel{Author_5}{東京大学}{The University of Tokyo}



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{document}
\maketitle

% 以下，論文を記述して下さい．
% 最後の部分に文献，著者関係の記述がありますので確認して下さい．

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{LLM-jp設立の経緯}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{figure}[t]
\begin{center}
%%%%%\includegraphics[scale=0.2]{llm-jp.png}
  \includegraphics{31-1ia21f1.pdf}
\end{center}
  \caption{LLM-jpホームページ}
  \label{fig:llm-jp}
\end{figure}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

大規模言語モデル (Large Language Model; LLM) をベースとしたChatGPT，特にGPT-4は驚くほど賢い．
従来の自然言語処理のタスク，たとえば構文の解析，意味の解析，文脈の解析，さらには機械翻訳，そしてもちろん人との自然な対話も，これまで長年の目標としていたレベルには到達してしまったといってよいだろう．
入力の深い理解や，言葉の使い方やニュアンスの説明まで行える翻訳機能\cite{yamada2023}には脱帽する．
我々が取り組むべき課題は，その賢さを解明すること，その安全性などを検討すること，そしてそれが社会にどのように受容され人間と共存していくかをデザインしていくことなどに一気に様変わりした．

しかし，ここで大きな問題がある．
LLMの研究開発には膨大な計算資源・資金が必要となり，一部の外国組織の寡占状態である．
そして，強い，大きなモデルの中身（アーキテクチャ，事前学習コーパス，学習ノウハウ，チューニングデータなど）はもはや公開されていない．
一方で，ハルシネーションや安全性の課題など，LLMが今後社会に本格的に受け入れられていくためにはまだまだ課題がある．

日本としての懸念もある．
GPT-3における日本語コーパスの割合は0.11\%であり\footnote{\url{https://github.com/openai/gpt-3/blob/master/dataset_statistics/languages_by_word_count.csv}}，それでもあそこまで賢いことが逆に凄いのだが，英語に比べると日本語の理解力，生成力は劣っている．
GPT-4のような英語コーパス中心のモデルが世界標準となれば，日本の活動や日本文化が埋没していく懸念もある．
また，外国モデルに完全に依存して日本の知的資産がただ流れていくことは経済安全保障上看過できない．

このような問題意識から，日本でもLLMを作ろう，そのための勉強会をはじめようということで，2023年5月に第一回のLLM勉強会を開催した（図\ref{fig:llm-jp}）\footnote{\url{https://llm-jp.nii.ac.jp/}}．
LLMの研究開発は計算資源的にも人的資源的にももはやビッグサイエンスである．
できるだけ多くの人が取り組む必要があるので，その活動から生まれるモデル，コーパス，チューニングデータなどはもちろん，議論の過程や失敗を含めてすべてオープンにすること（商用利用も可）を方針とした．

第一回のLLM勉強会は30名ほどの自然言語処理研究者による，まさに勉強会としてスタートしたが，この問題意識と考え方に賛同する参加者が日に日に増加し，現在（2023年12月）には800名を超える参加者となった．
学界と産業界がそれぞれ半数程度，産業界は50社超からの参加者がいる．

当初，計算資源の目処がなかったので，この活動の日本語名称はLLM勉強会とし，英語名称はLLM-jpとしてスタートした．
6月になって，2023年5月から有料サービスを開始したJHPCN（学際大規模情報基盤共同利用・共同研究拠点）が運営するmdxの計算資源に少し余裕があることがわかり，NII，理研AIP，そしてJHPCNで資金を持ち寄り3千万mdxポイントを購入し，40GBメモリーのNVIDIA A100 8基搭載の16ノードを専有する計算環境を手に入れた．
7月以降はこの環境を用いて具体的にモデルを作る活動をはじめたので，会の名称は日本語でもLLM-jpを使うこととした．

具体的なLLM構築のために，コーパス構築WG，モデル構築WG，評価・チューニングWGを作り，それぞれを河原（早稲田大学），鈴木（東北大学），宮尾（東京大学）が幹事としてリードした．
また，mdx をはじめとした計算基盤の整備や問題解決にあたる計算基盤WGを設け，空閑（東京大学）が幹事を担当した．
議論は，それぞれ週一回程度のオンラインミーティングとSlackで行った．
また，活動の進捗に伴い，学術ドメインWG，安全性WGなども立ち上がり，さらには，法律家も参加し，データ・モデルの利用や公開について法律の観点からSlack上ですぐにアドバイスがもらえる体制となったのはありがたいことであった．

ハイブリッド（リアル＋オンライン）のLLM勉強会は5月以降，月1回のペースで続けており，LLMに関する最新のトピックの紹介，日本で構築されるさまざまなモデルの紹介，WGの活動紹介などを行っている．

LLM-jpの最初のモデルとして，10月20日に，130億パラメータのLLM-jp-13Bを公開した．
モデルそのものはもちろん，コーパスやチューニングデータも公開する．
さらに，モデルの入出力に類似するコーパス中のテキストを検索する機能もそなえている．
つまり，何を根拠にそのような生成がなされているかを観察できる環境を整えている．

以下では，このLLM-jp-13Bの構築で中心的役割を果たした4つのWGの活動と，今後の見通しを紹介する．


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{コーパス構築WG}

LLM-jpとして最初に13Bモデルを構築することになり，その学習のために最初のコーパス (v1) を素早く構築する必要があった．
コーパス構築の方針として，公開可能なものを使うこと，日本語・英語・コードから構成することを決めた．
コーパスの規模としては，Chinchilla scaling law \cite{hoffmann2022training}に従い，13B $\times$ 20 トークン以上を目標に定め，具体的には日本語130Bトークン，英語130Bトークン，コード10Bトークンの合計270Bトークンから構成することにした．
日本語は，Wikipediaと多言語WebコーパスであるmC4 \cite{xue-etal-2021-mt5}の日本語部分を用い，mC4にはフィルタリングを適用した．
フィルタリングは，文書中のひらがなや有害語などの割合や，URLのドメインによって行った．
ドメインのフィルタはレトリバ社から提供を受けた．
英語はPile \cite{gao2020pile}，コードはStack \cite{kocetkov2022stack}の一部を用いた．
コーパスv1の構築スクリプトは公開している\footnote{\url{https://github.com/llm-jp/llm-jp-corpus}}．

トークナイザは『スーパーコンピュータ「富岳」政策対応枠における大規模言語モデル分散並列学習手法の開発』プロジェクト\footnote{\url{https://www.titech.ac.jp/news/2023/066788}}から提供を受けた．
コーパスv1の一部を用いて，日本語・英語・コードそれぞれからUnigram言語モデルでサブワード語彙を抽出し，それらをマージすることによって約5万サブワードからなる語彙を作成した．このトークナイザ関連のスクリプトは公開している\footnote{\url{https://github.com/llm-jp/llm-jp-tokenizer}}．

上記のコーパスv1およびトークナイザを2023年8月にモデル構築WGに渡し，それがLLM-jp-13Bモデルの事前学習に用いられた．
また，モデル構築WGから，事前学習の最後にもっとも高品質なコーパスを用いたいとい
う要望をもらい，コーパスv1のフィルタリングを強めることによって高品質な
27Bトークンを抽出し提供した．

LLM-jpにおける次のモデル構築のターゲットとして175Bモデルを構築することになり，現在，コーパスv2の構築を進めている．
Chinchilla scaling lawから，175B $\times$ 20 トークン以上の規模が必要と考えられたので，日本語2Tトークン，日本語・英語・コードで合計4Tトークンからなるコーパスv2の構築を目指している．
日本語は，Common Crawl全量から日本語文書を抽出し，重複除去，フィルタリングを行い，2023年12月に構築完了予定である．
コーパスv2の構築スクリプトは，ワークスアプリケーションズ社から公開されたuzushio\footnote{\url{https://github.com/WorksApplications/uzushio}}上で開発を行っている．

コーパスv1，v2はすべて公開予定である．
これらのコーパスにおいて，日本語と英語の混合比率は半々としているが，この混合比率や，コーパスの規模などについては今後の検討が必要と考えている．
また，Wikipediaやウェブ文書以外にも高品質なコーパスや各種ドメインのコーパスを使うべく，科学技術論文や特許文書，医療分野などのドメイン文書の利用について関係機関と交渉中である．

上述したコーパス構築はLLMの事前学習の入力を作るものであるが，一方で，LLMの出力がコーパス中のどこに基づいているかを分析するコーパス検索機能を開発中である．
すでに，コーパスv1に対してBM25および密ベクトルでインデックスを構築済みであり，LLM-jp Slack上のプレイグラウンドで検索を試すことができる．
この機能によって，ハルシネーションの低減やLLMの動作原理の解明に向けた研究を進めたいと考えている．


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{モデル構築WG}
モデル構築WGの役割は，言語モデルの事前学習を実施して，いわゆる「事前学習済み言語モデル」を構築することである．
より具体的には，コーパス構築WGから，事前学習に用いるコーパス（トークナイズ済み）を受け取り，ファインチューニングができる状態になっている事前学習済み言語モデルを，評価・チューニングWGに受け渡すまでを担当する．
つまり，受け取った学習用コーパスの前処理（事前学習時に高速にデータを読み込むためのバイナリ化），事前学習，そして，事前学習完了時のチェックポイントをチューニングに利用できるモデル形式に変換する処理などが主な作業になる．

本プロジェクトが発足した5月当初に，2023年の秋冬あたりまでに「日本語に強い13Bパラメータモデル」を構築し公開することを目標として，モデル構築WGの活動を開始した．
活動を開始した2023年5月当時の状況として，10ノード以上の計算機を用いた10Bパラメータを超える言語モデルの事前学習に関して，確固たる知見を誰も持ち合わせてはいなかった．
そのため，本WGの活動に参加した全員で事前学習に必要なことを一つずつ実際に経験し，試行錯誤しながら知見を得ていくという手順を踏んだ．

まず，言語モデルの事前学習を実施するためには，当然学習用のプログラムを用意する必要がある．
自前で学習用プログラムを構築するという選択肢もあるが，前述したように数ヶ月で13Bパラメータモデルを構築するという目標達成の観点で，時間的に困難と考えられた．
また，2023年5月の開始当時に10Bパラメータ以上の言語モデルの事前学習に利用可能なツールがいくつも公開されていたため，それらを利用することにした．
具体的には Megatron-DeepSpeed\footnote{\url{https://github.com/microsoft/Megatron-DeepSpeed}}, GPT-NeoX\footnote{\url{https://github.com/EleutherAI/gpt-neox}}, LLM Foundry\footnote{\url{https://github.com/mosaicml/llm-foundry}} の3種が候補として挙がった．
事前学習には，例えば10台以上の計算機を用いて10日以上の時間がかかるというように，膨大な計算機リソースを必要とする．
そのため，複数の学習を同時に実行したり，複数のツールを採用して大規模な言語モデルを複数個作って横並びで比較するといったことを実施するだけの時間的な余裕はなかった．
そこで，モデル構築WGの活動に利用するツールとしては，複数の参加者の利用実績があり，またDeepSpeedの開発に従事している開発者がLLM-jpの活動に開始当初頃から参加して頂いていたなどのいくつかの要因を加味してMegatron-DeepSpeedを本命のツールと考えた．
ただし，GPT-NeoX，LLM Foundryも学習速度や安定性の検証までは並行して実施することとした．
3つのツールに対して，それぞれ担当者を割り当ててチームを編成し，それぞれのチームで実施した結果を持ち寄って比較検討をおこなった．
最終的には，実行速度や学習の安定性の観点で，GPT-NeoXとLLM Foundryが明らかに優れているという結果は得られなかったこともあり，Megatron-DeepSpeedを用いて事前学習モデルを構築することにした（誤解がないように念のために書いておくと，GPT-NeoXとLLM FoundryがMegatron-DeepSpeedより劣っていたということではない）．

まずはじめに，言語モデルの学習速度について検証をおこなった．
例えば，10Bパラメータを超える規模の言語モデルを100Bトークン以上の学習コーパスで学習する場合に，現実的な時間で構築を終えるためには通常は10ノード以上の計算機環境を用いることになる．
仮に同じ言語モデルの学習設定を用いていても，利用する計算機クラスタ環境（CPU，GPU，ストレージ，ネットワークなど）の特性に応じて学習速度は大きく異なることがありえる．
そのため，利用する計算機環境ごとに適切な学習の設定を見つける必要がある．
%
利用した計算機環境の詳細と計算機環境に関連する様々な出来事に関しては，\ref{sec:mdx}節にまとめて記載しているので，そちらを参照されたい．
%
学習速度を計測する指標としては，モデルの大きさや計算機環境の違いに依存しない指標であるFLOPS (floating point operations per second) が既存研究でもよく用いられることから，ここでもFLOPSを用いて設定の探索を実施した．
%
今回採用したMegatron-Deepspeedでは，言語モデルの学習速度に関して，モデル並列（テンソルパラレル，パイプラインパラレル）に関する設定 \cite{DBLP:conf/iclr/LepikhinLXCFHKS21,DBLP:conf/iclr/LepikhinLXCFHKS21,DBLP:journals/corr/abs-1909-08053}，データ並列やバッチサイズに関する設定，および，Zero \cite{DBLP:conf/sc/RajbhandariRRH20}と呼ばれる主にGPU/CPUのメモリ利用と速度のトレードオフを決める設定など多岐にわたる選択肢がある．
それぞれの項目の値を組み合わせて様々な設定を用意し，それぞれに対して学習速度の実測値を収集した．
最終的に最も安定して最大のFLOPS値を出した設定を採用した．

学習速度の見積が完了したことにより，学習コーパス量が決まれば，学習時間を概算できるようになった．
実際にその当時に計算した学習時間は以下の通りである．
学習に利用する12ノードのmdx計算クラスタ上で13Bパラメータのモデルを学習する場合，平均的に170K トークン/秒で処理できるという実測値を得た．
このことから，13Bパラメータモデルを270Bトークンの学習コーパスを用いて学習する場合には， 約441.2時間，つまり，約18.4日という概算になった．


270Bトークンの学習コーパスを用いて言語モデルを学習させる目標で準備を進めていたが，学習コーパスの量が増えていくことが想定されたため，逐次的に学習コーパスが増加しても継続的に事前学習を実施できる学習方式を検討した．
ここでは，270Bトークンの学習データをおおよそ27Bトークンに10分割し，それらを一つずつ学習していく方式を試した．
また，将来的に1Tトークン程度のデータを学習すると仮定し，学習率のスケジューラーに1Tトークンの学習を実施する設定を適用した．
また270Bトークンから選出した品質の高いと考えられる27Bトークンの学習コーパスをコーパス構築WGに用意してもらい，事前学習の最後にその27Bトークンの学習コーパスを用いて学習を実施した．
またこの27Bトークンの学習時に学習率を収束させるように学習率のスケジューラーを設定した．

言語モデルの事前学習を実施する際に考慮すべき点の一つとして，学習の安定性も挙げられる．
大規模な言語モデルの場合には，学習がうまくいっているかの指針となる損失 (loss) の値が発散するという意味でモデルが効果的に学習できなくなる現象が散見される\footnote{例1 BLOOM-176B：\url{https://huggingface.co/blog/bloom-megatron-deepspeed#bf16optimizer}, 例2 OPT-{\linebreak}175B：\url{https://github.com/facebookresearch/metaseq/blob/main/projects/OPT/chronicles/10_percent_update.md#experiment-11xx-lineage---november-5-2021}}．
そのため，損失の発散が極力発生しないような学習の設定を見つけて利用する必要がある．
現時点で，なぜ損失の発散が発生するのかのメカニズムは完全には解明されていない\footnote{発生の要因は複数あることが想定されており特定が難しい．ただし，学習の安定性に関する研究は現在急速に発展しており，今後原因が解明される可能性はある．}．
そのため，試行錯誤的に対応していく必要がある．
今回のLLM-jpにおけるモデル公開用の事前学習においては，幸いなことに解決不能な損失の発散は起こらなかった．

10月20日に公開したLLM-jp-13Bのモデル (Version 1) には，GPT-2 \cite{Radford-gpt2}準拠のモデル構成を採用している．
GPT-2は相対的に古いモデル構成であり，モデル構成を選択する当時において，いくつかの新しいモデル構成やモジュールを採用できる可能性はあった．
しかし，モデルを公開し多くの人に使ってもらうことを考えた際に，モデル学習後のチェックポイントを世界的にみてユーザーの多い Hugging Face Transformers\footnote{\url{https://github.com/huggingface/transformers}} で利用できるモデル形式に変換可能なことが必須の要件となる．
残念なことに，学習に利用するMegatron-DeepSpeedのモデル形式はHugging Face Transformersではサポートされておらず，また，利用するコード自体も異なることから，適切にモデル形式を変換する必要があった．
このような観点でMegatron-DeepSpeedを見ると，Hugging Face Transformersへのモデル形式へ変換するスクリプトは提供されているが，GPT-2準拠のモデルしかサポートしていない．
そのため，独自にモデル変換スクリプトを用意しないのであれば，Megatron-DeepSpeedを用いる場合は必然的にGPT-2準拠のモデルしか利用できないという状況であった．
変換スクリプトを自前でバグを含まずに用意するだけの時間と人的リソースを確保できなかったため，また，今回はLLM-jpにとって最初のトライアルであることも鑑み，失敗の少ない選択としてGPT-2モデルを採用するという結論に至った．

上記の様々な検討を経て，公開用の言語モデルの事前学習を8月の下旬頃から本格的に開始した．
実際には，目標の13Bパラメータモデルの学習をいきなり実施するのはリスクも高いことから，1.3Bパラメータモデルの学習を本番前の練習として実施した．
10月20日に公開したLLM-jp-13Bは，丁度9月になった頃から学習を始め，おおよそ26日間かけて事前学習したモデルになる．
ただし学習途中に数回学習が止まるトラブルが発生しており，手動で学習を再起動させる必要があった．
もしトラブルなく学習が進んでいれば，理論値としては，最短で約21日程度で事前学習は実施できていた計算になる．
%
その後このモデルを評価・チューニングWGに受け渡し，モデル構築WGにおける公開用の言語モデル (Version 1) を構築する作業を終えた．

今後は，GPT-3 \cite{DBLP:conf/nips/BrownMRSKDNSSAA20}と同等の175Bパラメータ級の事前学習を実施することを検討して準備を進めている．
実際には，既に試験的にGPT-3準拠のモデルを用いて事前学習を試しており，いくつかの課題や考慮すべき点などを洗い出している．
来年度のできるだけ早い段階で，1Tトークンを超える学習コーパスを用いて学習した175Bパラメータ級の言語モデルを公開できるようにモデル構築WGの活動を進めていきたい．


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{計算基盤WG}\label{sec:mdx}

LLM-jpでは，1.3B，13Bパラメータモデル構築の計算機環境にmdxを利用した\footnote{\url{https://mdx.jp}}．
mdxは，全国の国立大学9組織，国立情報学研究所，産業技術総合研究所の計11組織で共同運営しているCPU，GPUからなる中規模計算機環境であり，インフラの特徴としては，クラウド型のアーキテクチャを採用している．
mdxはクラウドとしての機能を有することから，ユーザは，自身が必要なCPUやGPU，ストレージサイズを選択し，好きなOSとソフトウェアを利用した独自のクラスタを構築できる．
2023年5月当時，mdxは，正式運用を開始したばかりでGPU資源に空きがあったことから，LLM-jpのモデル構築に使用することになった．

クラウド型インフラにおけるGPUの取り扱いは，現在でも運用面，性能面で課題があり，実際mdxではLLM-jp用クラスタの構築時に様々なトラブルに遭遇した．
一般的にクラウド型インフラは，CPUを中心とした仮想マシン，仮想ネットワーク技術を土台として設計されているが，一方で，LLM開発で必要となるGPUクラスタは，GPU中心のインフラアーキテクチャが必要となる．
GPU中心のインフラアーキテクチャでは，今までCPUが実行していたストレージへのデータ読み書きやネットワークへのデータ転送を，GPUがCPUに代わって実行する．
そのため，GPUの運用面の課題としては，GPUによる転送データがCPUから観測できないケースが多く，トラブルが発生した際にクラスタの状況把握が難しい．
また，性能面では，仮想化マシン内，仮想マシン間におけるGPUのデータ通信に関する仮想化対応が未成熟であり，大規模なGPUクラスタを構築する際にGPUの性能が十分に発揮できないケースが発生する．

実際にLLM-jpでは，mdx上のNVIDIA A100 40GB SXMモデル128台によるクラスタ構築を通して，大小様々なインフラ側の性能問題を発見し，mdxチームと連携して対策を実施した．
発見した問題のうち，仮想マシン間におけるGPUのデータ転送の性能劣化に関する問題は，13Bモデルの事前学習開始日時までに解決できなかったことから，LLM-jpでは，当初予定していた8GPU仮想マシン16ノードによるクラスタの規模を縮小し，12ノードを用いて事前学習を実施した．
その後，計算基盤WGでは，13Bモデル構築完了後に，GPUの転送データの可視化環境を構築することでGPUクラスタの性能を調査し，その結果ネットワーク機器の負荷分散機能に関する設定不足と，利用ツールの通信ライブラリであるNCCLの設定不足を特定した．
現在はこれら発生した性能問題は解消されている．
計算基盤WGでは，LLM-jpの活動を通して得たGPUクラスタの運用ノウハウを他研究プロジェクトに対してもフィードバックしていきたい．


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{評価・チューニングWG}

ChatGPTに代表される対話型LLMが広く利用されるようになった一つの要因として，大規模コーパスで事前学習された言語モデルを適切な返答をするようにチューニングする技術が挙げられる．
チューニング前の言語モデルは，入力テキスト（プロンプト）に続けて自然で流暢なテキストを生成することができるが，それはプロンプトに対して人間が期待するような返答とは必ずしもならない．
プロンプトに対して人間が期待するような答えを出力させること（アライメント）はLLMの研究開発において重要な問題であり，チューニングはそれを実現するための重要なステップである．

LLMのチューニングでは，入力（プロンプト）に対する出力を学習データ（インストラクションデータ）として与えて教師付き学習を行う手法（インストラクションチューニング）と，LLMの出力に対して人間による選好度等をラベル付けすることで人間が好む出力をさせるように学習する手法（人間からのフィードバックによる強化学習; RLHF）が主流である．
インストラクションデータに変換できる日本語データが複数存在すること，学習が容易でツールが揃っていることから，LLM-jp-13Bモデルのチューニングではインストラクションチューニングを用いた．
LLM-jp-13Bモデルの公開に向けたチューニングでは，英語データを含めてさまざまなデータセットを検討した上で，3種類の日本語インストラクションデータを構築した．
1つは，既存の日本語処理タスクのデータをインストラクション形式に変換したものである．
これまでの自然言語処理の研究の蓄積で，意味解析や質問応答などの個々の言語処理タスクの学習・評価データが開発・公開されている．
そこで，これらのデータをプロンプトとそれに対する返答の形に変換し，インストラクションデータ jaster を構築した．
あと2つのデータは，英語インストラクションデータを日本語に機械翻訳したものである．
英語では多くのインストラクションデータが公開されているが，多くの研究で利用されていることとライセンス条件等を考慮し，databricks-dolly-15k \cite{DatabricksBlog2023DollyV2} と OpenAssistant Conversations Dataset (OASST1) \cite{kopf2023openassistant} を採用した．
これらのデータを DeepL\footnote{\url{https://www.deepl.com/}} で機械翻訳したものを，日本語インストラクションデータとして使用した．
チューニング手法としては，ネットワーク全体のパラメータをチューニングするフルパラメータチューニングと，低コストでチューニングを行うことができるLoRA \cite{hu2022lora} を用いた．

本WGのもう一つの活動として，日本語LLMの評価フレームワークの構築がある．
LLMはこれまでの特定目的のための言語処理システムと異なり，言語が関わるありとあらゆる応用で利用される可能性がある．
したがって，LLMの能力は特定のベンチマークによる精度では測ることが困難である．
実際，海外のLLM研究においても，LLMの評価方法についてはいまだ決着していない．
そこで本WGでは，一つのベンチマークを構築するのではなく，多角的な評価を行うことを目指して評価フレームワークの開発を進めている．
上述したように，これまでの自然言語処理研究の蓄積で，さまざまな個別タスクのための日本語データが開発されている．
そこで，それらの個別タスクに対して横断的にLLMの能力を評価するツール llm-jp-eval\footnote{\url{https://github.com/llm-jp/llm-jp-eval}}を構築した．
インストラクションデータの構築と同じ方式で，既存の日本語処理タスクをプロンプトと答えのペアに変換する．
LLM の評価を行う際は，プロンプトを入力し，LLMが出力したテキストを答えと照合して精度を測定する．

10月20日のLLM-jp-13Bモデルの公開 (Version 1) では，3つのデータセット (jaster, databricks-dolly-15k, OASST1) の合計約18万インスタンスのインストラクションデータを用い，フルパラメータチューニングあるいはLoRAチューニングを行ったモデルを公開した\footnote{\url{https://huggingface.co/llm-jp}}．
また，チューニング用ツール llm-jp-sft\footnote{\url{https://github.com/llm-jp/llm-jp-sft}}，インストラクションデータ jaster，評価ツールllm-jp-evalをあわせて公開した．
詳細は，LLM-jpリリースページ\footnote{\url{https://llm-jp.nii.ac.jp/release/}}を参照されたい．
jaster および llm-jp-eval (v1.0) では，日本語処理タスクのデータセット9個を用いている\footnote{執筆段階ではv1.1.0が公開されており，v1.0よりデータセットが増えている．}．
llm-jp-eval による評価では，上記3つのデータセットでチューニングしたモデルが高い精度を示しており，またフルパラメータチューニングとLoRAチューニングでは精度に大きな差がなかった．

LLM-jp-13Bの公開後も，チューニングおよび評価の改善に向けて活動を続けている．
チューニングについては，インストラクションデータの拡張，チューニング手法の比較検討，RLHFによるチューニングといった研究開発を進めている．
インストラクションデータとして，日本語のインストラクションデータを人手で構築したもの\footnote{\url{https://liat-aip.sakura.ne.jp/wp/llmのための日本語インストラクションデータ作成/}}や，GPT-4を用いてインストラクションデータを作成したものなどの開発が行われており，これらのデータを用いたチューニングの有効性を検証している．
また，RLHFを用いて有害性あるいはバイアスを持つテキストの生成を抑制する手法など別手法によるチューニングの実験や，低コストでチューニングを行うことができる量子化手法の検討を行っている．

評価については，さらに多様な日本語処理タスクのデータを収集し，llm-jp-eval でサポートするための作業を進めている．
ただし，llm-jp-eval による評価は既存の言語処理タスクをターゲットとしており，LLMの多様な利用場面における能力を十分に測定できているとは言い難い．
そこで，より多角的なLLM評価を実現するために異なるアプローチによる評価フレームワークについても研究を進めている．
現段階で，LLM-jpホームページでは，英語ベンチマーク Open LLM Leaderboard\footnote{\url{https://huggingface.co/spaces/HuggingFaceH4/open_llm_leaderboard}}による評価結果と，日本語VicunaQA\footnote{\url{https://github.com/ku-nlp/ja-vicuna-qa-benchmark}}による評価結果を公開している．
前者は，日本語LLMがどれほど英語処理能力を持つかを評価するもので，LLMの多言語性を測定することが期待される．
後者は，回答が非定型な多様なタスクにおいてLLMの出力を評価するために，GPT-4に回答の良さを判定させるもので，既存言語処理タスクでは評価が難しい回答の流暢さや的確性を評価できることが期待される．
いずれの評価手法もそれ一つでLLMの能力を完全に評価することはできないが，複数の評価フレームワークを用いることで，LLMの能力を総合的に評価・分析することを狙っている．

今後の重要な研究課題として，評価やチューニングの詳細な分析がある．
例えば，上述したフルパラメータチューニングとLoRAチューニングによるモデルは，llm-jp-evalの評価ではあまり差がないが，日本語VicunaQAでは大きな差が観測されている．
実際にLLMを使用した感触でも，LoRAチューニングによるモデルの方が適切な出力をすることが多いように観察される．
現時点でのチューニングや評価フレームワークは不完全なものであり，その分析はまだ手付かずである．
さまざまな評価・チューニングを簡単に試すことができる環境が整いつつあるため，チューニングデータやチューニング手法による効果の分析や，評価手法の有効性の分析を行う予定である．


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{おわりに}

日本でもLLMを研究開発する「場」が必要だし，まずはLLMを作ってみないと始まらない，そのような問題意識でLLM-jpを始めた．
これに賛同して多くの方に参加頂き，さまざまなご支援を頂き（寄付金，ツールの提供，環境の提供など），大きな活動に発展した．
参加者はこの規模でしかできないこと，ここでしかできないことをenjoyし，そして成果も出始めている．
このような，真のオープンイノベーションの活動はこれまでの日本にはほとんどなかったと言えるだろう．

このようなLLM-jpの活動が認められ，2024年4月にNIIにLLM研究開発センター（仮称）を設置することとなった．
これまでは資金的裏付けがなく，GPU難民であった．
4月からは，一定程度の計算資源を確保し，30名規模の研究者・開発者を雇用してLLM-jpの延長線上の活動を行う予定である．
優秀な若い方に集まって頂き，日本のLLM研究開発のハブとなり，また国際的な連携も進めていきたいと考えている．

我々の活動とその精神をよく表しているアフリカの諺で本稿を締めくくりたい．

If you want to go fast, go alone.  If you want to go far, go together.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\acknowledgment

LLM-jpの運営を支えて頂いたNIIの片岡洋教授／副所長，相澤彰子教授／副所長，菅原朔助教，計算環境整備等をご支援頂いた東京大学の田浦健次朗教授，東京工業大学の横田理央教授，多数のWGで活動頂いた株式会社リクルートの松田寛氏（Slackのmessage投稿数最多）をはじめ，LLM-jpに参加頂いているすべての方に感謝申し上げます．

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    \bibliographystyle{jnlpbbl_1.7}
    \bibliography{21refs}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{biography}

\bioauthor{河原　大輔}{%
2002年京都大学大学院情報学研究科博士課程単位取得認定退学．2005年同修了．博士（情報学）．東京大学学術研究支援員，情報通信研究機構主任研究員，京都大学准教授を経て，2020年より早稲田大学教授．
}
\bioauthor{空閑　洋平}{%
2015年慶應義塾大学大学院政策・メディア研究科博士課程修了．博士（政策・メディア）．
2015年5月より同大学にて特任助教．
2018年11月より東京大学情報基盤センター特任講師，2021年11月より同准教授．
}
\bioauthor{黒橋　禎夫}{%
1994年京都大学大学院工学研究科博士課程修了．博士（工学）．2006年4月よ
り京都大学大学院情報学研究科教授．2023年4月より同特定教授および国立情
報学研究所長を併任．
}
\bioauthor{鈴木　　潤}{%
2001年から2018年まで日本電信電話株式会社コミュニケーション科学基礎研究所研究員（特別研究員）．
2018年より東北大学大学院情報科学研究科准教授．
2020年データ駆動科学・AI教育研究センター教授．
2023年10月より言語AI研究センター長（現職）．
2005年奈良先端大学院大学博士後期課程修了．博士（工学）．
2017年より理化学研究所革新知能統合研究センター客員研究員．
2020から2022年までGoogle LLC Visiting Researcher（クロスアポイントメント）．
}
\bioauthor{宮尾　祐介}{%
2000年東京大学大学院理学系研究科修士課程修了．2001年より同大学にて助手，2007年より助教．2006年同大学大学院にて博士号（情報理工学）取得．2010年より国立情報学研究所准教授，2018年より東京大学教授．
}

\end{biography}


%%%%\biodate   %%%% 受付日の出力（編集部で設定します）

\end{document}
