プロンプトとは何か？プロンプトの本質と制約とそれを乗り越えるための工夫
前回のnoteでは、ChatGPT / LLMの原理を、進化の過程を振り返りながら整理してみました。今回は、GPTを活用するために今最も大切な"プロンプト"について、まとめてみたいと思います。
ユースケースを考えていくうえでは、このプロンプト自体とその制約を正しく理解することがめちゃくちゃ重要だと思いますので、まずは「プロンプトとは何か」を整理していきましょう！
1. よく聞く”プロンプト”ってなにしてるのか？
そもそも「ChatGPT等のLLM(大規模言語モデル)とは何か」から振り返ってみましょう（詳細は是非前回のnoteをご覧ください！）。
LLMは、「それまでの単語列をインプットとして、次の単語を予測する」モデルです。膨大なデータを学習することで汎用的な文法体系や知識を備えた言語モデルを構築したうえで、そのモデルに何かしらの情報をインプットすると、次の単語予測を通じて適切なアウトプットを出力してくれます。
プロンプトは、この言語モデルがアウトプットを生成するためのインプット情報です。つまり、私たちがChatGPT等に指示を出す時に入力しているテキストそのものということになります。
なお、LLMへの入力情報には、モデルへの「指示」だけでなく、適切な回答に導くための「条件」や参照すべき「事例」を含むことができます。
GPT-3以降のモデルでは、タスクごとにモデル自体をFine-tuningする代わりに、非常に少量のデータ（参照情報）をインプット情報に含めることで、1つの汎用モデルで様々なタスクに対するアウトプットの精度を高めることができるようになりました。
この「少量のデータ（事例）」を含めることは、Few-shot、One-shot、Zero-shot等様々な呼ばれ方をしますが、事例を何個使っているかの差であって、やっていることはあまり変わりません。
・Few-shot : いくつかの事例を与える
・One-shot : 一つの事例を与える
・Zero-shot : 事例を与えない（指示だけを出す）
入力情報に、指示内容だけでなく、事例であったり参照すべき情報を含めることができるようになったことは非常に大きな意味をもっています。
例えば、LLMは学習時点の情報しか持っていないので直近の情報を踏まえて回答することができないと言われていますが、プロンプトに参照してほしい最新情報を含めてしまえば、最新情報を用いて回答してもらうことができるようになります。
私たちが社内で実証実験している「IR資料からの質問生成」プロジェクトでは、当然LLMは当社の直近の決算情報を保持していないため、プロンプトにそのまま決算情報をインプットして、それを参照して回答を作るように指示しています。このように回答に必要な情報をプロンプトで追加的に提供することで、かなり幅広いタスクをこなすことができるようになります。
2. なぜ現時点でプロンプトが最も重要なのか？
大規模言語モデルを構築するところから、質問の回答を答えるところまでのプロセスを簡潔に書くと以下の様になります。
① Pre-training : 事前学習による汎用モデルの構築
② Fine-tuning : タスクに応じた微調整
③ Prompt : 事例・条件を交えた指示の入力
①のPre-trainingは、膨大なデータと計算リソースが必要になります。例えばGPT-4は100億円以上の開発コストがかかったと言われています。日本でも直近サイバーエージェントが独自の日本語LLMを開発されていますが、これもかなり膨大な投資をおこなったものと推測されます。よって、超大手でない限り、一般的な会社が独自のデータで独自の汎用モデルを作ることはあまり得策とは言えません。
②のFine-tuningは、専門性が高いタスクを行う上では重要なプロセスになることが予想されますが、GPTシリーズについてはInsructGPT以降のモデルではFine-tuningができないようになっています。
これはInsructGPT以降のモデルでは、「Reinforcement Learning from Human Feedback (RLHF)」というプロセスを適用していることに起因していると思われます。RLHFでは、LLMが出力したものに対して人間が良し悪しを評価し、その結果をモデルに学習させることで、たとえ統計的に可能性が高かったとしても、人にとって有害となる回答はしないようにモデルをチューニングしています。
わざわざRLHFというプロセスを通じて、人のレビューをしながら倫理的に有害なものをはじくようにパラメータをチューニングしているのに、パラメータを変更できるようにするということは、「RLHF」によってせっかくかけたフィルターを外して、有害なものを垂れ流すモデルに変形できてしまうということを意味します。なので、現状Fine-tuningができない仕様になっていると思われます。
もちろん、中期的には、Fine-tuningができるようになってくると思いますが、倫理問題の解決にはすごく時間もかかると思いますので、短期的には主流となる言語モデルでは、それが与える社会的影響力からFine-tuningできない状況が続くのではないかと推察しています。（逆に言えば、そこまで社会的責任を考えすぎなくてもよいオープンソースのモデルであれば、Fine-tuningできる状態が続くかもしれません。）
このあたりは、直近Open AIのCEO Sam Altmanが提唱している規制強化の話に繋がってくる論点だと思っています。IT企業側が規制強化を求めるのはなかなか珍しい話ですが、同氏はLLMを通じて情報操作等が簡単にできてしまうことから、免許制の仕組みによるガバナンス強化を提案しています。
これは、倫理上の話だけでなく、戦略的な意味合いも大きいと思います。オープンソースであれば社会的責任をそこまで慎重に考えなくていいためFine-tuningできると仮定すると、オープンソースの方が、エンジニアにとって利便性の高いモデルを提供できることになるため、Open AIにとっては現状の地位を奪われるリスクが高くなってしまいます。一気に注目を浴びる存在になってしまったOpen AIならでは悩みではありますが、間違いなくOpen AIは今後慎重なスタンスを取らざるをえず、開発競争で後れを取る懸念を抱えており、現状の地位を守るべく規制強化を推進するのではないかと思われます。
※これに関連する論点が、Googleの内部文書のリーク記事で詳細に書かれているので是非ご一読をお勧めします！
少し長くなりましたが、このように整理していくと、シンプルに言えば、GPTシリーズを前提とした場合、一般的な会社や人が現時点でできることは、「プロンプトを工夫することしかない」ということになります。
「プロンプトは入力情報のことであり、プロンプトがとにかく重要」であるとすると、入力情報をリッチにすればするほどよい回答が得られるのでは?!と考えられると思いますが、そこには制約があります。
3. プロンプトの制約
「Transformer」によって長文が取り扱えるようになったとは言え、計算リソースの都合、プロンプトとして一度に入力できる情報量には限りがあり、この上限を「Context length」と言います。
最近公開されたモデルのContext lengthは以下の通りです。
・GPT-3.5turbo : 約4,000トークン
・GPT-4 : 約8,000トークン → つい最近、約32,000トークンに！
（※１トークン＝1単語（句読点や記号も1単語としてカウント）みたいなイメージで考えておくとよいと思います。）
よって、プロンプトに何でもかんでも情報を突っ込むことはできませんので、限りあるトークンを有効活用することが求められます。そこで次はContext lengthという課題に対応するための方法を整理していきたいと思います。
4. Context lengthを乗り越える方法
4-1. Map-Rerank (分割総当たり)
最初にわかりやすいシンプルな解決策「分割総当たり」（Langchainでは「Map-Rerank」と呼ばれています）を見ていきましょう！
この方法は、以下のようなプロセスで行います。
1. まずLLMにインプットしたい情報を集めます
2. 上記で集めた情報をContext lengthに入る範囲に分割していきます
（例：30個に分割したと仮定）
3. 分割された30個の情報と指示、条件をLLMに投入し、30個分の回答を出力
（ここで「質問と回答の関連度をスコア化する」という指示を足します）
4. この関連スコアが高かったものを回答として採用します
このように分割して、いったん全部LLMに突っ込んでしまうことで、Contect lengthを超えた情報の中からどこかを使ってアウトプットを出すこと可能になります。
しかし、分割した分だけAPIをコールすることになるので、お金がかかりますし、速度も遅いという問題が生じます。
また、分割して独立したタスクとして処理してしまうため、全量データが持つ総合的な文脈を理解して回答することはできません。例えば、「本来は一番最初に書かれていた内容と一番最後に書かれていた内容を使って回答するとよかった」というようなこともあり、単純に分割して総当たりするだけでは常に良い結果が得られるわけではないという課題もあります。
4-2. Vector Databaseの活用
そこで次に考えられるのが、参照情報をしっかり集めたうえで、タスクと関連性の高い情報を抽出してプロンプトにするという方法です。
これは、以下のようなプロセスで行われるイメージです。
1. データを収集
2. データをベクトル化してデータベースに格納
3. データベースからタスクと関連性の高いデータを抽出
4. 抽出された関連性の高いデータをプロンプトとして使用
テキストのような非構造化データを取扱うためには、テキストをいったん数値として取り扱えるようにしておくことが重要です。2のプロセスにおいて、収集したデータをベクトル化して使いやすく格納しておくことを「Vector Database」と呼び、これにより後続の検索／抽出といった作業がしやすくなります。
3のプロセスにおいては、タスクに必要な情報を検索していますが、これには「ベクトル検索」という方法が使われることが多いです。タスクに必要な情報をベクトル化し、コサイン類似度が高いベクトルを高速に見つけることを実現しています。
現在は、LangChain等のツールやPinecone等のサービスが出てきており、Vector Databaseを構築したり、それを検索する機能を作ることができる環境が整いつつあります。しばらくはこうしたツールやサービスがどんどん出てきて、より複雑かつ精度の高い情報をプロンプトに入れ込むことができるようになってくるのではないかと期待しています！
4-3. [おまけ] そもそもContext lengthの制約はなくならないのか？
目下、Context lengthの制約をなくすべく、既に大量の情報量を処理できるTransformerが研究されています。
最近出てきているのは、Recurrent Memory Transformerというもので、Transformerの考え方は維持しつつ、より長い文脈を理解して文章を生成することができる技術です。これを用いると、トークン数は200万（GPT-4の60倍！）まで処理できるようになるということでとても話題になっています。
Antrhopic社が10万トークンのContext lengthを持つLLMをリリースする等、既に進化は始まっていますが、こうした技術が発展してくれば、プロンプトの工夫みたいなところはあまり論点にならなくなってくるかもしれません！
5. まとめ
現時点で最も重要なプロンプトに制約条件があるということは、逆をいえば、ここにこそ工夫のチャンス、そして事業機会があるとも言えます。個人的には、短期的にはこのあたりをしっかり深堀していくことが重要だと考えています。（とはいえ、進化のスピードが速すぎるので、あっという間に状況が変わる気もしますが、、）
以上、前回のLLMの概要に続き、今回はプロンプトについて整理をしてみました。次回は、「ユースケースを考えるうえで気を付けるべき情報セキュリティ」について、改めて整理をしてみたいと思います。
なお、Finatextグループでは、LLMに携わるエンジニアやインターンを募集しています！
社内でLLMをどう活用しようとしているのか等、少しでも興味を持っていただける方がいたらぜひTwitterでご連絡ください。