GPT-3.5 の微調整には非常に費用がかかることはよく知られています。このペーパーでは、実験を使用して、手動で微調整したモデルが数分の 1 のコストで GPT-3.5 のパフォーマンスに近づくことができるかどうかを検証します。興味深いことに、この記事はまさにそれを行っています。
SQL タスクと関数表現タスクの結果を比較すると、この記事では次のことがわかりました:
この実験の結論の 1 つは、GPT-3.5 の微調整が最初の検証作業には適しているが、その後は Llama 2 のようなモデルが最適である可能性があるということです。要約すると:
次に、この記事がどのように実装されるかを見てみましょう。
次の図は、SQL タスクと関数表現タスクで収束するようにトレーニングされたコード Llama 34B と GPT-3.5 のパフォーマンスを示しています。結果は、GPT-3.5 が両方のタスクでより高い精度を達成していることを示しています。
ハードウェア使用量に関しては、実験では A40 GPU を使用しました。コストは 1 時間あたり約 0.475 ドルです。
さらに、実験では、Spider のサブセットである、微調整に非常に適した 2 つのデータセットを選択しました。データセットと Viggo 関数表現データセット。
GPT-3.5 モデルと公平に比較するために、実験では Llama で最小限のハイパーパラメーター微調整を実行しました。
この記事の実験における 2 つの重要な選択肢は、フルパラメータ微調整の代わりに Code Llama 34B と Lora 微調整を使用することです。
#実験では、Lora ハイパーパラメータの微調整に関するルールにかなりの範囲で従い、Lora アダプターは次のように構成されました:
##SQL プロンプトの例は次のとおりです。
SQL プロンプトは次のとおりです。部分的に表示されています。完全なプロンプトを入力してください。 元のブログを表示します。
実験では完全な Spider データ セットを使用しませんでした。具体的な形式は次のとおりです。
department : Department_ID [ INT ] primary_key Name [ TEXT ] Creation [ TEXT ] Ranking [ INT ] Budget_in_Billions [ INT ] Num_Employees [ INT ] head : head_ID [ INT ] primary_key name [ TEXT ] born_state [ TEXT ] age [ INT ] management : department_ID [ INT ] primary_key management.department_ID = department.Department_ID head_ID [ INT ] management.head_ID = head.head_ID temporary_acting [ TEXT ]
実験では、sql-create-context データセットと Spider データセットの交差を使用することを選択しました。モデルに提供されるコンテキストは、次のような SQL 作成コマンドです:
CREATE TABLE table_name_12 (class VARCHAR, frequency_mhz VARCHAR, city_of_license VARCHAR)
SQL タスクのコードとデータ アドレス: https://github.com/samlhuillier/spider-sql -finetune
関数表現プロンプトの例は次のようになります:
function 表現プロンプトは部分的に表示されています。完全なプロンプトについては、元のブログを確認してください。##出力は次のとおりです:
verify_attribute(name[Little Big Adventure], rating[average], has_multiplayer[no], platforms[PlayStation])
関数表現タスク コードとデータ アドレス: https://github.com/ samlhuillier/viggo-finetune
詳細については、元のブログをご覧ください。
以上がGPT-3.5 を選択しますか、それとも Llama 2 などのオープンソース モデルを微調整しますか?総合的に比較した結果、答えは次のようになります。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。