Zenn
東大松尾・岩澤研究室 | LLM開発 プロジェクト[GENIAC]
💨

松尾研LLM開発プロジェクト進捗状況｜ハルシネーション逓減特化チーム

松尾研 LLM開発 GENIAC
2024/05/23に公開
LLM
GENIAC
松尾研
tech

第1回：週次報告

開発テーマ・概要

開発テーマ

  1. メインテーマ
    「ハルシネーションが最大限逓減された(最大限自然言語的に自然な言語のみを含ませた事前学習データによって学習された)日本語大規模言語モデルを開発する．」

  2. サブテーマ1
    「ディベートデータを用いて言語モデルを事後学習することでより高次な論理的思考力をモデルに付与する」

  3. サブテーマ2
    「MoE(Mixture of Expert)の実装例となるモデルをOSS公開する」

プロジェクト目標

  • 全員が成長する．
    • できるだけ離脱者を出さず，LLM開発経験者を最大限生産する
  • 研究余地や公開意義のある知見を取り出す
    • 日程，計算，データなどのリソースは限られるが，最大限アカデミアへの貢献を目指す
  • ハルシネーションの最大限逓減を目指す
    • 嘘をできるだけつかないLLM開発へ向け，事前学習データの精査(+RLHF)に挑戦する

メインの参考文献

開発状況

  • メンバーの個々人の特性に合わせてサブチームに振り分け．コアメンバーにサブチームリーダーを担当してもらう．
  • 各サブチームにリーダー補助のアシスタントリーダーを複数人配置
  • 能力値の高いメンバーには遊撃部隊としてチームを横断して意向を優先する権利を付与
  • 全サブチームを横断的に手助けするサポートチームを用意

チーム構成

  • データコレクションチーム
    • 使用するWebコーパスの決定・収集，それ以外のテキストデータの収集を担当
    • それぞれのコーパスの性質を理解し，必要なデータを決定し，データキュレーションにも助言する
    • 幅広いドメインに関わりのあるチーム
  • データキュレーションチーム
    • Webクロールデータを事前学習データへと変換する作業を担当
    • 参考文献から従来のフィルタリング手法を参考に，MLやLLM等も駆使し，高品質な事前学習データを作成する．
    • LLMによるリフレーズを用いて，データの絶対量を減らさないキュレーションフレームワークを検討する．
    • 最も人数配分の大きいチーム
  • モデル・トークナイザーチーム
    • 使用するモデルやトークナイザーを決定し，実装する作業を担当
    • 標準コードを参考に，transformerベースでMoEを組み合わせたモデルを開発する．
    • その他のモデルや学習手法についても検討する．
    • 少数精鋭で意思決定の速いチーム
  • サポートチーム
    • 文献の整理，Notionの整理，他チームや外部からの知識の整理を行い，全サブチームのサポートを担当する
    • 論文を読む能力やキャッチアップ能力の高い学生が中心のチーム

協力団体

  • 日本教室ディベート連盟
  • 全日本ディベート協会
  • 日本ディベート協会
  • パーラメンタリーディベート協会

サブチームの状況

コレクションチーム

  • 進捗

    • LLM-jpコーパスの構築
      • ja-wiki：完了
      • en-wiki：ダウンロードのみ完了
      • ja-cc：AWSでダウンロード中※2日ほど経過したが終わらず
      • Pile：著作権の課題あり
      • Stack：ライセンスの課題あり
    • 収集する事前学習用データセットの全体像の意識合わせ実施

      • 目標：4/15までに事前学習に必要な200Bトークンを集める

        ①：CulturaX ja ダウンロード中（あと1日程度の見込み）

        ②：mC4 ja LLM-jpコーパス構築にてダウンロード中（終了時期不明）

        ③：SlimPajama　⇒ダウンロードスクリプト確認中。人海戦術で収集予定

        ④：数学やコード

  • これからやること

    • 英語コーパスデータのダウンロード
    • trafilaturaでウィクショナリーをクローリング
    • クロールするディベートデータ一覧作成

キュレーションチーム

モデルチーム

  • 進捗
    • 標準コードによる事前学習 → プレ環境で事前学習の実行~wandbまでの動作を確認
    • +αの実装 → 標準コードを変更してMegatron-DeepSpeedに実装されているMoEの実験に挑戦
  • これからやること
    • 標準コードを変更して、チームで収集したデータセットでGPTを事前学習できるようにする．
    • MoEには引き続き挑戦(Megatron-DeepSpeedで実装できるのか、huggingfaceへの変換はできるのか)

