Join the Webinar
Loading...
セッションについて
LLMは膨大なデータで訓練されていますが、あなたのドライブやデータベース、APIの背後に存在し、LLMを再訓練できる速度よりもはるかに速く絶えず変化している、あなたのデータでは訓練されていません。その解決策がRetrieval-Augmented Generation（RAG）です。
学べること:
- RAGが内部でどのように機能するかの基本
- LlamaIndexがRAGをどのようにシンプルにするか
- RAGアプリケーションの構築方法
- アプリをさらに発展させたいときのための7つの高度なテクニック
さて、本日は本日のセッション、LlamaIndex による高度な Retrieval Augmented Generation アプリケーションをご紹介できることを嬉しく思います。そしてゲストスピーカーは Laurie Voss です。Lori は LlamaIndex の Developer Relations 担当 VP です。彼は 27 年間 Web 開発者として活動してきました。NPM Inc. の共同創業者でもありました。
そして彼は、複雑なテクノロジーのトピックをわかりやすくすることで、テクノロジーを誰にとっても利用しやすいものにすることに強い情熱を持っています。ようこそ、Lori。こんにちは。お招きいただきありがとうございます。画面を共有してもよろしいでしょうか？はい、お願いします。
素晴らしいです。Christy、丁寧なご紹介をありがとうございます。皆さん、こんにちは。ええと、今日は何についてお話しするのでしょうか？ええと、Retrieval Augmented Generation についてごく簡単におさらいします。それは何か？なぜそれを行うのか？Retrieval Augmented Generation の課題は何か？どのように行うのか？ええと、それから LAMA Index に入り、それが Retrieval Augmented Generation の実現にどのように役立つのかを見ていきます。
ええと、7 つのテクニックを詳しく見ていきます。皆さんの RAG の力をレベルアップできます。ええと、そして最後に、アプリを本番環境に持っていく方法について話して締めくくります。まずは Retrieval Augmented Generation、つまり RAG から始めましょう。根本的に、RAG は LLM の制限に対する対応です。
LLM は膨大なデータの山で訓練されていますが、皆さんのデータで訓練されているわけではありません。ええと、皆さんのデータは、Open AI が見ることのできないファイアウォールの内側にあります。ハードドライブやデータベースの中、あるいは API の背後にあります。皆さんの視点から見て、皆さんのデータこそが最も興味深いデータです。ええと、そして LLM にそのデータについて処理させ、質問に答えさせたいのであれば、それを渡す必要があります。
しかし、ええと、現時点では単純にすべてのデータを一度に渡すことはできません。なぜなら、LLM はそれを扱えないからです。ChatGPT に会社のすべての文書を一度に渡したら、吐き出してしまうでしょう。ええと、コンテキストウィンドウは現在、数十万トークンの規模ですが、ええと、皆さんの会社にはおそらく数億トークン分のデータがあります。
LLM が無限のコンテキストウィンドウを持つ世界であっても、それは依然として実用的ではありません。質問に答えたい、質問をしたい、そのたびに、会社がこれまで持っていたすべての情報を LLM に渡すというのは現実的ではありません。選択的でなければなりません。ええと、そこで RAG の Retrieval の部分が出てきます。最も関連性の高いコンテキストを渡す必要があり、それは非常に複雑な問題です。
ええと、しかし、単にコンテキストサイズだけの話ではありません。RAG をどのように行うかには、多くの固有の課題があります。RAG を行うことで何が得られるのでしょうか？4 つのものが得られます。第一に、精度です。もちろん、私たちは正しい答えを求めています。ええと、しかし最も関連性の高いデータを取得し、クエリ時にそれを LLM に渡すことで、その答えが単に正しいだけでなく、可能な限り完全なものになるようにします。
不完全な答えは、完全に間違った答えと同じくらい誤解を招く可能性があります。精度と密接に関連しているのが、私たちが faithfulness と呼ぶものです。この用語は業界全体で異なりますが、本質的にはハルシネーションがないことを意味します。LLM は役に立とうとしすぎます。時には、データを、そして本物のデータだけを与えることで、物事を作り上げてしまうのを防ぐ、助けになります。
ええと、誰もハルシネーションを望んでいません。それは AI アプリケーションを構築するうえで最も苛立たしい部分の一つです。もう一つの大きな課題は最新性です。ええと、基盤モデルを自分のデータでファインチューニングすることで、ある程度は精度と faithfulness を向上させることができますが、それは非常に時間がかかり、費用もかかります。そして皆さんのデータは常に変化しています。時には分単位で変化します。
したがって、リアルタイムで変化する CHA データに追いつくための唯一の実用的な方法は、Retrieval Augmented Generation を使うことです。そして最後に、出所があります。これは、LLM がどこから答えを得たのかを示せるという意味です。出典を引用できることは学術的な文脈では良いことですが、検索について話している場合には、多くの場合不可欠です。答えが由来する文書を見つけることが、検索の目的であることがよくあります。それは単に、あると便利な機能ではありません。
だからこそ、私たちはRAGを行うのです。では次に、どのようにRAGを行うのかに進みましょう。ええと、RAGの中核は検索であり、それを行う方法はたくさんあります。最も高いレベルでは、たとえば、Googleのような検索エンジンが使っている、そして何年も使ってきたのと同じアルゴリズムを使って、単にキーワード検索を行うことができます。これらは情報を見つけるのがかなり得意です。
実際、私たちはその問題に長い間取り組んできました。そして構造化クエリもあります。データでいっぱいの巨大なリレーショナルデータベースがある場合、それをすべてテキストにダンプしてからNLMに渡すのは理にかなっていません。なぜなら、そこには価値のあるリレーショナルな文脈がすべて含まれているからです。ええと、その代わりに、LMSはSQLクエリを書くのがかなり上手になってきており、LLMにデータベースをクエリさせて、その方法で重要な文脈を取得できます。そしてベクトル検索があります。これは最もよく耳にするものです。その理由の一部は、それが新参者だからですが、同時に、Brave Perfecta検索が本当に独自に強力だからでもあります。
最初に行うことは、データを数値に変換することです。具体的には、ベクトルと呼ばれる巨大な数値配列に変換します。この作業を行うモデルはlmsと密接に関連しており、データをキーワードとしてではなく意味としてエンコードします。利用可能なベクトルの総集合は膨大であり、それはベクトル空間として知られています。そのため、テキストを数値に変換することは、したがってテキストをベクトル空間に埋め込むこととして知られています。そしてそのため、その数値は略して埋め込みと呼ばれますが、これは紛らわしいです。
それが何であるかとその名前の間には、数段階の隔たりがあると思いますが、私たちはそれらを埋め込みと呼んでいます。すべてのデータをこのように埋め込む効果は、その後、クエリを同じ方法でベクトル空間に埋め込むことができるという点です。ベクトルが意味をエンコードする方法により、クエリへの答えはベクトル空間内で数学的に近くに行き着く可能性が高く、比較的単純な数学で見つけることができます。これにより、検索拡張生成を行うことができます。すべてのデータを埋め込み、次にクエリを埋め込み、クエリに近い文脈を取得し、その文脈とクエリをLLMに渡すと、クエリに対する妥当な答えが得られます。単に文脈をそのまま吐き出すだけではなく、それを文脈化し、説明もします。
つまり、この驚くべきベクトル検索を使うこともできますし、キーワード検索や構造化クエリを使うこともできます。しかしもちろん、さらに良い方法として、その3つすべてを同時に使うこともできます。ええと、探しているものがたまたま適切なキーワードであれば、キーワード検索は非常にうまく機能しますし、ベクトル検索は、検索しているものと同じ意味を持つ別のキーワードを使っても機能します。したがって実際には、それらすべてをある程度使いたいところです。そこでLAMA Indexの話になります。LAMA Indexは、データをLLMに接続するオープンソースフレームワークで、PythonとTypeScriptで利用できます。
ええと、データをLLMに接続するというのは、言うのは簡単ですが、実際に行うのは非常に難しい問題の一つです。典型的なRAGパイプラインを見てみましょう。まず、ソースからデータを読み込み、取り込み、処理できるように準備します。そのプロセスには多くの複雑さがあります。次にインデックス作成が来ます。
ここでデータを埋め込み、ベクトル検索に備えます。先ほど言ったように、それが唯一の方法ではありませんが、優れた方法です。そしてそのデータをベクトルストアに入れますが、ベクトルストアにどのように入れるか、そして当然、どのVector storeを使えるかについては多くの選択があります。そのデータをクエリする準備ができたら、まず最も関連性の高い文脈を取得する必要があります。もう一つのtaがあります。これはまた、取得したデータの後処理に関わることが多い、隠れた複雑さが大量にある別のタスクです。
次に、そのコンテキストをプロンプトと組み合わせる必要があります。そして、プロンプト作成自体がひとつの大きな技術であることは誰もが知っています。ええ、しかしプロンプトをコンテキストと組み合わせることも、隠れた複雑さを伴うタスクになり得ます。そして最後に結果を得ますが、それは何をしているかによっては、さらに処理が必要になるかもしれません。たとえば有効な JSON か何かに変換する、といったことです。つまり、ここでは多くのことが起きています。RAG は魔法のような技術ですが、魔法を正しく扱うのは難しいのです。
では、このプロセスの各段階に LAMA Index がどのように関わるのかを話しましょう。始める前に、LLM を選ぶ必要があります。私たちは O llama のような API や Bento ml のようなホスト型オプションを通じて、数十種類の LLM モデルに対応しており、その数は日々増えています。まずは取り込みから始めましょう。取り込みの最も単純な形式は、ディスク上の大量のファイルを直接メモリに読み込むことです。その方法はこちらです。
LAMA index では 2 行のコードで、ええ、実際の取り込み部分は 1 行のコードで実行できます。2 行目はインデックス作成です。ここで示しているこの simple directory reader は、CSV、PDF、Word ファイルを含む非常に多様なファイル形式に対応でき、さらにマルチモーダルなことをしたい場合には画像、音声、動画にも対応できます。データが静的ファイルにない場合はどうでしょうか？先ほど言ったように、データはあらゆる場所に存在します。Google Drive や Notion、ある種のデータベース内にある場合はどうでしょうか？LAMA Index は LAMA Hub というレジストリも提供しており、lamahub で利用できます。
ai、そしてこのハブは、RAG アプリケーションの構築をより簡単にするための巨大なソフトウェアライブラリを提供しています。そこには、お気に入りのデータソースに接続するためのコネクタ、エージェントを構築するためのツール、アプリケーションを評価するためのデータセット、そして LAMA packs と呼んでいる一連のものが含まれています。これは本質的に、さまざまな複雑なタスクを 1 行で実行できるようにする任意のコードパッケージです。これらは関連する場面でまたすべて触れますが、今関連しているのはローダーです。したがって、他のソースから読み込む必要がある場合は LAMA hub を確認できますが、この例では simple directory reader を使い続けます。私たちのデフォルトに満足しているなら、そこで完了し、2 行目に進むことができます。そこでは、ええ、データを埋め込み、インデックス化して、埋め込みモデルに送ります。
しかし、デフォルトでは満足できないかもしれません。その場合は、取り込みパイプラインを構築したいでしょう。これにより、一連の変換を設定できます。埋め込みのためにドキュメントをどのように分割したいかを指定でき、どのメタデータが必要か、どの埋め込みモデルを使うかも指定できます。その結果は、オンライン 11 で確認できるノードのセットとなり、それを使って 14 行目でインデックス作成を開始できます。そしてもちろん本番環境では、おそらくこれらのパラメータを試しながら、同じパイプラインを何度も実行することになるでしょう。
そのため、取り込みパイプラインをキャッシュし、即座に再読み込みできるようにしています。何も変更されていなければ、変更された部分だけを再実行します。これで第 2 段階、つまりインデックス作成に移ります。先ほど述べたように、これはデータのチャンクを取り、それらをベクトル空間に埋め込む段階です。私たちは、あらゆるものについて非常に幅広く対応しているのと同様に、膨大な数の埋め込みモデルに対応しています。
ええ、これらは取得の速度と品質の両面で、それぞれ異なる性能を持っています。ここでの主力は vector store index であり、リモート API 経由であれローカルモデルであれ、すべての埋め込み処理を担います。これからの例の中で、ユースケースに応じて Vector Store Index を何度も呼び出すのを見ることになるでしょう。また、知識グラフインデックスも確認したいかもしれません。これは非構造化テキストをエンティティと関係に分割し、それによってデータに対してエンティティベースのクエリを実行できます。しかし今やすべての埋め込みが揃ったので、第 3 のステップ、つまりそれらを保存する段階へ進む時です。私たちは数十種類のベクトルストアに対応しています。
ベクターストアはすべて、おおよそ同じことをしています。巨大な数値の山を受け取り、ベクトル演算を使ってそれらに対して検索できるようにします。しかし、この分野には多くの差別化要素があります。後で見るように、どのものがメタデータフィルタリングやハイブリッド検索を可能にするか、という点です。メタデータフィルタリングとハイブリッド検索が何であるかを説明しますが、それによって次の段階、つまりクエリに進みます。そして、私たちがあまり多くは話さないこと、それはプロンプティングです。他の RAG フレームワークはプロンプトやプロンプトエンジ、プロンプトエンジニアリングについて多く語りますが、私たちは異なる見方をしています。
LAMA index は batteries included なフレームワークです。つまり、私たちはすでに優れたプロンプトを考案しているということです。それらは試行済みで検証されており、細かく調整されていて、フレームワークに組み込まれています。そのため、すべてを自分で理解する必要はありません。もちろん、必要であればプロンプトを変更できます。最も基本的なことから始まります。つまり、プロンプトを検査して、私たちが提供しているデフォルトが何であるかを確認できますし、事前またはクエリ時に独自のものを渡すこともできます。構文やプロンプトのカスタム、カスタマイズは、以前にこの種のことを行うために他のライブラリを使ったことがあれば、非常になじみ深いものになるでしょう。
しかし本質的に、プロンプティングとは、LLM に任意のテキストを与え、質問にどう答えるべきかを指示することです。では、クエリに入りました。クエリの最も基本的な形式から始めましょう。ええと、インデックスから query engine を取得し、この方法ですべてのデフォルトを受け入れ、そのままクエリを実行します。これは素晴らしいです。
これは、LAMA Index を始めるのがとても簡単である理由の一部です。なぜなら、本当にそうしたければ、ロードからインジェスチョン、埋め込み、ええと、保存、クエリ、そして結果までをわずか 5 行のコードでエンドツーエンドに進めることができるからです。しかしもちろん、LAMA index のすべてと同様に、query engine はカスタマイズできます。ええと、デフォルトで行っているのは、あなたのデータのコンテキストのうち最も関連性の高い上位 2 つを取得し、それらをクエリ用に LLM に返すことです。しかし、ここに示すように、示すように、独自の retriever を構成できます。私は similarity top K を 5 に設定しています。これは、コンテキストとして最も関連性の高い 5 つのコンテキストを選択することを意味します。
synthesizer も構成できます。それは、engine が LLM に送信する前にクエリを組み立てる方法です。ここには、このトークで取り上げる時間のない利用可能な戦略がいくつもありますが、実質的にそれらがすべて行うのは、コンテキストのチャンクをまとめて、それらを使って LLM にクエリすることです。最後に、retriever と synthesizer を組み合わせて LLM にクエリすることで、query engine を作成できます。つまりこれは、基本的なクエリに関わるすべての段階を示すために、10 行のコードで、先ほど 2 行のコードで行ったのとまったく同じことをしたということです。
より高度な戦略を見ていくと言いました。では、その最初のものを見てみましょう、失礼しました。その最初のものを見てみましょう。これは、sub-question query engine として便利にパッケージ化されています。ここで sub-question query engine が解決する問題は、複雑な質問です。関連のないデータソースが多数ある場合、1 つの質問に答えるために、それらのうち複数からデータを取得する必要があるかもしれません。
そして、それは単一のソースからの単一のクエリでは不可能です。そこで Ascension が行うのは、LLM を使ってクエリをより簡単な質問の simp、系列に分解し、次にデータソースの配列が与えられると、各クエリを適切に各データソースへルーティングし、各データソースからの回答を単一の回答に結合することです。このおもちゃの例では、データソースを 1 つだけ作成しています。前のスライドにあったようなシンプルな query engine を作成し、それにメタデータを割り当てています。これは、そのツールが何と呼ばれるべきか、そしておおよそ何をするのかを指定します。l and m はこの説明を使って、どのデータソースがどの種類の質問に答えることになり、答えることができるのかを判断します。
これらのソースは、必要なだけいくつでも持つことができます。次に取り組みたい問題は精度です。ええと、基本的なRAGでは、コンテキストがクエリに正確に関連していることを確実にするのに苦労します。それに対処するための戦術の1つは、small to big revalとして知られています。small to big retrievalでは、大きなドキュメントを1文ずつに分割し、最大限の精度を得るために、その非常に具体的な文に対して検索を行います。しかしその後、合成の段階で、クエリとコンテキストをLLMのコンテキストとしてLに渡す前に、戻って、今検索した文の前後5文分のコンテキストを取得します。それがsmall to bigです。
これにより、求めている精度を維持しながら、LLLMが扱えるコンテキストをより多く与えることができます。これをLAMA indexで実現するのは驚くほど簡単です。というのも、ここでもまた、私たちがすべての作業を行い、それをきれいにパッケージ化しているからです。クエリエンジンを作成する際に、検索後、ただし合成前に動作するnode post-processのリストを指定し、気軽な名前のmetadatareplacement node post processorを、target metadata keyをwindとして使用できます。これは自動的にノードを検索します。ええと、それらのノードはすべて前後のノードへのリンクを持っており、クエリをLLMに送る前に前後のノードをつなぎ合わせます。Small to bigは、ノードのポスト処理による精度向上ですが、プリプロセスによってもより高い精度を得ることができます。
L-M-L-L-Mを助ける方法の1つは、データについて既に持っているメタデータを使い、検索前にそれでフィルタリングすることです。埋め込み検索を使うことに加えて、一部のベクトルデータベースは、各埋め込みに任意のメタデータを付与することをネイティブにサポートしています。この手法の優れた例は、企業の年次法定提出書類を表すドキュメントを扱っている場合です。ここに示す完全一致フィルターのように、年をメタデータとして付与し、その年でデータを事前フィルタリングできます。ここでの重要な教訓の1つは、データについてのメタデータがあるなら、LLLMに扱わせるものを少なくすることで助けられるということです。この答えは2021年のドキュメントにあると分かっているので、2020年や2019年のコンテキストを与える必要はない、と言えます。
特定の年だけを与え、自分が関連していると分かっているドキュメントの中で、その魔法を発揮させればよいのです。Vector index auto retrieverを使用すると、各メタデータフィールドを説明し、LLM自身にメタデータクエリの適用方法を判断させることができるため、こちら側で手動の手動 refinement を行わなくても、自然言語でクエリし続けることができます。このリストから分かるように、私たちがサポートしているベクトルデータベースのほとんどは、メタデータフィルタリングもサポートしています。サポートしていないものはごく一部だけです。これは皆さんにとって良いニュースです。
次の例はハイブリッド検索です。ええと、埋め込みベースのベクトル検索は本当に魔法のようですが、先ほど言ったように、業界として私たちは検索エンジンの構築に何十年もの努力を注いできましたし、現時点ではそれらは本当にかなり優れています。したがって、最も興味深いベクトルデータベースのいくつかは、実際には実行してピボットする検索エンジンです。それらはtop K retrievalだけでなく、既存の検索アルゴリズムも使えるようにしてくれます。その中で最も有名なものの1つはVM 25と呼ばれています。
ハイブリッド検索をサポートするデータベースがあれば、それを使うのは非常に簡単です。vector store query mode equals hybridを渡し、その後alphaという値を渡すだけです。ええと、同じクエリをベクトル検索と従来の検索の両方に対して実行します。Alphaは、検索が従来の検索の結果またはベクトル類似度にどの程度依存するかを決定します。0は結果が完全に従来のキーワード検索から来ることを意味し、1は完全にベクトル検索から来ることを意味します。そしてこの数値を調整して、自分にとって最良の結果を得ることができます。ご覧のとおり、ハイブリッド検索もサポートしているベクトルデータベースのリストはかなり短くなっています。ええと、このリストにVespaはありません。まだそれ用の特定の統合を構築していないからですが、ハイブリッド検索をサポートしており、LAMA Indexとうまく連携します。
私がそれに言及した理由は、Vespa が Yahoo によって発明されたからで、元 Yahoo の私としては、Vespa にはいつも愛着があるからです。ええと、高度な検索のもう一つのユースケースは複雑なドキュメントです。すべてのドキュメントが単なるテキストの山というわけではありません。複雑な表を含んでいることがよくあります。では、複雑なドキュメントをより単純なクエリの集合へと分解する方法を考えてみましょう。
ただしその前に、そもそも表をクエリする機能について紹介する必要があります。Pandas Query engine という素晴らしい組み込み機能があります。Python で pandas の表を作成します。たとえば PDF を読み込んだり、CSV ファイルを読み込んだりします。ええと、そして LLM を使うことで、それらの表をクエリして正しい値を取得するための正しい pandas 呼び出しを生成できます。その後、各表の説明を提供できます。自分たちで提供することもできますし、LLM に表を見させて、その表に何が含まれているかを導き出させ、ええと、index nodes と呼ばれる一連のものを作成することもできます。
これらは、先ほど取り込み時やキャッシュ時に vector store index に渡しているのを見ていただいた通常のノードと同じようなものですが、これから紹介する retrie はそれらを特別に扱うことを node します、失礼、これから紹介する retrie はそれらを特別に扱うことを node します。各 index node には、ここで作成している辞書への index が含まれています。辞書は pandos query engines のインスタンスで構成されており、ドキュメント内の各表につき 1 つあります。さて完全を期すために、すでに表を抽出済みであると仮定できるドキュメントの残りの部分をパースするところを示します。通常のノードと index nodes の両方、すべてのノードに対して動作する vector retriever を作成します。
そして今度は、先ほどと同じように query engine を設定します。retriever と synthesizer を組み合わせて query engine にします。ただし今回は、通常の retriever の代わりに recursive retriever を使います。recursive retrie retriever は使用する retriever のリストを期待するので、先ほど作成した vector retriever を渡します。ええと、また、index node を取得した場合には、そのノード内で見つけた index を subquery engines の辞書で検索し、そこでクエリを実行すべきだと認識します。そこで、前のスライドで作成した、ID から query engine へのマップを渡し、それを使って query engine を作成します。
これで、トップレベルのエンジンへのクエリは、関連するすべてのノードを取得することになり、そのノードの 1 つが表であれば、その表をテキストであるかのように読もうとするのではなく、その表に対して panda の操作を実行して、その表から正確な結果を取得します。そして、ええと、合成されたプロンプトを LLM に返し、LLM はコンテキスト内で完全な回答を返します。非常に一般的な高度な検索のユースケースは、SQL データベースを直接クエリしたいというものです。SQL データベースには本当に優れたデータが尽きることなく存在します。したがって、ここでのユースケースは明白です。これを分解して、どのように行うのかを示しましょう。内部では LAMA index は SQL alchemy を使用しています。Python でデータ作業をしたことがあるなら、すでに馴染みがあるでしょうが、ここでは、Lama Index 独自の SQL database class を初期化するデータベースに接続するだけで済みます。
SQL database class は natural language SQL Table query engine によって扱われます。これもまた非常に覚えやすい名前の 1 つですね、ええと、LAMA Index の別の組み込み機能です。これが内部で行うことは、クエリの一部として表の schema を LLM に渡し、sql を生成させることです。これは明らかに難しい処理なので、GPT-4 や Mr Large のような他の高度な LLM で最もよく機能しますが、事前に表の名前が分かっていて、schema がプロンプトに収まると確信している場合には、これを実現する信じられないほどシンプルな方法です。これが、先ほど見ていた recursive retriever にもうまく適合することが分かるでしょう。なぜなら、SQL tables を、retriever 内でクエリできるもう一つの、ええと、node にすることができるからです。しかし、その条件が当てはまらない場合はどうすればよいでしょうか？表の schema がメモリに収まらない場合や、事前にどの表をクエリすればよいか分からない場合はどうでしょうか？ええと、その場合は、ここで行っているように、se、ええと、SQL と table node mapping を作成できます。
変換する各テーブルのインデックスを作成し、それをリトリーバーに変換して、それをSQL Table Retriever Query Engineに渡します。これはまた別の素晴らしい組み込み機能です。これはインデックスを検索して最も関連性の高いテーブルを見つけ、それを自然言語SQL Tableクエリエンジンに渡して、以前と同じようにクエリを実行します。つまり、データベースにどれだけ多くのテーブルがあっても、LLMにどのテーブルが最も関連性が高いかを選ばせ、クエリを実行させることができます。どのテーブルにクエリすべきかはどうやって分かるのでしょうか？LLMを使い、テーブル名とカラム名を見ますが、より親切にしたい場合は、ここで示しているようにテーブルを手動で説明して、どのテーブルが役立ちそうかについてより多くのコンテキストを与えることができます。本日取り上げる最後のユースケースは、最も複雑なものでもあります。なぜなら、これは単なる検索戦略戦略ではなく、LAMA Indexにおけるエージェントの例だからです。
実際に使われているこのお気に入りの例は、私たちのデモアプリケーション、S sec insights, ai、SEC Insights aiです。AIは当初LAMA Indexのデモンストレーションとして意図されていましたが、今では適応やカスタマイズが可能な完全なオープンソースのデモアプリケーションになっています。これは、1社または複数社の財務報告書類を与えると、それらを比較・対比し、要約して、提出書類に何が含まれているかを教えてくれるものです。最新のY Combinatorバッチには、これを事業全体としている会社がありますが、私たちにとっては単なるデモです。ここでの最初のステップは、各データソースごとにクエリエンジンを作成することです。
ここでは、それらは非常によく似たソースです。単に別々のディレクトリにあるだけですが、ええと、今日すでに話した戦略のいずれかを使った、まったく異なるクエリエンジンであってもかまいません。そのうちの1つはSQLクエリエンジンでもよいです。別の1つはpandasテーブルを見るものでもよいです。別の1つは、ええと、sub-questionクエリエンジンでもよいです。
これらのエンジンを組み合わせることができますが、今回はエージェントなので、エージェントが選択できるツールを定義します。先ほどのSQLの例で行ったように、ツールにメタデータを与え、LLMがどのツールが質問に最もよく答えられるかを判断できるようにします。次に、エージェントを定義しますが、これもまた驚くほどシンプルです。ツール利用が可能なGPT-4のような、十分に高性能なLLMを与えます。ええと、作成したツールのセットを与えます。エージェントは、クエリを与えられると、最適なツールを選択し、そのツール上でクエリを実行し、答えが得られるまで続けるループに入ります。
この作為的な例では、クエリは非常にシンプルで、ツールも非常にシンプルです。しかし覚えておいてください。上で話したどの例でも、上で話したどの例でも、エージェントが利用できるツールの1つにすることができたのです。つまり、ええと、1つはsub-questionクエリエンジンを行い、別の1つはtext to sqlを行い、3つ目はhybrid searchを実行する、ということもできました。このようにソースを組み合わせることで、本当に素晴らしいことができます。ここまで、素晴らしいものを構築する方法を見てきました。これで最後のステップ、つまり本番環境に持っていく段階に進みます。
ここにLatent Spaceポッドキャストのリスナーが何人かいることを願っています。これは、AIエンジニアの台頭とAIの未来全般についての素晴らしいポッドキャストです。そして最近、ホストのSeanは2024年を本番環境におけるLAMA indexの年だと表現しました。私たちは完全に同意します。AIで作ったものをノートブックから本番環境へ出すための素晴らしい方法の1つがcreate lamaです。
これはcreate React appをゆるくベースにしたコマンドラインツールです。これはアプリケーションジェネレーターであり、動作するフロントエンドインターフェースと、serverless、TypeScript、node js、またはPythonから選べるバックエンドを備えた、出荷可能なragアプリケーションを作成します。つまり、この1つのコマンドを実行するだけで、カスタマイズして出荷できる動作するアプリが手に入ります。多数のオプションとテンプレートが付属しており、開発を加速し、すばやく本番環境に到達するための本当に優れた方法です。こちらは、すでにLAMA Indexを本番環境で利用している企業の短い一覧です。
これは私たちが望むよりも短いです。というのも、私たちが実際にそれを使用していると知っている本当に巨大な企業は、公にそう言うことに少しためらいがちだからです。しかしご安心ください。現在、本番環境で LAMA Index を使用している有名企業があります。簡単な例として、スタートアップを扱う大手法律事務所である Gunderson Detmeras を取り上げてみましょう。彼らは、テック業界の現状における現在の契約を支える膨大な内部データを持っています。Chat,GD は LAMA Index を使用する社内ツールで、弁護士がそのコーパスに関連情報をすばやく問い合わせ、クライアントの質問により迅速に回答できるようにしています。それでは、今日学んだことをもう一度振り返りましょう。
LAMA Index とは何かについて話しました。これはオーケストレーションフレームワークですが、ツールとコネクタのハブでもあります。そして最後に、本番環境に移行するための一連のツールです。検索拡張生成、取り込み、インデックス作成、保存、クエリ、ブリーフの各段階を取り上げ、LAMA Index のパイプラインとパイプラインキャッシュのサポート、インデックスの仕組み、利用可能なベクターストアのセット、そしてそれらがサポートする機能について話しました。プロンプティングと、プロンプトをカスタマイズする方法、クエリエンジンを作成する方法についても簡単に取り上げました。
次に、これら7つの例に入りました。まず、ナイーブな top K 検索から始めました。次に、より複雑な質問のためのサブクエスチョン・クエリエンジンに入りました。small to big による精度向上のための後処理について話しました。クエリの精度を高めるためにメタデータフィルタリングを使用すること、そして LLM をさらに使うことでそのフィルタリングを自動化できる方法について話しました。ベクトル検索の最良の部分と従来の検索エンジンの最良の部分を組み合わせるハイブリッド検索を取り上げ、非常に複雑なドキュメントをインデックス化するための再帰的リトリーバーについて話しました。
その後、テキストから SQL への変換と複数ドキュメントエージェントの世界、そしてそれらの異なる手法をどのように組み合わせられるかについて簡単に触れました。これが、あなたの AI への旅の始まりに役立つ一瞥になっていればと思います。私たちはまだ本当に初期段階にあり、誰もが学んでいるところですので、ところどころ少し圧倒されたとしても気にしないでください。また、LAMA Index でできる素晴らしいことの数々について感じていただけたなら幸いです。そして、あなたが作る素晴らしいものを見るのを楽しみにしています。皆さん、お時間とご清聴ありがとうございました。
ああ、Laurie、本当にありがとうございました。ええと、では、ええと、オープンソースの、ええと、ソフトウェアであることに敬意を表します。質問があります。Llama Index の商用版はありますか？はい。ええと、私たちは、ええと、オープンソースの Python 版と TypeScript 版に加えて、ええ、ベータ版として LAMA Cloud というサービスを提供しています。ええ、これは GUI と、ええ、ほんの数クリックで、これらすべてを代行するマネージド取り込みサービスを作成できるものです。
ええと、まだベータ版ですが、当社のウェブサイトにアクセスすれば、ええ、私たちに連絡することでベータ版に参加できます。わかりました、ではここで聞いたわけですね。ホットな見解です。ええと、さて、いくつか質問があります。ええと、Q&A ウィンドウに1つ、いくつか見えます。
ええと、Daniel の質問です。デッキに組み込まれたプロンプトは、トピック外の質問をする問題を解決しますか、たとえば宇宙はいつ作られたのか、のような質問です。しかしウェブサイトはドッグフードに関するものなので、つまりあなたのドキュメントはおそらく犬に関するものになるということです。ええと、それは素晴らしい質問です。ええと、いいえ、私たちのプロンプトはそれに特化して対処しているわけではありません。私たちのプロンプトは、ええ、関連する質問をすることを前提としています。ええと、ただし、それに対処するために使える、ええ、前処理と後処理の戦略があります。
はい、そして garish からの質問です。ええと、こんにちは。ありがとうございます。スライドを共有していただけますか？はい、もちろんです。ええ、もし、もし私を Twitter でフォローしていただければ、私のユーザー名は sdo、S-E-L-D-O です。
ええと、このトークの直後にスライドをそこに置く予定です。はい。匿名希望の方からです。私が直面している最大の問題の一つは検索速度で、ユーザーは信じられないほど高速なキーワード検索に慣れていますが、ハイブリッド検索でさえ少し遅くなってしまいます。検索エンジンをユースケースとした場合、結果と速度、FTSを管理するための最良で最も初歩的な方法、つまり推奨される最小構成は何でしょうか？これは素晴らしい質問です。ええと、LMSが従来のキーワード検索よりも高いレイテンシを持つという事実を回避する方法は、あまり多くありません。
ええと、ただしlmsの機能の一つは、本質的に非常に複雑なオートコンプリートであるということです。そのため、質問に対してすぐに回答を始めます。ただ、質問に答え終えるまでに少し時間がかかるのです。そこでできることの一つは、ええと、結果をストリーミングすることです。実際にはユーザーは、回答を待つことに対してずっと寛容です。
すぐに出始めれば、これがchat GPTのやっていることです。ええと、彼らは待ちます、そうですね、最大で、そうですね、15秒、20秒、30秒まで待つでしょう。これは、誰かが回答を待つ時間としては前代未聞の長さです。回答が出始めていて、その回答が自分にとって関連性がありそうだと見えている場合には。はい。ええと、ではMikeからの質問です。ragベースのアプリを完成させたものの、期待したほど性能が出ていない場合、精度、レイテンシ、コストを改善するために、パイプラインのどの部分やツールを推奨しますか？うわあ、それもまた本当に素晴らしい質問ですね。
ええと、皆さん本当にこのウェビナーをよく聞いていますね。ええと、精度、レイテンシ、そしてコストは、三つのまったく異なる問題です。ええと、ええと、もし、もしコストが主な関心事であれば、ええと、その場合はおそらく、ええと、精度とレイテンシに関する期待値を下げる必要があるでしょう。ええと、コストを下げる方法の一つは、ホスト型モデルの代わりにローカルモデルを使うことです。非常に有能なローカルモデルはたくさんあります。特に自分のデータでファインチューニングすればなおさらです。
ええと、ローカルモデルは、セットアップ方法によっては、レイテンシも改善できます。というのも、ローカルモデルはかなり小さい傾向があり、そのため回答がずっと速いからです。ええと、精度とレイテンシ。ええと、レイテンシは難しい問題です。先ほど言ったように、ストリーミングはレイテンシに対して、ある種の煙と鏡のような見せかけの対応を与えることができます。
ええと、しかし、レイテンシに対するこれ以上の修正策はありません。問題に大量のハードウェアを投入すること以上には。ええと、精度は、ええと、最も複雑なものです。精度は、本当に、ええと、繊細な、ええと、クエリ戦略を使うことで得られるものです。つまり、ええと、非常に細かく調整されたプロンプト、ええと、データソースを複数の独立したデータソースとクエリに分割し、それをエージェントを使って独立に問い合わせるクエリエンジンです。ええと、そうしたことは精度を本当に向上させることができます。
ええと、また、精度、レイテンシ、コストを改善することもできます。ええと、いじることで、ええと、取得するコンテキストのサイズを、です。ええと、つまり、ええと、最初にデータを分割するとき、それをチャンクに変換する必要があります。ええと、そのチャンクは非常に大きくすることも、非常に小さくすることもできます。小さいほど、応答は速くなりますが、その中に含まれるコンテキストは少なくなります。したがって、このトレードオフを行う必要があります。ええと、どれだけのコンテキストが欲しいのか、そしてどれだけ速くそれを取得できるようにしたいのか、という間で。
ええと、私の回答から分かるように、これは精度、レイテンシ、コストのように、あちこちに話が飛んでいますが、それらは、ええと、調整して、自分のアプリケーションにとって最適なもの、最適な組み合わせを選ぶ必要がある、複雑な三つ組の、ええと、スライダーです。お役に立てば幸いです。はい、ありがとうLaurie。では別の質問です。Q&Aウィンドウ、ええと、匿名です。
このトークをありがとうございます、Lori。非常に有益な質問です。LAMA Indexはデータクリーンアップにどのような用途がありますか？私は取得したいのではなく、実際にはその逆を行いたいのです。LLMを使ってデータを挿入し、それから検索パイプラインを構築したいです。これに使えるツールはありますか？へえ。ええと、それは興味深い、それは興味深いユースケースですね。
ええと、そのユースケースには特に詳しくないので、残念ながら、それに答えるための特定のツールがあるとは言えません。ええと、ただデータクリーンアップに関しては、ええ、LAMA Hub に行けば、利用可能な事前処理がたくさんあります。ええ、それらは、そもそもデータを取り込むときに、それをクリーンアップするのに役立ちます。ええ、最も優れたものの1つは、PII 検出ツールです。これは、ええ、保護対象の個人情報を取り除くのに役立ちます。それが懸念事項であれば。ただ、より一般的な問いは、どうやってデータをきれいにするのか、ということです。これは実際には LLM の話ではありません。
データをきれいにすることは、ええ、昔ながらのデータサイエンスの ETL の問題です。ええ、ですから、ETL データをどうクリーンアップするかについての、これまでの、ええ、何十年分もの取り組みが適用されます。前処理をしなければならず、取り込みをしなければならず、ええ、事前集計をしなければならず、そして多くのフィルタリングをしなければなりません。それはすべて、LLM とはあまり関係のない、細かな実装作業の多いプログラミングですが、回答の品質を高めるためには非常に重要です。ありがとうございます。
PII ツールは本当に便利そうですね。では、Terry からの質問です。コンテキストウィンドウがどんどん大きくなる LMS がある世界で、RAG がどのように有用であり続けるのか、詳しく説明していただけますか？また、オープンソースとクローズドソースの LLM の使用について、意見を共有していただけますか？どちらももちろんです。良い質問ですね。ええと、講演の冒頭で触れようとしたように、ええ、私たちは皆、Gemini 1. 5 Pro について聞いたことがあります。ええ、これは 100万のコンテキストウィンドウを持つ予定です。
ええ、LA takes では当然、検索拡張生成にとってそれが何を意味するのかについて、多くの質問を受けています。ええ、答えは、それでもなお自分のデータをこの LLM に接続する方法が必要だということです。それがどこにあるのかを知る必要は依然としてあります。何が最も関連性の高いデータなのかも、やはり知る必要があります。先ほど言ったように、100万の、たとえ無限のコンテキストウィンドウがあったとしても、質問に答えるときに、100万トークン分のものを渡したいとは思わないでしょう。
非常に単純な質問に答えるために、100万トークン分のデータを投げ込む必要はありません。もし、ええ、つまり、100行のコンテキストだけで得られると分かっているなら。ですから、結局、コンテキストウィンドウがどれだけ大きいかは関係ありません。もし無限のコンテキストウィンドウがあり、100万行のコンテキストではなく100行のコンテキストで答えを得られるなら、そのコンテキストウィンドウがどれだけ大きくても、100行のコンテキストの方が常に速いのです。つまり、私たちは精度、精度とレイテンシ、速度について話していました。ええ、関連するコンテキストを与えるように管理できれば、レイテンシは良くなりますし、また、毎回データコーパス全体を与えるのではなく関連するコンテキストを与えるなら、コストも良くなります。
ええと、オープンソースとクローズドソースの LLM についてですが、そうですね、私は以前 NPM を運営していたので、オープンソースの大ファンです。ええ、オープンソースの lms は素晴らしい仕事をしていると思いますし、モデルへのアクセスが民主化されることは、ええ、本当に、本当に素晴らしい流れだと思います。素晴らしいです。ええと、チャットウィンドウに他にもいくつか質問が見えます。ええ、ESH が「RAG は Microsoft Excel データへのクエリをサポートしていますか？」と尋ねているのが見えます。ええ、サポートしています。
Excel データをクエリするためのアダプターがあります。わかりました。そして今、別の、あ、すみません、あなたが、すみません。とはいえ、答えは単純なディレクトリリーダーではなく Lama hub にあります。わかりました。
素晴らしい情報です。ええと、そして Q&A ウィンドウに戻ると、別の質問です。teary、AI エンジニアとしてこの分野で仕事を探している人には、どのような l lam プロジェクトをおすすめしますか？つまり、ええ、彼はポートフォリオプロジェクトのようなものを考えているのだと思います。はい。ええと、それは素晴らしい質問です。ええと、今最も注目されているのはエージェントです、ええ、失礼しました。
ええと、誰もが見たいのは、ええと、ツールの使用を実証でき、ええと、単に質問に答えるだけでなく実際にアクションを実行できるエージェントです。うーん、なので、もし私が、自分が何をしているのか分かっていることも示せるようなファネルLMプロジェクトを探しているなら、うーん、RAGとエージェントを組み合わせます。つまり、ええと、あなたのカレンダーを読んで、それから新しい予定を設定できるエージェントを想像してください。それはragを使っています。カレンダーを見る必要があり、いつ忙しくていつ空いているのかを、つまり、把握する必要があります。ええと、そしてカレンダーに新しいイベントを作成するようなアクションを実行する必要があります。
うーん、それは、つまり、そういう種類のプロジェクトは、LMアプリケーションでできることの全範囲を実証します。うーん、なので、ええと、そのような方向性のものは本当に良いプロジェクトです。でも、その質問をありがとうございます。素晴らしいです、ありがとうございます。さて、ではチャットウィンドウに戻ります。うーん、Tossinが質問しています。さまざまな種類のデータセットをVectorデータベースにロードするためのフレームワークを構築することは可能ですか？わかりました。
サンプルコードやアプローチはありますか？彼は異なるものという意味ですか？うーん、はい。わかりました。つまり、それがすべてですよね？はい。うーん、それがLAMA Indexのためのものです。ええと、Lama Hubには、うーん、あらゆる種類のデータソースからロードするためのコネクタが何百も何百もあります。
うーん、そして、ええと、もし多くの異なるデータソースがある場合、それらをすべて単一のvectorstoreにまとめたいのか、それともデータの種類ごとに1つのvectorstoreを維持したいのか、いくつか選択する必要があります。うーん、個人的には、ええと、それらを別々に保存する、別々のデータベクトルストアに保存するのは良い考えだと思います。ええと、なぜならそうすると、ええと、先ほど言ったようにtool useを使えるからです。sub-question query engineのようなものを使って、わかりました、この質問はこのデータソースで答えるのが最適そうだ、対して別の質問はこの別のデータソースで答えるのが最適だ、と判断できます。そしてそれらを分けたままにして、質問に別々に答えることができます。わかりました。
うーん、それでは数日中に録画を公開します。うーん、そしてq and aウィンドウに戻ります。ええと、Danielが質問しています。LAMA Indexが適切なソリューションではない可能性のあるユースケースは何ですか？うーん、LAMA Indexはragに非常にしっかりと焦点を当てており、ええと、ragを解決するためにエージェントを使用することに焦点を当てています。うーん、なので、それをしていない場合、ええと、それを行うためのツールは私たちの側では少なくなるでしょう。なので、うーん、説明するのは難しいですが、つまり、LAMA Indexを使ってPhotoshopを作ろうとしないでください、なぜならそれは私たちがやっていることではないからです。うーん、でも、ええと、あなたがやっていることがretrieve augmented generationであるなら、私たちはそのユースケースに非常にしっかりと焦点を当てています。
了解です。うーん、それでは今チャットウィンドウに戻ります。うーん、Stefanが質問しています。生成されたPythonサーバーはどのライブラリに基づいていますか、Flask Fast？API、うーん、生成された、ええと、おそらく、Create Lamaによって生成されるAPIのことを意味していると思いますが、ええと、それはFlask apiです。それはFlaskアプリケーションです。わかりました。
q and aウィンドウに戻ります。ええと、anonymousが質問しています。PG Vector storeを使うことについてますます耳にしますが、実際にpgにどのデータ型を入れて、ええと、それを使うのでしょうか？もしかすると読み間違えたかもしれません。うーん、Vector storeとして使うために、実際にどの種類のデータ型をPGに入れるのでしょうか？ああ、彼はPostgres sqlのことを話しているんですね。うーん、でもPG Vectors Time series Vectorがあり、待って、TS Vectorは基本的なもののようです。TS Vectorはよく分かりません、私もよく分かりません。うーん、わかりました。
その質問を言い換えてもう一度試してみてください。はい、はい。Anonymousさん、質問を言い換えていただけますか。こちらで答えられるようにします。ありがとうございます。うーん、わかりました。
こちらが、彼が入力しようとしているのだと思います。いいえ。わかりました。これは閉じます。うーん、わかりました。
Code Similarity search、ああ、code completionをサポートする予定はありますか？うーん、はい、というより、すでに対応しています。ええと、使えます。ええと、code searchが非常に得意なモデルがあり、ええと、私たちはそれらのLLMに接続していますので、それらすべてと、code embeddingが非常に得意なembedding modelを使えます。ええと、なので今日それを行うことができます。素晴らしいです。そして、うーん、Rajeshが質問しています。私たちは企業向けのGenaiプラットフォーム構築に取り組んでいます。on Indexと提携することは可能ですか？もちろんです。
弊社ウェブサイトのお問い合わせフォームにアクセスしてください。喜んで提携させていただきます。わかりました。ええと、そうですね、これで締めくくりということになりそうですね。ええと、最後に何かアドバイスはありますか？そうですね、私たちは、というか少なくとも私は、もっと詳しくどこで知ることができるのか知りたいです。どこから始めればよいですか？ええと、そのためのリンクはいくつかもらえますか？ええ、はい、私のスライドにも載っていますが、Dots lama index にアクセスしていただければ。
ai、そこは始めるのにとても良い場所です。わかりました。わかりました。もう1つ質問がQ&Aウィンドウに匿名で来ています。わかりました。
彼は、彼は、彼は質問を書き直しました。ええと、LAMA Index で取得できる Vector store として Postgre を使用していますか？既存のテキストデータを embeddingmodel を使って埋め込み、それをベクターデータ型として保存するだけですか？はい、まさにその通りです。わかりました、完璧です。はい。皆さんの質問にはすべて回答できたと思いますし、ええと、たくさんの情報を共有していただきました。
llama index がどれほど多くのことを行うのか、特にインメモリの、ええと、vector store の部分は本当にすごいですね。Lori、ありがとうございました。私もたくさん学びました。ありがとう、Christie。わかりました、次もよろしくお願いします。
また次回お会いしましょう。また次回お会いしましょう、RAG の皆さん。さようなら。皆さん、さようなら。
Meet the Speaker
Join the session for live Q&A with the speaker
Laurie Voss
VP Developer Relations at LlamaIndex
Laurie has been a web developer for 27 years, and along the way he co-founded npm, Inc.. He cares passionately about making technology accessible to everyone by demystifying complex technology topics.