ハッカーのための言語モデルガイド [動画]

 (youtube.com)
1 ポイント 投稿者 GN⁺ 2023-09-25 | 1件のコメント | WhatsAppで共有
  • Jeremy Howardは言語モデルを理論よりもコード優先のアプローチで扱い、OpenAI APIからローカルのオープンソースモデルまで実際の利用フローを一通り見ていく
  • 言語モデルは単語ではなくトークンを予測し、事前学習・命令チューニング・RLHFを経ることで質問応答やタスク実行により適したものになる
  • GPT-4は2023年9月時点で強力な選択肢だが、自分自身・URL・知識カットオフ以降の情報には弱く、custom instructionsが回答品質に大きく影響する
  • OpenAI APIは会話状態を保存しないため、毎回会話履歴全体を送る必要があり、関数呼び出しによってPython実行のようなツールを接続できる
  • ローカル実行はHugging Face Transformers、Llama 2、GPTQ量子化、RAG、Axolotlファインチューニング、MLC・llama.cppなどで可能だが、GPU・プロンプト形式・評価の限界も伴う

言語モデルはトークンを予測する圧縮システム

  • 言語モデルは文の次の単語を予測したり、欠けた単語を埋めたりする形で動作する
    • 例としてOpenAIのtext-davinci-003に「panda breeding facility」と「live frogs」を含む文を入力し、その続きの文を生成する
    • nat.devでは複数の言語モデルを試し、次トークン候補の確率を見ることができる
  • 実際の予測単位は単語ではなくトークンである
    • トークンは単語全体、単語の一部、句読点、数字などになりうる
    • tiktokenを使うと、GPT系モデルと同じトークナイザーで文字列をトークンID配列にエンコードし、再びデコードできる
    • 例では「they are splashing」は空白を含む部分単語単位に分割される
  • 事前学習は、インターネット文書やWikipediaの文から次の単語を当てるようにニューラルネットワークを学習させる過程である
    • 「The Birds」のWikipedia文で、Alfredの次にHitchcockを当てるような学習が例として使われる
    • 次の単語をうまく予測するには、モデルが物事、時間、映画、監督、人名のような世界知識を内部的に学習する必要がある
  • Howardは次単語予測を圧縮の一形態と見なしている
    • 多くの情報をニューラルネットワークのパラメータ内に圧縮しなければ、次の単語をうまく予測できない
    • 圧縮と知能の関係は以前から議論されてきたアイデアである

事前学習から命令チューニング、RLHFへ続く流れ

  • HowardはULMFiTを言語モデル活用の基礎アイデアとして扱っている
    • ULMFiTはHowardが2017年に作ったアルゴリズムで、Sebastian Ruderとともに2018年初めに論文としてまとめた
    • 元の例はWikipediaで言語モデルを事前学習する方式だった
  • 学習の流れは3段階に分かれる
    • 言語モデル事前学習: 次単語予測を通じて一般知識を学習する
    • 言語モデルファインチューニング: 最終タスクにより近い文書で再び次単語予測を学習する
    • 分類器ファインチューニング: 最終タスクに合わせてモデルを調整する
  • 現代の言語モデルでは、第2段階は主に命令チューニングの形で使われる
    • 質問、指示、依頼とそれに対する応答データでモデルを調整する
    • 例のデータセットとしてOpenOrcaとFLAN collectionが挙げられる
    • OpenOrcaには約4GBの質問・コンテキスト・応答データが含まれる
  • 第3段階ではRLHFがよく使われる
    • 人間やより優れたモデルが、複数の回答の中からより良い回答を選ぶ
    • 例として「キャリアへの情熱を取り戻す5つのアイデア」のような質問に対する2つの回答を比較する方法が出てくる
  • 「言語モデル」という表現は文脈により、事前学習のみのモデル、命令チューニング済みモデル、RLHFまで経たモデルのすべてを指しうる
    • 純粋な事前学習モデルは単独では概して有用性が低く、ファインチューニングによって実用性が高まる
    • Howardは、最近では命令チューニングだけで十分かもしれないという議論もあると述べている