その他

  • キャッチアップがしやすい仕組みを整える
    • slackチャネルが多い、作業に必要な情報が流れてしまう．
    • 対策としてnotionにキャッチアップ用の資料を作る．
    • 特にslackの内容のキャッチアップさせるのが困難
  • 他チームの様子がわからない．
    • Notionが公開されていない
    • コンペ要素もあるが，できるだけ公開してほしいとの声
  • 外部団体とのディスカッション
    • ディベートデータ提供団体との話し合いが終了．
    • 既にネット上に公開されているテキストデータ，動画データのみ使用することで合意．
    • 今後の研究に繋がったら協力を約束．

第2回：週次報告

サブチームの状況

コレクションチーム

  • 進捗
    • 上記資料の通り、データセットを収集してきているが、共有ディスクの5TB制限が課題
      • SlimPajamaが大きなデータセット
      • 本番環境へのデータ移行を見据えて、別環境にデータ蓄積可能か検討中
        • 他チームとのファイル共有方法が課題
  • これからやること
    • 数学やコード系のデータセット調査と収集

キュレーションチーム

モデルチーム

  • 進捗
    • 収集いただいたデータ(wiki ja)の一部を使って標準コードの動作を確認しました
    • Megatron DeepSpeedのMoEが使えないか調査していますが、うまく動作しないのでもう少し続けてダメだったら代替案を考えるかもしれません
    • 先週話していたキャッチアップ資料のモデルチーム版を作成しました
  • これからやること
    • 標準コードで利用データの拡大およびマルチGPUでの学習を行い、動作確認と実行時間の確認を行います。
    • MoEの調査を続けます。Megatron DeepSpeedでだめだった場合は代替案(他のライブラリ)を検討します。
    • 事後学習の練習も開始します。huggingfaceにある既存モデルのfine-tuningの通じて、事後学習での精度改善のポイントを探索します。
    • 事前学習の精度改善アイデアは引き続き調査します。

その他

  • マルチGPUに関する案内が想定していた内容と違ったのですが、リーダー通じて問い合わせてもらっても良いでしょうか？(とりあえずgeniac_07_dev_envには書いた)
    • ノードではなくGPU数が3つまでになっている
    • マルチノードについての言及なし
    • ミス？
  • GPU時間がどれくらい制限きついかってリーダーには情報入ってたりしますか？
    • ストレージ容量のほうが，お金的にきついとのこと．．．

第3回：週次報告

サブチームの状況

コレクションチーム

  • 進捗
    • チームの共有ディスクの利用状況を踏まえ、別環境準備（AWS 5TB）@高志 柴田
      • 通信コストを考えて，アクセスメンバーは限定
    • SlimPajama：DL完了 @村上一真 @坂本真樹 @高志 柴田
      • チーム間の受け渡し方法やJSONL形式の単位について相談したい
      • Train/Validation/Testの単位で1個のJSONLファイルの計3個がアウトプットでよいか
      • 前処理で重複処理などをかける場合はマージ処理をしないほうがよいか
    • CulturaXのJSONL化：対応中 @由紀子 松田 @高志 柴田
    • proof-pile-2：今後、着手
    • ディベートデータ関連
      • 状況把握
      • PDF2Text対応から着手 @満喜 田上
      • 事後学習用の場合にどのようなアウトプットにするか
        • 今後チーム横断して作業する方向で．
  • これからやること
    • CulturaX JSONL化
    • proof-pile-2 DL
    • ディベートデータ関連

キュレーションチーム

  • 進捗
    • 実装・検証
      • ルールベースフィルタリング
        • 予定よりも進捗が遅れている（新学期が始まり、作業時間の確保が難しい人が想像以上に多いため）
        • 今週のメンバーの進捗状況を再確認したところ、水曜日の夜に実装が出揃う予定
        • 現在のフィルタリング実装だとほとんどのデータが削除されてしまっており、実装を見直しつつ原因を調査中
      • 重複削除
        • テストまで完了
        • 日本語Webコーパス2010の重複排除から実施予定
      • URLフィルタリング
        • ルールベースフィルタリングに合流する
        • ルールベースフィルタリングの実装リストに、URLフィルタリングと日本語判定を追加して進める
      • CommonCrawl抽出（3800/9000完了，フィルタリングが完成したら終了）
  • これからやること
    • 検証・プレ環境への実装
    • データ補充
    • 手分けして処理を回す
    • MLベースフィルタリング LLM Rephrasing?（人手募集）

