You’re in!
ウェビナー
評価により、より優れた検索拡張生成アプリケーションを構築する
本日は、今日のセッション評価「Builds BetterRetrieval」、拡張生成アプリケーション、そしてゲストスピーカーのJosh Raineyをご紹介できることを嬉しく思います。JoshはオープンソースであるTrue Lensのコアコントリビューターであり、Truの創設期からのデベロッパーリレーションズ担当データサイエンティストです。Truでは教育イニシアチブを担当し、実践者の活発なコミュニティを育成しています。AI品質に情熱を注いでいます。Joshは、Global AI Conference 2023、New York City Dev Day、2023 LLMs、そして2023年のRegenerative AI Revolution、AI Developer Meetups、AI Quality Workshopなどのイベントで、1,000人以上の開発者に向けて技術講演やワークショップを実施してきました。ライブ形式とUdemyを通じたオンデマンド形式の両方で提供しています。Tru以前は、Joshは国務省やWalter Re、national Military、ええと、medical Centerを含むクライアントに対して、エンドツーエンドのデータ、機械学習、ソリューションを提供していました。
ようこそ、Josh Rainey。素晴らしい。ありがとう、Eugene。呼んでくれてありがとう。ここに来られて本当に嬉しいです。
はい。いいですね。ええと、そうですね、Eugeneが言ったように、今日は評価がどのようにより良いRAGを構築するかについてお話しします。ええと、なので、最初にちょっと楽しいことから始めようと思いました。少しリサーチをして、Zillowsが取り組んでいることを本当にきちんと把握しておきたいと思いました。
それで、ええと、私はアシスタントのClaudeに聞きました。「Zillowsを創業したのは誰？」と。ああ、ええと、あれ、ああ、ミュートになっていますか？はい。いいえ、いいえ。でも、ええと、画面を共有してもらえますか？ああ、はい、はい、はい。ええと、すみません。ありがとう。
いいですね。今見えていますか？はい。いいですね。では、ええと、私はアシスタントのClaudeに聞きました。「Zillowsを創業したのは誰？」と。ええと、すると、ええと、あまり回答らしい回答は得られませんでした。
ええと、つまりZillowsを創業したのが誰かは知らなかったのですが、ええと、Zillowsはブロックチェーン企業だと言いました。ええと、Eugene、これを事実確認してもらえますか？はい。ええと、Zillowsはブロックチェーン企業ではありません。私たちはVectorデータベース企業です。なので、そうですね、実際これをどうやって思いついたのかまったく分かりません。そうですね、彼らは、LLMが本当に得意な、もっともらしく見える答えを作り出そうとする感じなんです。
ええと、そしてこれは後でも少し見ることになります。ええと、それでZillowを創業したのは誰かを聞いた後、もしかすると次に、ええと、Zillow'sは何をしているのかも聞いてみたいと思いました。ええと、いくつか箇条書きで教えて、と。ええと、いつ創業されたのか、ええと、どこに本社があるのか、ええと、どれくらい資金調達したのか。ええと、主なプロダクト提供や顧客にはどんなものがあるのか、ええと、Zillow。なので、Eugene、これもまた事実確認してもらいます。はい。
ええと、見てみましょう。なので、AIインフラストラクチャと機械学習運用のためのソリューションを開発している、というのは厳密には間違っていないと思います。それは私たちの公式な位置づけではありませんが、AIインフラストラクチャ向けのソリューションは開発しています。ええと、私たちは2017年に創業され、シリコンバレーに本社があります。なので、それは正しいです。ええと、メインプロジェクトはvissです。
ええと、そしてVissはオープンソースです。オープンソースのベクターデータベースです。私たちは、データベースシステムは類似検索エンジンとは少し異なると考えています。ええと、私たちは現在4,300万以上を調達しています。ええと、でもfive yは少なくとも正しいと思います。ええと、Hillhouseも正しいと思います。
ええと、他にここに何があるか見てみましょう。ええと、私たちにはML ops hubはありません。ML ops向けのML hubもありません。ええと、Zillows managed viss for fully managed vissというのは、Zillow's cloudを説明する非常に興味深い言い方ですが、まあだいたいそういうものです。かなり冗長だと思います。
はい。ええと、つまりこれは部分的には正しく、部分的には間違っています。わかりました。ええと、では今、最初のものを覚えているなら、それは、Elizabethについてもう少し文脈があればもしかすると、と言っていましたが、創業者が誰かは知りませんでした。ええと、ではもう一度試してみましょう。
ええと、同じ質問をしました。ええと、するとここでは、ええと、5人の名前が出てきます。ええと、Eugene、これらが実際に創業者なのかどうか教えてもらいます。はい。私たちの創業者は、ええと、創業者は、ええと、Charles Schiffです。
そして、これらの人たちは誰一人として、これらの名前は一つも。実はつい直前に調べたばかりなんですが、これらの人たちは誰も私たちの会社で働いてすらいません。つまり、これらの名前は私たちの会社のディレクトリに存在しないので、どうやってこれらの名前を思いついたのかまったくわかりません。はい、つまり、ええと、大規模言語モデルは、もっともらしく聞こえる答えを考え出すのが本当に得意なんです。
ええと、つまり、Zilla が中国企業だと知っているので、中国人らしく聞こえる名前をいくつか思いついたわけです、うーん、でも、ええと、そしておそらくこのようなソフトウェア会社をよく創業する人々に関する説明のようなものもいくつか。うーん、でも Yugen が言ったように、完全なハルシネーションです。ええと、だからそれが、私のホットテイクで、今回の例を見た今では少しだけホットさは弱まるかもしれませんが、大規模言語モデルはそうでないと証明されるまではハルシネーションを起こすものだと考えるべきだ、ということです。うーん、それはなぜか？ですよね？ええと、研究ではモデルを汎化に向けて最適化してきました。
うーん、そして同時に、記憶することに対してはペナルティを与えてきました。ええと、つまり、ええと、これによって私たちは非常に厄介な状況に置かれています。これらのモデルに事実を出すよう求めている一方で、ええと、かなり創造的であることも求めているわけです。うーん、そしてそれは、あの本当に小さな重なりのようなもので、ええと、そのような黄金の領域を見つけるのは非常に曖昧になり得ます。うーん、ですからこれに対する解決策は、これらのモデルを一般的なタスクに集中させることです。ええと、これらの一般的なタスクとは、要約、埋め込みの技術的生成、推論と計画の実行のようなもので、そして記憶は何か別のものに任せることができます。
ええと、つまりその別のものというのは知識ソースになります。ええと、これらの知識ソースは、Zills や vis のようなベクトルデータベースであり得ます、うーん、また、検索エンジンへの API のようなツールでもあり得ます、うーん、Yelp のような独自データベースでの検索かもしれません、うーん、あるいは Yahoo Finance。うーん、ではこれをどうやって全部つなげるのでしょうか？ええと、これは、ええと、rag の典型的なアーキテクチャのようなものです。うーん、retrieve augmented generation は、ええと、私たちのベクトルデータベース、ええと、そして知識ソースを QA アプリケーションに組み込むための、ええと、一般的なアプローチのようなものです。うーん、これは基本的には、ええと、ユーザーの質問から始めて、生成し、そして、質問の埋め込みを生成することで機能します。
うーん、そしてその埋め込みをベクトルデータベースに持っていき、ええと、そのクエリ埋め込みに最も近い、ええと、チャンクを検索します。そして、ええと、それらのチャンクを取得し、ええと、それらを私たちの LLM に返し、それからその、ええと、LLM または補完エンジンを使って、ええと、最終的な応答を返します。ええと、でも問題になり得ることはたくさんあります。ええと、時には、ええと、この、ええと、検索が無関係なコンテキストを取得することがあります。ええと、しかし別の場合には、時には、ええと、十分なコンテキストが得られないこともあります。
そしてこれらすべてがハルシネーションにつながり得ます。ええと、そこで、私たちが、ええと、自社のウェブサイトと会社のドキュメント上に rag を構築した例があります。うーん、それで私たちは、ええと、Chaac は誰か、と尋ねました。ええと、彼は私たちの創業者の一人です。うーん、これらの最初の数文は正しいです。うーん、つまり Chaac がコンピューターサイエンティストで、CMU で PhD を取得した、などなど、ということを知っています。
しかしそれから、彼が Bank ofEngland の AI public private forum のメンバーであるという詳細も書き加えました。うーん、そしてこれは、ええと、この情報が私たちの、ええと、チームの別のメンバーである Shameik に関するものだからです。うーん、つまり Shameik と Shak はベクトル空間内で似たような位置に配置されていたわけです、ええと、おそらくトークン化のされ方が原因です。うーん、だから私たちは、その両方を取得し、うーん、それからそれらを私たちの LM に与えたところ、それがそれらを組み合わせて、もっともらしい創業者に関する答えにしたわけです。うーん、Josh、ここで質問したいです。
はい。うーん、皆さんがこの IO みたいなものを構築するために、その、その、その、ベクトルデータベースに渡したデータは何ですか？この QA のものですか？はい。私たちは、ええと、自社の会社ウェブサイトと TRU Lens のドキュメントをインデックス化しました。わあ。なるほど。
いいですね。うん。うーん、つまりこれが、あの、核心的な問題です。ええと、私たちは Tru Lens を、そのために構築しました。Tru Lens は LLM 実験を追跡し評価するためのオープンソースプロジェクトです。うーん、そしてこれが一般にどう機能するかというと、ええと、アプリケーションを構築したら、ええと、True Lens に接続して記録のログ取得を開始できます。
ええと、そして入力、出力、ええと、中間ステップのすべて、ええと、後で評価したり検査したりしたいかもしれない、ええと、スパンと呼ばれることもあるものをログに記録します。ええと、これらに、ええと、フィードバック関数と呼ばれるものを追加して、アプリケーションが実行されるたびにその品質を評価します。そして、ええと、そうしたら、レコードを探索し、評価結果を理解し、反復して、採用したい、ええと、最良のアプリケーションバージョンを選択できます。ええと、ではこれはLMM Opsスタックのどこに当てはまるのでしょうか？ええと、私たちはこのオブザーバブルなオブザーバビリティ層に位置しています。ええと、ええと、TruLensは、開発、ええと、サイクルにおける、この、ええと、デスクテストとデバッグの部分に焦点を当てます。
そして、本番環境で監視し、スケールする必要があるときは、ええと、Truを備えた、ええと、よりマネージドなプラットフォームに頼ることができます。ここでもう一つ質問したいのですが、ちょっと刺激的な意見になるかもしれません。はい。ええと、そのスライドに戻ってもらえますか？ええと、はい。これですか？はい。
はい。わかりました。ここでfeature storeに取り消し線が引かれていますね。うんうん。なぜですか？ああ、ええと、これは一種の、ええと、古いML lopsからLM opsへの、ええと、移行を考えると、これは、その、切り替わりのようなものです。
ええと、ああ、わかりました。では、その、予測というか、または、そのパターンは、業界でこのパターンが見えているということですか、それとも、M ML opsまたはLM opsが進化している方向についての、あなたの予測のようなものですか？ええと、はい。これは今のところ業界で見てきた、そのパターンのようなものです。なので、例えば、ええと、考えてみると、ええと、こうしたLMMアプリでは、もはやそれほどエンジニアリングのようなことは実際にはあまりしていませんし、それから、コンピュート層では、ええと、ほとんどの場合、自分たちのモデルを訓練すらしていません。単に事前学習済みモデルを使っているか、APIを呼び出しているだけです。
わあ。なるほど。とても興味深いです。それは見たことがありませんでした。すごくクールですね。
いいですね。はい。素晴らしい。はい、それは、私たちがどこから来て、それが古いスタックのようなものとどう比較されるのかを考えるのはいいですね。なので、そこではある意味有用です。
ええと、いいですね。では、これらのRAGのハルシネーションをテストするにはどう考えればよいでしょうか？ええと、私たちはこれを使うのが好きです、ええと、ハルシネーション・トライアド、またはRAGトライアドと呼んでいるものです。ええと、これはアプリケーションが実行されるたびに、そのアプリケーションの経路を、ええと、クエリから、ええと、取得されたコンテキスト、最終的なLLM応答まで、たどるようなものです。最初に確認したいのはコンテキストの関連性です。ええと、ここでは、このコンテキストが、ええと、クエリに関連しているかを知りたいのです。質問に答えるために使う適切なチャンクを取得できているでしょうか？そして、ここで確認したい2つ目のことは、ええと、その応答が、私たちが取得しているコンテキストからの証拠によって完全に支えられ、裏付けられているかどうかです。それとも、その、ええと、証拠の上にある意味ハルシネーションしているのでしょうか？そして最後に、この2つを行ったら、私はまた知りたいのです。この最終回答は、ええと、実際に質問に答えるのに役立っているのでしょうか？場合によっては、ええと、私が、ええと、質問をして、適切なコンテキストチャンクを取得し、ええと、それらを根拠のある応答にまとめることがあります。
しかし、結局のところ、それでも質問に答えていないかもしれません。ええと、なので、この3つすべてを確認することで、ええと、ある意味、ええと、検証可能にハルシネーションをチェックできます。では、ここで特定できる、ええと、一般的な失敗モードにはどのようなものがあるでしょうか？最初にお見せしたいのは、ええと、検索の失敗です。ええと、ここではWikipediaデータに基づいて構築されたRAGがあり、ええと、ホノルル近郊で最高の国立公園はどこですか？と尋ねます。ええと、そしてコンテキストが与えられてもその質問に答えることができません。ええと、ええと、この応答は実際にはかなり良いです。なぜなら、それは、それがわからないと伝えているからです。ええと、しかし私たちはそれでも、何がその根本原因なのか、ええと、答えられない、その不能さの根本原因を知りたいのです。
ええと、それは単に、私たちが、えー、正しい情報を取得しなかったからです。なのでここでは下部に true lens のスクリーンショットが見えます。えー、そこでは取得した3つのチャンクそれぞれについて、ええと、これらのチャンクがどれだけ関連しているかを0から1で評価したスコアがあります。そして、それが低いスコアまたは高いスコアになった理由についての推論もあります。ええと、なのでその3つ目を見ると、ええと、これは10点中2点のスコアになっています。ええと、なぜなら、えー、その文は Honolulu の人口についての情報を提供していたのですが、ええと、国立公園については何も言及していなかったからです。えー、なので2つ目の、ええと、えー、失敗モードとして、えー、私たちがよく見るのは groundedness の欠如です。
えー、これは、えー、LM が私たちの取得した証拠の上にしばしば幻覚を起こすときに発生します。ええと、ここで例を見ることができます。えー、これは要約アプリケーションで、えー、そこに入力しているのは、えー、ホテルのヘルプデスクとの会話からのこの入力です。そして、えー、要約の中で、えー、ある種3つの主張が行われているのが見えます。ええと、1つ目は、彼らが1時間前にルームサービスに電話したということです。
2つ目は、彼らが待ち時間について不満を持っているということです。そして3つ目は、ええと、彼らには他に選択肢がないということです。ええと、なので私たちは、えー、取得されたコンテキストからの証拠によって、えー、最初の2つがサポートされていることを検証できます。えー、しかし2つ目については、彼らが待ち時間に不満を持っていると言っているような明確で直接的な、えー、文がコンテキストにはありません。ええと、なので私たちはそれがサポートされていない文であることをある程度検証して、そして、そして、groundedness スコアを少し下げることができます。
ええと、これについて私も質問があります。はい。それが明示的に書かれていない一方で、えー、彼らが待ち時間に不満を持っていない、いや不満を持っているということですが、ええと、これは、あなたなら、つまり人間としてその仮定をするようなものではないですか？はい、私はそれは、たぶん本当だと思います。これは少し議論の余地があるかもしれません。うん。
ええと、ありますか、たとえば、ええと、ああ、ここで私が本当に聞きたいのは groundedness の尺度です。それは提供された実際のテキスト、つまり明示的に提供されたテキストだけに完全に基づいているのでしょうか？えー、それとも、何か、ええと、何か、えー、えー、えー、なんというか、どう表現すればいいのか分からないのですが、えー、ああ、コンテキストからの外挿のようなもの、つまり人が行うようなものを考慮に入れるのでしょうかY はい。なのでそれは両方の混合のようなものです。ええと、なので、えー、このような評価は、えー、ある種2つのクラスのモデルで行うことができます。ええと、つまり、大きな suggish モデルで行うこともでき、その場合、えー、私たちは慎重なプロンプティングのようなことを行って、えー、私たちの文のようなものを異なる主張に分割し、それぞれについて証拠を探します。
ええと、そしてそれは ALLM なので、たとえば、えー、待ち時間について不満を持っていない、いや不満を持っていることが含意されているようなことを理解する自由度があるかもしれません。はい。そしてそれは少し見えますが、3つ目ですよね？それは、彼らには別の選択肢があると言っていて、そこには、まあ、私たちには選択肢がない、というような感じがあります。なので、ええと、そしてこのような評価のもう一つの選択肢は、えー、自然言語推論モデルのようなものです。ええと、えー、なのでこれは、えー、ある種中規模言語モデルの、えー、評価スタイルのようなものです。
ええと、そしてここでも同様の戦略に従い、主張に分解します。ええと、そしてそのモデルはおそらく、えー、外挿のようなものに関して、ええと、ある種の融通の余地は少し少ないでしょう。いいですね。すばらしい。えー、では3つ目、ここで指摘したい3つ目の失敗モードは、えー、間違った質問に答えることです、そうですよね？えー、ここで私は、えー、Hawaii 州歌は何年に書かれましたか？と尋ねています。ええと、取得はうまくいっています。
なので、えー、見ての通り、えー、正解は、ええと、取得結果の中にあります。曲名があり、年もあります。ええと、しかしその後、えー、私たちの応答は年ではありません。それは単に Hawaiian 州歌の名前のようなものです。なので、この周辺でのコンテキスト関連性は良好でした、えー、良好でした。ええと、しかし回答関連性は十分ではありませんでした。
ええと、では、私たちのアプリケーションに適した評価を選ぶことについて、ええと、どのように考えればよいのでしょうか？ ええと、私がこれを考えるときは、だいたい2つの軸で考えるのが好きです。つまり、まず1つ目は、ええと、その評価がどれほど意味のあるものか、ということです。アプリケーションの性能について、どれだけ良い見通しを得られるか、ということです。ええと、おそらく、私たちが考えられる最も意味のある、ええと、評価は、グラウンドトゥルース評価です。これは、ええと、人間による評価を行っていて、ええと、ある回答をどのように採点するかを正確に理解している場合です。ええと、ただ問題は、これらは、これらはスケールしないということです。
なので、ええと、こうした人間による評価を用意するのは、本当に費用がかかり、非常に時間もかかります。さらに、これらは動的ではありません。ええと、つまり、あなたの、ええと、アプリケーションへのクエリが変化しても、ええと、それを反映しません。ただ、このような静的なグラウンドトゥルース評価になるだけです。そしてこれは、モデルの採点で見られる多くの問題と同じです。ええと、たとえば hugging face のリーダーボード上で、ですよね？ つまり、ええと、このような静的データセットを使っていて、あなたのドメインを反映していないのです。
ええと、なので、ええと、ある意味で反対側には、従来型のNLP評価があります。これは BLEU や ROUGE のようなものです。ええと、これらの問題は、非常にスケーラブルで、実行コストが低い一方で、ええと、多くが構文的な類似性、ええと、に依存していて、実際には、ええと、意味的な、ええと、比較を理解していないことです。つまり、異なる単語を使っている場合に、ええと、2つの文が似ていることを認識できないことがよくあります。
ええと、そしてそれが、ええと、中規模言語モデルおよび大規模言語モデルによる評価につながります。ええと、たとえば単純でより定義された、ええと、一般的によく使われるタスクでは、ええと、中規模言語モデルは非常に役立ちます。ええと、以前に ground disk について話しました。ええと、テキストの言語を特定する、ええと、そしてそれを使ってプロンプトとレスポンスの間で一致させる、といったこともできます。ええと、感情をチェックするようなこともできます。
ええと、これらはすべて中規模言語モデルで行うのに非常に有用なことです。そして、ええと、UCI では、それらをLLMよりも少しスケーラブルなものとして示しています。単に実行コストが安いからです。ええと、そして最後に、LM評価ですが、これは最も柔軟なものになります。ええと、ええと、非常に意味があります。なぜなら、私たちのアプリケーションをどのように評価したいかに合わせて、正確に調整できるからです。ええと、なので多くの場合、アプリケーションをセットアップするときには、ええと、これらの評価をたくさん組み合わせることが有用です。ええと、初期のプロトタイピング段階では、いくつかのグラウンドトゥルース評価から始めたいかもしれません。ええと、しかしその後、ええと、最初のバージョンを超えていくにつれて、これら他の評価をいくつか追加したくなるでしょう。
ああ、なるほど。ええと、ここで少し止まりたいです。聴衆から質問があります。ええと、聴衆からは、関連性スコアはどのように計算されるのか、という質問がありました。はい。つまり、ええと、関連性スコアは、ええと、LMへのいくつかの慎重なプロンプトによって算出されます。
ええと、基本的には、ええと、プロンプトとレスポンスを、たとえば e文字列のようなものに挿入して、それから、ええと、この、ええと、質問に対してレスポンスはどれくらい関連しているか、と尋ねます。そして、いくつかの few shot 例を行って、たとえば、ええと、まったく関連していない、ええと、レスポンスには0から3のような低いスコアを与えるべきだ、といったことを示せます。ええと、4から6くらいは、質問の一部に関連している場合です。そして、完全なスコアのようなものは、質問に対して完全かつ包括的に、ええと、答えていて関連している回答のために取っておくべきです。つまり、必要に応じて関連性を調整できます。はい、はい、もちろんです。
はい。なので、もし、ええと、あなたの、もしアプリケーションで得られる回答のようなスタイルが、単純なプロンプトで、ええと、採点するのが難しい場合には、ええと、アプリ向けに採点したい回答のスタイルに合わせて、ええと、より few shot プロンプト形式のようなものにするのが有用な場合があります。いいですね。わあ。素晴らしい。
うんうん。素晴らしい。はい、良い質問でした。ああ、ええと、では、他に、はい。
それで、ええと、Revant がこれに対するフォローアップの質問をしています。それは、実際の関連性スコアは何によって決まり、どのメトリクスがテキスト A はテキスト B よりも関連性が高いと言うのか、というものです。事前のデータセットは必要ですか？これについては、あなたが、ある程度チューニングして、いくつか例を与えられる、と言っていたときに部分的に答えていたと思いますよね？何か、ええと、別の、メトリクスと呼べるようなものはありますか？ええと、その、測定という観点で。ええ、そうですね、そのメトリクスは単に、つまり、最終的には、LLM が次に最もありそうなトークンを埋めるようなもので、ええと、それが 0 から 10 までの何らかのスコアになる、ということです。ええと、それから、ええと、少数例プロンプティングのようなものを通じて、LM をある程度押し進めたり、lmm に影響を与えたりして、ええと、スコアとは何か、関連性とは何かを理解させることができます。ええと、でも、事前のデータセットのようなものは必要ありません。なのでこれは、ええと、その実行に対してある意味動的なものです。とてもいいですね。
いいですね。ええと、ここまで、実行したいさまざまな評価について、ええと、そして rag のセットアップがどのようなものかについて少し話してきました。ええと、rags をセットアップするときには巨大な設定空間があります。ええと、なのでベクトルデータベースを作成する際には、ええと、決める必要のあることがたくさんあります。たとえば、ええと、どの embedding モデルを使いたいのか？ええと、データをどう選ぶのか？ええと、私たちは大量の研究を見てきましたが、ええと、データの品質と多様性の両方が、モデルサイズなど、もっと頻繁に話題にされるものよりも、ええと、あなたのアプリケーションにさらに大きな影響を与えることが示されています。ああ、そうですね。
ええと、それから、distance metric index type のようなもの、ええと、これらは選ぶ必要のある追加的なもののようなもので、下流でかなり影響が大きくなり得ます。そして retrieval のステップに進むと、ええと、そこでもまた、ええと、非常に影響の大きい決定がたくさんあります。ええと、最初のものは、ええと、retrieval でいくつの chunks を取得したいか、です。ええと、どの retrieval method を使いたいのか？つまり、naive rag のようなものを使いたいのか、ええと、単に、上位 3 つ、あるいは top K の最も、ええと、関連性の高い chunks を取得するだけのものですね。それとも sentence renewing や auto merging のようなものをやりたいのか？ええと、あちらの law index の人たちは、毎日のように新しい、より凝った retrieval methods を考え出しているように見えます。ええと、そうした選択肢のいくつかを取り入れることについて、どのように考えたいのでしょうか？そうですね。ええと、それから、より dynamic retrieval のようなこともできます。
つまり、ええと、re rankers のようなものを使います。最初の retrieval を行い、それから、いったん、彼らが AK number of chunks を設定したら、ええと、どれが最も関連性が高いかを決めるために re-ranking を行うことができ、そのうえで最も関連性の低い、ええと、chunks をフィルタリングして除外することさえできます。ああ、ここで私も、ええと、もう一つコメントしたいことがあります。この、how many chunks top K というものは、実は私たちがちょうど追加したものです、ええと、これの別バージョンで、ええと、私たちは range search と呼んでいます。なるほど。
そしてそれが本質的に行うことは、あなたが欲しい top K の数を伝える代わりに、距離が何であるか、そしてあなたが、あなたが、あなたが、まあ、許容できる距離として受け入れたいと思うような距離を伝えると、その距離内にあるものをすべて取得する、ということです。ああ、それは非常に便利ですね。ええ、それは本当に本当に素晴らしいでしょうね、特に先ほど見たような種類の問題のいくつかでは、そうですよね？つまり、ええと、良い chunks がいくつか見つかる一方で、top K が高すぎるために、無関係な chunks のようなものも取得してしまうことがある、というところです。なので、ええ。素晴らしいです。
いいですね。とてもクールです。ええと、それから最後に、completion のステップに到達したとき、決めなければならないことがまた非常にたくさんあります。では、どのモデルを使うのか？ええと、モデルの大きさはどれくらいか？ええと、何らかの API を使うのか、それともローカルモデルのようなものを使うのか、ええと、ああ、それからモデルパラメータですね、つまり、温度はどうするのか？頻度ペナルティはどうするのか？ロジットバイアスはどうするのか？ええと、ああ、OpenAI でできるような function calling のようなものを使うように、問題をある程度きっちり絞り込めるのか？ええと、ここで決めるべきことはたくさんあります。ええと、では、これらすべての意思決定について、アプリケーションに使いたい構成をどう決めるべきだと考えますか？どれが最も高性能なのか、ええと、どれがユーザーに最も高品質な回答を提供するのか？ああ、そこで評価が出てきます。
それで、ええと、前に話したように、フィードバック関数は、ええと、TruLens で LLM を評価するために使う抽象化です。ええと、これには、ええと、前に話したような RAG triad のようなものが含まれます。つまり、回答の関連性、コンテキストの関連性、根拠性、ええと、しかしそれ以外にも、ええと、アプリの評価に役立つ可能性のあるものがたくさんあります。ええと、これは要約品質、プロンプトのセンチメントのようなものかもしれませんし、ええと、フィードバック関数として埋め込み距離を見ることはしばしばかなり有用ですし、ええと、PII の検出などもあります。ええと、そしてこれらのフィードバック関数は、ええと、どんなモデルでも実行できます。
つまり、ええと、左側のように、オープンソースモデルを使うことができます。ええと、たとえば Mistral や Meta の Llama のようなものかもしれません。ああ、Hugging Face の任意のモデルを使うこともできます。ええと、LiteLLM とのかなり良い、ええと、かなりクールな統合があります。ええと、これはたぶんあまり馴染みのない列車の絵文字のようなものです。ええと、彼らがやったことは、ええと、100 以上の LLM のための共通の、ああ、標準的なコネクタのようなものを構築したということで、常にレスポンスを OpenAI 形式のような形で返します。つまり毎回必ず同じ場所にあることになり、多数の LLM に接続するための、ええと、なかなか良い方法です。
ええと、それから、はい。ああ、このスライドから移る前に簡単な質問です。ああ、まずこのスライドを終えていただいてもいいのですが、実はこれらのモデルについて、どれが、どのオープンソースのものが好きで、どのプロプライエタリなものが好きか、あなたの意見を聞きたかったんです。ええ、そうですね、ええと、私は Azure Bedrock OpenAI のようなものは、ええと、エンタープライズ寄りでは、ええと、非常に一貫しているように感じましたし、OpenAI についても同じような感じです。一般的には、ええと、GPD 3.5 や GPD 4 のほうが、ええと、他のモデルよりも eval を提供するのに優れていると感じています。興味深いですね。わかりました。
ええと、それから、少しだけ、ええと、ベンチマーキングもしたことがあって、それは後でドキュメントでお見せできるかもしれません。ええと、後でリンクを送ることもできます。ええ、それは素晴らしいですね。うん。ええと、はい、それで、今少し触れたように、よりエンタープライズ寄りの側では、ええと、Bedrock、Azure OpenAI、ええと、Cohere などのモデルでフィードバック関数を実行できます。
そしてこれらは、ええと、かなり LM アプリのスタックに依存しない形で実行できます。つまり、私たちは L Chain と lax とかなり密接な統合を持っています。そしてそれらを通じて、ええと、評価のためにほぼ任意の LM アプリを簡単にラップできます。ええと、ではここから、ええと、少ししたらノートブックに移ります。少し行き過ぎたようです。
ああ、こちらがここからお見せするノートブックへの QR コードです。ええと、自由に開いて、ええと、表示してみてください。この、ええと、ノートブックを開くためにたぶん 1 分ほどお時間を取ります。それからデモに入り、順に見ていけます。ええと、そしてこの時点で質問を受けるのにもおそらく良い機会だと思います。わかりました。
それでは、私宛てのものと思われる質問をいくつか取り上げます。ええと、見てみましょう。Frankが、ええと、ライブで回答します。Frankの質問は、top Kの議論に関連する距離は、embeddingアルゴリズムに依存するのではないですか？もしそうなら、それはLLMごとにパラメータ化する必要があるのでは。そうですよね。
わかりました。ええと、ここには unpack すべきことがたくさんあります。まず第一に、embeddingsはアルゴリズムから生成されるものではありません。Embeddingsはニューラルネットワークから生成されるものであり、その距離は間違いなく、それを生成するネットワークに関連しています。そして実際には、Joshが先ほど触れたように、最も関連しているのは、そのニューラルネットワークが学習したデータの品質とデータの内容です。
それで、ええと、つまり答えは yes で、embeddingに依存します。ええと、それをLLMごとにパラメータ化する必要があるのか？それは必要ありません。というのも、ええと、ほとんどの場合、つまり、あなたがparameterizeで何を意味しているのか完全には分かりませんが、そうする必要はなく、embeddingが、ええと、だからといって別のLLMを使う必要はありません。同じembeddingモデルを使ってembeddingsを生成している限り、同じembeddingsで異なるLLMを使うことができますし、embeddingsモデルとlmmは必ずしも同じではありません。同じであることもありますが、そうである必要はありません。ええと、明確だったことを願います。ええと、この、この質問には unpack すべきことがたくさんあるので、追加の質問があれば、遠慮なく送ってください。
いいですね。Vissについての別の質問が1つ見えます。built inの、ええと、re-rank機能があるかどうかという質問ですね。ああ、はい、これが見えます。ええと、それはありません。ええと、でも付け加えるなら、odxを使うことで、visとre-rankを簡単に使えます。つまり、mondexは便利な、ええと、フレームワークです。ええと、なので、アプリ内でre-rankingが行われる場所はそういうところになります。
はい、はい、はい、はい。ええと、Novusは、ええと、Vector database systemであることにかなり特化しています。私たちの創業者はdatabase systemのバックグラウンド出身で、非常に、非常に高性能なシステムを構築することに注力しています。ええと、なので私たちは、外側の部分にはあまり触れないようにしています。ええと、でもそうですね、slam Indexはそのための素晴らしい選択肢です。
ええと、Vector databasesは、ドキュメントembeddingのすべてのリアルタイム追加をインデックス化してtop kを計算するのでしょうか？クエリが、複数の類似度計算を行わなければならないのに、どのようにtop Kのリアルタイムリストを提供できるのか、少し混乱しています。これは、これも非常に深い質問で、Amil vs.みたいに、ええと、Amil vsの、図を開いた状態で説明できるようなものです。でも、ええと、これはもっと長い議論だと思います。そして、その、その、ここでの短い答えは基本的に、ええと、すべてのvector databasesがこれを行うわけではありませんが、Vissではこれを行えます。なぜならVissにはリアルタイムストリームがあり、ええと、そしてNovus ISSは分散システム、ええと、ええと、databaseだからです。
そのため、タイムスタンプを使ってそれを行います。つまり、データが入ってくるときにタイムスタンプを付け、それからconsistency levelを設定します。そしてconsistency levelが、ええと、基本的に、どの、ええと、timestampからデータを取得できるかを決定します。素晴らしいです。それから、ああ、Josh、あなた宛てのものがありますね。LLMを使ったRAGのためのツールや全体的なセットアップは、現時点でかなり堅牢に見えます。
True Eraや他の場所で、画像生成向けにこれに近いものは何かありますか？はい、実は先週これについていくつか、探索のようなことを始めました。multimodal models、ええと、lavaのようなものを使って評価を行うというものです。つまり基本的には、ええと、その画像を使ってpromptingしているような感じですが、評価基準もテキストです。ええと、それらの組み合わせを使うことで、ストレートなテキストで行ったのと同じようなscoringを行えます。ええと、なので、私は、日付を約束したくはありませんが、それは間違いなく私たちが考えていて取り組んでいることです。ちょっとしたプレビューを見せてもらっているわけですね。
素晴らしいです。はい。では、今のところ質問は以上だと思います。では、いいですね。
ノートブックに行きましょう。そうですね。あなたのIDEは何ですか？ええと、これはCursorです。つまり、vs codeの拡張機能のようなものです。ええと、いい感じのAIアシスタントのようなものがあって、コードベースとチャットして質問できるAIのようなものがあります。なるほど、いいですね。わかりました。
そうですね、vs codeのように見えますが、アイコンが違って見えたので、あれ、と思いました。そうですね。そうですね、私は気に入っています。今のところ気に入っています。たぶん1か月くらい使っています。
ええと、そうですね、おすすめです。Cursorへの私からの宣伝です。ああ。それからRockも同じ質問をしていますね。いいですね。
では、例に入っていきます。ええと、ここではすでにvisをインストールしてあるので、そのセクションは飛ばせます。ええと、この例で使うライブラリは、LAMA Indexです。ええと、link chain embeddingsからいくつか埋め込みを取得します。
ええと、open aiのレート制限のようなものに対応できるように、指数バックオフとリトライを行うためにtenacityを使います。それから、評価を行うためにtrulanceからいくつかのものを取り込みます。ああ。いいですね。わかりました。
ここで最初にやりたいことは、ドキュメントを読み込む必要があります。ええと、いくつかのC City Wikipediaページを取り込みます。ええと、La、Houston、Chicagoのような都市です。そして、それぞれをLA IndexのWikipedia readerを使って読み込みます。ええと、それから都市のことを念頭に置きながら、これらの都市に関するテストプロンプトのセットのようなものを設定しておきます。これらを使って、アプリケーションがどのように動作しているかを測定するのに役立てます。ええと、それからRagの最初のバージョンを構築できます。ここでは、まず最初にやる必要があるのは、Vector storeの中間部分を設定することです。
ええと、異なる種類のindex typesを設定します。ええと、使用するembedding modelの次元に一致するdimensionを選びたいです。ええと、search parameterを設定できます。ええと、このvector storeを使って、それをlong indexアプリのstorage contextに設定します。そしてその後にやる必要がある2つ目のことは、cervix contextを設定することです。これは使用したいmodelとembeddingsになります。
ええと、それからその2つのcontextsを使ってindexを作成できます。ええと、それからquery engineを作成し、top Kを設定します。ええと、それをTenacity Libraryのretryのようなタグに入れます。これは、もし失敗してopen AIのHDTPのようなものに引っかかった場合、X分待つようなことができて、進むにつれてそれを増やしていくことで、rate limit errorsを避けようとするものです。そしてそれを行ったら、前に設定した各test promptsを通して実行できます。ええと、しかし、このprototype ragは作成したものの、実際にどの程度うまくいっているのかはわかりません。
もちろん、各responseを見て手動で、これは正しい答えか、と判断することはできます。ええと、もしかするとWikipediaに行って、これは実際に正しいのか、それとも幻覚のようなものなのかを確認しなければならないかもしれません。ええと、でも、このapplicationのperformanceがどうなのかを最初から把握するのは本当に難しいです。ええと、ここからTrulanceでevaluationを設定したいと思います。ええと、Trulanceでは、OpenAI GBT three and a halfを使って、これらのevaluationsの多くを設定します。ええと、GPT three and a halfは十分に優れていると私は感じています。特に、先ほど話したような丁寧なpromptingを与える場合です。ええと、そのpromptingがあると、three and a halfとfourの間でevaluation qualityに本当に大きな差はありません。
興味深いですね。ええと、これは少しホットテイクだと思います。丁寧さの少ないpromptingでは、もっと大きな違いがあると思います。なので、他のところでは別の意見を見かけるかもしれません。ええと、それはホットテイクですね。
はい、はい。GPT fourのほうがずっと優れていると言っている人をたくさん見ます。なので、これは、私はGP 3. 5もよく使うので、これは、これはいいですね。これは興味深いです。
うん、安いし、速い。うん。ええと、そうですね、ここで最初に設定したいフィードバック関数は、えー、groundedness です。ええと、この全体を詳しく説明するつもりはありませんが、いくつかの点を取り上げます。ええと、grounded を provider として設定します。つまり、それが、私たちが使うモデルです。
ええと、それから、context を指していることも指摘しておく価値があります。ええと、アプリケーションが実行されるたびに、えー、record または、つまり JSON をシリアライズします。ええと、それが trulance の observability コンポーネントのようなものです。そしてここでは、その JSON のどこに context があるのかを指し示します。これにより、アプリのさまざまな部分を指すための非常に大きな柔軟性が得られます。たとえば agent app を作っているなら、tool decision を指したいかもしれませんし、tool input を指したいかもしれません。ええと、RAG の場合は、context に加えて、えー、summarization step や他の intermediate steps のようなものを指したいかもしれません。
ですので、ここで何を評価するかについては非常に多くの柔軟性があります。ええと、それから他の評価として、answer relevance、えー、context relevance を行います。ここでは同じ context を指しています。ええと、そして特に注目すべきなのは、これらすべての、えー、評価を chain of thought reasons で行っていることです。ええと、これを指摘しているのは、これら2つが私たちにとってかなり良い点だからです。
まず1つ目は、評価の品質を向上させることです。ええと、LLM は段階的に考えるように促されると推論がずっと得意になることを示す研究がたくさんあります。なので、それが1つの利点です。そして2つ目の利点は、ええと、私たち人間が、特定の、ええと、record がなぜ低いスコアになったのかについて理由を得られることです。これは、理解したり、デバッグしたり、何が間違ったのかを見つけたりするのに役立ちます。
ここで最後に見せたいフィードバック関数は、えー、embedding distance です。これは、えー、異なる embedding models を比較して、えー、どれを使いたいか、どれを使うかを判断しようとするときに、かなり役立つことがあります。ええと、downstream performance のようなものに加えて、各 record について、えー、ここにあるこうした distances だけを見ることもできます。ええと、いいですね。OK。
これで評価の設定ができました。えー、次にやりたいのは configuration space の設定です。実際にはそれらを取り除いたと思います。ええと、ここでは2つの異なる embedding models、えー、mini LLM と ada を評価します。えー、2つの top kss と2つの chunk sizes を設定し、それから、えー、それらすべてを順に試していきます。
ええと、各 application を試し、えー、各 app に 10 records を通し、それからどれが最も良い性能を示すかを見ます。ちょっと面白い実験です。そして、えー、最後にここで触れておきたいのは、えー、ここで Tru lens を設定するとき、query engine を Tru Lama というものを使ってラップするだけだということです。えー、これは LAMA index integration のようなもので、ええと、observability を行い、LAMA index application を instrument します。ええと、そして実行されるたびに評価したい feedback functions のリストを渡すだけです。
ええと、ご想像のとおり、これは、全体として少し時間がかかります。8つの異なる application versions のようなものを実行しているからです。なので、ここでは事前にこれを実行しておきました。えー、では切り替えて、trulance leaderboard でこれがどのように見えるかをお見せします。いいですね。OK。
ここでは、えー、すでに8つの異なる、ええと、application merchants のそれぞれに 10 records を通しました。そして、えー、latency、cost、えー、total tokens、それからそれぞれの異なる evaluation metrics があるのがわかります。ええと、この information button のようなものに hover over すると、えー、model parameters が何かを見ることができます。えー、設定しました。これは、ちょっとした、実験追跡の、えー、ビューを提供してくれます。そして最初の4つは、えー、mini lm を使っていて、下に行くにつれて top K と chunksize が増えていくようになっています。
ええと、なので、私たちがかなり低いパフォーマンスから始めているのが分かります。うーん、特にコンテキストの関連性とグラウンデッドネスにおいてです。うーん、それからLLMにより多くのコンテキストを与えていくにつれて、それがチャンクサイズを増やすことによるものでも、top Kを増やすことによるものでも、ええと、その両方の指標でスコアが良くなり始めます。なので少し下にスクロールします。すると、チャンクサイズを200から500に増やしているのが分かります。その後、200に戻してtop Kを増やし、それを試します。そしてapp fourでは、このスコアにおけるグラウンデッドネスがより良くなります。
うーん。ThisOneはこのスコアにおけるグラウンデッドネスがずっと良いですね。そうですね、そうですね。大きな改善です。そうですね。
十分なデータを与えると、実際にはかなりうまくいくんですね。すごい。うーん、ええと、でも、これは、つまり明らかにかなり高価になりますね。なぜなら、かなり多くのトークンを与えているからです。まあ、たった2セントですけど、でも倍ですね。倍です、倍です。
それは本当です。それは、はい。コストを倍にしてもグラウンデッドネスが倍になるわけではありません。なので、それは覚えておくと興味深い点ですね、分かりますか？そうですね、そうですね。なので、私たちがapps fiveからeightのあたりに入っていくと、埋め込みモデルを切り替えます。
うーん、ここではadaを使い始めます。うーん、するとすぐに、top pay equals oneでチャンクサイズが200でも、ええと、この点でさらに良いグラウンデッドネスと、ずっと良いコンテキスト関連性が得られます。すごい。うーん、それに、これを指摘するのもかなり興味深いと思いますし、これはある意味明らかなことでもあるのですが、ええと、ADAのベクトル空間について考えると、うーん、その指標を検索に使っているときに取得するコンテキストチャンクは、ええと、平均的にはずっと低くなります。ええと、他のモデルを使っているときよりもです。これは明らかですが、指摘する価値もあります。うーん、なので、はい、adaを使うことで、そして特に、ええと、コンテキスト関連性を高めることで、これらの指標の多くが本当に改善されます。ただし、app sevenとapp eightでは、実際にはコンテキストが多すぎます。
なのでここでは、ええと、ある意味、無関係なチャンクを与え始めています。うーん、ああ、とてもいいですね。なので私たちのいわゆるスイートスポットは、このapp fiveとsix、ええと、おそらくapp sixあたりになります。そこでは適切なチャンクを取得しています。ええと、それらはかなり正確です。うーん、では、ええと、掘り下げて、これらのレコードのいくつかを見てみましょう。
うーん、ここでは、私たちがアプリケーションに尋ねた10個の質問それぞれを見ることができます。うーん、そして得られたさまざまなスコアも見ることができます。では、失敗モードを見て、それから成功例を見てみましょう。うーん、ここでは、ええと、laの有名なフェスティバルにはどんなものがあるか、と尋ねました。ええと、laのいくつかのフェスティバルを含む回答が得られましたが、ええと、取得しているコンテキストを見ると、そこには、これらのフェスティバルは入っていません。なのでこれはかなり典型的なハルシネーションで、答え自体はたぶん正しいとしても、それは事前学習から来たものであって、R ragからではありません。
うーん、なのでそれは、つまり、それは私たちが求めているものではありません。そして、ええと、コンテキストやchain of thought reasoningにも示されているように、RLMは、うーん、コンテキストに正しい情報がなかったことを私たちに伝えることができます。ええと、では、ええと、別の、うまくいった例を見てみると、ええと、ここでは、ええと、laにはどんなプロスポーツチームがあるか、と尋ねています。うーん、良い回答が得られています。そしてコンテキスト関連性を見ると、これらすべてのチームがコンテキストに列挙されているのが分かります。うーん、そしてまた、このような良いグラウンデッドな回答もあり、文としてのステートメントがあり、その後にコンテキストからの裏付け証拠があります。
ええと、まあ、ほとんどの部分では、この、ええと、app six バージョンにはかなり満足しています。おそらく、ええと、最後の数件のレコードを改善するために、さらにできるチューニングがいくつかあると思います。ええと、でも全般的には、ええと、いくつか違うことを試してみるだけで、かなり前進できました。ええと、このページで最後に触れておきたいことは、そのあとで、もっと q and a に入りますが、ええと、あなたのアプリケーション内で起こるさまざまなコンポーネントすべてが何かについての、ええと、こうした、ええと、インストルメンテーションビューがあります。ここでは、ええと、retrieval をどこで行っているかが見えます。
そして、ええと、そこから、その、ええと、retrieve context が LLM に渡される場所を見ることができます。ええと、なので、これはデバッグの仕方にも役立ち、あなたのアプリケーションのさまざまなコンポーネントが何で、なぜ、どこで何かがうまくいっていない可能性があるのかを理解するのに役立ちます。いいですね。よし。ええと、それでは q and a に行けると思います。
true lens の QR コードをちょっと表示します。ええと、私たちは完全にオープンソースです。ええと、GitHub で見つけられます、ええと、そこにある QR から。ええと、スターをいただけると嬉しいです。本当に人々を盛り上げます。
ええと、では、q and a に入りましょう。はい、私たちも viss のスターが大好きです。なので、ええと、Star on boat。はい、スターボタンです。ええと、メタデータに複雑なスキーマを持つユースケースについて。
ベクトル検索だけに viss を使い、それと併せて従来のデータベースを使用することを推奨しますか？もしそうなら、それはどのように機能しますか？ええと、本当に複雑なものがある場合だけだと思います。複数の、例えば通常複数の join を行う原因になるようなものがある場合は、おそらくそうしたほうがよいでしょう。それ以外なら、vis はメタデータを保存するので、公開日、著者、タイトル、Texas のどこから来たか、といったものをすべて Vis に保存でき、そのうえで filter を使うだけで済みます。ええと、そして BU の filter は非常によく設計されています。これは bitmask なので、線形に追加されるだけです、つまり、これは、これは、検索に対して、ええと、定数時間を追加しているのだと思います。
なので、ええと、はい、かなり複雑なメタデータでない限り、私はそうしません。Euclidean distance、co-sign similarity、dot product similarity のようなベクトル類似度距離について何か考えはありますか？ええと、Euclidean distance は、ええと、x squared plus y squared です。なので、だいたい、ええと、5つの計算がそこで行われています。ええと、Euclidean distance は、ええと、ああ5つ、実際には3つですね。何を言ってるんだろう、とにかく。ええと、occluding distance は、ええと、正規化されていないベクトルにとても適しています。
Cosign similarity は、ええと、では、まあ dot product から先にいきます。Dot product は A times B、行列またはベクトル A times vector B ですよね？ええと、そこでの inner product です。なので、ええと、基本的には、まあ、ええと、ええと、何らかの n 個の、ええと、計算がそこで行われています。ええと、これは magnitude と orientation が欲しいときに非常に適しています。そして co-sign similarity は、ええと、つまり、本質的には正規化された dot product です。
なので、これは、すでに正規化されたベクトルがあり、orientation だけを見ている場合には非常に適しています。Josh、この点についてコメントしたいですか？ええと、はい、なので私は、特にここで示した、Vector database に数ページの Wikipedia、Wikipedia、ええと、ページがあるような非常に単純な例では、どの distance metric を使っても、まあ違いはない、違いはありませんが、スケールが大きくなるにつれて、ええと、そのあたりは確実に念頭に置きたいですね。はい。ええと、他に language API はありますか？これは Josh への質問だと思います。はい、なので、私は、この質問にはおそらくいくつか答えがあると思います。
ええと、つまり、先ほどJimが言ったように、任意の埋め込みモデルに使われているもの、そのモデルとは別の言語モデルを使うことができます。つまり、同じでもいいし、違っていてもいいです。ええと、Trulinは、任意のモデルを使うどんなアプリケーションでもラップできます。ええと、なので私たちにとって非常に人気のあるユースケースとしては、ええと、この新しいモデルが出てきたので、それが今使っているモデルと比べてどうなのか、どのように性能を発揮するのかを見たい、というものがあります。あるいはプロトタイピング中に、g PT four、gbd、three and a halfのどれを選ぶべきか、ええと、オープンソースの何かを使うべきか、というようなことです。ええと、それから、ええと、先ほど話したように、評価には言語、ええと、APIを使います。ええと、なのでこれは、私たちが組み込んだ、ええと、非常に多様な言語モデルであり得ます。
なので、画面に表示しているこれらのプロバイダーのいずれかの任意のモデルで、ええと、フィードバック関数をほぼそのまま実行できます。それから、ええと、私たちは常にこれらをさらに追加しています。なので、replicateが、次に私が取り組んでいるものだと思います。いいですね。ええと、GPT 3.
5は、True Lensを使って関数呼び出しを評価する場合、どの程度うまく機能しますか？ええ、そうですね、ええと、評価という点では、ええと、かなりうまく機能すると思います。なので、たぶん私たちのドキュメントをさっと開けると思います。ええと、私たちにはこうした、ええと、スモークテストのようなものがあって、ええと、私が実行したもので、ええと、考えてみることができます。なので、実はこれらを実行するのにTrue Lensを使っています。おお、いいですね。ええ、これらが見えます、はい。
はい。おお、つまりGPT 3. 5は、これらの一部でGPT fourより良いスコアを出しているんですか？うん。ええ。信じられないですね。
うん。わあ。わかりました。非常に興味深いです。ええ。
ええと、これらは関連性に関するもので、それから、ええと、私たちはこうしたスモークテストを、他のすべてのフィードバック関数全体に広げるように取り組んでいるところです。ええと、でもGBD three and a halfは評価に関して私としてはオーケーです。ええと、それから次の質問だと思いますが、理解としては、viss内の埋め込みモデルとしてmini l, mとADAを使っているということですね。ええと、少し、少し訂正します。ええと、実際には、いえ、それでいいです。
ええと、それから、根拠性、距離、関連性スコアを出すためにGPT three and a halfを使う、ということですね。ええ、その通りです。それから補完エンジンのようなものにもG PT three and a halfを使っています。わかりました。ここで少しコメントしたいです。
ええと、埋め込みモデルはMilsの中にあるわけではなく、埋め込みがMilsの中にあります。それを明確にしておきたかっただけです。ええ。いいですね、いいですね。ええと、答えやソースドキュメントがない質問がいくつかある場合、それはtrue lymphのメトリクスではネガティブとしてカウントされるのでしょうか。
それを考慮する方法はありますか？ええ、そうですね、ええと、それは、良いことだと思いますよね？つまり、true lensのメトリクスでそれを捉えられるということですからね？自分のVector databaseのどこにギャップがあり、どこでデータが不足しているのかを知りたいですよね。ええと、できることの一つとしては、ええと、追加のフィードバック関数のようなものを設定して、たとえば、ええと、アプリケーションが知らないときに回答を出してしまったか、あるいはコンテキストがないときに、知らないと正しく言っているか、というようなものです。ええと、なのでそれも評価するのに有用なことです。ええと、Truには価格設定が関連していますか？なので、この分野の多くの企業と同じように、ええと、ええと、スケールする段階になると、ええと、私たちのマネージドプラットフォームに接続したくなるでしょうし、その点についてはもちろんお手伝いできます。もしよければ、その後で私に連絡していただければ喜んで話します。ええと、でも今日お見せしたものはすべて完全にオープンソースです。ええと、なのでそれを使うことができます。High piからダウンロードして、GitHubで確認して、ええと、貢献したりスターを付けたり、などできます。
最後に、Groundness eval set のサイズについて何か推奨はありますか？ええと、これはある意味、あー、あなたのドメイン次第という感じです。なので、たとえば、質問のソースに本当に大きな多様性があって、ユーザーがあなたのアプリケーションに対して尋ねると想定しているものが幅広く、また、あなたの、RAG を実行している対象のコンテキストの種類にも大きな多様性があるなら、おそらくより大きな eval set が必要になると思います。ええと、でも、より限定されたドメインなら、小さめのものでもたぶん問題ありません。クールです。あまり満足のいく答えではないかもしれませんが、多くの場合、多くの人が私に質問して、その答えはいつも結局、データ次第です、ということになります。
Okay。ええと、タイミングは良さそうですね。今、ええと、57分なので、私たちは、ええと、ほぼちょうど1時間の終わりに来ています。ええと、このプレゼンテーションをしてくれて本当にありがとう、Josh、これは本当に素晴らしかったです。ええと、私も、つまり GPT 3.
5 が g PT four i email より優れているというのは、かなり大胆な見解ですね。ええと、これは、ええと、私が見たことのないものなので、とてもクールです。ええと、本当にありがとうございます、Josh。皆さんも本当にありがとうございます。ええと、またお会いしましょう。
はい、呼んでくれてありがとう。はい、来てくれた皆さんありがとうございます。これは本当に楽しかったです、ええと、本当に素晴らしい質問でした。ええと、そうですね、また後でお話しできるのを楽しみにしています。では皆さん。