GPT-4をうまく使う方法と限界

  • Howardは2023年9月時点でGPT-4を最良の言語モデルとして強く推奨している
    • ChatGPTでは月額20ドルでGPT-4を多く利用できる
    • OpenAI APIは別途トークン単位の課金体系になっている
  • GPT-4は推論できないという主張について、論文やインターネット上の例をいくつか直接入力してみると、正しく答える場合が多かったと見ている
    • Mabelの生死時点の問題、Sallyと兄弟姉妹の問題、カップ・シンブル・ダイヤモンドの位置問題が例として挙がる
    • Howardは、インターネットでGPT-4にできないとされる例を確認すると、実際にはできることがかなり多かったと述べている
  • モデルは常に正解を出すよう訓練されたシステムではない
    • 事前学習はもっともらしい次単語を当てる過程であり、インターネットには虚構・冗談・誤情報も多い
    • RLHFではより自信のある回答が好まれた可能性があり、評価者が誤答を十分に見分けられなかった可能性もある
  • custom instructionsは回答品質の向上に役立つ
    • 「推論が得意だ」「正解がないかもしれない場合はそう言うこと」「まず背景文脈を数文で説明すること」といった指示を、すべてのクエリの前に付けられる
    • モデルは1語ずつ生成し、生成した内容を再び入力に含めるため、より多くの語を生成させればより多くの計算ができる
    • VVで始めると簡潔に答えさせる、といった個人ルールも例として使われる
  • GPT-4にも明確な限界がある
    • モデル自身がどう学習されたか、コンテキスト長がどれくらいかといった情報は、学習段階で知る機会がなかった
    • URLの内容はよく分かっておらず、尋ねると作り出してしまうことがある
    • GPT-4の事前学習知識は2021年9月までである
    • よく知られた古典パズルを少し変えると、既存パターンに引きずられて誤答することがある
      • キャベツ・ヤギ・オオカミの川渡りパズルで制約を変えた例が使われる
      • 間違った答えを出した後に会話で修正しようとすると、引き続き誤ることがあるため、チャットのedit機能で前のプロンプトを直した方がよい

OpenAI APIと関数呼び出しでツールをつなぐ

  • OpenAI APIはPythonなどからプログラム的に言語モデルを呼び出せるようにする
    • pip install openaiの後、ChatCompletion.createでgpt-3.5-turboのようなモデルを呼ぶ例が使われる
    • systemメッセージはChatGPTのcustom instructionsに近い役割を持つ
    • 例では「Aussie slangと比喩を使うAussie LLM」というシステムプロンプトを入れ、「What is money?」と質問する
  • APIの会話ではサーバー側に永続状態は保存されない
    • 続きの質問をするときは会話履歴全体を再送する必要がある
    • ユーザーが以前のassistant回答を任意に書き換えて入れても、モデルはその会話履歴を基に続けて答える
    • 例ではassistantが「money is like kangaroos」と言ったことにして、その比喩を続けて説明させる
  • コストはモデルとトークン数によって変わる
    • トークンは平均すると単語より少し多く、およそ1⅓トークンで単語1語程度である
    • 例ではGPT-3.5が0.0015ドル、GPT-4が0.03ドル程度という価格差が挙げられる
    • 約150トークンの応答はGPT-3.5で0.0003ドルほどと計算される
    • OpenAIのusageページで利用量を確認できる
  • 初期のAPIアカウントではrate limitが低いことがある
    • 最初の48時間の無料ユーザーまたは有料ユーザーに、1分あたり3リクエストのような低い制限が例として示される
    • rate limitエラーが出たら、retry-afterの値を読んで待機し、その後に再試行するPythonコードが必要になる
  • function callingを使うと、モデルに利用可能なツールを知らせられる
    • Python関数そのものを渡すのではなく、JSON schemaで関数名、説明、パラメータを伝える
    • 関数説明であるdocstringが、モデルがツール用途を判断するうえで重要な情報になる
    • sums関数の例では、モデルは直接6+3と答えず、関数呼び出し名と引数を返す
    • python関数をツールとして提供すると、12の階乗を計算するためのコードを生成し、ユーザーが確認後に実行して、その結果を再び会話に戻せる
    • この方式でJupyter内に簡単なコードインタープリタを自作できる