モデルチーム

  • 進捗
    • 標準コードのベースラインの動作確認・改善
      • ja_wikiの一部を使ったデータセットとトークナイザで実験可能に
      • マルチノードの動作確認が完了
      • 標準コードのパラメータ、モニタリング方法の確認
    • MoEなどを含むアーキテクチャの改善可能性の検討
      • Megatron-DeepSpeedでのMoEが動作することを確認
      • RoPEなどの改善デクニックを追加
      • huggingface transformers + DeepSpeedも間に合えば候補に入る可能性がある
    • その他事前学習の改善方法(カリキュラム学習など)の検討
  • これからやること
    • アーキテクチャの改善テクニックを本番で使える状態に仕上げる
      • MoEで実験して精度が改善するか確認する
      • HFへの重み変換スクリプトを作成し、動作確認する
    • 本番での学習を見据えた準備をする
      • コード、データ、トークナイザなど、必要なものをもれなくリストアップして確認する
      • コードの動作確認を行う
      • 学習が壊れることを想定して、モニタリング、モデルの保存、再開ができるように準備する
    • できれば、+αの工夫(学習方法か、トークナイザか、高速化か、チューニングか)を盛り込む)

サポートチーム

  • 進捗
    • 他チーム偵察

      • 使用しているデータセットと学習概要を報告

      • チームHatakeyama

        • スケジュール
          • 4/10~クリーニング開始
          • 4/15~学習開始、ファインチューニングの準備
        • 多くの種類のデータセットを使用

        HuggingFace Dataset化

        • cc100
        • oscar
        • shisa
        • japanese2010
        • NHK school news
        • J research courpus

        準備中

             CommonCrawl PDF
     Wikibooks

     PMC OA

        pes2o

        ChemRxiv

        The Stack v2

        OpenMathInstruct-ja/en

        • Branch-Train-Mergeを使用（モデルの構築はTransformerベース）
          • カリキュラム学習のようにドメインごとで徐々に行ってく形
          • 切換え方法は今後最適化
        • インストラクションデータをアプリを使用して収集（最低1000件程度作りたい）
  • これからやること
    • 追加調査
    • キャッチアップ資料の作成（Yokoi, Nonakaさん）
    • データベース整理（Matuiさん）

その他

コンペの評価指標について

(時間があったらで) @hiroaki shioya

  • プレ環境の制限が厳しくなったので、使い方を相談したい
    • チームで3ジョブまでらしいので、使う場合は毎回slack(tema_ozaki_11_privとか？)で連絡する形に?
    • 各サブチームの使用予定を聞きたい
      • slackに整理
  • データセットに関して
    • 実験用データに前処理後のデータも使ってみたいのだが可能か？
    • 現状の標準コードだと一つのjsonlファイルを処理して渡す形になっているが、本番用データはどういう形になっている想定か？
  • トークナイザに関する知見を募集
    • 単純に工夫した方がいいポイントがあれば知恵を増やしたい
    • どのデータを使うかと不可分なので、データチームと相談して決めたい
    • slackチャネルが多い、作業に必要な情報が流れてしまう．
    • 対策としてnotionにキャッチアップ用の資料を作る．
    • 特にslackの内容のキャッチアップさせるのが困難

第4回：週次報告

サブチームの状況

コレクションチーム

  • 進捗
    • 事前学習データセット
      • SlimPajamaDL完了、結合処理開始
        • ファイルサイズが巨大なため難航中
      • CulturaX JSONL化し、キュレーションチームへ引き渡し完了
      • Proof-Pile-2
        • DLはほぼ完了し、別環境へ格納中
    • 事後学習データセット
      • JDA PDF2Text
        • テキスト化完了
        • データの整形中
      • Voice2Text
        • Rimoでテキスト化済
  • これからやること
    • 4/22本番環境利用開始に向け、データセットの結合処理実施
    • 事後学習データセット関連準備
      • ディベート関連
        • テキスト化されたデータを確認し、検討
        • 校正作業に向け、だれでも作業できるように校正ルールを作成予定

