Haystack と Milvus を使用したベクトル検索と自然言語で「夕食は何？」に答える
何を学べますか？
専属シェフが欲しいと思ったことはありませんか？「恋人関係とは、死ぬまでお互いに『夕食に何を食べたい？』と聞き続けることだ」というジョークを聞いたことがあるかもしれません。もちろん、オンラインでレシピを検索することもできますが、それが本当においしいかどうかは誰にもわかりません。そこでLLMの出番です！
このセッションでは、私のお気に入りの料理本レシピを集めたKaggleのデータセットを使い、データをMilvusベクトルデータベースインスタンスに取り込み、エージェント型のHaystack RAGパイプラインを構築して、自然言語でおいしいレシピを検索できるようにする方法を実演します。さらに一歩進めて、関数呼び出しを使い、材料でAmazonの買い物リストを作成する方法も紹介します。このセッションに参加して、RAGで現実世界の問題を解決し、昔からの問い「夕食は何？」に答える方法をご覧ください。
取り上げるトピック
- 現実世界のRAGアプリの構築方法
- Haystackの始め方
- Milvusへのデータ取り込み
はい、本日は、Haystack と vis を使用したベクトル検索と自然言語による「今日のディナーは何？」という本日のセッションをご紹介できてうれしく思います。そしてゲストスピーカーは Tilian です。Tilde はサンフランシスコを拠点とするアーティスト兼エンジニアです。日中は Deep Set でフリーかつオープンソースソフトウェアのアドボケートをしています。おそらくあなたよりもデッドリフトが強いでしょう。アルゴリズムをどう描くか、Mutual aid と生物学の交差点、あるいはどの海岸のヴィーガン・クロワッサンが一番おいしいかについて、ぜひ聞いてみてください。
ようこそ Tilde。こんにちは。温かいご紹介を本当にありがとうございます、Chrissy。お会いできてとてもうれしいです。では画面を共有して、始めていきましょう。
皆さん、スライドは見えていますか？よかったです。ええと、はい。オーケー、いいですね。チャットを見て、すべてに目を配れるようにします。ええ、先ほど紹介があった通り、私の名前は Tilda です。
私はサンフランシスコを拠点にしています。Deep Set で Haystack オープンソースフレームワークに携わるシニアデベロッパーアドボケートです。そしてサンフランシスコを拠点にしています。パワーリフティングとアート以外の私の関心は、驚くことにヴィーガン料理です。このウェビナーのタイトルからおそらくお分かりいただけると思います。今日はこれから、まず Haystack の簡単な概要をお話しします。コードのウォークスルーを理解するための文脈を持っていただくためです。VIS も紹介します。
えー、私が作ったアプリケーションをお見せして、その後に形式ばらない Q&A を行います。そして、これが皆さんのお役に立つものになることを心から願っています。ですので、質問があればぜひチャットに投稿してください。最後に取り上げます。ええと、ただ、皆さんの事前知識と現在の状況を少し把握するために、チャットで教えてください。ここで Haystack について以前に聞いたことがある方はいますか？いませんか。オーケー、完璧です。
最初から始めましょう。Haystack は、本番環境対応の大規模言語モデルアプリケーションを構築するためのオープンソースフレームワークです。つまり、皆さんのデータがどのような形式であっても、それを使いたい任意のモデルに接続できるようにしつつ、柔軟で使いやすいものにしています。Haystack の基本的な構成要素は、これからもう少し詳しくお話しする、パイプラインとコンポーネントです。そして、このウェビナーの後にスライドをお送りしますので、これらの参考資料を参照したい場合はできるようになります。
なので、この QR コードを慌ててスクリーンショットする必要はありません。ええと、私たちの商用提供である deep set cloud は、実は Haystack フレームワークの上に構築されています。さて、retrieval augmented generation について聞いたことがある方はどのくらいいますか？はい。いいですね。ええと、RAG の retrieval augmented generation は、現在大規模言語モデルの分野で非常に注目されています。知らない方のために簡単に言うと、大規模言語モデルに追加のコンテキストを与えることで、質問に対してより良く、より正確な回答を出せるようにすることです。
そして私はこの週末 picon に参加していたのですが、Haystack での RAG を 3 行のコードで示す、私が見つけられた中で最良の例がこれでした。基本的には、Haystack のウェブサイトである URL があり、質問があり、それを大規模言語モデルに渡して、提供されたドキュメントに基づいて Haystack が何であるかを説明する応答と、少しのメタデータを返してもらいます。ですから、これを実現するのに大量のコード行が必要ないというのは面白いところです。もちろん、物事はもっとかなり複雑になることもありますが。Haystack は実は 4 年前からあります。私たちは、自然言語処理がクールになる前から取り組んできました。ただし、2020 年にリリースされた当時は、semantic search、extractive question answering、table qa のような、当時より人気のあったユースケースに重点が置かれていました。
しかし 2022 年にすべてが変わりました。大規模言語モデルがメインストリームになり、RAG やエージェントをサポートしたいという人々のユースケースが爆発的に増え始めました。そこで私たちは一度立ち止まり、これらのユースケースをよりよくサポートするためにフレームワークを再設計することにしました。そして 3 月に Haystack 2.0 をリリースしました。これは、最近の人々が AI アプリを書く方法により焦点を当てているだけでなく、より柔軟で拡張性が高く、より優れた開発者体験を備えています。
そして、Haystack の機能について十分な概要をお伝えするので、うまくいけばコードデモを理解できるはずです。ですので、前に述べたように、パイプラインは Haystack の構成要素の 1 つです。これは、LLM アプリケーション内でデータが流れる経路を定義できる強力な抽象化です。これはグラフです。すべてはグラフです。
あなたにはグラフがあり、あなたにもグラフがあります。そして、ええと、このグラフ内のノードはいわばコンポーネントと呼ばれます。そして、パイプライン内でコンポーネントをどのように配置するか、またデータがそれらをどのように通過するかについて、完全な柔軟性があります。さて、このコードは先ほどお見せしたものより少し複雑な例ですが、これからお見せするデモに似たものになります。では説明していきます。
ここには、Python オブジェクトのようなパイプラインがあります。これをインスタンス化し、いくつかのコンポーネントを追加しています。これは、ドキュメントストアからドキュメントを取得する retriever、そして prompt builder で、大規模言語モデルに送信されるプロンプトを構築します。これらを接続して、コンポーネントが実行される順序を指定し、それからいくつかの引数を渡すことで、実際にパイプラインを実行できるようにします。また Haystack には、パイプラインを描画するためのユーティリティも含まれていて、これは便利です。なぜなら、パイプラインの流れのロジックは実際かなり複雑になり得るからです。たとえば、パイプラインは分岐をサポートしています。
では、rag パイプラインを実行したいとして、ハイブリッド検索と呼ばれるものを行いたいとします。これは、クエリに関連するドキュメントを見つけるために、キーワードベースの検索と埋め込みベースの検索の両方を使用する方法です。この 2 つを組み合わせることで、どちらか一方だけの場合よりも良い結果が得られることがあるからです。Haystack では、分岐させて、document joiner コンポーネントで結果を再び結合し、それから、まあ ranker を使ってどの結果が最適かを判断できます。Haystack は条件付きルーティングもサポートしています。データベース内で答えを探したい rag パイプラインがあり、もし見つからなければ、Web や Slack、Notion、その他のデータソースを検索したいとします。
その場合も対応できます。パイプラインにはループを含めることもでき、これは、検証が必要で特定の形を含む構造化出力のような出力を生成したい場合に非常に便利です。私の同僚が作ったデモでは、会議メモを受け取り、ループするパイプラインによって、ええと、GitHub IPI に送信して issue を作成できる API 呼び出しを生成します。会議メモから issue を書き起こして GitHub に入れるのは、私にとってあまり好きな作業ではないからです。皆さんはどうかわかりませんが。なので非常に便利です。
そして最後に、ええと、今日話している内容に関連するものとして、エージェントパイプラインがあります。エージェントはサードパーティ関数を呼び出して外部に出て他のことをしたり、天気がどうかを尋ねるような判断をしたり、ええと、レシピを組み立てる手助けをしたりできます。これが実際にはどのように見えるのか、例をお見せするのが楽しみです。さて Hayek はまた、検索から返されたデータが大規模言語モデルにどのように渡されるかについても、多くの柔軟性を提供します。というのも、私たちは Ginger two というテンプレート言語を使っており、そこにはループや条件分岐があるからです。
そのため、プロンプトが正確にどのように見えるかを本当に細かく指定できます。そしてこのプロンプトテンプレートも、Haystack パイプライン内のもう 1 つのコンポーネントにすぎません。コンポーネントといえば、先ほど述べたように、それらはパイプラインの構成要素です。グラフ内のノードです。Haystack は、ドキュメントストアからドキュメントを取得する、前処理を行う、空白を削除する、テキストを要約する、あるいは先ほどお見せしたような条件付きの、ええと、分岐パイプラインの一部のようにクエリをブラウニングする、といった一般的なタスク向けに、大量のコンポーネントを標準で提供しています。
しかし、標準搭載のコンポーネントに加えて、ほんの数行のコードで独自のカスタムコンポーネントを書くこともできます。さて、本当に必要なのは Python クラスで、デコレーターがあって、このコンポーネント、このパイプが期待する入力と出力が何なのかを知りたいわけです。そうすることでパイプラインをシリアライズできます。そして、実際にそのコンポーネントを実行するためにどんな引数が必要なのか、ということですね。実際にはどんな感じになるのか、例をお見せします。Gina AI の友人たちが、haystack パイプラインを使って Jira チケットを重複排除する方法についてブログ記事を書きました。というのも、誰だって課題やバグを報告して、よい市民として振る舞っているつもりだったのに、あとで「あ、いや、もう誰かがこれを報告してた、すみません」となることがありますよね。
ええと、このカスタムコンポーネントですが、コンポーネントは理想的には 1 つの仕事だけを持つべきです。これは単に、キーを重複排除しているだけです。なので、そのあたりについてもう少し詳しく知りたい場合は、彼らのブログ記事を確認できます。そこではプロジェクト全体をどのように構築したかが説明されています。さて、haystack のより一般的な機能についてですが、haystack はモデルにもデータベースにも依存しません。なぜなら、皆さんが持っているどんなデータソースでも、使いたいどんなモデルでもサポートできるようにしたいからです。そして、追加のデータベースや追加のデータソースも取り込めるようにしたいのです。
RAG はベクトルデータベースだけを意味するわけではありません。Web は豊かなコンテンツのソースですし、API があるなら、Web 上に存在するなら、haystack はそれをパイプラインに取り込む手助けができます。haystack の中核は、軽量で柔軟なライブラリのようなものを意図していますが、機能を拡張するための拡張機能や統合が数多くあります。たとえば、モデルやベクトルデータベースをサポートする拡張機能に加えて、トレーシングやモニタリング、そしてアプリを本番環境に持っていくために必要なものすべてが含まれています。こちらの友人たちがメンテナンスしている VIS 統合も含まれます。では vus についてですが、これは高いスケーラビリティを目的として設計されたオープンソースのベクトルデータベースであり、ベクトルデータベースは非構造化データの管理と取得のために設計された特殊なシステムです。セマンティックな類似性検索に優れており、そのため大規模言語モデルを使ったアプリケーションの作成に非常に適しています。特に、大量のデータを対象に処理する場合にはそうです。ええと、Christie、何か抜けていますか？私はベクトルデータベースの専門家ではないので、追加の内容を補足してもらいたいと思いました。
ああ、それはいいですね。はい、私はたいてい、ベクトルを保存し、インデックス化し、検索することについて話すだけです。いいですね。では、これのライブデモをやってみましょう。
Regener アプリケーションとは何でしょうか？でもまず、ええと、私はこのプロジェクトを始めたとき Kaggle データセットを使おうと思っていましたが、実際に見てみると、「ああ、これには私のお気に入りの料理本のレシピデータは実際には含まれていないんだ」となりました。実際にはあまり役に立たないメタデータだけだったんです。でも大丈夫です。先ほど述べたように、haystack はデータをアプリケーションに取り込む方法において非常に柔軟だからです。そして、私が書いたコードはそれを実現するためにいくつかの異なる形式を使っていますが、説明するより見せたほうが簡単です。なので、今からエディターに移ります。
ええと、フォントサイズはどうですか？もう少し大きいほうがいいと思います。もう少し大きく。いいですね。これでいいですか？はい、いいです。ありがとう。
素晴らしい。いいですね。では、まず Melva document store に接続しています。というのも、これを 1 つのインスタンスとして、さまざまなコンポーネント間で受け渡しできるようにしたかったからです。そしてこれは私のローカルマシン上の Docker コンテナで実行されています。あ、失礼。
それで、私が最初に実行したパイプラインは、ええと、インデックス作成パイプラインでした。インデックス作成パイプラインはデータを取り込みます。ええと、そして多くの人と同じように、私はいつも最も整理整頓された人間というわけではないので、書いたレシピが3つあるのですが、ああ困ったことに、それらは別々のファイル形式になっています。というのも、それらを書いたときにパイプラインに取り込むことを考えていなかったからです。でも大丈夫です。haystack は、これらのレシピがどんな種類であっても受け取り、実際にドキュメントストアに取り込むことができるからです。そして、それがどのように行われるのかを正確にお見せします。では、ええと、最初のコンポーネントはファイルタイプルーターで、さまざまな種類のファイルを受け取り、どの種類を受け付けるかを指定します。そして各ファイルタイプ、つまりテキスト、Markdown、PDF は、それぞれコンバーターコンポーネントを受け取り、それを haystack ドキュメントに変換します。
それからドキュメントジョイナーがあり、これはこの3つの分岐を1つにして、すべての結果を結合するようなものです。ドキュメントを前処理するときはいつでも、クリーンアップして、空白を削除して、そういった楽しいことを全部やりたいわけです。そしてそれから、それらをチャンクに分割したいです。ええと、ドキュメントの種類や、テキストのチャンクがどのくらい長くなりがちかによって、単語単位または段落単位で分割できます。レシピには、150語くらいが良いサイズだと思いました。ええと、そして50のオーバーラップを入れて、見落としがないようにしています。
それから、この sentence transformers document embedder を使って、実際にそれらのドキュメントをベクトルにします。この、ええと、このモデルを使います。これは私のローカルマシン上で問題を起こさずに実行できるくらい軽量です。そしてそれらを Melva ドキュメントストアに書き込みたいわけです。そこで haystack パイプラインを作り、これらすべてのコンポーネントをパイプラインに追加する必要があります。そして connect メソッドを使って、どのコンポーネントが次のコンポーネントにつながっているかを指定し、どの順番で実行すればよいか分かるようにします。そしてこちらでは単に、「ねえ、これらのファイルはここにあります。ええと、ファイルタイプルーターにこれらすべてのファイルを入力するよう指定して、パイプラインを実行します」と言っているだけです。
ではこちらに移って、Python、ええと、pre-processing と入力して、うまくいくことを願います。よし。で、このエラーが出ています。今朝からこのエラーが出始めたのですが、実際には関係のない副作用だと思います。というのも、ご覧のとおり、データベースにはまだ6つの、ええと、ファイルがあるからです。なので気にしないことにします。でも、ええと、すみません。
それでは次に、ええと、この rag パイプラインがあります。これは実際に、ええと、ドキュメントストアにクエリを投げる方法を示してくれます。プロンプトがあります。これは、与えられたコンテキストに基づいて質問に答える、というようなものです。提供されたドキュメントをループし、また質問も大規模言語モデルに渡します。そして、以前使ったものとかなり似た API です。ええと、rag パイプラインがあり、embed を追加します。ここで重要なのは、これらの埋め込みを作成するのに使っていたものと同じモデルを使っていることです。
ええと、ドキュメントストアがあります。これは同じドキュメントストアのインスタンスです。ええと、プロンプトビルダーがあります。これはこれを受け取って、それからパイプラインが理解できるプロンプトにします。そして大規模言語モデルがあります。ここでは open AI generator を使っていますが、先ほど述べたように、haystack は柔軟で、心が望む主要なモデルのどれでも使うことができます。そこでこれらすべてを接続します。そして質問を渡してみましょう。それは、これら3つのレシピすべてを作るにはどんな材料が必要ですか？ というものです。ではこちらに移って実行します。
さて、返答は、keto eggplant、lasagna flan、hemp cheese を作るために、となっています。そして実際にすべてのレシピをリストしているように見えます。これらのレシピは私固有のものですよね。これはウェブ上には存在しないので、大規模言語モデルが事前知識を使っているのではなく、実際に私たちが提供した入力を使っているのだと分かります。これはかなりクールです。ただ先ほども言ったように、私は世界で最も多作な、ええと、料理本著者ではありません。他にもたくさん趣味がありますし、いろいろやることがあります。
それで、追加データも加えたいと思いました。ええと、Web からデータを取得する別のインデックス pipelinethat があります。これは以前使った Index Pipeline とそれほど違いません。ええと、ただし haystack link content vet を使っています。これは私たちが提供しているコンポーネントで、URL を受け取り、その URL を haystack documents に変換してくれるので、自分で scraper を書いてスクレイピングし、何が重要かを判断する必要がありません。ええと、それで at TML を documents に変換する converter も必要で、前と同じように、writer と、以前使っていた同じ model を使う embed が必要です。ええと、ここで使っている URL は実は、cookbook、私のお気に入りの cookbook、Issa ch Chandre Moscowitz の Vegan Omicron で、彼女はたくさんのレシピを online に公開していて、レシピは法的に著作権で保護することができません。
豆知識です。だからそれらは全部、冒頭で「私の hubby と私の dog はこのレシピが嫌いでした」みたいな話から始まるんです。そんなの誰も求めていないですよね？ でもこれを使えば、それを避けられます。ええと、それでこの URL のリストを indexing pipeline に渡しました。では実行してみましょう。うーん。ええと、web index pipeline。
これも大きくしますね。そのほうが読みやすいと思います。ああ、いいですね。そんなことできるって知りませんでした。はい、すみません。
ええと、はい、いいですね。これでできました。それから、ええと、ここで私がやったことなんですが、ここからが本当に面白くなりますよね？ 別の rag pipeline を作ることにしました。元の rag pipeline を使うこともできたのですが、少し凝ったことをしたかったんです。ええと、なぜなら、簡単に function にラップして tool として提供できる pipeline を作りたかったからです。そうすれば、他の、ええと、他の pipelines が実際にこの function を呼び出して、「ねえ、vegan shelf chef、レシピを書くのを手伝って」と言えるようになります。
それで、ええと、standalone として動くように小さな wrapper を追加しました。では、それが動作することを証明するために chef pipelinescript を実行してみましょう。buffalo wings と lasagna bolonese について尋ねています。これはここにあるレシピの一部で、ええと、pipeline に取り込んだものです。これは Chef Pipeline です。あは。
buffalo wings を作るには、14 ounce の extra firm tofu salt が必要です。ああ、これはお腹が空いてきますね。ええと、こちらはまだかなり朝早いのですが、でも私は基本的にいつもお腹が空いています。ええと、でも繰り返しますが、もし単に OpenAI に buffalo wings の作り方を尋ねたら、確実に肉を含む回答が返ってくるはずですが、これはそうではありません。なので、これが想定どおり document store から取得されていることがわかります。
では、この function をラップするために実際に tools を使っている箇所を見てみましょう。ええと、chef pipeline を、それを定義した file から import し、それから ask a vegan chef という function を作りました。基本的には、ええと、いくつかの arguments を使って pipeline を実行するだけです。それは JSON のようなもので、渡している query があり、response を print しています。これは単に、私がものを print するのが好きだからで、自分の code が少なくとも何かしていることを確認したいんです。そうしないと、ただそこに座ってパニックになってしまうので。ええと、それから open a API、いやすみません、open ai では、自分の function を tool として提供するために、従う必要がある JSO spec が用意されています。なので、この tool の type は何かを指定する必要があります。これは function です。
function には name があり、description があり、parameters がいくつかあります。query を受け取り、それは string で、それを説明します。ええと、そしてそれは required parameter です。現在、大規模言語モデルを呼び出す方法は大きく分けて 2 つあります。ひとつは generation で、これは basic rag pipelines でやっていたことです。
単に prompt を渡すだけです。でも実際には、すべての大規模言語モデルは chat completion, API の方向に移行しつつあります。これは agent に近いものです。ええと、なのでここでは agentic な、ええと、chat message を行います。「ねえ、この message は system からのものです。あなたは有用で知識豊富な agent で、自分専用の vegan chef にアクセスできます。すごくないですか？ そして vegan recipes について尋ねてください」と言います。
そしてユーザーが、「バッファローウィングとラザニア・ボロネーゼを作るにはどんな材料が必要ですか？」と言います。そしてここでも、OpenAIのチャットジェネレーターにはHaystackのラッパーを使っています。ええと、これにはAPIキーが必要で、私はそれを環境変数に保存しています。なぜなら、皆さんのことは好きですし、きっと皆さんとてもクールで信頼できる人たちだと思いますが、まだそこまでよく知っているわけではないからです。ではここで、実際にこの関数を呼び出して、どんなチャットメッセージが生成されるか見てみましょう。Python tools piを実行してみます、ああ。キーエラーが出ました。何か削除しましたっけ？ ええと、しまった。
うーん。興味深いですね。利用可能な関数、関数名。ここにタイプミスがある場所が本当に見当たりません。できました。
何も変更していません。見ていましたよね。私、おかしくないですよね？まあ、誰にも分かりませんよね？コンピューターですからね。ええと、とにかく、大規模言語モデルからメッセージが返ってきて、バッファローウィングを作るには、必要な材料はこれです、というように自然言語で説明してくれています。そして、ええと、以前受け取った応答とは少し違います。英語で少し多めの文脈を与えてくれていて、それはいいですね。
そして、ええと、私が進められたのは本当にここまでです。ええと、では少し止まって、どんな質問があるか見てみます。ここからはもっと会話形式で進めていけます。素晴らしいです、ありがとうTilda。ええと、あなたのエージェントでは関数が1つだけに見えました。それに複数の関数を追加することはできますか？はい、できると思います。ええと、たとえば、材料だけを取得する関数があったらどうでしょう？レシピのアイデアを提案する関数があったらどうでしょう？あるいは、買い物リストをメールで送ってくれるような連携があるといいですね。そうすればアプリケーションからそれを取り出す必要がありません。
そうですね。ええと、それはよさそうです。わかりました。チャットに質問があります。ええと、Nicole Nikolaiさんが、大量のファイルを扱うための戦略をおすすめできますか？たとえば、イタリア料理のレシピ、フランス料理のレシピ、などがあるとします。
うーん。はい。ファイルがたくさんある場合、メタデータのラベル付けは非常に重要です。そうすれば、検索するときに、たとえば「イタリア料理のレシピではないファイルを除外したい」と言えます。ええと、ですので、繰り返しになりますが、最初の段階で少し考えて、ファイルに必要なメタデータが含まれていることを確認しておくと、後で検索したいときに、ええと、頭痛の種を減らせます。
あるいは特に日付ですね。多くの場合、人々は新しさでフィルタリングしたり、再ランク付けしたりしたいものです。ですので、それもサポートすべき素晴らしいメタデータの一つになり得ます。質問への答えになっていますか？はい。それから、また、ええと、vissはベクトルデータベースです。ええと、ベクトルを除くすべてのフィールドはメタデータと呼んでおり、メタデータによるフィルタリングはvissでの検索で可能です。
ええと、素晴らしいです。ここにいるデータベースオタクとしては、私は、ええと、たぶんそこにあったのだと思いますが、あなたがvisの呼び出しをしていたときに、私の目が見落としたのだと思います。どの、ええと、ベクトル、ええと、ベクトルデータベースのインデックスを使っていたのか見えませんでした。ええと、OpenAI functionsはREST APIを呼び出せます。ええと、はい、私たちはHaystackの中でOpenAI APIをラップして、それをより簡単に使えるようにしているだけです。
でも、はい、基本的にはクラウドからそれらのモデルを呼び出しているだけです。ええと、わかりました。おそらく、そこには何らかのデフォルト設定があるのでしょう。なぜなら、DAインデックスとデータベースはデータ構造を指していて、クラスタリングや、ええと、ツリーのような異なるデータ構造があるからです。ええと、なので、把握するにはあなたのコードを見る必要がありそうです。はい、お見せできます。
ええと、私はあなたのドキュメントにあるデフォルト設定を使っただけで、始めるのがとても簡単でした。なので、ええと、これが参考になるなら、私が使ったのはこれです。ああ、それならおそらく、ええと、私たちのauto indexを使っていて、それはデフォルトでHNSWになります。わかりました。質問があります。はい。
ええと、far beyondさんが、OpenAI functionsはREST APIを呼び出せるのか、と質問しています。はい、それが質問です。はい。はい。ええと、Haystackについて触れましたが、HaystackのジェネレーターはOpen API呼び出しのラッパーのようなものです。
ええと、つまり、あなたの環境でOpenAIキーを環境変数として保存している限り、ええと、こちらでバックグラウンドでそのシークレットの受け渡しを処理します。それに、OpenAIだけではありませんよね？ Anthropic、Claude、Mixed Mixtureのような主要なモデルプロバイダーのどれでも使えます。Llamaでローカルモデルを実行することもできます。本当にかなり柔軟です。というのも、ええと、モデルはまさに軍拡競争の中にあり、私たちは、皆さんの具体的なユースケースに最も合うものをサポートしたいからです。どのモデルがサポートされているかは、どこで見られますか？ ああ、それはHaystackのドキュメントでお見せできます。
おっと、画面共有を止めますね。ええと、私たちのドキュメントはかなり包括的で、ええと、generatorsを見ると、これが実際にどのように機能するのかを説明するガイドがあります。ええと、generatorsとchat generatorsの違いですね。先ほど少しお見せしたものです。たとえば、generation APIとchat completionの違いがあって、chat completionはより多くのパラメータを渡す必要があり、ええと、その代わりによりエージェントらしい応答を返してくれます。そして、こちらがサポートしているすべてのモデルです。AWS Bedrock、Azure、Cohere、Gradient、Hugging Face上の多数のモデルなどです。
ええと、はい。なので、かなり広範なリストです。うん、良い質問ですね。では、Haystackがサポートしている他のエージェント、他のエージェントタイプはありますか？ ええと、エージェントタイプという意味では、私たちのエージェント機能はまだ現在構築中です。ええと、エージェントでできることとして、今日は全部はお見せしませんでしたが、function calling、これはtoolsでデモしましたね、それからrouting、fallbacks、つまり、回答が得られない場合にどうするか、looping、そして構造化された出力の生成などがあります。
ただ、まだないものでロードマップにあるのが、memoryのサポートです。これは本当に重要なものです。たとえば、行ったり来たりする会話型の対話を本当に実現したいなら、ええと、それをサポートする必要があります。なので、これは今四半期のロードマップにあります。ええと、multi-agentのサポートもあります。これもかなりホットですね。そして、全体的な開発者体験が理にかなったものになるようにすることです。なので、ええと、私たちはオープンソースなので、ロードマップはGitHubで公開されていて、それを確認すれば、それに対してどのように進捗しているかを見ることができます。これで質問の答えになっていますか？ はい。
はい、どのようなエージェント的な機能があるのか気になっていました。ええと、私たち、そうですね、実はあなたに少し個人的な質問があるかもしれません。先日、私たちのvis、ええと、meetupで登壇者がいて、オープンソースのmemory systemを作っていました。ええと、memory systemについて、オープンソースとクローズドソースに関してどうお考えですか？ ああ、難しいですね。ええと、または一般的にでもいいのですが、そこにはたくさんのgeneratorsがあることに気づきました。オープンソースのものもクローズドソースのものもありますよね。ええと、まあ、generators自体はすべて、API用のwrapperのようなものです。
ですから、それらはすべてオープンで、generators自体、wrapper classesはオープンソースです。はい、クローズドソースのモデルを呼び出すことはありますが、これはニュアンスのある質問ですよね。なぜなら、モデルをオープンソース化する人たちの中には、たくさんのweightsを公開して、「はいどうぞ」と言うだけで、実際に自分でモデルを構築して実行する方法についての本当の手順や文脈がほとんどない場合もあるからです。つまり、オープンソースは二値ではなく、グラデーションなのです。ええと、なので私は個人的には、Deep Setに入る前は、ええと、オープンソースエディターのAtomに取り組んでいました。なので、私はpublicに作業し、自分の作業を見せ、人々が貢献できるようにすることには非常に前向きです。ただし、それは、これがどのようにビジネス戦略を支えるのか、そして、ええと、あなたとコミュニティが同じ認識でいるようにするための感情的な労力を誰が担うのか、といったこととのバランスを取る必要があります。でもHaystackでは、定期的なoffice hoursを開催していて、たとえばevaluationのような新機能を作るときには、コミュニティに参加して意見を出してもらい、場合によってはその時間に対して報酬を支払うこともあります。そうすることで、コミュニティが何よりもまず私たちのプロダクトの支持者であり、利用者であることを本当に確実にしたいのです。
ですから、私たちはあなたにとって最も効果的なものを作っています。ええと、とはいえ、AIは急速に変化するエコシステムでありランドスケープで、時にはよりクローズドソースなものをサポートしなければならないこともあります。なぜなら、それが皆が使っているという一般的なコンセンサスだからで、私たちとしても自分たちのプロダクトを有用なものにしたいからです。なので、ソースについてただ取り留めなく話してしまった気がします。はい。私の意見です。
意味は通じていますか？あなたの質問に答えられていますか？ええ、たぶん。ええと、これは、これは私にとって、私自身にとってはとても素朴な質問です。ええと、他の人も疑問に思っていたかもしれません。つまり、インテグレーターという観点では、Lang Chainについては知っていますし、LAMA Indexについても知っています。Haystackを自分にとっての別の選択肢として考えるべきでしょうか？オープンソースの、インテグレーターおよびインテグレーター向けの別のオープンソースの選択肢として？はい。
それはまさに私たちが自分たちを位置づけているカテゴリですし、各フレームワークにはそれぞれ異なる強みと弱みがありますよね？たとえば、Lang Chainには巨大なコミュニティがあり、始めるのがとても簡単です。でも、Lang Chainについて聞く不満としては、「このチュートリアルは3週間前のものなのに、もう壊れている」といったものがあります。一方でHaystackには、後方互換性とリソースを維持してきた歴史があり、たとえば非推奨ポリシーを明確に定めています。私たちは、あなたのアプリを本番運用可能にし、少しでも安定させるための機能を提供したいと強く考えています。ええと、そしてLAMA Indexは本当にデータ処理の部分に重点を置いています。なので、両方を使いたい場合に備えて、HaystackとLAMA Indexの間には統合も用意しています。
ああ、それは興味深いですね。はい。はい。つまり、ええと、同時に協力者であり競合でもあり得るということですね。でも、はい、どれも優れたツールです。私たちは皆、似たような問題を解決していて、その問題をどう捉えるかというアプローチが少しずつ違うだけです。
そうですね。参加している人は見えていますが、質問は見当たりません。Haystackの、ええと、LLMジェネレーターとチャット補完に対する見解についてのドキュメントを読んでみます。それは興味深いニュアンスですね。はい。
プロバイダーと言いましたか？はい。はい。モデルプロバイダーは、たぶん人々をある種のジェネレーターからチャット補完のほうへ移行させようとしているのだと思います。というのも、それによって少し柔軟性が増すからだと思います。これは私の見解ですよ？OpenAIに電話して、広報部門に私の答えをチェックしてもらったわけではありません。ええと、でもこれについての私個人の意見としては、ええと、システムからチャットメッセージを生成できますよね？それによって、AIに言葉を押しつけるようなことがずっと難しくなります。つまり、彼らは、優れたユーザー体験になり、自分たちが提供したいものと一貫した応答を生成していることを保証するうえで、少しだけより多くのコントロールを持てるわけです。ええと、それに皆エージェントを求めているように見えますよね？今では、人々がLLMを使う主要なモデルとして、チャットに落ち着いたように見えます。
そして、それによって、その種の体験を生み出すためのツールが少し増えるわけです。ですから、これがなぜ行われている変更なのかについての私の意見です。でも、ええと、いつかイベントでOpenAIの人に会うことがあれば、これをちょっと話してみて、私に同意するかどうか聞いてみたいですね。あ、質問があります。ええと、仮想的なシナリオとして、Rag PipelineとHaystackを使っている場合、パイプラインは、これらのステップを順番に実行するのではなく、最初のクエリの生成ステップを処理する前に、2番目のクエリの検索ステップを開始できますか？ええと、はい、2番目のクエリの結果が最初のクエリの結果に依存しない限り、間違いなく可能です。
ええと、複数の異なるクエリステップがあるパイプラインを作りました。そこでは、ええと、私たちは、ええと、LLM、つまりPubMedから論文を取得する医療チャットボットを作ったのですが、最初のクエリでは、ええと、その質問を受け取り、それをPubMedの検索に使えるキーワードのようなクエリに変換します。なぜなら彼らのAPIは自然言語ではなくキーワードを受け取り、いくつかの論文を返すからです。そしてその論文を大規模言語モデルに返して、自然言語で回答を生成できるようにします。なので、はい、ユースケースに応じて複数のステップでLLMを呼び出す複数ステップのパイプラインを持つことができます。でも、ええと、それで質問の答えになっていますか？それと、ええと、何を作っているのか、知りたいです。興味が湧いてきました。あ、できると思います、見てみます、はい、できました。Alex、ミュートを解除しましたので、何か話したいことがあればどうぞ。
ええと、こんにちは、ええと、私はちょうど、ええと、hey Tech がどのように動作するのかを調べていました。ええと、もちろんパイプラインをデプロイすると、複数のクエリ、複数の、複数の、ええと、ユーザーが同時にそれを使おうとします。そして、ええと、通常、ええと、パイプラインは、ええと、ええと、検索ステップでも、ええと、生成ステップでもある程度時間がかかります。そして、次のステップの検索ステップを開始する前に、生成ステップの終了を待つ理由はありません。なので、ええと、私は、クエリが独立している場合に、それらが逐次的に実行されないようにする何らかの方法を探していました。ああ、つまり異なるクエリを並列で実行できるようにしたいということですか？ええと、はい。
または、ええと、ただ、ただ少なくともリクエストを、ええと、同期的に送るというか。はい、asyncサポートは予定されています。ええと、それもQ2のロードマップに入っています。まだ構築はしていません。ええと、なので詳細をお待ちください。コミュニティが望んでいる機能なので、できれば近いうちに出せる予定です。
同意します。本当に重要ですし、まだそのサポートは十分にありませんので。わかりました。ありがとうございます。ええと、Rishiからの質問です。HaystackはLlama Indexとどう組み合わせられますか？ええと、はい、Llama Indexはどちらかというとデータ処理に重点を置いています。
そのための機能がかなり多くあります。ええと、Llama Indexには、JavaScript SDKのようなものもありますが、私たちにはありません。なので、ええと、ただどちらも素晴らしいフレームワークですし、実際にLlama IndexとのHaystackインテグレーションもあり、両方を使いたい場合に利用できます。なので、ええと、それらはある意味、ええと、私たちのほうが、アプリを本番環境に持っていくためのツールに少し重点を置いていると思います。Llama Indexよりも。なので、ええと、長所と短所はありますが、でも、はい、正直どちらも本当にしっかりしたプロダクトです。
ええと、見てみましょう。では、これ以上質問がなければ、あ、わかりました。さらに質問があります。Jimがチャットで質問しています。いくつかのパイプラインをデモしましたが、それぞれのパイプラインは独自のWebサービスとしてデプロイされるのでしょうか？はい。
ええと、データを取り込むインデックス作成パイプラインは、たとえば、IO boundであることと、ええと、CPU boundであることなどの点で、少し異なるニーズがあります。ですので、すべてのパイプラインに同じ設定を使いたいわけではありません。ただし、Hay Hooksというパッケージがあり、Fast APIを使って個々のHaystackパイプラインを、ええと、Kubernetes経由でデプロイするのを支援します。そして、ええと、それらのAPI、ええと、エンドポイントを公開します。もう少し詳しい情報があるドキュメントを案内できます。万能のデプロイメントガイドのようなものは用意できません。なぜなら、ええと、それはパイプラインが何をしているかに大きく依存するからです。ただ、少なくとも適切な方向で始められるような資料はいくつか用意しています。
ありがとうございます。素晴らしい質問です。皆さんがこんなに積極的に参加してくださって感謝します。もし始めたい人がいる場合、通常おすすめする場所、最適な場所はありますか？はい。ええと、私たちのWebサイトには、ええと、もう一度画面を共有します。
はい。私たちのウェブサイトにはたくさんのチュートリアルがあり、それらは単にColabノートブックで、レンダリングされていて、すぐに実行したり試したりできます。ええと、YouTubeには説明動画もあります。もしそれがあなたの学び方なら。ええと、定期的なミートアップもありますし、サポートを受けられるDiscordサーバーもありますし、GitHubで私たちのコードを読むこともできます。ですので、あなたの好みの学習方法に応じて、始める方法はたくさんあります。でも、そうですね、私たちのドキュメントにはかなり力を入れています。
ですので、まずは私たちのウェブサイトをいろいろ見て回って、自分に響くものを探してみるといいと思います。そのミートアップはオンラインですか、それとも対面ですか？両方です。あなたはどちらにお住まいですか？ええと、私はサンフランシスコにいますが、Deep Setはヨーロッパ全体に分散しています。なので、この数か月でピッツバーグ、サンフランシスコ、ロンドン、ベルリンでミートアップを開催しました。ええと、Lumaカレンダーにも登録していただければ、また、そうですね、いくつかのオンラインミートアップやウェビナーもありますので、カレンダーに登録しておけば、次に何を計画しているかを把握できます。
わかりました。では、これでだいたい終わりのようですね。ええと、もしさらに質問したい方がいれば、もう1分だけ待ちます。そうでなければ、これで締めたいと思います。では、本当にありがとうございました。
皆さん、とても素敵な聴衆でした。ええと、質問があれば、ぜひご連絡ください。またお会いできるのを楽しみにしています。あ、もう1つ質問がありますか？待ってください、Q&Aエリアに何か見えます。イベントありがとうございました。ああ、ありがとうございます。いえいえ、どういたしまして。
はい。ええと、今朝は皆さんとお話しできて素晴らしかったです。残りの一日も良い時間をお過ごしください。また近いうちにお話しできることを願っています。ありがとうございます。さようなら。
Join the Webinar
Loading...
Meet the Speaker
Join the session for live Q&A with the speaker
Tilde Thurium
Senior Developer Advocate at deepset
Tilde (they/them) is a San Francisco based artist and engineer. By day they are a free and open source software advocate at deepset. They can probably deadlift more than you. Ask them about how to paint an algorithm, the intersections between mutual aid and biology, or which coast has the best vegan croissants.