ローカルモデル、RAG、ファインチューニングの選択肢

  • ローカルで言語モデルを使うには、一般にGPUが必要である
    • Kaggleでは古いGPUを2基搭載したノートブックを提供できる
    • Colabではより良いGPUと多くのRAMが利用でき、月額サブスクリプションで選択肢が増える
    • RunPod、Lambda Labs、Vast.aiのようなGPUレンタルの選択肢が挙げられる
    • 機密性の高い作業を「知らない人のコンピュータ」で実行するのは適切ではない
  • GPU選択では計算性能よりメモリ速度と容量が重要である
    • 中古のGTX 3090はeBayで約700ドル程度と言及される
    • RTX 4090はより新しいGPUだが、言語モデルでは3090より明確に優れているわけではない
    • 24GBでは多くの作業に十分でないことがあり、3090を2枚で約1,500ドルの選択肢として示される
    • 48GB RAMのA6000は約5,000ドル程度である
    • RAMの多いMac、特にM2 Ultraは既存モデルの実行には悪くないが、Nvidiaカードより遅い
  • Hugging Faceエコシステムはローカルモデル実験の中心的ツールとして使われる
    • TransformersでHugging Face上の事前学習済み・ファインチューニング済みモデルを読み込める
    • リーダーボードは参考になるが実利用性とは一致しないことがあり、ベンチマークデータが学習セットに混入するleakageの問題もありうる
    • 一般的な個人GPU環境では、70Bより13Bや7Bモデルの方が現実的である
  • Llama 2系と量子化が主要な例として使われる
    • MetaのLlama 2 7Bは事前学習のみのモデルで、命令チューニングやRLHFがなく、そのままでは質問応答に適していない
    • 7Bモデルを16ビットでロードすると、重みだけで約14GBが必要になる
    • 8ビットにキャストするとメモリは減らせるが、遅くなることがある
    • bfloat16はより高速だが、より多くのRAMを必要とする
    • GPTQ量子化モデルは低精度向けに最適化されており、メモリ転送が減るため、例では7Bより13BのGPTQモデルの方が高速に動作した
    • TheBlokeは人気モデルをGPTQ向けに最適化してHugging Faceへ公開している人物として言及される
  • 命令チューニング済みモデルでは必ずプロンプト形式を合わせる必要がある
    • Stable BelugaのようなLlama 2ベースの命令チューニングモデルは、モデルページのプロンプト形式をそのまま使う必要がある
    • OpenOrca Platypus 13B GPTQも別のプロンプト形式を確認して関数化する
    • 形式を合わせれば「Who is Jeremy Howard?」のような質問により良い回答を得られるが、それでもハルシネーションは残りうる
  • RAGは最新情報や私的文書を活用するための方法である
    • 質問に役立つ文書を検索し、その文書をコンテキストとして付与してモデルに回答させる
    • Jeremy HowardのWikipediaページ613語をコンテキストに入れると、より正確な100語程度の略歴に近い回答が生成された
    • sentence-transformersは文書と質問を埋め込みベクトルに変換し、類似度を計算して関連文書を選べる
    • 文書数が数千から数百万ある場合は、ベクトルデータベースを使って事前に埋め込みを保存しておく
    • H2O GPTはローカルでPDFをアップロードしてRAGを行うオープンソースの例である
    • 続きの質問では、検索モデルが前の文脈を知らないと的外れな文書を探してしまうことがあるので注意が必要である
  • ファインチューニングはモデル自体の動作を変える方法である
    • 例のデータセットにはデータベーススキーマ、自然言語の質問、正解SQLが含まれる
    • Hugging Faceのdatasetsライブラリでデータセットを読み込む
    • Axolotlを使ってLlama 2の例をコピーし、SQL用のYAML設定を作成して学習する
    • accelerate launch axolotlコマンドで約1時間学習すると、q_lora_outディレクトリが生成される
    • Qはquantize、LoRAはより小さなモデルとより小さなGPUでの学習を助ける手法である
    • 学習後はスキーマと質問を与えると、SELECT count(hosts), theme ... GROUP BY themeの形の正しいSQLを生成する
  • Macやその他のランタイムという選択肢もある
    • MLCはiPhone、Android、Webブラウザなどで言語モデルを実行できるプロジェクトである
    • Macで量子化された7Bモデルを実行して「What is the meaning of life?」に答えさせ、約9.6 tokens/sが出た例が示される
    • llama.cppはgguf形式を使い、Pythonラッパーからも呼び出せる
    • Nvidia GPUとPythonに慣れているなら、PyTorchとHugging Faceエコシステムを使う方がよい
  • 言語モデルの開発環境は急速に変化しており、まだ初期段階なのでインストールやエッジケースは扱いが難しいが、Pythonプログラマにとっては面白い時期である
    • fast.ai Discordのgenerativeチャンネルで質問したり、経験を共有したりできる

関連記事

