OpenAI DevDay分科会ChatGPT商用利用ビデオまとめ

何本かビデオがyoutubeにあがっているうちの「言語モデル（LLMs）の可能性を最大限に引き出すための技術」分科会ビデオを紹介します。

言語モデルの活用と最適化

このビデオでは、言語モデルのパフォーマンスを最大化するための様々な手法が紹介されています。紹介された技術を組み合わせることで、開発者は彼らのニーズに合った問題解決手法を設計できます。

REACTフレームワーク

「REACTフレームワーク」を参考にし、モデルにその理由付けのステップを書き出させることで答えにたどり着くのを手助けするというアプローチを紹介しています。

また、複雑なタスクをよりシンプルなタスクに分解することでモデルが予測をより容易に行えるようにすることを提案しています。スクリーンショットは、このアプローチの一例として、ニュース記事から意見を抽出し、それを構造化したJSON形式で表示しています。

ショー、ドント・テル

プロンプトエンジニアリングにおける次の一般的なステップとして、「ショー、ドント・テル」のアプローチをとることを勧めています。つまり、モデルにどのように行動してほしいかを伝えるのではなく、入出力のペアを示すことで所望の振る舞いをモデルに示すことです。これによって、実践的なタスクにおいて性能の向上が見られると言及しています。

フュー・ショット・ラーニング

最後に、ユーザーの質問に基づいて文脈を持たせたフュー・ショットの例を使うことで、モデルを産業化し、実用化することへの意欲が高まると述べています。これは、実際の応用において、モデルがより具体的なコンテキストに基づいて応答できるようにするためのステップです。

異なるタイプのモデル改善手法

プロンプトエンジニアリング、リトリーバル拡張生成（Retrieval-Augmented Generation, RAG）、そしてファインチューニングの3つのアプローチを対比しています。

プロンプトエンジニアリング

プロンプトエンジニアリングは、モデルに正しい指示を与えることで始まります。これはモデルがすぐにタスクを実行できるようにするためのものです。

リトリーバル拡張生成（RAG）

リトリーバル拡張生成（RAG）は、「短期記憶」として比喩されており、モデルが特定の情報を必要とするときに使われます。これは、モデルがタスクを解決するために必要な情報を「取得」することに相当します。例えば、試験中に本を参照できる「オープンブック」という状況を想像してください。モデルが探すべき情報の方法論を知っていれば、RAGはモデルが本から正しいページを開いて必要な情報を取り出すことを可能にします。

ファインチューニング

ファインチューニングは、「長期記憶」として比喩されており、モデルに特定の構造、スタイル、またはフォーマットを学習させることに使われます。これは、試験の準備のために事前に勉強することに相当し、モデルが質問に答えるために必要な方法論やフレームワークを学ぶプロセスです。

ファインチューニング使わずどこまでできるかRAGを使用した成功例

リトリーバル拡張生成（RAG）を試す

リトリーバル拡張生成（Retrieval-Augmented Generation, RAG）を使用した成功例を示しています。それは、プロンプトエンジニアリングとRAGがシンプルに見えるかもしれないが、実際には多くの繰り返しとテストを必要とし、それを実現するのは非常に困難であることを示しています。

コスト面で実用化されなかった方法

この例では、顧客が異なる知識ベースを持つRAGパイプラインを持っており、ユーザーの質問を受け取って、どの知識ベースを使用するかを決定し、クエリを発行し、それを使って質問に答えることが求められていました。開始時の正確さは45％でしたが、様々な手法を試した結果、65％に向上しました。これには仮想ドキュメントの埋め込み（質問の類似性検索ではなく、偽の答えを生成してそれに類似性検索を行う）や埋め込みの微調整（正確な答えにモデルを導くためにトレーニングセットに基づいて埋め込み空間を変更する）などが含まれますが、これらはコストや速度の面で実用的ではなかったため、採用されませんでした。

リランキングと分類を試す

次に行われたのは、リランキングと分類で、これにより85％の正確さに到達しました。リランキングでは、結果を再順位付けするためにクロスエンコーダを適用したり、分類ではモデルがドメインを分類し、その後、どのコンテンツが最も関連性が高いかを決定するために追加のメタデータをプロンプトに与えました。

プロンプトエンジニアリングに戻る

最終的に、プロンプトエンジニアリングに戻り、プロンプトをさらに工夫し、誤っていた質問のカテゴリーを見直し、ツールの導入を行いました。例えば、構造化されたデータの質問に対しては、SQLデータベースにアクセスさせ、変数を入力してクエリを実行し、構造化されたデータの答えを取り出すようにしました。最後に、複数の質問を一度に行うクエリ拡張を行い、それらを並列に実行して結果を取り出し、1つの結果にまとめました。これらの手法を組み合わせることで、98％の正確さに到達しました。

このプロセスで重要なのは、ファインチューニングを一度も使用していないことです。ファインチューニングは、本番環境への移行にしばしば必要だと考えられがちですが、このケースでは問題はすべてコンテキストに関係しており、ファインチューニングを行っていたら、それは無駄なお金と時間の浪費になっただろうと指摘されています。それゆえに、これは成功例として挙げられています。

プロンプトエンジニアリングとは全く異なるファインチューニングとは

既存モデルが新たなモデルに変わるプロセス

ファインチューニングは、既存のモデルを取り、新しいデータセット上でトレーニングを続けるプロセスです。この新しいデータセットは、元のデータセットよりも小さく、特定のドメインに特化していることが多いです。このプロセスを通じて、ベースモデルは変化し、新たなモデルに変わります。

何百万ものトークンをモデルに渡す事ができる

ファインチューニングが求められる理由には2つの主要な利点があります。1つ目は、ファインチューニングによって、プロンプトのテクニックだけでは達成できないパフォーマンスレベルを実現できる場合があるということです。プロンプトのテクニックではモデルのコンテキストサイズによって、モデルに示せるデータ量に制限があります。しかし、ファインチューニング中には、何百万ものトークンにわたるデータをモデルに示すことができます。

リクエストごとに送るプロンプトトークン数が少なくて済む

ファインチューニングされたモデルが対応するベースモデルと比較して、対話時の効率が良くなることです。ファインチューニングされたモデルを使用するときは、望ましいパフォーマンスを達成するために複雑なプロンプトのテクニックを使用する必要が少なくなります。つまり、リクエストごとに送るプロンプトトークンが少なくなり、それによって各リクエストが安価で、一般に応答が早くなります。

ファインチューニングからはモデルは学習しない

ファインチューニングは新しい知識をモデルに加えるのには適していません。LLMに存在する知識は、非常に大規模な事前トレーニングの実行中にモデルに組み込まれました。これらの限られたファインチューニングの実行中に新しい知識を取り込むことはできません。新しい知識をモデルに取り入れる場合、Colinが言及した理由でRAGなどを見る必要があります。