Events
オープンソースのMilvusを使用してRAGアプリを構築するための初心者向けガイド

トレーニング

オープンソースのMilvusを使用してRAGアプリを構築するための初心者向けガイド

Zilliz ウェビナー | Zoom

Join the Webinar

何を学べますか？

Milvusを使用してRAGを構築する方法をご紹介する技術ウェビナーにぜひご参加ください。検索拡張生成（RAG）は、外部ソースから取得した事実によって生成AIモデルの正確性と信頼性を高めるための手法です。

このセッションは、RAGとベクトルデータベースについてさらに学びたい開発者向けに設計されています。ライブデモを通じて、既存のソースから外部知識を取り込めるRAGアプリケーションを効果的に構築する方法をお見せします。

取り上げるトピック

RAG入門：RAGとは何か？いつ必要になり、どのように構築するのか？
RAG技術スタックとは：RAGはさまざまなコンポーネントを使用します。それらについて説明します。
RAGアプリをライブで構築：Milvusを使用してRAGアプリを構築する方法をご覧いただきます。

このインタラクティブなセッションでは、非構造化データを使用してRAGを効率的に構築・活用するための知識を身につけることができます。

View presentation slides

Transcript

本日は、オープンソースのmelvicを使用してRag Appを構築するための初心者向けガイドというセッションと、本日のゲストスピーカーであるStephen Batifolをご紹介できることを嬉しく思います。StephenはここZillizのデベロッパーアドボケイトです。ええと、こうしたウェビナーで同僚と一緒に仕事ができるのは嬉しいですね。彼は以前、Volで機械学習エンジニアとしてMLプラットフォームに携わっていました。また、Bravoではデータサイエンティストとして働いていました。Stefanはコンピューターサイエンスと人工知能を学び、仕事の合間にはダンスとサーフィンを楽しんでいます。

ようこそStephen。ご紹介ありがとうございます。では、そうですね、本日はvisを使ってRAGアプリケーションを構築するための初心者向けガイドについてお話しします。先ほど言ったように、私はスタッフですが、zillsではリベラルです。ええと、よろしければ、ここで私のすべてのSNSを見つけることができます。

visやragに関連するご質問があれば、LinkedInで直接、メールで直接、またはTwitterでもお気軽にご連絡ください。では、始めましょう。ragについてですが、ここにいらっしゃるのは、それが何かを知りたいからでもあると思います。RAGはretrieval augmented generation、つまり検索拡張生成を意味し、本日はそれについてお話しします。RAGの基本的な考え方は、LLMに自分のデータを扱わせたいということです。そして通常は、ベクトルデータベースに入れて注入します。たとえば、LLMがあり、open AIを使ってGPTを使ったことがあるなら、常にカットオフ日があることを見たことがあるかもしれません。

ええと、その後に何が起こったかをLLMは知りません。また、プライベートデータを使う場合、ええと、LLMはあなたのメールやそのようなさまざまなものにアクセスできません。そのため、通常はragを使います。その仕組みは、アクティブデータベースがデータを直接注入する能力を提供し、意味的類似性がある場合、ええと、それが仕組みであり、だからこそragには常にVector databaseを使用するのです。次に、考慮すべきことがいくつかあります。RAGとvector databaseを使う場合、ええと、スケール、パフォーマンス、柔軟性です。もちろん、数百万のベクトルやさまざまなものがあるのにスケールしないものを使いたくないなら、vector databaseを使いたくありません。

ですので、自分のサイトではそれを考慮してください。そして問題は、LLMは確率的なので、常に次のトークンを予測するということです。ええと、それは、まあ、いいことでもありますが、同時に、同じ質問でも時々異なる回答が出る理由でもあります。ですので、これは起こり得る問題ですし、欠点としても、先ほど述べたように、更新された入力データを持っていない可能性があり、それが幻覚を引き起こす可能性があります。ええと、幻覚が何かわからない方のために言うと、それは本当のように聞こえるけれど、事実としては正しくないものです。

たとえば、誰かがどこで生まれたのかをLに尋ねると、その人が実際にはシカゴで生まれたのに、この人はニューヨークで生まれたと非常に自信を持って答えるかもしれません。たとえばそういうことです。これが問題です。そしてこれは基本的なdrugアーキテクチャと言えるでしょう。常にデータがあります。ええと、そこから始めます。次に、データからコンテンツを抽出します。

つまり、PDFがある場合は、そのコンテンツを抽出しようとします。動画がある場合や、さまざまなものがある場合も同じです。次にデータをチャンク化します。それを埋め込みモデルに入れます。これらについては後ほど、別のスライドで説明します。ですので、それが何かわからなくても心配ありません。その後、すべてをvisに保存します。クエリを行うときには、ええと、クエリも埋め込みモデルを通す必要があります。

そして、セマンティック検索を実行します。すると、あなたのLLMは、ええと、似たようなデータについて把握し、それからすべてをコンテキストに入れて、結果を出します。これが基本的なRAGアーキテクチャです。ええ、チャンク化と埋め込みは、とてもとても重要だとわかるでしょう。では、このテックスタックは、ええと、今回は、LangChainです。

それから、Hugging Faceから直接の埋め込みモデルを使っています。ええと、Sentence Reformer with Formerから、ベクトルデータベースにはVISを使っていて、すべてをローカルで実行します。ええと、つまりLAMA 3を自分のノートPC上で直接実行します。それから、そうですね、このRAGアプリについて、言い忘れたこととしては、すべてがローカルで動き、すべて無料だということです。ええと、OpenAIやその他のモデルは使いません。LangChainとは何かというと、LLMアプリケーションを構築するためのフレームワークです。

そして主に、データの取得とLLMとの統合に重点を置いていると言えるでしょう。つまり、何らかのデータを読み込む必要がある場合に非常に便利です。たとえば、PDFを読み込みたいとします。ええと、そのPDFはローカルにあるかもしれませんし、自分のコンピューター上にあるかもしれませんし、あるいはインターネット上にあるかもしれません。そうしたPDFがどこにあっても取得しやすくしてくれます。また、データをチャンク化したり、チャンクのオーバーラップに関するさまざまな設定を持たせたりするのも簡単にしてくれます。

