Join the Webinar
Loading...
このセッションについて
この講演では、DeepsetのTuana ÇelikがHaystackにおける検索拡張の例と、特定のNLPユースケース向けに独自のパイプラインを設計する方法を紹介します。Milvusのようなベクトル検索エンジンを、あなたのユースケース向けに設計されたRAGパイプラインと組み合わせることで、強力なLLMを最大限に活用する方法を見ていきましょう。
本日、Haystackを用いた生成パイプラインのための検索拡張の設計という本日のセッションと、ゲストスピーカーのTiana Chalikをご紹介できることを嬉しく思います。そしてTianaはDeep Setのデベロッパーアドボケイトで、Haystackというl l Mアプリケーションを構築するためのオープンソースN l Pフレームワークに注力しており、University of Bristolでコンピューターサイエンスの学位を取得しています。彼女はソフトウェアエンジニアとしてキャリアを始めましたが、その後デベロッパーアドボケイトとして機械学習の世界へ移り、現在はオープンソースn l Pコミュニティの支援に時間を捧げています。Tianaには、私の同僚であるU Tangも参加しています。彼の名前は週に千回くらい言っています。ええと、そして、ええと、彼はここSillsのデベロッパーアドボケイトです。
ようこそ、Tiana、そしてu Eugene。はい。ええと、今日は大規模な検索拡張パイプラインの構築についてお話しします。ええと、私の名前はChenです。uh、deep setのTijuanaと一緒に参加しています。
そして、ええと、まずあなたに自己紹介していただこうと思います。わかりました。皆さんこんにちは。ええと、紹介ありがとうございます。Emmy reが全部言ってくれました。私はDeep Setのデベロッパーアドボケイトの一人で、Haystackと呼ばれる大規模言語モデルアプリケーションを構築するための、私たちのオープンN L Pフレームワークに注力しています。
ええと、今日は主にHaystackについてお話しする予定で、こちらが私の、ええと、ソーシャルメディア情報のすべてです。もし私をフォローしたくないなら、どうぞ。ええと、それでは始められると思います。いいですね。ええと、ちなみにそこのQRコードは、TuanaのLinkedInにリンクしています。
もし携帯をお持ちなら、ええと、それをスキャンして、ええと、彼女をフォローするか、またはつながることができます。ええと、皆さんがこれをスキャンするために、10、15秒ほど差し上げて、それから私のスライドに移ります。はい。では、これが私です。ええと、私の名前はYugen Tangです。
私はZillowのデベロッパーアドボケイトです。ええと、近いうちにもっと多くのデベロッパーアドボケイトが加わることを願っています。ええと、そのQRコードは私のLinkedInにリンクしているので、スキャンしてフォローしたり、つながったり、メッセージを送ったりできます。ええと、私を見つけたい場合の、ええと、リンクがいくつかあります。ええと、私のバックグラウンドは機械学習で、ええと、最近はこうした検索拡張生成パイプラインをたくさん構築しています。
今日のアウトラインはだいたいこのような感じになります。まず、ええと、なぜ検索拡張生成、ええと、パイプラインを構築したいのかについて取り上げます。それから、RAGアプリにベクトルデータベースをどのように使えるかについて話します。そして、HaystackでRAGアプリのパイプラインをどのように構築できるかを見ていきます。その後、ええと、よくある質問をいくつか取り上げます。
これらは、ええと、私たちのプレゼンテーションで時々出てくる質問です。ええと、そして最後には、皆さんにも、ええと、質問する機会があります。それでは、Tiana、この部分をお願いします。わかりました。では、少しやり取りしながら進めますが、まずはなぜ検索拡張生成について話すのか、そして検索拡張で解決しようとしている問題を示すために、簡単に、ええと、おさらいから始めます。
例があります。皆さんの多くはすでにこのUIを見たことがあると思います。これは実際に私がchat G p Tにした質問で、ええと、私は検索拡張についてのトークは何時ですか、と尋ねました。するとここでわかるように、理由を得ました、ええと、ここではG P T threeを使っていて、ええと、返答は単に知らないというものでした。ええと、そして、ええと、もし運がよく、これができるモデルを使っているなら、「わかりません」という返答が得られます。しかし最悪の場合、単に幻覚である返答が返ってくることもあります。私はこの特定の問題を検索拡張生成で解決しようとします。ええと、そしてなぜその質問をしたのか少し洞察をお伝えすると、こちらは実際に、今晩私とあなた、Jennaが行うミートアップのスクリーンショットです。
そして、6時25分に、ええと、私による検索拡張についての講演があるのがわかります。ええと、私たちが解決しようとしているのは次のことです。まあ、大規模言語モデルはすべての答えを知っているわけではありません。そして検索拡張の背後にある考え方は、関連するコンテキストを与えることでそれらを助けられるというものです。そしてそのコンテキストが検索されると、なぜ私たちがそれを検索拡張と呼ぶのか、これは、これがその名前の由来だったのではないかと私が想像しているのですが、ええと、プロンプトや指示を拡張するからです。
私たちは、関連するコンテキストとともにこれらの大規模言語モデルに送信します。ですから、私の前の質問に対しては、関連するコンテキストはこの特定のイベントデータかもしれません。このイベントは何ですか？イベントの内容は？各講演は何時か、などです。ですから検索拡張パイプラインは、結局のところ、次のようなプロンプトを送るように見えます。指示またはプロンプトがあり、私たちは、コンテキストが与えられたら、以下のコンテキストに答えが含まれていない場合は、わかりません、と答えてください、と言っています。
さて、これは検索拡張プロンプトの一例にすぎません、ええと、そしてここで私がしたことは、今夜のイベント、ええと、スケジュールをそのままコピーして貼り付けただけです。そして、検索拡張についての講演は何時ですか？と尋ねました。これを行うと、妥当な答えが得られます。そしてこれは実際に正しい答えです。検索拡張についての講演は午後6時25分から6:55までに予定されています。ですから、今日U G Nと話すことは、これを実際に代わりに行ってくれるパイプライン、つまり大規模言語モデルとのやり取りにおいてこの最終結果を実現してくれるパイプラインをどのように構築できるかです。そしてそのコンテキストを埋める方法が検索ステップになります。
ええと、haystacksでこれらのパイプラインをどのように構築するかについてはまた戻って話しますが、その前に、GNに引き継いで、ええと、ベクトルデータベースがこの、ええと、パイプラインにどのように関わるのかについても話してもらいます。では、ot、はい。では、ええと、RAGがどのように機能するかについて少し話して、それから後でVector databaseの詳細に入ります。ええと、基本的な考え方は、まだ、ええと、chat G B TやLlamaや、ええと、una、あるいはそれらの大きな、ええと、大規模言語モデル、大きな言語モデル、大規模言語モデルの中に入っていない何らかのナレッジベースがあるということです。ええと、そしてそのナレッジベースを取り、それをembeddingsモデルに入れます。embeddingsモデルは、対象となるデータの種類、ええと、あなたが扱おうとしているデータと同じ種類のデータで訓練された深層学習モデルです。
すると、その学習、その、ええと、その深層学習モデル、embeddingsモデルは、最後から2番目の層の出力として一連のベクトルを生成します。ですから、この小さな画像では、最後にこの1つのノードのようなものがあるのが見えます。embeddingsが生成されるときに実際に起こることは、最後のノートを切り取り、最後から2番目の層からの出力だけを取り出すということです。そしてそれがベクトルです。そしてそれらのベクトルは、vissやZillowのような何らかのベクトルデータベースに保存されます。そしてこれはragへの最初のステップにすぎません。
これは、カスタムの、ええと、ええと、検索拡張生成アプリを実際に持てるように、データをアプリケーションに入れるステップにすぎません。ええと、しかし私はここ数か月でこれらをたくさん構築してきました。そして、ええと、検索拡張生成のスタックが典型的にどのように見えるかというと、私たちがC V Pと呼ぶものです。ええと、そしてc V Pはchat、G b t、つまりl l mやchat、G B T、ええと、または他の任意のl l Mを表します。ええと、そしてこれは典型的に、これらの検索拡張生成アプリの背後にある計算能力です。
これはプロセッサで、これをコンピュータの観点で考えると、ええと、novis のようなベクトルデータベースがあります。そしてこれはストレージブロックとして解釈できます。これはあなたの、ええと、あなたの、あなたの、あなたのメモリ、ええと、あなたの ROM、ええと、そして、ええと、prompt as code があります。これは本質的に、必要な応答を得るために L L M に正しい、ええと、プロンプトを与えるように、そのプロンプトを、ええと、拡張するものです。そしてこれに使えるものの例として haystack があり、これは主にこれらのパイプラインのオーケストレーションに使われます。ええと、これは、ええと、これは私たちが構築した、C B P スタックを使用するアプリケーションの、ええと、アーキテクチャ例です。
私たちが構築したアプリケーションは O ss chat と呼ばれています。これはオープンソースの、ええと、ソフトウェアチャットボットです。基本的には oss chat chat. io にあります。見に行くことができますし、オープンソースソフトウェアについて質問することができます。
その仕組みは、先ほど示したように、ナレッジベースを用意します。ステップ 1 は、ナレッジベースを用意し、それを埋め込み、チャンクに分割し、埋め込み、ベクトルデータベースに入れることです。その後、ユーザーが来て質問をすると、私たちが最初に行うのは、実際にベクトルデータベースにアクセスして、ええと、つまり、答えはここにあるか、と確認することです。もしあれば、それを返すことができます。もしなければ、ええと、答えを持っているなら l l m に、ええと、答えを尋ねる必要があるかもしれません。
ええと、ここにはいくつか注意点がありますよね？ ええと、あなたは、lmm に尋ねる質問が意味をなしていること、そして何らかの holness や応答が返ってきていないことを確認したいわけです。ええと、そして O Ss s chat から生まれたものに G P T Cache と呼ばれるものがあります。これは、私たちが o s Ss chat を作成していて、ええと、答えを得ていた、ええと、またはこれらのドキュメントに対する質問を得ていて、これらのドキュメントが答えられる質問を生成していたときに、多くの、ええと、質問が、そして、ええと、私たちが LM に与えていた多くのクエリが同じになることに気づいたために作ったものです。つまり、あるいは、意味的に十分似ていて答えが同じになるほどだったのです。そこで私たちはそれらの応答をキャッシュすることにしました。そしてそれによって、ええと、基本的に多額のお金が節約されました。
では、検索拡張生成にベクトルデータベースをどのように使うのでしょうか？ これは、ええと、基本的に私がこの数か月間構築してきたものです。ええと、ステップ 1、なぜベクトルデータベースを使うのでしょうか？ ええと、基本的にベクトルデータベースを使いたい理由は、自分のデータを L l m に注入したいからです。ええと、または l l m の上に、l m アプリケーションに注入したいからです。そして、つまり、あなたがクエリしていることや尋ねていることに対して関連性のある応答を得たいわけです。そして l m は、必ずしもあなたが使用している種類のデータ、ええと、またはあなたのデータで訓練されているわけではありません。実際、ほとんどの場合、そして私は、つまり、もしそれがあなたのデータで訓練されていたら奇妙だと言えるでしょう、ええと、特にあなたがプライベートデータを持っている場合は。
ええと、そして最後に、これにベクトルデータベースを使う最後の理由、あるいは最後の理由ではないかもしれませんが、検索拡張生成にベクトルデータベースを使う 3 つ目の理由は、経済性がうまく成り立つからです。ええと、com. ええと、あなたが本当に持っているもう一つの選択肢は、もし、つまり、何らかの L L M に、ええと、自分のデータを注入したいなら、ファインチューニングを行うことです。ええと、そしてそれは通常、ベクトルデータベースを使って、ええと、その方法で自分のデータを注入するよりもはるかに高価です。では、ベクトルデータベースとは何でしょうか？ ええと、本質的にベクトルデータベースとは、いくつかのベクトル埋め込みを保存し、意味的類似性を行うために使用するデータベースです。
では、これはどのように機能するのでしょうか？ ええと、まず非構造化データから始めます。通常、何らかのデータがあります。ええ、つまり、データの大半は非構造化です。画像かもしれませんし、動画かもしれませんし、テキスト文書、PDF、ええと、音声かもしれません。ほかにも、そういったものかもしれません。そしてそれを適切な埋め込みモデルに入力しますよね？ ですから、適切な種類のデータを適切な種類のモデルに入力することを確実にするのは、実は非常に重要です。
画像データを sentence transformers のようなものに入力したくはありませんし、文を res 50 のようなものに入力したくもありません。こうしてベクトル埋め込みが得られたら、それらを VIS や zills のようなベクトルデータベースに保存します。ええと、そしてそこから、ええ、それがデータをベクトルデータベースに入れるために必要なことのすべてです。それがデータをアプリケーションに入れるために必要なことのすべてです。そこから、行うのはクエリのステップです、そうですよね？ クエリとは、探しているものと同じ種類のデータを取ることです。
たとえば、resnet 50 を使ってベクトル化された大量の画像データを保存している場合、クエリを使います。ええと、そして、問い合わせたい入力データからベクトル埋め込みを得るために同じモデルを使いたいわけです。さて、別のモデルを使いたい場合もあります。ええと、私も少し時間がかかりました。つまり、クエリに別のモデルを使うのはいつなのか、なぜ別のモデルを使うことがあるのか、ということを理解するのにです。ええと、そして分かったのは、graceful degradation と呼ばれるものがあって、既知のものを未知のものに対してチェックしたい場合があり、そのときにクエリデータに別のモデルを使ってベクトル埋め込みを作成し、ベクトルデータベースに対して照合するのだということです。では、セマンティック類似性の非常に簡単な例を取り上げます。これは非常に、非常に単純な例になります。ええと、現実の場面で二次元ベクトルのようなものを使うケースはありません。
そして、少なくとも retrieval augmented generation の観点で見ると、ユークリッド距離を使うケースも非常に少ないです。しかしこれは、ええ、かなり有名な論文で、ええと、セマンティック類似性についてのものであり、ベクトルを使ってセマンティック類似性の考え方を非常によく示しています。次の数枚のスライドから理解してほしいのは、基本的にベクトルによって、数値ではないものに対して数学を行えるようになるということです。そしてこの例では、言葉に対して数学を行います。
では、これから示す例は、queen から woman を引いて、man を足すと king になる、というものです。では見てみましょう。ええと、これらのベクトルを見てみましょう、いいですか？ queen は 0. 3, common 0. 9、king は 0.
5, common 0. 7、woman は、ええ、0. 3, common 0. 4、man は 0. 5, common 0.
2 です。queen と woman には、ええ、ある程度のセマンティック類似性があることが分かります。なぜなら同じ X 値を持っているからです。そして queen と king は、ええ、woman と man の関係に似た関係を持っていることが分かります。なぜなら y 値が、ええと、同じ量だけ異なっているからです。また、king と man も x 軸上で同じセマンティック類似性を持っていることが分かります。なぜなら 0. 5 を持っているからです。
いいですか？ ではここで何が起きるのでしょうか？ まず queen という単語を取り、woman という単語を引きます。すると 0. 3 comm, 0. 9、0. 3, comm 0.
4 となり、その結果は zero comm 0. 5 になります。ええと、これは必ずしもグラフ上で何かを表しているわけではありませんが、おそらく王族という概念のようなものを表しているのだろうと推測できます。なぜなら、queen と、つまり普通の人との違いは何かというと、ええと、それは王族としての地位ですよね？ ええと、そしてそこから、私たちが行うこと、行いたいことは、man という単語を足すことです。つまり、zero comma 0. 5、ええ、plus 0.
5 comma 0. 2 は 0. 5 comma 0. 7 になり、これは king に直接対応します。ですからこの例は、非常に、非常に単純なおもちゃの例で、二次元ベクトルにおいて、queen minus woman plus man equals king となります。
では、ベクトルデータベースとはどのようなものなのでしょうか？ ええと、ベクトルデータベースは、基本的には、ベクトル検索を行うために専用に作られたデータベースです。そしてベクトル検索に非常に特有なこととして、第一に、大量の計算を行うことになります。ベクトル類似度では、ベクトルを比較するために何らかの計算を行う必要がありますよね？ そして、そのためには専用のベクトルデータベースが必要です。なぜなら、通常のSQLデータベースは大量の計算を行わないからです。たとえば、SQLデータベースに入っていって、「今すぐ768個の計算をして」と言うようなことは、非常にまれです。というか、実際にはそんなことは起きないと思います。
そんなことは起きませんよね？ 通常は、何らかのビットマスクを行ったり、結合のようなことを行ったり、何らかの比較を行ったりするかもしれませんが、その程度です。だからこそ、ベクトル検索、そして検索全般において、ベクトルデータベースのようなものが必要になるのです。そこには、関心の分離が大きく3つあります。1つはインデックス作成で、つまり、データベースを検索する方法をどのように作るかということです。1つはデータで、これはデータ取り込みです。データをどのようにデータベースに入れるか。そして最後がクエリで、つまり、実際にデータベースに結果をどのように問い合わせるかということです。そして、vis は、クエリ、データ、インデックスノードに関して関心の分離を持っています。
そしてこれは、私たちの知る限り、かなり私たち独自のものです。ええと、インデックス作成では、インデックスノードがインデックスを管理します。vis が提供するインデックスには多くの種類があります。ええと、それについてはたくさんのリソースがあり、下にいくつかリンクを貼ることもできます。ですが、viss が提供するインデックスのいくつかには、hierarchical navigable small worlds、つまり H N S W、face、または inverted file index、つまり I V f data node などがあります。
データノードはデータの取り込みに使われます。ええと、メッセージを読みます。つまり write ahead log です。そしてデータを受け取り、コンパクト化し、インデックスを作成するタイミングになるとインデックスノードを呼び出し、それをある種の永続的なオブジェクトストレージに入れます。ええと、そしてクエリノードはクエリ時に使われます。つまり、データに問い合わせる必要があるときは、クエリノードを使います。
ええと、通常、クエリノードは永続ストレージと write ahead log の両方にアクセスできる必要があります。そうすることで、今何が起きているのか、そしてすでに何が保存されているのかを把握できるからです。その理由は、VUSs がデータの保存方法に関して非常に興味深いアーキテクチャを持っているからです。データは512メガバイトのチャンクで保存されます。そして、これらの512メガバイトの1つが来るたびに、私たちはそれを切り出します。つまり、一度に512メガバイトずつ、このようなセグメントを切り出し、そのセグメント上、つまり512メガバイトのセグメント上にインデックスを作成します。そして、そのインデックスは変わらず、そのセグメントも、強制的に再インデックスしない限り変更されません。これはスケーリングにとって非常に非常に良いことです。少し想像してみてください。たとえば、100ギガバイトを並列でクエリするのと、512メガバイトに対して200個の並列クエリを実行するのでは、どちらが速い応答を得られるでしょうか？ 並列クエリを実行する方が速い応答を得られることは、かなり明らかです。
これらのノードが分離されているもう1つの良い点は、必要に応じてスケールアップやスケールダウンができることです。「かなりクエリしているけれど、データはまったく取り込んでいない」というだけで、ノードをスケールアップする必要はありません。ですから、「このデータを取り込むときだけデータノードをスケールし、クエリが多いときだけクエリノードをスケールアウトする」と言えるのは便利ですし、経済的でもあります。つまり、これがベクトルデータベースの姿です。ここではアーキテクチャとして Novus を使っています。
ええと、はい、それらは大規模な、ええと、ベクトルをクエリして多くの計算を行えるように、目的に特化して作られています。ではこれから Haystack を使って RAG パイプラインを構築することについて話します。そして Ana、あなたにまたお渡しします。はい。ええと、では、パイプライン自体の説明に入る前に、ええと、Haystack について話しておく必要があります。ええと、Haystack は Python で構築された完全なオープンソースフレームワークで、本番環境向けの大規模言語モデルアプリ、ええと、アプリケーションを構築するために設計されています。
ええと、しかしそれだけではなく、haystack は、ええと、コアな N L P タスクもカバーしています。実際その一部は、ええと、はい、Jen も言及していましたが、ええと、多くの場合、もし、ええと、大規模言語モデルを活用するアプリケーションを構築したい場合、それは単に大規模言語モデルで構築するものだけにとどまりません。行うべきデータ準備がたくさんあり、ええと、選択した、ええと、データベースにインデックスする必要があります。ええと、そして当然、どのような、ええと、アプリケーションを構築したいかという選択肢があります。ですので、右側には、ええと、haystack で構築できる2つのパイプラインの古典的な例の1つを示しています。
1つはインデックス作成パイプラインと呼ばれるもので、ええと、Eugene がすでに言及していました。ここではファイルを準備し、前処理し、必要な形に整えます。ええと、これらの、ええと、ファイルを L L M パイプラインで使用できるようにするためです。2つ目はクエリパイプラインです。では、ドキュメントストアから始めます。haystack では、ええと、ドキュメントストアという概念があり、さまざまなデータベースの多くの選択肢があります。その1つが VUS です。
2つ目の概念はインデックス作成パイプラインで、すでに少し話しましたが、ここではさまざまなファイルコンバーターや前処理の選択肢がたくさんあります。これは重要です。なぜなら、使用したい言語モデルの種類によって、データを、ええと、その大規模言語モデルのコンテキスト上限などに応じて異なる長さにチャンク化したい場合があるからです。そして最後のステップは、おそらく最も興味深いステップです。ですので、この点については、特に今日は retrieval augmented generative pipeline の例として話します。この背後にある考え方は、パイプラインが retriever で構成され、ええと、その後に haystack で prompt node と呼ぶものが続くというものです。そして retriever と prompt node は一緒に動作し、最終的には、大規模言語モデルに送ることができ、そのモデルが処理して正しい答えを返せるような指示を持つことになります。
ええと、そしてここでは多くの選択肢があります。ええと、retriever と prompt node の両方について、開発者として、どの、ええと、どのモデルを使いたいかを選ぶことができます。ええと、embedding search を行うためにどのモデルを使うか、または answer generation を行うためにどのモデルを使うかです。ええと、ここにある QR コードをスキャンすると、haystack の GitHub ページに移動するはずです。ですので、興味があれば、ぜひ見てみてください。ええと、それでは haystack で RAG パイプラインを構築するのに役立つコンポーネントについて話し始めましょう。
最も重要な2つのコンポーネントは、ええと、RAG パイプラインの自分のユースケースに合わせて変更しカスタマイズすることになる prompt template と prompt node です。まず prompt template について話したいと思います。prompt template は基本的に、ええと、大規模言語モデルとどのようにやり取りするかの設計図です。最終的にはプロンプトを生成しますが、変更することができ、クエリ時にも変更できます。一方で prompt note は、大規模言語モデル自体とやり取りするノードです。
これらは基本的に、あなたのアプリケーションと大規模言語モデルの間のインターフェースです。プロンプトテンプレートを使用して、それらの大規模言語モデルとどのようにやり取りするかを理解しますが、本質的には、クエリを送信し、その後、使用することを選択した任意のモデルから応答を受け取るノードです。繰り返しますが、どのモデルを使用したいかは選択できます。ええと、OpenAI models が一例ですが、Falcon や M P TLama のようなオープンソースのものも使用できます。これは新しく追加されたものでもあります。そして結局のところ、もう一度このスライドに戻りたいと思います。私たちが到達したいのは、大規模言語モデルへのクエリがこのようなものである代わりに、このようなものを構築できるシナリオに到達することです。
難しい部分は、では、どのようにこのコンテキストを埋めるのか、ということです。もし何百万、何百万もの、ええと、データがある場合、どのように正しいコンテキストを見つけるのでしょうか？そしてそこで、検索拡張の部分が関わってきます。では、プロンプトテンプレーティングを見ることから始めましょう。ここでは、提供された情報をどう扱うかを l m に指示します。1つの例として、独自のカスタムプロンプトテンプレートを構築できます。ええと、ここにコードスニペットがあります。
いくつかコードスニペットがあります。ええと、この後、実際に rag パイプラインと haystack を構築することになります。そして、ここでは rag question answering というプロンプトテンプレートを作成しました。ええと、プロンプトにはコンテキストが与えられていることがわかります。以下のコンテキストに答えが含まれていない場合は、質問に答えてください、I don't, don't know と言ってください。
そして context と question がありますが、ここで強調したい部分は、中括弧の中に見えるものです。青で強調しています。ここには中括弧付きの context、join documents、そして question と中括弧付きの query があります。これは、parametal documents と query がクエリ時に埋め込まれる可能性があることを意味します。そして重要な点は、documents の、ええと、parameter はデフォルトで、それを受け取っている可能性のある retriever からのあらゆるものを受け取るように設定されていることです。
次にできることは、ええと、prompt node を使用し、先ほど作成した prompt template をデフォルトの prompt template として定義することです。ええと、繰り返しますが、これは私たちの設計図になります。L L M とどのようにやり取りすべきかについての、prompt notes の設計図になります。ここでは、G PT three を使用する選択をしたことがわかります。そして実際、G P T three を使用することを選んだのは、以前お見せしたあの chat. G P T のスクリーンショットで使用していたのと同じモデルだったからです。
当然、a p i key が必要になります。そして default prompt template を、ええと、brag question answering に設定しました。これは先ほど作成した prompt template です。プロンプトに関するもう一つのオプションは、私たちの新しい prompt hub で公開されているプロンプトのいくつかを使用することです。このQRコードをスキャンすると、そこに移動します。ええと、これは自分で設計しなくても、すでに利用可能なプロンプトを活用するかなり手軽な方法です。ええと、そして default prompt template を、Prompt hub で利用可能なプロンプト名の、ええと、key の1つに設定できます。
一例として、そして私はこれをかなり頻繁に使いますが、ええと、deep set question Answering というものがあります。この、ええと、prompt は、retrieval augmented の que、ええと、question answering を行うようにすでに設計されています。さて、prompt templates があり、prompt node があります。実際に rag pipeline をどのように構築するのでしょうか？ここから retrieval について話し始めます。そしてここで、どのような種類の database を使用するかについても気にし始めます。この例では、Mailbu document store を使用しています。Mailbu document store は、ええと、私たちの統合 document stores の1つです。
haystack integrationsページを見ると、他のものもすべて確認できますが、始めるのはとても簡単です。ただ、document store is vis document storeと言うだけです。これにより、visをローカルで実行している場合、すべてデフォルトパラメータでセットアップされます。そしてこれは、ローカルのNobusデータベースに入っているどんなデータドキュメントにも、今アクセスできるということです。私はインデックス作成パイプラインを通してはいませんが、データを準備してNobusdocument storeに入れるために、そうすることもできました。
次はretrieverです。ここでも、haystackのretrieverにはたくさんの選択肢があります。私はembedding retrieverを使っています。これは本質的には、vector databaseにクエリを投げるために使うと決めたモデルです。そして、これについての質問も来ているのを見ました。q and aの最初の質問の1つです。
そして、はい、このretriever nodeが行うことは、queryを取得すると、ユーザーからqueryを受け取ると、そのqueryのvector表現を作成し、それをmail内のすべてのdocuments、このdocument storeと比較します。だからこそ、embedding retrieverにどのdocument storeで作業するかも伝える必要があります。そして最後のnoteは、ここにあるprompt noteです。私はdeep setsから公開されているものの1つを使うだけです。そしてここでも、私はG P T threeを使っています。
これでcomponentsはすべて準備できました。次に、このpipelineを実際に構築したいと思います。ユーザーがqueryを尋ねたときにできるようにしたいのは、pipeline内の最初のnode、最初のcomponentを、そのembedding retrieverにすることです。ただし、作成したそのembedding retrieverは、その後Mel's document storeにあるdocumentsにqueryを投げます。そして、取得したdocumentsをprompt noteのpromptsに埋め込み、large language oneにqueryを投げます。それはどのように見えるでしょうか？ ええと、Zoomでは少し遅延があると思いますが、もう話し始めます。
ええと、次にrag pipelineを構築します。build a rag pipelineのslideが見えているか、どなたかchatで教えていただけますか？ こちら側では見えているのですが、そちら側では見えていないのでしょうか？ 見えています。ああ、わかりました。素晴らしいです。ええと、わかりました。
それでは次にrag pipelineを構築します。ええと、ここで行うことは、まずpipelineをinitializeします。ええと、そして先ほど言ったように、最初に追加したいnoteはretrieverで、inputsをqueryに設定します。ええと、haystackでは、デフォルトで少し特別なinput optionsが2つあります。1つはqueryで、もう1つはfileです。fileは、indexing pipelineを構築したいときに使われます。
しかし今は、querying pipelineを構築したいので、最初に使うinputとしてqueryを選んでいます。そして単純に、prompt nodeという2つ目のnodeを追加し、prompt nodeに対して、あなたのinputはretrieverです、と言います。つまり、retrieverから得られるどんなdocumentsも、今度はprompt nodeが使っているpromptに埋め込まれることになります。そして単純に、このpipelineを同じqueryで実行することで、最初に見たretrieval augmentedなpromptを実現できます。この良いところは次の通りです。ええと、ご覧のように、このrun functionにはqueryだけでなく、parsと呼ばれるものもあり、これらのparametersは各queryごとに個別に提供できます。
そしてここでは、retrieval nodeにtop K parameterを与えることにしました。これは重要です。なぜなら、どのmodelを使うと決めたか、そしてvector database内の各documentsがどれくらい長いかによって、使うと決めたmodelのcontext limitに達してしまう可能性があるからです。これは単なる例で、私は、いいでしょう、retrieverにはlarge language modelを作成するために、databaseから最も関連性の高い上位5件のdocumentsだけを取得してほしい、と言っています。もし能力の低いmodelを使っているなら、それを減らすことにするかもしれません。あるいは、より高い能力のmodelを使っているなら、それを増やすことにするかもしれません。それぞれに利点と欠点があります。
Top K を高くする利点は、大規模言語モデルが回答を生成するために、より関連性の高いコンテキストを与えられる可能性があることです。しかし欠点として、その場合、モデルが実際に処理できる限界に達してしまう、ということがあります。最後に、これが実際に動作しているのを確認できるサンプルアプリケーションで締めくくりたいと思います。その QR コードをスキャンすると、Hugging Face Space に移動します。これは公開 Space で、私たちが作成したデモは retrieval augmentation のデモです。これは G P T three を使っていると思います。そして、retrieval augmentation を行った場合と行わなかった場合で、回答がどうなるのかを紹介しているだけです。なので、plain G P T による回答と retrieval augmented G P T による回答の 2 つの回答が表示されるのが見えると思います。
それだけでなく、静的なニュースデータセットを使って retrieval augmentation を試すこともできます。つまり、私たちが用意しているのは接続先のデータベースで、そこには事前に読み込まれたドキュメントが入っており、私たちはそれを変更していません。ただ、できる面白いこととして、データベースを使う代わりに、単に Web 検索をしたい場合もあるかもしれません。なので、Web 検索を使った retrieval augmented generation がどのように見えるかも確認できます。そしてこのデモでは、SS v v についての当時のすべてのニュース記事をアップロードしました。
そして、この Space 上で手元にあるデータセットを使うことも、Web 検索を行うこともできます。以上です。これが haystack を使って retrieval augmented pipeline を構築する方法です。実際にはそれほど難しいことはありませんが、特に prompt template を作成するときには、多くの創造性を加えることができます。そこでは本質的に、question answering にしないで summarization や他のものにする、と決めることさえできます。自分の prompt を考え出すのは、とても創造的なプロセスです。
はい、いいですね。ありがとうございます。それも素晴らしい説明でした。これはとても面白い選択ですね。では、よく受ける FAQ をいくつか取り上げてから、質問回答、あるいは聴衆からの質問に移りたいと思います。
よく聞かれる FAQ のいくつかは、vector database を使いたくないのはどんな場合か、あるいは augmented generation を使いたくないのはどんな場合か、というものです。これに対する私の回答は通常、もしデータが単なる key value store で、類似性を比較する必要がないのであれば、vector database は必要なく、retrieval augmented generation app で使うべきものではありません。入力データや保存しているデータがどれほど類似しているか、あるいは意味的にどれほど類似しているかを比較する必要がある場合には、retrieval augmented generation のために vector database を使うことになります。もう 1 つよく受ける質問は、C S V ファイルや PDF に関する vector embeddings についてです。retrieve augmented generation で最も重要なことの 1 つは、実際に関連性のあるデータを取得したいということです。そして、自分にとって適切な関連性を持つデータを取得できるかどうかを左右する最も重要な部分は、embeddings models です。
そのため、C S V や PDF を扱う作業をしている場合、それらに対して適切な embeddings models を使っていることを本当に確認する必要があります。最近、あるユースケースに出会ったのですが、ある人が、すみません、ある人が C S V データを Vector database に入力していましたが、それを embed するために C SS v のような embeddings model を使っていませんでした。そのため、sentence transformers を使っていたので、良い結果が得られていませんでした。もう 1 つ、私たちが質問を受けることがあるのは hybrid search についてです。これは基本的に、構造化データと非構造化データを検索したい、そしてそれは Vector database でできるのか、というものです。答えは yes です。VIS や Zillow source metadata です。おそらくすべてでこれができるわけではなく、vector search library ではおそらくできないでしょうが、extra database ではこれができ、それによって retrieval augmented generation app を拡張し、強化するのにも役立ちます。
ええと、わかりました、ではQ&Aに入りましょう。ええと、ベクトル類似検索に関する質問があります。私の理解では、あ、ちなみに、このQRコードはベクトルデータベースのベンチマークツールへのものです。ええと、ベクトル類似検索に関する質問があります。私の理解では、retrieval augmentedにおける最初のステップ、検索拡張では、クエリをデータベース内のドキュメントベクトルと同じベクトル空間に埋め込むことが含まれます。
本質的には、これはクエリの埋め込みが潜在的な回答の埋め込みに意味的に近いはずだ、ということを意味します。この仮定は常に正しいのでしょうか？ええと、つまり、まあ、そうですね、そう、はい。はいでもあり、いいえでもあります。わかりました、これは実は少し複雑です。ええと、通常の考え方としては、あなたの質問、クエリは回答に意味的に近くなる、というものです。なぜなら、何かについて質問することになり、ええと、検索することになり、Vector databaseはあなたが尋ねた質問に意味的に類似したものを検索するからです。
さて、これを実際に強化する方法を見たことがあります。そしてこれは、os s chatのG P T cacheについて私が話していたことに少し近いのですが、実際に質問空間に対してクエリすることで、これを強化できます。つまり、できることとしては、ドキュメントを取り、chat G BTや他のL L Mに行って、「ねえ、これらのドキュメントから回答できる質問をいくつか生成してくれますか？」と言うことです。そうすると質問空間ができ、それに対してもクエリできます。ですので、ええと、答えははいです。あなたのクエリはおそらく回答に意味的に近いでしょう。そして同時にいいえでもあります。なぜなら、質問空間を作ることで実際にはより良い結果を得られる可能性があるからです。ええと、はい、意味が通じているといいのですが。わかりました、これは私が答えられると思います。
わかりました。ええと、この質問は、ええ、rag DB vectorの制限をどう克服するか、ええ、制限がある場合、大規模言語モデルに変更や更新が必要か、ええ、すべてをVector dbに再インデックスするために、クエリにはまったく同じL l Mが必要なのか、というものです。ええと、大規模言語モデルを変更できるのか、それともVector db内で定義されているため許可されないのか？実はRADパイプラインでは、ほとんどの場合、2つの別々のモデルについて話しています。ええと、最後の大規模言語モデル、ええと、回答を生成するために使う大規模言語モデルは、ベクトルデータベース内でデータをインデックスし、クエリするために使うモデルとは完全に無関係であり得ます。つまり、chat G P TやG P T threeを使い始めたけれど、性能が気に入らずlamaに切り替えたい場合、それはまったく問題ありません。これはVectordatabase内のデータに関して心配する必要のあることではありません。
さて、インデックス作成、ええと、Vector databaseへのインデックス作成に関しては、ええと、2つあります。はい、ええ、モデルを選びます。そのモデルには、ええと、各ベクトルに対して作成する次元数が決まっています。そして検索ステップでは、同じモデルを使うのが良い考えです。なぜなら、その場合、同じ次元数を持つクエリのベクトル表現を作成したいからです。ええと、そしてそれは、embedding retrieverのステップに対してのみ設定できます。いくつかのシナリオや、いくつかの、ええ、retrieverでは、ちょっと高度なことを行うものがあり、ええと、ドキュメント用にembedding modelを使い、そのモデルでドキュメントを埋め込みますが、クエリには別のモデル、似たモデルですが別のモデルを使うことができます。ただし、やはり最終的には同じ次元数になります。
ええと、つまり、これが、私のドキュメントを Vector DB にインデックス化するために使用されたモデルと、クエリに使用されたモデルについて注意を払うべき唯一のステップです。ええと、この中には、データを更新する必要がある場合に何が起こるのかという、3つ目の質問も隠れています。これは、クエリに使用する大規模言語モデルを再トレーニングしたり、何かしたりする必要があるという意味ではありませんが、だからこそ haystack には、私がまだ説明していない、インデックス化パイプラインと呼ばれる別のパイプラインがあります。ええと、新しいファイルがあるたびに、そのファイルをインデックス化パイプラインに通すだけで、他のすべてのデータが埋め込まれているのと同じ方法で、それがベクトルデータベースに埋め込まれます。ええと、これについても本当に手短に触れておきたいです。
ええと、あなたが、ええと、この質問でここで l l M と言っているのは、埋め込みモデルのことだと仮定しますが、それに対する変更や更新があった場合、Vector データベース内のすべてを再インデックス化する必要があるのか、ということですね。ええと、それは実際には、あなたがどのように実装するか次第になります。ええと、必要かもしれませんし、必要でないかもしれません。実際に、自分のパフォーマンスがどのように見えるかを確認することができます。ええと、これは先ほど私が述べたことですが、knowns と unknowns を確認する graceful degradation と呼ばれるこのプロセスを通じて、それを確認したいと思うかもしれません。
わかりました。ええと、ベクトルデータベースには何か制限がありますか？ 例えば、データベースが一度にインデックス化できるデータ量に制限はありますか？ さて、ベクトルデータベースには制限がありますか？ 答えは「はい」です。それらはソフトウェアであり、すべてのソフトウェアには制限があります。ええと、viss はインデックスだけです。つまり、viss は一度に 512 メガバイトしかインデックス化しません。なぜなら、チャンクと 512 メガバイトのセグメントを取るからです。データが大きいほど、あなたが、ええと、インデックス化する必要があるデータが大きいほど、時間が長くかかります。
ですから通常、私たちは「ねえ、データのサイズのようなものに基づいてだけインデックス化しよう」と言います。なぜなら、そのほうが効率的だからです。ええと、パフォーマンスの面でも、そして、ええと、金銭的価値の面でもです。ええと、そうですね、制限に関して私が触れられていない他の質問があるなら、遠慮なくこれを更新してください。ええと、Vis に特定のドキュメントを、データベース全体を再インデックス化せずに更新できるか、つまり、あるドキュメントの埋め込みを削除する、ええと、ドキュメントの、という質問があります。ええと、私は、haystack の観点からこれに答えられます。もちろん、はい、はい、はい。
そして familiar について話すこともできます。では haystack の観点から先にどうぞ。はい、これは私たちが持っているすべてのドキュメントストアで実行できます。ええと、繰り返しますが、これは私があまり詳しく説明しなかったインデックス化パイプラインのことを指していますが、インデックス化パイプラインは、あなたが見たクエリパイプラインと同様に、自分で作成するパイプラインであり、常にそこにあります。そして、ええと、ドキュメントストアに追加したい新しいデータがある場合は、単に、ええと、その新しいファイルでインデックス化パイプラインを実行します。
そして、何かをすべて削除する必要はありません。それは新しいファイルを、すでに存在しているあなたの vis、ええと、データベースに書き込むだけです。また、オプションもあります。ええと、これはその後、ドキュメントストアに使用するデータベースに依存しますが、ええと、既存のものを更新するためのものです。例えば、私たちはこれをよく使います。ええと、ドキュメンテーションサイトでは、それらは新しいページではなく、ページが変更されます。ええと、この場合、フラグを切り替えることができます。
つまり、そのページがある程度重複していた場合は、削除して再、ええと、再導入するのではなく、上書きするということです。はい、はい。ええと、Viss にも同様の種類の機能があります。ええと、asserting と呼ばれる概念があり、これは基本的にドキュメントを削除して置き換えることで、ええと、そのためにデータベース全体を再インデックス化する必要はありません。ええと、それは実際 Viss では馬鹿げています。viss について私が本当にクールだと思うことの1つは、ほとんど再インデックス化する必要がないということです。ええと、なぜならインデックスは非常に小さなセグメントのようなものに対してだけだからです。
データのセット全体を削除するような場合でない限り、再インデックスする理由はほとんどありません。また、unstructured、ええと、unstructured IO は、Haystack Ben Mils に調整される前にドキュメントを準備するのに面白そうですが、それについてどう思いますか？ありがとうございます。それについて話したいですか？話しますか、私たちはちょうどこれについて調べ始めたばかりなので、私にとっても非常に新しいものです。なので、確かな答えはできませんが、はい、私たちは全員で調べています。あなたにお知らせがあります。
ええと、今後数週間、私の LinkedIn で何が起こっているかに注目していてください。Novus で unstructured IO をどのように使えるかについて、何かをリリースする予定だからです。楽しみにしていて、見逃さないでください。ええと、Novus はハイブリッド検索をサポートしていますか？つまり、ファクター検索と BMM 25 のようなものを組み合わせるという意味ですか？ドメイン固有のテキストを扱うときには本当に役立ちますよね？私たちはネイティブには、ええと、BM 25 ハイブリッド検索をサポートしていません。ええと、しかし、テキストチャンクをメタデータとして内部に保存すれば、メタデータに対してキーワード検索ができ、それは本質的に同じことです。なので答えは、ええと、はい、メタデータをチャンクとして保存するだけです。ええと、テキストのチャンクをメタデータに保存して、ええと、それを通してフィルタリングします。
ええと、フィルタリングも本当に素晴らしいです。私たちが行うフィルタリングはビットマスクを使用しているので、ええと、これもまた計算コストが低いです。いいですね。チャットには他に何があるかな？ええと、QR コード、ソースコードへのリンク。ええと、わかりました。
私が見つけた課題の一つは、企業向けでは検索コストが法外になる可能性があるということでした。うんうん。プロンプトが OpenAI に送られる場合、代替手段は？Transformers to me？はい。ええと、はい。ええと、オープンソースのドキュメントを使うことができます。
これも私たちが G P T Cash を作った理由です。ですので、G P T Cash をチェックしてみることをおすすめします。ええと、基本的に私たちも同じ、同じ問題を抱えていて、「これは馬鹿げている。これにかなりのお金を払っている」と思ったので、ええと、それが G P T Cash を作った理由です。これはセマンティックキャッシュで、「もしこのクエリを以前に見たことがあるなら、キャッシュされたレスポンスを返せばいいのでは」というものです。私の顧客は、セキュリティ違反や機密性への懸念から OpenAI に反対します。
では open a p i のような lmm なしで検索 Rag はどのように実現できますか。そこについては、オープンソースの選択肢がますます増えてきていると思います。はい。ですので、それは間違いなく選択肢です。はい。ええと、私が示したすべて、このパイプラインも、ええと、Falcon four、tb、ええと、そして例えば Lama で試したものです。
なので、それらは間違いなく選択肢です。そして最初の点については、ええと、そこでは、ええと、コストについて話している場合、ええと、多くの前処理ステップが役立つことがあります。ええと、例えば、ええと、データをどのようにチャンク化するかを実験してみるとよいかもしれません。ええと、つまり関連ドキュメントを取得するときに、そこに入れるのは、ええと、500 行のファイル全体なのか、それとも最も関連性の高い、つまり、5 文を上部に入れるのか、どれくらい入れるのか、ということです。ええと、では q and a に戻りましょう。
テキストが2回見えたと思います。これは BMM 25 のフォローアップだと思います。ええと、これに対する答えは、ええと、いいえ、テキストは1回保存し、ベクトル埋め込みも1回保存します。実際のところ、あなたがここで何を尋ねているのかはよくわかりませんが、つまり、テキストを2回保存する必要はなく、1回だけ保存すればよいです。ええと、望むなら、テキストを SQL データベースに保存することもできます。
ええと、それはできないとは言いません。ええと、そしてまた、そうですね、それを参照して、必要ならクエリすることもできます。それはあなた次第です。私は、単にメタデータに保存して、ビットマスクフィルタリングを使うことをおすすめします。なぜなら高速で、簡単だからです。ええと、ソースデータが更新されたために embeddings を更新する必要がある場合はどうなりますか。
もしあなたが、何？ ええと、私は、これは実はちょっと、この質問にはニュアンスがあると思います。ええと、そしてそれは、インデックス化の、そうですね。パイプライン側の話に戻ってくると思います。はい。ええと、ソースデータに更新がある場合、ええと、ここで、元のものに使っていた同じインデックス化パイプラインを再利用することを検討します。
ええと、そして、私はまた、vis、ええと、あなたもこの機能があると言っていたと思います。なので haystack と並行して動作するでしょう。うんうん。ええと、ドキュメントを書き込むのではなく、ドキュメントを更新するという選択肢があります。つまり、サイトの変更がある同じファイルであれば、それを重複させるのではなく、単に更新するのです。そしてそれは単純な関数呼び出しです。はい。
ええと、これについての私の、私の私の考えは、ソースデータがどれだけ更新されたか、そしてそれで本当に何をする必要があるかによる、ということです。なので、データベース全体を変更するなら、そうですね、おそらく再埋め込みしたいでしょう。でもそうでなければ、たとえば小さな更新なら、私は、私はただすればいいと思いますし、それで、それで問題ありません。ええと、画像 C SS V P D F 動画の埋め込みにはどんな選択肢がありますか、ええと、画像については、私の提案はいつも resnet 50 です。ええと、C SS V P D F 動画。ここで、実際に誰かが unstructured io のようなものについて言及していました。彼らは、ええと、PDF に関して何かをやっていて、それが実際に私が彼らと一緒に取り組んでいることです。ええと、動画はもう少し難しいです。
CSB はもう少し難しいです。C SS V データを扱う人は本当にそれほど多くありません。CS V データを扱っていて、ええと、検索拡張生成をやりたい人たちに私が提案するのは、C S V データを完全な文に変換すべきだということです。そしてそれは、ええと、どんな種類のデータを扱っているにせよ、常に可能なはずです。そしてそれらの完全な文を取り、その文を sentence transformers のようなモデルを使って埋め込み、それから、ええと、それに対してクエリをかけることができます。
いいですね。では見てみましょう。ええと、はい、私たちは、あといくつか質問を受け付けます。このままもう少し開けておきます。ええと、たとえば、次に別の質問がある場合は、ええと、次の、ええと、30秒から1分以内に入力してみてください。そうすれば、私たちは、それに答えようとします。ええと、ああ、このコメント、オープンソースはまだ l として良くない、ああ、そうですね。
オープンソース LLMs は、ええと、G P T ほどの能力はありません。ええ、今のところ私は同意します。ええと、私の経験では、これは、これはそうでした。ただし、私が気づいたのは、あなたが言ったように、エージェントや、非常に、ええと、大規模言語モデルを使った複雑なアプリケーションの場合にそうだということです。ええと、多くの場合、単に質問に正確に答えたいのであれば、ええと、オープンソースモデルもかなり優れています。ええと、別の質問です。ええと、ソースデータをインデックス化して解析する際に、最高の rag パフォーマンスを得るための一般的なヒントはありますか？ そうですね、おそらく、まあ、context aware chunking または smart chunking と呼ばれるものがあります。これは、ええと、今多くの人が話しているもので、つまり、どうやって、どうやってデータを、意味のある適切なサイズのチャンクに分割するかということです。データが何についてのものかを理解できるだけの十分なコンテキストを保持し、同時にそれらを結びつけられるだけの十分なコンテキストも保持するように、です。ええと、これは解決済みの問題ではありません。まだ誰もこの問題を解決していません。
ええと、そしてそれは難しいです。ただ、チャンク化で私が一般的に見るのは、人々が 512 文字のチャンクに 25、ええと、文字のオーバーラップを使うというものです。これについて何か言いたいですか？ Tiana？ ええと、ソースデータをインデックス化して ing する際の一般的なヒント、ベストトラック。ええと、これは haystack の観点では興味深いものです。というのも実際、多くの場合、インデックス化パイプラインは、ええと、継続的に考え続けるタイプのパイプラインではないからです。ええと、私たちが見る多くのケースでは、インデックス化パイプラインは、ええと、一度実行され、ええと、データがあり、その上に rack パイプラインがある、という形です。ええと、パフォーマンスのベストプラクティスに関しては、私の経験では、特に前処理ステップについて話している場合、本当に考えるべきなのは、ええと、チャンクの長さをどれくらいにしたいかです。
そして、結局はこの、より経済的な側面の話に戻ってきます。大規模言語モデルが私たちの話していることを理解するのに十分な文脈を提供できるのか、そして、クローズドソースのモデルを使っている場合に、コンテキストサイズの制限や使いたい金額の範囲内に収まるほど短くできるのか、ということです。いいですね。ええと、私もまだLAMA twoは試していません。あ、ところで、Claudeは実際、皆さんがClaudeを使ったことがあるかどうか分かりませんが、Claudeは文章作成能力という点で興味深いです。このことについて何人かと話したのですが、ClaudeはGPTほどあなたの文章を編集しないようなので、ぜひ試してみて、どう思うか確認してみてください。
ええと、質問はもうなさそうですし、時間もそろそろなくなりそうなので、Emilyにお返しします。Eugene、本当にありがとうございました。ええと、Tawana、このウェビナーにご参加いただきありがとうございます。本当に素晴らしかったです。ええと、そして視聴者の皆さん、素晴らしい質問をたくさんありがとうございました。
ええと、今後のイベントで皆さんにお会いできることを願っています。ええと、サンフランシスコ地域にいらっしゃる方は、ええと、Tawanaが今夜、サンフランシスコのunstructured data meetupに参加します。ええと、ですので、このLのウェブサイトに来て、ええと、その詳細を確認するか、ええと、私たちのソーシャルチャンネルでご連絡ください。皆さん本当にありがとうございました。また次回お会いしましょう。
Meet the Speaker
Join the session for live Q&A with the speaker
Tuana Çelik
Lead Developer Advocate, Deepset
Tuana is a developer advocate at deepset, where she focuses on the open source NLP framework to build LLM applications: Haystack. With a degree in Computer Science from the University of Bristol, she started her career as a software engineer but then returned to the world of machine learning as a developer advocate and now dedicates her time to helping the open source NLP community.