1件のコメント

 
GN⁺ 2023-09-25
Hacker Newsのコメント

  • たった今公開したところなのに、もうHNに上がっていて驚いた。
    この動画にはかなり期待している。90分の発表の中に、思いつく限りの重要な情報を詰め込もうとした。目標は、開発者から「LLMについて知っておくべきことを全部教えて」と聞かれたときに、ここだけを示せるようにすることだった。
    それでも、抜けている内容や不明瞭な部分はきっとあるはず。今回は最初の試みで、いずれフル講義に拡張するつもりなので、動画を見た後に残った疑問や、扱うべきだったと思う概念を教えてほしい。
    そろそろ寝なければならず、オーストラリアは遅い時間なので、朝までは質問にあまり答えられないかもしれない。それでも起きたら必ずこのページを見るつもりだし、明日YouTubeの説明欄に関連論文へのリンクも追加する。
    倫理や政策の問題は扱わなかった。重要でないからではなく、今回の発表では技術的な問題だけに完全に集中することにしたからだ。

  • 素晴らしかった。動画と一緒に見るノートブックはこちら: https://github.com/fastai/lm-hackers/blob/main/lm-hackers.ip...
    プロジェクト構成もよかった。OpenAI APIのハック、OpenAI functionsで作ったCode Interpreter風のもの、Hugging FaceモデルによるローカルLLM実行、最後の10分にはテキスト-SQLモデルを作るファインチューニング例まで入っている。

  • 動画ありがとう。これまで見たLLM活用チュートリアルの中で最高だった。
    https://youtu.be/jkrNMKz9pWU?si=Dvz-Hs4InJXNozhi&t=3278で、ローカルモデルとGPT-4の適切なユースケースについて話し、「ファインチューニングによって、自分が解くべき問題の種類に特に強いモデルを作ることができ、そのような場合にはGPT-4より高い性能も十分あり得る」と述べている。
    これに関連して、しばらく考えていたアイデアがある。複数の「小さな」モデル、たとえば70億パラメータのモデル群を背後に持つチャットボットを想像できる。各モデルは特定のタスク向けにファインチューニングされているとして、こうしたシステムはGPT-4を上回れるだろうか。
    大まかな構想はこうだ。コンテキスト/プロンプトを「ルーターモデル」に送り、このモデルがどの専門家モデルが最もよく回答または補完できるかを判断する。次にシステムはコンテキスト/プロンプトをその専門家モデルに渡し、その回答を返す。適切な専門家モデルがなければ、一般的な指示チューニング済みの汎用LLMを使う。
    特定タスク向けにファインチューニングした小さなモデルが理論上GPT-4より優れ得るなら、そのような小さなモデルの集合体が全体としてGPT-4を超えることもあり得るのではないかと思う。

    • Sambanovaがちょうど似たものを発表した。新しいチップ上で動く1兆パラメータのMoEモデルのデモで、70億パラメータのllama2モデル150個を、それぞれ異なるトピックの専門家になるよう再学習した構成だ。あるものは「法律」の専門家、別のものは「物理学」の専門家、という具合。
      動画はこちら [1] https://sambanova.ai/launch2023
      少し下にスクロールすると、HuggingFaceのGPUで動く1800億パラメータのFalconモデルと比較している。MoEの結果は品質が同程度なだけでなく、非常に高速でほぼ即時に出るレベルだ。専門家モデルを差し替えたり、新しいデータで再学習したりできる点も大きな利点で、より一体型の1800億モデルでは当然そう簡単ではない。
    • 筋が通っている。実際、今まさにそうしたモデルを作っているオープンソースプロジェクトがいくつもある。よい例はこちら: https://github.com/XueFuzhao/OpenMoE/
    • Googleで専門家混合（mixture of experts）を調べるといい。未検証のリークによると、GPT-4もすでにこの方式を使っているらしい。

  • この一連の流れを始めた論文を書いた人の動画だという点も印象的だ。

  • 素晴らしい動画だったので職場にも共有した。実用的な観点では、私の知る限りこのテーマに関する最も包括的な入門資料である可能性が高い。
    特に「GPTがXをできないというバイラル投稿は再現しない」のセクションがよかった。周囲の人たちがこの技術を見るときに批判的に考える方法を学ぶ助けになってほしい。

  • 素晴らしい動画だ。今後使えそうな新しいコツをいくつか学んだ。
    ただ何かを試してみるだけでも、新しい用途が見つかる。
    少し前に良い例があった。住所が入ったスプレッドシートを地図レイヤーとして使うためにGeoJSONへ変換する必要があったのだが、かなり面倒に感じていたので、ChatGPTがどれくらいうまく処理するか試してみた。
    最初のステップとして緯度/経度のペアを与え、度/分形式を十進数に変換してほしいと頼んだところ、問題なく計算過程を示してくれた。次に緯度/経度の列全体を渡し、計算過程は表示しないように頼むと、出力もうまくできた。
    続いてプレースホルダー付きのサンプルJSON構造を作り、データを渡すので列名でプレースホルダーを埋めてほしいと頼んだ。データを貼り付けると、JSONを完璧に生成した。
    興味深かったのは、別途指示しなくても緯度/経度の変換をもう一度行い、私が言及していないid属性もインクリメントしてくれた点だ。かなり印象的だった。

  • Jeremyは私が尊敬する人物で、Queenslandで生まれ住んでいる身としては、世界的な才能が本当に身近なところに存在しているのだと思い出させてくれる。
    もちろんどの分野にもそういう人は多いだろうが、Jeremyは私が知っていて深く尊敬している人の一人だ。