それが何を意味するのかは後で見ます。つまり、これらはとても便利です。それから、考えられる最も人気のあるツールとの統合もあります。ええと、そのため、別の会社の埋め込みモデルを使う必要がある場合にも、とても扱いやすくしてくれます。ええと、その場合たいていは、インポートファイルを変更するだけで済みます。

それがLangChainです。次にOllamaがあります。ええと、もし使ったことがなければ、これはLLMをローカルで実行できるようにするものです。そして非常に便利です。ただし、量子化されたLLMしか実行できません。

ええと、ですがLAMA 3の最小バージョンなら、私のノートPCで実行できます。実行には約4GB必要です。ええと、そうすることで、たとえば飛行機の中やどこかにいるときでも使えるかもしれません。また最近では、埋め込みモデルを実行することもできるようになっています。なので、これは非常に興味深いものかもしれません。

そうですね、もしよければOllamaを使えば、LAMA 3を実行できますし、別のモデルも実行できます。ええと、利用可能なモデルがたくさんあります。これはベクトルデータベースで、クラウドネイティブであり、分散システムアーキテクチャで、関心の真の分離があります。また、スケーラブルなインデックス化戦略も備えています。さまざまなセグメントの詳細には立ち入りませんが、これはスケーラビリティのために作られています。そして、ええと、一般的な埋め込みモデルがあります。

先ほど言ったように、ええと、今回私はHugging Faceから直接利用できるものを使っています。ええと、ただしニーズによっては、別のモデルを使いたい場合もあるでしょう。たとえば、異なる言語のドキュメントを扱う場合です。ええと、たとえば、私はドイツに住んでいるので、ええと、ほとんどのドキュメントはドイツ語です、その点はすみません。そうなると、ドイツ語に特化した埋め込みモデルを使いたいと思うかもしれません。動画を使いたい場合も同じで、動画で学習された埋め込みモデルを使いたいかもしれません。

そして、そうですね、高いレベルの現時点で、何かを始めて別の埋め込みモデルを調べるとき、たいていHugging Faceには小さなランキングがあります。ええと、さらに、さまざまなユースケース向けのさまざまな埋め込みモデルのリストのようなものもあります。なので、常にOpenAIの埋め込みモデルを選ぶ必要はありません。ええと、一般的な用途には非常に優れていますが、専門的な用途では少し難しい場合があるからです。そうですね、本当にたくさんの種類があります。

ええと、そうですね、埋め込みについてもう少し詳しく見ていきましょう。まず最初に、すでに述べたことですが、埋め込みを使うときはモデルを選ぶ必要があります。そして繰り返しになりますが、私が言ったように、自分が持っているデータで学習された埋め込みモデルを選ぶことが非常に重要です。つまり、動画で学習されていないものを使うと、うまく機能しないかもしれません。日本語のテキストを使うつもりなのに、それが英語のみで学習されている場合、ええと、うまくいかない可能性が非常に高いです。

次に、何を埋め込むかを選ぶ必要があります。ええと、それからメタデータがあり、ええと、それについても後ほど少し触れます。そうですね、さまざまな埋め込み戦略があります。レベル1があります。これはチャンクを直接埋め込むようなものです。つまりデータがあり、そのデータをより小さなチャンクに分割します。

ええと、そしてチャンクをそのまま埋め込み、それからすべてをベクターデータベースに入れたいと思うかもしれません。その後、類似性検索を行うことができます。それは機能しますし、データによっては非常にうまく機能することがあります。ええと、しかし次のレベルもあります。それがレベル2で、サブチャンクやスーパーチャンクも埋め込むようなもので、通常はデータやLLMが何が起きているのかを理解するための、より多くの文脈を提供できます。さらに別のレベルとして、チャンク化メタデータと非チャンク化メタデータを組み込む、すみません、というものがあります。

つまり、たとえば、著者などすべてに関するメタデータを持つことができ、それはデータを理解できるようにするうえで非常に重要になることがあります。そして、チャンク化メタデータのさまざまな例としては、段落の位置、セクションヘッダー、もしそれが大きめの段落であれば、それもチャンク化したいかもしれませんし、文番号などがあります。これらは非常に役立つことがあります。そして非チャンク化のものは、たとえば、誰が書いたのか、出版社、組織、そういったさまざまなものになります。そして通常、これらは実際にragアプリにとって非常に有用な情報を提供します。

そして、ではそれはどのように見えるのか、と思っているかもしれません。つまり、データを埋め込みモデルに通すと何が起こるのか、ということです。ここではテキストの例があり、ええと、それを埋め込みモデルに通すと、ええと、最終的にこのようにベクトルが得られます。それは埋め込みモデルを通った後でのみ起こります。そして、そうです、ベクトルがあり、それを使ってこれから行うのです。ベクトルに対して類似性検索を実行します。

ええと、そしてそれが通信の仕組みです。それがベクターデータベースの行うことです。それが私たちがすべてを理解する方法です。ということで、この部分の要点としては、埋め込み戦略は、求める精度、コスト、必要なユースケースに本当に依存するということです。ええと、これらは、実際のところ、これ一つで全部に合う、というような解決策はありません。

そうですね、さまざまな埋め込みモデルを見てみてください。ええと、それはあなたにとって非常に役立つかもしれません。次にチャンク化です。先ほど言ったように、さまざまなことを考慮する必要があります。チャンクサイズ、ええと、チャンクをどれくらいの長さにしたいのか？つまり、1文字にしたいのか、それとも1000文字にしたいのか？ええと、それは状況によります。チャンクオーバーラップのようなものもあります。

つまり、2つのチャンク間の重なりです。ええと、ときにはそれが役立つことがあります。新しいチャンク同士の間で何が起きているのかを理解できるようにするためです。ええと、それから文字分割器もあります。カンマなどがある場合や、ダッシュがある場合には、たとえばダッシュで分割するのは非常に興味深いかもしれません。ええと、データがどのようなものかによります。

