Join the Webinar
Loading...
何を学べますか？
検索拡張生成（RAG）は、2023年以降に登場した大規模言語モデルアプリケーションの中で最も人気のあるスタイルです。RAGの最も基本的なスタイルは、データをベクトル化し、Milvusのようなベクトルデータベースに投入して検索を行い、LLMによって生成されるテキスト出力を拡張することで機能します。これはまだ始まりにすぎません。
RAG、そしてAIを拡張できる方法の一つは、多言語のユースケースを通じたものです。典型的なRAGは、英語で訓練された埋め込みモデルを使用して英語で行われます。この講演では、RAGが英語以外の言語でどのように機能し得るかを探ります。フランス語、中国語、ポーランド語を取り上げます。
取り上げるトピック：
- RAGの仕組み
- テキストを埋め込む方法
- 複数の言語が埋め込みモデルとLLM内でどのように相互作用できるか
本日のセッション「Multilingual Rag 入門」と、ゲストスピーカーの Gin Tang をご紹介できることを嬉しく思います。Gin は、Amazon で auto ML に取り組むソフトウェアエンジニアとしての経歴があります。彼はコンピューターサイエンス、統計学、神経科学を学び、IEEE、big Data などのカンファレンスで発表された研究論文、論文があります。彼はバブルティーを飲むことが好きで、確認済みです、ええと、家族と過ごすこと、そして水辺にいることも好きです。ええと、Eugene、ようこそ。
ええと、ありがとう、Emily。はい、バブルティーが大好きです。ええと、では。皆さん、こんにちは。ええと、私の名前は Yu Eugene です。
ええと、今日は Multilingual Rag についてお話しします。では、ええと、ええと、現在は Zillow のシニアデベロッパーアドボケイトです。そしてこのスライドは基本的に、皆さんが私に連絡するためのさまざまな方法を見つけるためのものです。ええと、私に連絡する最良の方法は LinkedIn 経由で、画面右側にある QR コードからアクセスできます。ええと、Emily が言っていたように、私のバックグラウンドはソフトウェアで、機械学習に取り組んできました。
機械学習の研究をたくさん行い、論文として発表しました。ええと、そして 2021 年から NLP に取り組んでいます。そして、ええと、この 1 年ほどで多くの rag アプリや AI エージェントを構築してきました。そして今日は、皆さんがどのように multilingual rag、つまり、ええと、さまざまな言語での rag を構築できるかについてお話しします。では、ええと、本日の講演内容ですが、まず rag のレビュー、RAG とは何かの復習から始めます。ええと、これはさまざまな rag のトピックについての短い解説になります。
それから LMS と embedding models に入ります。そこで、LMS の短い、ええと、歴史を取り上げ、それらを embedding models と比較します。ええと、これは昨年、ええと、私の講演でよく出てきたことで、ええと、人々は LMS と embedding models の違いについて多く質問していました。ですので、ええと、これらの違いについて少しお話しします。それから vector databases について話します。
ええと、vector databases は rag アプリケーションを構築するうえで不可欠です。そしてその後、デモに入ります。RAG を使う主な理由は基本的に、自分のデータを注入したいからです。ええと、データを LLM に注入したいわけですよね？つまり LLM を扱うとき、ええと、通常は何らかの汎用モデルを扱っており、そのモデルはアクセスしてほしいデータにアクセスできません。あるいは、ええと、ご存じのように、あなたのプライベートデータは一般的に、ええと、LLM の学習に使われることはありません。ですから、ええと、自分のデータ上で Allen を動かすためには、rag を使う必要があります。ええと、これにより、この種の事実に基づく想起が可能になります。
ええと、またコスト最適化にも有効です。なぜなら、コンテキストをある程度取り込み、コンテキストウィンドウや使用するトークン数など、こうしたあらゆることを調整できるからです。そしてこれは本番環境にとって非常に重要です。これは、rag の、ええと、セットアップの rag モデルの一般的な、ええと、図です。そうですね？では、左下の、ええと、角から始めます。そこがあなたのデータです。基本的に rag のセットアップでは、データを取り、それを embeddings model に入れます。embeddings model を通します。
モデルはベクトルを生成し、それらのベクトルは vis のような vector database に入ります。そしてクエリ時、実際に、ええと、あなたの、ええと、アプリケーションを使うとき、クエリは LLM に送られます。LLM は vector database で何を検索する必要があるかを判断し、その検索を再び embeddings model に送ります。これにより、その、ええと、その検索のテキストがベクトルに変換されます。そしてそれは vis のような vector database に送られ、viss でいくつかのベクトルを検索し、その後、ええと、それらのベクトルを metadata とともに LLM に返します。metadata にはテキストが含まれます。そしてそれが、LLM があなたの質問に答えられる仕組みです。
これはRAGの基本的な概要にすぎず、ここで扱うのは本当にそれだけです。では、LMSと埋め込みモデルの違いについて見ていきましょう。RAGの動機とその仕組みを理解するためには、LLMについての歴史や背景を少し知っておく必要があります。LLMは、ええと、LMSはニューラルネットワークの一種で、ニューラルネットワークは基本的に70年代に始まりました。その考え方は、基本的にはいくつかの数値を入力し、さまざまな計算を行い、その入力に関する何らかの予測、回帰、分類、あるいは何らかの出力を得るというものです。そうですよね？ええと、これは基本的なディープニューラルネットの図で、基本的には一連の数値となる入力を受け取ります。それを通して、いくつかの計算が行われ、そして隠れ層、ええと、特定の出力層へと渡されます。
そして出力層は、その入力に関する何らかの予測を与えてくれます。さて、進化するにつれて、ええと、つまりニューラルネットワークに取り組んでいく中で、ニューラルネットワークが進化するにつれて、特定の用途に非常に適した特定の種類のニューラルネットワークがあることがわかってきました。テキストや言語に関して、非常に有用だとわかったニューラルネットワークの一種が、リカレントニューラルネットワークでした。ここにある図は、リカレントニューラルネットワークの1つの層、あるいは層の中のニューロンを示しているだけです。そしてこれを展開すると、時間に沿って入力を取り込み、それらを再利用していることがわかります。
そのため、リカレントニューラルネットワークは時間の経過に伴うトークンを追跡することができます。そして、このコンテキストを追跡する能力があるため、つまり、時間の経過に伴うトークンを追跡する能力があるため、テキストを見るための何らかのコンテキストやコンテキストウィンドウを持つことができます。しかしRNNにはまだ問題があり、一定の長さまでしかコンテキストを保持できませんでした。この問題を解決するために、Transformerモデルが導入されました。Transformerモデルは入力を受け取り、基本的にその入力が何らかのエンコーダーに入り、エンコーダーが隠れ状態、行列の集合、ベクトルの集合、何であれ、それを作成します。
そしてその隠れ状態は通常、追加の入力と組み合わされます。それは、ええと、アテンション行列になります。つまり、2つの行列を取り、それらをデコーダーに入れると、デコーダーが何らかの出力を出します。これは、基本的に短いコンテキストウィンドウという問題を解決するうえで非常に役立ちました。そしてこれにより、はるかに、はるかに長いコンテキストウィンドウを持てるようになりました。今でもLMSについて話されるときに、コンテキストウィンドウというものが話題に上るのを聞くでしょう。そうですよね？つまり、あるモデルは8,000のコンテキストウィンドウを持っています。
あるモデルは4,000のコンテキストウィンドウを持っています。あるモデルは100万のコンテキストウィンドウを持っています。そしてコンテキストウィンドウは基本的に、そのモデルの構造の仕方によって、ええと、取り組まれるものです。そしてこれが、ある意味でGBTにつながります。GBTは、ええと、ご存じのように、最先端の、こうした最先端モデルの1つであり、GBTはデコーダーのみのアーキテクチャを使用しています。本質的にそれが行うことは、文や単語を受け取り、トークンと位置埋め込みを計算し、それから予測された次のトークンを出力する、ということです。そうですよね？つまりGPTが行っているのは、次のトークンが最も可能性が高いものは何かについての予測を与えることです。
つまり、テキストを生成しているのですが、そのテキストはあくまで予測なのです、いいですか？そして基本的にこの例で、ここで見ているのは、もし the chicken walked を取り出して、それを、ええと、GPT に送ると、across the road そして文末、つまりピリオドを生成するということです。そしてこれが本質的に言っているのは、GPT に the chicken walked という単語を与えると、次に最もありそうな単語は a cross だと予測するということです。そして the chicken walked across の場合、次に最もありそうな単語は the で、さらに the chicken walked across the の場合、次に最もありそうな単語は road です。そしてそれが文の終わりになります。これは、GPT が持っているデータから予測しているためです。
つまり、GBT はオンラインで見つかる大規模なデータコーパスで学習されています。そして通常オンラインで見ると、鶏が道路を渡ることについてのものをたくさん見ることになります。何か他のものを渡るとか、何か他のことを歩くというよりもです。つまりそれが lm です。では埋め込みモデルはどうでしょうか？埋め込みモデルは、ベクトルを生成する方法であり、本当に何からでもベクトルを生成できます。どんな種類の、ええと、非構造化データや構造化データからでもベクトルを生成できます。
つまり、画像、動画、テキスト、音声、ええと、DNA の例から生成できます。つまり、こうしたさまざまなものすべてを埋め込みに変換できるのです。しかし秘訣は、最後の層で予測を行う代わりに、そうですよね？先ほどニューラルネットワークについて話したとき、ニューラルネットワークは最後に予測を持つと話しました。埋め込みとは、ニューラルネットワークから得られる、ある種のデータの、ええと、表現、内部表現です。つまり、データをニューラルネットワークに渡すと、各層が何らかの計算を行い、そのデータの定量化可能な表現を、ええと、与えてくれます。そしてそのデータには意味的な意味が含まれます。
つまり、ニューラルネットワークの最後の層、最後から 2 番目の層は、そのデータからニューラルネットワークが学習したものを出力しますが、何らかの予測を与えるわけではありません。そしてそれがベクトルであり、それが意味的類似性検索を行うためにベクトルデータベースに入れるものです。ではこのセクションを簡単に振り返ると、LLM は大規模なモデルで、それが大規模言語モデルと呼ばれる理由です。ええと、それらは予測によってテキストを生成します。何らかの推論能力を持っている、あるいは少なくとも何らかの推論能力を持っているように見えます。
そして一般的なアーキテクチャは transformer アーキテクチャに基づいています。埋め込みモデルはより小さく、transformer に基づいている必要はなく、テキストを生成することも、予測を与えることもありません。本質的には、ええと、ニューラルネットワークの内部層の出力を埋め込みとして取り出しているのです。さて、ベクトルデータベースについて話しましょう。ベクトルデータベースは、意味的に類似したデータを見つけるためのものです。
ですので、もし私がこの 3 つの文を提示したとします。apple made profits of 97 billion in 2023. I like to eat apple pie for profit in 2023. そして apple's bottom line increased by record numbers in 2023. そして、これらの文のうちどれが、ええと、あるいはこれらの文のうちどの 2 つが他のものに最も似ているか、ええと、または最も似ているかを尋ねたら、ええと、あなたは何と言いますか？これはインタラクティブなプレゼンテーションです。
もし文 1 と 2 だと思うなら、それをチャットに入れてください。もし文 1 と 3 だと思うなら、それをチャットに入れてください。もし文 2 と 3 だと思うなら、それをチャットに入れてください。そうですよね？つまり、ええと、ベクトルデータベース以前は、テキスト全体の検索はキーワード検索によって行われていました。そしてキーワード検索では、特定のキーワードを探すことになります。
そしてもし私が AppleProfit と 2023 の例を探したとしたら、最初の 2 つの文が返ってくるでしょう。しかし実際には、ええと、ああ、皆さん誰もこの質問に答えていないのが見えます。ええと、実際には最初と 3 番目の文が最も似ているものです。おお、すごい。
ありがとうございます。はい、どなたかが質問に答えてくれました。素晴らしいです。次のスライドには、もう一つインタラクティブな部分が出てくるので、皆さん準備ができているといいなと思います。実際には、1文目と3文目が意味的に最も似ています。
ですので、もし最も似ている文を検索するなら、1文目と3文目を返してほしいわけです。しかし、ベクトルデータベース以前に行っていたようなキーワード検索をすると、最初の2つが返ってきたでしょう。これは、ベクトルデータベースがどのように役立つかを示す例です。さて、これを使えるのはテキストデータだけではありません。画像データにも使うことができます。
ここに、私の好きなアーティストの一人であり、世界で最も人気のあるアーティストの一人でもある人物の写真が4枚あります。皆さんへの質問は、この中で他のものと最も似ていないのはどれか、ということです。これが写真1、これはTaylor Swift 1、これはTaylor Swift 2、これはTaylor Swift 3、これはTaylor Swift 4です。皆さんにぜひ推測してほしいのですが、どれが他のものと最も似ていないと思いますか？素晴らしいです。では、皆さんTaylor Swift
2が他のものと最も似ていないと言っていますね。皆さんがこのプレゼンテーションを以前に見たことがあるのかどうかは分かりません。次回は分けるかもしれません。次回は混ぜるかもしれません。でも、正解はTaylor Swift 2です。Taylor Swift 2は偽物のTaylor Swiftです。
これは、人間である皆さんが、人物のさまざまな写真の間でこのような類似性比較を行える例にすぎませんが、それは実際には機械に組み込まれているものではありません。したがって、機械がそれを行えるようにするには、物事を数学的に比較できる必要があります。そして、それがベクトルの仕組みに近いものです。ベクトル埋め込みは、私たちが数字として見ていないものを数学的に比較できるようにする、長い数値の列です。これはその仕組みの例です。
そして、この意味的類似性の例では、4つの単語があります。queen、woman、man、kingです。このスライドの要点は、もしこのスライドから何も持ち帰らないとしても、唯一覚えておくべきことは、単語に対する数学、あるいはもともと数字ではないものに対する数学です。そして、このスライドから持ち帰って覚えておいてほしい、非常に重要なもう一つの点は、最初の次元にこれらの単語があることです。queenとqueen、womanとkingとmanは、最初の次元に沿って同じ値を持っていることが分かります。
しかし、これは実際にはその最初の次元が何を意味するのかを教えてくれるものではありません。教えてくれるのは、これらの単語がその次元上で同じ関係を持っているということだけです。つまり、queenとwomanとkingとmanで最初の次元が同じだからといって、その最初の次元がジェンダーや性別などを意味するわけではありません。ただ、それらの単語がその次元上で同じことを意味している、というだけです。では、この数学的な例を取り上げますが、併せて覚えておいてください。これはおもちゃの例であり、本番環境で2次元ベクトルを見ることはありませんし、本番環境でManhattan距離を使う人を見ることもありません。
後で実際に目にする距離についていくつか話しますが、本番環境でManhattan距離を見ることはほとんどありません。ここで何が起こるかというと、queenからwomanという単語を引くと、0. 3 comm, 0. 9 minus 0. 3, comm 0.
4となり、zero comm 0. 5が得られます。そして、manである0. 5 comm 0. 2を足すと、0.
5,comm 0. 7となり、これはkingです。つまり、このスライドの考え方は基本的に単語に対する数学です。ええと、質問がありますね。ベクトルの次元数は、データがどれだけ類似するかにどのような役割を持つのでしょうか？ええと、ベクトルの次元数は基本的に、類似データを比較する際の粒度のレベルとして考えられると思います。
しかし実際のところ、そしてこれは後で見ることになりますが、重要なのは、ええと、重要なのは、つまり、次元数がいくつあるかは確かに重要なのですが、何十万もの次元に達するころには、うーん、かなり似たようなものになります。次元数を増やすにつれて、ええと、何でしたっけ、あの言葉は何でしたっけ？ 次元数を増やすと、うーん、収穫逓減のようなものが起きるんですよね？ うーん、実際に重要なのは、モデルが学習したデータです。わかりましたか？ では、人々が実際に使っているいくつかの類似度指標を見てみましょう。そうですね？ 先ほど、マンハッタン距離はほとんど使われないと言いました。では、密なファクターでよく使われる距離には3種類あります。最初はユークリッド距離で、これは L two です。
そして基本的にここでやっていることは、空間内の距離、空間内の距離の大きさを捉えることです。幾何学を履修したことがある人なら、皆さん全員そうだと思いますが、うーん、ピタゴラスの定理と呼ばれるものを覚えているでしょう。そこでは本質的に斜辺を計算し、空間内の距離を計算しています。これが基本的にユークリッド距離の背後にある同じ考え方です。そうですね？ ここにこの三角形を描くと、つまり、ベクトルを点として考えていて、ここにこの三角形を描くなら、これはそれらの間の距離で、斜辺としての距離です。わかりましたか？ これが1つ、1つの方法です。次に、内積があります。
内積は少し直感的ではありませんが、うーん、実際にはとても、とても良いものです。とても、とても、うーん、シンプルでわかりやすく、距離を得るためのとても美しい方法だと言えます。内積は、あるベクトルを別のベクトルに射影したものを測定しています。ユークリッド距離では、ベクトルを空間内の点として考えます。内積では、ベクトルを線を伴う点として考えます。
そして射影するとき、うーん、2つのベクトルにおける大きさと角度、向きの違いの両方の尺度を得ることになります。これが内積です。内積は射影を測定します。そして式からわかるように、これは非常にシンプルで、計算コストも非常に低いです。次に、コサイン類似度があります。コサイン類似度は、内積をベクトルの大きさの積で割ったものです。
つまり、内積の正規化版です。そして、コサイン類似度に特化して学習されたモデルを使っている場合を除いて、これを使うことは決してないでしょう。なぜでしょうか？ なぜなら、計算コストが高く、ベクトルの実際の大きさを抽象化して取り除いてしまうからです。しかしコサイン類似度は、2つのベクトル間の角度を測定しますよね？ つまり今見たのは、大きさ、大きさプラス角度、そして角度だけです。ここから、ある意味で、実際に何がより測定可能なのか、何がより多くの自由度、粒度の自由度を持っているのかを考えることができ、おそらく自然に、内積が最も多くの粒度の自由度を持っているという結論に至るでしょう。
そして内積または L two は、ほとんどの場合、私が使う類似度指標です。さて、コサインは非常に人気があり、オンラインでもよく使われています。うーん、その理由は、コサインが、2010年代後半に NLP が人気になり始めたときに、人々が測定し始めた最初の指標の1つだったからです。うーん、しかし多くの人がしがちなように、多くの人はその指標の人気のために、この尺度を盲目的に使ってしまいます。そして、もし指標を使うのであれば、それが自分の埋め込みモデルにとって正しい指標であることを必ず確認するようお勧めします。
では指標の復習です。ユークリッドは空間的距離を測定し、コサインは向きの距離を測定し、内積はその両方を測定します。そしてベクトルが正規化されている場合、内積とコサインは同じになります。わかりましたか？ そして今度はインデックスです。インデックスはデータにアクセスする方法です。そしてこれは非常に重要です。なぜなら、ベクトルについて考えると、何百、あるいは何千もの次元があり、それは実行すべき計算が非常に多いということだからです。
それを行うには、効率的で効果的な方法が必要です。そこで、その方法のいくつかには inverted file index が含まれます。これは基本的には K と n、いや、すみません、K はクラスタリングアルゴリズムを意味しますよね？つまりここでやっていることは、単にクラスターと OID を見つけることであり、基本的にはそれだけです。OID 図を作成しているのです。ですから、ええと、インデックスを作成するには k-means を行い、そしてそのインデックスを使うときは、基本的に検索して最も近い CIN を探し、それからそれらの OID からすべてのベクトルを取得し、それらの OID 内で最も近いベクトルを探します。次に hierarchical navigable small worlds、HNSW があります。ええと、HNSW はグラフアルゴリズムです。
そして本質的に行うことは、ビルド時にグラフを構築し、検索時にはその中に入ってグラフの一部を検索することです。HSW は exploratory factor と呼ばれるものを使います。ええと、これは基本的には一様ランダム、ええと、変数に対するカットオフです。もし私が 0. 9 の 0. 9 の一様ランダム変数を使うとしたら、何が起こるかというと、挿入時、ビルド時に、すべての vert、ええと、頂点ではなく、ええと、ベクトルがレイヤー 0 に挿入され、そして 0.
9 を超えるベクトルはレイヤー 1 に積み重ねられます。0. 99 を超えるベクトルもレイヤー 2 に入れられ、以下同様です。検索時には、最上位レイヤーから始めて下へ進んでいきます。これはグラフなので、ええと、検索は非常に高速で、既存のベクトル間の距離を計算するための計算量を少なくできます。
そして、これもかなり正確です。なぜなら基本的に、ええと、これらすべての、ええと、ええと、ベクトル値をかなり簡単に保存できるからです。では次に話すのは、次の 2 つは量子化についてです。量子化は基本的にはバケット化、ええと、アルゴリズムだと考えることができますよね？つまり、もし何らかの、ええと、データをバケットに入れるなら、実数を取り出してそれらを整数に変換するなら、それはバケット化の例です。基本的にそれが量子化の考え方です。つまり 0.
0 4, 3, 2 と考える代わりに、0 を持つことになります。そして小数点として考える代わりに、たとえば、わかりますよね、7. 1 と考える代わりに、7 のように持つ、ということです。わかりましたか？それが量子化というものです。そして product quantization は 2 次元にわたるスカラー量子化です。つまり、ええと、たとえばベクトル内の、ええと、値だけに対してではなく、ベクトルのブロック内の値に対しても行うということです。
そして基本的に、ええと、product quantization はさらに大きく圧縮できますが、ええと、それほど正確ではありません。わかりましたか？ではインデックスを本当に簡単に概観しましょう。IVF があります。これは直感的なインデックスです。K は中程度のメモリを必要とすることを意味し、OID を保持しているだけで、かなり高性能です。そして HSW があります。これはグラフベースです。
実行するにはより多くのメモリが必要ですが、非常に高性能です。そして flat があります。これは、ええと、基本的な、つまり、まあ、すべてのベクトルを総当たりするだけで、100 パーセントの recall、つまり精度の点では非常に、そうですね、高性能ですが、かなり遅く、メモリへの影響はありません。SQ はスカラー量子化です。つまりこれは 1 次元にわたるバケット化で、ええと、メモリは少なく、pq ほど正確ではありません。もう一度言うと、スカラー、量子化、プロダクト化、ええと、さらに少ないメモリ、さらに低い精度です。わかりましたか？ではそのような、そうですね、概要が終わったところで、デモに入りましょう。
ええと、デモに入る前に、ええと、今日は何を作るのかを説明します。3 つの異なるコード、ええと、例を見ていきます。そして、すべてのコード例が非常によく似ていて、主な違いはそれらのデータ、ええと、コレクションであることに気づくでしょう。そして基本的に私たちが行ったことは、vis と lang chain と OpenAI を取り、それらを組み合わせて、3 つの異なる言語で動作するいくつかの rag アプリケーションを作ったということです。フランス語のものが 1 つ、中国語のものが 1 つ、そしてポーランド語のものが 1 つあります。
ええと、こちらがスキャンできるQRコードです。チャットにも掲載されています。それでは、デモに入る前に、もし何か差し迫った質問があれば、いくつか質問を受け付けます。ええと、AIエージェントとコストの大きさについて質問している方がいますね。おそらくLLMが最も高価な部分でしょう。いいですか？質問がなければ、ええと、プレゼンテーションに関して、あ、ありますね、はい。
複数の言語を含むドキュメント自体を扱う場合の最適なアプローチは何ですか？それは本当に良い質問です。ええと、実際にできることとしては、これはかなり複雑なやり方なので例ではやりませんでしたが、埋め込みを実行してくれるエージェントを作成し、どの埋め込みを、どの埋め込みモデルを使うかを判断させることができます。すべての埋め込みモデルが同じ次元数である限り、ドキュメント内で埋め込みたい言語に基づいて、どの埋め込みモデルを使うかを判断します。ええと、埋め込みの観点、または検索、VUSコレクション側では、すべての埋め込みが同じサイズ、同じ次元数である限り、それらを比較できます。それらは、比較可能です。異なる場合は、比較できません。
はい、素晴らしいです。ええと、デモに進めると思います。はい、これを小さくしましょう。どうせすぐにそれが必要になるので、それが必要になります。ええと、では基本的な正しい例から始めましょう。
正しい基本的なragの例は持っていないですよね？はい。ええと、では中国語の例を見るところから始めます。先ほど言ったように、これらのragアプリケーションを構築するこのプロセスで最も難しい部分は、実際には正しいデータを収集することです。ここでやっているのは、複数の都市にまたがってこれらのRAGアプリケーションを構築し、都市について質問するというものです。そのため、そのデータをrag経由でLLMに渡して質問に答えさせるために、Wikipediaから都市データをスクレイピングできる必要があります。
対象はAtlanta、Beijing、Berlin、Boston、Cairo、Chicago、Copenhagen、Houston、Karachi、Lisbon、London、Moscow、Munich、Paris、San Francisco、Seattle、Shanghai、Tokyo、Torontoです。これらの都市のどこかから参加している方はいますか？先ほどSeattleから来ている方がいたのを見ました。ええと、私もSeattleにいるので、Seattleがんばれ。ええと、これらの都市のどこかから参加しているなら、教えてください。気になります。ええと、Chinese版で最初にやらなければならなかったこと、そしてFrench版でも、さらに、ええと、ええと、ええと、Polish版でもやらなければならないことですが、ただしFrench版は実際かなり簡単でした。後でわかります。これらは都市の英語名です。
やらなければならなかったのは、これらを正しい言語に変換することでした。最初はWikipediaのAPIからそのままスクレイピングしようとしました。ええと、en wikipedia. orgとすると、それは英語版です。なので英語の都市名を使ったときは、全部スクレイピングできましたが、その後Zh do Wikipediaと入れてこれらの都市をスクレイピングしようとしたら、単純に、データがまったく取得できませんでした。ですから先ほど、多言語の話について質問があったときに言っていたように、最も重要なのはデータとデータ収集です。
そして、ええと、これらすべての都市を中国語に翻訳した後、このようにWikipediaからそれらをスクレイピングし、すべてのテキストファイルと中国語の都市が入ったexampleに保存しました。いいですか？それからそれに対してragを構築しました。ええと、あ、このテキストブロックは実際には間違っています、はい？この例では、ええと、もし一緒に進めたい場合は、Pine Elvis、lane chain sentence、transformers、tick token、ええと、この例では実際にはこれは必要ないと思いますが、OpenAIをインストールできます。そして、ええと、取得できます。あ、実際にはstandaloneは、この、ええと、ファイルはGitHubリポジトリにあります。なのでZ Shellでもbashでも、何を使っていても、ええと、使っているシェルで実行できます。
そして、ファイルを開始して、ええと、始めてください。うーん、つまり、これは実行しておくべきです。ええと、インストールに時間がかかるので、lane chain は非常に大きなライブラリです。Sand transformers もかなり大きいです。ええと、OpenAI はまあ大丈夫です。ここで最初に行うステップは、うーん、単に環境変数を読み込むことです。
そしてこの場合、OpenAI API キーを読み込むだけです。やっていることは load Mand で API キーを取得しているだけです。次に、LLM を取得しに行きます。ですのでこの例では、lane chain の OpenAI LLM を使うだけです。これは 3. 5 turbo だと思います。
そしてこれは、ええと、基本の、ええと、OpenAI の、うーん、LLM です。そして今度は hugging face embeddings を取得します。うーん、hugging face は多くの embeddings を持つモデルハブで、さらに mil this も import します。これは私たちが使う vector store です。最初にやることは embeddings を取得することです。つまりこの例では、私はこの特定の embedding モデル towns woo ええと、slash peg を使っています。
このモデルを使っている理由は、hugging face に行って MTEB、Mt e ええと、leaderboard を見てみると、これは中国語 embeddings 向けの主要なモデルの一つだとわかるからです。うーん、そして他にもより優れたモデルはいくつかありますが、それらはただ、ええと、はるかに大きく、ええと、計算コストの面で使用を正当化するほどには優れていません。そして、うーん、これを可能にするために lanechain からいくつかのものを import します。つまり character text splitter を使います。これはデータ、データのチャンクを分割する方法です、そうですよね？それで、データを見に行くと、データはこのように見えることがわかりますが、この全体を embed するのは意味がありません。
ですので私たちが望むのは、うーん、私たちは、ええと、これを適度なサイズのチャンクに分割できるようにすることです。そしてそこで character text splitter が出てきます。それから、この lane chain、この lane chain document というものもあります。これは基本的に、blank chain 向けに、ええと、vector databases へのエントリを作成する方法にすぎません。OS はただ、つまり、オペレーティングシステムです。基本的な shell functions に使います。
ここで私がやっているのは、これらすべてのファイルを一覧表示して、見えるようにしているだけです。これで、これらすべての Wikipedia ファイルがあり、すべて dot TFC であることがわかります。そして次に、file texts の空の list のようなものを作成します。そしてこの list は最終的に documents で埋められます。そしてこれが mobi に insert する方法です。
この list ができたら、すべての files を順に処理して、各 file を開き、各 file を読み込みます。そして character text splitter を作成します。そしてこれを、何らかの chunk size と overlap で作成します。これは本当にいろいろ試してみる余地がありますが、私は 5 12 64 がそこそこ良い default だと思っています。これは英語では、およそ 1 paragraph です。ええと、そしてこれはおよそ 1 sentence、短い 1 sentence です。
うーん、そして character text splitter ができたら、text splitter を使ってすべての filetexts を split します。そして次に、それらすべての split texts を loop して、それから documents を作成します。つまり page context というものを作成します。これには text が含まれます。つまりこれは vector と一緒に保存される metadata であり、実際に questions に回答するうえで非常に重要です。そしてさらに doctitle と chunk numbers も追加します。
これによって、それがどのドキュメント内にあったのか、そしてドキュメント内のどこにあったのかがわかります。ええと、それから時々わかると思いますが、pause があって、ええと、character text Splitter には、分割に使うトークンのセットがあり、文を完結させることができます。つまり、時にはより大きなチャンクになることがあります。そして、これらのチャンクがすべて揃って、すべてベクトル化されたら、それらを Vis のようなベクトルデータベースに入れます。ですので、ここに file texts と呼ばれるドキュメントのリストがあるのがわかると思います。そして embeddings、つまり embeddings 関数を使い、それからこのように Novus に接続します。
ええと、私は Novis をローカルホストのポート 19, 5 30 で実行しています。ここでこの standalone start を使って行ったことです。そして、それにコレクション名を与えます。この場合、このコレクションを Chinesecities と呼んでいます。なぜなら、これらは都市で、中国の都市なので、cities Chinese のように呼ぶほうが理にかなっているかもしれませんが、ええと、もう選択はされています。そして、そのベクトルデータベースができて、それに接続し、データを挿入したら、それを retriever として使います。
つまり retriever は lane chain 内のオブジェクトで、何らかの、ええと、Vector database からデータを取得できるようにするものです。次の部分ではプロンプトを作成します。プロンプトは、lms とやり取りする方法です。この場合、chat prompt template を作成し、それに「あなたは質問応答タスクのためのアシスタントです。質問に答えるために、以下の取得された context の断片を使用してください」と伝えます。
答えがわからない場合は、わからないと言ってください。最大3文を使い、答えを簡潔にしてください。そしてここでは、これは基本的な rag prompt のようなものです。そしてここで、中国語で答えるように言い、それから context 内の質問を与え、答えを生成するように伝えます。つまり、context 内の質問はどちらも、Python で S string を使っているかのように渡されます。
そして prompt template を作成し、それから link chain chain を作成します。この chain では、最初に行うことは、retriever から context を与えることです。これは関数であることに注目してください。そして質問を受け取り、その質問を関数として、runnable pass through function として扱います。これは、そのテキストをそのまま通すだけの関数という意味です。それだけです。
そして context と質問を取得したら、それらを prompt に入れます。これが、ここでこれらの値を埋める方法です。それからそれを LLM に渡し、LMS の出力が string output parser に渡されます。この例では、私は「東京でどんなランドマークを訪れるべきですか？」と尋ねています。すると中国語で何かを教えてくれます。実は、ええと、私は中国語を読めないのですが、東京のどこかに行くべきだと言っているようです。はい、これは読めません。はい。
ええと、それから実際に、ここにあるこの質問は基本的に「東京で何を訪れるべきですか？」というものです。ええと、ただ Google Translate を使って中国語に翻訳しています。ああ、実際にはこれをそのまま取って Google translate で何と言っているか見てみましょう。ええと、translate。これは、富士箱、伊豆国立公園、そして東京スカイツリーに行くべきだと言っています。そしてこれはおそらく非常によく似たことを言っているのですが、中国語で質問する場合と英語で質問する場合では、実際には異なる応答が返ってくることがわかります。これはポーランド語やフランス語のものでも同様に見られます。
そして、これが起こる理由は、embedding model が少し異なるものを embedding しているからです。言語間で質問が似ているからといって、実際のテキスト、実際のトークンは異なります。そのため embeddings model は異なるトークンを生成します。ですので、中国語のほうの答えは、東京タワー、皇居、浅草寺と言っていると思います。つまり富士山にはまったく言及すらしていないので、ちょっと興味深いです。
はい、これで基本的に、このようなアプリケーションをどのように構築すべきかの基礎はだいたいカバーできました。では次にフランス語版を見てみましょう。えっと、oops、あ、はい、OK。これらすべてについて、フランス語版で確認できるように、変更しなければならなかったのは北京をPékinにすることだけでした。これが北京のフランス語名です。つまり変更点はそれだけです。
そしてここでは、ZhやENではなくFr Wikipediaを使いました。それ以外はすべて同じです。そして、このテキストをすべてスクレイピングしたことがわかりますし、ほら、このテキストはすべて、えっと、ああ、Moscowもおそらく違いますね。まあ、ここにあるこのテキストがすべて、えっと、フランス語になっているのがわかりますね、OK？そして今、ragアプリケーションを構築するとき、えっと、これも間違っていますね、OK？ragアプリケーションを構築するとき、これらすべてのステップはまったく同じです。ですから、このテンプレートを文字通りそのまま使って、好きなデータに適用できます。確認しなければならない唯一のことは、えっと、正しいデータを使っていることです。
このテンプレートを使って、好きなものを追加できます。変更することを必ず確認しなければならない主なものは、これらのembeddingsです。お気づきのように、前回と同じembeddingsモデルは使っていません。ここではデフォルトのhugging face embeddingsを使っているだけです。デフォルトのhugging face embeddingsはフランス語でもかなりうまく機能します。実際、フランス語に最適なembeddingsはopen AI embeddingsです。えっと、それは後でわかりました。
えっと、それから、ファイルディレクトリとして渡すディレクトリを変更します。そして、ここで全ファイルを取得できていることを確認して、それからそれらを開いているだけだとわかります。同じように、chunk sizeやchunk overlapsはまだ調整して試せるものです。ここでも正しいfile directorを使っていることを確認してください。また、正しい、えっと、正しいデータが返ってくるように、collection namesを変更することも確認してください。
そしてもちろん、promptでは、何を答えてほしいのかを伝えるべきです。ですから中国語で答える代わりに、今度はフランス語で答えてほしいわけです。そしてこれはすべて同じです。今回は、Karachiについて歴史的事実を教えて、と尋ねました。oops、Karachiについてですね。すると、だいたいこんな感じで返答します。見てみましょう。
Karachiの何が興味深いのでしょうか。Karachiは紀元前3世紀のTheosの植物史で初めて言及されました。19世紀初頭にイギリスによって占領され、1839年にSindの首都になりました。1876年には、Pakistanの将来の建国者であるMohamed Ali JinaがKarachiで生まれ、埋葬されました。まあ、彼が同じ年に生まれて埋葬されたとは思いませんが、まあそういうことです。これはLMのハルシネーションの例です。
えっと、同じ質問をフランス語で尋ねると、少し違う回答が返ってきます。そしてこれはまた、えっと、ここでのembeddingsモデルが、実際には異なる回答を異なる形でembedするためです。そしてこの回答は、Karachiは19世紀初頭にイギリス人によって設立され、sendの首都になった都市です、というようなものになります。重要な経済中心地であり、急速な成長を経験しました。えっと、特にその港のおかげです。1980年代以降、この都市は民族的および宗教的対立の舞台となってきました。
そして2012年には、史上最悪の産業火災の現場となりました。そして最後はポーランド語の例です。ポーランド語でも、また、多くのこれらの都市名を変換しなければならないことがわかるでしょう。えっと、実際にはこれらの都市名を変換する方法はいくつかあります。TranslateというPythonパッケージがあり、そのPythonパッケージはこれらの都市名の一部を直接翻訳してくれます。
ええと、それを行うもう一つの方法は、アクセスすることです。この場合は pl なので、ポーランド語版 Wikipedia にアクセスして、英語名を入力するだけで、ほとんどの場合、都市名にリダイレクトされます。そしてこの例では、もう一度ほとんどまったく同じことをします。ええと、やることは埋め込みをまた変更するだけです。ここでは別の埋め込みモデルを見つけました。ですので、もう一度 mt e リーダーボード、NTEB リーダーボードを使えば、最良の埋め込みモデルを見つけることができ、そのリーダーボードから埋め込みモデルを選んで、そこから進めることができます。
そして、これがポーランド語に最適な埋め込みモデルです。それ以外はすべて、Polish という名前を変更するだけで、作成しているファイルから、正しい都市をすべて取得できていることも確認できます。ええと、それからここでもまったく同じことをします。コレクションの名前を変更して、ポーランド語で回答するように指示し、まったく同じことをします。そして、シカゴにはどのスポーツチームがあるかを尋ねます。ええと、これは Chicago Bears、Chicago Bulls、Chicago Blackhawks、White Sox、Cubs だと思います。
そして今回は、ポーランド語で質問したにもかかわらず、同じ答えが返ってくるはずだと思います。ええと、ただし少し言い回しは違うでしょうし、私はポーランド語がわからないので、その言い回しがどうなるかはわかりません。順番が違うでしょう。順番が違う？いいえ、同じ順番で Cubs、white socks、black hawks、bulls、bears です。はい、そんな感じです。
これが、多言語 rag アプリケーションを構築する基本です。rag アプリケーションを取り、それをまったく同じ方法で構築します。主な違いは、適切な埋め込みモデルを使用していることを確認できるようにしたい、という点です。ええと、これは hugging face のリーダーボードで最良の埋め込みモデルを探すことで見つけられます。各言語ごとに異なる埋め込みモデルを使うこともできますし、複数の言語でうまく機能する埋め込みモデルを探すこともできます。ですので、hugging board、the hugging board、hugging face leaderboard には、複数言語のオプションが用意されています。
そしてそれらの複数のオプションの中から、さまざまな埋め込みモデルを見て、選んで、すべての言語でそこそこ良い性能を示すものを選択できます。以上です。これが RAG を使って入力したデータであって、通常の GBT の回答ではないと、どうやってわかるのですか？ええと、なぜなら、ええと、これはちなみにとても良い質問です。ええと、正しい回答を使っていることを確認する方法は、この、ええと、テンプレートを通じてです。ええと、つまり GBT はテンプレートに従うことであまり知られているわけではありませんが、instruct tuned のものは従います。ですので、もし私を信じないなら、ええと、つまり、今ちょっと実行してみることもできます。
動作を見てみましょう。ただ、自分で実行してみて、例えば「もしこれらのテキストを一切与えなかったら、何と言うだろう？」と確認するべきです。なので、ここに正確な例は開いていませんが、探すことはできます。ええと、モデルが「これは自分のコンタクトにはありません」のように言っている例はどこかにあります。ええと、ただ、これらのモデルについてワークスペース内を探し回ろうと決める前に、質問に答えさせてください。ええと、もう一つの質問は、幻覚を克服するために RAG を使ったのではありませんか？いいえ、これは、ええと、これは RAG の誤解です。RAG は幻覚を克服するために使われるものではありません。
RAG は、ええと、幻覚を最小化するために使われます。LMS による幻覚は常に、ええと、lms を使用する上でのリスクです。なぜなら LMS は予測マシンであり、やっていることは次のトークンを予測することだけだからです。そして、ええと、幻覚をゼロにする方法はありません。まったくありません。99 にはできます。
9、99。99%は、ええと、それは、ほら、あなたのデータから来ているんですが、実際にはハルシネーションを克服する方法はまったくありません。そして考えてみると、それはある意味納得できます。だって、ほら、人間としてのあなたも、いつもハルシネーションしているんです。つまり、ほら、毎回、ええと、私たちが、ええと、自分の記憶を思い出すたびに、実際には新しい記憶を作り出していて、ええと、それを「ああ、これは過去に起こったことだ」と呼んでいるだけなんですが、実際には今あなたの脳の中で起こっていることなんです。
LM は embeddings と同一の言語で訓練されている必要がありますか？もしそうなら、あまり一般的でない言語についてはどうでしょうか？ええと、LLM は通常、膨大な範囲のデータ、膨大な範囲のインターネットデータにわたって訓練されています。ええと、そして通常はさまざまな言語が含まれていて、あらゆる種類の言語にアクセスできます。現在、一部の LLM は、他の言語よりも特定の言語でより良い性能を発揮するように特化されています。たとえば、ええと、Quen Q-W-E-N-L-L-M は英語と中国語に特化しています。フランスの会社 Misra の mixed draw model は、ええと、フランス語と英語に特化しています。
ええと、他の、ええと、ロマンス諸語もできると思います。ええと、イタリア語、スペイン語、それらは、ええと、かなりうまくできると思います。ええと、そして、これは本当に良い質問で、あまり一般的でない言語についてはどうか、ということです。ええと、これは今まさに人々が取り組んでいることですよね？つまり、ええと、インターネット上のデータ量について言うと、世界には英語話者が55%未満しかいないにもかかわらず、インターネットは55%が英語で、インターネット上のデータの55%は英語です。ですから、アラビア語やゲール語、あるいは、ええと、ほら、他のあまり一般的でない言語のような言語は、これらの LMs が、ええと、触れてきた言語ではありません。そのため、それらの質問に、ええと、答えたり処理したりする同じ能力を持っていません。
ですから、これは本当に、本当に重要な例であり、本当に、本当に重要な問題で、多くの人が取り組んでいます。ええと、そして技術が進んでいくにつれて、ええと、これは、ええと、より一般的になり、より多くの人々が、ええと、特にあまり一般的でない言語に関するデータセットを作り始めることになるだろうと思います。今日のセッションを締めくくる前に質問を送る最後のチャンスです。下部の q and a ツールを使うこともできますし、チャットに投稿することもできます。では、Eugene、このプロジェクトで一番大変だった部分は何でしたか？データ収集、そして、ええと、embeddings model を動かすことでもありました。つまり、ええと、実際にはいくつかの異なる embedding models を試してテストしなければなりませんでした。なぜなら、一部の embedding models は本当に大きく、私は限られた、ええと、Ram で実行しているからです。そして実際、これは多くの人にとって大きな問題かもしれません。つまり、適切なハードウェアへのアクセスというのは、もし、ほら、128ギガバイトの ram みたいなものがなければ、ほとんどの LLMs をローカルで実行できない、ということです。
ええと、人々がそれをできるように支援しようとしているツールはいくつかあります。llamas do cpp のようなもの、ええと、LM Studio のようなもの、こうしたことを人々ができるように支援しようとしているツールはたくさんあります。しかし、ええと、一般的に、最も大変な部分は、つまり、ハードウェアの制約と、それからデータ収集です。ええと、私は中国語データでとても長い間つまずいていて、なぜ動かないのかさえわかりませんでした。そして「ああ、ああ、なるほど、私は、実際にここに文の中国語の単語を入れなければならないんだ、英語を使って自動的に変換させるだけではだめなんだ」と気づきました。ありがとう Rob。ええと、language agent に関してですが、ええと、実際に言語を検出し、agent に embedding model を選択する仕事をさせるための最も効率的なアプローチについて、あなたの意見はどうですか？そして、それらを vis に保存する際のベストプラクティスは何ですか？各言語を別々の collection にするという質問ですか？はい、とても良い質問です。
これは非常に、ええと、複雑なタスクです。なので、ええと、ああまいった、言語を検出できる機械学習モデルがあります、ええと、そしてそれらは、基本的に、そのモデルを実行して言語を検出しなければなりません。これはまたしても、追加のコストオーバーヘッドになります。でも、それが何語なのかがわかっていて、その言語でタグ付けできるのでない限り、これがおそらく最も効果的なやり方です、言語を取得するには。そして、ええと、storand vis に関しては、同じコレクション内では同じ長さのベクトルしか保存できません。なので、複数の言語を埋め込める埋め込みモデルを探すか、いずれにせよこれらの異なる言語を比較できるようにしたいのであれば、自分が扱っているすべての埋め込みモデルが同じ長さであることを確認することをおすすめします。
そうでなければ、はい、別々のコレクションに保存するべきです。そして別々のコレクションに保存する場合、本番環境でこれを扱うときに、データを埋め込んで、それらのコレクションにクエリを投げるために、同じ埋め込みモデルを使っていることを確認する必要があります。なので、これはあなたがやっている非常に複雑なタスクです。ええと、そして、ええと、おそらく多くのバグに遭遇することになると思います。ああ、素晴らしい質問です。今日の最高のベクトルデータベースは何ですか？ええと、私は Zillow で働いているので、ええと、Novus が最高のベクトルデータベースだと言うつもりです。
これは本当に、私は、私は、あの、私の意見では、この質問をしたいなら、LLMs に取り組んでいる人か、ええと、あの、ベクトルデータベース以外の何かに取り組んでいる人に聞くべきです。なぜなら、私が何を言うかというと、それは Viss だと言うに決まっていて、Viss ではないとは言いません、なぜかを言います。では、いいですか？ Viss は非常に柔軟だからだと言います。複数の異なる種類のベクトル類似度を使えますし、複数の異なる種類のインデックスも使えます。そして非常に、非常にスケーラブルです。なので、他のベクトルデータベースを見に行くと、ええと、多くの種類のインデックスや多くの種類の類似度メトリクスを使わせてくれません。実際、これは私がしばらく前からずっと強く言ってきたことの一つで、コサイン類似度は非常に人気がありますが、まったく役に立ちません。
今年の初めに出た論文でさえ、コサイン類似度は類似度すら測っていない、というようなものがありました。そして私は、はは、私は正しい、と思いました。私はこれについてしばらく話してきました。これは高コストなメトリクスで、あまり有用ではありません。ええと、Milds では異なる距離メトリクスや異なるインデックスを使うことができ、それが本当に素晴らしい点です。
Emily、あなたの唇が動いているのは見えますが、ええと、私は、はい、ミュートになっていました。ええと、残り時間はほんの数分ですので、もし最後の質問があれば、ほんの、ほんの少し時間を差し上げます。なので急いで入力してください。ええと、ああ、コサイン類似度に関する論文を共有してほしいというリクエストがあります。ええと、見つけられるかどうか見てみます。
もし、もし Eugene が通話中に見つけられなければ、後ほど録画と一緒に、ええと、フォローアップメールで送れます。ああ、そう、ああ、もう見つけました。はい、見つけました。とても早く見つけました。何度も検索していました。
ええと、なぜだと思いますか？私はそれらが好きではないからです。高い類似度。はい、ええと、私は強い意見を持つ人間です。ええと、本日、聴衆の皆さんから他に質問はありますか？本セッションに参加してくださった皆さん、私たち全員、皆さん、ありがとうございます。ええと、楽しんでいただけて、途中でいくつかの追加言語、言語を学んでいただけたなら幸いです。
ええと、少しだけ時間をつなぎます。ええと、でもチャットには他に何も見当たらないので、皆さんを、ええと、数分早く解放しましょう。次の、ええと、会議に行くなり、昼食に向かうなり、世界のどこにいらっしゃるにせよ、その場所へ行けます。ええと、Eugene、このセッション本当にありがとうございました。とても楽しかったです。
そして、ええと、また将来のウェビナーで皆さんにお会いできればと思います。ありがとう Emily。参加してくださった皆さん、ありがとうございました。
Meet the Speaker
Join the session for live Q&A with the speaker
Yujian Tang
Developer Advocate at Zilliz
Yujian Tang is a Developer Advocate at Zilliz. He has a background as a software engineer working on AutoML at Amazon. Yujian studied Computer Science, Statistics, and Neuroscience with research papers published to conferences including IEEE Big Data. He enjoys drinking bubble tea, spending time with family, and being near water.