December 23, 2023
キヨシです。
某検索エンジンプロダクトの開発ではJSONエンジニアとしてあらゆる求人情報をクローリングし、マンパワーのスピリッツを発揮しておりました。
今年はジョブチェンジをし、プロンプトエンジニアとして、LLMのあれやこれやを担当しております。
先日、**Visional IP Awards という栄誉ある賞をいただきました。**プロンプトエンジニアのロールモデルとして、そのスピリッツを体現できたのではないかと思います。
さて、この記事は検索エンジンプロダクトを一緒に開発してた同窓会 Advent Calendar 2023の23日目の記事です！🎄
22日目の記事を担当された たけほなみさん とは『自社サービスでCopilotをうごかすなら？』について何度も議論をさせていただきました。
LLMが新たなユーザーインターフェースとなり、これまでの操作プロセス中心の体験設計から、クエリ中心の体験設計になることは容易に想像できるので、ユーザーインターフェースの設計でも試行錯誤を続けています。
こうした体験設計の変化のなかで今年はLLMを活用したナレッジベースからの生成型検索手法として、RAGのアーキテクチャが勃興しました。しかし、非構造化データに対するベクトル検索とその文書の自然言語をインプットとしただけの検索システム拡張には課題も多く、RAGのようなアプローチを用いる場合でも検索対象のデータを構造化することは、回答精度の向上やアプリケーションとしての応答性能を高めるために重要であると考えています。
私たちが開発していた、ジョブアグリゲーションのような検索エンジンなら求人の職種やその募集事業者の業種、これがレストランなど店舗検索なら料理のジャンルや予算などの区分値は掲載媒体によって定義がバラバラだったり、そもそも記載されていないので、検索体験向上のため自社の検索エンジンにインデックスする際に適切なラベリングをするということはよくあるかと思います。
このラベリングタスクを解くために、人力やアルゴリズムで頑張ることもありますし（笑）これまでも様々な機械学習のモデルが提案され、実際に試行錯誤してきました。
こうした、データの構造化タスクにLLMを活用することは容易ですが、一方でとてもドメインが限定的でハイコンテキストなタスクのため、学習済のLLMモデルをワンショットで利用すると精度が不十分であったり、モデルのサイズが大きいため大量のラベリングタスクにおいて、応答時間やスループットの課題もあります。
こうした課題に対して、先日Googleの研究者らが “[2305.02301] Distilling Step-by-Step! Outperforming Larger Language Models with Less Training Data and Smaller Model Sizes” という論文とともに実装も公開しました。
今日はこの "Distilling Step-by-Step”という手法について、日本語の求人情報に対して複数の職種をラベリングする問題を例に、そのトレーニングをGoogle Cloud Vertex AIで実行する方法について手順を確認していきましょう！
Distilling Step-by-Stepについての詳しい解説はGoogle Research Blogの記事がわかりやすいですが、Distillingとはモデル圧縮の手法で知られる「モデル蒸留」のことです。端的にいうとより少ないトレーニングデータで優れたパフォーマンスを発揮し、かつサイズの小さなモデルを作るためのLLM（大規模言語モデル）の効率的なトレーニング手法の提案です。
この手法では、高性能なLLMを用いてなんらかタスクの問に対する答えを説明する「中間理由」を生成し、これらの理由を個別タスクのラベルに加えて小規模なモデルをより効率良くトレーニングするいわゆる知識蒸留を行います。
一般的なモデル蒸留手法とおなじく、巨大な教師モデルを使用して、より小さな生徒モデルを訓練することで、特定タスクに対して高度な推論能力を持ち、より低コスト、低遅延で効果的に実行できるようになります。
はじめのステップではいわゆる "few-shot chain-of-thought (CoT)” プロンプトを使用してLLMから理由を抽出し、次にこの生成された理由を用いて、マルチタスク学習フレームワークのなかで小規模なタスク特化モデルをトレーニングします。