例として、ここで見ていただけますが、ええと、私たちが持っているデータ、そして実際に後ほどデモで使うデータなのですが、ここではチャンクサイズが50で、オーバーラップがゼロです。見てわかるように、私は自分でテキストをここに追加しただけなのですが、データはあまり、本当に何が起きているのか理解できません。つまり、実際には何も重要ではないという感じです。ここでは、たとえば6月30日みたいなものもなく、ええと、本当に重要なものが何もありません。なので、あなたのLLMも、物事を把握するのにかなり苦労します。別の例としては、チャンクサイズ128でオーバーラップ20の場合です。

ここでは、何が起きているのか、何が行われているのかを理解し始められるのがわかります。ええと、そしてオーバーラップも見えます。ええと、たとえば最初のチャンクでは、四半期期間についてのところで終わっていて、それが、ええと、6月30日、云々、となっています。そしてそれがここにあります。2番目のチャンクも同じです。

それはそこから始まっています。つまりそれがオーバーラップです。ええと、そしてはい、ここでは、まあ、これはより興味深くなり始めている、というのが見えますが、もちろんもっと大きくすることもできます。ええと、チャンクサイズ256、オーバーラップ50で、これは私たちにとってかなり、ずっと興味深いものになり始めます。いつでもさらに大きくできます。なので通常、人々から「特定の使っている数値はありますか？」と聞かれるのですが、残念ながら今のところそういうものはありません。ええと、特定の数値はありません。

それは本当にあなたのデータ次第です。何をチャンク化したいかに本当に依存します。私が時々使っているものに、ええと、セマンティックチャンクャーがあります。ええと、それらはlink chainとmain indexで利用可能で、あなたにとって非常に役立つことがあります。それらは、ええと、あなたの文の意味を把握しようとして、すべてをまとめようとします。

ええと、意味のあるものすべて、似ているものすべてを、1つのチャンクにしようとします。問題は、セマンティックジャンカーを使いたい場合、埋め込みモデルを使う必要があるということです。一方、前のものは非常に単純な方法です。つまり、単に文字を読んで、それから分割するだけです。

なので、はい、通常はより良い結果を得るにはこちらのほうが良いと私は感じていますが、そのためには埋め込みモデルを使わなければなりません。また、非常に重要なのは、あなたのデータがどのような見た目かということです。それは主に会話データなのか、それともドキュメントデータ、講義、またはQ&Aデータなのか。もしドキュメントデータなら、すでにいくつかのチャンクがあるかもしれません。たとえば、段落を持つことができて、それから、いわばスーパーチャンクのようなものを持ちたいかもしれません。タイトルや見出しについての情報を追加したいのです。それらは、ええと、あなたのデータとチャンクにとって非常に役立つかもしれません。ええと、講義やQ&Aについても同じです。

もしQ&Aデータなら、文の冒頭に、questionのようなものがあって、その後に実際の質問があるかもしれません。回答についても同じです。ですから、その場合は、おそらく質問と回答のように分割されたチャンクにするのが良い考えでしょう。たとえば、毎回256文字ごとに区切る必要はありません。なので、はい、残念ながら、素晴らしい数値のようなものはありません。

つまり、戦略はあなたのデータがどのようなものか、そしてそこから何が必要かに依存するだけです。では、これからもう少しデモに入ります。ここまでがスライドで、後で利用可能になるので心配しないでください。ええと、ではここで少しデモに入ります。そして先ほど言ったように、ええと、すべてローカルで実行します。なので、私のPython環境があります。ええと、ここにあり、私はvisのdocker composeバージョンを使っています。

では、起動してみます。実はすでに実行中のはずです。ええと、はい、それから起動して、visのさまざまなコンポーネントを起動し、これで問題ないはずです。見ると、すべてここにあり、すべて実行中で、すべて正常です。なので、これで満足です。

ノートブックも準備できています。なので、そこでコードを実行します。ええと、お見せすると、これが doca compost ファイルです。ええと、VIS のドキュメント上で直接見つけられるので、当然自分で作る必要はありません。ええ、これがコードです。

ええと、最初の部分は、必要なものをすべてインポートするところです。先ほど言ったように、私は lung chain を使っているので、lung chains のさまざまなコンポーネントを使えます。最初の部分は、ええと、PDF order ですが、後でさらに詳しく説明します。ええと、嘘をつかないようにするために。実際には、ここにこのコード片があり、すでに存在している場合は接続を実際に削除します。なので、全部実行してみます。

ええと、コレクションは削除されました。ええと、その後、実際にそれを再作成する必要があり、それをデモ中に行います。なので、ここのこの部分は、ええと、実際に PDF をロードするところです。前に言ったように、ええと、long chain を使うと、ローカルまたはインターネット上にある PDF をロードするのがとても簡単になります。そして、その PDF がどんなものかお見せします。ええと、これは、ええと、WeWork に関する PDF です。

ええ、これは、非常に長い PDF で、169 ページあります。多くの財務情報や、さまざまなものがたくさんあることがわかります。そしてこれが、ええと、デモで使う PDF です。なので、「この PDF を取得してください」と言います。ええと、それからロードします。

つまり、loader を使い、それから実際に PDF からデータをロードします。これで、インターネット上のこの PDF にアクセスし、どこかにダウンロードして、それからメモリにロードします。ええと、先ほど言ったように、ええと、私は hugging face の embeddings も使っています。なので、それらは Samsung performers のようなものです。別のモデルを自由に使ってかまいません。

これらは、彼がデモ用に使うことに決めたものです。一般的なテキストにはかなり優れています。ええ、サイズもそれほど大きくありません。なので、これは、これは、これは、とても良い embedding モデルだと言えるでしょう。これを後で使って、先ほど見た PDF であるデータをベクトルに変換します。

それから、ほら、私はいつも chunk size と chunk overlap について話していました。なので、ここでまさにそれをやっています。これは、ええと、これからやることです、ええと、stupid chunk です。つまり、512 文字ごとに、ええと、512 文字ごとに新しい chunk になります。すみません。