キュレーションチーム

  • 進捗
    • ルールベースフィルタリング処理中
      • 分担してColab上でCulturaX前半&後半のフィルタリング処理中。
      • 今週4/18(木)中の完了を目標に進行中。
    • 重複削除処理中（今日終わる予定?）
    • Rephrasing
      • Colab環境を中心に検証中
        • A100（40GB）で動作可能（vllmを使うと速い）
  • これからやること
    • 重複削除メンバーのタスク振り
    • Rephrasing
      • 明日（4/16）以降，Colab Pro以上をお持ちの方にご協力お願いしたいです
      • 5人くらいあれば3日くらい

モデルチーム

  • 進捗
    • 標準コードベースと自前実装の2ラインの準備を進めています
      • 標準コードベース
        • LLamaやMoEを試みていますが、huggingfaceへの重み変換処理の実装が想定していたより難しく、まだ作業中です
          可能な限り改善テクニックを取り込んでphase1を迎えたいと思います
        • 本番環境での動作を担保するためにモニタリングやモデル保存周りの実装を確認しています
          可能な限り確認を行いますが、最終的には本番環境でもテストが必要です
        • 加えて、トークナイザーについても標準コードのロジックから上積みできないか検討しています
      • 自前実装
        • コードの作成が一旦完了し、動作確認を始めています
        • wandbとの連携など本番での使用を見据えた機能も実装できていますが、まだ調整が必要です
        • また、パラメータ設定まわりも検討しきれていないのでこれから調整が必要です
  • これからやること
    • 標準コードベースと自前実装の2ラインを本番で使用する想定の状態まで持っていきます
      その上で改善テクニックを可能な限り載せます
    • 本番環境が開始されたら最初の数日(2日程度？)は動作確認と速度の検証を行い、最終的にどの実装を採用するかを決めるのに使用します
    • phase1全体でGPUリソースをどう使うか計画を立てる必要があります
      • 本番環境前に運営から運用の留意点などをアナウンスできるか交渉。

サポートチーム

  • 進捗
  • これからやること
    • チーム体制の変更（今週のサポートチームMTG時に相談）
      • 各チームに担当をつけて直接要望を確認
    • キャッチアップ資料の更新
    • DBの更新

開発のマイルストーン

  • データ準備
    • 英語コーパス，数学コーパス，コードコーパスを準備
    • 日本語コーパスはLLMrephrasingと追加スクレイピングを使ってギリギリまで増加
  • モデル学習コード準備
    • MoEの確認をSannaiチームと実験
  • シングルGPUでの稼働確認、実績
    • 標準コードで確認
  • マルチノードでの稼働確認、実績
    • 標準コードで確認
  • うまくいきそうか計画の確信度
    • やりたいことはできてきている．

第5回：週次報告

サブチームの状況

コレクションチーム

キュレーションチーム

  • 進捗
  • これからやること
    • 事後学習データの準備

モデルチーム

  • 進捗
    • 事前学習に向けた準備をしていました
      • MoEを最後まで検討していましたが、本番で使用できる状態まで時間内に至れず、採用は見送りとする予定です。本番は標準コードベースに少し手を加えたllama2ベースでいく予定です。
      • トークナイザーやモデルを稼働させるのに必要な検証も同時に進めました
    • 本番環境での検証を行いました
      • シングルノードマルチGPUでの動作検証まで終えています
  • これからやること
    • 本番環境での事前学習を開始させます(4/24目処に終えたい)
      • マルチノード、サイズの大きいモデルでの検証
      • トークナイザーの作成
      • パラメータの最終決定
      • 使用する実験リソースの最終決定
    • 事前学習の残タスクを進めたい
      • 学習途中のcheckpointの出力を確認する仕組みの構築
    • 事後学習の準備を開始したい
      • 学習手法の調査
    • (少なくとも)モデルチームのメンバーのshioyaさん以外の人で環境を持っておく

サポートチーム

  • 進捗
    • 他チームの偵察は一時休止
      • 他チームは事後学習について今週から始動
      • hatakeyamaチームは自作データセットを作成中
        • mixtral 8x22b instを使用してQ&Aを自動生成
        • 人手により1000件程度のデータセットを作成
  • これからの流れ
    • コレクションチームの要望の確認
    • 自作する場合の人手

開発のマイルストーン

  • データ準備

    • 事前学習データの準備は完了

    • 事後学習データの作成準備中

  • モデル学習コード準備
    • llamaベースのモデルで実装完了
  • シングルGPUでの稼働確認、実績
    • 標準コードで確認
  • マルチノードでの稼働確認、実績
    • 標準コードで確認
  • うまくいきそうか計画の確信度
    • やりたいことはできてきている．

第6回：週次報告

サブチームの状況

