Join the Webinar
Loading...
何を学べますか？
Retrieval-Augmented Generation（RAG）は、高度な質問応答システムから先進的なセマンティック検索エンジンまで、生成AIアプリケーションの最新の波を支える基盤技術として台頭してきました。RAGの人気が高まるにつれ、従来のRAGパイプラインを強化することを約束する手法が次々と登場しています。これらのイノベーションには、クエリの書き換え、インテリジェントなルーティング、結果の再ランキングが含まれますが、それらがアプリケーションのパフォーマンスに与える実際の影響をどのように測定すればよいのでしょうか？
情報提供型ウェビナーにぜひご参加ください。このウェビナーでは、LLM-as-a-Judgeの手法、業界標準のベンチマークデータセット、革新的な合成データ生成技術など、堅牢な評価フレームワークを探ります。このセッションの終わりには、RAGシステムを評価・最適化するための実践的なアプローチを習得し、これらのツールを自分のアプリケーションで効果的に実装するための知識を身につけることができます。
取り上げるトピック：
- LLM-as-a-Judge
- MT-Bench
- LM Eval Harness
- 合成データ生成
本日は、今日のセッション「Retrieval Augmented Generationの評価」と、ゲストスピーカーのStephan Webbをご紹介できることをうれしく思います。StefanはZillowsのデベロッパーアドボケイトで、オープンソースのベクトルデータベースvisの普及に取り組んでいます。それ以前は、Twitterとmetaで応用MLリサーチャーとして業界で3年間過ごし、プロダクトチームと協力して最も複雑な課題に取り組んできました。StephanはUniversity of Oxfordで博士号を取得しており、nips、ICLR、ICMLなどの主要な機械学習カンファレンスで論文を発表しています。彼は生成AIに情熱を持っており、その深い、ええと、技術的専門知識を活かしてオープンソースコミュニティに貢献したいと考えています。
ようこそStefan、それではセッションを始めてください。はい、ACHI、ご紹介いただき本当にありがとうございます。それで、ええと、参加者の皆さんにも、ここに来てくださってありがとうございますと言いたいと思います。生成AIの分野では、競合するウェビナーや対面イベントが本当にたくさんあると思います。ですので、ええと、これを選んでくださってありがとうございます。
ええと、まず始める前に、このスライドに私の連絡先を載せています。それで、つまり、私のデベロッパーアドボケイトとしての役割は、開発者と、ええと、melvicのユーザー、ええと、私たちのオープンソースのベクトルデータベースとの間のギャップを埋めることです。つまり、ええと、私は本質的に誰とでも、ええと、つながることが本当に好きです。ですので、もし、例えば少しお話ししたい、ベクトルデータベースやragについて質問がある、ええと、そういったことだけでなく、皆さんが何を作っているのかについてもぜひ聞かせていただきたいです。ええと、皆さんの多くは、スタートアップで本当にクールな新しいアプリケーションを作っているのではないかと思います。ですので、ええと、どうぞそのアドレスにメールを送ってください。
LinkedInでフォローして、ええと、LinkedInメッセージを送ってください。どれも本当に、本当に歓迎です。では始めましょう。それで、ええと、今日のトピックについてですが、ええと、私は最初「Bragの評価」と呼んでいたのですが、その後、まあ、もう少し、ええと、RAGを評価する理由の結果、あるいは、RAGを評価する背後にある動機を示すようなタイトルの方がよいかもしれないと思い、「原則に基づいたragパイプラインの構築」にしました。つまり、RAGパイプライン内のすべてのコンポーネントを構築し、自分が行う特定の設計上の選択が、実際にアプリケーションのパフォーマンスを向上させていると分かるようにすることです。
それで、こちらが簡単なアウトラインです。まず、問題について簡単に紹介し、なぜそれが重要なのかを説明します。その後、いくつかの、ええと、大規模言語モデル、特にRAGを評価するための評価手法について紹介します。次に、特に何らかの事前定義されたベンチマークデータセットを使用するのではなく、大規模言語モデルを使ってRAGを評価する場合に関連する課題と限界について話します。そして最後に、ええと、いくつかのオープンソース評価フレームワークについて簡単に議論します。
ええと、4つ目の部分に関しては、私はもともとこのウェビナーについて、もう少し大きな範囲を考えていましたが、その後、多くの人にとって新しいトピックなので、基礎をしっかりカバーしてほしいという要望を受けたため、少なくとも2回のウェビナーに分けることにしました。ですので、今回のウェビナーでは、LLMとragを評価する背後にある動機と基本的な考え方に本当に焦点を当てます。そして2回目のウェビナーでは、ragusやsのような評価フレームワークに深く踏み込んでいきます。では、問題を紹介し、なぜそれが重要なのかを議論しましょう。すみません、うちの猫がこちらで少し音を立てています。それで、ええと、私が使うのが好きな動機付けの例は、ええと、semantic searchです。
それで、ここにあるのは、ええと、perplexity ai の検索結果のような画像です。この、この、この新しい、ええと、生成AIベースの、ええと、検索エンジンです。つまりこれは、ええと、もしかすると見てみてもいいかもしれませんし、あるいは、ええと、皆さんがチャットに書き込んでもいいかもしれません。perplexity. ai のようなプロダクトを以前に使ったことがありますか？もしそうなら、例えば、より従来型の、ええと、Google 検索と比べて、どのような印象でしたか？それで、ええと、これは、生成aiのキラーアプリケーションの1つだと言えると思います。そして、ええと、裏側では、ある種の、そうですね。ええと、Ken show さんがここで言っています。GPT よりも高品質で正確な検索結果が得られるので気に入っている、と。
それは間違いなく共感できます。ええと、裏側では、これは何らかの rag、ええと、パイプラインを持っています。ええと、それがこの技術の基盤です。ええと、そして、ええと、ええと、そのために、つまり、その理由で、私たちはできる必要があります。つまり、ええと、このようなシステムを構築しているとき、ええと、どのように最適化するのか、というような問いが生じます。どのように、つまり、裏側のアーキテクチャにどのような変更を加えていけば、時間とともに実際に人々に、ええと、より良い結果を提供できるようになるのでしょうか？だからこそ、これは非常に重要な問いなのだと思います。まず、セマンティック検索は生成aiのキラーアプリケーションのようなものですが、ええと、それは継続的に改善でき、さらにその改善を測定できて、実際に正しい方向に進んでいると分かる場合に限ります。
ええと、ではなぜ、ええと、なぜ、これが Gene W ai のキラーアプリケーションだと思うのでしょうか？それは、セマンティック検索が、いわゆる非構造化データを検索するための非常に効果的な方法だからです。そして非構造化データには、ええと、文書、画像、音声、ええと、位置情報データ、これらすべての種類のデータが含まれます。これらは、例えば、ええと、表形式データのように、すぐに利用可能な特徴表現を持っていないデータです。なので、ええと、はい、そして 20 25 年には、ある推定、ええと、レポートによると、新しく生成されるデータの90%が非構造化データになるとのことです。ですから、この、このセマンティック検索、AI 上の perplexity のようなものは、時間とともにさらに重要になっていくでしょう。ええと、これから RAG を評価する方法と rag システムを改善する方法について話しますが、まずは簡単なおさらいからです。
では、非常に、基本的な rag システムがどのように機能するかを示します。ええと、まず、検索できるようにしたい、そして、関連する、ええと、チャンクをチャットボットに渡せるようにしたい、ええと、文書、画像などの知識ベースから始めます。つまり、ええと、事前に、あるいはオフラインで、その知識ベースを取り、それを embedding ディープニューラルネットワークに通します。するとそれは、ええと、テキストのチャンクのようなもの、ええと、画像全体を、embeddings として知られるこれらの、これらのベクトルに変換します。これは実数の並びのようなものです。そしてそれらの数値は、ある意味で入力の意味やセマンティクスを捉えています。
これらの非構造化の、ええと、データ項目を、より、ええと、機械学習に適したこれらの embeddings に変換したら、それらを Novus のようなベクトルデータベースに入れます。これは特に、ええと、こうした embeddings を大量に保存し、効率的な検索のようなものを実行できるように設計されています。ですから、例えば1億件あるかもしれませんし、perplexity ai 規模だと想像しますが、ええと、数千億あるいは数兆の embeddings があることさえあり得ます。ええと、そのウェブ規模に達したとき、検索を行って、クエリに対して、ええと、その、最も近い一致を見つけられるようにしたいのです。なので、ええと、ええと、それが最初のステップです。検索したいデータを取り、それを embed し、ベクトルデータベースに入れます。そして、ええと、すると、ええと、ユーザーがクエリを持ってやって来ます。
そしてユーザーがチャットボットに質問します。その仕組みは、単に大規模言語モデルが質問に直接答えるというよりも、クエリを深層ニューラルネットワークに通してクエリ埋め込みを取得し、それからベクトルデータベースを検索して、私たちが知識ベースから保存しておいた、クエリに最も近い一致、または最も近い項目を見つけます。そして、ええと、それらを取得して、LLM、ええと、チャットボットに入力されるプロンプトのコンテキストとして追加します。つまりこれは、外部知識を、ええと、チャットボットに追加できる方法です。そして、これは本当に有用だと思います。なぜなら、ええと、知識は変化しており、ええと、LLMを再学習したいと思うよりもはるかに速く、常に変化しているからです。
つまり、LLMは固定したままにして、ええと、ただ、ベクトルデータベースを変化させるだけで、知識の変化に適応するようなことができます。あるいは別の方法として、ベクトルデータベースに自社独自のデータを取り込ませることもできます。ええと、そうすればLLMを訓練する必要はなく、独自データを、ええと、ベクトルデータベースに入れて、それを検索できるようになります。さて。これがRAGの簡単なおさらいで、そこでお見せしたのは非常に基本的なRAGでした。ええと、最近のRAGにはさまざまなコンポーネントがあります。さまざまな種類の機能を実行するステップを組み合わせたモジュール式のシステムのようになっており、ええと、つまり、無限ともいえる数の方法で組み合わせられます。
ええと、ここに、より高度で高性能なRAGシステムを設計するときに決めなければならない、主な設計上の選択肢がいくつかあります。まず、質問が、ええと、そのシステムに入力されます。前の例では、さて、ここに質問があります。ええと、質問への回答については、いつでもチャットに質問を入れていただいて構いません。ええと、進めながら適宜止まって、それらに答えるようにします。
Austinからの質問は、異なる入力タイプを埋め込むことで生成されたベクトルをどのように比較しているのか、というものです。たとえば、ウェブサイトとユーザークエリを埋め込む場合、これらは非常に異なるエンティティです。これらの項目をより比較可能にするために、どのようなアプローチがありますか？ そして、これは素晴らしい質問です。答えは、もし、もし私たちが、ええと、たとえば、ええと、そうですね、では、知識ベースの中に画像とテキスト文書がある、ええと、あるいは知識ベースが画像で、クエリがテキストであると仮定しましょう。すると、異なる、いわゆるモダリティからの入力を比較できるようにするには、同じ空間に整列する埋め込みを生成するよう特別に訓練されたモデルが必要です。これは、ええと、マルチモーダル、ええと、埋め込みモデルと呼ばれます。
そして、ええと、まあ、これは、以前に丸ごと講演したことがあるようなトピックです。しかし、ええと、簡単に言うと、その仕組みは、一致する画像とテキストのペアからなる訓練データセットを用意し、それから、その一致する画像テキストペアに対応する埋め込みが、ええと、埋め込み空間の中で近くなるように訓練を行います。ですので、ええと、質問への答えは、画像やテキストのような複数のモダリティで機能するよう特別に訓練された、特殊な埋め込みモデルが必要だということです。さて。では、ええと、今お話ししているのは、RAGシステムを設計するときに、潜在的に行わなければならないさまざまな設計上の選択肢すべてについてです。
そして、まず最初に出てくるのは、クエリに対してどのような処理を行うべきか、ということです。ここにある赤いボックス、クエリ翻訳を見ると、検索をより効率的にするためにクエリを翻訳したり変換したりする、こうしたさまざまな技術があります。では、ここにあるこの1つ、疑似ドキュメントを見てみましょう。ええと、質問が入力として、いわば脳のようなものに入っていきます。その下には、ええと、hide HYDE と書かれています。つまり、この特定の技術がどのように機能するかというと、クエリを取り、それから大規模言語モデルに、そのクエリに答えるような仮想的な、ええと、ドキュメントチャンクを合成するよう依頼します。
そして、VEC データベースを、ええと、そのクエリで検索する代わりに、その仮想ドキュメントの埋め込みで検索します。そしてそれは、多くの場合ではるかに良い結果を生み出せることが示されています。なぜなら、その仮想ドキュメントのほうがずっと近いからです。オフライン段階で埋め込んだ、ええと、その、ええと、ドキュメントチャンクに対して、ずっと似ているのです。つまり、ほかにも実行できる種類のクエリ翻訳があります。そしてそれを行った後、次の判断は、ええと、ルーティングになるかもしれません。では、データをどこで検索するのでしょうか？常にベクトルデータベースである必要はありませんし、あるいは複数のベクトルデータベースであることもあります。
私たちは判断しなければなりません。クエリを特定のデータソースにどのようにルーティングするのか、それが、ええと、グラフデータベースであれ、リレーショナルデータベースであれ、ええと、ベクトルストアであれ、あるいは複数のベクトルストアのうちの1つであれ、です。そして、システムをそのように設計すれば、クエリが何であるかに応じて、その選択を、ええと、知的に行うことができます。ええと、それから次のステップ、クエリ構築では、実際に、ええと、どのようにクエリを構築するのでしょうか？もし、もし、もしリレーショナルデータベースから検索するのであれば、テキストクエリから SQL クエリへ、ええと、そのリレーショナルデータベースを検索するために、どのように変換するのでしょうか？インデックス化のステップに関しては、ナレッジベースを分割し、埋め込み、そして、ええと、ベクトルストアにインデックス化するためのさまざまな方法があります。私たちのドキュメントの例を取りましょう。それらを段落に分割したいのでしょうか？固定長の、ええと、チャンクに分割したいのでしょうか？何らかの意味情報を使って、その区切りをどのように作るか決めたいのでしょうか？ええと、これはインデックス化において行わなければならない、ごく基本的な判断の1つにすぎません。
その後、つまり、グラフデータベース、リレーショナルデータベース、ベクトルデータベースから関連ドキュメントを取得したら、その結果を処理して、ええと、関連性のようなものを、ええと、改善しようとすることができます。多くの場合、人々は、ええと、再ランキング手順を適用します。そこではドキュメントを取り、関連性の観点からそれらを、ええと、ランク付けできるような何らかのモデルに通します。そして、関連性の低いものをフィルタリングするかもしれません。あるいは、もし複数のソースから結果を得ているなら、ええと、異なるソースからの、ええと、ランキングを組み合わせるための何らかの方法が必要になります。ええと、そして生成段階では、単に答えを生成してそれで終わりにしたいのでしょうか、それとも、ええと、システムが生成品質をある種振り返るような、能動的検索のようなものを持たせたいのでしょうか？そしてそれが、何らかの質問の書き換えにフィードバックされ、ええと、場合によってはドキュメントの再検索につながります。これらが、ええと、より現代的な RAG システムのようなものを作るときに、考慮しなければならない主な設計上の選択肢のようなものです。そして、つまり、問題は、どれを、どのように行うべきか、ということです。私はここにあるこの表を、RAG に関するサーベイ論文から持ってきました。
というわけで、これは、ええと、いくつかの異なるRAG手法の要約で、これはかなり不完全なものです。ですから、RAGパイプラインで行えるあらゆる種類の異なる設計上の選択肢について、どれほど多くの、ええと、技術や研究論文があるかがわかると思います。そして右側には、ええと、とても、ええと、心配そうで、ええと、不安そうな、ええと、デザイナーたちがいて、こう考えています。さて、この、ええと、ええと、この種の、ええと、複雑さをどうやって切り抜けて、実際に完璧なシステムを構築すればよいのか、と。ええと、ですから、ええと、答えはもちろん、こうしたシステムをただランダムに設計すべきではないということです。誰か別の人のベンチマークで、ええと、それが高い性能を出したと聞いたからといって、単にコンポーネントを追加すべきではありません。私たちは、情報に基づいた方法でそれを行う必要があり、その情報に基づいた方法とは実験です。
ですから、私たちは、ええと、よく設計された、あるいは、ええと、合理的な実験を行って、こうした設計上の選択をする必要があります。それがどのように機能するかというと、まず代替案を検討する必要があり、理想的には、一度に変える要因は1つだけにします。つまり、他のすべてを一定に保ったまま、設計の1つの要因を変化させるのです。たとえば、ええと、こう言うかもしれません。よし、非常にナイーブな、つまりこの非常に基本的なRAGシステムと、他はすべて同じだけれど、この仮想的なドキュメント手法を追加したものを比較してみよう、と。つまり、他のすべては同じに保ち、1つだけを変えるわけです。
代替案が得られたら、それは単一の代替案かもしれませんし、一度に検討している複数の代替案かもしれませんが、次に、その、その変更の効果を測定できる必要があります。つまり、何らかの、ええと、良さや性能のような指標が必要で、その変更が有益だったのか、あるいはある面では有益で、おそらく別の面ではそうではなかったのかを言えるようにする必要があります。ええと、そして、ええと、その後は、本質的には、もし、もし私たちがこれら2つのステップを効果的に行う方法を理解できていれば、このプロセスを、ええと、何度も繰り返しながら、追加の設計上の選択を行い、設計の道筋を、ええと、原則に基づいた形で導いていくことができます。ええと、ですから、これはかなりシンプルだと思います。難しいのは、RAGパイプラインに変更を加えた効果を、どのように測定するのかということです。それは何を意味するのでしょうか。つまり、何を測定しているのでしょうか。どのように測定すべきなのでしょうか。ええと、それはそもそも意味があるのでしょうか。ですから、それが、ええと、このウェビナーの残りの部分で、もう少し詳しく話していく内容だと思います。そして、これは本当に、つまりRAGの評価だけでなく、一般に基盤モデルを評価することも、応用生成AIにおいて理解すべき最も重要なトピックの1つだと思います。なぜなら、ええと、原則に基づいたこのような方法論なしに、ええと、最先端のシステムのようなものを設計することは、ただできないからです。
わかりました。では、ええと、このウェビナーの残りで話す内容の範囲について、いくつかメモしておきます。bragの評価は非常に大きなトピックです。ですので、今日は取り上げたいことがいくつかあります。そして、将来のウェビナーに残しておきたいこともあります。
ええと、つまり、このウェビナーの主な焦点は、LLM as a judgeと呼ばれるこの手法の基礎になると思います。これは実際にjudge、つまり大規模言語モデルを使って、大規模言語モデルの性能を評価するもので、それがragシステム内であるか、単体であるかを問いません。したがって、大規模言語モデルの出力、ragの評価を、主にオフライン設定で見ていきますが、これらの考え方はオンライン評価にも適用できます。ええと、それで、LM Evaluation Harnessという1つのフレームワークについて話します。これは本当に使いやすいものです。数行のコマンドラインで、これらの一般的なベンチマーク上で、皆さんのパイプラインや皆さんの大規模言語モデルの評価を始められるようになります。ええと、ragusというような他の非常に一般的なフレームワークについては扱いません。というのも、少し大きなトピックであり、このウェビナーでは入門的な考え方に本当に焦点を当てたいからです。
ですので、フォローアップのウェビナーでは主にragusに焦点を当てるとともに、LM as a judgeに代わるもののようなもののいくつかにも焦点を当てます。したがって今日は、LM as a judgeについて非常に深い議論をするわけではありません。LM as a judgeの論文の研究を土台にして、その手法のいくつかの欠点に対処しようとする他の方法があります。繰り返しますが、それは今後のウェビナーに残しておきます。エージェントの評価を具体的に扱うことはありませんが、これらの手法の多くはエージェントやエージェントのワークフローにも適用可能です。
ええと、マルチモーダルモデルの評価やオンライン設定での評価については話しません。ただし繰り返しますが、これらの考え方の多くはそうした設定にも関連しています。ええと、性能と言うとき、性能はいくつかのことを意味し得ます。ですので、私なら、主なものは大きく2つあると言うと思います。生成出力の観点での性能と、ええと、たとえば、レイテンシ、スループットのような、より時間ベースの指標の観点での性能です。したがって、レイテンシについてはまったく話しません。
それは完全に別のトピックです。ええと、ここでは、回答の品質をどのように評価するかに本当に焦点を当てます。ええと、最近目にした興味深いトピックは、敵対的攻撃という考え方でした。つまり、研究者たちは、入力出力を特定の方法で構成することで、judgeモデルとして使っているLLM、またはベンチマーク指標を欺くことができることを発見しています。つまり、そのようにして、モデルの評価に対して敵対的攻撃のようなものを構成できるわけで、オンライン設定でそれを行っている場合には特に関連性があるかもしれないと思います。
そして、ユーザーからのリアルタイムの入力出力を評価している場合です。ですので繰り返しますが、非常に興味深いトピックであり、今後のウェビナーで話し合う可能性のあるものです。さて、それでは、いくつかの、ええと、基礎または基本的な考え方について話しましょう。大きな問いは、性能、あるいはモデルやシステムの良さとは実際に何を意味するのか、ということだと思います。そしてそれに答えるには、いくつかの区別をする必要があると思います。
では、ここでいくつかの区別を説明します。タスク上でのシステムの性能と、タスクとは独立した、大規模言語モデルそれ自体の性能との間には区別があります。そこで私が意味しているのは、ええと、特定のタスクにおけるシステムの性能について話すことができる、ということです。そこでは、事前に定義された入力出力ペアと、正解応答のようなものがあります。そして、よし、正解が何であるかはわかっている、答えが何らかの形で正解と一致しているかどうか、と言うことができます。しかし、これとはまったく別に、モデルそれ自体を評価することができます。
そこで私たちができることは、入力と出力を取り、その出力が人間の嗜好の何らかの側面に関して入力と整合しているかどうかを見る、ということです。つまり、こうしたものは、たとえば、ええと、私たちには嗜好がある、あるいは、うーん、おそらく単なる常識かもしれませんが、出力は入力に関連しているべきだ、というようなものです。そしてそれは、実際の答えがどうあるべきかとは独立したものです。うーん、これは入力と出力の間の一貫性に関するものです。あるいは、うーん、根拠性、つまり出力が文脈に含まれていた事実だけを参照していて、単に、ええと、でっち上げていないか、ということかもしれません。うーん、ですからこれもまた、正解データとは独立しています。
それは、そのシステムのモデルそのものの品質に関するものです。ですから、そこには非常に異なる2種類の評価があります。うーん、ですので改めて言うと、私が思うに、ええと、繰り返しになりますが、そのタスク評価というのは、非常に、うーん、具体的な、ええと、タスクに関連した指標のようなものです。一方で、これらのモデルそのものを評価する場合は、通常、そのモデルが私たちの期待するような形で人間の嗜好に合致しているか、ということに関連しています。うーん、それで、そして、ええと、これはかなり関連していると思いますが、ええと、比較することができます。ええと、私たちは、この評価を行う際に、答えを既知の正解データと比較しているのか、それとも出力を入力または文脈と比較しているのか、ということです。うーん、RAGに関しては、評価できるパイプラインの部分がいくつかあります。検索部分を評価することができます。つまり、ベクトルデータベース、リレーショナルデータベース、またはグラフデータベースへの呼び出しから返されるものを評価するということです。
そして、LM自体の実際の出力を評価することもあります。ですから、評価できるパイプラインの部分は2つあります。うーん、そしてまた、ええと、完全に相互排他的な次元ではないものがあります。正解データがあるのか、うーん、それとも正解データがないのか、ということです。うーん、もし、もし私たちが、うーん、もし、ええと、正解データを持っていない場合、うーん、人間による評価をゴールドスタンダードと見なすことができます。しかしもちろん、これはうまくスケールしません。人間による評価でラベルをすべて埋めるようなことはできません。
うーん、単純に費用がかかりすぎます。ですから、このプレゼンテーションから持ち帰ってほしい重要なポイントの1つは、ええと、私が、うーん、ええと、このプレゼンテーションから持ち帰ってほしかった重要なポイントの1つは、少し意外かもしれませんが、chat DPT four や、うーん、たとえば Claude の最新バージョンのような強力な大規模言語モデルは、正解データがない場合でも、実際に LM の出力を評価したり判断したりできる、ということです。そしてこれは、ある意味では驚くべきことだと思います。というのも、それは、なんというか、ええと、不正行為やハックのように思えるからです。うーん、なぜモデルがある意味で自分自身を評価できるべきなのでしょうか。うーん、しかし、これらの LLM judge の判断による、うーん、その、うーん、回答は、実際には人間の判定者と同じくらい、あるいはそれ以上に互いに一致する、という経験的証拠があります。うーん、そしてこれは、はるかに小さい、うーん、たとえば70億または80億パラメータのモデルのようなものではなく、すでに人間の嗜好に非常によく整合している強力な LLM を使用している場合に特に重要だと思います。
では、ええと、タスクベースの評価については、いくつかの異なるタイプに分けることができます。知識ベースのものがあります。つまり、質問に対して正しい答えを返すか、というものです。指示追従ベースのものもあります。つまり、モデルが望ましい方法で簡単な指示に従うか、というものです。そして会話型のものがあります。ええと、例えばその一種として、モデルが対話から基本的な読解問題のようなものに正しく答えられるか、というものがあります。ええと、ここには、論文やリーダーボードで通常使われる最も一般的なベンチマークのいくつかを挙げています。ですので、もし、これらのベンチマークの中に実際に何が含まれているのか、例えば質問と回答などがどのようなものなのかを知りたい場合は、Hugging Faceのウェブサイトでそのデータベースのバージョンを実際に探してみるのがよい方法です。
では、こちらに移ります。ええと、例えば、Swagは知識ベースの、ええと、タスクベンチマークです。Hugging Faceのデータセットページで見つけることができます。おそらく多くの異なるバリアントがあるでしょう。人々がデータベースを自分たちの目的に合わせて適応させている、ええと、データセットを自分たちの目的に合わせているからです。ええと、ここでは、activity labelが与えられ、そして、ええと、primary contextのようなものが与えられ、その後、2つの異なるcontext AとBが与えられ、そしてこのendingsがあり、モデルは、ええと、モデルがその文をどのように完成させるかを評価する、という形です。
そして、どれが、ええと、私たちが完成させているものなのかというground truthのlabelのようなものがあります。いいですか？ええと、また別の例として、これを見てみると、ええ、これを見てみましょう、ええと、CoQAまたはCoca、どう発音するかはともかく。これでは、ええと、まず、ええと、sourceがリストされていますが、それは実際にはそれほど重要ではなく、ええと、storyがあります。そしてモデルはこのstoryをcontextとして受け取り、いくつかの質問について、その質問に答えるstory内の特定のテキストのspanを参照しなければなりません。つまり、ええと、この特定の例では、ええと、Vatican Libraryについて話しており、最初の質問は、Vaticanはいつ、ええと、あるいはすみません、VTはいつ正式に開設されたか？というものです。ええと、そのため、答えがそのテキスト文字列のどこから始まり、どこで終わるのか、そしてそれが何なのか、というground truthがあります。
つまり、答えがどうあるべきかというground truthがあります。ええと、それは、ええと、storyのサブセットのようなものを参照する形です。つまり、これはある意味で、ええと、理解力をテストしているようなものです。ええと、はい、つまり、これらは非常に一般的なタスクベース評価の一部です。これらのタスクベース評価についての1つの点は、それらはしばしば人間の好みを十分に捉えないということです。つまり、人間の好みとの整合性のいくつかの側面を捉えられません。ですので、より内省的な、補完的な評価指標を別途検討したいのです。
そして、ここにその例がいくつかあります。あなたのRAGシステムやあなたのLMの生成を評価するものがあります。その一側面として、先ほど述べたように、faithfulness、ええと、faithfulnessまたはgroundednessという概念があります。出力は、contextで与えられた情報と事実的に一貫しているか？contextから推論できない追加の主張をしているか？ええと、もしそうなら、それは、回答は質問に関連しているべきだという人間の好みと整合していないことを示します。ええと、はい、answer relevancy。
同様に、たとえば、その応答は実際に関連性があるのか？つまり、ええと、それがコンテキストに基づいているかどうかではなく、その答えは実際に質問に関連しているのか？単に、話が、脱線してしまっているだけなのか？私たちは、rag パイプラインの検索ベースの部分についても、いくつか同様のメトリクスを構築できます。なので再び、ええと、つまり、私たちのベクトルデータベース、または、ええと、グラフデータベースなどから取得されたチャンクは、実際に、その、尋ねられている質問に関連しているのか？ええと、別に、つまり、ええと、もし正解データがあるなら、ええと、私たちは、検索ベースの、ええと、検索メトリクスを使って、私たちの、その、ベクトルデータベースからの、ええと、検索結果を、その、その、その既知の正解データに関連づけてスコアリングできます。ええと、ただし最初の3つについては、これは、これらは、実際に別の大規模言語モデルを審査員として使って、その、入力出力を、または、これらのメトリクスをスコアリングできるものです。なので無料です。ええと、その仕組みは、別の審査員LLMを用意し、そして、ええと、メトリクスの計算方法についての指示を与えるようなプロンプトを作成します。
そのプロンプトは、ええと、0から1のスコアを与えてください、このコンテキストは、ええと、a、ええと、ええと、コンテキスト、ええと、bには存在しない事実を含んでいますか、というものかもしれません。なので、ええと、ここで私たちは、正解データは持っていないけれども、大規模言語モデルを使って、これらの、これらの内省的タイプのメトリクスを計算し、そうすることで、こうした、ええと、よりタスクベースの、ええと、評価では捉えられない、人間の選好との整合性の別の側面のようなものを捉えることができます。はい。ではごく簡単に、いくつかの課題と限界について。ええと、ええと、私が最初にこれを、ええと、見たとき、私は、これはあり得ない、と思いました。
大規模言語モデルがどうやって別の大規模言語モデルを審査できるのか？ええと、それはとても、ある意味で循環的な、ええと、議論のように思えます。なので、ええと、でも、そうですね、その後、LM as a judge の論文で実証結果を見て、なるほど、これはうまくいくようだ、と思いました。ただもちろん、いくつか注意点があり、研究者たちが当初見つけた特定の限界もいくつかあります。なので、それらのいくつかを簡単に触れてから、ええと、それらの一部を、ええと、改善できる簡単な方法のようなものについて話します。最初のものは位置バイアスと呼ばれるものです。つまり、私たちのLLM審査員の結果は、時には、あるいはおそらくしばしば、提示する、ええと、情報の正確な順序によって異なることがあります。
なので、ええと、この特定の、ええと、質問では、その、その審査員は、どちらの回答を好むかを言うよう求められています。アシスタントAを好むのか、それともアシスタントBを好むのか？それは、日本における、ええと、ビジネス上の適切な規範についての質問に対して、より良い回答なのか？そして、ええと、なので、ええと、ええと、GPT-4は、アシスタントaの情報をコンテキストの先に置くか、アシスタントbの情報をコンテキストの先に置くかによって、異なる答えを出します。そしてこれは明らかに、ええと、起きるべきではありません。なぜなら、質問は同じなのだから、それは無関係であるべきだからです。それは単に、コンテキスト内の情報の順序のようなものです。なので、ある意味では、何というか、大規模言語モデルにおける人間の選好の審査員に対する人間の選好のようなものがあるのだと思います。もう一つ、ええと、真実性バイアスと呼ばれるものがあります。
ええと、コンテキストを一つ取って、その情報の一部を複製するだけでもよいです。すると、GPT-3 0. 5とClaudeでは、それが、ええと、応答を変えます。ただし、この場合GPT-4ではそうではありません。ええと、質問によっては、もし、ええと、もし、ええと、LLM審査員にその質問に答えるよう求めると、その質問に正しく答えることができます。たとえば、数学の問題のようなものです。
しかし、もしそれに2つの回答を判断するように頼んだり、あるいは、ええと、別のモデルからの回答を判断するように頼んだりすると、その回答の中の、ええと、誤った推論のようなものに、ある種ミスリードされてしまいます。ですからこれは、これは正しくないように思えます。つまり、もし、もしモデルが、もし、すみません、もしジャッジがその質問に答えられるなら、他のモデルの回答を判断できるはずです。それからもう一つ。ごく簡単に言うと、ええと、もう一つの失敗モードがあって、もし私たちが思考の連鎖タイプの、ええと、推論のようなものを含めるとします。すると、ええと、それら、それら、その、ええと、ジャッジの正確な結果は、ええと、ある意味で、ええと、その不正解を与えるように影響を受けることがあり、ある種、ええと、独立して考える、という感じにはならないのです。
ええと、それで、ええと、彼らはいくつかの、いくつかの方法を提案していて、ジャッジの、ええと、品質を改善しようとし、ええと、これらのバイアスの一部を修正しようとしています。ええと、私は、つまり、ええと、それ以来、あるいは、ええと、彼らがその論文である程度ほのめかしていることの一つは、ファインチューニングされたジャッジモデルを見る価値があるかもしれないということです。つまり、ええと、ジャッジモデルとは、特にジャッジになるように、そしてこれらのバイアスや、ジャッジが犯し得る他の、ええと、誤りを避けるようにファインチューニングされたモデルです。そして、そういうわけで、その、その論文が発表されて以来、ええと、ええと、企業や研究者たちは、ええと、ええと、クローズドソースとオープンソースの両方で、ジャッジモデルを公開してきました。そしてここに最近のオープンソースのものをいくつか、いくつか挙げているので、確認してみてください。
そして、ある種の、ええと、教訓は、あなたは、あなたは常に、その目的のためにファインチューニングされた、ええと、LLMジャッジを使うべきだ、ということだと思います。あるいは、特定の目的ごとに別のものを使うかもしれません。たとえば、あるものはグラウンデッドネス用にファインチューニングされ、別のものは関連性用にファインチューニングされる、などです。ええと、では最後に、ある種の重要なメッセージで締めくくりたいと思います。ええと、評価において本当に重要な部分は、あなたの、ええと、評価のデータ品質だと思います。そして、ええと、それがタスクベースの評価にどう関係するかというと、そのベンチマーク内の、ええと、特定のデータが、あなたがアプリケーションで行おうとしているタスクとどれだけ密接に一致しているか、ということです。もしそうでなければ、あなたは、あなたの、ええと、その、あなたが行っている特定タスクのパフォーマンスのいくつかの、いくつかの側面を捉えるために、独自の、ええと、カスタムデータセットを構築する必要があるかもしれません。そして次に、ええと、これらの、ええと、ジャッジモデルをトレーニングするための、ええと、ええと、ええと、データ品質です。
つまり、私たちのジャッジモデルをファインチューニングできるように、そしてジャッジモデルがどのように動作すべきかについて人間の選好と整合するように、適切なデータセットのようなものを構築できるか、ということです。時間がなくなったようなので、質問に移りたいと思います。ええと、ええと、私はごく簡単に、いくつかの、いくつかのオープンソースフレームワークについて話すつもりでしたが、それは今後のウェビナーに残しておき、そのウェビナーの主な焦点にします。そこで、LM evaluation harness、ええと、ragus、RAGを特に評価するために最も広く使われている、ええと、フレームワークについて話し、ええと、いくつかの代替案についても簡単に話し、ragusと比較します。そして、VUSオープンソースベクトルデータベースを、その、ええと、この上で実演する、ええと、その、その、RAシステム用のベクトルデータベースとして使います。ですから、この、この今後のウェビナーでは、実際にシンプルなragシステムを構築し、設計上の選択を行い、それを評価し、そして、検証可能な改善を行った方向へあなたの、あなたのシステムを進める方法を、最初から最後までお見せします。
わかりました。では、ええと、時間の都合上、質問に、ええと、移るべきだと思います。はい、チャットにいくつか質問があります。ああ、Q&Aツールの中ですね。では、ここで最初のものを読み上げます。ええと、より伝統的なMLでは、モデルをトレーニングするためのハイパーパラメータの最適なセットを見つけるためにグリッドサーチを使います。
ragには、モデルクエリ、構築クエリ変換など、非常に多くの異なる設定項目がありますが、グリッドサーチを実行できるフレームワークはありますか？ええ、はい、とても良い質問です。そうですね、ええと、私の知る限りでは、ありません。ええと、ragシステム向けのハイパーパラメータ探索用に特化して設計されているわけではない既存のフレームワークのようなものを、ある程度使うことはできると思いますが、ragシステムに適応させることはできます。ですので、既存のライブラリをいくつか組み合わせる方法は十分に考えられます。それがグリッドサーチであれ、Ian最適化であれ、そこにrag固有のメトリクスのようなものを差し込めば、その空間を探索することになります。ええ、たぶん一つ言及しておくべきことは、これらのメトリクスのいくつかを評価するのはかなり高コストだということです。
ですので、それによって、探索できる空間の幅が正確には制限されるかもしれません。ですので、私のアドバイスとしては、パイプラインのこれら各部分を独立して考えることです。つまり、それらが互いに相互作用しないという仮定を置く、ということです。それが本当かどうかは別として。そして、たとえば学習率に対する従来型のグリッドサーチのようなことをする代わりに、何が重要で何が重要でないのかについて、より大きな感覚を得るために、ごく少数の代替案を検討してください。わかりました、ありがとうございます。
それから、受け取ったもう一つの質問は、ragパイプラインを構築し始めるときに、既存のオープンソースのコードベースを出発点として使えますか？また、始めるのに良いコードベースについて教えてもらえますか？ええと、それらにはすでに、もしかするとデータの前処理やモデル評価のためのスクリプトがあるかもしれません。ええ、もちろんです。そうですね、ここで私が言いたいのは、lane chainのようなオープンソースライブラリのようなフレームワークを使う、ということです。それは、コンポーネントを一つ一つ自分で構築しようとする場合よりも、少し高レベル、つまりより高い抽象度のものです。ですので、より高い抽象レベルから作業できます。そして、それらにはサンプルコードがあり、ライブラリを使ってさまざまなタイプのragパイプラインをどのように構築するかを示してくれます。
それとは別に、ragusはL chainとの統合が良好で、ragusをlang chainと一緒に使うことに特化した例があります。ですので、そこから始めるとよいと思います。つまり、L chainのようなライブラリを使い、ARAシステムの出発点として彼らのウェブサイト上のリソースを使い、それから評価の出発点としてragusのウェブサイト上のリソースを使う、ということです。ありがとうございます。それから、MLやデータサイエンスの経験がないソフトウェアエンジニアにとって、bagパイプラインを構築しようとしているチームに役立つ方法にはどのようなものがありますか？ええ、もちろんです。
ですので、そうですね、ここで重要なポイントは、良いパイプラインを構築するのに、必ずしもMLの知識は必要ないということかもしれません。ただし必要なのは、実験のマインドセット、または研究のマインドセットです。そしてそれは、私たちが行う各変更の影響を測定する必要がある、という考え方です。ですので、原則に基づいた方法で行う必要があります。これらのステップの背後で何が起きているのか、その仕組みのすべてを必ずしも理解する必要はありません。
ですが、自分たちが行っている選択が実際に何であるかを理解していて、それらが非常に明示的であり、測定できるのであれば、それが必要なものです。ですので、そうですね、機械学習の側面にはあまり焦点を当てず、むしろ実験、つまり研究マインドセットの側面にもっと焦点を当てるとよいと思います。そして、多くのソフトウェアエンジニアは、たとえばソーシャルメディアアプリやその他のオンラインアプリのようなものを開発している場合、ABテストから何らかの良い経験を持っていることを期待しています。ですので、非常に似た原則です。わかりました。
ええと、それから、私たちが興味を持っていたRAGASについて、RAGASを始めるためのリソースをいくつかチャットに入れました。それから、RAGASとVISの統合についても少し。そして、これを避けるためにもう一つ質問があります。評価を新しい会話またはプロンプトとして行うと、プロンプトの順序によるバイアスは取り除けますか？あ、すみません。ええと、最初の部分がよく聞き取れませんでした。もう一度読んでいただけますか？彼らは、これを避けるために、評価を新しい会話またはプロンプトとして行うと、プロンプトの順序によるバイアスを取り除けますか、と言っています。これは、あなたのスライドの一つにあった位置バイアスに関するものです。
はい。わかりました。そうですね、位置バイアスを避けるために、評価を新しい会話またはプロンプトとして行うと、バイアスを取り除けるか、ということですね。ええと、そうですね、この位置バイアスは、以前のチャット履歴のようなものというよりは、メトリックを計算するための、最初のステップのようなもの、つまりこれは単一ステップのチャット対話のようなものですが、そのために含める必要があるコンテキストに関するものです。ですので、そのバイアス、位置バイアスを取り除く方法の一つとしては、実際に両方の選択肢を試すことができます。
つまり、こう言えます。よし、judgeモデルにコンテキストAを先に与えて質問してみよう。そして別に、同じモデルにコンテキストBを先に置いて質問してみよう、と。そしてその二つが一致すれば、ではこの場合は位置バイアスはなく、判断に自信が持てる、と言えます。そうでない場合、つまり実際に異なる回答が返ってくる場合には、さまざまな戦略があります。たとえば別のモデルに委任したいかもしれません。ただ、最も効果的な方法は、特にjudgeとしてファインチューニングされた、こうしたjudgeを使うことだと思います。
いいですね。ありがとうございます、Stephan。あと一つ質問する時間があります。どなたか最後に質問があれば、彼が話した内容について急ぎの質問があれば、Q&Aツールまたはチャットに入れてください。なければ、1分だけ待ちます。入力中の方がいれば、どうぞ。これでStephenのプレゼンテーションはほぼ終了となります。
あ、わかりました。質問が一つあります。もしかするとその情報を聞き逃したかもしれません。コンテキストのrecallとコンテキストのrelevancyを測定する方法はありますか？ええ、もちろんです。ええと、それはground truthがあるかどうかによります。recallについては、はい、ground truthが必要だと思います。relevancyについては、ground truthがある場合もあります。
たとえば、人間のアノテーターにやってもらっているかもしれません。ただ、もしない場合は、そこでLMをjudgeとして使ってrelevancyをスコアリングします。ですので、こう言うことになります。あ、ちょっと待ってください。すみません、もう一度質問を読んでいます。コンテキストのrecallとコンテキストのrelevancyを測定する方法はありますか。
あ、わかりました。つまり、この質問は、LMからの出力のrelevancyではなく、データベースから取得された情報のrelevancyについて尋ねているのだと思います。ええ、これもやはりLMをjudgeとして使って、このrelevancyをスコアリングできるものです。たとえば、1から10のスコアで、VICデータベースから取得されたコンテキスト、つまりこれらの取得されたチャンクが、尋ねられている質問にどのくらい関連しているか、というプロンプトを組み立てることができます。誰かが、会社Zillowは主に何をしていますか、と質問しました。そしてここで簡単な回答をしました。
私たちはオープンソースのベクトルデータベースです。オープンソースのベクトルデータベース製品としてvissがあります。また、エンタープライズ向けのベクトルデータベースであるZillow cloudもあります。そしてそれは主にスケーラビリティのために構築されています。ベクトルデータベースに入力するデータがどんどん増える場合、Zillow's cloudがそれを支援します。
ですので、さらにご質問があれば、あなたの具体的なユースケースに対して私たちが何をできるかについて、ぜひお気軽にご連絡ください。はい、まったくその通りです。ありがとうございます、Achi。もう一つ付け加えると、私たちはVISをLinux FoundationのAIおよびデータサイエンス向けに寄贈しました。
ええと、とはいえ、私たちは今でも、その、主要な貢献者です。つまり完全なオープンソースには商用利用ライセンスがありますが、もし、もしホスティングを自分で扱いたくない場合は、そこで私たちの商用提供であるクラウドの出番になります。これはMelと同じ技術を基盤に構築されています。はい、時間になりましたが、本日はご参加いただいた皆さん、本当にありがとうございました。ええと、スライドと録画はどちらも、ウェビナーの後ほどまもなくメールで共有されますし、録画はYouTubeにもアップして、皆さんにもご覧いただけるようにします。
楽しんでいただけたなら幸いです。また次回のウェビナーでお会いしましょう。皆さん、ありがとうございました。さようなら。はい、ご参加いただいた皆さん、ありがとうございました。次回お会いできることを楽しみにしています。
はい、さようなら。
Meet the Speaker
Join the session for live Q&A with the speaker
Stefan Webb
Developer Advocate, Zilliz
Stefan Webb is a Developer Advocate at Zilliz, where he advocates for the open-source vector database, Milvus. Prior to this, he spent three years in industry as an Applied ML Researcher at Twitter and Meta, collaborating with product teams to tackle their most complex challenges. Stefan holds a PhD from the University of Oxford and has published papers at prestigious machine learning conferences such as NeurIPS, ICLR, and ICML. He is passionate about generative AI and is eager to leverage his deep technical expertise to contribute to the open-source community.