ええと、それについて賢いことは何もありません。ええと、そういうものになります。ええと、そして「これを、ええと、ドキュメント全体に対して実行してください」と言っています。なので、それがやっていることです。

ドキュメントを複数のドキュメントに分割し、それからすべての splits が得られます。もしお見せすると、ええと、splits をお見せできます。こんな感じで、異なるドキュメントが作られたことがわかります。ええと、そしてドキュメントは基本的にページです。ええと、それから「これは content で、blah, blah, blah」といった感じになります。「ページは page zero です」と言っています。

いくつかの metadata も追加されています。これは非常に、あなたにとって非常に役立つことがあります。この場合は、インターネット上の PDF であるだけなので、それほど役立ちません。なので UL だけですが、必要であれば別の metadata を追加することもできます。そして、ええ、また、それがどのページなのか、ええと、すべてを教えてくれます。なので、これらが、ええと、splits です。

これらを削除します。そしてここが、すべての splits、先ほどお見せした split を置く場所です。ここでそれらを変換し、ここですべてを vis に保存します。なので、すべての splits、つまりすべての、どの model documents も、2 つの chunks に分割されています。embedding model があり、ここで定義しています。つまり、また、すみません、また hugging face embedding model です。そして「collection を作成してください」と言っています。

ええと、「collection を使ってください」。それが rag vis webinar です。そしてそれが collection の名前です。そして、それが先ほど削除したものです。なので、それを実行します。少しだけ時間がかかります。

なぜなら、すべてを変換しなければならないからです。つまり、データは今、ええと、データを embedding model に通すと、それがベクトルを生成します。そしてそれらを、ええと、私たちの、ええと、vector database に保存します。ここでは metaverse です、ええと、retriever を定義しています。つまりそれが、前に共有したことです。ええと、スライド上でクエリを入力して、ええと、それから、セマンティック検索を行う必要があります。なので、ええと、それがこれのすることです。

つまり、クエリ用のデータを、ええと、あー、embedding model に直接送信し、それがその後 vector database とやり取りします。これが retriever 用に用意しているものです。ここでの prompt は、ええと、通常 rag で使う典型的な prompt です。つまり、だいたい「あなたはアシスタントです。答えがわからない場合は、答えがわからないと言ってください」、ええと、そうすれば ate しないように、というものです。ええ、ここにあるのはそういうものです。今、vis を、ええと、retriever として定義しました。

ええと、LLM を定義します。ええと、これは Alama から来ているもので、LAMA three です。ええと、ここにあるのがそれです。これは単なる詳細ですが、LAMA three には、それが停止した、彼が終わった、ということを示す特定の token が、ええと、あります。なので、その token を見るたびに止めてください、と言っているだけです。そうしないと、通常 lambath は自分自身に話し続けてしまい、ええと、それは面白いのですが、ここであなたが rag に望むものではありません。これはただ、ええと、私の document をフォーマットするためです。

私の document をフォーマットするためです。つまり、見た目がかなりよくなるように。そしてここが right chain です。ここに基本的にすべての魔法があります。つまり、こう言います。オーケー、context として、ええと、これが私の retriever です。

question は、後であなたに尋ねる question です。ここに表示されているものです。ええと、つまりそれを渡すだけで、それを rag に渡すと、あとはそれが魔法をかけてくれます。そして、はい、prompt は、ええと、ここで pull するものです。つまり「あなたは AI assistant です、blah, blah, blah」と言って、それを LLM に渡し、それから output が得られます。つまりそれが rack chain を定義するということです。

ええと、それで document があります、つまり、すでに question があります。準備できていますか？それは、WeWork とは何か？です。ええと、document が WeWork についてのものだからです。そしてその後、直接、ええと、それが何を言っているのかを見ることができます。その部分は少し遅いです。なぜなら、まず私はすべてをローカルで実行しているからです。ええと、それから、ほら、context を LLM に渡すと、LLM がすべてを見つける必要があります。そして、はい、ここでは、ええと、WeWork などについて教えてくれます。そしてまた、たとえば、こうすることもできます。オーケー、でも LAMA three は WeWork について知っているかもしれない。

なので、この document に関連するものではまったくない可能性もありますが、その場合は直接質問できます。ええと、この document は何についてですか？そして通常は、document は what we serve についてです、みたいに教えてくれるはずで、はい、その通りです。つまり Moses はそれが financial report だと言っています。ええと、それから、はい、company による quarterly report だと言っています。ええと、それで、それだけです。その後、LLM にさまざまな質問をすることができます。ええと、それが、あなたが持つ basic rag application です。

そしてその basic なもの、ええと、すべてがローカルで動作するものです。何にもお金を払う必要はありません。実際、すべて open source でもあります。なので、何かデータがあって、自分の rack system を構築したいなら、将来使いたければ使えるものです。ええと、あとかなりクールなこととして、ええと、long chains では、回答に sources を追加できるようになっています。

つまり、「はい、お願いします。回答の出典を、ええと、回答のソースとして追加してください」といった感じにできます。そうすることで、少し役に立ちます。幻覚をチェックして、それが実際に、つまり、何かをでっち上げていないことを確認できます。ええと、そしてここでは、「はい、コンテキスト、これが私たちが与えたコンテキストです」といった感じにできます。すべてそうです。そして「ソース」として、ソースが以前に持っていたドキュメントそのものであることが確認できます。そして、「はい、これは12ページです、ええと、これは69ページです、ページ6、70です」といった感じにできます。ええと、そうですね、これは通常、私がとても興味深いと思うものです。

ええと、ソースを追加すること、ええ、特にあなたのプライベート文書については、そうすることで、LLMが何かをでっち上げていないことを常に確認できます。そして、基本的なRAGアプリケーションとしてはだいたいそれくらいです。では、ええと、質問を受け付けます。質問は見ていませんが、ええ。Wayne、何か質問はありますか？ええと、デモありがとうございます。

