前回記事はこちらから
→ https://qiita.com/uaokit0905/items/40b8b6b1203c921fe07b
【機材協力について】
本記事（および本連載プロジェクト）は、株式会社ハイレゾ様よりGPUクラウドサービス「GPUSOROBAN」の計算資源（NVIDIA A100 80GB）をご提供いただき、開発・検証を行っています。
0. はじめに
こんにちは！東京大学文科3類2年で、東大AI研究会 代表の青木です。
私たち東大AI研究会は東大で活動するサークルで、1年かけて0からGPT型モデルを開発するために、毎週水曜日に勉強会を開催しています。勉強会では初心者でも理解しやすいスライドと、充実したカリキュラムを用いて開発を進めています。
株式会社ハイレゾ様は自社でGPUデータセンターを運営し「GPUSOROBAN」 というGPUのクラウドサービスを提供する会社です。高性能GPUは非常に高価で、私たちのような学生サークルが簡単に手を出せるような代物ではありません。GPUSOROBANではクラウド上で必要な期間・量だけGPUを借りることができるため、初期投資を抑えてGPUを活用し開発を行うことができます。
現在株式会社ハイレゾ様の協力のもと、25億パラメーターのGPT型モデルの実装と訓練を行っています。その名もSGT（Scratch Generative Transformer）プロジェクト！前回に引き続き、SGTプロジェクトの様子をお伝えします。
1. チームを組むのは難しい
つい先日、大学の研修で訪れたベトナムから帰ってきました。四月にプロジェクトが始まったかと思えば、もう九月になってしまいました。あっという間ですが、十月には大学の授業が春学期より増えて、留学準備にも時間を割かなければならないので、このプロジェクトに割ける時間も減ってしまいます。したがって、この九月が実質的なタイムリミットになります。
私は夏休みが終わるギリギリにならないと宿題に手がつかないタイプでした。締め切りが近づいてこないと、マイペースで進めてしまう癖があります。今回も例のごとく、締め切りを意識して初めて焦り始める、というわけです。
さすがに今のままではまずいと、チームを組むことにしました。先輩からはずっと「チームを組め」と言われてきたのですが、私はチーム制のコンペなどに出たことは無く、チームで何かをやってきた経験がほとんどなかったので、いまいち「チームを組む」という行為にピンと来ていませんでした。。。
チームを組まなかった他の原因として、何をすればいいのか分からないまま進めようとしていた、というのがあります。私の中では、私がチームメンバーを招集するのだから、私がリーダーになり、私が他の人に仕事を振らなければならない、という考えでした。一方で今回のプロジェクトはかなり行き当たりばったりなもので、暗中模索しながら進めていたので、何をやるべきなのかもよくわかっていない状態でした。意識の問題と、進め方の問題が嫌な形でマッチして、人に協力を仰げない状態でした。
あと遠慮のせいもありますね。私は遠慮しがちなので、シンプルに人に助けを求めるのが苦手というのはあります。
2. YUTECT様への技術相談
なんと、ハイレゾ様のご厚意で、株式会社YUTECTの田中様と門脇様に、直接技術的なご相談に乗っていただけることになりました。（株式会社YUTECT:HPhttps://yutect.com/ ）
株式会社YUTECTは、プロダクト提供に加え、建築×AIを軸にしたAIモデル開発・画像生成・R&D共同研究・PoCまで幅広く受け持つAI開発・コンサルティングの企業です。さらに、建築業界で使われる3DモデリングソフトウェアのREVITにおいて、AIが設計を支援するRevit助人を開発しています。
今回の目標は、とにかく現状の問題点を洗い出して、暗中模索の状況を打破することです。以下の点について質問しました。
・検証方法はどのように決めるのが良いか
・事後学習の方法はどのように決めればいいのか
・何が何だか分からないままでAIを使って開発してもいいのか
・事前学習モデルの性能不足の可能性はあるのか
・事後学習で強化学習を組み込む場合はどうやって進めていくのか
ハイレゾ様経由でこれらの事前質問を送付していただき、YUTECT様からの回答を踏まえて、相談当日はさらに内容面を深掘りしました。相談に乗ってもらう中で明らかになった現状の大きな問題点を整理します。
①実験の進め方が論理的ではない
私は「実験の進め方」が良くなく、現状の問題点や仮説を立てて実証するような進め方ができていなかったのです。そりゃ、実験なんてしたことない文系大学生なので当然っちゃ当然ですが。
「GPTモデルをフルスクラッチで学習して、G検定に合格させる」なんてプロジェクトを他にやっている人はいません。したがって、このプロジェクトは、既存の方法をそのままなぞるだけでは不十分で、どんなやり方で進めればうまくいくのか、実験を繰り返す必要があります。
上手くいったときに何が実証されて、うまくいかなかったときに何が原因なのか分かるような実験方法で進めていく必要があります。
②プロジェクトのパイプラインができていない
タイムリミットまでにプロジェクト完了の目途を立てるには、ちゃんとしたパイプラインを組み立てる必要があります。おそらくプロジェクトを進める上で、このような進行のパイプラインを組み立てるのははじめに時間をかけてやることですが、それすら全然できていなかったのですね。
私は前述のとおり、このような開発はしたことありませんし、それどころか、コンペティションにすら出たことがありません。当然、プロジェクトの進め方なんて知りません。「G検定に合格させる」という曖昧なゴールだけ掲げている状態です。本当に暗中模索です。
まずは暗闇を進むのを止めて、進行方向と進み方をはっきり決める必要がありますね。
YUTECTの田中様と門脇様に相談したことで、この辺の、見ないふりをしていた問題点がかなりはっきりしてきました。
3. 実験の進め方
ゴールから逆算していく形でパイプラインを組み立てていきます。
そもそもゴールとは具体的に何なのか、というところから始めます。
今まで「G検定に合格する」という曖昧な目標でしたが、G検定ベンチマークを独自に作り、その正答率を7割にのせることを目標とします。
（G検定ベンチマークは、先輩が作って販売用に公開していた問題の使用許可をもらい、準備しました。参考リンク→https://www.udemy.com/course/gkentei-moshi/?couponCode=V3JPLETSLEARN)
もし7割に到達しなかった場合は、「なぜ到達しなったのか」を明らかにし、さらに全体を振り返って、「プロジェクトの進め方は適切だったのか」「次に他のプロジェクトを行う場合はどのように進めていくべきか」を記録に残して、東大AI研究会全体で学びが残るようにします。
ゴールが決まったので、ここからゴールに向けて検証を進めていきます。
まずはベースモデルでのG検定ベンチマークの正答率を見てみます。
0shot、選択肢の尤度推定、位置バイアスなしの状態で、正答率は20%(29/145)です。
これまでの実験から、事前学習＋CPT＋Instruction tuningを行ってもG検定ベンチマークのに対するこの正答率が有意に向上するわけではないことは分かっています。そのため、事前学習、CPT、Instruction tuningのどこが学習のボトルネックになっているのかを見ていきます。
まずはInstruction tuningの段階を疑っていきます。今まで、単純にG検定likeの問題を1100問程度、そのまま学習させていました。そのやり方では性能向上が見られなかったので、今度はモデルにCoT形式で出力させるようにします。
CoT とは Chain of Thought の略で、AIの思考過程を出力させる手法です。
G検定問題と選択肢と回答に加えて、回答に至るまでの解説文を学習させることで、モデルが自分で問題を解く際にも、解説文のようなものを出力するようになります。この解説文が思考過程の代わりになり、正答率の向上が期待できるのですが、私も理由はよくわからないので、気になる方は調べてみてください。
CoTの形式をさせた結果は以下のようになります。
まずは回答の形式から確認します。
あるAIモデルの学習に用いるため、複数の提供元から取得したデータに対して、除外や変換などの加工を行った。後日、特定の予測結果について、どのデータがどのような経緯で学習に使用されたかを確認できるようにするための対応として、最も適切なものを1つ選べ。
A. 取得元・取得条件、加工内容、利用目的をデータセットの版ごとに記録し、更新履歴と関連付ける
B. 取得元・取得条件、加工内容、利用目的をデータセットの版ごとに記録し、利用時の運用ログと関連付ける
C. 取得元・取得条件、加工内容、利用目的をモデルの版ごとに記録し、評価結果と関連付ける
D. 取得元・取得条件、加工内容、利用目的をデータセットの版ごとに記録し、モデルの版と関連付ける
というプロンプトを打ち込みます。
学習前の回答はこちら。
やタグを付けて保存する
このように、データセットごとに異なる記録と加工を行うことで、モデルの再現性と信頼性を高め、過去のデータとの比較や改善点の抽出に活用できる。
CoT形式での学習後（1epoch）の回答はこちら。
データセットの版ごとに記録し、更新履歴と関連付けることで、取得元・取得条件、加工内容、利用目的が一貫性のあるデータセットを作成できる。答え：A
それらしい解答になっています。それでは正答率の方に変化はあったのでしょうか。
epoch数はCoT形式のデータセットの学習epoch数を示しています。
1epoch目：27.6%
2epoch目：26.2%
3epoch目：27.6%
4epoch目：26.2%
5epoch目：28.3%
あてずっぽうで回答を選んだ場合と有意な差はありません。
つまり、解答形式は学習出来ましたが、それが正答率向上に結び付きませんでした。
なお、2epochからは、学習で使用した問題をプロンプトで与えると、解説部分を学習データと一言一句同じに返答する丸暗記が見られたり、問題文でない普通のプロンプトに対しても「答え：A」というような記号を付けて返す現象が見られました。
ただし、これだけではCoTの意味が無かった、と言い切ることはできません、
そもそも、モデルが「4択問題」の形式を理解していない可能性があります。
知識はあっても、それを適切に取り出せていないかもしれません。
そこで、簡単な問題で4択問題への適応力を確かめることにしました。
ベースモデルの知識でも回答可能だと期待できる簡単な4択問題を用意し、その問題に正解できるのかを検証します。
もし簡単な4択問題でも間違ってしまったら、それは知識よりも形式の部分に問題があるということになります。逆に正解出来たら、4択問題を解く能力自体は問題なく、モデルの知識不足が原因になります。こちらの結果は次回の記事で公開します。
さて、もし”モデルの知識不足”が原因だったとして、さらに細かく見てみると、CPTによる知識獲得に失敗している場合と、CPTはうまくいっているけれども、事前学習モデルがCPTで補えないほどの知識不足である場合の2つの可能性があります。
この検証も同時並行で進めていきます。検証にはQwen3-0.6Bを使用します。
Qwen3-0.6BのG検定ベンチマークの正答率は約59%（0shot、選択肢の尤度推定、位置バイアスなし）。
これにCPTを加えて、G検定ベンチマークの正答率が有意に上昇すれば、CPTでの知識獲得に成功しており、CPTデータセットに問題はないことが分かります。正答率に変化がない、または有意に降下する場合は、CPTデータセットに問題がある可能性があります。
こちらについても、次回の記事で結果を公開します。
4．チーム体制に変えた結果
ここまで新しい実験の過程を述べましたが、チームに変えたことで、実験のスピードがとてつもない速さになっています。感動的です。一部これまでの検証と似たようなことも改めてやってみたのですが、私が2か月くらいでやってきた内容が2週間程度で終わってしまいました。チームって、すごすぎる。。。
私はチーム全体のタスク管理を担っています。先輩や同期に助けられ、ちょっとずつコツを掴んできました。以下に、現在のチーム体制で意識していることをまとめます。
・タスク管理者の自分がタスクを抱え込みすぎないようにする。
私が皆さんにタスクの指示を出しているのですが、私の指示が曖昧だったり、必要な道具がそろっていなかったりして、チームメンバーから私に質問が投げかけられることが多々あります。そのほとんどは私が責任をもって判断しなければならない質問です。ここで、私が他のタスクで手一杯になってしまうと、本来私がやるべき”判断”に時間を割くことができなくなってしまいます。”判断”自体をタスク管理者の重要なタスクと捉え、他の部分でチームメンバーに助けてもらっています。なお、もちろん判断のときもチームメンバーに助けてもらっています。
・成果物（情報）の一元管理
これは先輩から助言いただいたものです。みんながばらばらで作業しやすくなるように、成果物は一つの場所で管理するようにします。このプロジェクトではNotionを使っていて、すべての成果物がそのNotionから見られるようにします。
基本作業は並列で行えるようにしているのですが、他の人の成果物を参照しなければならないタスクもあります。その際に、いちいちその人に連絡して返事が返ってくるのを待っていては無駄な待機時間が生まれてしまいます。成果物（情報）の一元管理は、コミュニケーションコストと待機時間を減らすのに役立っています。
・ミーティングを定期的に行い、できるだけ短く終わらせる。
ミーティングを定期的に行い、成果報告と方針の相談を行います。毎回のミーティングで新しいタスクが来まり、次のミーティングが締め切りになるので、全体の進捗を管理しやすくなります。また、仲のいいメンバーでミーティングすると、雑談が入ったりして長くなりがちなので、集中すべき時に集中できるように、会議中の脱線に気を付けています。
チームに変えて、新しいことをたくさん学びましたし、チームメンバーが何度も助けてくれるので、進度も比べ物にならないくらい早くなりました。まだチームリーダーとしては未熟なので、これからもチーム運営の勉強をしていきます。
5. YUTECT様へのお礼
ご相談に乗っていただいたことで、技術的にも意識的にも大きな気づきがありました。
この場をお借りして、株式会社YUTECTの田中様と門脇様に、改めて感謝申し上げます。誠にありがとうございました。
関連リンク
株式会社ハイレゾ公式サイト：
https://highreso.jp/
クラウドサービス「GPUSOROBAN」：
https://soroban.highreso.jp/
株式会社YUTECT公式サイト：
https://yutect.com/