GPTのトレーニングパイプラインが整理された「State of GPT」
大嶋悠司氏（以下、大嶋）：「Keynotesだけじゃない！ 深掘りセッションズ」ということで、キーノートで全体の地図を与えられたわけです。じゃあその地図の中で、それぞれどこにどういう話をしているかという深掘りセッションズをいくつか紹介できればなと思います。
まず、Foundation modelsについてです。もしかしたらみなさん、もう見ているかもしれませんが、このセッションはマジでみんな見たほうがいいと私は思っています。「State of GPT」というタイトルなのですが、OpenAIのAKさん（Andrej Karpathy氏）が発表してくれた内容で、GPTについてすごく詳しく話してくれているんですね。
GPTだけじゃなくてLLMと言ってもいいかな？ とにかく、トレーニングパイプラインの話をしてくれています。ここまで整理されたGPTのトレーニングパイプラインを私は初めて見たので、頭を整理する上ですごく良い発表だったなと思っています。
トレーニングパイプラインがあって、それぞれのモデルが生まれるので、自分が見ているモデルがこのフェーズのどこに相当するモデルなのかを考えながら見ると、非常に整理できるし、これも地図だと思っています。
最初が事前学習言語モデルで、GPTのベースモデル、「GPT3 davinci」とか「LLaMA」とかがここに相当します。大規模な言語資源でランゲージモデルを事前学習したようなものですね。こいつはアシスタントではありません。
ランゲージモデルなので、最初に言語が与えられたらその先を推定するだけのモデルですね。最近サイバーエージェントさんが出した「CALM（OpenCALM）」も、ここの事前学習言語モデルに相当します。このモデルは、ChatGPTみたいなアシスタントにはならないものです。
それをQAの形式になっている少量かつ高品質のデータでチューニングしたものが、SFTモデルです。ここになると、少しアシスタントっぽい感じになります。これは、「Vicuna-13B」などのモデルに相当すると説明されています。
これだと、まあ確かに、アシスタントみたいな振る舞いはしてくれるけれど、ChatGPTはさらにRLHF（Reinforcement learning from human feedback）ということをしているよと説明してくれています。
知っている限り、実際にここまでできているのはChatGPTとClaudeだけだと言っていますが、生成された回答を人手でランキング付けして、それを強化学習に使って、人間が思うより良い回答を学習するという流れになりますね。
そういうことで、よりアシスタントとして優秀になるという話になります。
なぜRLHFが必要なのか？
これ、ちょっとおもしろかったので挟んだのですが、「なんでRLHFが必要なんですか？」という質問に対して、（回答は）「いい感じに動くからです」。エキサイティングな理由ではないけれど、それをすると人がいいと思う回答が出るからでしかないと言っています。
もし潜在的な理由を説明できるとしたら、「いい俳句を作りなさい」と言うよりも、「どっちの俳句のほうが良さそうですか？」という質問のほうが、人間にとっては簡単ですよねということです。
生成よりも比較のほうが簡単というのがRLHFがよく動く潜在的な理由かもね、みたいなことも別で話してくれているので、非常に技術的に深いセッションだったなと（思います）。
RLHFによる悪影響
ほかにおもしろかったのは、RLHFによる悪影響もあるという話ですね。ベースモデルだと 、次の単語を予想する時に、けっこうエントロピーが高く、言語を満遍なく推定するのですが、RLHFを挟むと非常にピーキーな推定をするようになります。
（スライドを示して）例えばここの「If you are referring」の時の「are」の予想ですが、ほかにも可能性がなくはないはずなのに、「are」が99.9パーセントになっていて、かなりピーキーなモデルになると話されています。
ということは、エンベディングモデルにはRLHFをしたモデルは向かないのかな？ と想像をしたり、なかなかおもしろい発表だったと思います。
LLM使用のベストプラクティス
あとは、LLM使用のベストプラクティスについても話してくれていました。「Chain of Thought」、「Self-consistency」、「ASK for Reflection」、「Tree of Thought」など、「Expertとして振る舞ってください」みたいなことを言うと質が上がるよねみたいな。
そういうよくあるベストプラクティスをまとめて話してくれているし、メタファーを含めて話してくれるので、すごくわかりやすいセッションだったなと思います。
最後に、検索の拡張みたいなものも話されていました。これについては後の発表で詳しく話しますが、LLMに検索による拡張を付けるのはすごくいいよねという話ですね。
Vector searchやHybrid searchは当たり前になってくる
それに関連して、Groundingの部分になりますが、個人的に、これはLLMの本質的な使い方における拡張だと思っています。
先ほども申し上げたとおり、Groundingというものが、ある情報に基づいて生成する上で証拠となる情報を取ってこないといけないというところで、Vector searchを使うというのが、なんとなく今の技術的な流れになっているかなと思います。
Vector searchについてのセッションはElasticsearchがやってくれたのですが、Vector searchという技術について話した後、Vector searchを使ってChatGPTを拡張すると、こんなにいいことがあるよという話をしてくれたので、Groundingについて興味がある人は、この発表を見るとおもしろいと思います。
Embeddingというものが、こういう概念みたいなものを何次元かの空間に落とし込みます。リアルな鹿、リアルなカートゥーン、イラスト、鳥なのか哺乳類なのかみたいなのにマッピングされています。
こういう鹿のイラストっぽいやつが与えられた時に、その周辺の概念みたいなものも取ってくることができるのがVector searchです。
このVector searchがなぜ今流行っているかというと、別にVector searchはそんなに新しい技術ではありませんが、LLMを使うとEmbeddingがすごくうまくいくので、LLMと組み合わせると非常に効果的だよねということを説明してくれています。
Vector searchは、今まで見つけられなかったものが見つけられるようになる技術ではありますが、キーワードマッチのほうが完全に一致するものを見つけることに優れているので、トラディショナルなサーチとVector searchを合わせたHybrid searchみたいなものがすごく重要になってくるよねという話もしてくれています。
Vector searchやHybrid searchはけっこう当たり前になりつつあるなと思っています。
Elasticsearchは当然のこと、Azureの「Cognitive Search」とか「Azure Cosmos DB」とか「Vertex AI」とか「Pinecone」「Qdrant」。
いろいろな方法でこれは実現できるので、今後当たり前の技術になるんだろうなという気がしています。
「Build and maintain your company Copilot with Azure ML and GPT-4」もおすすめ
次の、MetapromptとResponse Filteringについての発表でおすすめなのがこれですね。
「Build and maintain your company Copilot with Azure ML and GPT-4」。これはけっこうデモベースですごくおもしろい発表なので、聞くと楽しいと思います。
先ほどみたいに、Retrieval Augmented Generationみたいなものをすると、いい感じのCopilotが作れるよという話から始まるんですよね。
「実際にCopilotを設計する時には、これぐらいのパイプラインを組まなきゃいけないんや」と言っていて、「クライアントがチャットに質問した時に、内部でプロダクトIDを入れて、プロダクトをサーチして、その情報を使ってLLMに問い合わせつつ、リプライを生成するんや、複雑なフローがあるんや」という話をしてくれるわけです。
PromptFlowで実現できるよというのがその話の流れになるわけですね。PromptFlowは、基本的にLangChainを想像してもらえればいいので、わかるかなと思いますが、インプットがあって、if文みたいなものがあって、並列でLLMと合わせた結果をアグリゲーションしたりできます。
PromptFlowは私がめちゃくちゃ欲しかった機能なのですが、これはプロンプトのバージョニングをしてみたり、過去のものから良くなったのか悪くなったのかを比較したり、取ってきた情報にどれだけ基づいているか、Groundnessみたいなパイプラインをきちんと測ったりすることで、プロンプトのデバッグなどがすごくビジュアルでやりやすくなる機能です。
なので、LangChainやPromptFlowみたいなものは、非常に必要になってくると思いますが、それをどれだけ楽にできるかが、今後重要なのかなと思います。
まとめ
まとめとして、Copilotという名前がどれだけ一般的になるかはわかりませんが、Copilot Stackという整理されたマップは、マジでありがたいです。
今後こういう概念のスタックがあるよねというのは共有されるのかなと想像しています。
FrontendやOrchestrationが、どこに当てはまるのかを考えながらツールなどを整理すると、どこまでの責任を持たせられるかが非常にわかりやすいと。
あと、現状のLLMについても、State of GPTで非常に整理されたと思っています。パラメーター数が7ビリオンだとか、65ビリオンだとかというだけではなく、そのモデルがいったいどのフェーズにあるのかもすごく重要だよね、ユースケースに合ったモデル選択をしないとねという話があります。
Vector searchやPromptFlowみたいな、Orchestrationのツールは、Azureに今後拡充されていくだろうし、オープンソースのものもたぶん出てくるので、Copilot Stackのどこにあるのかを見ながら選んでいきたいなと思っている次第です。
メルカリでの取り組みを紹介
メルカリでの取り組みについても、ちょっとここで話をしたいなと思っています。私はLLMと生成系AIの専属チームでやっているのですが、社内でどういう取り組みをしているかについて、ちょっと簡単に紹介できたらと思います。
まず1個目が、これはすでにうちのチームのmaze（石川佑樹氏）も発表しているのですが、「mercari ChatGPT」みたいなものを社内で出しています。
ChatGPTだと社内の機密情報などが漏洩するリスクがあるから、社内で安心して使えるものを作ろうねという話が、最初にありました。
付加価値として、もっといろいろできないかということで、バックエンドはAzureのOpenAIを使って、gpt-3.5-turboやgpt-4などやっていたところにGoogleの「chat-bison」も入れて、いろいろなモデルを社内で比較しやすいようにしようねと、社内の理解を深めました。
あと、シェアの機能を入れています。これは最近、ChatGPTにも入ったらしいですね。自分のチャットの履歴をシェアできます。プロンプトを書くのが上手な人がやはりいるわけですよ。言語能力に長けている人。そういう人が作ったプロンプトはけっこう汎用的に使えるので、それを社内で展開して、活用や習熟を促進していくことを狙ってやっています。
もう1つ。たぶんこれは、非常にティピカルなユースケースではありますが、社内ドキュメント検索ですね。
「Confluence」とか「Google Docs」とか「Slack」とか、データソースがいろいろあるものをベクトライズします。ただの全文検索と違うのは、自然言語で質問して、検索して、自然言語で返してくれるところです。
例えば「○○の施策の内容について教えてください」と言った時に、「○○の施策ってこういうもんですよね。こういう進捗ですよ」みたいなことを、自然言語で教えてくれるというのはすごく便利だよねと取り組んでいます。
内部では、AzureのCognitive SearchのVector searchを使っていて、Hybrid searchとかも入れています。それ自体は非常に便利だし、ツール自体も整っているのですが、じゃあ幸せな世界が訪れるかというと、決してそんなことはありません。やはりチューニングはまだまだ必要だなという印象です。
例えばドキュメントを、どの粒度でベクトル化をするか。例えばConfluenceのドキュメントはめちゃめちゃ長いので、それを一度に全部ChatGPTには入れられません。チャンクに切らないといけないのですが、どれぐらいのサイズで切っていくかとか。
ほかにも、ドキュメントをサマライズしてからベクトル化するとか、これはこういうドキュメントですよみたいなインストラクションを付けるとか、いろいろな選択肢がありますが、どれがベストかはまだいまいちつかめていません。
例えばFAQは質問と応答なので、検索が非常にしやすいのですが、社内ドキュメント検索だと、質問に対してのドキュメントが、ベクトル空間上でそんなに近くはなかったりすることがけっこうあるわけです。
そういう場合に、どうやってそこを近づけていくか、正しい検索となっていくかみたいなところでTwo-Towerモデルみたいな概念はありますが、それを使ったからきれいにできるかというとそうでもありません。
そこは今後社内で検討しなきゃいけないし、みんなで知見共有できると、車輪の再発明をしなくて済むなと思っているので、ぜひともみんなで深めていきたいし、ベストプラクティスを深めていきたいなと思っている分野です。
最後に、LLMチームは採用もしています。LLMをメルカリでもやっていきたい人は、私たちのチームにアプライしてもらえると。みんなでやっていきましょうという感じです。以上です。ありがとうございます。
そうだ、最後に。実は私、今までMacしか使っていなかったのですが、今回の「MS Build」の発表が良すぎて、「Surface」買ったんですよ。
発表を実はWindowsからやっているというオチで、おしまいにしようと思います。ありがとうございました。
「mercari ChatGPT」の開発工数と費用はどのくらいなのか？
司会者：はい、大嶋さん、ありがとうございました。Windowsデバイスも買ってもらって（笑）。「MS Build」自体も非常に良かったかなと思います。質問が1件来ているので、公開させていただけたらなと思います。
「mercari ChatGPTのように、社内GPTの構築にかかった費用はどのくらいでしょうか？ 差し支えない範囲でご教示いただければ幸いです」ということですが、いかがでしょう？
大嶋：額そのものを言ってもいいかというと、ちょっと怪しいので、ふわっとした感じになるんですけども。
実際、けっこう使ってはくれていますが、ChatGPTの3.5のAPIとかだとそんなに高くはないので、月に何百万ということは決してないですね。許されるレベルのお金感でやっている感じです。
ただ、GPT-4とかだと事情が違ってくるので、GPT-4をいっぱい使うようになってくると、ちょっと変わってくるかなという気がしている感じですかね。
司会者：ありがとうございます。ちなみに、構築の工数でいうとどれくらいかかったんですか？
大嶋：構築の工数自体は、どれぐらいだろう？ 2週間ぐらいで作ったんだと思います。そこはもう、1人のエンジニアが気合いを入れて作った感じ。
司会者：おぉ、1人で2週間で（笑）、メルカリさんのChatGPTを構築したということですね。
大嶋：そうですね。内部的にはAPIコールするだけで、基本的にフロントエンド開発だけなので、それぐらいの規模感でやった感じです。
司会者：ありがとうございます。