ええと、これは聴衆からの質問です。もし私がOpenAIでベクトルを埋め込み、その後、Hugging Faceのような別のモデルでクエリを埋め込んだ場合、レスポンスは依然として意味的に類似したものになりますか？要するに、異なる埋め込みモデルを使っても、結果間の距離を意味のある形で取得できますか？ええと、できます、異なる埋め込みモデルを使うことはできますが、その場合、それはまた、何を、何をしようとしているのか、その背後にある意図が何かによります。つまり、もし特定の埋め込みモデルを、ええと、質問に対して使うなら、ええと、それをデータにも使わない別の理由があるのか、ということです。可能ではありますが、結果はかなり異なるかもしれません。あまり良くないかもしれません。ええと、ええと、追加の補足説明がありました。レガシーデータの場合です。何ですか？すみません？OpenAIで埋め込まれたレガシーデータの場合です。ああ、レガシーデータですね。はい。

はい、つまり、できるとは思いますが、その場合、基本的に結果の品質については保証できません。はい。ええと、では、あ、しまった。はい。ええと、その質問に十分に答えられていなかった場合、追加のコメントがいくつかあるのが見えています。

ええと、気軽に、ええと、再度送信してください。ええと、別の質問に移ります。ノートブックでAlamaを使用する場合、モデルのQuantisバージョンを読み込んでいるのですか、それともDocker ComposeがすでにAlamaを実行していて、ノートブックがそれに接続しているのですか？いいえ、私のラップトップ上で量子化されたバージョンを実行していて、その後Alamaがサーバーを起動し、ノートブックがそのサーバーに直接接続します。つまり、基本的に今、私のラップトップ上でローカルのAlama Alamaサーバーが動いていて、すべてがコンタクトです。はい。

ええと、コードを入手することは可能ですか、というリクエストがありました。はい、実際に私のGitHubにあります。ええと、ll shadowのリンクを、この後すぐに共有します。もうアップされています。完璧です。録画を送る際のフォローアップメールにも含めます。ええと、別の質問があります。埋め込みモデルが使用される場合、より賢いチャンク化の方法はありますか？埋め込みモデルが使用される場合は必要ないとおっしゃっていたと思いました。はい、ここにはセマンティック検索、ええと、セマンティックチャンク化、すみません、があります。ここに示されているもので、これは、ええと、埋め込みモデルを使用する必要があります。

なぜなら、文の意味を把握する必要があるからです。ですので、はい、これには埋め込みモデルが必要で、通常その方法でチャンク化するほうが賢いです。もう一つのこちらは、ええと、愚直なチャンク化で、これは、つまり、すべてを各文字ごとに分割するだけです。ええと、「ありがとうございます」とあります。セマンティックチャンク化の例はありますか？はい。

ここには直接ありませんが、ええと、別のデータベース上のどこかにはあります、はい。わかりました。ええと、それから、フォローアップでさらに送ることもできます。ええと、では質問です。ええと、通常どのようにモデルを評価していますか？私の場合は状況によります。

私は、自分が真実だと知っている答えがあるのが好きです。なので普段は、私は、私はこう、ええ、自分のモデルに話しかけて、こんなふうに、質問をします。とても具体的な質問で、それが真実だと知っているもの、ええと、そして答えを確認します。それから、異なる評価モデルのようなものがあり、モデルを動かすさまざまな方法があります。でも、ええ、それが普段私のやり方です。ええと、通常は10、20くらい。そしてそれが真実だと知っているように、例えば、私はベルリン議会のデータを扱っていて、ええと、彼らはまだファックス機を使っています。

ええと、そして私は正確な数、ファックスの専門サービスを使わなければならないサービスの正確な数が189だと知っています。なので、使う埋め込みモデルによって、LLMによって、同じ答えにはなりませんが、本当の答えは189だと知っているので、それを確認します。LLMを使ってテキストから意味概念をベクトル表現として抽出する方法はありますか？質問を繰り返していただけますか？はい。LLMを使ってテキストから意味概念をベクトル表現として抽出する方法はありますか？あると思います、ええ、それは、うーん、それは、それは埋め込みモデルに通したときに起こることです。つまり、テキストがあって、それから埋め込みモデルがあり、そこでそれが何か、こう、何かを作ってくれて、物事を理解しようとして、そしてええ、データに意味を持たせようとします。そしてベクトルがあります。ええと、もう一つあります。

この問題はどう解決しますか？例えばPDFの中で、関連する情報があるけれど、複数のページにわたって展開されている場合です。では、クエリ結果を取得する際に完全な情報を得るにはどうすればよいですか？どのチャンクサイズとオーバーラップを使うべきですか？ええ、いい質問です。それは、チャンクのさまざまなオーバーラップでいろいろ試す必要があるときのようなものです。うーん、そしてそれは、例えば、あるいはメタデータをチャンク化するかもしれませんね、つまり、うーん、あなたの、あなたは例えば512文字のような小さなチャンク化を持つことになりますが、それから同時に、文書についてのさまざまなメタデータを埋め込みたいかもしれませんし、あるいはスーパーチャンクも埋め込むことができます。つまり文書の小さな部分と、それからいくつかのスーパーチャンクを持つ、ということです。ええと、私が普段好きなのはセマンティック・チャンカーです。なぜなら、それらはそれを見分けられるかもしれないからです。

しかしそれはまた、つまり、データを異なるページに分割するとき、うーん、それらが、わかりますよね、別々のページにあると理解するようにしなければならないということでもあります。そして、おそらくそれらの異なるページを取り除こうとする、つまり、テキストを一つの部分として持つようにする、うーん、またはそういうことです。でも残念ながら、かなり試行錯誤で、今のところ本当に魔法のようなものはありません。なので、ええと、これは私自身の質問なのですが、うーん、チャンク化、チャンクサイズ、オーバーラップを指定できるので。はい。先ほどLLMをテストする話をしていたような、そういう似たようなことをしますか？つまり、特定の答えがあることを知っている、あるいは、見えるはずのものを期待しているという同じ前提を使って、それによってチャンクとオーバーラップサイズを確認する、という感じでしょうか？それとも、正しく分割できたことを確認するもっと良い方法がありますか？ええ、通常は私もそうしています。

