You’re in!
ウェビナー
ベクトル検索の未来とは？HNSWの著者Yury Malkovとの炉端談話
はい。ちょうど開始の時間になりました。えー、皆さん、おはようございます、こんにちは、そしてこんばんは。本日のセッションにご参加いただき、本当にありがとうございます。Vector search の未来とは？ H N S W の著者 Yuri Malka との fireside chat です。
私は Emily kk で、ここ Zillows のチームの一員です。いくつか簡単な連絡事項をお伝えしてから、すぐにセッションに入りたいと思います。まず、このウェビナーは録画されていますので、途中で退出しなければならない場合でも、数日以内に、できればもっと早く、オンデマンド版にアクセスできるようになります。えー、ご質問がある場合は、画面下部の q and a ツールに貼り付けてください。
えー、チャットウィンドウを使うこともできます。私たちにとっては少し追跡しにくいので、その QA ツールを使っていただけると大変助かります。えー、それから、とても素晴らしい今後のイベントがいくつかあります、えー、画面が消えてしまいました。あ、出ました。えー、素晴らしい今後のイベントがありますので、zillows でぜひチェックしてください。
com/event。えー、それについては追加情報をお送りします。えー、それから、もしまだであれば、えー、私たちのコミュニティに参加していただけると、えー、その後も会話を続けられればと思います。それでは早速、本日のセッションに入りましょう。本日のセッションを改めてご紹介できることを嬉しく思います。Vector search の未来とは、h and s w の著者 Yuri Malkoff との fireside chat です。えー、そしてゲストスピーカーの、えー、Yuri は Adverse Innovation の Distinguished Engineer であり、現在、1億人を超えるユーザーに提供される重要なレコメンダーシステムを開発しています。
2000 件の引用を誇る研究を発表しており、SPAN cv、LLMs reus、そして Similarity Search では、Hand S W や learnable triangulation のような広く認知されたオープンソースソリューションを取り上げています。Yuri の専門的関心は、高度にスケーラブルなコンテンツ機械学習システムの構築に及びます。Yuri に加えて、同僚の Frank Lu、えー、ML architect であり、ここ Zillows の director of ops も参加しています。ようこそ、URI、Frank。紹介ありがとうございます、Emily。
えー、そしてはい、本日このセッションにお越しいただいた皆さん、ありがとうございます。今回は少し違った形で進めます。えー、正式なプレゼンテーションなどはありませんが、オープンなチャットをするだけです。えー、LLMs について少し、えー、vector databases について少し、そしてもちろん vector search と H H S W についても話します。では、Yuri、来てくださることに同意していただきありがとうございます。えー、ただお話ししたいと思います、つまり、気軽に話しましょう、そうですよね？でも、機械学習について、えー、あなたのバックグラウンドや仕事についての質問に本格的に入る前に、今の場所にどのようにたどり着いたのかについて少し伺いたいです。
そうですよね？どのようにして、えー、Vector search に関わるようになったのですか？レーザー物理学のバックグラウンドから、どのようにして今していることをするようになったのですか？やあ、Frank、えー、はい、紹介ありがとうございます。えー、はい、私はレーザー物理学の教育を受けました。なので、えー、PhD のときは、えー、実験的な f plus second レーザー物理学に取り組んでいました。そうですね、そこで、専門的に形作られる助けになりました。私はロシアのアカデミアで、非常に優秀な人たちと一緒に働きました。
そして、えー、はい、私の指導教官の一人は、えー、後に、えー、ロシアのアカデミアの長になりました。ある時点では Putin に報告していました。えー、そういう時期がありました。えー、また、ある意味では、えー、実験的レーザー物理学と機械学習の間には類似点があります。どちらでもパイプラインを構築しますが、えー、レーザー物理学では、えー、物理的なパイプラインを構築します。
つまり、レーザービームを輸送するパイプラインを組み立て、組み立てて、診断、輸送などを追加します。えー、そうですね、楽しい時期でした、えー、はい。えー、そして、えー、どのように、私が vector search に移行したかについてですが。えー、厳密な、えー、移行のようなものはありませんでした。レーザー物理学に取り組み始める前でさえ、私は契約を結んでいました、えー、えー、パートタイムの仕事で、Nira のスタートアップ、me labs と呼ばれる会社でした。
ええと、それで、私はそこにたぶん6年か7年くらい働いていて、その間に、ええと、修士号と博士号をやっていました。その会社はかなり野心的で、特に当時としてはそうでした。彼らは2007年に始めて、ええと、高度にスケーラブルな分散型類似性検索エンジンを構築したいと考えていました。ええと、3つをベースにした、ええと、3つのベースのエンティティを対象にしていました。彼らは言いました、わあ、そこには、ええと、モノのインターネットがある、と。それでそれらは、ええと、ええと、プロパティの3つとして表現できる、と。たとえば、あなたが、GVGプレイヤーとか、ネットネットプレイヤー、ネットワークプレイヤーがチリビザ、GTVを持っている、みたいな感じです。つまり、それらは接続できるので、効果的にお互いを見つける必要があるのです。
ええと、それで、その研究は最終的に、ええと、NSWの発表につながりました。ええと、それはHNSWの前身です。この研究は、ええと、Alexander Panari、ええと、Andrea Log、そして、ええと、そうですね、それは、ええと、私がレーザー物理学で博士号を取得する前に起こりました。そしてその頃には会社も存在しなくなりました。なので、今なら、なぜ10年前にベクトル検索にそれほど関心がなかったのかは、かなり明らかかもしれません。ええ、でも、ええ、そんなに多くはありませんでした。ええ、つまり、わかりません。
私が思うに、確かにある程度の関心はあったと思いますが、それは、それは、それは、それは確実に非常に初期段階でした。ええと、今日見られるようなものではありません。つまり、LLMに関するあらゆる誇 hype、レコメンダーシステム周辺のあらゆる誇 hype、ええと、こうしたさまざまな種類のモダリティすべてにまたがるあらゆるタイプの検索があります。でも、ええ、そこにもう少し深く入ると、つまり、私は、私は思うのですが、レーザー物理学のバックグラウンドを持っていて、つまり、これらすべてのパイプラインを再構築することが、MLのインフラを構築すること、ええと、あるいはMLモデル自体を構築することにもどのように似ているのか、ある程度は理解しているつもりです。ええと、でもまだ気になります。つまり、あなたは、たぶん、レーザー物理学から始めて、それでもデータ構造を作れる、つまり率直に言って、ほぼ普遍的に使われているデータ構造の1つだと思います。ええと、すべてのベクトルデータベースで、そして本当にすべての、つまり、多くの本番環境のベクトル検索システムで使われているものです。個人的には、それは本当に、本当に印象的だと思います。ええと、でも、まあ、つまり、どう、どう思いますか、h and s w のようなもの、そしてグラフベースのインデックスは、今後、つまり、未来はグラフベースになると思いますか、それとも、つまり、ベクトル検索を行うために、何かより良い解決策を思いつくと思いますか？より高い精度、より良い再現率、ええと、あるいは、あるいはより良いクエリ性能を与えてくれるものを。ええと、まあ、それは、何をグラフベースのインデックスと理解するかによります。ええと、確かに、グラフはアイテム間の関係を表す自然な形式です。
わかりました。ええと、そしてLLMを見ると、ええと、それらも、ええと、グラフニューラルネットワークとして見ることができます。ただし、その段落は、ええと、完全に接続されていて、ええと、つまり、ええと、LLMを高速化する多くの方法があり、ええと、そのほとんどは、いや、いや、いや、でもその多くは、入力内の各要素に対してアテンションを行わなくて済むようにグラフを指定する、というようなものに基づいています。そしてそれは、ええと、GNSと同じです。ええと、ただし、特別に作られたグラフを使っているわけではなく、いや、使っています。動的グラフかもしれないし、固定グラフかもしれません。ええと、でもそれでも、つまり、それは、ええ、それは表現の一形態です。
だから私は、私は、ええと、グラフの近傍探索がどこかへ行ってしまうとは思いません。それは確実に存在し続けるでしょう。ええと、だから、他にもそれを補完する方法はありますが、ええと、そうですね。つまり、関係を何らかの形で定義する必要があります。とても良いグラフはその形式です。なるほど、なるほど。
どのようにして生まれたのですか？あなた自身のオリジンストーリーに加えて、ぜひ聞いてみたいです。ちなみに、先ほどはありがとうございました。H and s w の、その、ある種のオリジンストーリーについて、そして、この特定のalgorithmを開発するに至った経緯についても、少し聞いてみたいです。ええ、そこを理解するために、もう少し深く掘り下げたいです。そこで共有できる限り多くの詳細を教えていただけるとありがたいです。はい、もちろんです。
ええ、先ほど言ったように、その研究は startup で行われた以前の研究から派生したもので、nsw です。これも graph algorithm です。そして、その graph algorithm は分散されるように設計されていて、random entry point のようなものを持っています。つまり、新しい node の追加に伴って scale することを想定しています。したがって、既存の industries は scalable であるべきです。ええ。
そして、そこにはいくつか問題があり、それは私たちも分かっていました。ええ、私がレーザー物理学で PhD を取得したとき、キャリアを進めるには海外へ移る必要があると理解しました。なので、その時点では海外へ移りたくありませんでした。ええ、だから他の選択肢を探していました。同時に、PhD を取得する少し前に、ええ、連絡がありました。以前の algorithm が本当に非常によく機能していて、新しく開発された benchmark で、高い recall のところで右上に位置していた、ということでした。なので、n w にそれほど多くの関心があることに少し驚きました。
ええ。ですが、関心があるのなら、この研究を復活させるのは理にかなっていると思いました。そして最初に、natural networks における nav ability の起源について、network physics paper のようなものを発表しようとしました。これは、かなり長く古い研究テーマのようなものです。そして二千年代初頭に natural scale journals のようなところに掲載されていました。
なので私も論文を書きました。つまり、natural lang natural networks がなぜ navigable なのかについて、単純な説明を考え出しました。しかしそれは nature で却下されました。その時点では network science への関心はやや下火になっていたようです。それで、他の journals からもいくつか却下された後、plus one に掲載されました。これは良い journal ですが、それでも nature ではありません。
そして、私がその論文に取り組んでいたとき、s w を既存の navigatable networks の models と比較しました。それらは research として宣伝されていたもので、s w はそれらと比較して最も良い性能を示しました。しかし、それでも、小さい dimensionality では dimension に対して poly algorithmic scality を持ち、低次元データでは苦戦しましたよね。しかし、他のものはもっと苦戦していて、それが、なぜ苦戦するのかという理由を示唆していました。うーん。ええ。問題は、N S W や navigatable networks の他の解決策が、ある意味で空港での移動のようなものだということです。
つまり、point A から B へ移動する必要があるとします。まず公共交通機関や車で空港まで行く必要があります。そして、おそらく近くに大きな空港がない場合、自分の空港からより大きな空港へ移動し、次に別のより大きな空港へ移動し、それから小さな空港へ移動し、さらに移動する、ということになります。そしてそれは、navigatable networks のよく知られた model です。問題は、hub、つまり大きな空港へ行くと、そこは非常に connected であるということです。つまり、これを機能させるには本当に非常によく connected である必要があり、それは network 内の elements の数に対して logarithmic に scale し、double leading to となります。そして、ええ、それに気づいた後は、より簡単です。
つまり、ええと、まずランダムな要素から始める必要はありません。分散検索が必要ないなら、それを切って、トップ要素から直接始められます。だから、それは常にそうで、それが助けになり、性能を向上させました。でも2つ目は、ええと、その場合、ハブから始めるので、ハブに対して長い接続を全部張るようなことを避ける必要があります。そのために、ええと、私たちは n w がスキップリストに似たようなものだと知っていたので、その類似性については発表しませんでした。
でも、ええと、内部的には、私たちは、NSW がなぜナビゲート可能なのかを説明するとき、それはスキップリストのようなものだと言っていました。スキップリストは msw にとって良いモデルです。ええと、でも、この時点まではそれほど重要ではありませんでした。そして Skip Lift には、リンクを長さで分ける自然な区分があります。だから、よし、w で ski police の区分を使おう、と言えば、ええと、スケーラビリティを解決でき、それはうまくいきました。
低次元データでの性能は、W と比べて何桁も向上し、ほとんどのデータセットでアルゴリズムが良好に動作するようになりました。そして、ええと、最後の点は、ええと、それでも1つのデータセットではうまく動作しなかったということです。それは非常に低次元のデータセットでした。そして、ええと、それ自体との議論の後で、つまり、修正する価値があるかもしれないと考え、近傍選択のためのヒューリスティックを追加しました。これは、優れた人たちによって行われた spatial approximation tree の研究から知っていたものです。そして、ええと、それによって1次元のスキップリストへの遷移が正確になったので、良い性質があります。
ええと、はい。そして後になって、同じヒューリスティックがさらに以前にも使われていたことがわかりました。area mount による研究のようなもので、ええと、Google 検索、つまり school、school or search を通じて見つけなければなりませんでした。relative neighborhood graph と graph es で検索するときです。つまり、私は全部見つける、というか、この論文を見たのですが、自分が実際にそれを使っていたことは知りませんでした。はい。そして、ええ、それが基本的にすべてです。
それで、ええと、はい、私たちはテストしました。つまり、ええと、N W N と統合しました。そこには、ええと、すでに Python との統合と、ええと、Benchmark がありました。だから、私たちは in and Benchmark に参加しました。はい。そしてご存じのように、文脈として言うと、NMS live と Hsw は、n n benchmarks におけるトップクラスの vector search ライブラリの1つであり続けていると思います。これは本当にすごいことだと思います。そしてその背景についてもありがとうございます。
スキップリストの概念と、ナビゲート可能なスモールワールドを、実際にどのように組み合わせることができたのか、そしてまた、この研究の一部が過去にどのように使われていたのかという文脈についても聞けて、本当に興味深いと思います。ですので、本当に感謝しています。ただ、いずれにしても、H and s c W の誕生の物語と、それが Vector search のアルゴリズムとしてどのように成立したのかを聞くのは、本当に、本当に興味深いと思います。あなたのお考えについても、ほんの少しだけお話ししたいのですが、ええと、ご存じのように、いくつかの新しい手法についてです。scan disk、n n、ええと、もちろん、disc、K n n もグラフベースです。ええと、私は Disc k n n について、本来そうあるべきほど詳しくありません。ええと、内部の仕組みという点で、特に個々のコンポーネントの一部が M VM e のページ上にどのように格納されるかに関しては、詳しくありません。
ええと、でも、それらについてもあなたの考えを伺いたいです。そうですね。ええと、ご存じのように、まさに vector search の第一人者として、disk についてどうお考えですか。そして、ええと、scan について、新しい span のいくつか、ご存じのように、いくつかの新しい、ええと、vector search アルゴリズムについてです。そして、そして間違いなく、ご存じのように、私たちは、この分野への関心が非常に急速に高まっているのを見てきたと思います。うーん。
ええと、あー、disc n についてですが、私の、私の、私の私の私の理解では、disc K n n の主な貢献は、あー、ディスク上で使われるデータのコロケーションのようなものです。なので他の、他の点については、私は、よく分からないのですが、それらが、それらが大きな違いを生むのかどうかは分かりません。でも、あー、はい、これは、これは disc search を行う正当な方法のようなものです。なので代替案はあります。例えば、あー、Microsoft からの別の研究も、彼らは、彼らは disk に対して、disk のための別のソリューションを持っています。そして、あー、そのソリューションについては、分かりませんが、私は実際にはたぶん、その、その別のソリューションのほうを好むかもしれません。つまり、あー、なぜならそれは他のことをいくつか容易にするからです、例えば要素の削除などです。
あー、でも、はい。そして、あー、私の理解では、あー、つまり disc canan は、彼らも、あー、disc canan を持っていて、今は fresh disc canan を持っています。彼らはある意味で収束してきていて、つまり実際には H N S W に近づいています。ただし、scan の更新や鮮度に関しては、scan や他の種類の、あー、ization アルゴリズムについては、それらはグラフとは直交しているので、一緒に使うことができます。なので、そしてそれらを一緒に使っているソリューションもいくつかあると思います。
ああ、はい、はい。あなたは、今は少し良く聞こえますか？すみません。はい、ベクトル検索の周辺で関心が爆発的に高まっているのを見るのは、かなり、かなり興味深いと思います。ええと、ご存じのように、そこには、そしてそれは非常に、非常にうまく結びついていると思います。
それで、私たちは、実際に、現在オーディエンスの中に一人、一人のメンバーがいて、その方が実際に、グラフベースの技術について、について質問をしています。これは今話していることと非常によく結びついていると思います。なので、最後にある q and a セッションではなく、今ここでそれに答えてしまってもいいと思います。それは、ええと、現在のグラフベース技術の状況では、支配的なトレンドは pruning と incremental building のプロセスを中心に展開しています。そこで特に disk と n run に関連して、あなたの見方では、効率的な navigability を備えた高品質なグラフを構築するための次の重要な要因は何だと考えますか？かなり一般的な質問ですが、あー、今まさにグラフベースネットワークと disco について話しているので、これに今答えるのがいいと思いました。グラフベースネットワークではありません。グラフベースのインデックスは N K N N と言います。
うん。ええと、私は、あー、その、あー、質問に対する最良の答えが何になるのか、完全には分かりません。なので、あー、現在存在しているグラフを構築するための手法は、あー、かなり発展していると思います。そして、まあ、いくつか改善はありますが、それらは少し追加的なものです。なので性能面で 2 倍以上を与えることはないでしょう。
ええと、もしかすると私が何か見落としていて、それが可能かもしれませんが、あー、私の理解では、人々はグラフを構築して、それらが良い状態になるようにする方法を知っています。はい、なるほど。そうですね、その文脈もありがたいです。ええと、少し先に進みたいと思いますよね？少し話したいのは、ええと、私たちはベクトル検索について少し話しましたし、特に、h and s w について少し、scan span について、ええ、scan N についても話しました。あー、少し話したいのは、あー、最近は誰の頭の中でも最も人気のあるトピックのように思えるもの、つまり LLMs について話します、ええと、より具体的には auto regressive lms ですね？あー、私はそれらを LLMs と呼ぶのが本当に嫌いです、私はそれらを LLMs と呼ぶのが本当に嫌いです、なぜなら大規模な言語モデルはたくさんあると思うからです。それらは、ええと、テキスト生成を行うように訓練されていないものもあります。
ええと、でも、ご存じのとおり、まずは非常に、非常に広いところから始めて、ええと、話題が出てくるにつれて、いくつかの興味深いトピックに掘り下げていけます。でも、LMS や AI ML 全般において、私たちが解決すべきだと思う興味深い問題にはどんなものがありますか？ まずはこれから始めて、個々のコンポーネントについては、ええと、それが出てきたときに、うーん、それが、ええと、後で出てきたときに掘り下げていけます。ええと、そうですね、たくさんあります。LMS にはかなり多くの課題があると思いますし、ええ、私は、ええと、大企業がどうやっているのかについての内部情報は持っていません。もしかすると彼らには何か秘伝のノウハウがあるのかもしれません。なので、私の理解では、最大の、ええと、問題はスケーラビリティに関するものです。つまり、非常に知識豊富なモデルをどう動かすか、重みがたくさんあるわけですが、ええと、実行や学習にあまりお金をかけずにどうやって動かすか、ということです。
そう、そうですね。ええと、聞こえません。すみません。マイクが切れ続けていて、申し訳ありません。それについては本当に同意します。
そして、コンテキスト長については多くの、多くの議論があると思います。ええと、ご存じのように、Anthropic の最近の 100 K コンテキスト長モデルですね。そして私は本当に疑問に思っています。ご存じのように、多くの、多くの人々は、いったんそれを、つまりその量のコンテキストを本当に使うようになったとき、全 100 K トークンにわたって生成する、ええと、つまり本当に補完を行うのにどれだけ時間がかかるかを過小評価していると思いますよね？ うーん、そしてそのすべてを本当に処理して解析できるようにすることも。これはそうしたことの一つだと思います。なので、あなたが話していたことについて少し、もう少し深く掘り下げると、うーん、ええと、スケーラビリティやデプロイメントに関して、そしてあなたは、でも、でも、すみません、私は、つまり、ええ、どうぞ。途中で遮ってすみません。いえいえ、大丈夫です。
ええと、そうですね、ええと、長いコンテキスト、長さは、ええと、かなり重要です。そして、ええと、まあ、スケールさせる最も簡単な方法は、あなたのソリューションに、ええと、より大きなコンテキスト長をサポートさせることです。なので、私の知る限りでは、ええと、手法としては、ええと、まあ、それを少しでもスケーラブルにするために、少なくとも学習では、ええ。ええと、この alibi のような、ええと、位置エンコーディングのようなものです。ええと、でもやはり、何らかの形で spar を適用しないと、最終的にその方法は、ええと、ncore の計算量を必要とします。計算とメモリの両方で、ええと、それが多くのアプリケーションにとって制限要因になります。
ええ、ええ、ええ。本当にそうです。ええ、ありますよね、うん。ええ。ええ、私は、ええと、そうですね、私の理解では、GBT four については確かではありませんが、G three、G three は、ええと、ある種、ええと、疎な層、疎な attention 層と、密な attention 層の両方の組み合わせですよね？ だから、それについては言うべきことがあると思いますし、おそらく現在出回っている多くのモデルへの拡張も非常に、非常に似ているのだと思います。
だからわかりません。様子を見ましょう。様子を見ましょう。でも、うーん、それが私のちょっとした意見です。ええと、ええと、興味深い質問があります。ご存じのように、私が持っているもので、同時に話したいと思っていたことなのですが、うーん、あなたは、うーん、LLM は、あるいは自己回帰型言語モデルは、自己認識していると思いますか、それとも創発的だと思いますか？ 最近そのことについて少し議論があったのは知っています。うーん、ええと、特に人々が agi と呼びたがるものへの道筋においてですが、あなたの考えはどうですか？ うん。
そうですね、私は、私はそれらが自己認識しているとも創発的だとも思いません。実際この質問を ChatGPT にして、少しそれとチャットしました。つまり、彼らには予算がないので、ええと、だから彼らには苦しみの、そして苦しみの概念がありません。苦しみの概念は重要です。つまり、人間は、まるで、人間の主な目標は未来を予測することだと教えられているようなものです。とても。
もし彼らが未来をうまく予測できないなら、期待が現実と一致しないために苦しむことになります。ええと、でも、ええと、rail lamps については、ええと、それはないので、バックプロパゲーションで訓練されています。だからバックプロパゲーションは、ええと、苦痛を伴うプロセスのようには聞こえません。だから、ええと、訓練後には新しい、まるで新しい存在があると言えます。そうですね、つまり、まあ、そこにそれ自身に関するデータのようなものを加えれば、ある意味では自己認識的になり得ますが、ええと、相互作用の記憶はないので、忘れてしまいます。
ええ。ええ。あなたがそれにも言及したのは興味深いと思います。というのも、自己認識であること、創発であることに関しては、2つ、いくつかの重要な要素があるからです。そして最初のものは、私たちはいつも創発や自己認識を、人間の概念に関連するものとして定義していると思います。そして、私たち人間が学習するときに、基本的に、私たちの、あの、脳の中でバックプロパゲーションを行っている、と言うのは非常に、非常に難しいと思います。
私は、それが物事を見るうえで、とても自然な見方だとは思いません。ええと、だから私は LMS が本当に自己認識を持っているのか、本当に創発的なのか疑問に思っています。わかりません、興味深い問いです。うーん、おそらく、私が答えられるものではないでしょうが、ええと、とにかく議論できると思ったものです。ええと、なので、そうですね、LMS と ai、ML 全般の話題にとどまるという点で、あの、いくつか、あの、私たちは先ほども、ねえ、これらを本番環境に投入したいなら、うまく機能させられるようにスケールさせる方法が必要だ、という話をしました。
あなたが知っている、LLMs に役立つスケーラビリティ技術にはどんなものがありますか、ええと、単にベクトルデータベースを使うことを超えて、ですよね？ベクトルデータベースを使って、ええと、ドキュメントやドキュメントのチャンクを保存し、クエリに関連する最も関連性の高いものを取得することを超えて？ええと、まあ、ええと、parts based methods はたくさんあります。つまり、ええと、すべての項目に対して attention を行うのを避けるようなものです。だから reformer のようなすべての研究があります。ええ。いくつか、ランダムな、ええと、random attention のようなものを使った Google の研究があったと思います、つまり、attention pattern を付けるというか。ええ。
それから rance もあります、ええと、それらは非常に、非常にさまざまな sparse です。うーん、ええ。なので多くの解決策があり、そういうことを行う論文が山ほどあります、ええと、それは、ええ、それは context one を増やす文脈での話ですよね？ええと、ええ。でも、ええと、open AI や他のところで実際に何が使われているのかはよくわかりません。なので、私がいくつかの generative AI 企業と話して、それを使っているか尋ねたとき、彼らは、ああ、いいえ、使っていませんと言いました。
私たちはとても単純なものを使っています、と。なので驚きました。なるほど。わかりました。そして、ええと、そうですね、CNNs もまた、この、ええと、複雑性の問題を持っていません。
そして私は、たとえば、ある、ある、たとえば、私は、おそらく CNNs に pulling と、ええと、ええ、pulling と evolution を組み合わせたようなものを見ることになると予想しています。つまり、異なるスケールを持つとき、それが、ええと、将来のどこかで主流になり得る、というようなものです。興味深いですね。わかりました。興味深い。
興味深い。では、私たちは、つまり本質的にはあなたは、私たちは、ええと、削減する、と言っているわけですね。わかりました。なるほど。興味深い。つまり、削減するという感じですね。ええ、文脈上それがどう機能するのかはよくわかりませんが、でもそれは興味深い考え方です。
ええ。次元を空間的にある程度削減することで、より良い性能を得られるようになる、ということですね。ええと、まあ、そうですね。つまり、computer vision では、ええと、あると思います、とても興味深い概念として、ええと、stack power glass models があります。つまり stack、stack、stack のようなもので、覚えています、覚えています。
ええ。すると基本的に情報の流れがあり、ええと、情報が、ええと、異なるレベル、ええと、special levels のようなものの間を流れます。そしてそれは、それは、それは非常に、ええと、強力なアプローチだと思います。ええと、なので、似たようなものが Transformers にも機能する可能性があり、何か、何かを使った論文を見ました、でも私はすでに本番で何が、何が使われているのかは知っています。なるほど。
十分です。はい。分かりました。ええ、ええ、間違いなく未解決の問題です。ええ、間違いなく未解決の問題です。
そして、その、検索にVector databaseを使うことは、その一つだと思います。間違いなく今最も一般的なものの一つです。そして、ええ、でもまだ取り組むべきことはあると思います。その、いったん最も関連性の高い文書を取得した後、ええ、あるいは後で、別のモダリティ、画像や動画も同様に、いったん最も関連性の高いデータ片を取得した後、それをLLMに非常に、非常に効率的に通して、非常に、非常に速い応答を得られるようにすること。これはまだ、ええ、まだやる必要があることだと思いますが、ええ、でもそうですね。うーん、そうですね。LLMに関しては、その、どう思いますか？LLMと、そしてVector searchは、これらは今後、手を携えて進んでいくものになるのでしょうか？ええ、これらは、これらは、その、今後多くのアプリケーションで基本的に密接に結びついていくのでしょうか？それとも、たとえば、その、非常に、非常に長いコンテキストのモデルに対して、長いコンテキストでの性能を改善する方法を見つけて、Vector databaseはもっと、その、異なるセッション間の会話を保存する、さまざまなものを保存するために使うようになると思いますか？ええ、私が言いたいのは、その、これらは本当に、本当に、その、今後手を携えて進んでいくと思いますか？うーん、それともこの分野で何らかの変化が見られると思いますか？そうですね、ええ、私はそれらは互いに非常に補完的だと思います。
つまり、ええ、vector searchは、大規模言語モデルも使う人々が利用できるツールのようなものです。つまり、ええ、なぜ、そもそも、あの言語モデルのようなものが必要なのでしょうか？つまり私たちは、ええ、テキストやその他のデータをベクトルとして表現したいのです。うんうん。そうすると、それらは、ええ、それによって比較可能になります。ええ、それから他の、数値的な値のようなものを、そこから、そこから、そこから推論できます。
そして、ええ、ベクトルがあれば、類似という概念がありますよね？そして、ええ、それを大規模なサイロにスケールさせるためのツールが必要です、必要です、必要です。なので、たぶん、ええ。Vector databaseは小規模ではそれほど必要ないかもしれませんよね？そうですね。データがあまりないなら、ですよね？でも、ええ、本格的なアプリケーションのようなものでは、それはすぐにボトルネックになります。つまり、データが多すぎると、うーん、特にそれらをフィルタリングしたい場合です。
なのでボトルネックになります。そしてそれは、現在の推薦システムでもボトム、つまり、つまり、スケールのために、つまり、ええ、近似最近傍探索を使わなければなりません。ええ。機能させるために。
そして、ええ、おそらくl lampsでも使われるでしょうし、lampsの内部でも使われるでしょう。なので、おそらく、ええ、retrieval argumentedアプローチの中でも使えます。つまり、単に使うだけではなく、つまり、ユーザーデータではなく、ええ、たとえばトレーニングデータを取得する場合です。トレーニングセットのすべての情報をモデル内に保存したくはありません。ええ、それはあまり効率的ではありません。ええ、なので、モデルと組み合わせることもできます。
つまり、単なるツールです。新しいLMを作るとき、あるいはlmmと一緒にプロダクトを作るとき、ええ、ベクトル、つまり最近傍を見つけることをより速くしたいわけですよね？なので、うーん、ええ、それを行うためのツールがあると非常に便利です。ええ。ええ。そして推薦システムの話題についても、うーん、そこにももう少し深く踏み込みたいです。
思うんですが、ほら、そこには、Vector データベースに不慣れな多くの人たちにとって、ええ、Melva や Zillows のようなベクトルデータベースの周辺に、ほら、lms の頃、chat, pt の頃、ほら、Bard や Claude の、ええ、ほら、ベクトルデータベースは実際にはかなり前から存在していました。うーん、ほら、私たちは特に、Novis に取り組んできて、ええ、取り組んできて、そしてほら、私が言うには、LMS 以前の最大のユースケースはレコメンドシステム周りであり、ほら、本当にコンテンツを意識した推薦を行う能力でした。そうですよね。そして Rex uri というこのトピックに戻ると、ほら、何が、まず広く始めてもいいと思いますが、ぜひあなたの考えを聞きたいです、つまり、レコメンドシステムを構築することに関連する最大の課題にはどのようなものがありますか？ そしてそれはベクトル検索に関連していなくてもよく、一般論で構いません。そうですね、ええ、最大の、つまり私は、私は、ml のランドスケープがあると思っていて、つまり、コンピュータビジョンがあり、ええ、自然言語処理があり、それらはある種、収束しています。
ええ、それらは同じアーキテクチャを使っているので、似たデータで学習します。だから画像もテキストに役立つように見えます。ええ、でもレコメンダーシステムは、ええ、ちょっと違います。そして、ええ、私が思う大きな問題は、レコメンダーシステムはほとんど決してオープンソースではないということです。つまり、ええ、それらは、ええ、企業データを使って、ええ、良い推薦を行います。
だから、本当に、つまり、あなたのプロダクトのために特定の人々によって作られた異種混合の特徴量セットのようなものをサポートしなければなりません。そして、ええ、それが、ええ、事前のレコメンダーシステムや、ええ、強力なベースラインやレコメンダーシステムを持つことを複雑にしています。だから今、新しい会社に行くたびに、ええ、レコメンダーシステムを作るというようなタスクがあるわけです。すると、やるべきことがいくつもあって、それはある意味ゼロから始めるようなものです。そして、ええ、そうですね、私は、私は、私は、私は、ある時点で、人々は、ええ、レコメンダーシステムのための汎化可能なソリューション、ソリューションを思いつくと信じています。
ええ、つまり、まあ、そして確かにスタートアップはあります。例えば、ええ、kumo ai がありますよね？ ええ、つまり、あの、うーん、はい、いくつかのつながりが、ええ、あるものです。だから他にもありますが、つまり、目標は、ええ、レコメンダーシステムの典型的なユーザー、つまり顧客のようなものを使うことです。ええ、そこで彼らはよく知られた形式で何らかのデータを提供します。ユーザーに何が必要かを本当にきちんと指示しなければならず、そうすれば何らかの解決策を出すことができます。
それで、ええ、その問題をユーザー側で解決します。そしてユーザーは、自分が正確に何を望んでいるのかを本当にうまく説明できなければなりません。だからたぶん、そうですね、今は、LMS がそのギャップを埋める、つまり、そのギャップを、を、を縮めるのに役立つでしょう。そうすれば、彼らは、ええ、ええ、つまり私の理解では、ええ、レコメンダーシステムは変わっていくでしょうし、ええ、そうですね、今、もしあなたが新しい会社で、レコメンダーシステムをやりたいなら、つまり、Meta や Google のようなところから高価なエンジニアを雇う、うーん、他の高給企業から雇うようなことに、ええ、あまり多くのお金を持っていないわけです。だから、おそらく選択肢は、あまり、多くないでしょう。ええ、だからそれも良い市場だと思います。
そして、ええ、pi 最近傍探索は、つまり、ベクトル検索は、ええ、他の多くのシステム、特に大規模システムにおいて重要なコンポーネントです。だから、数百万以上にスケールする必要があり、ええ、コストを節約したいなら、そうですね、ベクトルを使う必要があります。はい。ベクトルデータベースです。はい。あなたは、まあ、ええ、はい、皆さん、ここで聞きましたね。
うん、そうですね、たぶん、えー、推薦に載ること、レコメンデーションに入ることは、は、えー、まあ、そこにいる誰にとってもかなり大きな恩恵になり得るし、かなり大きな収益源にもなり得るんですが、ええと、でもそうですね、あなたに同意する傾向があると思います。つまり、今後、人々がレコメンデーションを行う方法にいくつか変化が見られるだろう、ということです。えー、私の意見では、それは純粋にベクトル検索だけの話にはならないと思います。なので、そこには間違いなく多くの、えー、間違いなく、つまり、ベクトルと、既存のメタデータの両方を混ぜたものになると思います。たとえば YouTube 動画を考えると、ええと、あるいは他の動画プラットフォームを考えると、その動画の内容を理解すること、しかし同時に、ねえ、もしかすると誰が、つまり、それが動画で、テレビ番組のクリップだとしたら、えー、その動画に出ている人たちの何人か、その動画に出ている俳優の何人かを理解すること、ええと、さらに動画内で起こっているアクションのいくつかも、こうした非常に、非常に具体的なタグを通じて理解すること、それはかなり重要になり得ると思います。ええと、なので私は、私は、私は、あなたに同意しますし、特に LM の時代においては、えー、つまり、こうした従来型の、ええと、プラットフォームに多くの変化が見られていると思うので、どうなるか見てみましょう。
見てみましょう。えー、こうしたレコメンドシステムを構築してきたご経験の中で、最も難しいことのいくつかは何ですか、つまり、直面したこと、えー、見てきたことは何でしょうか。そうですね、はい、ええと、これは、一般的な、えー、一般的な、えー、答えだと思います。つまり、レコメンドシステムにおける最大の問題はデータであり、正しいデータを持つこと、その、その、そのデータにバグがないこと、そして正しいターゲットを持つことです。もし、もし、もし、えー、良いデータがあれば、特に構造化データのようなものがあれば、すると、その、結合、結合がレコメンダーシステムにおける大きな問題になります。すると、その問題は非常に単純になります。
つまり、モデルを訓練して、えー、はい、本番環境に投入するだけです。しかし、えー、通常はデータに何らかの問題があります。つまり、その、あるいは、その、その、ターゲットが適切に定義されていないのです。たとえば、あなたが、ランキング目的、えー、つまり、何か、いくつかのアイテムをランク付けしたいのに、えー、その代わりに point wise loss を使ってしまう、というようなことです。そして時には、特に、えー、位置バイアスを考慮しない場合、つまり、もしかすると、あなたは以前に訓練したモデルを蒸留しているだけかもしれません。
つまり、問題は非常に、非常にたくさんあります。えー、なので、エンジニアはたいてい、えー、データに取り組むこと、データが良いものであることを確認すること、最適化している目的が筋の通ったものであることを確認することに時間を費やし、えー、それから、えー、まあ、その、その、その、モデルです。なので、そして今は、たぶん、えー、かなり明らかなことかもしれません。つまり、えー、ユーザー理解には進歩があります。なので、えー、今ではユーザー理解のほとんどは、ユーザー履歴に適用された transformer です。
なのでそれも大丈夫で、えー、コンピュータビジョンとも収束していて、そして、そうですね。つまり、私が思うに、あなたはそこで興味深い点を指摘したと思います。それは、レコメンドシムに関しては多くの場合、特にベクトル検索を行いたい場合や、あなたの、あなたのデータベース内にある任意の、つまり任意のアイテムを意味的に表現したい場合、えー、多くの時間は大量のデータ整備を行い、モデルに取り組み、実際に最適化している関数が本当に、本当に、本当に自分たちが望んでいるものなのかを確認することに費やされる、ということです。そして私は、それは、そして私たちはおそらく少し時間をかけすぎているのだと思います、えー、たぶんこうしたシステムを構築する私たち全員が、よし、最善の方法は何か、つまり、データを本当に理解するよりも、より多くのエンジニアリング上の問題を解こうとすることに。なので、その点、ありがとうございます。本当に、そのアドバイスに感謝します。
ここで最後の15分に入ってきたところでもありますし、とても役に立つと思います。ええと、そして、あの、まず最初に、皆さんありがとうございます。ここにいる皆さん、私たちに付き合ってくださってありがとうございます。ええと、話したいのですが、ええと、最後に一つだけ質問があります。うーん、それについて本当に、本当に深く掘り下げたいんです。ええと、そしてそれについてのあなたの見解も聞きたいのですが、それは、Vector Searchの未来はどうなると思いますか、そしてVector databasesの未来はどうなると思いますか？そうですね、私はそれらは改善されて、人々が使う非常に有用なツールのようになると思います。
今あなたが持っているもの、今あるものは、とても良いツールです。Vector databaseがあるだけで、それは使いやすい、ええと、そうですね。人々がそれを使いたいと感じたときはいつでも、ただそれを使うだけです。シンプルです。はい。
私たちは今後も見続けることになると思いますか、ええと、つまり、そう願っていますが、あなたは、ええと、Vector Searchの新しい手法や、新しいVector Searchアルゴリズムが本当にもっと頻繁に出てくるのを見ることになると思いますか、ええと、それともほとんどの人は自分たちの方針を貫いて、embedding生成技術の改善にもっと取り組むことになると思いますか？ ええと、おそらく、より良いモデルやretrieval向けのモデル、ええと、re-rankingの能力などを改善する、といったことですか？そうですね、ええと、私は、ええと、nearest neighbor searchのような、Vector Searchはかなり、洗練された分野だと思います。だから、まあそうですね、論文はあります。70年代から良い論文がありますし、90年代のような相当な量の領域もあります。なので、ええと、確実に、改善はあると信じています。そして、ええと、今nearest neighborsへの関心が急増しているので、間違いなくもっと多くの研究が行われるでしょう。そしてもっと多くの論文も出るでしょう。ええと、でも、私は、私は、私は、性能の面で巨大なブレイクスルーが起こるとは思いません。
漸進的な向上はあるでしょう。なるほど。ええと、おそらく、それはユーザーが使いやすくすることにもつながるでしょう。なので、ええと、使いやすさの改善のようなものがあり、それがユーザーにとって大きな違いを生むかもしれません。ええと、でも、ええ、進歩の大半はおそらく表現の部分にあるでしょう、なので、なるほど。
より良い表現を得ることですね。なるほど。はい。ええと、はい、ええと、それで本当に、このやり取りの終わりにたどり着きます。おそらくより広い質問に踏み込んだと思いますし、Vector Searchについて少し話し、ええと、hswについて、その背後にある歴史のいくつかについて話しました。
ええと、そこで技術にあまり深く踏み込む必要はありませんでした。ええと、でも、ええと、質問のために場を開きたいと思います。もし何かあれば、ええと、すでにここに2つあるのが見えますし、聴衆の皆さんから他にも質問があれば、ぜひ受けたいです。ええと、もちろん受け付けます。ここでぜひ取り上げたいです。ええと、最初のものは、ええと、サブグラフ制御アクセスやVector Searchの回避策に暗号化を使用すること、プライバシーを強制するために暗号化を使用するグラフについて何かコメントはありますか？というものです。つまり、この質問はより、ええと、graph、graphベースのインデックスとセキュリティ、ええと、graphベースのインデックスと、そしてプライバシーに関するもののようです。
そうですね、私は、ええと、プライバシーについてはあまり詳しくありません。なので、何が、何がプライバシーとして定義されるのか？ graphにとって、graph searchにとって。つまり、検索するときに、そうですね、私は、何が、何が、その場合のプライバシーの定義なのかを理解しているかどうか、よくわかりません。はい、私の、たぶん私の推測では、私がもし、私がもし、私の質問の理解としては、より、ええと、もし私が、例えば、ユーザーロールを持っている場合、あるいは、つまり、とても、とても大きなベクトルのグラフがあって、そして、ええと、それぞれの、それぞれのベクトルが潜在的なロールのいずれかに関連付けられる、あるいは、つまり、そのようなものに関連付けられるようにしたい、ということですよね？ なので、mm-hmm。ええと、わかりました。
100%確信があるわけではありませんし、繰り返しますが、間違っているかもしれません。ただ、それが、ええと、暗号化とどう関係するのかは100%は分かりませんが、これがこの特定の、ええと、質問に関係していることについての私の推測です。うんうん。うんうん。はい。
そうですね、たぶん、もしUユーザーが、ええと、インデックスと共有されるデータを、こう、制御したい場合、というようなことかもしれません。つまり、サブグラフがあるかもしれなくて、実際に、大きなグラフを持っていて、その中に分離されたサブグラフを持つ、そういう研究や論文があります。そしてそれはある程度はまだ機能します。なので、もし、ええと、すべてを暗号化できるなら、彼らは、私が使えるようなキーを持っていて、すべてのリンクとデータを復号できる、たとえば特定のユーザー向けに、あるいは、またはデータをユーザーのデバイス上に保存する、そうすると、ええ、たぶんそれは、そのための解決策になるかもしれません。Frank、ちょっと割り込ませてください。チャットに補足があります。ええと、私の質問のプライバシーに関するQ&Aの質問は、たとえば組織内の部門のデータに対するロールとアクセスについてのものでした。
わかりました。はい、その文脈をありがとうございます、Emily。感謝します。ええと、そうですね、ただ、私たちが少し話していたこと、この質問に答える中で話していたこととも、かなり一致していると思います。ええと、特に、ええと、ベクトルだけでなくメタデータ、あるいはベクトルだけでなくスカラー・フィールドも保存できる能力、ええと、それらを同じ場所に配置でき、近似ニュース、近傍検索を行えるが、フィルタリングもできる、ええと、そこが、おそらくあなたがそこで探している重要なコンポーネントだと思います。
ええと、そして、ご存じのように、それは利用可能で、それは、HNSWのようなもので簡単に実現できます。ええと、それをメタデータ・フィールドと同じ場所に配置できるようにする、ということです。ところで、素晴らしい質問です。ありがとうございます。ええと、HNSWについてのチャットの流れへのフォローアップとして、ええと、ここに質問があります。ええと、ええと、HNSWのスモールワールド特性は、階層的な長距離エッジだけから生じるのか、それとも逐次的な構築プロセスの初期に確立されるエッジにも影響されるのか、という質問です。うんうん。そうですね、初期の、初期のエッジは、pr、ええと、HNSWのヒューリスティックの内部にあるようなものなので、彼らは、ええと、ああ、大きな役割は果たさないと言って差し支えありません。つまり、それらは別の理由、より、ええと、メモリをフラットに、メモリフレンドリーにするためのものです。
ただ、ええと、そうですね、この、こうしたプロセスの中では、性能リストを大きく損なうことはありません。なので、低次元データにおいては、アルゴリズム的なスケーラビリティは長距離エッジだけによるものだと言って差し支えありません。わかりました。はい、その質問をありがとうございます。
ええと、その質問へのフォローアップもあります。それは、現在のグラフANN手法が直面していると考える主な制約は何ですか、というものです。ええと、そうですね、制約としては、ええと、距離計算が、少なくともNSW実装チャネル、Wでは、メモリ、すみません、距離実装が、ええと、遅い可能性があります。つまり、それが解決するのが最も簡単なことです。というのも、ええと、HNSWはデータを要素とクエリの間の距離として見ているので、ええと、比較があるたびに、それが、こう、もしベクトルを持っているなら、それはL2やコサイン、あるいは内積のようなもので、それを計算します。そしてそれは高コストになる可能性があります。なので、そうですね、それは、ええ、最大の制約の1つだと思います。ただ、ええと、Faissのようにベクトルを圧縮することはできます。つまり、ええと、ええと、HNSWと一緒にベクトル圧縮のようなものがあり、それによって処理を高速化できます。
ええと、はい、それは、ええと、また、他にも制約があるかもしれません。ええと、ただ、ええと、私は、私は、確信がありません。たぶん補足があれば、つまり、どのような制約を、ええと、指しているのかが分かれば、もっと良く答えられるかもしれません。はい。ええと、そうですね、それについて補足をいただければ、それはありがたいです。ただ、制約についての私の最善の推測としては、おそらく、ご存じの通り、あなたはとてもよく表現されたと思います。つまり、距離計算、距離演算はそうした側面の1つですが、ええと、たぶんもう1つは、たとえばメモリに関係するものかもしれません。
ええと、つまり、どうすればインデックスのフットプリントを再削減、どうすれば、ええと、Emory Index のインデックスのフットプリントを少し削減できるでしょうか？ ええと、特に、しばしば、しばしばインデックスは実際には、データセット自体よりも大きくなります。ベクトルの圧縮を何もしていない場合、量子化も何もしていない場合です。ええと、何もしていない場合、あの、つまり、何らかの、ええと、そこに導くための、何らかの細かい量子化器がない場合です。あの、だから課題の一つはそのあたりにあるのではないかと思いますよね？ では、実際にどうやってメモリフットプリントを削減し、どうやって、ええと、つまり、グラフやインデックス、特にサブグラフだけでなくデータセット全体とメモリを保持するものを、どうやって、ええと、より効率的にするのでしょうか？ そして、ええと、そうですね、わかりません。ええと、確信はありませんが、ええと、つまり、ハイブリッドインデックスは一つの解決策です。
ええと、そうですね、あなたは、つまり、先ほどおっしゃったように、あなたもおっしゃったように、つまり、私たちがより効率的な計算を行える方法を見つけることが、ええと、別の解決策にもなるでしょう。ですから、ええと、ああ、ここでのフォローアップ、補足説明は、ええと、大規模データセットサイズにおけるフットプリントとインデックス作成時間に関連しています。うんうん。うんうん。うんうん。
はい。まあ、はい、はい、はい、メモリには、確かに制約があります。ですから、少なくとも要素ごとにいくつかのリンクを持つ必要があり、それはつまり、最低でも10バイト程度、あるいは、もしくはそれ以上が必要だということです。なので。そして、ええと、それを避けたいのであれば、要素をクラスタリングする必要があり、ええと、個々の要素を保存するのではなく、blob のようなものを保存します。
はい。ですからそれで回避はできますが、ええと、速度とリコールの、ええと、トレードオフは低下します。なので、はい、削減はしますが、はい。はい、ちなみに素晴らしい質問です。ありがとうございます。そしてここで最後の質問です。そろそろ時間の上限に近づいているのは承知しています、ええと、最後に少し事務連絡もあります。
dense plus sparse vector search についてのご意見は何ですか？ まあ、それは、ええと、そうですね、私は church にとても良いと思います。つまり、church です。なるほど。はい。ですからそれは非常に関連性があり、ええと、つまり、ええと、graph ink に戻ると。
つまり graph ink は、ええと、標準でサポートしています、なぜなら、ええと、距離を扱うからです。ですから dense plus part distance を定義すれば、動作しますし、そして、そして、must slip です。つまり sparse distances があり、ええと、インデックスは spar distances で動作します。ですから、あなたの場合にそれをより効率的にするためのハックがいくつかあるかもしれません。例えば、もし、ええと、BM 25 について話しているのであれば。BM 25 はヒートベースの手法です。ええと、ですからそれを、ええと、あなたの、ええと、sparse plus dance metric を使ったグラフの inter points として追加すれば、かなり早く収束するでしょう。
なので、しかし、ええと、はい、それ、それ、それは、ええと、そして、そして、そして、ええと、はい、s w で、ええと、sparse synthesis と一緒に動作させるためのものです。ですから、そこには、inter points を使ったハックがいくつかあります。はい、ええと、楽しみにしています、ええと、将来的にそのサポートが H S W live にも入る可能性があることを楽しみにしています。ええと、ですが、これが q and a セッションで用意していた最後の質問です。ええと、つまり、もし、もしフォローアップの質問があれば、ええと、もし皆さんがこのセッションで Yuri に聞く機会がなかった質問があれば、どうぞ私たちにフォローアップしてください。
ええと、対応するようにします。では Emily、あなたに戻します。ありがとうございます、Frank。ええと、Frank、Yuri、素晴らしい会話でした。ええと、私自身とても多くを学びました。
今は答えよりも質問のほうが多いかもしれないと思います。ええと、皆さんにもこのセッションを楽しんでいただけていればと思います。ええと、ご参加いただき本当にありがとうございました。今後の、ええと、Zillow's のウェビナーでまたお会いできることを願っています。それらは zillows.
com/event でご覧いただけます。ええと、コミュニティでお会いできることを願っています。お二人ともありがとうございました。ありがとうございます。そして、質問をありがとうございました。