You’re in!
トレーニング
チュートリアル: 大規模環境でのLLMの活用
本日は、今日のセッション「LLMを大規模に扱う」と、ゲストスピーカーのGin Tangをご紹介できることを嬉しく思います。GinはZillowsのデベロッパーアドボケイトです。彼は、Amazonでauto MLに取り組むソフトウェアエンジニアとしての経歴があり、YuEugeneはコンピューターサイエンス、統計学、神経科学を学び、i e e、big Dataを含むカンファレンスで研究論文を発表しています。彼はバブルティーを飲むこと、家族と過ごすこと、水辺にいることを楽しんでいます。ようこそ、Eugene。
ええ、はい、ご紹介ありがとうございます、Emily。ええ、皆さんこんにちは。私の名前はYu Eugeneです。ええ、本日はl l mアプリケーションのスケーリング、つまりLMSを大規模に扱うことについてお話しします。そしてこのスライドには、ええ、l l mアプリケーションをスケールする鍵、というタイトルを付けました。
では、ええ、最初に少し事務連絡をします。これから、ええ、これらのスライドを見ていきます。短いウォークスルーになる予定で、たぶん20分くらいです。その後、コードに入って、llama index、lang chain、visを使ってマルチドキュメントのq and aをどのように行えるかに取り組みます。お越しいただきありがとうございます。
始めます。はい、これは私です。ええ、私の名前はyou Eugene tで、デベロッパーアドボケイトです。Asus、もし携帯電話をお持ちなら、QRコードをスキャンできます。ええ、それで私のLinkedInに移動できます。
また、me@zillow. comにメールしていただくか、Twitterで見つけていただくこともできます。ええ、でも私はLinkedInで最も活発です。あれ、何が起きているんでしょう？はい、ええ、これはZillowsについて少しです。ええ、私たちはvisをメンテナンスしており、これは世界で最も人気のあるオープンソースのベクトルデータベースです。
こちらは私たちを見つけられるリンクです。ええ、Twitter、LinkedInでZillow Universeにアクセスできます。Zillowを検索できますし、ここでVicのSlackを見つけることも、GitHubに行くこともできます。また、GitHubに行ってviss dash io slash melvicにアクセスし、ええ、そのVectorデータベースを確認できます。はい、では今日のこの講演では、まず大規模言語モデルの基礎を扱います。ニューラルネットワークがどのようなものか、そしてそれらがどのように大規模言語モデルへと発展してきたかを取り上げるだけです。
次に、ええ、LLMsに関わる課題や、LLMsを本番環境で使用する際の課題について話します。それから、C B Pフレームワークと呼ばれるものを紹介します。これはchat G B T、vector Databases、Prompt as codeです。そして、それがどのようなものか、またLLMsの課題解決にどのように役立っているかを見ていきます。その後、Vectorデータベースとは何かについて手短に話し、VISを例にして、measureデータベースを理解するためのサンプルアーキテクチャとして使います。最後に、ええ、簡単なデモを行います。これはコードウォークスルーです。
最初のステップとして、大規模言語モデルについて考えます。皆さんはしばらくこの分野にいらっしゃるでしょうから、おそらくChad、G B Tについて聞いたことがあると思います。ええ、そしてOpenAI、AnthropicのClaude、Googleのbarredについてもご存じでしょう。これらは、ええ、現在存在する中で最も高度な言語モデルの一部です。今、大きな話題を呼んでいるこれらの大規模言語モデルです。
では、一歩引いて、私たちがどのようにここに至ったのか、そしてどのようにして言語モデルという考え方に入ってきたのかについて話しましょう。2012年までずっと遡ります。ええ、convolutionsについて話します。これは、ええ、実際には2012年以前から存在していましたが、AlexNetによって本当にEdされました。そしてこの例では、この種のconvolutionsがどのように機能するかを見ることができます。つまり、自分の隣にあるtokensについての文脈を与えるのです。文では、Novus is the world's most popular open source factor database.
ご覧のとおり、ええと、このニューラルネットワークでこれがどのように設定されるかというと、自分のすぐ隣にある2つの、ええと、トークンへのコンテキストを持つことになります。そこから、私たちは自己注意と呼ばれるものに移りました。これはグローバルなコンテキストを与えてくれます。ご覧のとおり、これらすべての矢印がすべての、すべてのニューロンを指していて、すべての単語は文中のすべてのトークンということになりますか？いいえ、これは世界で最も人気のあるベクトルベクトルデータベースです。ええと、ここではすべての単語を取り上げたわけではありませんが、基本的には文中のすべての単語が、文中の他のすべての単語へのコンテキストを持つことになります。ええと、つまり vis は world を知っている、というようなことです。
しかし、ご存じのように、英語ではそれは実際には必要ありません。ええと、文というのは、このように構築されます。ですから実際に必要なのはこのようなもので、これは因果的注意であり、これらのニューロンに、つまり、その単語が、ええと、自分より前の単語にアクセスできるようにします。すべての単語が下向きに指しているのが見えると思いますが、これは文のさらに後ろにあるすべてのトークンが、文の冒頭のトークンによって与えられる情報にアクセスできることを意味します。そしてこれが、LLM、r n CNN、つまり、これらの、ええと、trans trans、ええと、ええと、trans transform、ええと、transformerモデルがどのように動作するかへとつながっていきます。
ええと、つまり、アーキテクチャに基づいてニューロンに課される、こうしたさまざまな注意機構があるということです。そして、ええと、そこからは本質的に統計になりますよね？LMS は将来のトークンを予測します。これらの例では、次のトークンを予測することになります。つまりこの例では、database という単語を探すことになります。そして、これは Novus is the world's most popular vector blank のように、ここでモデル化されています。
ええと、そして l l M がその文を生成しているなら、database と言うでしょうし、まあ、それは database だ、と言うでしょう。なぜなら、この例では 0.86 でそこに最も高い確率があると分かるからです。したがって、LMS は最も可能性の高いものを予測しているだけの確率的モデルなので、次のトークンに関する最大の欠点の1つは、ハルシネーションと呼ばれるものがあることです。これは、ええと、もっともらしく聞こえるが事実としては正しくない応答です。
つまりこれは、l l M が見たデータに基づいて、ある種のデータベースを作り上げる場面です。そして、それが基本的には、ええ、次に来る正しい単語だと言うわけです。ええと、少し数学を見ていきましょう。ええと、この部分にはあまり時間をかけません。これは主に、機械学習の背後にある数学に本当に興味がある方のためのものです。ええと、これは基本的な統計ですよね？いくつかのトークン、T zero から tn TN plus one までが与えられています。
そして、確率分布に基づいて出力をモデル化したいわけです。つまりこれは、ええと、ベイズ統計の表現ですよね？文の中で、その前にあるすべての単語、is the world's most blah, blah, blah, blah, blah が与えられたとき、database の確率は何か。ええと、そしてこれは、ええ、これらは、舞台裏の数学で、その上に書かれている、その、その、その指標です。いいですか？では、LLM に関わる課題のいくつかを見てみましょう。chat G p T からの、ええと、ハルシネーションの例を見ていきます。
そして、このクエリの例は、Novus を使ってクエリを実行するにはどうすればよいか、です。するとこのようなものが返ってきます。一見するとかなり正確に見えます。これを見て、なるほど、Pythonコードのように見える、ここに、何かリストがあるように見えるし、いくつか、いくつか、いくつかの辞書もあるように見える、などと言えるでしょう。しかし実際のコードを知っていてドキュメントを見に行くと、これがハルシネーションであり、この例は誤っていることが分かります。そしてここでの問題は、基本的に、これは実際には anovis サーバーに接続する方法ではないということです。
なので後ほど、接続をどのように行うかについて話しますが、ここでは、ハルシネーションと L M がどのように見えるかの例として、この例をお見せしたかっただけです。では私たちの解決策、ハルシネーションへの解決策ですね？現在提案されている大きな解決策は実際には二つあります。一つはモデルをファインチューニングすることで、これはモデルを最新の状態に保つのに役立つことがありますよね？あるいは、あなた固有の情報でモデルをトレーニングするのに役立つこともあります。しかしこれには、どれだけのデータを持っているかに関する課題が含まれます。なぜなら、ご存じのように、これらの L M S は、あなたがそれらに触れる前、ファインチューニングできるようになる前に、何十億ものデータポイントを見ているからです。そこで私たちが提案する解決策は、C V P フレームワークを使って、これらの大規模言語モデルにドメイン知識を注入することです。これが次に話す内容です。
先ほど言っていたように、C V P フレームワークというのは、ええと、chat、chat, G B T で、実際には任意の L L M でよく、私たちは C B P の響きが良いから使っているだけですが、ベクトルデータベース、これが v で、p は prompt、つまりコードです、わかりましたか？ ええと、C V P フレームワークの背後にある重要な考え方は、L L M Maps を汎用コンピューターとして捉えることです。プロセッサ、たとえば C P U のようなもの、永続ストレージであるベクトルデータベース、そしてコード、この場合はプロンプトです。そして後ほどコードを見ていくと、LAMA index と Lang chain がプロセッサやコードのように動作する様子がわかりますよね？つまり Lang Chain は、LMS とのプロンプティングを構築するのに役立ち、LAMA index はあなたのデータを包み込むような役割をします。ええと、つまりスケーラブルな L l M を構築するためのこのフレームワークがどのようなものになるかについての考え方はそんな感じです。そしてこれらがその構成要素です、そうですよね？ G B T、その他の任意の L L M がプロセッサです。そして Novus のようなベクトルデータベースはストレージ、つまり rom やメモリのようなもので、prompt this code はインターフェースです。
そしてこれは、C V P を使ったプロジェクトの一例です。O ss s chat と呼ばれています。ええと、これを見たことがあるなら、どこかで見たことがあるかもしれません。これは、オープンソースソフトウェアとやり取りするためのチャットボットです。ええと、これが行うのは、そのオープンソースソフトウェアで利用可能なドキュメントを取り込み、chat G B T の上にレイヤーを作成することです。それはベクトルデータベースとして zills Cloud を使います。ええと、zills cloud は viss のクラウド版です。
ええと、それはベクトルデータベースとして zills Cloud を使い、それから、より多くのユーザーが G P T cache を使って質問するにつれて、尋ねられたすべてのデータをキャッシュします。そして質問をすると、それがベクトルデータベースに行って中を調べ、こう言います。「ねえ、この質問への答えとなる情報はここに保存されていますか？」ええと、そして、ご存じのように、もしそうなら、それを返し、それから Chad G P T に行って応答を提供します。ええと、そうでなければ、do, do, do はしません。ええと、では先ほどのハルシネーションの例、vis を使ってクエリを実行するにはどうすればよいか、に戻りましょう。そしてそれを o s s chat で使うと、実際にこのコードが返ってきます。これは役に立ち、co 接続を行う実際の方法を示してくれます。ええと、つまりこれは主に、L L M の上にデータを注入すれば、正しい情報を返せることを示すための例です。ええと、正しい最新情報を持っていないかもしれない L l m に直接尋ねるのではなく、データを検索することによって、正しい情報、正しい、あるいは最新の情報を得られるのです。
いいですか？では、ベクトル埋め込みについて少し話しましょう。そして、ベクトルとは何か、またそれらをどのように作成するのかについて話しながら、なぜこれらのベクトルがこのハルシネーション問題の解決に役立つのかを、ざっくりと話していきます。つまり、ええと、これは当然、このフレームワークがハルシネーションを解決するのに役立つのは、ドメイン知識を注入し、l m にドメイン知識へのアクセスを与え、その後、ベクトル埋め込みを通じてそのドメイン知識に対してセマンティック検索を行うことによります。それを担っているのがベクトルデータベースです。これは非常に、いわば初期の論文で、ベクトルとベクトル埋め込みに関する非常に画期的な論文です。ええと、これは単に、単語で数学ができるということを示していますよね？ベクトル埋め込みの背後にある考え方全体は、何らかのオブジェクトを表現するためにいくつかの数値を使い、その数値を使ってこれらのオブジェクトに対して数学を行う、というものです。
つまり、単語に対して数学を行い、画像に対して数学を行い、動画に対して数学を行う、何でもそうです。ええと、この例では単に、単語を取ると、queen という単語から始めて woman という単語を引き、man という単語を足すと、king が得られる、ということを示していますよね？単語に対する数学です。そして、最近目にするほとんどのベクトル埋め込みは、まあ、二次元ではありません。たいていは 700 いくつ、300 いくつ、1500 いくつ、1000 いくつ、といった具合で、今でははるかに、はるかに、はるかに、はるかに大きくなっています。ええと、実際には、これを実装する方法として、まずナレッジベース、つまりドキュメントから始めます。ドキュメントを変換し、チャンク化し、その他いろいろ行い、それらをディープラーニングモデルに投入します。
そして実際には、ここで最後から2番目の層を取得します。失礼。従来、ディープラーニングモデルでは、通常何らかの分類層である何らかの出力を得ます。ええと、ベクトル埋め込みは、実際には最後から2番目の層です。つまり、ナレッジベースを取り、それをディープラーニングモデルに通し、最後の層を取り除いて、最後から2番目の層への出力を取得します。
それがあなたのベクトルです。それがあなたのベクトル、つまりオブジェクトの表現の埋め込みです。ええと、ナレッジベースの表現ですね。そしてそれを Novus のようなベクトルデータベースに入れます。いいですか？では、ベクトルデータベースとは何でしょうか？私たちはそれをどう使うかについて話してきましたが、それが何であるかを見てみましょう。Zillows または viss で私たちがベクトルデータベースを定義する方法は、ええと、大量のベクトル埋め込みを保存、インデックス化、クエリするために専用に構築されたデータベース、というものです。ええと、特に Viss について言うと、ええと、viss の利点は、スケールしたときに非常に、非常にうまく機能することです。
そして、スケールしたときに非常にうまく機能する理由は、ええと、さて、待って、次ではなく、次のスライドですね。わかりました、それについてはすぐに説明します。ええと、しかし、なぜ専用に構築されたベクトルデータベースが必要なのかについて話しましょう。まず、もしベクトルを扱いたいのであれば、実際にはベクトルデータベースは必要ありません。face、F A I SS S、あるいは H N Ss W、annoy などのベクトル検索ライブラリを使うだけでも構いません。何らかのベクトルインデックス作成、ええと、戦略です。ベクトルデータベースは、実際にはベクトル検索の上に必要となる多くのさまざまな機能を提供します。
もし、本番環境でこれを使う、実際に実務でこれを使うとしたら、フィルタリング、フィルター検索、チェーンフィルター、ハイブリッド検索、ええと、バックアップ、レプリケーション、スケーラビリティ、水平・垂直スケーラビリティ、ストリーミングデータ向けのシャーディング、ええと、集約検索、ライフサイクル管理、upserts、えー、削除、挿入、そういったものが必要になります。そして、ユースケースによっては、高いクエリ負荷や大量の挿入・削除にも対応できる必要があります。ええと、つまり、リコールやそのためのインデックス戦略を調整できる必要があります。ええと、それから、たとえば、えー、Nvidia の GPU サポートがあるので、それらの GPU 上でより高速に動作しますし、本当に十億規模のストレージもあります。これこそが Viss を、ええと、非常にユニークなベクトルデータベースにしている点です。では、いくつかのベクトルインデックス戦略について見ていきましょう。こうしたもの、つまり、これらのベクトル検索ライブラリについて、基本的に、えー、そのうちのいくつかを取り上げて、それから Viss のアーキテクチャがどのようなものか、そしてなぜそれが、ええと、なぜそれほど強力なのかというトピックに踏み込んでいきます。
ベクトルおよびインデックス戦略で一般的なものの一つに、えー、近似最近傍と呼ばれるものがあります。ああ、そう、annoy です。ええと、これは Spotify のものです。基本的には、ベクトル空間内の任意の2点を選んで、その空間を半分に分割します。えー、ここにはいくつか制限があります。たとえば、空間を2つの半分に分けたときに、一方の半分にベクトルが1つしかない、というような2点は選びたくありません。それは、それは明らかに問題です。ただ、ほとんどの場合、ランダムな2つのベクトルを選んで空間を半分に分け、それを何度も何度も何度も何度も繰り返して、もう分割する半分がなくなるまで、あるいは各セクションに5つのベクトルがある、というような状態になるまで続けます。
つまり、これは基本的に二分木のようなものを構築します。そして、それがその検索を行う方法のようなものです。次に inverted file index があります。これは OID 図のように見えます。基本的には、えー、まず、えー、えー、K means を使って OID のようなことをします、すみません、すべての点を、自分が望む数の OID にクラスタリングします。そして検索する方法としては、最も近い OID の末端から始めて、それらの各 OID の中で最も近い点を検索します。これによって、検索対象をより小さな部分に絞れるため、検索空間がどのように減るかがわかると思います。annoy に少し似ています。
次に H N S W、つまり hierarchical navigable small worlds があります。これは本当に、本当に人気のあるものです。これは非常に人気のあるグラフベースの、ええと、ベクトルインデックス戦略です。基本的には、えー、データポイントを挿入していくにつれて、最も近いデータポイントを指すようなグラフを作成します。ええと、そしてデータポイントを挿入する際に、0から1の間のどこかに割り当てられる一様乱数を生成します。つまり、そして、どのレイヤーに行くかを示すカットオフがあります。
たとえば、カットオフが 0. 9 だとすると、0. 9 0. 9 はレイヤー0にのみ存在します。そして、0.
9 から 1 の間のどこかであれば、レイヤー0とレイヤー1に入ることになります。そして、もし、あるいは 0. 9 と 0. 99 の間であれば、もし 0. 99 と 0.
999 の間であれば、レイヤー0の間、えー、レイヤー0、レイヤー1、そしてレイヤー2に入ることになります。えー、つまり基本的に、これらのレイヤーは乱数によって割り当てられ、最近傍を指すグラフベースのインデックスです。ええと、検索方法としては、最上位レイヤーから始めて最も近いものを見つけ、そこからずっと下まで検索していきます。えー、想像できると思いますが、これによって検索時間は短縮されます。ええと、理由は A、インデックスがすでに構築されていること、そして、えー、b、最初から検索する空間が少なく、えー、えー、非常に小さな空間で済み、その後、下に行くにつれて少しずつ大きな空間を検索するようになるからです。えー、これの唯一の欠点は、実際には、インデックス化によってインデックスが実データよりも大きくなることです。
わかりましたか？では、BUのアーキテクチャがどのようなものか、そしてなぜNovusが速いのかを見ていきましょう。なぜvissは、なぜNovusは、たとえば、スケールした状態で役に立つのでしょうか。ご存じのように、ええと、ほぼ、数百個のベクトルくらいでは、実際には、ほとんど同じです。しかし、スケールしてくると、考えなければならないことがあります。たとえば、ええと、ご存じのように、私が処理している空間はどれくらい大きいのか？これらすべてのベクトル比較をその上で行うわけです。ベクトルを比較するとき、検索を行うときには、既存のベクトルに対して何らかの、ええと、比較を行う必要があり、それには何らかの行列乗算、または、または、そういったものが必要になります。ええと、vissの仕組みとしては、3種類の異なるクエリノードがあり、何かを行いたいときに毎回立ち上がる3つの異なるノードがあります。つまり、インデックス作成は特殊なノードで、ええと、ご存じのように、インデックス作成をしたい場合、通常これはデータを追加するときですが、ええと、indexノードを使います。ただし、これはあまり一般的に使われるものではありません。ええと、それで他の2つのノードがあり、それがdataノードで、必要なデータをメモリ内に保持します。そしてqueryノードがあり、クエリを実行して、必要なデータを返します。この、実際の作業、visでの実際の処理を行うこれらのノートの外側には、オブジェクトストレージがあり、これは基本的に、ご存じのように、min io、s three、Azure blob、何でもです。
ここに、ええと、ここにベクトルデータベース内のデータを保存します。ええと、そしておそらく皆さんはこのあたりのことをあまり気にする必要はありません。では、mostがスケール時に本当に、ええと、高速である理由の1つは、segmentと呼ばれる仕組みを使っているからです。そこでは、すべてのデータをこれらの512メガバイトのsegmentに入れ、そしてそれらが512メガバイトに達するたびにこれらのsegmentを封印します。すると、ええと、クエリを実行するときに、これらのsegmentを並列に検索できるようになります。つまりクエリを実行するとき、たとえば100ギガバイトのものに対して、基本的に512メガバイト単位のクエリを行うことができます。そして、ええと、最後にそれらをある程度、ええと、まとめて、セグメンテーションに基づいて比較しますが、ええと、セグメント化された、ええと、ブロックがなければ行うことになる、100ギガバイトの空間全体を検索する必要はありません。
なのでそれを考えると、ご存じのように、ええと、必要な、ええと、操作の200分の1で、ある程度、やり遂げることができます。それに少し余分な処理が加わるくらいです。なので、おそらく、100分の1くらいかもしれませんが、データサイズが大きくなるにつれて、これはますます顕著になります。さて、それでは、ああ、そうですね、ちょうど時間どおりくらいでした。約20分です。では、簡単なデモを見ていきます。
コードを開いて、それからコードウォークスルーを行います。では、ええと、はい、マルチドキュメントの、ええと、Q&Aシステムを、ええと、Lama Llama index、Lang chain、visを使って構築します。そしてデータを使います。使用するデータ、取得するデータはWikipediaからです。ええと、Emily、CoLab notebookへの、ええと、その、そのリンクをチャットに落としてもらえますか？はい。はい、そこにあります。
CoLab notebookがあります。これはCoLab上にあるので、そこに入って、一緒に進められます。画面を少し大きくします。これが正しく収まるといいのですが。ええと、これについては、今一緒に進めるために本当に必要なのは、ご存じのように、Python three 10またはthree nineです。ええと、私はthree 10を使っています。ええと、皆さんには、先に進んで、ええと、ご存じのように、どこかに新しいディレクトリを作って、それから何らかの、ええと、virtual environment、うんぬんかんぬんを行い、ええと、virtual environmentを起動することをお勧めします。
それを行う時間を少し取ります。ええと、あ、実は、ここで自分のvirtual environmentを起動していませんでした。なので実際にやることは、はい、これでvirtual environmentがそこにできました。すでにインストールしていたと思っていました。そしてそれをactivateします。
そして次に行うのは、これに必要なライブラリをインストールすることです。なので、pip install LAMA index、Lama index、link chain、mbus、nobus、えー、それから requests が必要だと思います。Python m は、環境変数を扱うために使っていたものです。実際には、必ずしも Python m が必要というわけではありません。OpenAI の a p I キーをそのまま notebook に入れたい場合はそれでもいいのですが、私は自分の do m ファイルに入れているので、えー、Python M で扱っています。えー、それからおそらく OpenAI と、えー、IPI Kernel も必要です。これは、これを、えー、ああ、ああ、わかりました。実は1つ見落としていました。
N L T K も必要です。N LT K の stop words パッケージのようなものが、つまり、えー、Llama Index がクエリ分解を行うために使っているものだと思います。クエリ分解というのは、クエリをより小さな部分に分割するもので、それによってマルチドキュメントの q and A を行います。なので、それもインストールしましょう。ではここでインストールします。
はい、いいですね。これで N L T K が入りました。さらに、ここは notebook からコピー＆ペーストします。えー、N L T K から Stop Wordss パッケージをインストールする必要があります。これは、えー、時々こういうエラー、S S L エラーが出ることがあるので、単に新しい Python の、えー、インタープリタを起動してそこで何かするのではなく、プログラム的に行っています。
では見てみましょう。質問があります。CoLab CoLab リンクを再共有してください。CoLab リンクを失いました。えー、わかりました。再共有できますね、はい。
えー、私がこれを進めている間に質問があれば、遠慮なく止めてください。これは、えー、インタラクティブなワークショップのようなものを意図しています。いいですか？では、import を行います。えー、なので、Llama Index から、えー、いろいろなものを import します。import、まず G PT Vector Store を import します。
次に何を import しますか？ああ、simple keyword table index ですね。BT simple keyword table index。なぜこれがハイライトされないのかわかりません。これはハイライトされると思っていたのですが、ああ、LAMA index にするのでしょうか？これならハイライトされるかもしれません。はい。
なぜコード補完が出ないのかわかりませんが、出ません。えー、あ、チャットに質問があります。関連する GitHub repub はありますか？今のところ GitHub には何もありません。えー、これを GitHub に置くことはできます。実際には、これは bootcamp の GitHub に置かれるべきです。Novus には bootcamp の、えー、repo があり、これはそこに置かれるはずなので、後でそこに置いておきます。そこでも確認できます。
Pine Novis があるのに、なぜ Llama Index が必要なのですか？つまり Llama Index は、えー、私たちが、えー、クエリ分解を行うために使うものです。実際にここで構築するものは、ああ、そうですね、構築するもののアーキテクチャを説明したほうがよかったですね。それはいい考えでした。えー、私たちがここで実際に構築するのは、これらのドキュメントを取り込んで、こうしたベクトルストアのようなものにロードする、というものです。そして keyword index を使います。これは llama index によって生成されます。それが実際に、正しいベクトルの集合へルーティングしてくれます。なので、vis を使っているにもかかわらず、えー、えー、だから llama index が必要なのです。John、あなたの質問には後で答えます。
それには q and A を使ってください。それはもっと一般的な質問で、コードについてではありません。でも、えー、コードについて質問があれば、これを進めながら答えます。いいですか？えー、では link chain から何かを import します。これが唯一の link chain です。これは私たちが行う唯一の link chain import です。
えー、実際にはこれについて別のやり方もできますが、えー、これは好きなのでこのようにします。えー、import open。はい、chat ですね。その通りです。はい。
さて、これから全部をセットアップしていきます。えーと、基本的には、私たちの、そのベクター、ベクターデータベースとかをセットアップします。なので oss をインポートして、えー、mm import load dot m をインポートします。ああ、本当にここにコード補完があればよかったのに。AI m なので、これは dot の、えー、m ファイルを読み込んで OpenAI キーを取得します。えー、get m OpenAI a p i key。これで、えー、OpenAI へのアクセスがセットアップされます。それから、えー、vis をセットアップします。なので LAMA index から、えー、vector stores、vis vector store。
それから、えー、実際の vis も必要になります。なので vis から default server、default server をインポートします。えー、それから default servervector store を開始します。この vector store は、えー、ええと、host equals local hosts, 1 27 0. 0 0. 0 0. 1 で、そして port は、えー、default server。
Listen port。いいですか？ なので、これは、えー、だいたい、あ、いや、実際には思っていたより少し速かったですね。10 秒くらいかかると思っていました。はい。えー、でもこれは基本的に、えー、vis のローカルインスタンス、私たちの vis light を立ち上げます。これは、えー、実際には、ほら、サードパーティの、えー、Zillow で働いていないサードパーティのメンテナー、オープンソースの人によって作られたものです。
なので Matrix G に感謝です。GitHub で彼を知っているなら、声をかけてあげてください。えー、バージョンの競合が起きています。えー、どのバージョンか確認して、えー、正しい G G E R P C e O io バージョンをそこに入れられるか見てみてください。もし、もし私にもっと時間があれば、止まって、ちょっと、ほら、これを一緒に解決する、ライブで一緒に解決することができたと思います。
でも、えー、残念ながらこれは大きなセッションです。なので、えー、これからやるのは wiki のものを取得することです。これは重要ではないコードで、技術的には、えー、ほら、l l m アプリを構築することとは関係ありません。これは単にデータを集めるセクションです。なので、このコードをコピーして貼り付けるだけにします。
ほら、Toronto、Seattle、San Francisco、Chicago、Boston、Washington, dc、Cambridge, Massachusetts、そして Houston に関する場所や、えー、情報を取得しています。もし誰か、ここに追加する都市を次の 10 秒で入力したい人がいれば、チャットに貼り付けるのを読みながら待ちます。G B T、えー、誰かのを選んでみます。みなさん、あ、Dubai、はい、Dallas、Seattle はもう入っているので、Dubai をここに入れます。えー、それから Dallas をここに入れます。えー、Dallas はもうここに入っていますか？CCL はここに、ここにあります。
はい。えー、はい、いいですね。たくさんの都市が挙がっています。えー、でもこれらが今回使うものです。いいですか？ では、この部分は、単に、これは文字通りコードのスクレイピングセクションです。
なので、これをコピーして貼り付けるだけにします。説明しながら進めますが、ここで何が起きているかを理解する必要はありません。このコードをコピーして貼り付けて、ここに入れるだけで大丈夫です。基本的に私たちがやっているのは、ここにリストされている各 Wikipedia ページに get request を送信している、ということです。そして、それらをまとめています。ほら、この、これは yield 関数です。えー、すみません、これは generator 関数です。そしてそのテキストをすべてまとめて、それからローカルのファイルに保存します。いいですか？ なのでこれは数秒しかかからないはずです。そしてこれがどんな感じか見られますよね？ Boston はこんな感じです。
Cambridge, Massachusetts、Chicago、Dallas、Dubai、Houston、San Francisco、Seattle、Toronto、Washington, DC。はい。えー、私は Seattle にいます。私の好きな場所です。現在は、実際には、たぶん今は San Francisco により近いところにいますが、住んでいるのは Seattle です。はい。
では、これがすべて揃ったら、ええと、すべてのドキュメントが揃ったら、実際のインデックスの構築に入っていきます。いいですか？では docs を取得して、documents 用の空の辞書を作成し、それからすべてのタイトルを順に見ていきます。なので、title and titles、city docs titles、そしてこれを設定します。ここでは Simple Directory Reader、simple Directory Reader を使います。そしていくつかの入力ファイルを読み込みます。入力ファイルは slash data slash oh six be f stringtitle になります。
うわ。ええと、あ、これは実際には、ええと、リストの中に入れる必要があります。というのも input files はリストを期待しているからです。ええと、それからそのデータを hash type list で読み込みます。えっと、何をした？何をしたんだ？Slash もしかするとこうしないといけないかもしれません。
あ、これは前にやったものと違います。これは、えっと、何を間違えたんだろう？誰かこれ見えましたか？ええと、and put files f Data slash Wiki title。Okay。Okay。まあ、私は、私は、私はここに正しい、正しい、ええと、このための正しいコードを持っています。
ええと、では次に service context、ええと、storage context、そして実際のチャットボットを作成しましょう。これには、ええと、predictor chat、G P T を使います。ええと、これは、ええと、基本的にはチャットボットです。つまり、これが L L M に接続するものです。なので lm には、ここでは l m を使って、SQL をこれに設定します。これは OpenAI chat だと思います。
はい。OpenAI chat、OpenAI Chat、これは先ほどダウンロードした link chain の部分です。temperature。そしてこの temperature をゼロに設定します。そして model name が必要だと思います、はい、model name です。それは G B T 3 と等しくなります。
5。いいですか？そして service context が必要です。Service context、a service context、これは L L M predictor を使います。ええと、service context、lmm predictor、LMM Predictor chatt。そして storage context が必要で、これは、ええと、これは LAMA index に基本的にファイルをどう保存するか、または、ええと、ベクトルをどう保存するかを伝えます。and Vector store equals vector store。いいですか？そして、okay、いいですね。
特に大きな問題は起きていません。ではインデックス、または indices を構築していきます。ええと、チャットで何が起きていますか？あ、Okay。あ、Citi にしていました。あ、Wiki titles にしていました。
Okay、いいですね。ありがとうございます。Herba。Herve、すみません。ええと、okay、この Citi index を構築しましょう。
なので Citi indiceswiki summaries または index summaries。前に何と呼んでいたんだっけ。ええと、index summaries はキーワードのもので、これを使って、ええと、クエリを基本的にルーティングします。あ、違う、すみません、fourWiki title and Wiki titles。これらすべてをループして、そこから G B T vector、ええと、store index を作成します。では見てみましょう、Citi and the CS Wiki title、大丈夫です。
今回は Wiki title にしました、ss なしです。なので hopefully 怒られないはずです。G B T Factor store index、ええと、from documents、ここで C docs を取得すると思います。C docs title、ええと、service context、service context、storage context、full storage context。この部分に必要なのはこれですべてだと思います。ええと、そして index summary を設定する必要があります。
なので index summary、wiki title、これは等しい、たぶん FT string を使うべきだと思います。はい、Wikipedia article aboutwhat he title。これがインデックス作成を開始する方法です。皆さんがお互いに助け合って、ええと、これらの、これらの、これらのエラーを解決しているのを見られて本当に嬉しいです。ええと、okay、では次に必要なのは composable graph、ええと、object を取得することです。
ここで行うのは、Llama から compostable graph をインポートするだけです。そしてこれが、ええと、基本的に indices を構成する graph を作成する部分です。なので graph equals compostable graph、ええと、そしてまずは、ええと、G P Tsimple keyword table index から始めます。ええと、これは基本的に、そのためにこの keyword table index を使うことを示しています。ええと、それから、I believe this would be city in the scenes、ああ、鼻が。
ええ、それからサマリーも必要で、それから単に max keywordschunk は 50 に等しいと言います。ええ、それは正しい最大値ではないですか？チャンクごとのキーワード数？ええ、ああ待って、それは私がこれを間違ってやったからです。オーケー、できました。うーん、オーケー。Alex Ashkin、誰か、ええ、vis エラーが出ている人はいますか？はい、うーん、それがあるなら、もう一度起動してみるだけでいいと思います。ええ、以前に vis を起動したことがあって、うーん、ローカルで実行していて、そのファイルの最後で stop のようなことをしていなかった場合、いくつかのスレッドが動き出してエラーに遭遇することになります。
うーん、rod、Sam、OpenAI key の設定を過ぎた人はいますか？オーケー、分かりません。それについて言います。Jerry Lou、Jerry Lou ではなく、Llama Index の作者です。Jerry Lou。オーケー。
うーん、underscore blah, blah, blah の index は何ですか。オーケー、つまりアンダースコアは基本的に Python で未使用の変数を表すために使われます。ですから実際にここで起きているのは、取得しているということで、実際にはたぶん city indices values と呼ぶこともできます。つまり city indices items は 2 つの異なる、みたいな、基本的に 2 つのものを返していて、うーん、キーと値を返します。そして必要なのは値だけで、キーは必要ありません。ええ、なので、そういう理由です。ええ、Daniel Crosby が、ここで追いついているところです、と言っています。
Unicode と code error の領域に遭遇しましたか？うーん、もしかすると、もしかすると、あなたが私が使っているのと同じ、ええ、Wikipedia 記事を使っているかどうか分かりませんが、それは Unicode 文字のように見えますし、これをいじって UTF-8 にエンコードできるようにできるか試してみるとよいかもしれません。うーん、オーケー、ではこの残りを進めましょう。これを終わらせてみましょう。うーん、query transform も import します。これは実際のクエリ変換を行う関数になります。ここで何が起きているのでしょう？オーケー、つまり decomposed tray query transform は、ええ、基本的に、うーん、ええ、ああすごい、これは dictionary ではありません、すみません。
それは l l m にあなたのクエリを分解させ、クエリを複数の部分に分けさせるよう設定します。Chat gt そして verbose SQLs を True にします。実際には verbose SQLs を True にする必要はありません。
うーん、これはクエリがどのように分割されているかを示すだけです。ええ、それから最後に import する必要があるのは transform engine です。そしてこの場合、実際にまず始めるのは、ええ、いくつかの custom query engines で、それを空の dictionary にします。うーん、オーケー、では indexes をループしましょう、four。そして next in、ええ、city in theCSCs values、ええ、最初に query engine を設定します。
つまり query engine。なので、ここではこれを decomposed、ええ、すべての query、つまり decomposable queries にして、このセクションでその上に query engine を使います。つまり index query、うーん、それから service context を渡します。Service context。それから、ああ、チャットにたくさん質問があります。
録画は共有されますか？これは、はい。有効な opening はありますか？ええ、Raj、はい。ええ、OpenAI key は、OpenAI に行って OpenAI a p i key を取得する必要があります。ええ、このようなものを構築するためには、うーん、必要です。ああ、完璧です。できましたね、Daniel。
ええ、それから Isaac？はい、録画は共有されます。オーケー。うーん、それから追加情報も渡します。つまり extra info、そしてそれは等しく、index summary または summary、または summary summary に渡します、たぶん。そしてそれは indexnext に等しくなります。つまりこれは実際には、オブジェクトをそれに渡すだけです。ええ、それは基本的に index track を与えます。
ええ、これは、index transformed queryengine の summary が transform query engine に等しいです。ええ、それを query engineD decompose transform に設定します。ありました。うーん、それから transform extra なしの extra も渡します、extra equals。そして最後に、custom query engine query engine、ええ、1 つだけ、ああ違う、おっと、custom query engines、index dot index id。
次の ID、つまりこれは実際には、基本的に XID のような文字列を返すだけです。ええと、そしてそれが変換クエリエンジンです。いいですか？ ではそれを動かしておいて、さらにいくつか質問に答えます。簡単な質問ですが、OpenAI は GPT-4 モデルへの API アクセスを提供していますか、有料ですか、ええ、はい、有料です。クエリエンジンはフィルタリングできるようになりますか、wiki ページに重みを追加してより良くフィルタリングできるようになりますか？ できると思いますが、今回のこれではそれはやりません。
まずは非常に基本的なレベルで動くようにして、クエリを分解できるようにするだけです。ええと、何かを追加してみたい場合は、LA index docs を見て、それをどうやるか確認できます。いいですか？ カスタムクエリエンジン、そして graph に行きます。これは先ほど作成した graph ですよね？ これは、ええと、keyword index から始まる graph です。ええと、next id、つまりこれは graph root と等しいです。
では root ID ですか、それとも root index ですか？ つまり root index を query engine として取得して、retriever mode。これで大丈夫ですか？ Retriever mode、これについては私に対して不満があるようです。ええと、では response mode、ええと、tree summarize、summarize、ええと、service context。Service context、次に storage context もここにあります。はい、storage context。
ええと、はい、では実際にここに上がります。これを変更します。これにも storage context を渡すべきだと思います。はい、これでこの custom query engine ができました。そして、あとは decomposition engine を作るだけです。あと数行のコードです。
ええと、それから皆さんの質問に答えます。ええと、この数行のコードをここに載せさせてください。そうすれば、これがどう動くかがなんとなく見えると思います。ええと、graphs on as query engine、そして custom query engines を渡すだけでいいです。つまり custom query engines、custom query engines として渡します。これで動くはずです。はい、これで response が得られるはずで、それは query com query と等しくなるはずです。
そして実際に、皆さんに response を入力してもらおうと思います。ええと、ここにあるこれらの都市のどれかについて質問してください。たとえば、Seattle と Dubai の天気を比較対照する、みたいなことを聞いてみるかもしれません。ええと、これは query engine です。GPT cash はこれのどこに入りますか？ 今回は GPT cash は使っていません。ええと、GPT cash は、ええと、GPT アプリ用のオープンソースの cache で、ええと、Novus を使うものです。
ただ今回のこれでは、実際には何もキャッシュしません。というのも、FAQ のようなものができるほど十分に LLM に ping する例をやっていないからです。ええと、novis は author date に基づいて docs に重みを追加することをサポートできますか？ できないと思います。はい、では Seattle の天気を比較対照しましょう。Compare、おっと、Seattle と Dubai の天気を compare and contrast。では待ちます。これは質問の分解を表示してから、答えを出してくれます。
ああ、実際には少ししたら response を print out しないといけませんが、見てみましょう。Response、これを読み込ませて、ええと、進めましょう。いいですか？ そして、出ました。Seattle は年間 150 日に降水があり、しばしば小雨が降る、Seattle の正確な年間降水量は提供されていない。Dubai は平均気温が高い、などなど、などなど、などなど、などなど、blah, blah, blah。
いいですか？ つまり、Seattle の天気は頻繁な降水によって特徴づけられる一方で、Dubai は年間を通して高温です。ええ、つまり Seattle は雨が降っていて、Dubai は暑いということです。Vector database 上の governed data に対する解決策はありますか？ PII データが漏れることを懸念しています。ええと、governed data に対する解決策があるか？ つまり、自分でデータをホストできます。たとえば Mil のように、VIS はローカルデータにアクセスするために使えます。もしそうしたければ。ええと、そうでなければ Zillow's cloud を使うだけでもいいです。
でも、もし p i i 関連のことを心配しているなら、たぶん自分のデータを自分でホストして、ローカルでホストし、何かを使いたいのかもしれません。たとえば、vis light ではないかもしれません。Vis light は、ご存じのとおり、主にこの種の、ええと、ノートブック内でこうした概念実証を作るために使われるものです。おそらく Nova standalone のようなものを使いたいでしょうし、ええ、たぶん Nova standalone を使いたいのだと思います。それは、ええと、helm や Docker compose でできます。ええと、Emily、もしそれらのリンクがあれば、チャットに投稿できると素晴らしいです。ええ、というわけで、これがこの基本チュートリアルのすべてで、自分自身のマルチドキュメント q and a を作る方法でした。そして、ええと、残りの時間で、デバッグの助けが必要であれば、簡単そうなものなら少し見てみることができますし、ベクターデータベースについて何か質問があれば、ええと、遠慮なく聞いてください。
さて、質問がたくさんあります。これはレコメンダーシステムにも使えると思いますか？ベクターデータベースのことですか？ええと、それは実際、本番環境におけるベクターデータベースの主要な用途の一つです。ええと、たとえば eBay です。ソースドキュメントを引用するにはどんな解決策がありますか？ええと、単にそれを返すようにできます。あ、すみません、鼻がかゆいです。ソースドキュメントを返すように設定できます。
必要であればリンクを保存しておいて、それを回答と一緒に返すようにすることもできると思います。ありがとう Ian。ありがとう Herve。Herve、ええと、この例で見せてくれたものは素晴らしいです。私たちは wikis データセットで G P T 3.5 turbo モデルをファインチューニングしていて、その後で初めて G P T 3.5 turbo が回答できるようになるのでしょうか？はい、casing、私たちは何もファインチューニングしていません。私たちはデータ注入をしています。ここで起きているのは、これがあなたの l l m で、ご存じのように、こんな小さくて大きな箱のようなものです。その上にベクターデータベースがあり、その上にクエリ処理とインデックスがあります。
つまり何が起きるかというと、いくつかのデータを取り、それをベクターデータベースに入れます。そしてあなたが来て、このクエリボックスを叩くと、クエリがベクターデータベースに入り、こう言います。ねえ、答えはある？すると、それは、はい、答えがあります、と言います。ええと、いや、実際にはそれより少し複雑です。クエリはインデックスに入り、そのインデックスが G B T を呼び出して、こう言います。このクエリをどうやって複数のクエリに分解すればいい？たとえば、Seattle の天気を比較対照する、という場合、G P T が応答して、こう言います。わかりました、Seattle の平均降雨量は？あるいは、ご存じのように、Dubai の平均気温は？そしてそれを使って、これらの質問でベクターデータベースに ping し、その後これらの質問をまとめ、Chad G P T を使ってそれらの質問から答えを得て、本当の応答を組み立て、それをあなたに返します。つまりファインチューニングは行われておらず、単なるデータ注入です。p i I についてですが、私の見解では、もしあなたのシステムに公開エンドポイントがなく、N P I の漏えいが低いのであれば、D L P クラウドソリューションを使えると思います。これについてはコメントはありません。
これは何なのかわかりません。ええと、取り上げてくれたのはわかっていますが、LAMA Index とは何か、ここでの役割は何かを理解するのを手伝ってもらえますか？ええと、わかりました。LAMA Index は、あなたのデータと L L M とやり取りするためのフレームワークです。つまり、先ほど見せた C V P フレームワークのスライドでは、LAMA Index は C と P のようなものです。ええと、ここでの役割は、LAMA index がこれらのインデックス、たとえばこの keyword index、この vector store index を作成するために使うものであり、そしてそれらの、ええと、クエリを適切なベクター、vector stores にルーティングするために使うものだということです。このシナリオでは何トークンが関わっていますか？ええ、実はわかりません。なぜなら、ええと、ここに token counter を入れていなかったからです。さて、linkchain はトークンを数えられるので、実際にはここに token counter を入れる方法があるはずだと思いますが、ただ、私は、私は、わかりません。なぜなら、私はそれをやらなかったからです。
オーケー、e brushy answer Live。返信がモデルの以前から存在する知識のデータを使って生成されたかどうかを知る方法はありますか？ それと、Vector database からの FET とは何ですか？ ええと、なのでこの場合、ええ、ほぼ、この場合は Vector database からのデータだけを使っています。ええと、できることとしては、コードのどこかに、なんというか、ああ、もしこれが見つからなければ、みたいな、何らかの句を入れて、単に、もしこれが Vector database に見つからなければ、ええと、L L M に ping する、みたいに書くことができます。でも実際に私たちがやっていることは、l L M を使って質問とクエリを分解し、つまり、異なる、そして、分解されたクエリ、というか、より単純なクエリに分けているだけです。そしてそれを使って回答を作成しています soya pavon、途中に vector database を挟まずに直接クエリできますか？G B T の上に得られていない利点は何ですか？index ne ここで indexing は必要ですか？ クエリできますか、つまり、クエリできますか、これをこの live に追加します。
ええと、少し待ってください。G P T に直接クエリできますか？ ええ、つまり技術的にはできます。ええと、vector database は必要ですか？ next thing は必要ですか？ ええと、つまり、G P T の上に得られる利点は、UpToDate な知識やドメイン固有の知識を注入できることです。ですから、まあ、I、ここでは譲歩しますが、都市というのはおそらく最もドメイン固有のものではありませんが、公開例として示すために、非常に具体的な知識を取りに行けるわけではありません。ええと、そして indexing は、つまり indexing は、ベクトルがあるとき、そして物事を意味的に比較したいときはいつでも、これを行う必要があるものです。
たとえば、もしできるなら、G P T にこの質問をしたら、答えられるかもしれません。ええと、でも何か尋ねることができるかもしれません。たとえば、ええと、Seattle と Dubai の空港を比較対照してください、と尋ねることができます。この場合、もしかすると、実際には分かりませんが、2021 年以降に新しい空港が建設されているかもしれず、その場合は更新された知識が必要になり、その場合 G B T だけにクエリするのでは十分ではありません。その場合は間違いなく vector indexing が必要になります。このデータ注入は望ましくない hallucinations を最小化して防ぎますか？ はい、それがまさに目的です。
ええと、ああ、Emily。オーケー。まあいずれにせよ、それがまさに目的です。ええと、その、その考え方は、ええと、基本的にすべてのデータを用意しておき、ええと、既存のデータにクエリし、その後、つまり、Chad G B T に行って、ねえ、あの、blah blah, blah、これをできますか？ この質問に答えられますか？ と尋ねることは決してない、というものです。Chat G PT はクエリを分解し、応答を作成するのを手伝うだけです。この方法を使って、G P T の出力を検証できますか、ええと、G P T の出力を検証？ たぶん、I、できると思います。
ええと、はい、もしすべての正しい答えを持っていて、G B T に尋ねて、つまり、G B T が正しい答えを持っていることを確認したいなら、このような方法を使うことができます。ええと、これがどれだけ正確かについて、追加の guardrails をまだ加える必要がありますか？ 追加の guardrails については、ええと、つまり、たとえば、G P T はまだ biased ですし、インターネット上のデータで訓練されていて、それはまだ biased です。ええと、なのでその、その意味では guardrails は、はい、ええと、別の意味では、私たちはそれに何かをさせるよう頼んでいるわけではなく、送信される prompts を制限しています。つまり、世界を支配するよう頼んでいるわけではありません。なのでその点については guardrails は不要です。
複数のソースからvisへのデータの取り込みパイプラインを構築する際に、企業が犯す最大の間違いは何ですか？ そうですね、Julian、それは素晴らしい質問です。なぜなら、それは私自身も個人的に考えてきたことだからです。というのも、こう思っているんです。ねえ、これらのアプリは本当にクールだけど、どうやって最新の状態に保つのか？ どうやってデータを最新の状態に保つのか？ ええと、実はその質問への答えはわかりません。答えられたらいいのですが、答えられたらいいのですが、その質問への答えはわかりません。そしてそれは、私自身も知りたいと思っていることです。悪い質問を制限できますか？ 間違ったクエリをフィルタリングできますか？ つまり、ええ、それはあなたのシステムです。いつでもそこに何でも入れられます。「ねえ、〜についての質問には答えないで、Dallasについての質問には答えないで」のようなものです。
その領域が気に入らない、何でもいいです。ツールはまだハルシネーションしますか？e brushyから注入されたデータの外のプロンプトを尋ねた場合、いいえHamza、どの時点でファインチューニングはコンテキストやデータ注入よりも理にかなうようになりますか？ええと、たくさんのお金とたくさんのデータがあり、モデルを頻繁にファインチューニングする意思がある場合です、Ron、一部のガードレールは、過去のマーケティングおよび営業文言からすでに承認されている企業ソースからの取り込みに由来します。これは質問ではありません。わかりません。これについて何と言えばいいのかわかりません。
さて、私たちが持っている質問はこれですべてのようですし、ええと、時間も近づいています。ですので、これは良い、ええと、良いセッションでした。皆さんにとって良いセッションであり、ええと、クールなアプリを作ることができたことを願っています。もし質問があれば、遠慮なく、連絡してください。ご参加いただいた皆さん、ありがとうございました。そしてEgen、この素晴らしいセッションをありがとうございました。
ええと、次回また皆さんにお会いできることを願っています。今後のイベントカレンダーをご覧になりたい場合は、zillow. com/eventをチェックしてください。ええと、今後のトレーニングでお会いできることを願っています。皆さん、本当にありがとうございました。