つまり私は、実際にいくつか質問をします。うーん、例えば1ページの終わりに対してですね。そして次のページに続きます。ええと、それから確認して、こんな感じで、ねえ、ええと、自分でそれを把握できましたか？あるいは、つまり、本当にそれを把握できますか？ええと、そしてええ、通常はアプリのチェックを使うと、うーん、続けられるので役立つことがあります。でも、ええ、たいていは多くの試行錯誤です。うーん、ローカルでllamaをどうやって実行していますか？サイズは小さいですか？たぶん小さめです。ええと、LAMA 3の最小の、ええと、バージョンでは4ギガバイトです。はい。なので、うーん、多くのノートパソコンで、実行できます。

RAGを備えたLLMモデルは、法律関連の質問をレビューして回答するのにどの程度役立ちますか？どの質問ですか？すみません。法律関連ですね。ああ、ええ、良い質問です。とても有用になり得ると思いますが、一方で、つまり、通常のデータと同じようなものでもあります。まったくハルシネーションしないようにする必要があります。

良い点としては、たとえば、常にソースがあることを確認すること、ええと、つまり、それらを本当に再確認することです。ええと、自分が持っているソースで、たとえば回答があり、そのソースを確認して、「よし、これは実際に存在するのか？本当に、これは本当に事実なのか？」というように確認することです。そういうのはたいていうまく機能します。そして法律で良いところは、非常に特定の形式があるということです。法律は文書の形式に非常に厳格です。ええと、なので通常は、チャンク化が実際に良いものになるかもしれませんし、他のどんな文書よりもずっと良いかもしれません。なぜなら、文書をその論理に沿って分割できるからです。文書内で意味を成し、論理があります。ええと、そういった点は非常に役立つ可能性があります。

ただ、そうですね、ソースを用意し、LLMが回答を出すときにそのソースを確認することだと思います。そして同じことが当てはまると思いますが、モデルを見つける際には確認したいでしょうし、選ぶものについて具体的でありたいでしょう。つまり、法律に関して学習された埋め込みモデルを使っている、というような点を考慮し、要素について慎重になるということです。まさにその通りです。まさにそうです。そして、たとえばその種のデータで訓練された多くの役割があるなら、そのほうがはるかに良いです。

それから、そうですね、自分の言語に合ったものが必要な種類のものでもあります。英語なら、英語の法律データで訓練されたものを見つける、そして他の言語についても同様です。ええと、トークンベースのチャンク化は、文字ごとのチャンク化と比べていつ使う必要がありますか？正直なところ、それは状況によります。残念ながら、それに対する本当の正解があるとは思いません。なのでチャンク化は状況によります。ええと、私は通常トークンベースにはしません。

ええと、単に個人的な好みです。パフォーマンスの向上は特に見つけられませんでした。ええ、なので本当にあなたの側次第です。埋め込みモデルの切り替えに関する質問を明確にすると、古いレガシーデータがまだモデルに意味的に類似した応答を返せるかどうかは分からない、と言っているのですか？いいえ、新しく選んだモデルで古いレガシーデータをすべてテストするか、再読み込みする必要があるということです。いいえ、それは、ええと、まず、注意が必要です。最初のモデルはすべてのデータをベクトル化し、それは特定の次元になります。

そして、もう一方のデータは、異なる次元かもしれません。なので、ここで問題にぶつかる可能性があります。ええと、それを解決したとしても、非常に馬鹿げた例を挙げますが、もし古い埋め込みモデルが中国語で訓練されていて、そしてもう一方が英語で訓練されているなら、技術的にはどちらも多少ベクトル化されていますが、意味は非常に異なります。なぜなら異なる埋め込みモデルを使っているからです。なので、それらが一緒に機能できるかどうかには注意する必要があります。言いたいことは分かりますよね。つまり、そうです、異なる埋め込みモデルがあるということです。

ええ、なので、それらが同じデータ、あるいは異なるものでも同じようなデータで訓練されていることを確認し、さらに異なる次元に対処する必要があります。マルチモーダルRAG、またはマルチモーダルRAGアプリケーションのアプローチは似ていますか？はい、はい。非常に似ています。ええ、同じです。ただしチェーンが少し複雑になるだけです。ええと、しかしそれ以外ではマルチモーダルも同じです。

ええと、それは、異なる埋め込み、ええと、異なるモデルがあって、うーん、そして何を持っているかに応じて、そうしたら、オーケー、これが自分のチェーンだ、という感じになるでしょう。ええと、画像があり、テキストがあり、ええと、それから異なるパスを通らなければなりません。でもはい、それは、とても似ています。うーん、それから、別のリクエストもありましたが、GitHubの、ええと、情報は、うーん、リプレイを送るときに共有しますので、あなたのメールに直接届きます、ですので受け取れます。うーん、それからスライドへのリンクも送ります。

うーん、これは可能ですか、これは以前に聞いたことがあります。ええと、埋め込みベクトルから元のデータを取り戻すことは可能ですか？近似です。なので、なんというか、私が間違っていたら教えてほしいのですが、直接元に戻すことは可能ではないと思います。でも、はい、近似です。なので通常、ああ、オーケー、という感じで分かることはあります。でも、いいえ、本当に逆変換することはできません。

それは初期の懸念の一つだったと思います。特に、regを行い始めていた大企業、うーん、独自データに関してです。うーん、オーケー、次は、概念をどのように洗練させるのか、例えば、テキストから概念を抽出する際のドメイン固有の概念について、例えば、見つけようとしている非常にドメイン固有の概念がある場合、オーケー、質問を正しく理解できているか確認させてください。つまり、ドキュメント内に非常に具体的な概念がある場合、それが意味していることだと思いますか？同じ質問者からフォローアップの質問があります。それには、ドメイン固有の知識のためにLLMをどのように訓練しますか？とあります。ああ、そのためのトレーニングですね。通常は、LLMをファインチューニングすると言うと思います。ええと、例えば、あなたの、個人データのようなもの、あなたの、分かりませんが、もし車の世界で働いていて、多くの車のマニュアルを持っているなら、ええと、それを直接ファインチューニングするかもしれません。これは、かなり高価になることもあります。ええと、LMのファインチューニングは、なんというか、非常に長いタスクになることがあります。ええと、一から訓練するほど長くはありませんが、とても長くなることがあります。