事前学習チーム

事後学習手法チーム

ORPOの論文
ORPO: Monolithic Preference Optimization without Reference Model

  • これからやること
    • ORPOの本番環境での検証（checkpointを使用）
    • フルパラでのチューニングに対応したコードの実装

既存データ収集チーム

  • 進捗
  • これからやること
    • （続）wikihowQAとchat-bot-arena-jaのキュレーション
    • 他データセットの調査
    • 事前学習に向けた準備をしていました
      • MoEを最後まで検討していましたが、本番で使用できる状態まで時間内に至れず、採用は見送りとする予定です。本番は標準コードベースに少し手を加えたllama2ベースでいく予定です。
      • トークナイザーやモデルを稼働させるのに必要な検証も同時に進めました
    • 本番環境での検証を行いました
      • シングルノードマルチGPUでの動作検証まで終えています

ディベートデータチーム

開発のマイルストーン

  • データ準備

    • 事前学習データの準備は完了

    • 事後学習データの作成準備中

  • モデル学習コード準備
    • llamaベースのモデルで実装完了
  • シングルGPUでの稼働確認、実績
    • 標準コードで確認
  • マルチノードでの稼働確認、実績
    • 標準コードで確認
  • うまくいきそうか計画の確信度
    • やりたいことはできてきている．

第7回：週次報告

サブチームの状況

事前学習チーム

  • 進捗
    • 事前学習
    • 進捗
      • 5/8に日本語中心のStage1から英語多めのStage2への切り替えが無事に完了
        • 懸念されていたスパイクは切り替え後の数iterationで起こっただけですぐに収まった
        • Stage1終了時点のモデルでも英語は割と普通に話せており、あまり苦労はなかったのかもしれない
        • Stage2以降のモデルは何回か出力を確認しているが、日本語は普通に話しているので少なくとも日本語スキルの忘却はなさそう
      • ストレージ容量が足りなくて一度学習がクラッシュしたものの、それ以降は問題なく進行中
      • 順調にいけばStage2の終了は16日の午前中
        • 15日の夜までにStage3のコーパスを渡していただけると助かります
    • これからやること

      • Stage3、4への移行

        コーパス設計図 (2).jpg

