LangChainと一緒に使う4つの異なるモデル(FLAN-T5 XL、FastChat-T5、StableVicuna、WizardLM)の結果と利点、欠点について説明します。
公開日:2023年5月11日
※動画を再生してから、インタビューを読むのがオススメです。
OK。
前回のビデオでは、ChromaDBを使ったマルチドックレトリバーにインストラクターのエンベッディングを追加することを見ました。
これは、埋め込みをローカルモデルで行うことを意味しますが、OpenAIはまだ使っています。
このビデオでは、OpenAIを完全に削除することを検討します。
というわけで、まだ動画を見ていない方は、私が投稿しているチャンネルをご紹介します。
定期的に見たい方はぜひご登録ください。
LangChainのビデオ、大規模言語モデルのビデオをたくさんやっています。
なるほど。
ではまず、この中で4種類のモデルを使って、これらを使った結果をお見せします。
また、LangChainなどのリトリビューションQAでこれらのタイプのモデルを使用するときに、目にする利点と欠点についても少しお話します。
最初に選んだのは、網羅的にリストアップしているわけではありません。
他のモデルをベンチマークするビデオをまた作るかもしれません。
最初に紹介するのはFLAN-T5 XLというモデルです。
これは30億のパラメータを持つモデルです。
Seq2Seqモデルです。
T5モデルの1つです。
基本的にはエンコーダーとデコーダーが搭載されています。
ですから、これを導入するときは、Seq2Seq言語モデリング用に導入する必要があります。
もう1つ、パイプラインでこれをセットした場合、Seq2Seqモデルでテキストからテキストへの生成を必ず行う必要があります。
そこで、まず、このモデルを持ってきます。
論文やPDFファイルを持ち込むのは当然ですが、まずはモデルを持ち込んで、そのモデル用のパイプラインをセットアップし、LangChainのHugging Faceパイプラインをセットアップして、そのモデルを使用するようにします。
そして、それが正しく機能するかどうかをテストしています。
つまり、ここで定義したローカルLLMを使って、生のプロンプトを実行し、そこから何が得られるかを見るだけです。
あとは、前のビデオでやったことと比べると、非常にシンプルになります。
基本的には、すべてを取り込み、PDFを含むドキュメントを取り込むだけです。
このビデオを初めてご覧になる方は、他のビデオもご覧になってみてください。
こういう部分について、私がたくさん話しているのがわかると思います。
このために様々なテキスト分割を行い、そしてここにインストラクターのエンベッディングをセットアップしています。
これで、GPU上で2つのモデルを実行することになりました。
これらの問題が発生する可能性もあります。つまり、埋め込みモデル(それほど大きくはありません)と言語モデル(はるかに大きくなります)の両方を実行するのに十分なGPU RAMがあることを確認する必要があります。
これらのデータベースは、ここで作成します。
データベースを削除して復活させるとか、そんな面倒なことはしません。
興味がある方は、以前のビデオを見てください。
レトリーバーを送り出す。
ここで、OpenAIのようなものとは異なり、ローカルのLLMとの付き合い方について考えなければなりません。
OpenAIでは、4,000のトークンがあります。
FLANの基本モデルでは、512個のトークンがあるだけです。
長く設定しようとしたとしても、512にしか設定できないことを教えてくれます。これは、トレーニングされたものです。
なるほど。
さて、基本的にデータベースをセットアップしたら、次はレトリーバーが必要です。
そして、ここが重要なポイントになります。
トークンの数とは、どれだけのコンテキストを渡すか、ということです。
今回は3つにしています。
しかし、おわかりのように、この中に例があればいいのですが、どうしてもうまくいかない場合があります。
この場合、トークンの数が多くなりすぎてしまうのです。
そこで、2枚にするか、それともどういう戦略をとるか、考えたいところです。
OpenAIの場合は、4,000個のトークンで遊べたので、このようなことを考える必要はありませんでした。
次に、チェーンを作ります。
鎖を作り、小さなラッパー関数を用意します。
フラッシュアテンションとは何ですか」と尋ねると、答えが返ってきます。
と尋ねると、答えが返ってきますが、あまり冗長な答えは返ってきません。
しかし、あまり饒舌な答えは返ってきませんし、あまり詳細な答えは返ってきません。
最も有用な回答は得られていないかもしれません。
I/Oアウェアとはどういう意味か」と尋ねると、「そうですね。
と聞くと、返ってくる答えがあまり良くないものもあります。
でも、中には大丈夫なものもあります。
では、どのAPIを呼び出すか、いつ呼び出すか、どんな引数を渡すか、そしてその結果を将来のトークン予測にどう反映させるかを決定するために学習したモデルをフォーマットすることとは?
ということで、技術的にはその通りです。
他のものに見られるような多くの情報を与えてくれるわけではありません。
ここではどのようなツールを使うことができるのでしょうか?
ここでも、非常に簡潔な答えと要点が求められています。
さて、非常に簡潔な答えが返ってきましたね。
このツールの中には、「これは全く良い答えではない」という答えが返ってくるものもあるようです。
文脈が512の範囲を超えている場合、エラーになりますよね。
この中に渡すには、トークンが多すぎるよ」と教えてくれるのです。
これがFLAN-T5ですね。
これは30億の基本的なものです。
GPT-4-allを作った人たちが作った、基本的にこれの微調整版と言えるモデルがもう一つあります。
これが「FastChat T5」です。
ですから、基本的にはこれを同じような方法で使って、これを持ち込むことができます。
そして、コードは基本的にすべて同じであることがわかると思います。
回答は、ある意味では少し良くなっていますが、冒頭で奇妙なパディングトークンが発生しています。
スペーシングに問題があるのは確かです。
ここでも奇妙なダブルスペースが発生しています。
確かに、奇妙な間隔があり、その理由はよくわかりません。
なぜそうなっているのかはよくわかりません。
このモデルは、微調整されているため、取得されたコンテキストから情報を抽出する点で、おそらく少し優れていることを示しています。
次に紹介するのは、もっと大きくした場合です。
StableVicuñaモデルのようなもので、130億個のモデルです。
これを持ち込むのです。
ここで、これとは別の問題に直面します。
というのも、ここではもっと長いコンテクストが可能なのです。
2048年までの文脈に対応することができるのです。
4,000までいけるかもしれませんね。
しかし、生のチェックをするとすぐに、プロンプトを特定の方法で処理するように作られていることがわかります。
つまり、これを実行すると、ちょっと困ったことになるのです。
つまり、このプロンプトは、ハッシュ、ハッシュ、ハッシュのような人間的なものを表示させたいと考えていることがわかります。
つまり、正しい情報を与えてくれているのですが、良い方法で与えてくれていないのかもしれません。
出力を見てみると、ここでは良い出力が得られていることがわかると思います。
フラッシュ・アテンションは、正確な注意を計算する新しい注意アルゴリズムです。
ちゃんとした出力が得られています。
どの程度なのかは分かりませんが、確かに、ここで得た文脈に注意を払っていることは確かです。
そして、「フラッシュ・アテンションはどのように機能するのか」と自問していきます。
そして、それはあなたにとって本当に役立つかもしれません。なぜなら、それはあなたが考えていた質問であるか、またはその場合もあるからです。
時には、それが実現することもあります。
そうでない場合もあります。
このように、本当に素敵な答えが返ってきましたね。
ここでも、かなり良い答えが出ましたが、その後、また、自分自身に質問するようになります。
ToolFormerです: ここでも、質の高い回答が得られています。
全体として、このような結果になったと思います。
私たちの課題は、基本的に正規表現を書いてこれを取り除くかどうかということです。
そして、プロンプトの前処理と後処理を行うことができます。
そうすると、課題の1つは、「なるほど」となります。
プロンプトを書き換えるだけで、このようなことができるのでしょうか。
そこで、プロンプトを見ながら、実際に書き換えてみることにします。
このように、プロンプトを何らかの形式に書き換えることで、実際に動かしてみて、「よし。
これでうまくいくか?
実は、多くの場合、うまくいきません。
あまりにいじりすぎると、「十分な情報を提供できるほどの文脈がありません」と言われるだけです。
もっと情報を提供してください。
この場合、興味深いのは、この質問に対して、何らかのコンテキストが得られるということがわかるからです。
おそらく、この特定の質問に対しては、この論文から得るのがベストだったのでしょう。
だから、最高の文脈を得ることはできないかもしれませんが、これらのモデルが、他のモデルも、ここから何かを得ることができるように見えるのは、ちょっと面白いことです。
ですから、私たちが問題にしているのは、検索部分ではないと思います。
どちらかというと、この部分に問題があるような気がします。
ですから、このプロンプトを書き換えて、自分の選んだ特定のモデルに適したプロンプトができるまで、いろいろと遊んでみたいものです。
というわけで、小さなものをいくつか見てきました。
大きなものも見てきました。
最後に保存したのは、スイートスポットのようなものだと思います。
これがWizardLMです。
このように、普通に持ち込むだけなのですが、これがLLaMです。
これはLLaMaモデルです。
LLaMaのトークン化をしているのがわかりますね。
因果関係言語モデリング用のLamaもあります。
そして、今回は1024トークンになるように設定しました。
生テストをしてみてください。
はい。
出力は実に良好です。
これはいい感じです。
その他の設定も、通常と同じように行います。
それを通過してください。
そして質問を始めてください。
両者のいいとこ取りをしているのがお分かりいただけると思います。
非常に徹底的な回答を得ていますが、StableLMプロンプトの問題は発生していません。