なので、その場合の別の解決策は、通常は、そうですね、あなたの特定のデータ用の適切なアプリケーションを持つ、というようなものです。なので、例えばまた車の例で言うと、ええと、マニュアルデータを注入し、ええと、車のマニュアルを注入して、それをベクトルデータベースに入れます。そうすれば、あなたのコンテキストに非常に特化したものを持つことができます。うーん、もしその一部に答えられていなければ、うーん、遠慮なく再送してください。でも、私は、私たちはその質問には答えられたと思います。うーん、でもはい、もしその質問の、ええと、どの構成要素でも見落としていたら、再送してください。うーん、こちらに別の質問があります。

LLMの性能をどのように改善しますか？わあ。なので、この文脈では、ええと、一般的なragについてのことだと仮定します。うーん、すべて、2つのこと、チャンキングと埋め込みが通常、ええと、実は鍵です。ええと、もし質問が一般的なLLMについてであれば、それは非常に深い質問です。ええと、でもagに関しては本当に、そうですね、埋め込みモデルが正しいものであることを確認することです。確実に、そうですね、同じデータを持っているようにしてください。

もしあなたの目的が、画像内の、そうですね、もし画像内の切り傷を検出することなら、ええと、確実に、それがその上で訓練されていることを確認しなければなりません。うーん、それからはい、チャンキング、チャンキングも大きな違いです。例えば、そうですね、私は、私はこれを示していますが、50のチャンクサイズでオーバーラップがゼロだと、明らかに何も意味を成していないことが分かります。ええと、おそらく何が起きているのかまったく分からないでしょう。もしかすると、過去に四半期報告書を読んだことがあれば分かるかもしれませんが、LLMは物事を理解できないでしょう。

一方で、semantic chakerがあれば、そうですね、文があり、物事はなんとなく機能し、なんとなく意味を成します。だから、そうですね、基本的にはそれらが通常、その2つが、非常に注意しなければならないものです。うーん、ありがとうございます。うーん、質問がどんどん入ってきます、ええと、人気のトピックですね。ええと、advanced rag techniquesはたくさんあります。

どれが、ええと、とても役に立つと思いますか？ええ、はい、それは、うーん、私の側では。うーん、ユースケースによる、によると思います。ええと、いちばん良いもの、つまり、これまで見た中でいちばん良いもの、ええと、いちばん良い結果が出たものは、私はragアプリをシンプルに保つ傾向があります。埋め込みについては疑いなくそうしています。だから通常は、ええと、私は、私はその方が良いと思っています、うーん、本当に、本当に深いrag、つまりシステムにかなり踏み込むよりも、より良い結果が得られる、という感じです。

ええと、少なくとも私の個人的な経験では、ええと、異なる埋め込みを使って、本当に、すごく良いものを見つけることが、ええと、たいていより良い、より良い結果につながると感じています。うんうん。ちょっと、その質問に付け加えると。何か、うーん、たとえば評価ツールのようなものを使っていますか、うーん、あなたのragを評価するために？それとも、使うのが好きなものや、定番のようなもので、今ぱっと思い浮かぶものはありますか？はい、私は、そうですね、LLMを審査員として使う、というようなものがあって、うーん、かなり良いもの、いいものがあります。ええと、最近Raggaを試していて、それから、ええと、Phoenixも試したいと思っています。これは評価ツールのようなものです。

うーん、なので、はい、それらは、RGAsで試してみて、かなり良かったのですが、Phoenixでも試してみたいです。ええと、そうですね、できれば、はい、自分の生活も楽にできるかどうかを見たいので、自分でやらなくて済むように、つまり、物事を直接チェックするようなことをしなくて済むように、という感じです。でもはい、NLMを使って、ええと、ULLMも判定する。はい。そしてそのトピックについては、Phoenixを評価に使うことについて、Arise Teamからの過去のウェビナーがあります。なので、そのリンクをチャットに投下します。

ですが、それは、うーん、rag技術、advanced rag技術に興味があるなら、うーん、おそらく再生を見るのに良いセッションです。うーん、なので、すぐにそれを共有します。うーん、CSV Excelデータセットに対してRAGはできますか？もしはいなら、これらのデータセットをどのように分割しますか？うーん、私はExcelで直接は試していませんが、CSVは、はい、ええと、非常に多くの異なるドキュメントタイプとの統合があると思うので、可能だと思います。ええと、例として、notionページやさまざまなものに対してできるようなものがあります。うーん、なのでCSVの場合は、ERsがあり、ええと、それから、それから何を持っているかによります。CSVに何が入っているかにもよります。たとえば、わかりませんが、CSVには入れられるコンテンツの種類が非常にたくさんあるので、うーん、それ次第ですが、はい、それ以外は同じです。

つまり、特定のERsがあり、それらはe-commerceで、それに応じて物事を見極める必要があります。なので、データによっては、たとえば、わかりませんが、10列あって、そのうち9列に、ええと、数字が入っていて、それは、ええと、あなたにとってあまり関連性がなく、1列だけにテキストが入っていて、それがあなたのragアプリにとって非常に関連性が高いかもしれない場合、たぶんその1列だけを使いたいでしょうし、それから、その特定の列でチャンク化します。なので、はい、CSV、それからExcelも同じです。ええと、Excelコネクタがあると思います。ええと、おそらく、彼らはあらゆるものに対するコネクタを持っているので、そうですね、うーん、私たちが言うところの、同じだけど違う、という感じです。

