Join the Webinar
Loading...
セッションについて
インコンテキスト学習は、LLMを私たち自身のデータで拡張するための強力な方法として登場しました。入力プロンプトに関連するコンテキストを挿入することで、LLMの高度な推論能力を活用し、私たち独自のデータ入力を反映した正確で意味のある応答を生成できます。
LlamaIndexは、LLMを外部データに接続するためのシンプルで柔軟なインターフェースです。LlamaIndexの共同創業者兼CEOであるJerry Liuと一緒に、このセッションにご参加ください。彼がどのようにLlamaIndexを構築したのかを詳しく共有し、そこに含まれるさまざまなツールや、プライベートデータでLLMを強化し始める方法について説明します。
学べること:
- LlamaIndexがプライベートデータでLLMを拡張するのにどのように役立つか
- データ接続、インデックス、クエリのために存在するLlamaIndexツール
- LlamaIndexをMilvusと統合するためのベストプラクティス
分かりました。皆さん、おはようございます、こんにちは、そしてこんばんは。本日のセッションにご参加いただき、誠にありがとうございます。LAMA Indexを使ってプライベートデータであなたのl l Mを強化しましょう。私はEmily kkで、ここZillowsのチームの一員です。
いくつか事務的なご案内をした後、すぐにセッションに入ります。まず、このウェビナーは録画されていますので、途中で退出される必要がある場合でも、数日以内にオンデマンド版にアクセスできるようになります。ご質問がありましたら、画面下部のq and aツール、または画面右側のチャットウィンドウにお気軽に貼り付けてください。ええと、今後のイベントについてはzs.
comをぜひチェックしてください。ええと、theda Slackワークスペースにもぜひご参加いただき、また無料リソースもご確認ください。これらへのリンクは、あと数分でチャットに投稿します。そして本日は、LAMA Indexを使ってプライベートデータでl l mを強化する本日のセッションと、ゲストスピーカーのJerry Leをご紹介できることを嬉しく思います。まだご存じない方のためにご紹介すると、JerryはLAMA Indexの共同創業者兼c e Oであり、L L Mアプリケーションのための中心的なデータ管理およびクエリインターフェースを提供するオープンソースツールです。
その前は、ML研究とスタートアップの交差点でキャリアを積んできました。Robust IntelligenceでMLモニタリングチームを率い、Uber at tgで自動運転AI研究に従事し、Quoraで推薦システムに取り組みました。2017年にPrincetonを卒業し、csの学位を取得しています。Jerryに加えて、ええと、セッションの少し後には私の同僚であるFrank Leuも参加します。私はMLアーキテクトで、ここZillowsのopsディレクターです。
それでは、ええと、Jerry、あとはお任せします。素晴らしいです。Emily、どうもありがとうございます。Emilyが言ったように、ええと、まず短いプレゼンテーションを行い、その後でFrankと、ええと、楽しくお話しします。では、ええと、いいですね。
LAMA Indexは、大規模言語モデルと外部データの間の中心的なインターフェースです。ええと、これはGitHub Proとして、ええと、GitHubのオープンソースプロジェクトとして存在しています。ええと、LAMA Indexの、ええと、組織内には、ええと、さまざまなプロジェクトのエコシステムがあります。ただ、ええと、本日は主にchlor repoと、ええと、それが提供するツールキットについてお話しします。
ここでの背景として、大規模言語モデルは知識生成と推論のための驚異的な技術です。ええと、これらは、まあ、公開されている大量のデータで事前学習されており、さまざまな種類のユースケースに利用できます。ええと、たとえば、質問に答えられること、任意の量のテキストを書こうとできること、テキストを要約できること、そしてさまざまな種類のアクションを計画できることなどです。
L l Mアプリケーションを構築している人、ええと、あるいはこの素晴らしい技術の上にアプリケーションを構築しようとしている人なら誰でも、自分たち自身のプライベートデータでLMSをどのように最適に拡張できるのか、と自問すると思います。ええと、つまり、あなたが一個人のような立場で、ハードドライブ上にたくさんのファイルが散らばっている場合でも、あるいは、エンタープライズユーザーで、notions、slack、Salesforceのような職場向けアプリケーションを大量に持っている場合でも、あるいは、ええと、エンタープライズデータレイクを使用していて、さまざまな種類のデータベースがあり、それらに、ええと、異なる種類のデータが保存されている場合でも、これらの異なるソースに保存されているこのデータで言語モデルをどのように拡張するのでしょうか？知識を、ええと、言語モデルに追加するためのparadigm cessはいくつかあります。ええと、その最初のパラダイムの1つがファインチューニングという考え方で、これは古典的な機械学習により近いもので、たとえば、この新しい知識を組み込むためにネットワークを再トレーニングするだけで新しい知識を追加できます。ええと、そのため、さまざまな種類の、まあ、学習アルゴリズム、手法、プロセスを実行できますが、根本的には、ネットワークの重みに対する何らかの最適化プロセスに行き着きます。ええと、つまり、このネットワークを、まあ、何らかの新しいプライベートデータで学習させるということです。
少なくとも現時点ではいくつか欠点があります。そして、ご存じのとおり、ファインチューニングには、ええ、非常に近いうちに、ええ、とても良くなる大きな可能性があります。しかし現時点では、大量のデータ準備作業が必要です。うーん、ある程度の透明性の欠如があります。ええ、実際にこのデータの上で学習できることによって、ええ、ネットワークがこの知識を内部化してくれると、いわば、ええ、その、数値の中に基本的には、信頼するような形になります。ええ、そして実際にはさまざまなケースでうまく機能せず、かなり高価です。最近のもう一つのアプローチは、インコンテキスト学習という考え方で、実際にプロンプトの中にコンテキストを入れるものです。
ええ、そして、うーん、多くの皆さんはすでにこのパラダイムに馴染みがあるかもしれませんが、その考え方は、事前学習済みモデルを使うというものです。たとえば、事前学習済みのChatGPTやGPT-4のようなものです。そして、ええ、外部知識のコーパス、たとえばエッセイの集合やテキストの集合、あるいは本当に望むものであれば何でも、それを用意し、言語モデルを何らかの検索モデルと組み合わせて、ええ、望む結果を返してもらうことができます。つまり知識のコーパスが与えられた場合、ここではまず検索を実行し、うーん、関連するコンテキストを入力プロンプト自体に注入します。そして入力プロンプトは、たとえば、「こちらがコンテキストです、コンテキストを挿入してください、コンテキストに基づいて質問に答えてください、こちらが質問です」のような形になります。そして、それから、その全体を言語モデルに送ります。
では、インコンテキスト学習をどのように行うのかという一般的な課題があります。うまく行うにはどうするのか、検索、ええ、ええ、そして生成を、意味があり良い結果をもたらす形でどのように組み合わせるのか。最近ではこれを表す別の用語として、検索拡張生成のようなものがあります。うーん、そして、たとえば、ええ、検索をどのように行うのか。プロンプトに適したコンテキストを実際にどのように取得するのか。うーん、長いコンテキストをどのように扱うのか。潜在的に非常に大きいソースデータをどのように扱うのか。そこで、LAMA Indexはそれを解決することを目指すツールキットであり、ええ、その中核的な使命は、あなたのプライベートデータと、ええ、言語モデルとの間のインターフェースを解決することです。私たちの目標は、このインターフェースを、ええ、高速で、安価で、効率的で、高性能なものにすることです。そして、ご存じのように、これらすべての側面に向けて一定の前進はしてきたと思いますが、間違いなく、継続的な改善と成長の領域です。ですので、中核プロジェクトの中には、うーん、ええ、3つの主要なコンポーネントが含まれています。
1つ目は、データコネクタという考え方で、ええ、LAMA Hubというコミュニティ主導のサイトを通じて提供されています。ここでは、既存のデータソースやデータ形式、たとえばAPI、PDF、ドキュメント、sqlなどに実際に接続できます。そして基本的に、これらすべてのデータを、ええ、言語モデルで使える形式で取り込むことができます。ですので、ええ、LAMA Hubには現在、90以上の異なる、ええ、データコネクタが含まれています。取り込みについては少し話しますが、大量のデータを読み込むための、かなり使いやすいツールです。
次の部分は、ええ、その、その、リポジトリの中核に本当に関わるものですが、うーん、データインデックスです。そしてデータインデックスは、本質的には、さまざまなタイプのユースケースに合わせてデータを構造化するデータ構造です。ですので、生データがどこかに保存されていると想像してください。たとえば、ええ、オブジェクトストレージやベクターデータベースに保存されている場合、うーん、インデックスは本質的に、このデータの上にある軽量なビューであり、ええ、たとえばキーワード検索や埋め込みベース検索のようなものを定義できるようにします。うーん、そしてその考え方は、定義する新しいインデックスごとに、異なる検索と文のモードをある程度誘導し、各インデックスは異なる、ええ、ユースケースに最適化されるというものです。そして最後に、最後の部分は、クエリインターフェースのような考え方です。つまり、ええ、データを取り込み構造化したら、ええ、今度は、ええ、これを全体的なクエリインターフェースでラップでき、そこに何らかの入力プロンプトを与えると、ええ、知識で拡張された出力が返ってきます。
つまり、LAMA indexの別の見方としては、実際にはこの種のブラックボックスのようなもので、ええ、基本的にはLMアプリケーション開発のためのデータインターフェースとして見ることができます。ですから、ええ、入力は、実行したいタスクのリッチなクエリ記述になります。ええ、そして出力は、参照、ええ、アクションなどを含むリッチなレスポンスです。そしてLAMA Indexの下では、言語モデル、ええ、それからプライベートデータとの相互作用を管理して、望む結果を返します。ここでの最初の部分は、ええと、これらのコンポーネントのいくつかについて、ええ、もう少し詳しく話しましょう。
データコネクタは、ええ、Lama hubによって支えられており、これは、ええ、先ほど述べたように、さまざまな種類のデータローダーが集まるコミュニティ主導のサイトのようなものです。そしてこれは基本的に、どこからでもあらゆる種類のデータを取り込み、統一されたドキュメントコンテナに入れることを可能にします。ええと、その、そこには、ええ、そこには、このハブ内に多くの異なるデータコネクタがあります。ええ、ですので、この、この数字は実は少し古くなっています。ええ、現在は90種類ほどのローダーがあり、さらに増えています。
たとえば、PDFパーサーが大量にあり、ウェブページリーダー、ええ、doc、さまざまな種類のスクレイパー、そして、ええと、さまざまなAPIなどからロードできるものがあります。また、たとえば画像を含むマルチモーダルドキュメントへの対応も拡大しています。次に、データインデックスとクエリインターフェースについて少し話しましょう。データインデックスは、インコンテキスト学習における一般的なボイラープレートや課題を抽象化するのに役立ちます。ええ、ですので、ええ、私たちは、ええと、たとえば、それらはプロンプト挿入のためにアクセスしやすい形式でコンテキストを保存できるようにします。
ええと、それらは、コンテキストが大きすぎる場合の、ええ、da riあたり4,000トークンのような、さまざまな種類のプロンプト制限に対処できるようにします。また、テキスト分割のようなものにも対処するのに役立ちます。繰り返しますが、考え方としては、インデックス自体はある種、生データの上にあるメタデータのようなものとしてほぼ見ることができる、ということです。そして各インデックスは、ええ、繰り返しになりますが、データの異なる見方を持ち、異なる検索モードを作成します。何を話しているのか、何を考えているのかを示すために、いくつかの異なるインデックスの例を見ていきます。
そして重要な考え方は、ユーザーに、繰り返しになりますが、データに対して検索と合成を実行し、ええ、その相互作用を非常に強力な方法で管理するためのツールを提供することです。最後に、ええと、次の部分はクエリインターフェースで、ええ、これらのインデックスの上にあり、ええ、繰り返しになりますが、この入力を受け取り、望む出力を返すことができます。ここでの例として、ええと、ええ、コード画像を見ると、ええと、根本的な考え方、エンドユーザーに公開されるインターフェースは、単にクエリエンジンを取り込み、ええ、インデックスからでも、自分で定義できる何かからでもよく、そして質問を投げると、望むレスポンスを返すことができる、というものです。最初のインデックス例は、ええ、ええと、ベクトルストアインデックスのようなアイデアです。ええ、そして、そしてこれは最近ますます人気が高まっているものです。この全体的な、ええ、検索と合成のモードのようなものです。
ええ、そして私は、ええと、私は、ええ、これが基本的にどのように機能するのかをお見せしたいだけです、そうですよね？そしてこれは、NovisやZsとも非常に優れた統合ポイントを提供するものです。つまり、その、Vector Store Indexは基本的に、ベクトルストアと言語モデルを組み合わせるという考え方です。そしてこれがどのように機能するかというと、ええと、最初に、ええ、たとえばnotionドキュメントやPDFのようなソースドキュメントのセットがあり、その後データ取り込みを実行し、データ取り込みを実行します。そして、そしてこれらのドキュメントは、ええ、取り込まれ、ええと、へ、ええと、または、または、すみません、ええ、これらのソースドキュメントを取り込み、それらを分割し、何らかのテキスト分割技術を使ってテキストチャンクに分割し、その後、ええ、それらを基本的にノードに分割します。ええ、ノードは基本的にテキストチャンクです。
そして各ノードはベクトルストアに保存され、ええと、それに埋め込みが付与されます。ええと、これは最近、ますます人気が高まっています。ええと、ベクトルストアは基本的に一連のドキュメントを保存し、ええと、各ドキュメントには埋め込みがあり、そしてクエリ時には、このクエリがあります。ええと、あなたは、ええと、ええと、このクエリを取得し、埋め込みモデルを取得し、そしてこのクエリを埋め込みます。ええと、このクエリ埋め込みを使ってベクトルストアから top K lookup を実行し、ええと、最も類似したノードを取得します。
ええと、そして、ご存じのように、これが公開できるさまざまなクエリインターフェースがあります。たとえば、ええと、rossman search を実行したり、hybrid search を実行したり、さまざまな種類の、たとえばメタデータフィルターの追加などを行ったりできます。考え方としては、ベクトルストアから一連のノードを取得し、それからクエリを取り、そしてこれを基本的に、ええと、取得したノードのセットとともに assist module のレスポンスに入力するというものです。ですので、ええと、少しだけ戻ると、response synthesis についてはもう少し後で話しますが、繰り返すと、大まかな考え方は retrieval があり、その後に synthesis があるということです。つまり retrieval は、ええと、ベクトルストアから関連するノードを検索することで行われ、synthesis はノードのセットを受け取り、それをクエリと組み合わせ、そしてレスポンスを生成できるようにすることで行われます。
私たちが持っている index structure の別の基本的な例として、ほかにもありますが、これは非常に基本的な例にすぎません。それは list index のような考え方で、つまり、ご存じのように、いくつかの、ええと、ええと、一連の、ええと、ドキュメントを取り込み、それをチャンク化し、任意のノードのセットを基本的にフラットなリストとして保存することを選べます。つまり、必ずしも top K lookup のために、ええと、埋め込みでインデックス化するのではなく、それを、ご存じのように、ええと、前後関係を持つノードの線形リストとして保存できます。たとえば、node two は node three の前にあり、node two は node one の後にあります。これは非常に単純なデータ構造ですが、ええと、基本的にクエリ時には、リストからこのノートの全セットを取り込むだけでよく、必要であれば ad filters を選ぶこともよくあり、ええと、それからそれをクエリと組み合わせて response synthesis module に入れます。ですので、興味深いのは、ええと、ここでの考え方として、この、ええと、list index のような考え方は基本的に要約クエリを実行できるようにするということです。
ええと、一方で、ええと、たとえばデフォルトの vector store ベースの lookup では、ナレッジコーパスから最も類似した上位 k 個のノートを取得します。これにより、基本的に任意のドキュメントまたはドキュメントの大きなサブセットからのすべてのコンテキストを、ええと、ええと、何らかの response synthesis model に入力できるようになり、たとえば、大きなテキストの塊を要約することができます。実際に retrieval model を持った後で response synthesis がどのように機能するかについても少し話せます。ええと、そして、つまり、複数の異なるテキストを取り込み、テキストの集合が言語モデルのコンテキスト長を超えている場合でもレスポンスを作成できるようにするための戦略がいくつかあります。ええと、ここでの一つの戦略は create and refine です。
そのため、クエリで受け取る最初のノードから開始し、冒頭でお見せしたものと非常によく似たプロンプトを使って初期応答を生成します。つまり、ここにいくつかのコンテキストがあり、ここに、そしてノードからのコンテキストを入れます。そして、このコンテキストに基づいて質問に答える、というものです。違いは、ノードのセットがある場合、前のノードからの前の応答を取り込めるという点です。つまり、この中間応答を取り込み、ノード2からの新しいコンテキストを取り込み、クエリを再度取り込んで、それを言語モデルに戻し、こう尋ねます。ええと、前のノードからの初期応答があります。この新しいコンテキストがあり、既存の質問があります。既存の答えを実際に洗練させて、場合によってはより良い答えを返してもらえますか？そして、このリスト内のすべてのノードを反復処理して、最終応答を得るまで続けます。
ここでの別のアプローチです。この、このアプローチは逐次的です。そして、こちらのアプローチは少し並列的に処理します。各ノードを取り込み、それぞれのノードについて、ええと、そこから初期応答を取得します。つまり、このノードと、ええと、このクエリが与えられたとき、初期回答を返してください、ということです。そして、各ノードに対する答えが得られたら、各ノードを階層的に親回答のセットへと結合し、最終応答が得られるまでそれを続けます。
私たちはこれを、ええと、ツリー要約と呼んでいます。考え方としては、1つのルートノードに到達するまで、ほぼ回答のツリーを階層的に構築していくことができ、そのルートノードが最終回答になる、というものです。そのため、これは async によって並列化できるので、やや高速になる傾向があります。このアプローチは、各ノードを逐次的に反復処理する場合には、実際にはもう少し詳細を含む傾向があります。しかし結局のところ、これは、ええと、経験的な実験次第であり、ええと、さまざまな種類、ええと、さまざまな手法を試してみるということです。
では、説明してきましたが、他の種類のインデックスもあります。ええと、私たちが持っている他の種類の、ええと、統合もあります。強調したい重要な統合の1つは、ええと、novis との統合です。実際に統合を使って、ええと、novis をバックエンドストアとして、ええと、テキストと埋め込みの両方に利用できます。ええと、セットアップ方法は実際にはかなりシンプルです。
必要なすべてのパラメータを持つ Novis ベクターストアのようなものを定義し、ええと、それを何らかのストレージコンテキストでラップしてから、ベクターストアインデックスに入れます。そして実際に、ええと、この、このインデックスにクエリしたいときは、単に、ええと、query engine equals index as query engine と言い、response equals query engine dot query とします。すると、これは、ええと、このインデックスにクエリします。このインデックスは Novis によってバックアップされており、あなたが持っているあらゆる種類の質問に答えられるようにします。ですので、ええと、いくつかの例を見ていくことができます。実際に、ええと、どのように LAMA index を実行するのかについてです。ええと、これは単なるデモのウォークスルーで、ええと、LAMA hub からデータを取り込み、ええと、その上にインデックスを構築し、それに対してクエリすることもできるものです。
ええと、なので今はこれは置いておきます。ええと、スライドを共有しますし、もし時間があれば、少し時間があれば、このプレゼンテーションの終わりの方で、例を手早く見ていきます。ただし、LAMA Index の主なユースケースのいくつかについては議論したいと思います。ええと、これまで説明してきたすべてから、ええと、LAMA Index の全体的な目標は、実際には、ええと、言語モデルを使って自分のデータに対する基本的にあらゆる種類のクエリに答えられるようにするための、非常に優れたインターフェースであることに、ええと、私たち自身を向けることです。ですから、ここでの考え方は、chat G B T と話していると想像してください。質問をして、応答が返ってくる。そのまったく同じ体験を基本的に維持しつつ、今度はこの、ええと、ご存じの、chat G B T でも、あなたが使っているどんな言語モデルでも、全体のデータを可視化できるようにするにはどうすればよいか、ということです。
それで、その、ええと、その、ええと、データに対して尋ねるかもしれないクエリの集合は、単なるシンプルな質問であれ、言語モデルに依頼したい実際のタスクであれ、いろいろ、つまり、さまざまになり得ます。ええと、なので、これらの例をいくつか見ていきます。ええと、LAMA index を使ってデータに対して実行できるクエリの、ええと、さまざまなユースケースです。最初のユースケースは、ええと、基本的にはすでに見てきたものですが、単なるセマンティック検索という考え方ですよね。つまり接続して、データ上にベクトルストアインデックスを定義できます。つまり、G B T Vector Store Index をインポートして、Novis factor store でラップし、それからドキュメントの集合を読み込みます。それから、ええと、このインデックスの上に、ええと、クエリエンジンを定義できます。
そして、この記事の要約をお願いできますか？のような質問をすることができます。あるいは、ええと、ああ、興味深いですね、この、ええと、質問は更新する必要があると思います。ええと、基本的にこの質問は、ええと、たとえば、著者は、ええと、大学時代に何をしましたか？のようなものにすべきです。ええと、なので、この質問が実際には、あなたの知識コーパス内の特定の事実に関する何かを表していると考えるなら、それがセマンティック検索が、ええと、うまく機能するケースです。なので、はい、この回答はその質問に答えることを意図しています。つまり、著者は成長過程のその時期に何をしましたか？ということです。ええと、つまり、ええと、答えは、著者は短編小説を書き、I bM 1401 でプログラミングをしながら育った、となるでしょう。ここでの考え方は、この質問を受け取り、この質問があなたの知識コーパス内で実際に取得できる特定の事実を参照している、というものです。そして知識コーパスを取得し、ええと、あなたの知識コーパスから、その、その、ドキュメントを取得して、それを使って回答を生成します。
そしてそれが、セマンティック検索がうまく機能するケースです。なぜなら、ある種の、ええと、関連検索や topate lockup のようなことを行い、x の関連チャンクを本当に取得できるからです。LAMA index には他にもユースケースがあります。そうですね、そして別のユースケースは、単なる要約という考え方です。どうやって、つまり、知識目的からテキストの関連部分を取得するだけではなく、記事全体を単に要約するにはどうすればよいのでしょうか？ええと、たとえば、list index を使う場合、これは、ええと、復習として、単にリストノード全体を保存し、クエリ時にはデフォルトで、すべてのノードを取得して response synthesis に投入します。この記事の要約を改行区切りの箇条書きでお願いできますか？のように尋ねることができます。そしてこれは基本的に、ええと、この記事に対応するすべてのノードを取り込みます。それがどれだけ長くても、ええと、ええと、それを response synthes、つまりモジュールに追加します。このモジュールは、プロンプトの制限のようなものに対処する複雑さを抽象化し、著者は大学前に執筆とプログラミングを始め、ええと、哲学を学び、というような最終回答を返し、そして著者の全体的な経歴を示します。別のユースケースです。
そしてこれまで主に非構造化データについて話してきましたが、構造化データに対する、ええと、tax receivable サポートも提供しています。つまり、たとえば非構造化データ上に定義された index があり、また、ええと、構造化データ上に定義された index もあります。そしてこれは、つまり、ええと、ある種、私たちの s l index の中にあります。そしてそれは主に2つの主要コンポーネントで構成されています。1つは、ええと、非構造化データから構造化データポイントへの変換です。
つまりデータ取り込み側では、実際に非構造化ドキュメントを取り込み、それをデータベースに読み込むことができます。2つ目の部分は、実際にデータベース内に構造化データがあると、私たちはこのデータに対してかなり、ええと、優れた taxi sql、ええと、インターフェースを提供するということです。したがって、デフォルトの taxi sql を行うことができ、これはテーブルスキーマを受け取るだけです。そして、ええと、L l M を使って、ええと、自然言語クエリから SQL 文を推論できます。その上に追加機能も提供しています。
たとえば、テーブルの上に、ええと、テキスト注釈やコンテキストを追加できます。実際、テーブルスキーマ自体をインデックスに保存することもできます。ええと、大量の、ええと、いわば大量のテーブルボリュームに対処するためです。ええと、もし、つまり、テーブルスキーマが実際にはプロンプトに収まらないのではないかと心配している場合です。ここでの別の例は、この異種データをまたいで合成するというような考え方です。これは実際、LAMA indexで定義できるグラフ構造の一部に関わってきます。ええと、たとえばここでは、ええと、notionドキュメントに対してベクトルインデックスを定義でき、Slackドキュメントに対してもベクトルインデックスを定義できます。
それから、notionとSlackドキュメントの上にlist indexを持たせることで、これらのドキュメント上にグラフ構造を実際に定義できます。この、この、このグラフ構造の仕組みは、実際にこのトップレベルのグラフにクエリを投げるとき、たとえば、ええと、この、この2つの記事の要約を教えて、あるいはたとえば、ええと、リスク要因について教えて、ええと、ええと、もしこれらがいわば財務諸表で、あなたが「ねえ、できますか、ええと、」と尋ねる場合、あるいは実際にはもっと良い質問としては、ええと、この、ええと、顧客Aについての要約を教えて、そう、ええと、ええと、顧客アカウントについて、というようなものです。これは実際にクエリを受け取り、このlistを通してルーティングし、それから各indexに渡します。そしてまず各indexから回答を取得し、それをトップレベルの、ええと、list indexにルーティングし、それから実際に回答を生成できます。では実際に例を見ていきましょう。
たとえば、質問が、つまり、Seattle、Houston、Torontoの空港を教えて、ええと、もし、1つの都市が提供されているなら、空港情報だけを、ただ教えて、そうでなければ、実際に、ええと、ええと、すべての都市の空港について少し説明して、というものだとしましょう。たとえば、Toronto、ええと、ええと、Seattle、そしてHoustonについて、それぞれ別々のindexがあると仮定します。ここにはBostonと書かれているのはわかっていますし、そして、その部分は修正できます。ええと、ここでの考え方は、このトップレベルの質問を受け取り、それが各個別の、ええと、indexにルーティングされ、各個別の、ええと、indexから最初の回答を生成する、というものです。そしてそれを生成し、その応答を受け取り、そして、ええと、各indexからその応答を受け取り、list indexを通してトップレベルでそれを結合します。
そして、ええと、一番下では、ここに、つまり、Seattle、Houston、Torontoの空港は、ええと、というように表示され、その後、実際に、ええと、ええと、あなたが持っているすべての異なるデータソースを非常に高いレベルで合成できる最終応答を返すことができます。少し戻ると、グラフ構造を定義するという考え方は、データに対してやや複雑なビューを定義し、それによって特定の種類の質問に答えるために、ええと、解決するために、少し複雑な検索形式を実行できるようにする、ということです。別の例としては、ええと、単純に、より明示的に異なる種類の、ええと、ドキュメント、または、ええと、本当に比較したいものなら何でも、比較対照できるようにすることです。ですからここでは、つまり、ええと、ここでの例として、HoustonとBostonのスポーツ環境を比較対照したいとしましょう。この質問を受け取り、そして、つまり、HoustonとBostonの両方について、ええと、ええと、vector indexで構成されるグラフを組み立てるとします。
それらは別々のインデックスです。そして、それらをトップレベルのリストインデックスと組み合わせます。このクエリは各インデックスに個別にルーティングされます。そして、クエリ分解モジュールのようなものを追加できます。そこで、このより複雑な質問を受け取り、より単純なものに変換できます。たとえば、ヒューストンを拠点とするスポーツチームは何か、ボストンを拠点とするスポーツチームは何か、そしてその質問を使って実際に質問する、ええと、または以前と同様に各個別のベクトルインデックスに対してその質問を行い、応答を返してもらいます。つまり、ヒューストンとボストンの両方について、スポーツチームの答えを返してもらい、その後、両方の答えがリストインデックスを通じて組み合わされ、そして最終的な答えが返ってきます。
繰り返しになりますが、このグラフ構造に加えて、たとえば、その、これらのクエリ分解モジュールのような追加要素を定義することで、より複雑なク、ええと、クエリを実行できます。たとえば、stern X、ええと、異なる種類のドキュメント間で比較できるようになります。ええと、これは、たとえば単純なセマンティック検索を超えて、より複雑な分析クエリのようなものを尋ねられる非常に強力なツールです。もう1つ強調したいユースケースは、まさにマルチステップクエリの考え方で、これは、ええと、chain of thought prompting のような考え方を想起させます。ご存じであれば、その考え方は、複雑なクエリをデータソース上の複数のより単純なものに分解できるというものです。ここでの例は、たとえば、「著者が始めたアクセラレータープログラムの最初のバッチにいたのは誰か」という質問です。これは少し複雑な質問です。なぜなら複数の部分があるからです。
この特定の著者についての質問に答えられるデータソースにアクセスできるとしましょう。この質問を取り、ええと、言語モデルによって動作するクエリ分解モジュールを使って、ええと、より単純な質問を推論します。「著者が始めたアクセラレータープログラムは何か？」そしてそれを使って最初の応答を生成できます。つまり、著者は yc というアクセラレータープログラムを始めました。それからそれを再び入力します、つまり、ええと、またはクエリ分解モジュールを通して再入力し、「LY C'S アクセラレータープログラムの最初のバッチにいたのは誰か？」と尋ねます。ええと、それをデータソースインデックスに再入力します。答えを返してもらいます。
つまり、この ycs アクセラレータープログラムの最初のバッチは 2005 年に始まり、さまざまなスタートアップが含まれていました。そして、質問を踏まえて、このデータソースから答えられるすべての質問に答えたと感じるまで続けます。ええと、そうすると最終的な答えが返ってきます。ここでの重要な考え方は、より複雑な質問がある場合、望むならそれをより単純なものに分解することを選べるということです。実際に満足のいく答えを得られるようになるまでです。最後に、私が話したい最後の部分は、ええと、時間的な性質を持つ非常に興味深い質問もあるということです。ええと、質問の一例は、「著者は yc での時間の後に何をしたのか？」です。このような質問の場合、基本的なセマンティック検索を行うだけだと、著者の yc での時間だけを説明しているノードに当たることになります。ええと、本当に、前や後を見るのではなく。
そこで私たちは、基本的な検索プロセスの後でも、質問に関連し得る追加のコンテキストを継続して入力できるようにする一連の抽象化を持っています。なぜなら基本的な検索、たとえばセマンティック検索を行う場合は、この埋め込みを取り、おそらく著者の yc 期間中の情報と照合するだけだからです。そして、ええと、多くの場合、時間的な形で追加のコンテキストを入力することが役立ちます。たとえば、将来のノードを見る、または前のノードも見る。そしてこの場合、将来のノードを見る必要があります。
ここでのもう一つのユースケースは、recency filtering、つまり古くなったノードという考え方です。ええと、ああ、これは実際、ユーザーから広く要望されてきた機能で、たとえば、同じ、ええと、同じデータのタイムスタンプ付きバージョンが3つあると想像してください。そしてそのデータの一部は古くなっていて、ええと、当然ながら最新の、ええと、バージョンが最も最新のものになります。ですから質問をするときに、たとえば、ええと、古いコンテキストを大量に与えて言語モデルを混乱させたくはありません。そこで私たちは、ええと、さまざまなタイプのrecency filteringを行うための機能を提供しています。それが、何らかの、ええと、数学的な式による時間加重のようなものであれ、あるいは単に明示的に日付でソートするものであれ、そして実際に古いノートをフィルタリングして除外できます。
これにより、ええと、より最近のノートを優先して返答を返すことができます。いいですね。というわけで、発表は基本的に以上です。このスライドは、ええと、ええと、チャットにも共有します。ええと、そして、別の、つまり、ここにも他のスライドがあり、ええと、基本的にはさまざまなタイプのチュートリアルを示しています。
たとえば、ここでは下流アプリケーションと統合できます。ええと、たとえば、外側のエージェント抽象化としてLAMA index plus line chainを使ってチャットボットを構築できます。ええと、ここにはstreamline appを構築する方法のチュートリアルがあります。デモのウォークスルーもたくさんあり、特にzero sixで行った新リリースでは、検索クエリエンジンやトピックまたはデータをカスタマイズできるようになっています。ええと、さらに、ええと、この統一されたクエリインターフェースを構築するのに役立つよう追加したシンプルなルーター抽象化もあります。いいですね。
それでは、プレゼンテーションは以上だと思います。次は、ええと、Aviが、ええと、Frankと話しながらいくつか質問に答えます。では、Jerry、そのプレゼンテーションありがとうございました。ええと、ちなみに素晴らしい講演でした。それで、ご存じのとおり、聴衆からの質問と私自身からの質問がいくつかありますので、もう少し、ええと、会話のような形で、ええと、会話とQ&Aのハイブリッドのようにできればと思いました。ええと、llamaについてもう少し話し、その起源の話について、そして皆さんが今後どこへ向かうのかについて話したいと思います。
ご存じのとおり、皆さんが、ええと、今後予定しているワクワクする機能にはどんなものがあるのか、ということもです。ええと、最初の質問ですが、つまり、私たちは、lmsに関して、人々が大きく2つの陣営に分かれているように見えると思いますよね？ 1つ目は、継続的に進化するモデル、非常に特定の目的のために設計されたモデルが出てくるだろうと考える人たちです。たとえば、金融データに関するBloomberg、G B Tのようなものです。そしてもう一方には、将来は、こうした非常に、非常に汎用的なlms、非常に大規模なモデルが多くなるだろうと考える人たちがいます。ええと、あらゆる目的のために設計されたものですよね？ 本質的に、想像するに、長いインデックスの中で本当にできること、あるいはやりたいことなら何でも行うためのものです。つまり、これら両方のパラダイムに役立つでしょうし、もし最初の道、つまり、より、より小さいけれどもよりターゲットを絞ったモデルに進む場合、これらとLumexをどのように使うかに潜在的な違いはあると思いますか？ええ、良い質問です。これは発表の最初の部分にかなり関わってくるもので、fine tuning、distillation、ええと、そういった考え方についてです。
ええと、たとえば、誰もが新しいデータの上で何らかの機械学習プロセスを行って、基本的に、さまざまな種類のタスクをこなせる、こうした専門化されたモデルをすべて学習し、蒸留するような世界を想像できると思います。そしてそれは本当に、より古典的な機械学習の領域に入っていきます。ええと、それが、最近の多くの現在のモデルが、ええと、本当に特定のタスク向けに学習されている理由です。うーん、私たちはおそらく、より専門化されたモデルを持ち始める世界に向かうのだと思います。うーん、実際、その世界はおそらく良いものだと思います。ええと、単一のモデル提供者のようなものによる独占が少なくなるだけですから。うーん、そしてシステムの観点からも非常に理にかなっていると思います。
その理由は、うーん、これらの大規模モデルは素晴らしいのですが、ええと、その性質上とても大きいからです。そしてもちろん、クラスやスケールやそういったものは下がっていくでしょうが、これらのネットワークには、おそらく何らかの根本的な情報容量のようなものがあって、つまり、その、あるモデルが今のように強力であるためには、ええと、ある最小サイズが必要になる、ということです。そうですよね？ だから私は、純粋にほとんどコストと専門化の目的だけでも、特にたとえば、モデルをデバイス上やオンプレミスで動かせるようにしたい場合には、より蒸留され専門化されたモデルをもう少し見るようになると思います。なので、うーん、私は個人的にそのようなエコシステムにとてもワクワクしています。そして次の点として、LAMA index はこれら両方の世界で使われ得ると思います。なぜなら、こうした専門化モデルであっても、つまり、最初に述べたようなトレードオフ、つまり自分のデータに正しい知識を確実に取り込めるようにするという点は、依然としてたくさんあるからです。そうですよね？ たとえば、入ってくる新しい情報のすべてについてファインチューニングすることを選んで、そのモデルが知識を取り込めるようにすることもできますし、あるいはモデル自体を固定して、それを検索モデルと組み合わせることもできます。そして多くの場合、それは考えるのがずっと簡単です。つまり、たくさんの機械学習をする必要はなく、これを全体的なデータパイプラインやシステムの一部として配線するだけでよく、そうすればそのまま使えて機能する、という考え方です。
そして最後に言うと、ファインチューニングや蒸留というこの考え方に沿って、私が非常に関心を持っていることの一つは、実際には、ええと、非常に優れた検索モデルをファインチューニングできるという考え方です。たとえば、ええと、このモデルをずっと小さくする、GBT four のようなものを使って、知識能力の大部分を取り除くようなことです。Wikipedia について知っている必要はないし、他のことを知っている必要もありません。ただ、与えた新しい情報について推論するのが非常に得意であるという点だけを残すのです。そしてその部分に私は非常に関心があります。なぜなら、つまり、そのモデルはいったいどれくらい小さくできるのか、そうした驚くべき推論能力をなお持つためには、どこまで小さくできるのか、と考えているからです。それは実際、私たちが LAMA index で構築しているものに大いに役立つでしょう。ああ、そうですね、100% です。
そして、既存の多くの、ええと、これらの大規模言語モデルや自己回帰型言語モデルの大きな問題は、ええと、それが非常に、非常に大規模なデータコーパスで訓練されていて、次トークン予測をたくさん行っているために、ええと、もしすぐにその次のトークンを正しく得られなければ、あー、結果として、結果としてハルシネーションが起きたり、間違った答えになったりする、という点だと思いますよね？ うーん、何らかの形でモデルに、プロンプトから非常に具体的にデータを見るよう本当に制約をかけることができれば、それは間違いなく、ええと、あなたがLoma Indexで取り組んでいることの両方において、あー、そしてさまざまな、あー、他のアプリケーションにおいても、大きな前進になると思います。素晴らしい回答だと思います。本当にありがとうございます。ええと、ここにいる方々から、あー、参加者からもいくつか質問が来ています。そして最初の質問は、あー、おそらくより一般的なもので、LAMA indexはlmと組み合わせられるRivaモデルなのですか？ はい、それは良い質問ですね。
そうすることもできます、うーん、それは、そうなのですが、それだけではなくもう少しあります。うーん、LAMA indexにはいくつか異なるレイヤーがあります。LAMA indexの最上位の見方としては、うーん、LAMA indexは単にあなたのデータとLLMを包むブラックボックスであり、そのため、通常言語モデルに問い合わせるのと同じ、同じやり方でLAMA indexに問い合わせることができます。そして、うーん、たとえば、あー、track BTやGBT fourのようなものと同様に、あー、応答が返ってきますが、私たちが言語モデルとあなたのデータとの相互作用を管理するので、あなたのデータに関するコンテキストを実際に持った応答が返ってきます。さて、その内部、そのブラックボックスのすぐ下では、両方、たくさんのことが起こっています。
うーん、あなたのデータに対する検索のようなものがあり、それから、あー、要素を組み合わせて答えにすることができる、いわば合成のようなものがあります。そして、あー、これは検索を行い、次に合成し、それで完了するという1ステップのプロセスにもなり得ます。あるいは、多段階の検索・合成プロセスにもなり得ます。たとえば、データ上にグラフを定義する場合や、あるいは、あー、私が先ほど触れたような、いわゆる思考の連鎖プロンプティングのようなものを定義する場合です。そして、うーん、これらのモデルをそれぞれ独立して使うことも選べます。
ですから、もしそれを自分自身の、あー、アプリケーションロジックのようなものと組み合わせたい場合には、LAMA Indexを検索モデル単体として使うこともまったく可能です。はい、はい。こちらも素晴らしい、素晴らしい回答ですね。あー、それに対する素晴らしいフォローアップのような質問として、あー、番号の方からも、ええと、各クエリごとにインデックスを動的に構築できるのか、それともすべてのクエリについて手動で事前定義しておく必要があるのか、というものがあります。それは、それは実際とても良い質問です。これは私たちがかなり考えてきたことだと思います。
うーん、現時点では、インデックスは、うーん、ユーザー指定のようなものです。つまりユーザーが、あー、自分が望む一連のインデックスを定義する必要があります。うーん、ですので、もう少しうまく整理して言うと、あなたがユーザーであるようなものです。うーん、あなたがこれらの、このLMアプリケーションを開発し、一連のインデックスを定義します。これはつまり、大まかに言えばオペレーターとして、あー、この、あー、ええと、この、あー、アプリケーションが受け取るかもしれない質問の種類について、ある程度の感覚を持っているということです。なので、意味があると思う一連のインデックスで、それに対してほとんど準備しておきたい、ということです。さて、私たちが非常に強力だと考えていることの一つは、たとえば、異なるインデックスは異なるユースケースに最適化されているという点です。
たとえばベクトルインデックスがあるなら、それは意味検索により適しています。もしless indexがあるなら、それは、うーん、要約のようなものにより適しています。先ほど示したような凝ったグラフの一つがあるなら、それは比較対照のようなものにより適しています。うーん、私たちが最近ちょうど導入したようなものの一つに、より良いルーター抽象化という考えがあります。そこでは、あー、ある一連のツールのようなものを定義できます。各ツールは特定の種類のクエリにより適しており、それらすべてを何らかのルーターの下にまとめるのです。
ええと、それはこのエージェントツールのパラダイムに似ていて、基本的に何をするかというと、ある種、ええと、これらすべてのツールを単一のクエリインターフェースの下に統合するようなものです。つまり、クエリを受け取って、それがルーターに渡され、ルーターが実際にその仕事に適したツールを自動的に選べるわけです。ユーザーとして、ええと、このインデックスは実際にはこうしたさまざまな種類の、ええと、クエリを解決しようとすべきだ、と予測する必要がある代わりに。すごいですね。応答してください。さまざまなユースケース向けに異なる種類のインデックスやクエリ設定を開発することに集中して、それを何らかの迅速な抽象化の下にまとめることができます。
だから、それは私たちがとてもワクワクしていることです。そしてこれは、尋ねられる質問をより自動的に予測できるようになる、ということにつながると思います。ええと、それから次の部分は、実はまだ話していないのですが、では、ええと、インデックス作成プロセスもどう自動化するのか、ですよね？これはどちらかというと、適切なインデックスにルーティングするためにクエリエンジンのプロセスをどう自動化するか、という話ですが、例えば、本番システムで大量のデータが入ってくる場合に、そのデータに対して最適なインデックスを、ユースケースとシステム要件の両方を踏まえて、どうやって自動的に、ええと、見つけるのか、そしてその部分が結果的に重要になってくるわけです。はい、なるほど。いつ頃、もしかすると、いつ頃この種の、このルーター、ああ、このルーター抽象化が Luma index に入ると期待できますか？ええと、ルーター抽象化は実はすでに LAMA index にあります。ええと、私たちは、それをしばらく前から持っていて、つい最近、ええと、基本的には昨日、そのような形で改良しました。
なので、ええと、もしよければ、ええと、これはちょうど出した新しいブログ記事への無料宣伝になります。ええと、それから、より自動的なインデックス作成のようなものについてですが。ただ、ルーティング抽象化はほんの一歩にすぎないと思います。ええと、さまざまな種類のクエリを本当に処理し、それをデータ上で実行するための、より優れた自動化インターフェースを構築するには、まだまだ多くのステップがあると思います。例えば、ビルド時の自動インデックス作成、ええと、トークン使用量のようなものを最適化できること、こうしたことすべてについて、私たちは、私たちは今も継続的に改善しています。
いいですね、いいですね。ええと、それに関連する質問として、つまり、ローカルで実行して Loma Index を使うのに最適な L l M は何ですか？そしておそらく、ええと、まずあなたに答えてもらいますが、でも、ええと、もちろん。あなたの答えがどうなるかはたぶん想像できます。ええ、そうですね、まあ実は私は本当に、ええと、これについて広範なテストをしたわけではないので、実際のところ、私がこれに答えるのに最適な人間かどうかさえわかりません。なので、ぜひあなたの考えを聞きたいです。私はこれらを、例えば、ええと、alpacas のものや stable lm、それから hugging face を少し触ってみたことはあります。
どれも、まあ、どれも悪くないと思います。ええと、それでも open ai の should b t の方が単に優れていると思います。ええと、でも、つまり、ええと、多くの基本的なタスクについては、それらは機能すると思いますが、正直なところ、ええと、私はたぶん答えるのに最適な人間ではないので、実際にはコミュニティから追加の、ええと、フィードバックや洞察をぜひ得たいと思っています。はい。はい。
ええと、思うに、その、いろいろなモデルがあって、それぞれに得意なことがある、ということだと思います。で、うーん、残念ながら、それに答えるとても簡単な方法はないと思います。ええ、でも、そうですね、多くの部分は、あなたが言及したように、目を開かせるようなものが、おそらく今のところのゴールドスタンダードだと思います。うーん、その、G P D four、ええ、でも、その、可能性としてフルの、そうですね、私が Loma Next について本当に、本当に気に入っているのは、その、完全なオープンソースソリューション、フルスタックのオープンソースソリューションを持てる可能性があるということです。つまり、その、あなたの、あなたの、あなたのインデックス作成から、使用しているどんな LM まで、ですよね。はい。
ええ、今日オープンソースの LMS はたくさんありますが、うーん、それぞれ少しずつ異なる方法で訓練されていると言えるでしょう。彼らには、うーん、得意なこともあれば、そうでないこともあります。彼らは、彼らはまたあまり得意でないこともあります。うーん、そして本格的に進める前には、やはり少し実験が必要です。ですが、うーん、言うならば、どんな、その、どんな、どんな、Facebook の LA model をベースにしたモデルでも、おそらく始めるには良い場所だと思います。ええ、おそらく。
ええ、私は、それは、うーん、かなり良いと聞いたことがあります。私は、私はかなり良いと聞いています。最近は毎日のように、何らかのプロプライエタリモデルの新しいオープンソース版が出てくるのを見ている気がしますし、そこに何らかの収束があっても驚かないでしょう。ええ、ええ、もちろんです。もちろんです。うーん、それから、その、たぶんこの質問はよく受けると思いますが、うーん、その、私が、これを少し終わりの方に残している理由の一つでもありますが、その、Llama mix と blank chain を比較できますか？ええ、もちろんです。
うーん、なので、思うに、その、つまり、ええ、それは、それは、とても人気のある質問です。ええ。ええ、それは、それは良い質問でもあります。うーん、私がそれを説明するなら、私たちはかなり、つまり、今プレゼンを見たばかりなら、私たちは、あなたのデータの検索合成のようなものに非常に焦点を当てています。つまり、それが私たちが注力している主な目標だと思いますし、私たちはそれを一連のビルディングブロックとしても重視しています。うーん、そしてまた、それを全体的なシステムへとパッケージ化することにも取り組んでいます。そのシステムは、私たちが話したすべての次元を解決するものです。たとえば、使いやすさの側面からパフォーマンス、レイテンシ、コストのようなものまで、これらすべての異なることです。
そのため、私たちは取り入れたいこれらすべての抽象化について、本当に深く考えてきました。そして目標は、ユーザーが自分のデータと対話し、クエリすることを本当に簡単にすることです。なので、でも、Lane Train とはいくつか重なる部分がありますが、Lane Train はこの領域に関しては抽象化が少し軽めだと言えるでしょう。うーん、そして、その、私たちはあなたの Lane Train アプリとの統合も本当に簡単にしています。ええ、なので、Lane Train が持っているものとしては、たくさんのプロンプト、評価のようなもの、エージェント抽象化のようなもの、いくつかの検索関連のもの、そしてまた、チャットボットを作れるようにすることや、その、多くの異なる、異なるものがあります。
ですから、私たちは自分たちを本当に、本当に優れたデータプラグインのようなものだと考えています。つまり、エージェントであれ、Lane Train のようなものからであれ、chat G P T インターフェースであれ、その他どんなものでも、クライアント抽象化の一部として使えるものです。ええと、auto G P T のようなものでも、Loma Index でも、ええと、特にコアモジュールとして、それがまさに私たちが進んでいく方向だと考えています。そして、もしそれを使うなら、理想的には、データに対して期待するすべての機能を提供し、それを下流のアプリケーションに実際に簡単にプラグインできるようにしたいと思っています。そうですね、それに加えて言いたいのは、Jerry のスライドの中にも、Lumex を Lang Chan と一緒に実際に使っているデモについての素晴らしいものがあるということです。ですから、この2つは実際、少し深く掘り下げてみると、非常に、非常に補完的なプロジェクトだと思います。ええ。
とはいえ、素晴らしい、素晴らしい質問です。ええと、lms についての前の会話に少し乗っかる形で、どのオープンソース l l m を使うべきかという話ですが、あなたの目から見て G 3. 5 に近い性能を発揮する l l m はありますか？ええと、またフォローアップとして、GBT four に匹敵するものはありますか？ああ、はい、私は、私は、ええと、そうですね、主なものはおそらく、ええと、anthro のようなものだと思います。それは、ええと、かなり一般的な見方でもあるようです。ええと、他のモデルもいじってみましたが、ええと、そこそこ良いように思います。ただ、主な点は、ええと、これらのモデルの多くについては、いくつか見るべき点があるということです。1つは、ええと、どれくらい頻繁に幻覚を起こすかです。ええと、どれくらい頻繁に実際に、ええと、あるいは1つ目として、どれくらい頻繁に幻覚を起こすか。2つ目は、どれくらい頻繁に間違った決定をするかです。何らかの反復的な推論チェーンに入れると、実際に間違った応答を選んでしまう、ということです。
ええと、そして3つ目は、その出力の品質はどうか、ということです。ですので、ええと、私は、いくつかのモデルをかなりストレステストしました。検索統合のようなものを通じてもそうですし、la、ええと、LAMA index の中には、反復的な、ええと、推論や統合の呼び出しを行えるインデックスがいくつかあります。そして、これらのモデルの多くは途中のどこかでつまずくと思います。つまり、この情報を完全に推論することができないのです。間違った情報を幻覚として出すことがあります。ええと、そして G B T three、ええと、特に G B T four は、ええと、良質な回答を出力できるという点で非常に優れていると思いますが、プロンプトのチューニングをそれほど多く必要としません。
そして、それは非常に強力なことだと思います。ええと、またそれが、たとえば G P T four がこの auto G P T のようなものすべてで使われ始めている理由でもあると思います。なぜなら、このデータに対して基本的な推論を行い、反復呼び出しを通じて大量のエラーを伝播させない形で実行できると、ある程度信頼できるからです。そして、これはこれまでのところ、これらの要素の多くでは本当にできないことだと思います。そうですね、それに非常に、非常に簡単に付け加えると、G P G 3. 5 とオープンソースに関しては、唯一の、いや、どんなとは言いませんが、llama ベースのモデルであればそれに匹敵すると言える、というわけではありませんが、かなり近づくことはできると思います。
ええと、そして本当に、OpenAI のトレーニングデータの品質は、多くのオープンソースモデルのそれよりも少し優れていると思います。ええと、G P T four に関しては、ええと、残念ながら今のところそれに近いオープンソースモデルはおそらくないでしょう。おそらく一世代ほど遅れていますが、これらのオープンソースモデルの多くは追いつき続けると思います。ええと、そして、その観点でも現在進行中のオープンな取り組みがたくさんあります。QD four は、もし私が推測するなら、おそらく、だいたい1兆パラメータくらいあるのではないかと思います。それについて何か考えがあるかどうかはわかりませんが、Jerry。
ええと、それから、推論能力は、つまり、単にコンテキスト長が長いだけではなく、より深いモデルでもあることから来ていると思いますよね。そして、うんうん。その深さこそが、おそらく G D four の向上した推論能力に本当に寄与しているもので、残念ながらオープンソースの世界では利用できるものではないと思います。そうですね、つまり、私が気になっているのは、同じような two d four の推論能力を得られるのか、ただしそれを、うーん、もっとずっと小さなパッケージにできるのか、ということです。そうですよね。
そして、それはまだ未解決の問題だと思います。ああ、そうですね。ああ、そうですね。そうですね。私はずっと気になっていたんです。より小さなモデルの上に、ある種の再帰性を加えることができれば、少なくとも何らかの証明推論能力のようなものが得られるのかどうか、ということに。
でもとにかく、それは、ええと、私がこれから話そうとしていることの話で、なぜ、なぜ PowerPoint や PDF をインデックス化するときに、l l M はその情報を少し違った形で理解するのでしょうか？ ああ、うーん、そうですね。インデックス化については、異なる種類のデータのようなものですね。つまり、ええと、LAMA Hub の仕組みは、これは私たちのデータ取り込み部分のようなものですが、PDF、PowerPoint、API などの異なる種類のデータソースから、どんな形式であってもテキストに変換するだけです。だから、たとえば、PowerPoint 内のテキストであれば、それはテキストですよね？PowerPoint 上の画像であれば、何らかの画像キャプションモデルなどを通じてテキストに変換します。ええと、PDF のようなものであれば、PDF に OCR r をかけるか、パーサーによって必要なことを何でも行って、それをテキストに変換します。
つまり、ある意味では、ええと、私があまり議論してこなかった部分があり、それは、その形式が何であれ、テキストへの解析の品質のようなものです。たとえば、あなたの、ええと、tax parser が本当にひどい場合、言語モデルがインデックス化して内容を理解するのは単純に難しくなります。うーん、だから、この全体のシステムを構築するときには、ええと、tax parsing は、重要ではあります。ええと、それを何らかの tax format に変換する必要はありますが、以前よりはかなり簡単になっていると思います。なぜなら、うーん、Q P T には、生のテキストを理解する能力があり、それに対してあまり多くの処理をしなくてもよいからです。何らかの最低限の方法でクリーンアップしておけば、ええと、すでにかなりうまく機能する傾向があります。だからこそ、LAMA hub のようなものがあり、さまざまな種類のデータソースから、利用できる形式へと取り込むことができるのです。
素晴らしい内容ですね。そうですね、うーん、ちょっと、ええと、二重に追っているだけですが、チャットにも質問があるように思います。ええと、それは q and a とは違うものだと思いますが、これらのいくつかについて話せるように確認しておきたいだけです。もちろんです。もし何かあれば、たぶんこの会話の最後の5分から来る質問は、あと1つか2つくらいしか時間がないと思いますが。
でも、もし何か、あなたが、特に答えたいものがいくつかあれば、それでいきましょう。ああ、もちろんです。これについてちょっと確認したいだけです。Archer が、異種データに対するカスタム合成はスケーラブルなのか、と質問していたと思うからです。そして、long index のようなもので、スケーラビリティの数値を見たことがあるか、ということですね。そうです。そして、これは良い質問だと思います。なぜなら、これは私が話したいことの一つだと思うからです。うーん、つまり、その考え方として、私は、スケーラビリティは間違いなく課題だと思っています。つまり、うーん、l l m の呼び出しをチェーンするような場合はいつでも、少し遅くなります。なぜなら、より多くのデータを使って言語モデルを繰り返し呼び出しているからで、それだけコストも増えるからです。
それで、あー、根本的にはそれが課題だと思います。つまり、私たちもかなり考えてきたことです。ええと、とはいえ、こうした異種データに対する、ある種の統合を少し推論しやすくする方法はいくつかあります。これを考える一つの方法は、ええと、一つには、async api のようなものを許可しているので、これらすべての呼び出しを、あー、異なるノード間で並列化できるということです。つまり、グラフの一つのノードが完了するのを順番に待ってから、次のノードを待つ必要はありません。そこで呼び出しを並列化できるのです。
ここでの次の部分は、私が、私たちが示したデフォルトは、異なるvector indexes の上に list index のようなものを定義するものでした。これは実際にはデモ目的に近いものです。ちなみに list index は、あまりスケーラブルではありません。なぜなら、繰り返しになりますが、list index であるという性質上、すべてのデータを投入しているからです。つまり、あー、language model に、あー、すべてのデータを処理するよう求めているわけです。私が思うに、一つの方法、これを考える別の方法としては、他の vector indexes の上に、ええと、あー、何らかの vector index があると想像してみることです。
そうすると、まずトップレベルのクエリに関連するドキュメントのサブセットを取得できます。そしてそのドキュメント内で、ある特定の情報を探すようなことができます。つまり、composable graph 構造を使ってできるさまざまなことがあり、これらの、あー、検索や統合、そしてその他のさまざまなことを、少しだけよりスケーラブルにできます。はい。
いいですね。おそらく、あと一つ質問する時間しかありません。いくつかあるのは分かっていますし、実際にはまだいくつもあります。ええと、なので、私たちがやってみるのは、残りの質問についてはオフラインで何とか対応できるか見てみる、ということにしますが、最後の質問は、もちろん。ええと、これもまた聴衆からのものですが、つまり、クエリ自体についてですよね。多くの場合、prompt を実行するときや query を実行するとき、クエリ自体にも、あー、つまり、その中にも多くの知識が埋め込まれていることがよくありますよね。では、クエリの重要な側面やクエリ頻度をどのように見つけるのか、そして、LAMA index にある何らかの index や indices と組み合わせて、クエリをよりうまく活用できるのか、より良い、あるいはより洗練された応答を得るためのクエリのより良い活用方法はあるのか、ということです。それは、いい質問ですね。
ええと、実際、多くのユーザーがこの点について質問してきたと思います。あー、これについてはまだ、明示的なチュートリアルやデモのようなものはありません。ええと、ただ、これは本当に重要になると思っています。というのも、その考え方は、つまり、多数のクエリがあり、あー、knowledge purpose から何かを検索するだけでなく、類似したクエリも検索したい、というものだからです。これはある意味で、memory のように考えることができますが、単なる一般的な chat bot conversational memory というよりも、実際にはクエリのための memory のようなものです。ええと、できる非常に基本的な例としては、ただ、あー、クエリ用、つまりその、クエリですよね、あるいは static queries と responses 用に、別のバックグラウンド index を作成する、というものです。
そうすると、検索を行うときに、knowledge purpose から検索できます。ええと、あー、それには index や graph structure が定義されているとします。そして、query information に対して定義された index もあります。両方のソースから情報を検索して、それらをどう組み合わせるかを考えられます。今後、この query の memory と、あー、knowledge corpus index との、より深い相互作用については、おそらく私たち自身でも調査していくことになると思います。はい。あー、なので、それは非常に興味深い問題だと思います。
それで、ええと、私たちは、これに適したアーキテクチャについてもう少し深く考えたいと思っています。はい、間違いなく。私としては、それはおそらくもう少し未解決の問いでもあると思いますし、ぜひ、ええと、うんうん。ええと、見て、見ていきたいですね、つまり、この分野でさらに研究が出てくるにつれて、そこにどんな興味深い応用があるのか、私たちがどんな興味深い方法で取り組んでいるのかを。なので、ええと、はい、私は、ええ、ちょうど時間の区切りに来ているようですね。
ええと、それでは、ええと、あなたに戻します、つまり、このQ&Aを進めてくださってありがとうございます。そして、Jerry、素晴らしいプレゼンテーションもありがとうございました。ええと、Emilyに戻します、ええと、皆さん、ありがとうございました。はい、はい。素晴らしいプレゼンテーションをありがとうございました、Jerry。
本当に素晴らしかったです。そしてFrank、素晴らしいQ&Aセッションの司会をしてくださって本当にありがとうございました。まだたくさん質問がありますので、Jerryからオフラインで回答を得られるよう最善を尽くし、おそらくそれをブログのまとめに取り込むことになると思います。ですので、それを皆さんに必ずお送りします、ええと、これらの質問に対応したいと思っていますし、Jerryには今日の残りのミーティングに進んでいただく必要があります。ですので、少し早めに退席していただくことにします。
ええと、皆さんご参加いただきありがとうございました。このセッションを楽しんでいただけていれば本当に嬉しいです。録画へのリンクといくつかのフォローアップ資料を、ええと、私たちから経由で受け取ることになりますので、その点ご確認ください。それから、次回のZillowsウェビナーでお会いできることを願っています。そちらはzillowsで確認できます。
com/event。皆さんありがとうございました。素晴らしい。ありがとうございます。ありがとうございます。
Meet the Speaker
Join the session for live Q&A with the speaker
Jerry Liu
Co-founder and CEO of LlamaIndex
Jerry is the co-founder/CEO of LlamaIndex, an open-source tool that provides a central data management/query interface for your LLM application. Before this, he has spent his career at the intersection of ML, research, and startups. He led the ML monitoring team at Robust Intelligence, did self-driving AI research at Uber ATG, and worked on recommendation systems at Quora. He graduated from Princeton in 2017 with a degree in CS.