事後学習手法チーム

  • 進捗

    • 進捗

      • プロンプトの統一

      image.png

      →JMT Benchは違う説が出てきており現在(リーダー運営間で？)確認と調整中

      • SFT（@Anonymous)

        • stage2-iter40000に対してWikiHowとHatchi-Alpacaを用いてSFTを実施
        • 繰り返しの発生などがみられる
          • Elyza task 100を解いた結果 ‣
          • 事前学習でも同様の傾向があり、2~3文以上意味のある文章を話すのが難しく、以降は自身が話した内容を繰り返すことが多い

      • DPO(@Anonymous)

        • preferenceデータ(chatbot-arenaのrejectにsftを施したモデルの出力)を用いてDPOの検証中
        • 学習時間は23kに対して2時間程度(モデルのUP含む)
        • 学習が破綻（意味不明な生成）してしまっている
        • ハイパラを調整して実験中
          • 調整中のハイパラ：学習率、beta（どのくらい参照モデルを無視するかの割合）
          • 学習Log

        DPO参考資料：小話その1~4

        Akifumi Wachi

      • ORPO(@Anonymous)

        • 実行速度が遅い問題は(原理は不明だが)Flash Attentionを外すことでsftの1.5倍程度の実行時間に収まるようになった
        • 学習が安定しない

      • テスト用スクリプトの作成(@Anonymous)

        • llm-jp evalでは評価を実施 (https://wandb.ai/weblab-geniac-leaderboard/leaderboard から結果を見ることができる。このチームはweblab-geniac6)
          • 回答のルールも守って答えられているものもあるが、問題文を繰り返したり、テンプレートの###を余分に生成して余計な回答を続けたりしている
          • 現状の内容はトークナイザーの挙動が評価時に違っているようなので参考程度
        • 回答内容の評価まで手が回ってない
          • 似たようなサイズのモデルとのスコア比較
          • 回答のクセの分析

    • これからやること

      • SFT+DPO or ORPOの比較
      • どの手法を採用するのか決定

既存データ収集チーム

  • 進捗
  • WikiHowQAのキュレーション（完了）
  • chatbot-arena-jaのキュレーション（進行中）
    • 29,204→半分くらい？の見込み
    • 質問文のアノテーション
      • 意味不明なQAや日本文化に合わないQAを削除
    • chosen（良い解答）をより高品質なLLMで生成
  • これからやること
    • （続）chatbot-arena-jaのキュレーション
    • Hachi-Alpacaのキュレーション（v1.0_cleaned, 28.9k件）
      • アイデア検討中
        • Open-QA（MT-Bench型）とClosed-QA（llm-jp-eval型）の問題に分ける
          • 例）単語で回答している問題はClosed-QA
        • Open-QAはLLMで回答生成
        • Closed-QAはllm-jp-eval形式の質問形式に寄せる
          • 例）「それ以外には何も含めないことを厳守してください。」という命令を追加

ディベートデータチーム

  • 進捗
    • 進捗

      • ディベート文字起こしデータ作成

      • ディベートデータ作成方法を抜本的に変更

        {
    "議題": "日本はすべての原子力発電を代替発電に切り替えるべきである",
    "肯定側第一立論": "国民を核の危険から守る原子力発電所が事故を起こした場合、そのダメージははかりしれません。資料を引用します。93年発行、反原発新聞編集者西尾漠著『脱！プルトニウム社会』より引用です．『もし大事故が起これば、最終的には、少なくとも数千人を上回る早期の死者、数十万人規模の被爆者をもたらし、その後も長寿命放射能による汚染の被害が続くであろう』もう一つ資料を引用します。先ほどの『原発が止まった日』より引用です。『どんなに浴びた線量が低くても、将来ガンになる危険は高くなる。』。このように、発電所が事故を起こしたときに出たり、核廃棄物から漏れたりする放射能は呼吸や食べ物を通じて私たちを蝕んでいきます。さらに放射能により遺伝子につけられた傷は子孫にまで悪影響を与えてしまうのです。この様な危険や恐怖から日本国民やその子孫を守ることは非常に重要です。",
	  "肯定側第二立論": "",
    "肯定側第一反駁": "",
    "肯定側第二反駁": "",
    "否定側第一立論": "1点目、産業の衰退です。電力供給が安定しないことは国にとって致命的で、仮に昼間に18 時間の停電が発生すると、これは年間総労働時間の1％で、単純計算で GDP の1％、つまり5兆円もの損害になってしまいます。実際に停電がこの程度ですむはずがないため、毎年数十兆円規模の打撃になります。深刻性2点目、国民健康への影響です。国民の健康への影響です。停電の発生は医療での治療を妨害し患者の健康を著しく損ねます。また夏の昼間の停電の多発により全てのクーラーが停止し、高齢者の熱射病、日射病が増えます。96年現在、65歳以上の一人暮らしをしている老人世帯数は 236 万世帯です。仮に日本の家庭の 1％で停電が起きたとしたら、2 万人もの老人が衰弱死の危険にさらされてしまいます。加えて冷蔵、冷凍設備も停止するため食品衛生上の信頼度も低下します。では、デメリットの 2点目です。デメリットの2点目は膨大なコスト、膨大なコストです。発生過程です。発生過程は 1点。デメリット１、発生過程でも述べたように原発を廃止したらその 7000 万キロワット分の電力を太陽光、水力発電で補わなければなりませんが、その場合の 1キロワットあたりの発電所建設費用は太陽光発電では、証拠資料を引用すると電力中央研究所編、『2匹目のデンキウナギ』によると 120万円、1キロあたり約120万円です。よって 7000 万キロワット分の発電所を建設するには 120 万掻ける7000 万、つまり 84兆円です。84兆円の費用がかかってしまいます。",
    "否定側第二立論": "",
    "否定側第一反駁": "",
    "否定側第二反駁": ""
}
        • 議題
          • インプットの素
        • 肯定・否定の第一主張
          • アウトプットの素

      • 上記２点のみを集めるように変更

      • 大きく作業負担が減り，各人8つのjsonを最終的に作る．

        • 5/17 デッドライン

      • 合計で195(暫定)＊2のQAデータが作成される予定

    • これからやること
      • 17日までに提出
      • すぐにQAセット化する
        • jmtbenchの入力を意識した形へQを修正
    • アナウンス
      • 事前学習データにもディベートデータを使う予定であったが，スケジュールとデータ品質の観点から事後学習に限ることとする．

その他

  • checkpointの評価者募集
    • 似たようなモデルとのベンチマーク比較をする
    • 出力結果からの回答分析

開発のマイルストーン

  • データ準備

    • 事前学習データの準備は完了

    • 事後学習データの作成準備中

  • モデル学習コード準備
    • llamaベースのモデルで実装完了
  • シングルGPUでの稼働確認、実績
    • 標準コードで確認
  • マルチノードでの稼働確認、実績
    • 標準コードで確認
  • うまくいきそうか計画の確信度
    • やりたいことはできてきている．

第8回：週次報告

サブチームの状況

事前学習チーム

  • 進捗

    • 事前学習

      コーパス設計図 (2).jpg

    • 進捗

      • Stage3が5/19に完了し、現在はStage4が進行中
      • 今朝クラッシュしてしまった影響で、完了予定は5/21の22:00~24:00ごろ予定

    • これからやること

      • Stage4の完遂

事後学習手法チーム

  • 進捗
    • 進捗
      • DPO
        • 繰り返しの改善傾向が確認できた。（β：0.5 学習率：1e-6）
        • 1epochのみだが、エポック数を増やして検証を行う
          • llm-jpだと30epochくらい
      • ORPO
        • 繰り返しの改善は行えているがDPOほどの精度が出ていない
        • 現在は1epochの学習しか行えていないのでエポック数を増やして検証を行う（ORPOは複数エポックが前提らしい）
      • スペシャルトークンの取り扱いなどについてのMTG
        • ハドルレベルで．．．
      • 評価 @hiroaki shioya
        • llm-jp-evalのスコアが1.51→2.15に改善
          • キュレーションチームに用意いただいた対策データの影響
        • jmt-benchは回答のみ生成、スコア算出は評価コードの問題点解消や評価用APIキーの停止の影響でこれから
    • これからやること
      • 共有用にコードの修正
      • マルチノードに対応したコードの修正
      • jmt-benchのスコア算出(事前学習終了後に即sftをして算出予定、5/22早朝？)

既存データ収集チーム

  • 進捗

  • 進捗

    • karakuri（GENIAC-Team-Ozaki/karakuri-lm-8x7b-chat-v0.1-awq）での回答生成
      • chatbot-arena-ja-karakuri-lm-8x7b-chat-v0.1-awq（12474件）
        • chosenデータがオリジナル（calm2-7b-chat）よりも精度up
      • WikiHowNFQA-ja_cleaned_newans（6545件）
        • 自動翻訳＋人手キュレーションした文章よりもkarakuriの出力の方が良さそうだった…
      • GENIAC-Team-Ozaki/Hachi-Alpaca_newans（27805件）
        • ベースモデルが同じなので、精度はあまり変わっていないかもしれない
        • 単語回答は少なくなっていそう
          • 単語回答をするように指示されたときのみ、単語回答にすることでllm-jp-evalと生成系タスクを両取りしたい
    • llm-jp-eval対策のデータ作成（進行中）
      • llm-ja-train
      • 他データセット転用（＋手動）による類題作成
      • 各質問形式につき100問（9割完了）
      • shioyaさんにSFTで検証していただいた結果、効果ありそう
      • 回答形式は概ね守れるようになっているが、質問を理解できているかは怪しい
      • 問題の考え方を学ばせる必要がある？
    • 論理的推論能力向上のためのデータ作成

      • 考えて質問に回答できるようになるために、Chain-of-thought形式のデータ作成を行う

      • databricks/databricks-dolly-15k（約15000件）のCoT回答をkarakuriで生成中

        普通のプロンプトの場合

        Input:  以下は、タスクを説明する指示と、文脈のある入力の組み合わせです。要求を適切に満たす応答を書きなさい。

### 指示
アリスの両親には3人の娘がいる：エイミー、ジェシー、そして三女の名前は？

### 応答

Output:  三女の名前はアリスです。</s>

        CoT形式にした場合（ステップバイステップで考えさせる）

        Input:  以下は、タスクを説明する指示と、文脈のある入力の組み合わせです。要求を適切に満たす応答を書きなさい。
ステップバイステップで考え、論理的な説明をもとに答えを導いてください。回答例を見たことについては言及しないでください。

### 指示
アリスの両親には3人の娘がいる：エイミー、ジェシー、そして三女の名前は？

### 回答例
三女の名前はアリス

### 応答

Output:  三女の名前はアリスです。

指示に従って、論理的に考えると以下の通りです。

1. 指示には3人の娘がいるとあるため、エイミーとジェシーはアリスの姉妹である。
2. アリスの両親とあるため、エイミーとジェシーもアリスと同じ両親の子供である。
3. アリスの名前が最後に出てくるため、三女の名前がアリスであると推測される。</s>

  • これからやること

    • （間に合えば）llm-jp-eval対策のデータについてもCoT回答を生成したい

ディベートデータチーム

  • 進捗
    • 進捗

      • 文字起こしが概ね完了

      • 例

        {
    "議題": "日本は有罪判決を受けた者に対する電子監視制度を導入すべきである",
    "肯定側第一立論": "日本は有罪判決を受けた者に対する電子監視制度を導入すべきです。犯罪白書2007によると、全犯罪者の約30%が再犯者で、再犯による犯罪は全体の約60%を占めています。特に性犯罪の再犯率が高く、法務省2010によれば、性犯罪者のうち10年以内に再犯を犯した者の割合は16%、5年以内では17%です。性犯罪者は計画的に犯行を行い、再犯者の89.4%が計画的な行動を取っていました（犯罪白書2015）。再犯を防ぐためには、性犯罪者に対して電子監視制度を導入し、監視下で生活させることが有効です。電子監視により、対象者に「見られている」という心理的効果を与え、再犯の抑止に繋がります。フロリダ州の研究によれば、電子監視を受けた性犯罪者の再犯率は大幅に減少しました（中央日報2008）。電子監視の導入により、性犯罪者が再犯を防ぎ、社会に適応するための環境を整えることが必要です。",
    "肯定側第二立論": "",
    "肯定側第一反駁": "",
    "肯定側第二反駁": "",
    "否定側第一立論": "前科者の社会復帰には就労支援が不可欠であり、国はそのための支援を行っています。就労支援の結果、刑務所出所者の再犯率は低下し、就労状況も改善されています（総務省2014、法務省2023）。一方、GPS監視制度の導入は、対象者が周囲から劣位に見られ、心理的圧迫感から引きこもりになる可能性があります（甘利2017、弁護士ドットコム2010）。これにより、社会復帰が妨げられ、再犯リスクが高まる恐れがあります。従って、電子監視制度の導入は適切ではなく、前科者の社会復帰を支援する政策を継続すべきです。",
    "否定側第二立論": "",
    "否定側第一反駁": "",
    "否定側第二反駁": ""
}

      • 少し遅れて今日中に提出される分もあり．

      • 高品質と考えられ，追加される分があるので，協力者求．

        • 1,2動画ほど振りたい．．．このあとMTGできれば．．．
    • これからやること
      • 文字起こしデータから学習データに成形
      • 1ファイルから2セットのQAができる予定
      • どういったQにするかを検討中

        • シンプルなQA

          Q:「日本は有罪判決を受けた者に対する電子監視制度を導入すべきである」という主張をより強固にしてください．

Q:あなたは以下の主張を肯定しています．

「日本は有罪判決を受けた者に対する電子監視制度を導入すべきである」

その立場からスピーチを行って下さい．

Q:「日本は有罪判決を受けた者に対する電子監視制度を導入すべきである」に肯定的な立場をとって，メリットを詳しく説明してください．

        • LLMを使うのもあり．

        • jmtbenchを意識してマルチターンにする

      • 追加分を作業

その他

開発のマイルストーン

  • データ準備

    • 事前学習データの準備は完了

    • 事後学習データの作成準備中

  • モデル学習コード準備
    • llamaベースのモデルで実装完了
  • シングルGPUでの稼働確認、実績
    • 標準コードで確認
  • マルチノードでの稼働確認、実績
    • 標準コードで確認
  • うまくいきそうか計画の確信度
    • やりたいことはできてきている．

この成果は、NEDO（国立研究開発法人新エネルギー・産業技術総合開発機構）の助成事業「ポスト５Ｇ情報通信システム基盤強化研究開発事業」（JPNP20017）の結果得られたものです。

松尾研LLMコミュニティへのご案内

Slack参加リンクを始めとして、GENIACの概要やLLMコミュニティ主催各イベント等、関連リンクはこちらにまとめられております。
ぜひご覧ください！！
https://linktr.ee/matsuolab_community

東大松尾・岩澤研究室 | LLM開発 プロジェクト[GENIAC]
東大松尾・岩澤研究室 | LLM開発 プロジェクト[GENIAC]

東京大学 松尾・岩澤研究室が運営する松尾研LLMコミュニティのLLM開発プロジェクト[GENIAC] の開発記録、情報発信になります。 各種リンクはこちら linktr.ee/matsuolab_community

Discussion