ええと、見てみましょう。質問フィードをもう一度確認しているところです。そのリンクを、ええと、チャットにすごく素早く投下します。うーん、なるほど。大規模なSQLデータベースのような構造化データ内のVectorを、ええと、ファインチューニングまたはマルチエージェントシステムの方がより良い選択になりますか？ちょっとそれは理解できているか確かではありません。

わかりました。質問の始まりは何ですか？それは、ええと、こう書いてあります、なるほど、だと思います。大規模なSQLデータベースのような構造化データ内のベクトルを、ファインチューニングまたはマルチエージェントシステムの方がより良い選択になりますか？ええと、できれば、その質問に、うーん、もっと詳細を加えて再送していただくとよいかもしれません。彼らが、ええと、質問を明確にしてくれるのを待つ間に、私たちは、その一部が、一部が抜けていると思います。私は、ええと、Ariseのウェビナーのリプレイへのリンクを投下します。ええと、Ariseによる、ええと、Phoenixを使って、うーん、right evaluationsを行うものです。うーん、そしてPhoenixはオープンソースでもあります。

はい、どうぞ。ええと、では見てみましょう。ファインチューニングの費用を抑えられて、場合によってはローカルで実行できる、より小さな LMS はありますか？はい、利用可能な LMS はたくさんありますし、それは本当に、あなたのユースケース次第です。ええと、時間があればローカルでファインチューニングすることもできます。ええ、でも常に可能です。非常に非常に、まあ、それを lms と呼べるのかはわかりませんが、LMS 言語モデル、ええ、より小さいものがあり、それらは、それなりに良い場合があります。

ええ、それは本当にあなたのユースケース次第です。それから通常はチェックアウトも、すみません、そうですね、hugging face などをチェックしてみてください。ファインチューニングしている人たちを見ることができます。ええと、LAMB three のような古典的な lambs は、これまでにさまざまなもの向けにファインチューニングされています。たとえば関数コーディングなど、ファインチューニングされてきました。ですから、オープンソースコミュニティが何をしているのかを確認して、ええ、もしかすると誰かがすでにあなたがやりたい作業をしているかもしれません。

ではこれは、ええ、私自身の質問です。ええと、あなたが最初に rag アプリを作り始めたとき、どこで間違えたのかを、ええ、知りたいです。もし戻って、過去の自分に、何をすべきか、あるいは何をすべきでないかについてアドバイスできるとしたら、ええ、それは私たちの視聴者にとって本当に役立つと思います。もちろんです。私にとって最初のことは、本当に、チャンク化が何なのか全くわかっていなかったことでした。ええ、あるいは、それがどう機能するのか、そして実際にどう機能させられるのか、ということですね。ええ、それで私はただ、毎回、たぶん最初はスペースごとにチャンク化していたと思います。そうすると、まあ、何も意味を成さなくなりますよね。

ええと、基本的に最初の rag を作るとき、自分で理解できないなら、データを見て、自分が ULM に何を与えているのかを見たときに、通常は m がそれを理解するのは非常に難しいです。ええ、もちろん可能ではありますが、ええ、通常は本当に難しいです。ですから、何が起きているのかをある程度理解できるようにしてください。ええ、例えばチャンクについて言うと、もし自分のチャンクを見て、ランダムにチャンクを1つ選んだとき、そのチャンクの文脈を理解できる可能性が非常に高いです。なので、それはとても役に立ちます。

それからもう一つは、私はすべてに OpenAI を使っていたことです。それは非常に良いのですが、つまり、とても、汎用的なモデルです。仕事はこなしますが、その後気づいたのは、ええ、だからこそ私が言い続けている、だからこそ embedding モデルについて話し続けているのですが、embedding モデルは大きな違いを生むということです。ええ、なので、それが、通常2つ目の間違いです。つまり、OpenAI が持っている whatever embedding モデルをそのまま使ってしまうことです。ええ、それで時にはうまくいかないので、そうすると、RAG アプリで非常に高度なことをしようとするのですが、実際には通常、embedding モデルを変えるだけでよかったりします。なので、これらがよくある2つです。

ありがとうございます。ええと、これは適切な、ええ、最後の質問だと思います。なので、最後の呼びかけをする感じにしましょう。ええと、あなたのプレゼンテーション、あるいは rag アプリについて、2文で要約していただけますか？残念ながら最初の5分を見逃してしまったので、きれいな締めがあると嬉しいです。はい。

ええと、RAG はローカルで使えます。ええ、LLM もローカルで、ええ、25行程度のコードで使えます。それが私のやったことです。完璧です。ええ、それから、少し遅れて参加されたその参加者の方には、録画をお送りしますので、必要なだけ何度でも見直していただけます。

ええと、本日はご参加いただき、また本当に素晴らしい良い質問をたくさんいただき、皆さんありがとうございました。ええと、あ、すみません。構造化データについての質問が最後の最後で追加されました。たとえば大規模な SQL データベースで、SQL データベースとチャットするような場合です。bu を使うのは理にかなっていますか。つまり、知りたいのが、たとえば SQL データベースとは何か、ということであれば、そこにあるものを埋め込む必要がある可能性があります。何らかの形で、だと思います。

データベースと話すことが可能だということは知っています、つまり、それらとチャットするということです。ええと、ですから、そうですね、それらを変換できる限り、そしてそれらを bu に変換できるなら、はい、ええと、ただしコンテンツとコンテキストを変換する必要があります。ありがとう、Stefan。ええと、ご参加いただいた皆さん、ありがとうございました。また次回お会いしましょう。

ええと、録画へのリンク、Stephan が説明したノートブック、ええと、そしてスライドについては、受信トレイをチェックしておいてください。そして、ええと、今後のトレーニングやウェビナーにもぜひご参加ください。皆さん、ありがとうございました。ありがとうございます。

Meet the Speaker

Join the session for live Q&A with the speaker

Stephen Batifol
Developer Advocate
Stephen Batifol is a Developer Advocate at Zilliz. He previously worked as a Machine Learning Engineer at Wolt, where he was working on the ML Platform and as a Data Scientist at Brevo. Stephen studied Computer Science and Artificial Intelligence. He enjoys dancing and surfing.