You’re in!
ウェビナー
LLMアプリケーションのためのメモリ：最も関連性の高いコンテキストを取得するためのさまざまな検索手法
リソース
本日は、L l Mアプリケーションのセッションメモリ、最も関連性の高いコンテキストを取得するためのさまざまな検索手法にご参加いただき、誠にありがとうございます。私はEmily Ziで、Zillowのチームメンバーです。いくつか事務連絡をお伝えしてから、すぐにセッションに入ります。まず、このウェビナーは録画されていますので、途中で退出しなければならない場合でも、数日以内にオンデマンド版にアクセスできるようになります。
ご質問がある場合は、画面下部のq and aツールに自由に貼り付けてください。ええと、それによりスピーカー側で整理しやすくなり、皆さんの質問をモデレートしやすくなります。ええと、数分後に、チャットパネルにいくつかリソースを投稿します。今後のイベントもぜひチェックしてみてください。来週木曜日には素晴らしいセッションを予定しています。
無料のリソースもありますし、もちろん、いつでも私たちのコミュニティSlackにご参加いただけます。本日は、L l Mアプリケーションのセッションメモリ、最も関連性の高いコンテキストを取得するためのさまざまな検索手法のセッションに、ゲストスピーカーのHarrison Chaseをご紹介できることを嬉しく思います。HarrisonはLang Chainの共同創業者兼c e oです。同社は、言語モデルアプリケーションを簡単に開発できるようにすることを目的としたオープンソースのPython TypeScriptパッケージを中心に設立された会社です。
Lang Chainを始める前は、機械学習モデルのテストと検証に注力するML ops企業であるRobust IntelligenceでMLチームを率い、FinTechスタートアップのKenshoでエンティティリンクチームを率いていました。また、Harvardで統計学とusを学びました。Harrisonに加えて、本日はDillasのソフトウェアエンジニアである同僚のPhilipも参加しています。ご参加いただきありがとうございます。そしてHarrisonとPhilip、ようこそ。お招きいただきありがとうございます。
ここに来られて嬉しいです。では、Philip、さっそく始めましょうか。そうですね、ここに来られて嬉しいですし、お話しできるのを楽しみにしています。ええと、あなたと一緒にできるのも楽しみです。これは面白くなると思います。ええと、二つの視点ですよね？つまり、ほら、あなたは、ええと、あなたとZillowの、そしてvisとの、そしてZillow's Cloudでは、検索の問題に関して多くの人々と取り組んできたと思います。おそらく、よりデータベースのような観点からだと思います。
そうですね。ええと、そして、私の経験の多くはアプリケーション構築の観点からでした。検索は非常に重要だと思います。ですので、本当に楽しい会話をするつもりです。いくつかスライドもありますし、やり取りもあります。q and aの機能もありますので、回答してほしい質問があれば、そこに投稿してください。楽しい50分、あるいはそれくらいの時間にしましょう。
ええと、今日は検索全般について話します。検索とは何か、そしてなぜ重要なのかの基本的な概要です。ええと、セマンティック検索は、おそらく最も一般的なタイプ、または最もよく使われているタイプの検索ですが、いくつかエッジケースもありますので、基本を扱うとともに、いくつかのエッジケースも取り上げます。それらのエッジケースに対する解決策、ええと、または回避策も扱います。そして最後に、生成エージェントについて少し話したいと思います。これは、こうしたより高度なアイデアの多くを組み合わせた、ごく最近出た本当にクールな論文です。大まかに言うと、ええと、これは非常に簡素なスライドなので、Philip、ここで何か補足したいことがあれば、きっと色を加えるのに良いスライドだと思いますが、検索とは何か、そしてなぜ重要なのか、ということです。検索の考え方は、外部知識を言語モデルに持ち込むことです。
つまり、言語モデルは基本的に学習したことしか知りません。学習されているのは、たしかchat G p tは2021年のどこかにカットオフ日があります。ええと、また、すべてに対して学習されているわけでもありません。あなたのデータコーパスで学習されているわけではありません。時には、より小規模だったり、あまり一般的でなかったりするデータコーパスで学習されていないこともあります。
ええと、それから、検索のもう一つの理由としては、単に、いわゆるグラウンデッド生成という用語を使う人もいると思うんですが、生成を実際のドキュメントにしっかり根付かせるため、ということです。たとえ情報が言語モデルの中にあるとしても、もしかするとそれはごく小さな形で存在していて、モデルがそれをうまく認識できないのかもしれません。だからそれを取り出して、前面に押し出し、検索のために提示するわけです。ここで他に付け加えることはありますか？ほとんどの人は検索についてある程度の概念を持っていると思っていますが、あなたの視点からはどうか気になっています。そうですね、検索を動機づけるために何を使っているのか、ということです。
私にとって大きいのは、回答に根拠を与えることでもあると思います。大規模言語モデルを使うと、時には好き勝手なことを言うことがあります。そしてこうした検索エージェントを使うと、なるほど、その根拠はどこから取り出されたのかを見に行けます。検索エンジンのような形で、事実上の証拠を列挙できるわけです。つまり、基本的にはこれらを検索エンジンとして使い、あなたのLLMが言っていることに対する証拠を与えるということです。ええと、外部知識と組み合わせて、何について話しているのか分かるように情報を与えること、この2つが私の意見では最も重要だと思います。
その、情報源を示す、基本的には引用するという点について、どのような事例を見てきましたか？ うんうん。これは本当に重要だと思います。人々がそこで何をしているのを見てきましたか？明らかなものとしては、出典を引用するように頼むと、URLのリストや、渡しているドキュメントの情報源に当たる何らかのリストで返してくる、というものだと思います。ええと、あなたは何を見てきましたか？多くの人はそれらを表示するのでしょうか？それとも、エラー対応のようなことをしたり、それらの情報源との整合性を内部的にチェックしたりするのでしょうか？それらはどのように使われることが多いと見ていますか？私たちが見てきたところでは、主に上位K件の結果を提示し、テキストのスニペットのようなものを示し、それから実際のドキュメントへのリンクを付ける、という形で使われています。ええと、各回答について、これは正しいのか、ということを確認する分析はまだそれほど多くはありません。どちらかというと、ええと、裏付けを与え、現時点ではたいていの場合、どこから引いてきているのかを示す、という方向です。
ええと、OpenAIのretrieval appでは、ええと、そこで私たちは、分からない場合にどこを参照するかを列挙するようなスタイルを取っていました。正確にどんな方法で、分からないことを判定していたのかは忘れてしまいました。内部的には、もしかすると、よし、ええと、vector indexを検索するタイミングかもしれない、と判断する何らかのトリガーがあったのだと思います。ただ主には、結果を示し、表示することでした。というのも、retrievalから取り出すときには、ええと、時には要約しようともしますし、多くのユースケースではそれを要約するために使います。そしてこの要約も間違うことがあります。なぜなら、その場合、要約の中に物事を取り込み始めてしまう可能性があるからです。
そして、vector indexを使っているときには、念のため検索結果も提示しておく価値がある、というのはまさにそこです。ええと、そうすれば何が起きているのかかなり確信できますし、何かに戻る必要がある場合にも対応できます。ただ、内部的に、また大規模な利用においては、通常、事実上の根拠を見て物事が一致しているかどうかを確認するのはユーザー次第です。ただ、それら2つを比較するような取り組みは進んでいると思います。ええと、正確には分かりませんが、そこでは作業が進んでいると思います。はい。
素晴らしいです。ではこれで、検索の良い動機づけと、なぜそれが重要なのかが伝わっているといいですね。そして、ここにいるリスナーの多くもそれには馴染みがあると思います。では次に、Semantic Searchの簡単な概要に移ります。ええと、これは、圧倒的に最も一般的な検索のタイプだと言えると思います。
ええと、実際にはたぶん、たぶんその、その、たぶん本当に、最も人気があるものです。検索エンジンを使うだけ、みたいなものだと思います。検索エンジンを呼び出すことを考えると、それも一種の検索です。でも、社内ドキュメントに対する検索という点では、セマンティック検索が最も人気があるはずです。ええと、基本的な、ええと、概要は、ええと、これは、これはクエリ時に起こります。
ええと、ユーザーのクエリを受け取り、それに対する何らかの埋め込みを作成し、それをベクターストアに対してクエリします。そしてこのベクターストアには、すでに大量のあなたのドキュメントが事前に格納されています。ええと、そしてこれらのドキュメントは取り込まれ、チャンクに分割され、各チャンクに対して埋め込みが作成されています。それからそれらは、Zillow's や、または、または VIS のようなこのベクターストアに入れられています。ええと、そして、ええと、ご存じのように、実行時に検索クエリを渡し、いくつかのドキュメントを返してもらい、それを、その、言語モデルのコンテキストに入れると、答えが生成されます。
ええと、そしてここでわかるように、ほら、プロンプトはすごく複雑である必要はなくて、追加のコンテキストを使って質問に答えて、みたいなものです。そしてこれにはたくさんのバリエーションがあって、たとえば、そこにあるコンテキストだけを使うようにしてください、とか、使用した、ええと、使用したソース引用を返してください、といったことを言います。だから、だから、だから、この、ここのボックス、ええと、ここが、l chain における多くのプロンプトエンジニアリングが起こる場所です。ええと、これは、これは高レベルな話で、その前に、まあ、どこでこれが失敗するのか、という話に進む前のものです。それは面白い議論だと思います。たぶん少し、ベクターストアについて、ええと、そして、そして特に VIS と、そして Zillow's について話せるかもしれません。
それで、多くの人が疑問に思っていると思います。たとえば、どうやって、どうやって私は、1つ目として、たぶん、ベクターストアとは何なのか？なぜベクターストアが必要なのか？ええと、うんうん。そして、どうやって、どうやって1つを選べばいいのか？ということです。あなたの視点から見ると、皆さんがベクターストア向けに最高のオファリングを構築しようと考えている中で、どのようにそれを考えていますか？どの軸で比較していますか？ええと、はい、現在私たちが見ている最大のものは、単に使いやすさだと思います。ええと、多くのユーザーにとっては、彼らがどの段階にいるかにもよりますが、6つの docker コンテナを動かしたり、dock 内でネットワークを設定したり、dock に接続したり、そういうことを全部やりたいわけではありません。彼らはただ、よし、pip um、install して、これを import して、動く、というものが欲しいだけです。なので、それは大きな点でした。
それから、クライアントの使いやすさのようなものもあります。ええと、これらのベクターデータベースのどれも、言語 slash スタイル、たとえば API スタイルのようなものについて、まだ本当に定着していません。人々が目指そうとしている SQL のようなものです。他にもいくつかあります。ええと、graph DB スタイルがあると思いますが、これを行うための単一の言語、単一の API のようなものはありません。ええと、なので、最もシンプルなものは何か、ユーザーがベクターデータベースを設定したりこれらすべてを行ったりするために大量の引数を持たなくても、どうすれば物事をよりシンプルにできるかを考えようとしています。ええと、なぜなら、そうですね、誰でもかなり速く始められますが、ある時点では使いやすくする必要があります。ええと、私たちはできるだけ多くのスイッチを提供しようとしています。それは、こうしたことを扱えるチームを持っている大企業のようなところには素晴らしいのですが、これにかなり不慣れな小規模ユーザーにとって、本当にそれらすべてのスイッチが必要なのでしょうか？ただいじっているだけの人にとって、追加の10ミリ秒は本当に重要なのでしょうか？それはそのバランスを見つけるようなもので、みんなのための選択肢を作るようなものです。
ええと、それがずっと主なことでした。でも一方で、大規模ユーザー側としては、やはり速くありたいし、安定していたいし、出てくるすべての新機能にもある程度対応したいんです。ええ、でもそれは、パフォーマンスと使いやすさのバランスですね。そこが彼らの主な注目点のようなものです。ただ、私が興味を持っていたことの一つは、ええと、最近出てきている、たとえば最新のものが何だったかは分かりませんが、異常に大きなトークンサイズをサポートしている新しいモデルについて、あなたはどう思いますか、ということです。いずれはおそらく、自分のデータコーパス全体をプロンプトに入れられるようになるようなものです。はい。
ええと、つまり、そうですね、短い答えとしては、正直よく分かりません。誰にも分からないと思います。つまり、ええと、そうですね、私は ANTHROPIC のもの、100K のものを触ってみました。ええと、まだ触ってはいませんが、今はそれより大きいはずのものもいくつかあると知っています。そういったものはまだどれも試していません。
Anthropic の 100K のものを試してみましたが、多くの場合、単にこう、必要なのが、何にすごくうまく機能するかを言うと、それはすごくうまく機能するのは、私たちのコードベース全体を渡して、その中の単一の事実のようなものを見つけたい場合です。ええと、それにはとてもよく機能します。つまり、その事実を見つけて、ええと、抽出してくれる感じです。あまり驚くほどうまくいかなかったのは、複数のものを組み合わせるように頼んだ場合です。例を挙げると、Lang chain には agents という概念があります。そして、異なる LLM がありますよね。なので、link chain の多くの例で agents を使っているものは open ais の L l m のようなものを使っています。なぜなら、それが mm-hmm.
つまり、それが一番人気だからです。だからドキュメントのあらゆるところにあります。でも、基本的に私が頼んだのは、philanthropic wrapper を使って agent を作ってくれますか、ということでした。そして、その情報はすべてコードベースに存在しているんです。つまり、anthropic wrapper のようなものです。そして私は、ええと、anthropic wrapper をどう import するか、それはどうするか分かっていました。agent をどう開始するか、それも分かっていました。anthropic model で agent をどう開始するか、そこは少し苦戦していました。なので、そういうタイプのもので、そしてそれがコンテキストが本当に長いからなのかは分かりません。もっと大きな質問ではより良く動作しているのを見たことがあるので。
ええと、でも、私が与えたそれらのケースでは、驚くほどうまく機能していたわけではありませんでした。なので、私は思うに、つまりこれは少しまとまりがないですが、誰にも本当のところは分からないと思います。試してみるのは本当に面白いと思います。私はかなりいろいろ試しました。
mm-hmm. ええと、もっと試す時間があればよかったのにと思います。おそらく、ええと、いろいろなユースケースもありますよね。たとえば、非常に速い回答が必要なユースケースもあります。なので 100k の欠点は、とても時間がかかることです。ええと、でも待つ時間があって、これらのモデルが十分に良くなって、そうした問題のいくつかに対処できるようになり、そしてすべてに対して推論できるようになるなら。
そうですね、もちろんです。だから、私は、おそらく両方に、ええと、適した場面とタイミングがあると思います。あなたの意見はどうですか？皆さんはそれをどのように考えていますか。つまり、一部の、一部の過激な意見を言う人たちは、ああ、これらの長いコンテキスト長ウィンドウがあるから vector stores はもう必要ない、などと言うかもしれません。皆さんはそれについてどう考えていますか？私たちの一般的な考えとしては、多くのデータは巨大なコンテキストの中で失われてしまうのではないか、というものです。なぜなら、そこに重みがかからないだろうからです。分かりませんが、私はそれを実際にあまり試したことがなく、私たちもそれほど試してはいません。ただ論文などを読んできたという感じです。
でも、いくつかの、重要な情報を失ってしまうところがあります。たとえば、もし、もし本当に目立つ質問があって、たとえば、たとえば3つ、1回だけ出てくる1文とか、あるいは物語の文脈の外にかなりあるようなものだとすると、私はそう思います。あるいは、philanthropic がいくつかのテストを公開していて、本全体を入れて、その1行を見つけたところ、その1行は見つけるのがわりと簡単なものだった、という話だったと思います。誰かがそう話していたのを覚えている気がしていて、そこが私の中でちょっと、100%確信はないのですが、そのテキスト内の内容を覚えていられるのか？ 取り出そうとしているものに正しい重みを割り当てられるのか？ そしてそこが、私たちがそれはできないかもしれないと考えているところです。そこには情報が多すぎて、情報を取り出せないかもしれないのです。それからスピードも、ええと、リポジトリ全体についての質問に答えようとしているわけですよね。そうです、使うたびに結局、リポジトリ全体をアップロードしなければならなくなります。
ええと、どこかのレイヤーで何らかのキャッシュ方法を使って、最初に入れたテキストに基づいてキャッシュし、より速く応答を得られるようにしない限り、あまり有用だとは思えません。価格についても、ええと、最後に確認したときはかなり高かったです。そうですね、現時点ではそれほど多くの心配はありませんが、この分野は本当にすごい速さで進んでいるので、どうなるか見てみましょう。それから、ええと、ちょっと、これに関連するQAの質問が2つあって、たぶん今答えられると思います。
ええと、はい、そのうちの1つは、ええと、Sunil からのもので、要約してみます。モデルがすでに一連のデータで訓練されているとして、追加のドキュメントや外部知識に対して、モデルは実際には何をしているのでしょうか。単に驚いているだけなのか、それとも何らかの形で、回答を生成するうえで外部知識を考慮に入れているのでしょうか？ はい、それは、回答を生成するうえで外部知識を考慮に入れています。つまり、たとえば、ええと、たくさんの事実を含むドキュメントを与えることができます。つまり、たとえば、ええと、Lang chain の repo からのコード、コードスニペットに関するドキュメントを与えて、それから「この行では何が起きていますか？」とか、ええと、「この行を別の行に変えるにはどうしますか？」といったことを尋ねられます。ですから基本的に、すべての言語モデルは次のトークンの条件付き生成のようなものです。そして追加のコンテキストを渡すと、その生成は、あなたが渡したデータを条件にするようになります。
そして、その、その生成が何であるか、質問に答えることなのか、ええと、要約をすることなのかは、何をするように求めるかによって決まります。ですから、質問に答えるように求めれば、それは間違いなく、その外部コンテキストを取り込んで、それを使って質問に答えているようなものです。素晴らしいです。それから、ええと、もう1つ、ええと、またお名前を間違えて発音していたらすみません。ええと、これはドキュメントと、それらをベクトルストアに入れることに関するもので、ここでチャンクを適切に生成することはどれほど重要ですか？ チャンクの最適なサイズはどれくらいですか？ チャンク生成の最良のテクニックは何ですか？ ええと、Lang chain には皆さんがチャンクサイズを生成する方法についていくつかデフォルトがあるのは知っていますが、それについて調べて、これらの異なるチャンクがどのように機能するのか、ええと、最良の道筋のようなものは何かを見たことがありますか？ それは素晴らしい質問です。
私も、顧客から何が見えているのかをあなたに聞こうと思っていました。私は、ええと、つまり、ここで自分の見解を述べるのは喜んでします。わかりません。わかりました。では、つまり一歩戻って、チャンク化とは何で、なぜ重要なのか？ 基本的には、これらの長いドキュメントを取り出して、それらを配置し、そしてそれらからより小さなデータのチャンクを作成することです。
これが重要なのは、取得したいのは、ええと、その、その最も関連性の高いチャンクだけだからです。ええと、だから思うに、ええと、ほら、思うに、まあ、つまり、まあ、一方の極端では、ほら、もしすべてを1語ずつにチャンク化したら、それはかなり役に立たないでしょう。なぜなら、多くの文脈を失ってしまうからです。ええと、もしすべてを1つのドキュメントにチャンク化したら、実際には何もチャンク化していないことになります。だから、それはある種のトレードオフを示していると思います。つまり、チャンクが短ければ短いほど、小さければ小さいほど、持てる文脈は少なくなります。ええと、でも、それが、それが、それが大きくなるほど、1つには埋め込みが少し、その埋め込みが完全には捉えられないかもしれない、つまりその中に完全には捉えられない複数の概念があるかもしれません。
ええと、それから2つ目に、ええと、単に、コンテキストウィンドウを一定に保ったまま、それらをそれほど多く取得してコンテキストウィンドウに入れることができません。だから、ええと、思うに、ええと、私は一般的には正直なところ、より小さいチャンクのほうがうまくいっています。ええと、思うに、思うに、LinkedInで私たちが持っているデフォルトは少し大きめで、だから私は一般的にそれを下げて、たとえば500トークンくらいのチャンクサイズとか、そんな感じにします。ええと、ここでいくつかあります。これは、ほら、純粋にヒューリスティックです。
正解があるかどうかはわかりません。Lance MartinによるAuto Evaluatorという素晴らしいツールがあり、これを使うと、異なるチャンクサイズや異なるチャンクのオーバーラップを含めて、この質問応答パイプライン全体のようなものを実行できます。なので、チャンクにオーバーラップを持たせることは、ええと、基本的に文脈の一部を引き継ぐためにしばしば有用です。ええと、そしてLance MartinによるAuto Evaluatorという素晴らしいツールがあり、これを使うと、これらの異なるバージョンを試してから、あなたのユースケースに対して、ええと、何が最良として出てくるかを見るために、エンドツーエンドの評価のようなものを実行できます。ええと、もう1つ付け加えると、これはLang Chainがかなりうまくやってきたことだと思うのですが、これらのチャンクをどのように作成するかは本当に重要です。
ええと、だからデフォルトでは、すべてのトークンごとに分割することもできますよね？でも、思うに、チャンク化の背後にある考え方は、できる限り、おそらく意味的に同じものを同じ、同じチャンクに入れたい、ということです。ええと、そして、そして私たちが追加した多くのテキストスプリッターは、トークンレベルでは分割しません。ええと、それを行うこともできますし、そのデフォルトもそこにあります。ええと、でもそれらは、私たちが意味的に意味があると思う文字のようなものに基づいて分割します。たとえば、ええと、markdownがある場合、たとえば、その、単一のハッシュマーク、またはハッシュタグ、またはポンド記号があり、ええと、それはヘッダー1のようなもので、それからそれが2つあるとヘッダー2で、それからそれが3つあるとヘッダー3です。
そして、それらに基づいて再帰的に分割し始めると、ええと、同じセクション内などにあるようなテキストのチャンクが得られ始めます。そしてそれらは一般的に、意味的に意味のあるチャンクのようなもので、おそらく一緒にあるべきものです。なので私たちはそれに従って分割するようにしています。追加で。もう1つ、これは私たちが取り組んでいることで、私は、そのバージョンを出せることを望んでいます。
ええと、ええと、LA Lanceが実際にそれに取り組んでいます。彼は、彼は、検索に関して本当に素晴らしいことをたくさんやっています。実は彼をポッドキャストのゲストに呼ぶべきですし、私たちのゲストであるべきです。でも、ええと、彼が見ていることの1つは、分割するときに、ドキュメント内のどこにいるかに関する文脈情報を失うことがある、ということです。ええと、今挙げた例では、もしヘッダー1で分割し、それからヘッダー2で分割し、それからヘッダー3で分割すると、ヘッダー3で分割したときに、少し情報を失います。つまり、まあ、これはどのヘッダー2の中にあったのか、そしてこれはどのヘッダー1の中にあったのか、という情報を失うのです。そしてlink chainには、各ドキュメントに関連付けられたmetadataのような概念があります。
ええと、それで、ええと、基本的に私たちが取り組んでいるのは、そうしたセクション見出しの一部をメタデータに伝播させて、進めていくにつれてメタデータを基本的にリッチにしていく、というようなことです。そしてそこでの考え方としては、ドキュメント内のどこにあるのかという、ええと、コンテキストの一部を失わずにチャンキングができる、ということです。チャンキング周りについての、長くとりとめのない回答でした。これは本当に、本当に面白いと思います。私たちは lang chain の中で、多くのテキストスプリッターにかなり投資してきましたし、ええと、他にそこまでやっているところをそんなに見たことがあるかどうかは、私、私、私にはわかりません。でも、でも Phil、これについてのあなたの見解にも興味があります。つまり、ベクターストアに入れるための埋め込みを作成するものを作っているとき、人々は何をしているように見えますか。現時点では、私たちが見ているのはどちらかというとシンプルなルートで、ええと、見られているドキュメントの種類を分析して、それからヘッダーに基づいて取得するようなことは間違いなくしていません。
ええ、なので私たちの場合は主に、X トークンごとにシンプルにチャンクする、という感じです。ええと、それはほとんどのユーザーにとってかなりうまく機能する傾向があります。ええと、彼らが求めている結果に対しては、改善できる余地がたくさんあるとは思いません。そこは、より良いパイプラインを得るために lane chain を案内するところですが、たいていは基本的なものだけです。ええと、あるいは彼らがしているのは、通常、そうした巨大なものを保存していないということです。
つまり、彼らがこの P d F ルートで進む場合や、あるいは自分たちのデータのようなものの場合、通常は Lang Chain を通して、それから彼らが使っているものをこちらに渡してきて、そこで決めます。Lang chain やこれらのライブラリのどれも使わずに直接私たちを使っている人の場合、そのデータは通常、こうした巨大なドキュメントではありません。彼らはすでにデータを抽出しているような感じで、QA データとかそういうもので、そこではある程度チャンク化できますし、ほぼチャンクをそのドキュメント全体にすることもできます。ええ。ええと、本当に場合によりますが、通常はあまり見かけません。彼らはだいたい「わかりました、この埋め込みがあります。検索をどうすればより良く、より速くできますか？」と言うだけです。それは理にかなっていますね。ええ。
ええと、ここにはもう少し質問があると思いますが、そのうちの一つについては会話メモリとプロンプトの観点で後ほど扱うことになると思います。なので、ええ、続けられると思います。いいですね。わかりました。インジェスチョンパイプライン周りでもあなたに聞きたい質問がもう少しありますが、今はいったん、ええと、今後のスライドに進みましょう。
では、はい。セマンティック検索のエッジケースにはどのようなものがありますか？ええと、私たちが気づいたものは、ええと、いくつかあります。私は、私は言うなら、ええと、セマンティック検索は、そして、ベクターソースを使いやすくすることの使いやすさについてあなたが言ったことが私は本当に気に入りました。というのも、セマンティック検索はかなりのところまで到達できると思うからです。正確なパーセンテージは出しませんが、ユースケースによって、おそらく 80% から 90、95% くらいのところまでは到達します。なので、それを本当に簡単にできるようにすることは、多くの開発者にとって非常に可能性を広げるものだと思います。
ただ、進めていくにつれて、ええと、いくつかのエッジケースが生じ始めると思います。そして、ええと、これらの多くは、セマンティック検索の上にある、あるいはセマンティック検索の周辺にあるヒューリスティックのようなものです。ええと、それで、ええと、はい、ここでの概要ですが、私は、私は、おそらく抜けているものがたくさんあるので、Philip、あなたの見解にも興味がありますが、でも、いくつかを、ええと、比較的手短に説明します。ええと、まず、ええと、まず、ええと、繰り返し情報です。ええと、たとえば互いに完全に同じコピーであるドキュメントや、非常によく似た内容を持つドキュメントがある場合です。ええと、それで、なぜこれが、ええと、なぜ、なぜこれが重要なのか。ええと、一つには、検索を行うとき、同じもののコピーを大量に取得してしまうということです。そしてそれは、ええと、言語モデルに、それが必要とする、可能な限り最良の情報セットを提供するという点では、必ずしも理想的ではありません。ええと、そしてこれと非常に相関しているのが、単により多くのコンテキストを消費するということです。
ええと、その多様性を得るためには、持っているドキュメントの数を本当に増やさなければならなくて、そうするとそれがコンテキストを占有し始めてしまいます。ええと、なので、ここで lang chain で見てきて、実装してきたもののいくつかとして、ええと、1つは、そうですね、似たドキュメントを基本的にフィルタリングするというアイデアです。つまり、大きな検索ステップを行うようなものです。ええと、そして、通常は LinkedIn ではデフォルトで、検索を行って4つか5つくらいのドキュメントを取得し、それらをプロンプトに渡します。そして一般的に4つか5つを選ぶのは、コンテキストウィンドウの長さのためで、それが妥当なデフォルトだからです。
ええと、でも1つできることとしては、基本的に20個とか30個のドキュメントを取得して、それから似ているものをフィルタリングする、ということです。ええと、埋め込みを通じてでも、言語モデルに渡すことによってでもできます。そして埋め込みは、ここではおそらくより速いユースケースです。ええと、そして、それを私たちは「コンテキスト圧縮」のようなアイデアとして実装しています。これは基本的に、ドキュメントを取得してから、入ってくるクエリに対してそれらの中の情報を圧縮するようなことを行う、というアイデアです。ええと、そして、それがここでの1つです。ええと、もう1つできることで、ほとんどのベクターストアに実装していると思うのですが、異なる種類の検索を持たせることです。
つまり、基本的に最も類似しているドキュメントを選択するセマンティック検索を行うのではなく、max marginal relevance のような別のタイプの検索があります。これは基本的にベクトルを取り、取得するベクトルを選択するときに、類似性だけでなく、すでに取得した他のベクトルからの多様性も最適化します。なのでアイデアとしては基本的に、そうですね、もし取得を始めたときにまったく同じ2つのベクトルがあったら、それらがあまり価値を追加しないなら追加しない、ということです。そこには調整できる異なるパラメータがあります。もう1つ付け加えると、ええと、ここに書くのを忘れましたが、同じくらい単純なことで、入ってくる前にドキュメントを重複排除するようなことができます。何らかの重複排除プロセスを行うことができます。それはたぶん、ええと、そうですね、つまり、その欠点の1つは、もしドキュメントが場所Aと場所Bにあって、それらを重複排除した場合、場所として何を入れるのか、ということだと思います。場所Aを入れるのか、場所Bを入れるのか。それは実際にあなたのアプリケーションにとって重要になるのか。たとえば出典を引用している場合などです。なので、そこは少しリスクが高くなります。
これについてどう思いますか、Philip？これが出てくるのを見たことがありますか？ほかにどんな手法を見たことがありますか。この3つのうち、人々が最もよくやっているのはどれだと思いますか？現時点では、ええと、少し難しい領域だと思います。ドキュメントの重複排除については、完全なパターンマッチングをしているのでない限り、ええと、埋め込みだけで判断するなら、そうですね、検索のようなことをして、わかりました、最も近い結果は何か、最も近い10件の結果は何か、というようにできます。最も近いとは何か、何が重複と見なされるのかについて、ある程度の尺度を設定し、それから削除する、ええと、そこで唯一の問題は、スコアにおける類似度のどのレベルを重複を意味するものとして設定すればよいのか、本当には分からないことです。なぜなら繰り返しますが、ベクトルの1つの、ええと、要素が完全に異なる可能性があり、つまりすべてが異なっている可能性があるからです。これらは非常に大きな、ええと、埋め込みなので、そうですね、変動は難しいです。ええと、1つ思うのは、ええと、質問がありました、ええと、圧縮に関しては後で聞きますが、もう1つ、私たちがいろいろ試したと思うのは、圧縮が、ええと、そうですね、あなたが言ったように、上位10件の結果を取り、それらすべてにわたって要約し、それをプロンプトで使う、というものだったかどうかです。つまり、ある意味、それらがそれほど正確にヒットしなくても、ええと、4つすべてにわたって要約して1つのドキュメントにし、それを次の質問で使うことができます。これは、おそらく皆さんがコンテキスト圧縮でもやっていたことだと思います。ええと、はい、あります、でもそうですね、繰り返し情報を取り除くという点では、ドキュメントがかなり似ていることが分かっていない限り、難しいです。
ええと、それは、ドキュメントの主キーに基づいてある種アップサートするだけでできますが、本当に文脈的に繰り返されている情報を取り除きたいなら、そのためのコツはまだないと思います。はい。ええと、では、私がよく出てくるのを見てきた次のこと、矛盾する情報に移ります。つまり、複数のソースに同じ答えがある場合です。これについての考え方としては、たとえばあなたのNotionデータベースでは、ええと、例えば、あなたの会社の休暇ポリシーは何ですか？という場合です。ええと、それに対する答えが、いろいろな場所にあるかもしれません。
たとえば、その答えは時間とともに変わってきたようなものかもしれません。ですから、マスターとなるようなHRドキュメントがあり、そこに答えがあるのですが、一方で1年前くらいのランダムな会議メモがあって、そこで休暇ポリシーについて議論されていて、そこにも答えがある、ということです。そうすると検索を行うと、ある場所から情報を拾い、別の場所からも情報を拾い、それら両方をコンテキストに取り込んで、そしていま言語モデルに対して、ねえ、ええと、次の情報に基づいて質問への答えを生成して、たとえば休暇ポリシーは何ですか？と尋ねることになります。そしてその次の情報には、2つの矛盾する情報セットが含まれているわけです。ええと、では、ええと、そこでどうしますか？ええと、私たちが見てきたこととしては、基本的に、ソースを検索するときに、ええと、何らかの重要性を持たせることができます。重要度の概念を組み込むことができます。上の例では、おそらくHRドキュメントに、ランダムな会議メモより高い重みを付けるでしょう。
ええと、そして取得されたドキュメントがその2つだけなら、これはあまり効果がありませんが、ドキュメントがたくさんある場合には、重要度による重み付けを追加して、それらをある程度上位にフィルタリングできます。ええと、もう1つ、おそらく少しより堅牢なものとしては、渡すことができます、まあ、ある意味ではより堅牢なのですが、ソース情報、メタデータを生成ステップに渡すことができます。つまり、生成ステップに渡すときに、単に、ええと、ほら、これは見つかったテキストのチャンクで、関連していそうです、と言うだけではありません。これはマスターHRドキュメントで見つかりました、ということも言います。そしてもう一方については、これは、ええと、たとえば2022年3月14日頃の会議メモで見つかりました、というように言います。
そして、言語モデルは曖昧な推論のようなものがかなり得意です。そうすべきで、もしあなたが、ええと、もしそれらが、そしてこれはプロンプトエンジニアリングやプロンプト構築の一部に戻るのですが、もし「矛盾する情報がある場合は、より信頼できそうなソースのものを選んでください」のように言えば、それは、そこでは役に立つはずです。ええと、矛盾する情報について私が持っているのはそれです。これが実際に起きるのを見たことはありますか？他にも何か補足はありますか。これらはすべてエッジケースのようなものなので、念のため明確にしておくと、これらが聞いている視聴者にとって非常に一般的だとは思っていません。ええと、ただ、こうしたものに遭遇し始めたときに、裏側で何が起こっている可能性があるのかについて、少し文脈を提供しようとしているだけです。
ええ、私たちにとって重要だったものの一つは、ええと、日付を取得できて、日付に基づいてメタデータフィルタリングを行える場合で、その場合、基本的に最新の知識が最良の知識だと仮定します。ええと、あなたが言ったように、それがHRが言っていることなのか、それともどこかのランダムなものが言っていることなのか、そういうケースは確かにあると思います。私たちの領域では、メタデータフィルタリング以外には、実際にはその能力はあまりありません。ええと、それはまた、実際のドメインに関するプロンプティングのようなところで、あなたの領域により近づいてきます。ええ。でも、ええ、あなたが言ったように大規模言語モデルを使えるなら、通常は、質問を分析して、HRからの回答のほうがおそらく良い、といったことを理解できます。
ええと、ただ生の、生の、本当に生の側面からすると、メタデータフィルタリングで、いくつかの結果を外に出せるかどうかを見て、ええと、望む結果を得られる可能性を高めようとする感じです。もし、たとえばランダムなフォーラムから来たものなら、ほとんどの場合、それを結果として使いたくはないので、そのデータをすべてフィルタリングします。ええと、でも本当に、データをどのように構造化できるか、事前にどんな情報を持っているかに依存します。ええと、繰り返しになりますが、重要度の重み付けでも、それを行うのはやや難しいです。ええと、なぜなら、それがどれだけ重要かについても、ある程度指定しなければならないからです。
ええと、大規模言語モデルを使いたくない場合には、そうしたメタデータを手元に持っている必要があり、その場合は、重要度の重み付けもある程度フィルタリングで対応できますが、自動的なものについては、ええと、ほぼ大規模言語モデルに戻って判断させる必要があります。ええ。次のものは、ええと、前のものに関連していて、そしてあなたが話していたことのいくつかにも関連しているのですが、単に時間性です。つまり情報は時間とともに更新される可能性があります。ええと、そうですね、休暇ポリシーはある日から別の日に変わる可能性があり、両方の文書がまだデータベースに存在していることもあります。ええと、なので、ここで見たことのある解決策としては、ええと、そのうち2つは以前のものと非常に似ていると思います。つまり、あなたが言ったような新しさによる重み付けと検索、または新しさによるフィルタリングで、それは完全にフィルタリングして除外する良い方法だと思います。
タイムスタンプを生成ステップに含めることもできます。そうすれば、言語モデルに対して、より最新の情報をより信頼するよう伝えることができます。ええと、もう一つは興味深いものです。ええと、これはすべての状況に当てはまるわけではありませんが、基本的な考え方は、リフレクションを使って、時間とともに何かに対する自分の概念を更新するというものです。休暇ポリシーの例では、ええと、それに加えて、そして、これは、そうですね、つまり、私はこれが主に会話型の設定で使われているのを見ます。チャットボットがいて、私はそのチャットボットと話していて、自分の友人Philipについて、彼が何をしているのか、何に取り組んでいるのか、そういったことを話しているような場合です。なので、ええと、Philipについて次回話すときに、私がPhilipについて言った関連する部分を検索する、というのがそのチャットボットにメモリを追加する一つの方法です。
しかし、メモリを追加するもう一つの方法は、知識グラフのようなものに似たこのアイデアを作ることです。そこにはPhilipという概念があり、Philipが誰で、何をしていて、何が好きで、そういったすべてのことがあります。そして時間が経つにつれて情報が入ってくると、そのエンティティが知識グラフ内で更新される、という感じです。そして私は、ええと、これには多くの欠点があると思います。ええと、その、そのリフレクションのステップでは言語モデルを使うので、コストがかかり、よりお金がかかり、少し遅いです。うーん、なのでまだ非常に実験的だと思いますが、でも最後に話す論文、generative agentsの論文では、うーん、このテクニックが使われています。
うーん、なので、現時点ではそれは少し研究寄りだと言えるでしょうが、とても、とてもクールだと思います。そして他の2つはもう少し実用的です。うーん、ここにさらに付け加えることがあるかはわかりません。これは以前話したものとかなり似ています。そうですね、主にタイムスタンプベースや日付ベースのようなものです。
うーん、私の感覚では、いったん取り込み始めると、もしLMSsを取り込むための資金があるなら、ベクトルと一緒に保存したメタデータに対してもLMSを使って、ああ、これを組み合わせたいかどうか、を判断することもできます。そして更新し続け、upsettingし続けるような感じです。でも、私たち側の話で言うと、私たちはある意味、私たちの一連のことに関する問題は、できるだけ生データだけに基づいてやろうとしていることです。うーん、得られるデータのようなものに基づいて、うーん、できるだけ多くのl l m呼び出しを避けようとしています。なぜならそれは高くつくからです。そうですね。うん。うーん、これは最近追加したクールなものです。うーん、基本的に、質問はコンテンツよりもメタデータに関するものである場合があります。
うーん、なのでこの例としては、たとえばユーザーの質問が、「1980年のエイリアンに関する映画は何ですか」のような場合です。semantic content。そして、さらに一歩引いて説明すると、embeddingsは物事の意味的な意味を捉えるのが非常に得意です。それらはテキストの密な表現を作ります。うーん、そして、そして、ええと、その意味的なもの、ユーザーが探している概念はエイリアンに関連する映画ですが、もう一つ別のものがあり、それは私たちが呼ぶところの基本的にメタデータフィルターのようなもので、つまり、年を1980のように設定したい、ということです。うーん、これは非常に完全一致タイプのものです。
うーん、それは、ええと、これは当然スキーマに完全に依存しますが、たとえばこれはクエリしたいスキーマ内のフィールドである可能性が非常に高く、基本的にそれに基づいて結果をフィルタリングしたいわけです。うーん、そこで私たちは基本的に、セマンティック検索の取得を行う前に、それを実際に2つに分割する、ある種のself queryメカニズムを追加しました。それをメタデータフィルターに分割し、それから、それを、クエリ自体に分割します。うーん、なのでこの場合、exact match year equals 1980のようなメタデータフィルターが得られ、それから、その、クエリが得られ、それはこの場合だとaliensか何かのようなものになるでしょう。そしてそれを、そして、そして次に、メタデータフィルターをどのように適用するかという問題があります。多くのvector storesには、ええと、メタデータフィルターを渡す方法があるので、それをクエリ内で直接行うことができます。
うーん、もしそれがうまくいかないなら、おそらく取得から出てきた後で物事をフィルタリングすることもできます。でもほとんどすべてのものには、ええと、メタデータフィルターを渡す方法があります。うーん、そして基本的に、そのメタデータフィルターを、生成されたaliensクエリと一緒に渡します。うーん、そしてそれはある意味で両方の良いところを組み合わせます。この、ええと、この、ええと、ええと、ええと、適用できる完全一致フィルターとともに、セマンティック検索を得られるのです。
自己挿入で反対側でもそれをやってみたことはありますか？つまり、自分の挿入のバッチを取って、それから挿入したいもののスキーマみたいなものを生成できるわけです。つまり、フィルターについては、どのカラムでフィルタリングしたいかを抽出できるかもしれなくて、その後クエリについても同じことをする。そしてスキーマで見たものに基づいて判断できる。おそらく高くつくでしょうけど、データからどんなメタデータを取り出したいかを判断できるというのは面白いですね。ええ、それは、私たちはまだやっていませんが、まさに今あなたが言ったような形で考えたことはあります。つまり、ドキュメントからどんなメタデータを付与すべきか、ということです。うん、ええ、それは、メモしておきます。ええと、今すぐLanceにSlackします。
ええと、取り込み時にメタデータを抽出する。よし、そこに何か追加しておきます。それは本当に良いアイデアです。ええ、というのも、これは取り込みの部分に戻る話だと思うんですが、ええと、たとえ、そうですね、たとえこの自己クエリをやっていなくても、この強化されたメタデータのようなものがあるのは本当に、本当に有用ですよね。だから、ええ。ええと、Stanが、ええ、誰だったか、たしか、これを持ち出した人がいて、Zapierの誰かと話していたと思うんですが、その人も似たようなことを持ち出していました。
なので、これで2人目です。ということは、これは間違いなくやらないといけないということですね。私が見える唯一の問題は、その場合メタデータのためにLLM呼び出しをして、さらに埋め込み呼び出しもすることになって、残念ながらコストが高くなっていくことです。ああ、そうですね。でも、ええ、ええ、ええ。とはいえ、私は、ええと、全体のスピードを考えると、LLMのコストは下がっていき、レイテンシも時間とともに下がっていくと、おそらく信じる必要があると思います。
それに、もう一つ言うと、すべてのユースケースでこれを行う必要はないですよね。必要に応じてこれを行えばいい。本当にその通りです。ええ。望む形で、という感じです。今のこの分野で重要なのは、何でも正しく行う唯一の方法というものはないということだと思いますよね。そうです。
私たちがLangChainをどう見ているかというと、その多くは単にこれらのコンポーネントであり、いろいろなユースケースに使える、ツールベルトの中の道具のようなものだと思っています。なので、これを本当に重視したくて、こうした識別可能なメタデータのようなものを持つことが本当に重要なら、それは選択肢の一つです。でも、それが正しいことだという意味ではありません。繰り返しますが、セマンティック検索は、少しの間で80%くらいのところまで連れて行ってくれる、あるいは80%のユースケースではそこまで到達させてくれます。なので、ええ。すばらしいです。
ええと、マルチホップ質問。これもまた、1つのものの中で複数の質問をしている可能性があるケースです。なので、こういう質問の例はたくさんあると思います。いくつかは、ええと、最初にこれについて考え始めたのは、reactの論文が出たときだったと思います。これは行動における推論を相乗させるもので、エージェントの初期バージョンです。基本的には、こうした質問がありますよね。たとえば、カンザス州の州都の人口は何人ですか？そうすると、まず「カンザス州の州都はどこですか？」という質問があり、その次に「その都市の人口は何人ですか？」という質問があるわけです。なので、ええと、ここでのセマンティック検索の問題は、元の質問だけを検索すると、一方の部分だけ、またはもう一方の部分だけを引っ張ってくるかもしれないし、州都の人口については引っ張ってくるけれどカンザス州のものではないかもしれないし、カンザス州の州都は引っ張ってくるけれど人口情報はないかもしれない、ということです。なので、ええと、基本的にはこのようなマルチホップ的なことを行う必要があります。
ええと、それでエージェントというのは単に、つまり、質問を複数のステップに分解する、という言い方の一つです。ええと、それで言語モデルを推論エンジンとして使います。まず最初にどの情報を調べる必要があるかを考える。よし、Kansasの州都はどこか？それから二番目にどの情報を調べる必要があるかを考える、よし、その都市の人口は何人か？そして、それらを別々のクエリで実行する。ちなみに、これらのクエリの一部は同じデータベースに対するものではないかもしれませんよね？つまり、1つはベクトルストアに対するもので、もう1つはSQLテーブルに対するもの、ということもあり得ます。
そして、これは検索に使える汎用化可能なエージェントのようなアイデアに、どんどん近づいていきます。ええと、そして繰り返しになりますが、話したように、l l m 呼び出しがかなり積み上がりますし、ええと、少し脱線しやすくもなります。なので、だから、これはやはり、ここで道具箱に入れておける、もう一つのツールだと思います。素晴らしいですね。ええ。
l m 呼び出しが積み上がる話で言うと、取り組みがあるのは知っていますし、私たちも L l M 呼び出しのキャッシュのようなものに取り組んできたのは知っています。今ではそれも link chain に含めていると思いますが、G BT cash。ええ。GG cash。ええ。
素晴らしいプロジェクトですね。ええ。うまくいけば、こうした、ええと、ユースケースに役立つといいですね。というのも、誰にも分からないですが、同じ最初の質問を何度も送っているかもしれないからです。Kansasの都市について複数の質問をしていて、それを分割しているなら、たぶん、キャッシュに何度かヒットして、少しお金を節約できるかもしれませんが、誰にも分かりません。まったくその通りです。素晴らしい。
ええと、いいですね。では、最後にすごく手短に話したいことがあって、ええと、そのあと残りの時間はたぶん質疑応答に移れると思いますが、ええと、ええと、gender if agents についての論文です。ええと、これはStanfordから1か月、2か月ほど前に出たものです。基本的なアイデアは、互いにやり取りするさまざまなエージェントのシミュレーションを設定した、というものです。ええと、ちょっとThe Simsみたいな感じです。つまり、25体くらいの異なるエージェントがいました。それぞれが、ええと、それぞれ独自の、ええと、それぞれが自分の行動を取ることができて、そして、それぞれが基本的に独自の記憶のようなものを持っていました。
ええと、それで彼らがその記憶をどう扱ったかは、かなり興味深いと思います。というのも、ある意味で記憶というのは、本当に適切なタイミングで関連情報を検索することのようなものだからです。ええと、そして、彼らがどうやったかは、かなり興味深く、見ると非常に参考になると思います。そして彼らは、概念を使いました。つまり基本的に彼らがやったのは、これらすべての観察を持っていて、ええと、それから基本的に関連する観察を取得し、エージェントが次に何をするか決めるときにそれらをコンテキストに入れる、ということでした。ええと、そして、このリトリーバーの中で正確に何が起きていたのか？いくつか異なるコンポーネントがありました。ええと、関連性のコンポーネントがあり、ここでセマンティック検索の部分が関わってきます。
つまり彼らは、現在の状況と過去の状況との関連性のようなものを計算し、過去の状況に関する情報を取り込んでいました。ええと、重要度も関わっていたので、より重要な情報のようなものを取得していました。ええと、そして、あなたの指摘したような、つまり、これを自動化された方法でどう行うのか、という点については、ええ、彼らは言語モデルを使って記憶に重要度を割り当てていました。なので、彼らは、彼らは、つまり、ええと、その追加コストが、ええと、そこに発生していました。ええと、それから最近性もまた別の要素だったので、より最近のものにより大きな重みを与えていました。ええと、相反する情報を重複排除しようとする目的とか、そういうことのためではなく、ただ、つまり、より最近の記憶のほうが、あるいは、おそらくより関連性が高いからです。
それを取り込むわけです。そして、それに加えて、彼らが追加したもう一つのもの、これは先ほど話に出たもののいくつかに似ているのですが、リフレクションのステップでした。つまり、彼らはある種のリフレクションのステップを持っていて、各時点で過去について、つまり観察などについてリフレクションを行い、それを記憶として追加していました。そしてその後、これを取り込み始めるのですが、彼らはそれをあらゆる観察と同じように、他のすべての観察と同じように扱っていました。つまりリトリーバーの観点では、リトリーバーについては何も変えていませんでした。
リトリーバーは依然として、関連性、重要性、最近性のようなものの組み合わせでした。ただ、今や彼らが取得していたものは、単なる個別の観察だけではなかったということです。その中には、それら個別の観察に対するリフレクションも含まれていました。ですから、それらについて、より高次の推論のようなものを取り込む一つの方法だったわけです。ええと、繰り返しになりますが、これは研究論文でした。
ですので、これはおそらく、いわゆる本番環境で使えるものではありません。でも、より複雑なタイプの検索が、非常に興味深く動的なシミュレーションや状況をどのように支えられるかを見るうえで、とても面白いものだと思います。チャットで、その論文へのリンクか論文名があるかという質問がありました。はい、確か Generative Agents という名前だったと思いますが、リンクを探して、そこに貼ります。Generative agents, interactive SRA of human behavior。チャットに貼ります。
あ、誰かが先に貼ってくれましたね。はい。素晴らしいです。ええと、いくつかQ&Aの質問があるので、それらを見ていきましょうか。はい、スライドがまだあるかどうかは分かりませんが、ええと、それが私の用意していたもののすべてです。他に話したほうがいいと思うことがなければ。
それでだいたい、lmにおけるメモリの要点はつかめたと思いますが、ええ、ではこれらを見ていきます。まずは大きな質問から始めましょう。ええと、将来のl Lumsは、モデルの推論能力とモデルが保持する知識を分離することにある、という考えがあります。これは、タスクについて推論することに長けたモデルにつながりますが、あらゆることについてすべての知識を持っているわけではないかもしれません。そして、これが将来、人々がLMSsを使う方法だと見ています。これについてどう思いますか。このシナリオの例をいくつか議論してもらえるとよいかもしれません。はい、そうですね、つまり、私は確かにかなり妥当性があると思います。これは、検索拡張生成のような考え方の多くの基盤になっていると思います。
つまり、関連するコンテキストを取り込み、そのうえで言語モデルに、関連するコンテキストと質問について推論し、単に重みの中にある情報を使うのではなく、答えを提供するよう求めるわけです。ええと、ありますね、つまり、そうですね、はい、確かにあります。そう考える非常に妥当な理由はたくさんあります。もちろん、これを行う必要のないアプリケーションもたくさんあります。たとえば言語モデルは会話をするのが得意ですし、もしかすると、ここで一つ区別をするとすれば。
つまり、その、あなたは言語モデルと、その推論能力のためにやり取りしているのか？ ええと、それとも、エンターテインメントとか何かそういう目的で言語モデルとやり取りしているのか？ ですよね？ だから、その、たとえば character ai を見ると、彼らのキャラクターの多くは、ええと、エンターテインメント目的ですよね？ それで私は、彼らが、こういう、その、検索拡張生成みたいなことを、そこに入り始めたときにあまり多くやっているとは思わなくて、それから、ほら、人々は chat g P T を多くの情報のために使っていますよね？ そしてそれは、その多くについてかなり優れていて、かなり事実として正しいものを返します。 そして彼らも皆そこにいて、L l m の根底にある、その、ええと、事実性のようなものを改善するための取り組みも行われています。 つまり、単に作り話をしないようにするためです。 ええと、たとえ作り話をせず、幻覚を起こさない言語モデルがあって、そしてそれが知っていて、そして質問への答えを知らないときには、今の状況のように作り話をするのではなく、単に知らないと言うとしても、ええと、それでもおそらく、あるいは、言語モデルを他のデータと組み合わせるというこの考え方は、依然として非常に重要です。なぜなら、モデルが訓練されていないデータは常に存在するからです。 そしてその場合の選択肢は、そのデータでモデルを訓練することになります。
現時点でのファインチューニングは、この多くの、この、この rag、検索、拡張生成スタイルのものよりもはるかに高価です。 ええと、つまり長々と言うと、私は、ええと、質問は LLMs の未来についてだと思うのですが、私は、未来について予測することには本当に慎重です。なぜなら私は本当に何も知らないからです。 ええと、でも私の推測では、おそらく、将来何らかの形でこれのための場所は間違いなくあるでしょう。 ええと、次のものを取り出します。 それで、誰かが会話メモリについて質問していました。
ええと、私たちは以前の、ええと、会話をどのように保存しているのか、そして、ええと、それらはより構造化されていて、ええと、自由形式の会話よりもずっと優れています。 なので、たぶん、はい、会話メモリ、つまり、これを保存し、そこから取得するためのルートが何か、ということですね。 はい。 ええと、つまり、今みんなが会話メモリでやっている基本的なことは、ええと、以前のメッセージと会話のバッファを保持するだけです。 だから最も、それは完全に新しさに重みづけされています。
ええと、Jet G P T がやっているのはかなり確実にそれだと思います。 character がやっているのもかなり確実にそれだと思いますが、間違っているかもしれません。 ええと、でも彼らは直近のメッセージのこのバッファを保持しているだけだと思います。そして、コンテキストウィンドウが長くなるにつれて、そのバッファをより長い期間保持できるようになる、などなどです。 ええと、私は、ええと、それを拡張することについて話すと、そうですね、同じことがすべて当てはまります。 ええと、できると思います、つまり、あなたが指摘したように、それらはいくつかの構造化された情報よりも構造化されていません。
ええと、ええと、これは実際に本当に良い質問です。 はい。 私は、私は、検索をどうしたいかという点での違いについて、あまり深く考えたことがありません。 おそらく、各メッセージをドキュメントとして扱うのではなく、会話を、ええと、1つのドキュメント全体として扱いたいのだろうと思います。 ええと、おそらく会話の中でかなりの量の重なりを持たせたいでしょう。もしかすると、構造化されたドキュメントよりもなおさらです。
ええと、でもそれは本当に良い質問です。 あまり詳しく考えたことはありません。 ええと、チャンクについてのもう1つは、長いドキュメントの場合です。 要約に使うべき最良の末尾チャンクを選択する方法はありますか、ええと、rector stores を活用して？ ええと、これについて考える最善の方法は何ですか？ つまり、必要ないものをある程度フィルタリングする方法はありますか？ はい、つまり、私は、ええと、その、まあ、1つには、ある程度、それはあなたがそれに尋ねたい質問に依存します。 ドキュメントを要約するように求めているなら、おそらくドキュメント全体を、に、に、に、入れたいでしょう、つまり、使いたいでしょう、ドキュメント全体を使いたいでしょう。もしそれについての質問のようなものを抽出しようとしているなら。
ええと、それなら、ベクターストアを使うことは、ええと、それを行うためのとても自然な方法を提供すると思います。ある種、それをチャンクに分割するような感じです。ええと、重要なチャンクだけを取得します。高いレベルのチャンク数を設定するわけではありません。ええ、なので、私は、私は、私は思うのですが、それにどんな質問をするかに少し依存すると思います。
それから、チャンクをどう決めるのか、ということもあると思います。ええと、これは最初のポイントに戻るのですが、現時点ではすべてがヒューリスティックな空間のようなものです。このあたりには、ある種、決まったものがありません。たとえば、Lance Martin が作った auto evaluator へのリンクを貼らせてください。あれは本当に良いです。そこで、かなり簡単に、ええと、このすべてのさまざまなバージョンを実験できます。
ええと、それで、はい、私は、ええと、ええと、今それをチャットに入れました。ええと、なので、それは、ええと、私は、私は思うのですが、かなり良い方法だと思います。ええ、基本的には、そこには、万能の答えはありません。いろいろなことを試して、自分に何が合うかを見るべきです。そして auto evaluator はそれを行う良い方法です。それからもう一つ、ええと、圧縮戦略が実際にどれほど効果的かについて何か印象はありますか？なので、これは圧縮についてだと想定します。
はい。ええと、つまり、まだかなり初期段階だと思うので、ええと、それは、ええと、正直な答えは、わからない、です。確実に機能するエッジケースはあると思います。私は、思うに、つまり、大きな問いは、こういうものが機能するという点については議論の余地はないと思います。問題は、ROI とか、そして、ほら、それによって発生するコストの面でも効果的なのか、ということだと思います。そして、その点についてはまだ結論が出ていないと思いますし、おそらくアプリケーションによって少し変わると思います。
それから、ええと、情報の重み付けはどのように機能するのか、プロンプト内のメタデータレベルでどう実装するのか？ええと、はい。はい。では、つまり、具体例をいくつか取り上げると、generative agent の論文では、意味的類似性に基づいて検索ステップを行い、それから重要度を組み込んでそれらを再ランク付けしました。ええと、それに加えて、まあ、重要度スコアの前にいくつかの lambda があり、類似度スコアの前にもいくつかの lambda があり、さらに新しさスコアに関してもいくつかの Lambda があったと思います。ええと、なので、一般的には、つまり、つまり、それが一つのやり方でしょう。基本的には重要度スコアと類似度スコアを組み合わせて再ランク付けし、その再ランク付け後に上位 3 つか 4 つのドキュメントを取る、ということです。
ええと、プロンプト内で行うこともできます。ええと、これは少し、私は、まあ、generative agents はこれの非常に具体的な応用例ですが、ええと、ええと、プロンプトに入れる場合は、あなたは、あなたは、言語モデルにそれにもっと注意を払うよう伝えるために、ある程度のプロンプトエンジニアリングを行う必要があります。ええと、これは実務ではそれほど多く見たことがありません。ほとんどは、ドキュメントを取得した後の再ランク付けや並べ替えのようなものでした。さて。
ええと、generative agent の論文で説明されているコンポーネントに関して、そのような概念は、有用なアプリケーションへと構成できる一般的な高次の抽象化にどの程度うまく対応しますか？コストは予見可能な将来において本質的に問題になりますか？ええと、つまり、私は思うに、その、ええと、コストに関しては、正直なところ、ほとんどのことにとって最大のブロッカーは、ええと、やはりプロダクトマーケットフィットを得ることだと思います。正直に言うと。ええと、機能して有用なものを作ることの方が、コストよりも大きなブロッカーだと思います。ええと、その後にはコストが、はい、おそらく問題になります。ええと、ええと、でも、でも私は、たとえコストを脇に置いたとしても、このタイプのメモリやこのタイプの検索に本当に深く取り組んで、そして、そして、そして、そして、そして、そこで本当に最適化しているプロジェクトをあまり見たことがありません。ええと、それが質問の後半でした。
質問の最初の部分は何でしたか？ええと、この概念は、一般的な高次の抽象化にどれくらい当てはまり、有用なアプリケーションに組み合わせられるのでしょうか？両方の質問に答えたと思います。ええと、それからもう一つは、AIとの親密でプライベートな関わりへと向かう進化するトレンドについて、あなたの見解は何ですか？AIシステムに委ねられる会話が増えています。通常なら完全に人間同士だけで行われていたであろう会話です。これらのやり取りが安全でプライバシー中心のままであることを保証するために、信頼ベースのメカニズムをどのように設計し実装できるでしょうか？はい、いい質問ですね。まず前置きとして、私は実際のところよく分かっていないので、この後に私が言うことはすべて、話半分に受け取ってください。ただ、思うに、ええと、ぱっと思いつくだけでも、本当に大きな要素が2つあると思います。
ええと、1つは、そうしたよりプライベートで親密な会話において、言語モデルが本当にいかなる形でも有害なことを提案しないようにすることです。そうですよね？こういう種類の会話をしているなら、それが有害だったり、あるいは暴力などにつながり得るようなことを言うべきではありません。ええと、なぜなら本当に、つまり、ランダムな文書に対する質問応答のようなものとやり取りしている場合とはまったく違うからです。そこでのリスクははるかに高いです。そしてもう一つは、つまりそれは安全性に関するものかもしれませんし、これは、ええと、基盤となるモデルそのものの安全性により近いものだと思います。それから、このシステム全体のプライバシー、おそらくプライバシーの問題があります。ええ、ですから、自分のデータが、ええと、可能な限り安全であることを確保することです。
ええと、これは、ええと、ローカルにデプロイされたLLMを意味するのでしょうか？ええと、そうかもしれませんし、クラウドのものの一部について、より良いプライバシーポリシーを意味するだけかもしれません。それはおそらくリスク許容度によります。ここについては、ええと、私には非常に強い意見はありません。明らかにローカルLLMが理想的だと思います。ええと、ただ、それが100%障害になるのかどうかは分かりません。もし本当に優れたセキュリティ対策が導入されているなら、私たちは多くの個人情報をクラウドにも委ねていますから。ええ。いいですね。本当にいい質問だと思います。もう1問分の時間があります。
ええと、あー、はい。セマンティック検索に基づく要約と推論にLMSを使う場合、その特定の目的におすすめのオープンソースモデルはありますか？ええと、私が少しでもうまくいったことがある唯一のもの、唯一のものは、ええと、mosaicsの、ええと、M P T 7 Bモデルです。ええと、いくつか他も試しました。これは、まあ、私はあまり実験していません。UNAは悪くないと思います。
ええと、だから、ないですね、言い直します。M P T 7 Bがうまくいった唯一のものではありません。ええと、vicunaと、それから、そのモデルの2つは、少しうまくいったことがあると思いますが、オープンソースの時代としてはまだ本当にごく初期です。ですので、おそらく、もっとたくさん出てくるでしょう。素晴らしいです。
ええと、時間になったと思います。おそらくあと4つ質問があり、後で回答を得られるかもしれません。たぶん、ええと、時間を大きく超過しすぎないように、ええと、Emilyがどうしたいか分かりませんが。はい、あなた次第です。Harrison、もしあと数分余裕があれば、もう少し質問を受けても構いませんが、もし移動しなければならないなら、その質問への回答を載せたフォローアップブログをおそらく出します。私は、私は行かなければなりません。ここに呼んでいただいて本当に感謝していますが、行かなければならない予定が重なっています。もちろん分かります。ええと、fellow Paris、本当にありがとうございました。とても素晴らしいセッションでした。ええと、聴衆の皆さんからの素晴らしい質問すべてに感謝します。ええと、今後の、ええと、Zillow'sのウェビナーでまたお会いできることを願っています。そしてそのブログ記事にもご注目ください。残りの質問に回答できるよう最善を尽くしますし、それはZillow'sのブログでご覧いただけます。皆さんありがとうございました。ありがとうございます。ありがとう、さようなら。