You’re in!
ウェビナー
RAG評価：検索戦略の統計分析
本日は、今日のセッション「RAG Evals、検索戦略の統計分析」と、ゲストスピーカーのJason Loをご紹介できることをうれしく思います。Jason Loki。JasonはRise aiの共同創業者兼CEOです。本日Jasonには、同僚のSally Ann Decia、AriseのML SolutionsEngineerも参加しています。ようこそ、Jason、Sally Ann。
ええと、あー、お招きいただき、本当に、本当に、本当にありがとうございます。ええと、簡単に自己紹介します。私はRiseの共同創業者で、あー、技術系の創業者です。で、ご存じのとおり、riseは、ある種のAI MLオブザーバビリティで、正直に言うと、あー、私たちはランキングと検索システムのパフォーマンスを、かなり何年にもわたって測定してきました。そして、この1年、LLMとRAGの成長に伴って、私たちにとって非常に多くの、ええと、あー、多くの取り組みがある領域になりました。多くのデプロイメントも行ってきました。そして今日皆さんに共有するのは、本当に、私は、ええと、現場からのメモと言えるものです。こうしたシステムを数多く構築する中でどのようなものなのか、私たちが使ってきたメトリクス、ええと、そして改めて、コミュニティに私たちが学んだいくつかのことを共有するものです。ここに来られて本当にうれしいです。
ええと、それではSally Annに自己紹介してもらいます。はい。素晴らしいです。ええと、私はSally Annで、AriseのMLソリューションエンジニアです。私のバックグラウンドはディープラーニングなので、この1年で、それがどのように応用され、私たちが今LLMとして知っている世界へと変化したのかを実際に見るのは、本当に刺激的でした。
なので、これに、ええと、入っていくのが本当に楽しみです。ええと、Jason、始めましょうか？始めましょう。飛び込みましょう。はい。素晴らしいです。
それでは皆さんに、検索のベンチマーキングと分析について、本当に有益で刺激的なセッションをお届けします。ええと、これは非常に重要です。なぜなら、コンテキストをどのように検索するか、異なるチャンキング戦略などについて、さまざまなアプローチが出てきているのを私たちは目にしているからです。しかし、実際には、何をすべきかを示したり、構築したこれらのシステムを評価するのに役立つ標準やガイドラインはあまり見当たりません。そしてそれは、ariseで私たちが多く考えてきたことですし、Jasonが言ったように、これは現場からのメモであり、私たちが見つけたいくつかの学びやまとめてきたことです。ええと、ですので、私たちのRAGシステム、あるいは皆さんのRAGシステムを評価するためのガイドラインをいくつか皆さんに共有していきます。ええと、まず皆さんにオブザーバビリティの5つの柱を紹介したいと思います。
そして、この5つの柱によって実際に可能になるのは、私たちのLLMアプリケーションがどのように動作しているかを可視化し、最終的にそれらをどのように改善するかを把握することです。結局のところ目標は、本番環境で非常に高性能で信頼性の高いモデルを持つことです。ええと、そのために、これらの柱は非常に重要になります。そして今日の会話では、あー、私たちは主に評価というこの部分に焦点を当てます。ここでの目標は、別の、ええと、評価用LLMを使用してLLMの出力を評価することです。それでは、ここでいくつかのビルディングブロックを確認するところから始めましょう。
では、evalとは何か、評価をどのように行うのかといった具体的な話に入る前に、成功する評価を構成するビルディングブロックを理解することが本当に重要だと思います。まず、evalとは何かから始めると、私たちはevalライブラリを構築しており、それによって、あー、チェーンまたは個々のスパンのいずれかに対してevalを生成できます。そして検索に関して私たちが話していることとして、評価したいものが2つあります。まず1つ目は、ええと、私たちのチェーン上で行うもので、それがQA evalになります。そしてこれは、私たちのRAGシステム全体のパフォーマンスを表すものです。
ここでの2つ目の要素は、ええと、私たちの検索です。では、私たちの検索は実際に正しいのでしょうか？これは非常に重要です。なぜなら、ご存じのように、RAGは類似度指標に基づいてコンテキストを検索することで機能するからです。私たちは間違いなく、検索しているものが正しいことを確認したいと考えています。ですので、mbusを使用している場合、ええと、これが検索を評価する方法です。そしてここでは、これらを評価するための構成要素について議論し、それらをどのように活用して、つまりシステム全体を評価できるかに焦点を当てていきます。
そして、そして私が言うなら、これらを構成要素と呼ぶ理由は、私たちは、私たちは、N D C G M R R のような従来の検索指標が検索システムの評価には本当に理想的だと深く信じているからです。しかしそれらを構築するには、ある程度のラベルや評価、あるいは何か、その土台となるものが必要です。ですので、構成要素について話すとき、これらは従来の検索および取得指標に向けた構成要素になります。私は、私は、こうしたポッドキャストをたくさん聞いていますが、人々がこれについて話しているのを聞きません。そして、そして、それは、まさにそうしたシステムを本当に見ていきたい方法なのですが、これらはその基盤で使う、いわば中核となる、ええと、レンガのようなものになります。はい、それは素晴らしい説明の仕方だと思います。
ええと、ですので改めて、ここではこの検索セクションに焦点を当てます。ええと、そして本番環境であなたのLLMを評価するために、私たちがArizeでまとめた基本事項がいくつかあります。ええと、そして、ご存じのように、私たちはそれをオープンソースライブラリやevalsに適用してきました。ええと、ですのでevalsについて考えるとき、私たちはゴールデンデータセットを使用することを提案しています。ええと、私たちのフレームワークではいくつかのゴールデンセットを提供していますが、多くのお客様が独自のデータセットを構築しているのも数多く見てきました。
ええと、なぜなら、最終的にはそれらを信頼できることが本当に重要だからです。使用しているevalsを信頼できるようにしたいのです。ですので、ゴールデンデータセットを構築することは、実際には、ええと、あなたのデータの非常に良い例、良いクエリ、良い検索結果、良い回答を集めたものです。ええと、そして利点は、繰り返しになりますが、Jasonがちょうど測定、ええと、言及していたように、このゴールデンデータセットを使って、精度、再現率、F1のような、私たちになじみのある指標を適用できることです。ええと、そしてこれにより、単に、たとえばスコアの平均のようなものを使う場合と比べて、私たちのモデルがどれほど良く機能しているかをより具体的に理解できるようになります。2つ目は、ああ、そうですね、そうですね、私なら、これについて少し補足すると、ええと、左側にあるのは、多くの人が、もし、もし今evalsのエコシステムを聞いているなら、多くの人が、正しさのような数値の平均に飛びついているということです。
そして、そして、現場の苦労を経験してきた私たちには、数値を平均しても実際にはあまり多くのことは分からないと分かっています。データが非常に偏っていて、その数値を歪めることがありますし、そして、そして、そして、自分が測定しているのが、つまり、結果なのか、それとも偏り、つまりデータ内の、その、その、奇妙な偏りなのか分からなくなります。ですので、従来の、私たちが行き着いたのは、タスクベースのevalsでは、精度、再現率、F1をよく使うということです。ええと、この構成要素のセクションから1つだけ持ち帰るとしたら、ここでは何かが関連しているかどうかを判断するために二値判定を使い、単一の数値は使わない、ということだと思います。ええと、そしてまた、evalsが正しいことを確認できるように、あるいはそれらを使用する前に数値に納得できるように、データセットや信頼できるデータセットをしっかり構築してください。
はい、その通りです。そして、あなたはちょうど、実はここで2つ目の点にも触れました。それはタスクベースということです。そしてそれも重要だと思います。つまり、二値という立場を取ることだけでなく、それらがタスクベースであるべきだという事実も重要です。ええと、世の中にはモデルベースのevalsがたくさんあります。ええと、そしてこれは、ええと、私たちのアプローチでは、パフォーマンスを定義するためにテンプレートとタスクを使用することを強く提案しています。
そしてこれは本当に、ええと、重要です。というのも結局のところ、私たちはこれらの基盤モデルを特定のタスク向けに適応させていて、それを本番環境に投入しているだけだからです。だから私たちはそれらを評価しています。本当にタスク固有であるべきです。ええと、だからこそ、あの、私たちはタスクベースのアプローチが最善のアプローチだと考えています。私は、私は思うんですが、あの、あなたが open AI eval について少し、記事を書いていたのを見ました。
うんうん。つまり、evals というのはかなり広い言葉ですよね。少し説明してもらえますか、混乱している点や、エコシステム、つまり open AI evals、モデルベースの evals、そしてそれらが hugging face のリーダーボードなどでどう使われているのかについて。ええ、もちろんです。ぜひその記事をチェックしてみてください。さまざまな evals について、もっと幅広く概説していますが、基本的に open AI で見られる evals は、あの、特定のタスクベースのデータセットに対してモデルがどれだけうまく対応できるかを判断するものです。
つまり、もっと一般的な考えとして、たとえば、この l l m がどれだけうまく、ええと、汎化できるのか、この eval がどれだけうまく、ええと、質問に答えられるのか、といったことを示してくれます。それは、あなたが行っている特定のタスクを見ているというよりは、ええと、モデルの一般的な能力を見ているものです。そしてそれは、開発の出発点のようなものを意図していますよね？例えば、世の中には無数のモデルがあります。誰かが新しいモデルを発表して、「やあ、私たちはこの最先端モデルを持っています」と言うたびに追跡するのは不可能です。ですからそれらの evals は、モデル同士を比較できるようにしてくれますが、これを特定のタスクに適用したとき、本番環境でどのように機能するのかについて、本当の洞察を与えてくれるわけではありません。そしてそれが、ええと、ここで私たちが提案していることです。
いいですね。素晴らしい。はい。そしてここで最後のことですが、ええと、evals は異なる環境で、できるだけ高速に実行できる必要があります。これはここではある意味当然のことだと思います。
あの、多くの場合、私たちは異なるフレームワークを試しています。あの、ここでは lane chain と LAMA Index と書いていますが、どのフレームワークや環境で作業しているかに関係なく、これらの指標を比較しやすく、有用にしたいのです。ですので、基礎がわかった今、皆さんはおそらく、実際に何かを本番環境で実行するときに、これがどう全部つながるのか、と疑問に思っているでしょう。では、皆さんに例をお見せします。ここに l m spanner chain があり、ええと、何らかの eval ライブラリがあります。あの、Phoenix があります。これは括弧内にあるように私たちのものです。
ええと、私たちが実際にやっているのは、あなたの l m を流れるデータが、ええと、eval ライブラリにも流れて eval を作成するようにすることです。そして、あの、ここでは使用しているテンプレートを切り替えたり、評価に使用している eval や lmm を切り替えたりしているかもしれません。でも、ええと、これは一般的なセットアップにすぎず、最終結果はそのライブラリによって生成された eval になります。ええと、次にこれらのライブラリのさまざまなコンポーネントと、それらの結果が実際にどのようなものかについても見ていきます。それから付け加えると、あの、Phoenix はオープンソースです。
ええと、私たちは特定の考えを押し付けるわけではありません。自分の evals を使いたい場合や、自分たちの evals が良いと思うものを持っている場合は、それを使ってください。私たちがやろうとしているのは、現場での経験から、これらを使ってシステムから、あの、N D C G M R R タイプの検索指標を得る方法を少しお伝えすることだけだと思います。まったくその通りです。私は私たちの evals を、ある意味で土台を築くものとして見ています。
私たちが経験してきたことすべての要約のようなものです。経験してきたことを、このパッケージにまとめました。そしておっしゃったように、私たちは人々にそれらを試してみることを勧めていますが、自分たちで作って、何がわかったか教えてほしいとも思っています。いいですね。オーケー。いいですね。
では、evals はどのように機能するのでしょうか？この例では、retrieval span に対して retrieval eval を実行しようとしています。数枚前のスライドを覚えていれば、全体の chain があり、その中に qa があり、さらに retrieval に特化した retrieval chain がありました。そして、これがそのために使う eval です。つまり、入力であるユーザーの query と document を取り、eval library を実行しています。ええと、このケースでは、今回も Phoenix を使って evals を取得しています。
この template は、ここで特に注目することが非常に重要だと思います。なぜなら、これは私たちの system を評価するために使う l l m に対して、実際に何をどう評価すべきかを指示するために使っているものだからです。つまり、g p t four あるいは 3. 5 turbo に、この chunk が私たちの question に答えるために relevant な information を含んでいるかどうかを判断してもらっています。私たちは、自分たちの retrieval が relevant なのか irrelevant なのかを理解しようとしているだけです。そこで binary label が関わってきます。
つまり、はいかいいえか、relevant なのか？そして、これを行っている理由の一つは、これまで話してきたように、system を本当に benchmark するためです。ええと、この output は、Jason が触れたように、実際の retrieval の quality について分析を始められる場所になります。ええと、retrieval performance と、自分たちの retrieval を理解することは本当に重要です。なぜなら、それを行うのは非常に難しいからです。ですので、こうした新しい eval frameworks が登場する前は、自分たちの retrieval が良いのかどうかを知ることが不可能な場合もありました。responses を掘り下げたり、retrieve context を見たりして、ある程度推測するだけだったかもしれません。
しかし、これを使えば、自分たちの retrieval がうまく機能しているかどうかを、はるかに詳細かつ確実に知ることができます。ええと、それから、そうですね、ここで技術的な点を付け加えるなら、similar documents を見つけるために embeddings を使っているということです。これは大まかな検索アプローチです。Semantic search です。その latent space の中で近いものを見つけているのですが、document の取得の仕方という観点では、非常に、非常に大まかです。つまり、すべての dimensions が同じ扱いで、基本的には distance を見ているだけです。
ええと、そうですね。ここで私たちが行っているのは、はるかに繊細な check です。G P T four を使って、その embedding distance によるものが本当に question に答えられるものを返しているかどうかを見ています。だから、relevant である可能性はあります。例えば、platform arise のような words が大量にある例を見たことがあります。mm-hmm.
返された chunk と semantically similar な words がたくさんあるわけです。しかし、その chunk には question に答える可能性があるのか？それが G P T four が答えている中核的なことです。まさにその通りです。そしてこれは、similar であることが必ずしもより relevant であるとは限らない、という事実に結びついていると思います。そして、これにより実際の insight が得られます。つまり、はい、最も similar だったことは分かっているが、それは実際に私たちにとって relevant だったのか、ということが見えるようになります。では、この retrieve eval をもう少し詳しく review して、分解して見ていきたいと思います。ええと、ここでは query があり、次に vector database から retrieved された chunks がいくつかあります。例としては Zills や Novus かもしれません。
そして、前の slide で見た template もあります。そこで私たちが行っているのは、この template を、その query に対して、これらの chunks の一つ一つに適用し、その chunk が relevant かどうかを評価することです。そして、本番環境では、すべての run で、すべての chunk に対してこれを行うとは限らないかもしれません。percentage などで一部だけ sampling することを選ぶかもしれません。しかし goal は、物事がどれくらいうまくいっているのかを把握することです。
活用、つまり、別の L L M を活用することは、これを自動化する本当に優れた方法です。ええと、これについては後でも触れますが、これは人間によるラベリングの代替だと言っているわけではありません。ご存じのように、私たちは、優れたチームほどその両方を組み合わせているのを見ていますが、考え方としては、これに関するデータをできるだけ多く集めようということです。ですから、l lmm で自動化することで、これを効率的に行う力が本当に得られます。はい。
それから maje、ええと、私は「そうですね、eval では、その評価を行う要素のミスをどう考慮するのですか？」というような質問をしました。これは、あなたがちょうど触れたのと同じトピックにかなり当たっていると思います。つまり、今のトップチームは本当に両方を組み合わせて使っていると見ています。つまり、あなた、あなた、あなた、分かりますよね、人間のラベルがあり、これは関連しているかどうかを示す人間のラベルがあります。それはスケールできませんが、でも本当に信頼できるものです。つまり、あなた、あなた、結果についてかなり良い感触を持てるものです。L m e valves ははるかに大きく、はるかに広くスケールし、本番環境のプロキシになり得ます。そこにラベラーを付けられないときには、実際、良い直感的チェックを得るのに非常に役立ちます。
つまり、始めたばかりのチームもあります。もしあなたがハッカーで、自分のシステムを手早く直感的に確認したいだけなら、これらの evals は実際かなり良いプロキシです。ですから、私たちは、それらが完璧だとは思っていません。ええと、でも、でも G PT four、しかし私たちは、ええと、参照、ええと、mm-hmm. テストデータの中に、それらがどれくらい良いかの目安を示すものを持っています。
ええと、それから自分自身で信じられるように、自分の直感やデータセットを構築します。はい、その通りです。ですから、たとえば、eval とは何かから持ち帰るとすれば、繰り返しになりますが、それはプロキシ指標を自動化することです。それが、私たちがここで本当にやっていることです。ええと、そしてそれは、あなたが言ったように、人間によるラベリングの代替では決してありません。
はい。いいですね。それから QA eval についてですが、これは、rag システムに対して行う 2 つ目の eval です。ええと、ここでも querying context がありますが、今回は generated response も含めます。なぜなら、これは最終的にこの eval で評価するものだからです。そこで、取得されたコンテキストに基づいて質問が正しく回答されているかどうかを l l m に尋ねています。ですからここで分かるように、繰り返しになりますが、chunk が正しい回答を作成するためのすべての情報を持っていたかどうかを見ることができます。
そしてこれらは、私たちのフレームワーク内で利用できる rise の、ええと、LM evals と golden data sets の一部です。ですから繰り返しになりますが、今日は retrieval と QA eval に焦点を当てています。ええと、しかし他にも、自分のさまざまなタスクを benchmark するために使えるものが非常にたくさんありますし、ぜひ確認してみることを強くお勧めします。Jason が言ったように、それらは自分自身のものを作成するためのガイドラインとして使うことができますし、ぜひコミュニティや私たち全員がどんなものを生み出せるのかを見たいと思っています。ええと、とても楽しみなことです。
では今から、ここでもう少し楽しい内容に入っていくと思います。ええと、Jason がライブ例を案内してくれて、その後でもう少し分解して見ていきます。では Jason、引き継いでもらえますか？はい、ここで共有します。では、ええと、では、まず最初に、チームから、ええと、ええと、performance と何について、という質問がありました。では、これらの reach について、これらの、ええと、これらの eval metrics についてですが、私たちはさらに多くを展開予定です。ええと、ええと、私たちがしているのは、ええと、test data sets を持っているということです。それは、Sally Ann が言ったように、これが performance の proxy metric として使うのに十分良いかどうかを判断する、完全な benchmark フェーズがあります。
繰り返しになりますが、それは、本番環境で理解するために外に出てラベル付けを手伝ってくれるかもしれない hand labelers を置き換えるものではありませんし、あるいは、あるいは、構築においてもそうですが、でも良いものです。ただ、ここにはいくつかの performance metrics があります。Precision F one recall、ええと、異なる、ええと、異なる models、model types に対するものです。ええと、これは、分かりますよね、G P D four と three Turbo では、これらのいくつかについて大きな違いはありません。これら他のもののいくつかでは、q and a i のように、大きな違いが見えます。ですから、ええと、私たちは gut check template plus model を得る手助けをします。
そのタスクには十分でしょうか？ええと、でも私はあなた自身の、ええと、あー、自信を築くことをお勧めします。ええと、やあ Jason、そこで、その、あー、テーブルのところでちょっと止めてもらえるかな。誰かが、あの、検索をしているときの L L M の評価について質問していました。これはここで、さまざまな LMS の比較と、それらがどのように機能しているかが見える例です。そこを指摘しておきたいだけです。
はい。そしてこれは、いわば本番前のベンチマークです。なので、自分の evals がどれくらいうまく機能しているかについて、ある程度感覚をつかめます。自分のゴールデンデータセットを保存しておき、テンプレートやモデルについて安心できます。ええと、そしてそれが本番環境で動作します。
何らかのプロキシのパフォーマンス指標があり、そして、その上で手作業のラベリングも行うことができます。自分の直感的な確認を維持するために、つまり、あなたの、あなたの指標の直感的な確認を保つためですね？ ただし繰り返しますが、これは手作業のラベリングよりもスケールするプロキシ指標です。ええと、それについて考えると、arri、あの、Phoenix open source は、かなり素晴らしいソリューションで、evals と一緒にお見せしているものです。これは LAMA index と link chain でも数行のコードとして動きます。なので、文字どおり検索のためにこれを、これをここにドロップします。小さなリンクがあって、そのリンクをクリックするとローカルで実行されます。
これです。データをどこにも送信せず、完全にローカル実行で、クエリと、そして検索結果を見ることができます。これから検索について少し話しますが、ええと、私はこの、この re-ranking、ええと、ここにある l m 呼び出しの数のようなものを見ることができます。ここに re-ranking の、ええと、出力があります。ドロップして、LAMA Index と Ling chain によって使われているテンプレートを見ることができます。
ええと、つまり、そこには、そこには、そこには、データを収集できる方法があり、そしてここで収集されるこのすべてのデータがあります。なので、なので私は、あの、ここで簡単に、ある検索アプローチを、あの、もしかすると、ええと、より単純なアプローチと比較できます。つまり、ここでは、おそらくたぶん 6 回、6 回の L l m 呼び出しが、この 1 つに対してあるのがわかります。なので、ええと、あるいはここでの、最も単純なアプローチでは re-ranking がなく、ええと、単なる、シンプルな検索です。取得されたチャンクのパフォーマンス指標を見ることができます。
なので、これは本当に良いデバッグツールです。Open source で、Longman と link chain との統合は 1 行です。これの本当に良いところは、このすべてのデータを dataframe に戻せることです。ええと、なので後でこの notebook を公開しますが、これは rise docs 上の例で、クエリと N R R、M R R、D C G と一緒に saliann が実行しているすべての指標、ええと、そしてこれらの evals は、あー、自分で実行でき、そしてこれが自分のシステムで機能するという自信を自分で築くことができます。ええと、自分の docs に向けるだけでもできます。
なので、自分の docs と questions があれば、この同じ script が、動作します。ええと、通話後、ええと、通話後に提供します。素晴らしいです。もう一度画面を共有します。はい。
はい。他に話したかったことはありますか？ あー、それに関してもう一度、私たちが、はい、つまり、別の質問が投稿されていますし、少しこのことを見ていく予定ですが、あなたの経験では mm-hmm。eval の結果があまり良くなかった場合に検索を改善する方法にはどんなものがありますか、ええと、あー、より良い文書化された処理に注力しますか、より良い類似度指標に注力しますか？ そして答えは、私たちは多くの異なる失敗シナリオを見てきた、というものだと思います。なのでまず、Phoenix の目的は、実際にはそれらの問題がどこにあるのかの例まであなたを導くことだと言いたいです。私が見た問題の例としては、大量の重複チャンクを持つ人たちを見たことがあります。コンテキストウィンドウ内のすべてのチャンクが、まるで同じ mm-hmm. のような場合です。
同じことです。なぜなら、フランス語と英語があるんですが、それらは全部、なんというか、国ごとに異なるウェブページなんです。でも全部英語で、すべてのチャンクが重複していました。なので、そこにはそういう単純なことがあります。Ian がこれから説明するような複雑なものにもなり得ます。たとえば、K が大きすぎて、10件返していて、それがパフォーマンスを悪化させている、といったことです。そして実際には、使っているモデルには本当に、ごく少数のコンテキストが必要なんです。
たとえば、チャンクサイズが小さすぎるという例もあります。これは Sanne がこの後ここで説明するもう一つのものです。ドキュメント内の乱雑さのせいで、ゴミのようなものを返してしまう例も見たことがあります。たとえば、大量の文字があって、それがチャンクとして取得されるけれど、英語ではない、というようなものです。なので、データのクリーンさに関することや、検索システムを適切なパラメータ設定でセットアップすることに関することがたくさんあります。スクリプトが手助けしてくれるのは、まさにそういうことです。そして、デバッグのためのツールを提供することでもあります。失敗パターンは無数にあると思うので。
はい、はい。まったくその通りです。そして、さっきチャットで受けた質問は、私たちが最もよく聞かれる質問の一つだと思います。そして繰り返しになりますが、これ全体の動機の一部は、実際にそれを判断するための情報を持つことです。なぜなら、パフォーマンスの原因になり得る要素が本当にたくさんあるからです。
それで、Jason が言ったように、これらを具体的に取り上げて特定していくことで、これに対して何をすべきかを戦略的に決められるようにしていきます。いいですね。では、これまでに、あの構築ブログの中でいくつか話してきました。つまり、これらの eval をどのように構築しているかについて話しました。Jason が Phoenix ツールに入ってそれを見るところも、すでに見ました。でも、実際にこれらをどうベンチマークするかを議論することは、非常に重要な部分だと思います。なぜなら、ここから複雑さが出てき始めるからです。
では、retrieval eval に戻ります。ここにクエリがあります。クエリは二つ、zero と one があります。そして、返されたさまざまなチャンクもあります。すでに、eval を通して、これらの各チャンクに対して実行するという話はしました。でも、ここで実際にやっているのは、eval template を使ってこれらのラベルを生成することです。
eval template を覚えていれば、取得されたコンテキストは無関係か、それとも関連しているかを尋ねていました。そして、このゼロと一がそれを示しています。つまり、一は関連するコンテキストの一部で、ゼロは無関係なコンテキストの一部です。最初のクエリでは、関連するコンテキストを三つ返しましたが、二つ目のクエリではあまり良くありません。ここでは、関連するコンテキストが一つしかありません。これらのラベルを使ってできること、そしてこれが冒頭で Jason が話していた力の部分なのですが、たとえば、precision@ はどれくらいか、あるいはこれらの M r R はどれくらいか、というふうに言い始めることができます。つまり、検索のセットアップができていて、クエリがあり、eval に自信が持てるようになると、ここから本当に従来の検索および retrieval metrics を適用し始めることになります。これによって、はるかに簡単になります。
そして、自分が実際にパフォーマンスの観点で何を評価しているのかについて、より自信が持てるようになります。単に平均スコアを持つことについて話しましたよね。もしデータに歪みがある場合や、そういったものがある場合、全体的なパフォーマンスを本当に理解することはできません。これはそれを可能にしてくれます。そしておそらく、あなたにとってより慣れた方法でもあるでしょう。
というのも、これらの手法はかなり前から存在しているからです。ええと、そしてこれについては、Phoenix を使った本当に素晴らしいサンプルノートブックもいくつかあります。ええと、それは必ず皆さんに共有しますが、ぜひチェックしてみてください。生活がずっと楽になります。ええと、2つ目の retrieval、あ、すみません、eval 手法である q and a については、クエリ、チャンク、そして回答を見ていきます。つまりこれは、実施すべき追加レベルの分析のようなものです。
つまり最初の部分は、retrieval が良かったかどうか、ということです。ええと、でも今度は、回答が正しかったのか間違っていたのか、ということを言おうとしています。ええと、そしてこれに関するもう1つの要素は、取得されたコンテキストに基づいて l l m が完全な回答を知っていたのか、という点です。ですから、場合によっては回答の一部はあるかもしれませんが、完全な回答はコンテキストに含まれていないことがあります。そしてこの eval は、その点を理解するのにも役立ちます。ええと、そしてこの QA 部分から学べることはたくさんあると思います。なぜなら、qa に影響を与える要素はたくさんありますし、何が良い retrieval を定義するのかを正確にはまだ分かっていないからです。ですので、今後さらに多くのことが出てくると確実に期待しています。ただ、私たちがある程度確信していることの1つは、良い retrieval と良い qa 結果の間には、何らかの相関関係があるということです。
Jason、先に進む前に、これに何か付け加えることはありますか？ええ、つまり、ウェビナーのチャットで大きな、大きな質問があって、それはまさにあなたが触れたことに当たるものです。つまり、l m の動作の仕方を考えたときに、N D C G M R R が見るべきものなのか、ということです。ええと、そして私たちが見てきたこととしては、繰り返しになりますが、自分自身の直感を築き、私たちのスクリプトを使い、自分がすべきだと思うことを何でも行ってください。ええと、ただ、ここでは良い retrieval 結果と良い q and a eval の間に相関が見られます。ですから繰り返しますが、全体として、正しい質問を得られたのか？ということです。この2つは、良い retrieval があると、うまくいき、良い q and a が得られます。N D C G と MRR が本当に役立つ、基本的な問題の切り分けや土台作りが非常に多いと思います。うん。
たとえば、私が挙げた例のように、文字だけのチャンクがあった場合です。それを見つけた方法は、つまり、これらの多くで MRI がほぼゼロになっていて、「え、何が起きているんだ？」となったことです。そして、ええ、これは基本的な問題の切り分けに役立ちます。本当に、本当にクリーンなデータや、ある程度まともな retrieval に到達していくと、おそらく他のことに取り組むことになるでしょう。たとえば、全体的にこれらの q and a eval を見て、自分が行っている次の一連の微調整が機能しているかどうかを理解する、といったことです。でも、これは間違いなく有用だと思います。非常に有用で、コアとなるセットアップ上の問題や retrieval システムの問題を捉えるのに役立つと思います。ただし、それだけがすべてではありません。
そして、ここでのポイントはそこだと思います。はい、確かにそうです。そして、特定の問題、lost in the middle 問題についても、ええと、そこで議論されているものですが、eval はそれを特定する助けになる力があると思います。というのも、どのチャンクが本当に良い回答を提供しているのか、あるいはどのチャンクが本当に関連しているのかを実際に確認できるからです。そして、関連するものが真ん中にあると分かっていて、そのうえで q and a で悪い応答が返ってきていることに気づいた場合、それはまさに私たちが lost in the middle を経験していることを示しています。
ですから、その問題に対しても eval には間違いなく価値があります。いいですね。さて、私たちは eval についてたくさん話してきました。ここで少し、モデルを評価するための並行した方法に切り替えたいと思います。それは、retrieval setups を横断的に試すのに役立つスクリプトです。これはすごくクールだと思います。なぜなら、自分の docs を指定して、さまざまな options を一通り試せるからです。
それで、ほら、以前に受けた、何をすればいいの？とか、最適なセットアップは何？みたいな質問、あるいは私たちがいつも受けるその質問に対して、これは本当に役立ちます。だから、ほら、統合したい範囲にわたって、異なるチャンクサイズを設定できます。異なる k も設定できて、それで、ほら、結果が得られます。何度か言いましたが、これは私たちが受ける最も一般的な質問の一つで、この retrieval を実際にどう設定するか、どれが最良の選択肢か、というものです。ええと、だから私たちが実際にチームに可能にしているのは、ほら、これらのセットアップを一通り試して、それから、セットアップに関して行う意思決定を支えるこれらの結果があるので、ある程度の厳密さをもってシステムを設定することです。
ええと、それで、ほら、これは、ほら、開発のユースケースには少しより関連があるかもしれませんが、ええと、それでも、私は、これはすごくクールだと思っていて、もう少ししたらその結果のいくつかについて話し合います。はい、それから、私は、ええと、私たちは今週これらのスクリプトの一部をリリースし始めたばかりで、ええと、まだ初期段階です。だから、フィードバック、フィードバックは歓迎です。ええと、この、このバージョンのスクリプトは、ええと、LAMA index 向けで、lane chain の、ええと、バージョンも来る予定です。ええと、それで、はい、ええと、かなり役立っていると思います。
その、その一つの注意点は、ほら、一般的に evals は、全般的に遅いということです。私としては、実際に一番遅いのは、実は、その、querying と question and answer systems 自体だと思います。だから mm-hmm. 何百、何百もの質問を通して実行して、ええと、QA 的に、これらの異なることを行うには、ほら、時間がかかります。これは、この、この sweep は実行に 24 時間以上かかるかもしれません。ええ、ものすごく高価というわけではありません。
相対的に言えば、また予算次第ではありますが、ええと、でも、その、その、その遅さは、今のところこれらのシステムの多くでは自然なものですFor sure. それで、ほら、私たちはその大きな、遅い部分を実験しています。だから調整するにつれて、実装だけでも、そうですよね、例えば、ほら、re-rank は、単に、ほら、取得するだけの元の実装よりもずっと時間がかかります。なので、それもすべて間違いなく要因になります。それで、正直に言うと、私が今遅いと感じているものは。
だから、つまり私たちのライブラリ、つまり evals 用の Phoenix library は、可能な限り pipe を埋めるように設計されています。ええと、ほら、open ai への呼び出しをたくさん fork しますが、その、その link chains と LAMA indexes は、呼び出しを一つずつ順番に行うような感じです。だから、それらが今は gating calls のようになりがちです。それら、それらのアプローチは、かなり遅いです。通常、次の query を開始する前に、一つが返ってくるのを待ちます。For sure.
For sure. では、あるいは少なくとも maybeAt least they don't fill the pipes. Yep. Yeah. 少なくとも同じようには、ではありません。
Yeah. ええと、素晴らしいです。では、ここで見ている、ほら、これら個々の、ほら、sweeps について、もう少し詳しく話し合いましょう。まず chunk size sweep からです。ええと、ここではおそらく想像どおり、chunks の数またはサイズを変えています。ここでは 500 と 1000 の token sizes があり、それから、ほら、これらを評価して、ほら、relevance や correctness、あるいはこの chunk size を使った全体的な performance を本当に確認できます。ここでは K を標準の 4 として使っているだけだとわかります。なのでこの例では、ええと、k は変えておらず、単に、私たちの、chunk size を変えているだけです。ええと、k については、非常によく似ていますが、今度は、ほら、ちょうど逆です。今度は k を変えていて、K values として 4 と 6 があり、それらを比較しています。ええと、そして chunk size は 500 のままにしています。つまりそれを標準に保っていて、繰り返しますが、ほら、異なる K values を見ることで全体的な performance を得るために、これを sweep できます。ええと、K values は、ええと、your context windows とも呼ばれるものです。それは、返すことになる chunks の数です。なので間違いなく重要なものです。
ええと、それから、ご存じのように、retrieval transformation も見ることができます。つまり、先ほど話していた、original や re in、あるいは hide のようなものです。ええと、試して比較できるさまざまな transformation があります。ここでは original を見ていて、そして繰り返しになりますが、比較することができ、これらを、ええと、別のパラメータに差し替えることもできます。そして実際に、分析できる結果が得られ、それによって本当に最適な戦略を判断できます。
この sweeping method は、たとえば、どうやって retrieval を改善する方法がわかるのか、という質問に答えるための方法のひとつです。そうですね、これはそのためにできる方法のひとつかもしれませんし、先ほど話していた evals も同様です。ええと、では、実際に得られる結果と、それをどう解釈できるかについて話しましょう。これは、AriseDoc 上に構築した chat bot のために行った chunking retrieval eval の結果セットです。これは arise documentation を使って動いている chat bot です。私たちの customer base から通常受けるいくつかの質問でテストしています。
ええと、そしてまず最初に、これらすべてについて前置きしておきたいのですが、皆さんの use case では同じ insights が見えないかもしれませんよね。私たちは異なる docs を使っているので、insights はそこで変わってきます。ですので、これを聞いて、ええと、Sally と Jason がこう言っていたから、これが存在するものなんだ、と思って帰ってほしくはありません。これはあくまで私たちの documentation に対するものなので、ぜひご自身のもので試してみてください。ええと、ただしポイントは、insights は得られるということです。ええと、ここを見てみると、ご存じのように、4 つの異なる checking methods があり、さらに 2 つの異なる methods と 3 つの異なる K も見ています。
ですので、たくさんのことが起きています。ここにある結果には、先ほど話していたすべての結果、あるいはすべての evals が含まれています。ええと、そして、すべての re-rank のものを見ると、ええと、この左上のあたりに注目すると、これは chunk size が 100 で、2 つの異なる ranking metrics があります。そして、ええと、いや、すみません、retrieval methods です。ええと、ここで注目に値するのは、retrieval の観点で明らかに少し良い performance が得られているということだと思います。
繰り返しになりますが、これは retrieval であって、question answering ではありません。re-rank によって、より良い performance が見られています。ですので、ええと、これはすぐに見て取れる insight のひとつです。それから、なんとなく見えると思いますが、ご存じのように、chunk sizes が大きくなるにつれて、あるいは k が増えるほど、performance が、ええと、少し下がっていくかもしれません。はい。
そして、そして、期待されるのは、K が大きくなるにつれて、retrieval performance は下がる、下がるということです。ただ、もしそれがうまく機能していなかった場合に実際に予想されるほどには急激には下がっていません。この slope は、あなたが実際に見積もるほど急ではありません。もし、より良く機能していなかったとしたら、ですが。とはいえ、ええと、もちろんです。では、他のものについて続けていきます。いいですね。はい。
ええと、オーケー。これらについて話したかったですか、それとも他の、他の結果のことでしたか？たぶん、次の、次の他の結果ですか？はい、次の slide です。はい。ではこちらですが、ここでも指摘しておきたいのは、私たちが使っている metric は precision at K ですが、もちろん M R R も見ることができるという点です。そして MRI について注意すべき点のひとつは、retrieve context の順序にやや影響を受けやすいということです。
ですので、それは間違いなく念頭に置いておくべきことです。少し相対的ではありますが、ええと、注目に値すると思う点です。ええと、前の slide で precision at K について見ていたのと同じ、または類似した patterns が見えています。ですので、ここでも分かるように、re ranks がほんの少し良いです。これらの maps では隣り合っていないので見づらいですが、それでもそれが見えています。
そして同様に、ええと、おそらく、えー、Kを増やしたり、あるいは、より大きなtrunkサイズを追加したりするにつれて、うーん、パフォーマンスが悪化しているのが見えているかもしれません。うーん、この検索ユースケースに本当に使用を推奨する指標は、この2つだと思います。うーん、私たちは、うーん、検索はより良いのに、その後のQAはより良い、という場所も確かに見ています。うーん、ただ、考慮したいもう1つのコンポーネントもあります。でもその前に、あ、見えたのは、ああ、ただのチャットですね。
もしかすると質問が来ているのかと思いました。はい。うーん、そして、そして繰り返しになりますが、これらのいくつかは、M R Rやクラスターのようなものに本当に優れていて、これはPhoenixで私たちがある程度行っていること、あるいは全体としてのM R Rで、つまり、個別項目ごとの基準では、個々の問題をトラブルシューティングするのに非常に役立ちます。そしてそれは、これから話す次のこと、つまり、えー、全体的なQ&Aパフォーマンスと相関しています。うーん、まさにその通りです。はい、これはPhoenixがトラブルシューティングの観点で本当に提供できるものの、ほんの小さな一部です。
うーん、ただ、ここにいる皆さんがL oneシステムを構築しているときにおそらく考えたことがあるであろうもう1つのコンポーネントは、レイテンシです。うーん、なので、これは、ここで考慮すべき本当に大きな、えー、ポイントです。というのも、ほら、本当に、まあ複雑なアプローチを選ぶときには、パフォーマンスと、レイテンシの間に、いくつかのトレードオフが予想されるからです。ですから、私たちには、これらのバランスを取ろうとする役割が本当にあります。うーん、先ほど述べたように、re-rankはより計算コストが高いので、うーん、ここでそれほど驚きはありません。少し複雑で、それに伴ってより高いレイテンシがあります。ですから、それは、より良い検索を得るためにre-rankを使うこととの間で、バランスを取る必要があるものかもしれません。
でも、もしレイテンシが非常に重要なら、別の方法を選びたいかもしれません。うーん、でも、はい。Jason、何か補足はありますか？はい、つまり私の、私の補足としては、これはcoherence re-rankの、えー、LAMA index内での呼び出しをここに入れたものです。そして、人間とやり取りするものを何か出している人にとっては、右側のものはほとんど使えないのではないかと思います。例えば、その、その、その、4または6 kssと小さなチャンク、たぶん500のchunk sizeのものです。私は、私は、つまり、たぶんより小さいウィンドウを選ぶと思います。Q&Aパフォーマンスで見ることになるように、その、simple methodと、より小さなウィンドウが、おそらく、うーん、選ぶべきより強いものです。
なので、重要なのは、人々が出している派手な新しい検索アルゴリズムや、誰かが出した検索アプローチにただ引き込まれないことだと思います。どれくらいうまく機能していて、どれくらい追加の時間と遅延を加えるのか、ということです。まさにその通りです。そして、私は、ほら、その変更を加える前に、この本当に派手な新しい方法を見て、すぐに「自分のシステムに入れてみよう」と思うかもしれません。でも、これは、それが最終的なパフォーマンスの、レイテンシの観点でどのような影響を持つかを実際に見ることを可能にします。つまり、それは本当に私のパフォーマンス改善に役立つのか？ということを確認できます。なので、これはそのために間違いなく役立ちます。
ここまで、あるいはこの数枚のスライドでは、検索の観点からこれを見てきましたが、先ほど話したように、2つ目のコンポーネント、Q&Aパフォーマンス、全体としてどれくらいうまくできているか、があります。そしてそれが、ここで皆さんのために本当に要約しているものです。さて、ここには多くの異なる可視化があります。私たちは、私たちは多くの異なる、うーん、コンポーネントを見ています。chunk size、方法、K値があり、そしてQA evalsからの不正解の割合を見ています。そしてここでは、うーん、300または500あたりの真ん中に、いわばスイートスポットがあります。
ここでは、このかなり低い、ええと、不正解の、ええ、割合でそれが見えているように思えます。ええと、そしてこれは、まあ、100サイズや1000サイズのチャンクよりは少し良いです。ええと、そしてここでできることとしては、これらの結果を見たときに質問をし始めることです。なので、私がこれらを見ていたときに持った質問の1つは、ここにあるこのグラフを見たときで、チャンクが1000だと言っているところ、つまり、元のものを使っていて、Kが10で、これはかなり大きなコンテキストウィンドウです。なので、これを見ると考え始めます。つまり、ここにはかなり多くの不正解の、ええ、応答があるな、と。
もしかするとウィンドウをあふれさせているのかもしれないし、これは関連するコンテキストが失われて、ええと、L l Mに忘れられてしまう「lost in the middle」問題なのかもしれません。つまり、これらの結果によって、そうした質問を投げかけ、それを掘り下げ、そして本当に、ええと、これらの異なる要素のバランスを取り、システムを本当に最適化するための情報を全体として得ることができます。より興味深いものの1つは、パターンで、つまり、これが一貫しているかどうかを見ているところです。私たちはこれを自分たちのドキュメントと、さらに多くの顧客の、ええと、ドキュメント、ええ、これを使っている顧客のドキュメントの両方で実行しています。そして、kを4から6、10へと増やすと、検索方法に関係なく悪化するというのはかなり一貫しています。うん。
だから、つまり、私の一部は、ええと、私は、その結果が本当に正しいのかもっと深く掘り下げて確認したいと思っています。ええと、それは、ええ、それは、ウィンドウをシンプルに保ち、取得したドキュメントを高品質に保つ方向へ進ませるように見えます。ええと、そしてウィンドウに入れるゴミが多ければ多いほど、その、その、結果は悪くなるということです。ええと、これがさらに多くのドキュメントでテストして、ええと、まあ、さらに経験を積む中でどれだけ成り立つか見ていきます。確かに。私、私はあなたも同じように感じていると思います、Jason、でも、これらすべては今後数か月、数年の間におそらくあと10回は変わるだろうと想像しています。この、ええ、ええ、この分野全体が進化し続けるにつれて。だから、これは、これらすべてを試して、本当にうまく機能する最良の方法を見つけられる、わくわくする時期です。
さて、いいですね。いいですね。ここまででたくさんのことを行い、多くの情報を扱ってきました。evalsが何であるかを理解し、構成要素にたどり着き、今では結果の見方や、evalsを実行することでどのような結果が期待できるかがわかっています。ええと、そしてここで少し触れておくべき重要なことは、いくつかの、あるいは実際には、これらのrag、ええと、システムに関して本番環境で見られる課題です。
そしてそれは本当に、私たちの顧客の多く、そして世の中の多くのアプリケーションや組織が大量のドキュメントを持っているという事実です。つまり、これは、ベクトルデータベース内に何百万ものチャンクを生む可能性がありますが、その一方で、妥当な、ええ、検索ができるように、チャンクの数を妥当なものに制限する必要もあります。そして、つまり、ナレッジベースから正しいコンテキストの断片を取得する必要もあります。なので、これは、私たちが抱えている本当に興味深く複雑な問題です。そして、そして、AIメモリや、LMSを、ええと、顧客データや自分自身のデータで使うことについて話すとき、ええと、それは、私たちが対処しているまさにこの問題であり、しばらくの間対処し続けることになる問題なのです。
これこそが、こうした l m エコシステムの本当の未来である可能性が高いです。つまり、ここで本当に話しているのは、チャンクの数をどう管理するのか、そのチャンクを使った検索が実際にどれくらいうまく機能しているのか、ということです。そして、データをどうやって可能な限り最善の形でプロンプトに取り込むのか、ということなんです。ええと、それが、私たちが今直面している問題です。ええと、これについて、今後の方向性について話す前に何か付け加えることはありますか？そうですね、つまり、私の唯一のポイントは、これを解決するために人々がやっていることのいくつかについてこれから話しますが、でも、根本的には、今後5年を考えると、LLMは、その、コンテキストウィンドウは大きくなっていくでしょうが、無限にはなりません。うん。そして、ドキュメントがあり、与えたいデータがあるでしょう。
そして、そのデータは大きく、通常は大量にあります。ですから、この、どうやって l l m に良いデータをコンテキストウィンドウへ、そして適切なデータを与えるのか、という問題は、今のこの RAG の瞬間だけにとどまらないものだと思います。うん。LMS を自分のデータと連携させる方法というのは、今後 X 年間にわたる根本的な問題です。そして、これについて考えることは、私たちがかなり多く考えていることです。
ええと、そして、そして、そして、今私たちが見ていることの一つとして、ええと、シンプルな方法、いわば、これを助けるためのハンマー方式のようなものがあります。これは次に、私たちが提示する内容です。はい。ええと、Jason がここで話しているのは、私たちが実際に見出しているのは、セマンティック検索と構造化されたフィルタリング機能のようなものを組み合わせること、ええと、それこそが、これに対する潜在的な解決策になり得ると私たちが見ているものだということです。つまり、ここでの考え方は、このメタデータを追加することです。ここでは、たとえば、これらの location メタデータを追加しています。us があり、France があり、他の国々も混ざっているかもしれません。
そして、これによって実際に可能になるのは、特定のデータセットに対してフィルタをかけ、そのうえでセマンティック検索を行うことです。たとえば SQL のような従来のクエリ手法を考えると、人々はそれを好みます。なぜなら、データを絞り込んで、必要なデータだけを取得するのに非常に効率的だからです。そして私たちは、ベクトルデータベースが進化し続けるにつれて、ええと、こうしたフィルタがますます統合されていくと考えていますし、それは、何百万、何百万ものチャンクをどう管理し、ユーザーのクエリに対して可能な限り最良のコンテキストの断片を取得できるようにするか、という問題に対する潜在的な解決策になるかもしれません。はい。
私は、ここがポイントだと思います。つまり、その検索方法が、潜在空間内の embeddings を見て距離アプローチを取るものである限り、ええと、それは非常に粗い検索です。つまり、基本的には距離の球体であり、潜在空間です。そして、その粗い方法では、チャンクが増えれば増えるほど、正しいものが返ってこない可能性が高くなります。だから、検索方法がシンプルで、高速で、距離ベースのままである限り、そして、もっと複雑になる可能性もありますが、ええと、現時点ではそういうものです。その、良い解決策の一つ、簡単でシンプルで、誰もが理解できる解決策は、そして、おそらくすでに持っているものですが、分割することです。
すべてのデータをただ詰め込むのではなく、製品カテゴリ別、地域別、何らかの簡単なグループ別に分けることです。つまり、あなたが、わかっている、あるいは、たとえば e-commerce サイトでは、検索の一部として誰かが持っているかもしれないフィルタのようなもので分けています。なので、ええと、特により大きなシステムを作っている場合には、よく考えることをおすすめします。確かに。そして、かなり最初の方に受けた、検索をどう改善するか、という質問に戻ると、これもまた、ここで試してみる別の方法かもしれません。いいですね。素晴らしい。
ええと、うーん、これで、つまり、あー、私たちのプレゼンテーションは終わりです。これからは、うーん、質問を受け付けますが、こちらは皆さん向けの、うーん、リンクです。いくつかの colab にアクセスできますし、うーん、rag 用の GitHub もあります。あー、それから私たちの Phoenix ツールもチェックしてみてください。もしよければ、うーん、私たちの GitHub にスターを付けてください。そんなところです。
あー、私たちにどんな質問がありますか？はい、彼ら、彼らは途中でたくさん、私たちはある意味まず、素晴らしい、あー、素晴らしいセッションをありがとうございます。うーん、original と re-rank の違いは何ですか？あー、はい、では、original は、ただ、あー、クエリを埋め込んで、意味的に類似した、ほら、うーん、ものを取得するだけです。なので、それはある意味、ほとんどの人が、使っている、非常に伝統的な、うーん、rag アプローチのようなものです。そして re-rank は COHEs の re-rank を使って、取得されたコンテキストを再ランク付けし、うーん、そして Lum index と COHEs の re-rank のようなバージョンを組み合わせて使っています。
なるほど。それから結果に関してもう一つ質問があります。次に何をしますか？それらをまた画面に出しましょう。はい。うーん、あー、結果に関してですが、つまり、なので、この例を順に見ていくと、もし今自分のシステムのパラメータ設定を選ぶなら、チャンクサイズに関しては 300 か 500 を選ぶと思います。もしかすると、この場合は 3 でもいいかもしれません。
そしておそらく K は、そうですね、4、4 か 6、うーん、小さめで使います。なので、私がやることは、自分のパラメータ設定を選ぶことだと思います。つまり、これは最初のセットアップで役立ちます。うーん、おそらく Phoenix を使って、残りの問題を見つけられるようにすると思います。つまり、顧客からさらにデータが送られてきたり、実行したいテストセットがある場合に、うーん、Phoenix を使って、本当に、どこで M R R が失敗しているのかをマッピングします。よし、このグループはどんな感じか？よし、これはゴミのようなチャンクなのか、それとも何か別のものか？うーん、なので、これを最初の優先順位付けに使い、その後は、ほら、うーん、実績のあるトラブルシューティング、良いテストデータセットの構築、それを実行し、それらのツールを使って、一般的な問題を絞り込む、ということをすると思います。うーん、おそらく常に、継続的にぶつかることになる問題ですし、それらを取り除いたとしても、本番環境に進むにつれてさらに増えていくでしょう。
うーん、なので、あー、それが、おそらく私がやることです。うーん、それから、すみません、chunk overlap は見えていませんでした。はい、chunk over。いいですね。良い質問です。
素晴らしい、素晴らしい、素晴らしい質問です。chunk overlap も別のパラメータです。うーん、スクリプトに追加する予定です。今のスクリプトには入っていませんが、パフォーマンスを向上させるために人々が使う、もう一つの一般的なものです。つまり、いくらか、ある程度のオーバーラップを得ようとする、つまり、そこにあるチャンク同士に、完全にばらばらにするのではなく、オーバーラップを持たせようとするものです。
うーん、いい、いい指摘です。現在のスクリプトでは、あー、パラメータにはなっていません。皆さんはどうかわかりませんが、うーん、Vis と Zillow のチームでは間違いなく、チャンク化戦略について非常に多くの質問を受けます。うんうん。うーん、皆さんは多くの経験がありますよね？この素晴らしいツールセットを作ってきました。
うーん、ほとんどの人がどこで間違えると感じますか、そして最もよく見かけるのはどのようなことで、では、人々がそうした最初の間違いを避けるにはどうするのがよいと勧めますか？はい。私は、私は、間違いの核心的な領域は、測定を持たずに、新しくてピカピカでクールなものを追いかけることだと思います。うーん、それが、私の、私の、私の、私の皆さんへの推しです。何か測定を用意してください。それによって、この戦略とこの戦略を比較して、何がどうなのかを理解できるようにするものです。そして、そしてもう一つ、私が入れておきたいこと、そして人々が間違えると思うのは、うーん、データがけっこう重要だということです。なので、最初にいくつかのテスト質問や、ほら、いくつかのテストセットを用意することです。そして、時にはそれらがないこともあります。その場合は生成できます。私たちは、今週の初めに llama index とセッションを行いましたが、彼らにはチャンクから質問を生成するための素晴らしいツールがいくつかあります。ただ、合成データも役立ちます。
それは、あなたが持っているデータを置き換えるものではありません。Jerryのメモは、テスト質問はチャンクがガラクタならガラクタになり得るので注意、という感じでした。ええと、だから私は、大きいのはデータだと思います。データを用意し、テストを用意することです。ええと、それから、結果が示しているように思えるのは、チャンクサイズを大きくしすぎない、小さくしすぎない、ということです。つまり、現時点では、これらのモデルのコンテキストウィンドウと強みを踏まえると、ちょうどよい量というものがあります。また、どのようなクエリなのか、そしてシステムが何をするように設計されているのかを考慮することも、チャンクサイズを決めるうえで役に立つと思います。ええ、なのでそこももう一つの役立つヒントです。では、あなたは自社の製品ドキュメントでテストしていたとおっしゃっていましたね。
自分にドメイン知識があるものをテストすることは、これらの評価結果を解釈するのに役立ちますか？そういう人間によるチェックポイントのようなものとして、あるいはそれはどのように関係しますか？ええ、私の答えをお伝えしてから、Jasonに少し詳しく話してもらいます。でも、自分たちのl l mを見ていて、そのデータに何が含まれているかを知っていて、目の前のタスクが何かを知っていると、返ってきた結果を評価するのは少し簡単になると思います。ええと、たとえば私たちのドキュメントの場合、公開されているドキュメントの中に価格に関するドキュメントがないことは分かっています。ですから、評価を見ていて、たとえば価格に関する質問がある場合、その質問に答えるためのコンテキストを持っていないことが分かりますよね。
そうなると、評価でそれが見えているなら、それは検索の問題ではないのかもしれません。むしろ、ナレッジベースの問題、あるいはプロンプトエンジニアリングの問題かもしれません、すみません。ええと、そして、知らない質問に答えないようにすることです。なので、ドメイン専門知識とまではいかなくても、自分たちのナレッジベースが何か、たぶん利用可能なドキュメントが何か、そして実際にこのl mに何を期待しているのかを理解していることは、これらの結果を評価するうえで本当に役立つと思います。Jason、この点について何か付け加えることはありますか？よかったと思います。
質問をうまく、うまく、うまく捉えていたと思いますし、はい。ありがとうございます。完璧です。それからチャットに別の質問があります。ええと、検索フェーズでl l mを適用するrag技術もあります。
うん。ええと、たとえば、十分以上のチャンクを検索して、L Lmmを使って無関係なものを除外できます。この方法では、すべてのチャンクが関連するようにされるため、ええと、N D C G D C G M R Rは有用性が下がるのではないかと思います。ええ、そうですね、すごく良い質問です。ちなみに、私たちはhideのような、より高度な手法も使いました。
ここでの例では、より複雑で、より中心を捉えた質問を生成しています。ええと、でも、そうしたものはすべて、私は、その一部には実際かなり見込みがあると思います。ここでの結果を踏まえると、先ほど触れたもの、つまりウィンドウから不要なものを取り除くこと、つまりコンテキストウィンドウの中で、生成ステップの前に関連性のないものを取り除くことには、実際かなり見込みがあると思います。ええと、繰り返しになりますが、私は測定を見ましょう、結果を見ましょう、というところに戻ってきます。また、そうしたより高度な手法であっても、なお多くの、ええと、うまくいかない可能性のあることがたくさんあると思います。
ですから、私は、これらの指標をすべて取り除くべきだとは思いません。システム内の問題を見つける方法として、それらは必要になると思います。ええと、でも、でも良い指摘だと思います。良い指摘でした。ええと、参加者からもう一つ質問です。cohereや、ええと、基本的なクロスエンコーダを使わずに再ランキングする他の方法にはどのようなものがありますか？ええ、つまり、私は、私は、つまり、なしで、acoなしでやることになると思います。
ええと、私は、たぶんあなたは、たぶん、ええと、あの、l l m か、あるいは内部の、たとえば lmm のようなものを使っているんじゃないかと思います。もし、より高機能な側にいるなら。そして、もしローカルモデルを使えるなら、ええと、私なら、hugging face タイプのものを見るようなアプローチもあると言うと思います。でも、そうですね、私は、クロスエンコーダーと、ええと、L L M がたぶん、その、あの、そうしたアプローチがたぶん、ええと、より、あの、私が見ているもの、より多くの、ええと、そうですね、その、つまり、それらについて今私たちが見ている課題は、ただ、その、かかる時間です。だから、ええと、そうですね、リアルタイムシステムを扱っている皆さん、あるいは私たちにとっては、ええと、そうした二重のコールバックのようなものが少し時間を取っているというのが課題です。なので、それが今みんなが取り組んでいるものだと思います。リランクを行うには、たぶんそれによって価値を得られる、あるいはウィンドウから何かを落とすなら大きな価値を得られるかもしれませんが、ええと、それを速く行うには、たぶん何らかの形でそうしたローカルモデルが必要になると思います。
素晴らしいです。ありがとうございます。ええと、質問があります。ええ、単なる個人的な好奇心からです。皆さんから共有したいことはありますか、ええと、Phoenix チームにおける Arise の台頭から、人々が注目しておくべきことについて。ええと、ああ、ええ、私は、そうですね、これらの評価、ええと、セットなどに関する重要なポイントの一つは、つまり、私たちはこうしたものをもっとやろうとしているということだと思います。
私たちは、ここで evals セットの最後に、本当に合成 GE データ生成に関するセッションを追加する予定です。私たちは、それが、あなたの evals から始めて、いくらかのデータをまとめるうえで重要な部分だと感じています。それは、あなたの、ええと、あの、あなたの、あなたの、あなたの現在のデータセットの置き換えではありません。なので、そうですね、それに関する別のセッションを期待してください。そして、ええ、それから Phoenix には本当にたくさん、たくさんのものが控えています。
なので、ええ、そこには retrieval と embedding space を可視化するための素晴らしいツールがいくつかあります。私たちはそれを、これから来る spans や traces のものにもう少しうまく結びつけています。ええと、たくさん期待してください。あのチームには、ええと、あの、まだ展開していない仕込みがたくさんあります。いいですね。今のところ質問は以上だと思います。
皆さんに最後の1分だけお時間を差し上げます。ええと、でも何か、ええと、皆さん、今日話したことについて考える中で、最後に共有したいこと、ええと、何か持ち帰りたいポイントはありますか？わかりませんが、どうぞ自由に。私は、あの、ぜひ私たちのコミュニティに参加してください。私たちはいつもこうしたことについて話しています。Arise、ええと、コミュニティはかなり大きくて、これは、これは私たちの関心事です。
質問があれば、そこにメモを残したりフォローアップしたりしてもかまいません。ええと、私たちは、あの、私たちは皆、この分野に取り組んでいる技術者で、あの、測定とデータを、あの、少し科学的なものを加えようとしています。いいですね。ええと、Sian、QRコードをもう一度共有していただけますか？完璧です。これが、ええ、それらのコードを取得する最後の、最後のチャンスです。
必ず、ええ、Arise チームとつながって、彼らのコミュニティに参加してください。彼らは本当にクールなことをたくさん進めています。ええと、尋ねている皆さんのために、録画はおそらく今日中に公開します。ええ、このセッションに参加していただき、本当にありがとうございます。Sally と Jason、本当に素晴らしかったです。
お立ち寄りいただき本当に感謝していますし、ええ、皆さんが構築し、創り出すすべてのものを見るのを楽しみにしています。お招きいただきありがとうございます。感謝します。ええ、お招きいただきありがとうございます。では。
ありがとうございます。