Join the Webinar
Loading...
セッションについて
このチュートリアルとプレゼンテーションでは、長文テキスト向けの transformer ベースの embeddings について掘り下げ、BERT 風のモデルが再帰型ニューラルネットワーク（RNN）よりもはるかに優れた性能を発揮する理由に関する理論の一部に焦点を当てます。そこから、「sentence-transformers」ライブラリを活用したいくつかの例に進み、感情分類、クラスタリング、そして RAG など、さまざまなタスクでの利用方法を紹介します。
学べること:
- 長文テキスト embeddings の背後にある理論
- 実際のアプリケーションで sentence-transformers を使用する方法
私はChristy Bergmanです。ここZillizでデベロッパーアドボケイトをしています。本日は、本日のセッションであるtext Embedding Modelsチュートリアルと、ゲストスピーカーのFrank Liuをご紹介できることを嬉しく思います。彼はここZillizのオペレーションディレクター兼ai、MLの責任者です。ようこそ、Frank。ありがとう、Christy。
ええ、ここに来られてうれしいです。では、今すぐ始めます。皆さん、それでよろしいですか？彼らは話せないと思います。わかりました。ええと、いいえ。
お二人に確認したかっただけですが、とにかく、はい。皆さん、ありがとうございます。本日このセッションにお越しいただいた皆さん、ありがとうございます。ええと、今日はtext embedding modelsについて、より広くお話ししたいと思います。
そして皆さんにあらかじめお伝えしておきたいのですが、これは初心者から中級者向けのセッションです。ですので、もしあなたがディープラーニングに本当に本当に詳しい方であったり、embedding modelsがどのように機能するのかを本当に本当に深く理解したい方であったり、自分のアプリケーションにはどのembedding modelを選ぶべきか？そして特に、今日embedding MALに関して行われている、本当に本当に興味深い最先端の、先端的な研究にはどのようなものがあるのか？ということを知りたい方であれば、それについて少しお話しします。特に、embedding modelを選ぶ際に注意すべきいくつかの点について少しお話しします。ただしこれは本格的な、これは、いわば研究の深掘りでも、たくさんのarchive論文などを掘り下げるものでもありません。
これはtext embeddingsの非常に非常に高レベルな概要であり、注意すべきいくつかの点についてです。そして特に、プレゼンテーションの終盤で、sentence transformersを使ってembeddingsを生成する方法のチュートリアルを行います。ただ、これを大きく二つのパートに分けるつもりです。最後にチュートリアルがあります。その前に、このプレゼンテーションでは、理論について少し、そして、私たちが今日いる場所にどのようにたどり着いたのか、これらのembedding modelsの歴史について少しお話ししたいと思います。
ですので、まず少し、私たちのembeddingsとは何か、そしてそれらに関して私たちが今日いる場所にどのようにたどり着いたのか、ということについてお話しします。もし本当に、Bend modelsについて考え、そしてそれらがlarger language modelsとどのように関係しているのか、またそれらをvector databaseの中でどのように使えるのかを考えるなら、私はそれらは本当に本当に過小評価されていると思います。そして私がよく皆さんに伝えたいことの一つは、bend modelsはAIアプリケーションにとって本当に主力であるということです。その証拠は、遠くを見る必要はありません。hugging phaseにありますよね？そして、かなり人気のあるtext embedding modelであるAlman L six V twoを見ると、先月だけで500万回以上ダウンロードされています。そして、非常に非常に人気のあるlarge language modelであるLAMA twoを見ると、もちろんアクセスにはいくつかの障壁があり、hugging face以外にもllama twoを使う方法はあります。
しかしhugging faceは依然として最も人気のあるものの一つです。先月hugging phaseでのダウンロード数は70万、700,000程度、100万未満です。ですので、世の中にあるembedding modelsの純粋な数、そしてembedding dataを生成する方法の数を考えると、embedding modelsが私たちにとって本当に本当に重要であることが皆さんに明確であればと思います。特に、retrieval augmentationを活用するだけでなく、あなたのデータをVector databaseに詰め込むだけでなく、他の形式のデータについても考えるアプリケーションを考える場合です。画像について考えれば、それらをembedできます。動画や音声について考えても、それらもembedできます。グラフのようなものさえembedできますし、そのようなものもembedできます。
私、えーと、何だっけ、Christie？わかった、とにかく続けますが、えー、でも本当によく考えてみると、私たちはさまざまな異なる種類のデータを埋め込むことができます。だからこそ、埋め込みモデルは私たちにとって本当に、本当に重要なのです。そしてだからこそ、それらを使いたいと思うし、その仕組みを本当に理解したいと思うわけです。さて、この特定の講演、この特定のウェビナーは、えー、テキスト埋め込みモデルに焦点を当てますよね？特に、非常に、コンポーネント、検索拡張生成における検索コンポーネント、そしてデータをベクトルからベクトルデータベースに取り出し、さらに取り出す方法に焦点を当てますよね？ではここから続けます。まず埋め込みの歴史について少し話します。えー、これが皆さんの一部にとってかなり興味深いものになればと思います。
えー、実は私はコンピュータビジョンの人間です。ですから、その昔にはsift特徴量、えー、あるいはコーナー検出器と呼ばれるものがありました。右下にあるものは、たぶんHarrisコーナー検出だと思います。そしてこれが、埋め込みを生成する方法でした。えー、当時それらは特徴記述子と呼ばれていました。昔は、ほら、2000年代初頭、そして2000年代後半にもそうでした。
そして、えー、これらの、いわゆる手作り特徴量または手作りアルゴリズムを使っていました。画像の一部を表現する方法を考え出すのです。そして、えー、CIF特徴量やコーナー検出器の場合には、その画像の一部を表現する方法を考え出し、それらの特徴量を使い、それらを袋に詰め込むようなことをしていました。えー、そしてそれらすべての特徴量が、その画像の表現になるわけです。えー、明らかにかなり非効率的でした。
1つのデータに対して非常に多くの特徴量がありました。えー、そして、えー、たとえばTF IDFの場合には、それがその方程式です。皆さんの中にはその方程式を見覚えがある人もいるかもしれません。右上隅にあるのがTF IDFです。それにより、ほら、これらの多くの、これらのベクトルの多くは非常に、非常に大きく、疎でもありました。
ですから、それは本当に昔の話ですよね？そして今日では、埋め込みを生成するはるかに効率的な方法があると思います。えー、これは実際にはArise Phoenixのスクリーンショットで、えー、私が本当に、本当に気に入っているプロジェクトです。そしてこれは、ある意味で何を示しているかというと、ニューラルネットワークから生成するこれらの本当に、本当に高次元の埋め込みを実際に取り、それがumapを使って三次元でどのように見えるかを可視化してくれるということです。そして、えー、ここではこのプレゼンテーションでumapの細かい複雑な部分には踏み込みませんが、実際には、これを高次元空間を取り、それを本当に圧縮して、えー、この本当に、本当に大きな埋め込み空間の中で何が起こっているのかを正確に可視化できるようにするものだと考えることができます。
しかし現在では、以前のように画像ごとに非常に多くの、ほら、非常に多くの特徴記述子があったり、あるいはテキストを表す本当に、本当に長い疎ベクトルがあったりしたのとは違い、画像やテキストを表すために、またさまざまな異なるモダリティをすべて同じ空間内でまとめて表現するために、非常に、非常に圧縮された、えー、固定長のベクトルを持つことができますよね？そしてそれこそが、テキスト埋め込みに関して私たちが今日いる位置について本当に、本当に素晴らしい点であり、えー、それを超えた埋め込みモデル全般についても同様です。そこから、えー、今、埋め込みの歴史について少し良い理解ができているといいのですが。えー、そして、ほら、埋め込みの歴史とベクトル検索の歴史は非常に、非常に長いものです。ですから、ほら、ベクトルデータベースはここ1年か2年で本当に人気になりましたが、ベクトル検索自体は、ほら、ずっと、ずっと長い間存在してきました。
そして今日は、テキスト埋め込みを生成するいくつかの方法について話したいと思いますよね？ええと、まずはリカレントニューラルネットワークから始めます。そして、ええと、昔ながらの方法にも触れます。リカレントニューラルネットワークの背後にある考え方は、この、ここにある青い箱のようなものを使えるということです。これがニューラルネットワークです。これに入力、ええと、隠れ状態を与え、さらにトークンを与えます。そのトークンは通常、ええと、つまり、そのトークンは通常、埋め込みとして、またはこのリカレントニューラルネットワークに与えるスパースな one-hot 入力として表現され、何らかの出力を返します。
リカレントニューラルネットワークには本当に多くの異なる種類があります。たとえば、ええと、単一の隠れ状態を与えて、その後のすべての隠れ状態を取り除くこともできます。あるいは、ある種の encoder decoder アーキテクチャのようにすることもできます。そこでは必ずしも、各状態ごとにニューラルネットワークの出力を読み取るわけではなく、たとえば separator token を与えて、文を完成させるよう求めるまでは出力を読みませんよね？できますし、今日私たちが transformers を使うような方法でも使えます。ええと、でも考え方としては、それは単一のモデルであり、そのモデルにデータを継続的にフィードバックして、正しい出力、あるいは最終的に望ましい出力を得るということです。
そして特に、これらのリカレントニューラルネットワークから実際に得られる埋め込みについてです。セルの種類によっては、内部埋め込みの1つを使うこともできます。以前にそうされているのを見たことがあります。通常は、一般的にはこの隠れ状態が欲しいので、この図では a of T として表されている隠れ状態が、リカレントニューラルネットワークにフィードバックされます。そしてそれが、つまりそれが保持するもの、ええと、それが、ええと、その、リカレントニューラルネットワークに少し記憶を与えるようなものです。
そしてこれは、テキスト埋め込みを生成する本当に昔ながらの方法です。現在では、それを行うもっと強力な方法があります。ええと、具体的には transformer encoders です。ええと、そしてご存じのように、この、このセッションは transformers を深掘りするためのものではありません。Bert と GPT の違いや self attention、ええと、あるいは self attention のさまざまな変種、transformers を訓練するさまざまな方法について深掘りするためのものでもありません。むしろ本当に高いレベルでは、ええと、Transformers、enc、transformer encoder はトークンのシーケンスを受け取り、出力として埋め込みのシーケンスを返すものだと考えられます。
そして入力と出力のこれら両方のシーケンスは、同じ長さになります。つまり、トークンごとに1つの埋め込みが得られます。そしてそれには明らかに多くの制約がありますよね？表現という点では非常に非効率です。多くの場合、先ほど述べたように、長いテキストや画像全体が欲しいわけです。そのすべてを1つの埋め込みで表現したいのです。この方法のほうが、検索や retrieval を行ううえでずっと効率的です。
ええと、そして少し先に早送りすると、transformer paper は2017年に出ましたが、そこから少し先に早送りすると、たしか20 20 19年に Bert がありました、ええと、そして Bert は本当に、まあ、pre-training のアイデアを導入したわけではないと思いますが、bi-directional pre-training のアイデアを transformer encoder architecture に適用しました。そして再び、ええと、これは、あの、Burt がどのように機能するかについての素晴らしい記事はたくさんありますし、ええと、Burt の本当に、いくつかの複雑な点についての記事もたくさんあります。そして興味がある人には、ぜひ Burt paper を見に行くこと、ええと、あるいは Burt についてのオンラインチュートリアルをいくつか読むことをおすすめします。でも本当に、結局のところ、それは、pre-training と transformer encoder によって、自然言語理解を活用するさまざまな異なるアプリケーションで本当に、本当に強力な結果を得られることを示した方法でした。ええと、そして繰り返しますが、これらすべて、Transformer encoder と Bert、これらすべては、ええと、使っていません、mass language modeling を使っています。
causal modeling は使っていません。だから GPT や Bard や Llama のように next token prediction を行うことを目的としているのではなく、文を受け取る、あるいは長い形式のテキストを受け取り、表現を与え、その文で何が起きているのかを本当に理解する、あるいはコンピューターが理解するのを助けることを目的としています。そうでしょう？ ただし birth にはまだ問題がありますよね？ ええと、まだ transformer encoder architecture を使っています。つまり、ここにあるこの図を見ると、ええと、少し複雑ですが、大丈夫です、何が起こるかというと input token があり、embedding の数があり、output は input の token の数と同じになります。そして Bert が通常、2つの文書が関連しているかどうか、あるいは、ええと、あるいは transformer encoder の何らかの variant が判断しようとする方法は、実際には2つの文、あるいは長い形式のテキストの2つの部分を取り、そこに separator を追加し、それから最後に、すべての token にまたがって classification layer を追加する、というものです。そして、失礼、すべての embedding にまたがって、持つことができ、ええと、それはある種、これら2つの文が関連しているかどうかについて、0 1 の間、あるいは negative one と one の間の値を与えてくれます。
それは本当に非効率です。なぜなら、文のすべてのペア、あるいは query document pair のすべて、ええと、あるいは symmetric または asymmetric pair のすべてについて、1回の inference を行わなければならないことを意味するからです。このプロセス全体には多くの非効率が存在していますよね？ transformer inference について考えると、それは安くできることではありません。そしてもし私が何十万もの文書を持っていて、input prompt を比較したい場合、retrieval augmentation をしている場合、あるいは document search をしたい場合、input query を10万件の文書と比較しているので、ML model に対して10万回 inference を行わなければなりません。もちろん、それをすべて並列化することはできますが、それには多くの計算能力が必要ですし、それは非常に、非常に、物事を行ううえで依然として非常に、非常に非効率な方法です。たとえ、2つの文あるいは2つのテキスト片が互いに関連しているかどうかを本当に理解するための、より良い表現方法、ええと、より良い方法があるとしてもです。そこで、もう少し先に早送りすると、たしか、ええと、speral も2019年に出ました、うーん、それとも2020年だったでしょうか？ はっきり覚えていません。
その点については私の言葉を引用しないでください。でもそれは追加します、takes stock します。つまり、あの、通常の pre-trained transformer encoder を取り、それに2つの layer を追加します。1つ目は pooling で、2つ目は、ええと、新しい objective function を与えることです。つまり、sentence bird の場合、実際には、使用できる3つの異なる objective function があります。
できます。分類目的関数があります。コサイン類似度があり、トリプレット損失もあります。これは、ええと、この特定の図はコサイン類似度を示しています。2つの文の間で、2つのテキスト片の間で、どのように回帰を行うかを示しています。これは、ええと、それは、理解するのが非常に、非常に難しいものではありませんが、私が思うに、それは、ええと、それは、今日私たちが埋め込みを生成する方法を本当に変え、再形成したものです。
そして私は主張したい、2024年の今日でさえ、ほとんどのテキスト埋め込みモデルは何らかの種類の sentence bird に基づいていると主張したいです。もちろん、例外はたくさんあります。そこには、ええと、いくつもの、本当に、本当に最先端の論文がいくつもあります。文埋め込みを生成するのを助けるために畳み込みを使うことに戻る論文もいくつか見たことがあります。しかし今日の非常に、非常に人気のあるモデルのほとんどは、私が示したものも含めて、少し戻りますが、この図で示したものも含めて、ここでもう少し。そしてここに残っているもの、Al lm も含めて、これは sentence Burt と sentence Burt の一種だと私は主張します。
それがすることは、単に埋め込みを本当に効率的に生成する能力を与えてくれるということです。そして sentence Burt として、sentence burnt モデルまたは sentence transformers モデルを訓練するときに起こることは、ええと、これらの文ペアがあるということです。それらは標準的な burt を通過し、そこで、最後の最後にプーリングを受けます。これは非常に、非常に重要です。なぜなら、もし思い出すなら、この従来の、または、ええと、元の Burt アーキテクチャでは、元の、元の transformer encoder では、各トークンに対して1つの埋め込みを得ますが、これはかなり、検索の観点からすると今のところかなり非効率です。私たちはそれらすべてのトークンにわたってプーリングし、それからファインチューニングするか、またはニューラルネットワーク全体を、検索をはるかに、はるかにうまく実行できるようにする何らかの新しい目的で再訓練します。つまり、例えば20トークンずつの2つの文がある場合、ベクトルデータベース内に保存する必要がある、あるいは類似性検索を行う必要がある40または43のトークンを持つ代わりに、ここで起こることは、今や2つのトークンだけになるということです。なぜなら、これら2つの、ええと、これら2つの結果の出力をプーリングしたからです。
そして私は、使いたい目的関数を使って、モデル全体を再訓練しています。コサイン類似度の目的関数を使って、ベクトルデータベースのような検索システム、ええと、またはそこにある他の種類のベクトル検索ソリューションで非常に、非常に効率的に実行できる類似度目的関数を使っています。そしてそれが本当に sentence の核心ですよね？では、話すことのポイントは何でしょう？ああ、そしてこれ以上進む前に、これは buying coder と呼ばれます。そしてこれはテキストごとに1つの埋め込みを与えてくれます。そしてそれこそが本当に私たちが望むものです。長文テキストに対する圧縮された単一の埋め込み表現が欲しいのです、そうですよね？そして、ええと、話す前に、そして、考えてみると、私たちが最初の段階で、本当にやりたい目標は、データの一片を取ることです。
この場合、それは長文テキストであり、私たちはそれを圧縮表現、単一の埋め込みへと変換し、その埋め込みが私たちが行っていること、生成しようとしているものを代表するものになり、できれば私たちのアプリケーションに適したものになることを望んでいましたよね？そして見てみると、先に進めると、ええと、この一部について少し先出ししたのですが、今日のテキスト埋め込みモデルを見ると、ええと、そのほとんどが sentence Burt の何らかのバリエーションであり、ええと、それらは、うーん、それらは Burt にある、次文予測をマスクする典型的な自己教師あり事前学習を持っています。そしてその後、そのモデルを訓練するために、何らかの対照損失やトリプレット損失を使います。そしてこれらのモデルで見られる変更の多くは、実際にはほとんどがデータに関連していますが、時折、モデルアーキテクチャや訓練戦略の変更も見られます。うーん、たとえば sparse attention のようなものを活用するかもしれません。ええと、Roberta はそうしていると思います。
ええと、それらはランダムなトークンをマスクする代わりに、任意のトークンだけをマスクしたり、あるいはまったく別の目的関数を使ったりするかもしれません。しかし結局のところ、本当に、ええと、これらのモデルの多くが動作する方法、その基盤は sentence birth にあります。それらは sentence transformers の中にあります。そしてそれこそが、これらのテキスト埋め込みモデルに関して、今日 sentence transformers を私たちにとって非常に重要なものにしているのです。もう一つ本当に注意すべきこと、そしてこれについては、今後のチュートリアルで少し話しますが、非常に、非常にデータ依存性が高いということです。
うーん、いわゆる対称または非対称の埋め込みを持つことができます。対称埋め込みとは、ええと、すみません、対称または非対称のテキストのことです。非対称とは、たとえば、ええと、プロンプトとドキュメントのマッチングです。一方で対称テキストは、単に二つの文が同じことを意味しているか、同じ意味的意味を持っているかを理解しようとするものです。そして異なる、理想的な状況としては、テキストの異なるドメインごとに異なるモデルを持つことです。そして voyage AI はこれを行っている、あるいは行う予定だと思います。
ええと、たとえば、ええと、金融業界向けの埋め込みモデルを持つべきです。もしアナリストレポートを読んだことがあるなら、これらのレポートが異なる言語を持っていることがわかりますよね？それらは、うーん、たとえば、ええと、New York Times に載っているものや、あるいは、ええと、Wall Street Journal やこうしたニュース媒体にあるもののようには読めません。同様に、ええと、アーカイブ論文も金融レポートや他の文書とは異なる読み味があります。そして私たちがこうした種類の文体に慣れるのに時間がかかるのと同じように、これらの文体や文章の形式に適応するモデルも必要です。そして最後になりますが、テキスト埋め込みモデルは、たとえ、その中には、たとえば、30 2K トークン長や 1 K トークン長を持つものがあるとしても、私が思うに、あなたが行っていることは、非常に、非常に長いテキストを取り、それを単一の固定長埋め込みへと凝縮または圧縮しようとしているということです。通常これは、ええと、3 3 84 または 7 68 であり、あるいは今後のチュートリアルで見るように、埋め込みの長さは実際には 10 24 だと思います。
埋め込みの次元数は、おおよそ1つの段落に相当するんですよね？つまり、スイートスポットはだいたい100から200トークンあたりで、それはおおよそ1つの段落に相当するんですよね？皆さんに注意しておきたい、注意しておきたいのですが、ええと、チャンクサイズはいろいろ試してみる必要があります。万能な戦略というものはありませんが、私の経験では、ほとんどのモデルについて、だいたい100から200トークンの間くらいが、データをどれくらいチャンク化したいか、つまりそのカットオフとして良い目安だと思いますよね？テキスト埋め込みに関しては注意すべきことがたくさんあり、結局のところ、どれがベストなのかを問うのは役に立ちます。そしてこれは、実は昨日スクリーンショットを取ってきたものです。これは実際には検索からのものだと思います。Hugging Face の MTEB リーダーボードに行くと、これは実際には retrieval タブです。
つまり、これらのさまざまなモデルすべての性能が表示され、さまざまなデータセットの平均に基づいて順位付けされますよね？ええと、たとえば、重複質問をたくさん尋ねるものなど、いろいろです。そしてこれらはすべて、結局のところ、もちろん鵜呑みにしないでください。単にモデルがずっと大きいという理由で性能が高いものもあります。ご存じのように、これらの多くのモデルは同じデータの多くで学習されています。アーキテクチャにいくつか違いがあるかもしれませんが、結局のところ、その多くは、これからのチュートリアルで見るように、sentence BERT や sentence transformers に基づいています。
そして、そうですね、これについては以前、ええと、以前の開発者向けAIミートアップのような場でも少し話しました。もし私に、私のアプリケーションに最適な埋め込みモデルは何かと尋ねるなら、それはアプリケーション要件に非常に、非常に大きく依存すると答えますよね？まず第一に、何をしたいのかです。データのドメインは何で、何をしたいのか？分類に関心があるのか？検索、再ランキングに関心があるのか？アプリケーションのさまざまな部分には、それぞれ異なるモデルがありますよね？これを理解することは非常に、非常に重要です。2つ目は、自分のモデルをファインチューニングするのに十分なデータがあるか、ということです。ええと、もしあるなら、事前学習済みのものを持ってきて、それに対してファインチューニングすればよいのではないか、ということですよね？たとえば、MTEB リーダーボードにあるもののいくつかを取ってきて、それらに対してファインチューニングできます。どれくらいのレイテンシを許容できるのか、ですよね？もし非常に、非常にレイテンシに敏感であれば、ええと、おそらくより小さなモデル、ええと、GT や bge small のようなものを選びたくなるでしょう。そして false positives を許容できるのか？もしそうでないなら、もう少し特化したもの、もう少しドメイン固有のものが欲しくなります。先ほど少し触れたように、多くの場合、金融文書や法務文書があります。
特定の業界や特定のバーティカルに合わせて調整されたものが欲しいわけです。そうすることで、ベクトルデータベースだけでなく、埋め込みモデルからも最高の性能を引き出せますよね？アプリケーションを開発していく中で、何を多く使いたいのかを考えていく中で、これらの多くは非常に、非常に重要です。もし今回の発表、この特定のセッションで、ひとつだけ持ち帰ってほしいことがあるとすれば、それは唯一の正解はないということです。ええと、その多くは非常に、非常に依存的であり、モデルを学習すること、あるいは社内にデータサイエンティストがいるならモデルを学習したり、モデルを選んだりすることです。もしいないなら、ええと、これは本当に、多くのトレードオフが関わるものであり、結局のところエンジニアリングの問題です。どのモデルを選ぶべきか？どれが自分のアプリケーションに最適なのか？というわけで、だいたい半分のところに差しかかっていますが、ええと、たぶん残り20分くらいあります。ええと、ここで皆さんにお見せしたい簡単なノートブックのようなものがあります。たぶん時間いっぱいはかからないと思います。
それでは最後に少し時間がありますので、そこで、ええ、出ている質問にお答えできます。ただ、ええ、実際には別の、別のタブに切り替えます。ええ、最後にもいくつか質問を受け付けます。別のタブに切り替えます。いい質問ですね、Frank、その間に。うーん、画像にexpert variationsをどのように適用するのですか？ああ、それは素晴らしい質問です。
Expertは通常テキスト専用ですが、世の中には多くのマルチモーダルモデルがあります。たとえば、clipで訓練された任意の、任意のモデル、つまりclipデータセット上の事前学習済みvision transformersがあり、実際に適用できますし、expertドキュメントにも画像への適用、マルチモーダルmalsを画像へ適用するためのセクションがあります。ただし、画像にsensor transformersを使う予定なら、bold imagesとテキストをサポートできるモデルを持っていることを非常に、非常に慎重に確認する必要がありますよね？私が注意したいのはそれだけです。ええ、最後に少し時間があれば、どうやるとよいかを実際に示せるか見てみます。ええ、ええ、ただ注意点として、マルチモーダルモデルを使う必要があります。
純粋なテキストembeddingモデルは使いたくないでしょう。また、もう一つ付け加えると、clipのようなものを使う場合、純粋なテキストの性能は、ええと、非multi-mobileモデルを使った場合よりも少し悪くなります。では、この特定のnotebookにはだいたい3つのセクションがあります。とても、とても短く簡潔です。うーん、いくつか別の、ええ、ここに投げ込むいくつかの異なる、まあランダムな例もあります。
皆さんが、まあ、異なるembeddingsの生成を試したいのであれば、聴衆からの例も喜んで受け付けます。うーん、それから最後に、ええ、ええ、すべてをまとめることについての最後の短い説明がありますよね？このセッションの多くの方々はおそらくLlama indexやlang chainを使っていると思いますし、最後にそれについても少し、少し話したいと思います。ただその前に、うーん、これも、ええ、このnotebookもどこかオンラインで利用できるようにするか、または、または、最後にこのnotebookリンクをメールで送ります。ただ、このチュートリアルには2つのライブラリが必要です。send TransformersとNovusです。そしてNovusについて興味深いことの一つは、組み込み版があるということです。
多くの、いや、それほど多くの人がこれを知っているわけではありませんが、ええ、それはNovus Lightと呼ばれていて、実際にpip install Novusするだけで、Jupyter Notebook内で実行できるvector databaseを入手できますよね？なので実際には、私は、これら両方をすでにインストール済みのはずです。だからこれはかなり、かなり、すごく速く進むはずです。ええ、ここで最初にやることは、a、model、sense transformer modelを作成することです。非常に、非常に簡単で、非常に、非常に使いやすいです。そしてそれがSense Transformersで私が気に入っていることの一つです。ここに戻って、これがMt a leaderboardだと見てみると、私は実際にそこに載っているモデルの一つ、ええ、現在トップモデルの一つと見なされているものを使っています。後で見るように。
このモデルにも独自の制限がありますよね？ただ、まず私がやることは、モデルをインスタンス化することです。本当にそれだけ簡単です。そして、もしこのモデルをまだダウンロードしていなければ、これは事前学習済みモデルなので、ええ、続行する前に実際にモデルのweightsをダウンロードしに行きます。この場合は、すでにモデルをダウンロードしているので、これは、まあ、呼び出せる、最大シーケンス長がいくつかを確認できる、と表示されます。そしてこの場合、それが512であることがわかります。そしてこれをbangに変えるには、正直とても簡単ですよね？単にencodeすればいいだけです。うーん、まあ、いろいろ、いろいろ、いじって試せることがあります。
たとえば、ええと、それをエンコードして、NumPy配列ではなくテンソルを返すように頼むことができます。この例ではそこについてはあまり気にしません。ええと、そしてそれが埋め込みを返すのがわかります。この埋め込みに対して dot shape を行うと、この埋め込みの次元数は 10 24 です。なので OpenAI の埋め込みは、ええと、たしか 7 68 だと思います。ほかにも、この特定のケースでは 1536 になり得るモデルがありますが、Ember V one では、これは、ええと、10 24 次元ベクトルを返す埋め込みモデルで、これは、まあ、かなり標準的な次元数でもあります。
でも、今やりたいことの一つは、この埋め込みを取りたい、ということです。そうでしょう？そして皆さんに、ええと、ここで、密な埋め込みの力と限界を示したいと思います。そして、アプリケーションによっては、自分自身のデータセットを持ち、これらの事前学習済み埋め込みをファインチューニングできること、あるいは単に標準の Bert を取り、自分のデータでファインチューニングすることが、なぜそれほど重要なのかを示したいと思います。なので、ここに 5 つの文があります、5 つの文がありますね。最初は Zills is vector data store. That is amazing. です。2 つ目は unstructured data can be semantically represented within embeddings. です。3 つ目は特異値分解に関連しています。
4 つ目はチェスに関連しています。そして 5 つ目は、ええと、つまり、5 つ目は、ええと、ああ、うーん、たぶん実用主義についての文です。猫が黒いか白いかは問題ではなく、ネズミを捕まえる限りよい、というものです。そして私がやろうとしていることは、このモデルを使って、これらすべての文を互いに比較することです。なので sentence transformers に、このモデルでこれらすべての文をエンコードするように依頼し、その後、この sentence transformers が提供している特定のユーティリティ関数を使って、これらすべての文と元の文との間のコサイン類似度を計算します。
では、これをやってみましょう。ではここで試してみましょう。この場合のコサイン類似度は、コサイン距離の逆、反対です。したがって数値が高いほど、結果が高いほど、2 つの文はより関連しています。そしてわかるように、これは実際かなり理にかなっています。意味的にもかなり理にかなっています。
Zillow is a vector data store that is amazing と、Zillow is an awesome vector database の比較です。この 2 つはほとんど同じ意味です。ええと、この場合のコサイン類似度が 0. 93、つまり非常に、非常に 1 に近いというのは非常に納得できます。繰り返しますが、コサイン類似度は、ええと、コサイン類似度とは通常得られる値であり、どれほど似ているかを決定するもので、2 つの文が互いにどれほど似ているかを決定するものです。
そしてまた、私には、私にはわかります、つまり、それが継続的に低下していくこともわかります。Unstructured data can be semantically represented with embeddings と Zillow is an awesome vector database は、それほど関連していませんが、それでもまあ、ある程度はあります。なのでこの場合、この特定のモデルによると 0. 57 というスコアになります。ええと、そしてそれはさらにどんどん下がり続けます。
下がり続けるのは、これらの文、これらの長めのテキスト片が、私の最初の埋め込みに関連していないからです。そうでしょう？非常に、非常にシンプルです。残り 5 分、ええと、残り 5 分です。はい、わかりました。よし。なのでかなりシンプルです。
そして、すでにこれらの Ben 埋め込みには、たくさんの、ええと、たくさんの、そこには、たくさんの情報がエンコードされていると思います。それは見て取れると思います。でも、さらに、うーん、2 つ別の例も見ていきたいと思います。それらは引き続き、これらの埋め込みの強みと、また限界を示すものだと思います。そして最初にやるのは、うーん、ええと、これを覚えているか見てみましょう。ええと、I like green and ham.
これをやってみましょう。そしてそれから、I、うーん、enjoy consuming、うーん、green な m and x です。そしてこれをやると、実際には、わかりました、これは 1 に非常に、非常に近いと言います。繰り返しますが、1 は最大値で、類似度が 1 ということは、それらが同一であることを意味します。うーん、そして非常に、非常に近いです。つまりこのモデルは、この 2 つが非常に、非常に似ていると考えているということです。
実際、これもできるんですよね？つまり実際にそれができて、コサイン類似度が1になるのがわかりますが、これの限界も示したいと思います。なので、このコサイン類似度をやってみます、let's eat。すると、最初の文は、let's eat Chris。2つ目の文は、let's eat Chris。そしてこの2つは、ここにある句読点のせいで、実際には非常に、非常に異なる意味になります。
最初のものは、ええと、つまり、Chrisという名前の人に私が話しかけて、ねえ、行こう、ランチを食べに行こう、あるいは夕食を食べに行こう、何か食べに行こう、と言っていると考えられます。そして2つ目の、2つ目の文は、そのカンマを取り除いたので、非常に、非常に異なる意味になります。つまり、これは、おそらく普段言うようなことではありませんが、モデルの出力を見てみると、確かにそれほど高くはありません。0. 9未満で、この場合はかなり良いのですが、それでもかなり高い値です。たとえこの2つの意味が意味論的には非常に、非常に無関係であっても、ですよね？let's eat comma crisp と let's eat crisp と言った場合、この2つは非常に、非常に異なることを意味します。
では、なぜこの両方の例を見せたのか？それは、これらの埋め込みの力を示すためですが、同時に、ここには多くのニュアンスもあることを理解してもらうためです。もし自分のアプリケーションに本当にうまく合うものが欲しいなら、こうしたデータを使って自分のモデルをファインチューニングしたくなる可能性がありますよね？そして、埋め込みから最大限の価値を引き出したいなら、これは本当に、本当に重要なことだと理解する必要がありますよね？なので、ええと、今後これらのdancetechs埋め込みを扱う際に、ちょっと覚えておいてほしいことです。ええ、それから、モデルをファインチューニングする方法について簡単な例を示したいと思います。かなり簡単です。ええと、sense Transformersは、この、ええと、入力例のようなもの、ええと、ああ、この、この、このクラスを提供しています。そしてできることは、単に、トレーニング例のセットを渡すことです。
非常に、非常に大きなデータベース、ええと、これらの例のデータセットがある場合は、これらの例をDiscからストリーミングすることもできます。そしてできることは、単純にトレーニングを、ええと、ここでは2つの例しか使っていません。なぜなら、いろいろあって、つまり、もっとあったとしても、まず第一に、このノートパソコンにはGPUがありません。ええと、そして第二に、もしたくさんあったら、非常に、非常に長い時間がかかるからです。しかしトレーニング後には、ええと、つまり、すべて、ええと、形状は同じですが、ええと、ここでの結果は少し異なるものになりますよね？なので、ええと、これを再実行すると、重みが実際に少し更新されていることがわかります。ええと、これはまだ同じになりますが、これらの結果、コサイン類似度は今は少し異なっています。
これは、これらが実際に機能していることを示しています。最後に取り上げたいことは、残り1分しかないのはわかっていますが、これらをベクトルデータベースに挿入することです。そして、ええと、本当にかなり、つまり、皆さんにぜひ示したいのは、Novusを使えるし、Mils Lightを使ってこれらを非常に、非常に簡単に挿入でき、そしてそれらすべてに対して本当に、本当に大規模な類似検索を実行できるということです。この場合、私がやっているのは単に、Nobusからデフォルトサーバーをインポートして、それを起動する、と言っているだけです。非常に、非常にシンプルで、ええと、自分のモバイルベクトルデータベースのインスタンスを立ち上げて実行する非常に簡単な方法です。それが終わったら、実際に、ええと、それへの接続を作成できます。
標準的なデータベースであるかのように使えます。コレクションを作成して、それから先ほど計算したそれらの埋め込みをすべてベクトルデータベースの中、この default という名前のコレクションに挿入しますよね？するとここで、これらをすべて正常に挿入できたことがわかります。特定のタイムスタンプが付いています。すべて終わったら、サーバーを停止してデータもクリーンアップできますよね？えー、この2つの呼び出しは逆にすべきでしたが、大丈夫です。ええ、この特定のノートブックについては、かなり駆け足でした。では、皆さんからのご質問をお受けします。
えー、では皆さんからのご質問をお受けしますので、えー、チャットに投稿、貼り付けてください。そこから進めていきましょう。はい、ありがとうございます、Frank。えー、Q&A は見えていますか？えー、いくつか読み上げることもできます。ちょっと待ってください。見えます。
では、最初の質問は Keen からです。お名前を間違えていたら申し訳ありません。質問は、対称型と非対称型についてです。動的クエリや保存されたドキュメントの取得について語られているのを見ます。逆方向にはどうすればよいのでしょうか。たとえば、この記事に最も適した図書館の件名標目はどれか、というような場合です。これは素晴らしい質問です。
それで、特定のドキュメントに対するプロンプトやクエリを作成するために大規模言語モデルを使う、かなり興味深い最近の研究があります。つまり、大規模言語モデルは本質的に多くの情報をエンコードしているので、えー、それによって、すみません、Web のぼやけた圧縮袋、というのは大規模言語モデルについて聞いた呼び方の一つですが、実際に LLM に保存されている知識を使ってプロンプトを生成したり、クエリを生成したりできます。そして実際、それは本当に非常にうまく機能します。もしドキュメントがあるなら、えー、そのドキュメントをチャンクに分割して、LLM に潜在的なクエリを生成するよう依頼できます。
たとえば、「あなたはエキスパートの検索者です。このドキュメントを検索するために使える潜在的なクエリやプロンプトを生成してください」と言えます。あるいは、人間が書きそうで、その結果そのドキュメントが返されるような潜在的なクエリやプロンプトを生成してください、というような感じです。プロンプトをいろいろ試したくなるでしょうが、実際には、いわゆる教師なし、あるいはラベル付きデータなしでデータを生成するための優れた方法です。基本的には LLM を使ってラベル付きデータを生成する、すみません。2つ目の質問は Frank Greco からです。私たちの埋め込みは言語をまたいで機能しますか。言い換えると、英語からの埋め込みを使ってイタリア語の補完を生成できますか？えー、答えは、モデルによります。つまり、一部の埋め込みモデルについては、ほとんどの埋め込みモデルは、十分なイタリア語と英語のテキストを見ていない限り、箱から出してすぐにイタリア語を理解できるわけではありません。しかし、たとえ英語を見ていたとしても、もしモデルが英語とイタリア語の両方のテキストを見ていて、これら2つの言語の間に多くの関係があることを理解しているなら、できることとしては、実際には、たとえば特定のドメインの英語テキスト、たとえば法律文書があり、学習データには同じ種類のデータがない場合でも、イタリア語で書かれた法律文書に関連する埋め込みを作成すると、実際にはかなり高い性能を示すでしょう。
繰り返しになりますが、もしトレーニングデータにイタリア語が含まれていないなら、純粋な、ええと、純粋な英語の、英語の埋め込みモデルから何らかの結果を期待すべきではありません。単純に、そのトークナイザーがそれらのイタリア語の単語を見たことがないからです。ですが、たとえ異なるドメインのデータがあっても、モデルがこれら両方の言語を一緒にマッピングできる方法がある限り、実際にはかなり妥当な結果を得ることができます。素晴らしい質問です。ところで、sentence expert がエンコードできる文の長さに制限はありますか？ええと、答えはノーだと思います。確認し直す必要がありますが、ただ覚えておいてほしいのは、transformer は二次的であり、ええと、少なくとも dense attention は入力長に対して二次的なので、たぶん、ええと、この場合、ええと、実際にここでライブで試してみますので、動くか見てみましょう。
ええと、最大シーケンス長は 5 12 です。実際には、ええと、10 24 にできます、おっと、10 24、そうでした。なので 10 24 にできて、基本的にこれらすべての埋め込みをやり直すことができます。そして、見ていただければわかるように、はい、できます。ただし、ご存じのとおり、トークン長が増えると、まず第一に、埋め込みの品質に関して収穫逓減が起こりますし、場合によっては埋め込みが悪化することさえあります。第二に、大量のメモリがない限り、あるいは、大量の、CP もしくは GP メモリがない限り、トークンがどんどん増えるにつれて、そうした制限にぶつかることになります。繰り返しになりますが、ええと、transformer は必ずしも非効率というわけではありませんが、入力長に対して二次的であるだけなのです。
句読点は、文字や単語、埋め込みと統合されるためにどのようにトークン化されるのでしょうか？ええと、それはトークナイザーによりますし、ええと、ほとんどのトークナイザーでは、句読点は実際にはそれ自体が独立したトークンです。ええと、残念ながら、ここでそれに答えることはできません、Brian。繰り返しますが、モデルによりますし、私が使ったトークンにもよります。ええと、ただ通常は、ええと、そうですね、ええと、ほとんどのトークンについては、4〜6文字くらいが1トークンだと考えられると思います。keen からの asymmetric embeddings に関するフォローアップの別の質問です。
記事からクエリやプロンプトを生成したくはありません。記事を既存の主題見出しフレーズと照合したいのです。このために LM は必要でしょうか？なるほど、おっしゃっていることはわかります。ええと、私の理解では、そして、もし間違っていたら訂正してください、記事があり、それから、あるいは1つの記事があり、それから既存の主題見出しやフレーズのセットがある、ということですね。ええと、やっていることが単にこの2つを照合しようとしているだけなら、LM は必要ではなく、標準的な埋め込みモデルを使えますよね？ええと、埋め込みモデルは、sentence transformers の素晴らしいところは、いわば入力の順序、あるいは、その、その、入力の順序が問題にならないということです。なぜなら、最終的にやっていることは、これらの、これら2つの文書セット、ええと、あるいはこれら2つのコーパス、2つの文書コーパスを一緒にトレーニングしているからです。
そして、それぞれの長文テキストごとに、実際には単一の埋め込みが得られます。ですので LLM は必要ありません。その場合、特別なことをする必要はありません。普通に照合するだけで、特定の文書に対して最も関連性の高い、ええと、主題見出し、ええと、またはタイトルを得ることができます。さて、質問は以上だと思います。ほかにあれば別ですが、Christie。
ええと、いくつか質問が見えます。たとえば質問は、ええと、埋め込みにはセマンティック検索以外に、ええと、どのような用途がありますか？セマンティック類似性以外には？ああ、はい、それは素晴らしい質問です。もし、もし実際に mt a リーダーボードに行ってみると、ええと、かなり多くの、そうですね、さまざまなモデルがあり、4つの異なる用途があります。たとえば、クラスタリング、ええと、要約、再ランキング、検索、Q&A などがあります。ですから、プロンプトをドキュメントにマッチさせることを超えて、埋め込みを使えるさまざまなことがたくさんありますよね？そこで、あなたが何をしたいのか、アプリケーションが何を必要としているのか、ええと、それを本当にしっかり理解して、その特定のリーダーボードから埋め込みモデルを選ぶのがよいです。ええと、それを踏まえて、ええと、それから多言語埋め込みについての質問がありました。
たとえば英語以外を話す場合、ええと、これらの埋め込みは使えますか？はい、多言語埋め込みは、ええと、まず第一に、トークナイザーがさまざまな種類の文字を理解できるように、複数の言語にわたって学習されています。そして、ええと、これらの多言語埋め込みは、そうですね、先ほど少し触れましたが、たとえある言語のデータ領域があって、それを、ええと、別の言語に拡張しようとした場合でも、その第二言語のその領域が元の学習データで見られていなかったとしても、それでもかなりうまく機能します。ですから、はい、多言語埋め込みは、たくさん存在しますし、sense もかなり多く提供しています。今日のこのセッション、このセッションでは、そこにはあまり深く踏み込みませんでした。ええと、でも間違いなくそういったものはたくさん存在し、それらも非常に、非常に強力です。
わかりました。では、ええと、テキストではなく画像を埋め込みたい場合はどうでしょう？はい、はい、素晴らしい質問です。ええと、何をしたいかによります。なので、単に画像を埋め込みたいだけなら、ええと、私は実際には PyTorch image models、TIMM を見てみると思います。つまり、pip install TIMM するだけで、たくさんの事前学習済み画像埋め込みモデルが手に入ります。マルチモーダル検索をしたい場合は、少し選択肢が限られますが、clip dataset で、ええと、Leon、L-A-I-O-N 上で学習されたモデルであれば、発音が正しいかはわかりませんが、ええと、あなたの特定のアプリケーションに対して非常に、非常にうまく機能します。
では、Q&A ウィンドウで最後の質問を1つ受ける時間があると思います。はい、見えています。はい。特定の質問や検索クエリに対する応答として、ドキュメント内で最も関連性の高い段落をどのように特定できますか？特に、ドキュメント全体を単一の埋め込みに変換している場合には？これが sentence transformers の素晴らしさであり、テキスト埋め込みの素晴らしさです。ええと、そうする必要はありません。ドキュメント全体を埋め込みに変換すると、内部的な、ある種の内部コンテキストを失います。ですから、その長文形式の、その圧縮された埋め込みを使って、非常に具体的な段落を取り出すことはできません。
しかし代わりにできることは、段落に関心があるなら、単純にテキストを段落にチャンク分割し、段落に分けて、それぞれの段落を埋め込むことです。ドキュメント全体を埋め込む必要はありませんよね？それがテキスト埋め込みの素晴らしさで、ええと、それらはトークン数に対して固定長ではありません。そして短い形式のテキストを長い形式のテキストとマッチさせることもできます。さて、今日は時間があるのはここまでだと思います。では、Frank、ありがとうございました。
そして、ええと、discord へのリンクを投稿しました。ぜひそこで皆さんにオンラインでお会いできることを願っています。そしてご参加ありがとうございました。皆さんありがとうございます。そして Christy、ホストしてくれてありがとう。
Meet the Speaker
Join the session for live Q&A with the speaker
Frank Liu
Director of Operations & ML Architect at Zilliz
Frank Liu is the Director of Operations & ML Architect at Zilliz, where he serves as a maintainer for the Towhee open-source project. Prior to Zilliz, Frank co-founded Orion Innovations, an ML-powered indoor positioning startup based in Shanghai and worked as an ML engineer at Yahoo in San Francisco. In his free time, Frank enjoys playing chess, swimming, and powerlifting. Frank holds MS and BS degrees in Electrical Engineering from Stanford University.