これは、オフィススペースのウォータークーラーの周りでよく見られる特別なタイプの世間話です。そこでは、従業員が社内のあらゆる種類のゴシップ、神話、伝説、不正確な科学的意見、軽率な個人的な逸話、またはあからさまな嘘を共有することがよくあります。何でもありです。私の Water Cooler Small Talk の投稿では、私や私の友人、知人が私のオフィスで聞いた、文字通り言葉を失った、奇妙で通常は科学的に無効な意見について議論しています。
さて、今日の投稿に対するウォータークーラーの意見は次のとおりです。
私たちは非常にうまくいっている RAG アプリを構築しました。現在は評価段階にあり、すべてのテストを通じて問題を特定し修正し続けているため、非常に順調に進んでいます。すでにスコアは 97% に達しています。
さて、少し立ち止まって、この発言の何が間違っているのか考えてほしいのです。 🤔表面的には完全に理にかなっているからです。問題を見つけて修正することは、まさに優れた評価プロセスが行うべきことのように思えますよね。責任もある。それで、実際に何が起こっているのでしょうか？
ここでの問題は微妙ですが根本的なものです。評価プロセスを使用して問題を特定し、それらの問題を修正し、同じ一連のテストで再評価している場合、残念ながら、実際には評価を行っていないことになります。評価セットには、これを非常に便利にする重要なプロパティが 1 つあります。それは、モデルがこれまで見たことがないものです。その結果に基づいて修正を行い、同じセットで再評価するたびに、その資産が少しずつ奪われていきます。言い換えれば、評価セットはひそかに開発プロセスの一部となり、現在ではトレーニング セットのようなものになっています。
しかし、正しく行うことは言うは易く行うは難しです。実際には、評価プロセスを適切に実行するのは非常に骨の折れる作業です。特に、RAG アプリの継続的な評価について話す場合、つまり評価セットが履歴データセットではなく質問と回答のペアのセットであることを意味し、それを正しく行うことは非常に面倒で時間がかかる可能性があります。それにもかかわらず、評価を適切に実行できないと、非常によく知られた ML の問題が発生します。 過学習。
過剰適合についてはどうですか?
一歩下がって、ML の基本を少し見てみましょう。
機械学習では、通常は次のように分割されるデータを使用してモデルが構築されます。 トレーニングセットあ 検証セットそして テストセット。より具体的には、モデルはまずトレーニング セットに適合されます。トレーニング セットは、使用する必要があるモデルのタイプを示し、それに応じてモデルのパラメーターを調整するために使用されるデータです。最も単純な形式では、トレーニング セットは x と y のデータのペアで構成され、私たちの目標は、利用可能な x と y データに最もよく適合する ay = f(x) モデルを考え出すことです。
これが完了すると、トレーニングされたモデルを使用して検証セットの結果が予測されます。具体的には、検証セット内の各 x について、選択したモデルに基づいて推定 y = f(x) を生成し、それが検証セットの実際の y とどのように比較されるかを確認し、それに応じてモデルを調整します。
最後に、検証フェーズに基づいて最終的にどのモデルを進めるかを決定した後、それをテスト セットでも実行します。テスト セットの目的は、これまでに見たことのないデータに対するスコアを計算することで、最終モデルがどの程度一般化されるかを確認することです。このため、テスト セットは 1 回のみ使用する必要があります。
私たちがこのようなことを行うのは、私たちの目標がトレーニング セットに適合させることではなく、トレーニング セットが何を表しているかを理解することであるためです。このようにして、基礎となるパターンを十分に学習して、新しい未知のデータ (テスト セット) を正確に予測できるモデルを作成できます。
残念ながら、これができない場合があり、一般的なケースに適合するモデルを構築する代わりに、一般化せずに狭いトレーニング セットのみに適合するモデルを構築してしまいます。これを私たちはそう呼んでいます 過学習。その結果、モデルはトレーニング セットでは非常に優れたパフォーマンスを発揮し、印象的なスコアを達成しましたが、新しいものではパフォーマンスが低下しました。
ここでのコツは、テスト セットが意味を持つのは、モデルがこれまでに実際に見たことがない場合のみであるということです。モデルについての意思決定にそれを使用した瞬間、たとえそれが一見些細なモデルであっても、それは侵害され、本質的にトレーニング セットとマージされたことになります。
しかし、ML の基本に関するこの少しの更新の後、元のウォーター クーラーの意見に戻りましょう。
RAG 評価におけるオーバーフィッティング
これは、AI アプリケーションを構築して評価する私たちにとって特に重要となる点です。
RAG パイプラインの評価に関する私のシリーズでは、Precision@k、Recall@k、MRR、NDCG@k などの回復メトリクスについて多くのことを話しました。それでも、これらすべての派手なメトリクスは、それらを適用する評価セットと同じくらい役に立ちます。 RAG における評価セットとテスト セットの間の境界線は、驚くほど簡単に曖昧になることがわかりました。この原因の一部は、単純な回帰モデルとは異なり、AI モデルと RAG パイプラインが私たちにとって直感的とは程遠いという事実にあると思います。モデルが実際にデータにどのように適合しているかについては、私たちにはほとんど直感がありません。その結果、調子に乗って、テスト セットに基づいてシステムを調整していることに気づかずに調整してしまう可能性があります。
それがまさに私たちの Water Cooler Story チームが取り組んでいることです。評価中に問題を特定し、修正し、同じ質問と回答のペアで再評価します。当然のことながら、基本的に AI アプリをテスト セットに適合させているため、反復ごとに評価スコアが向上します。
具体的には、RAG でこれが発生する最も一般的な方法を次に示します。
- 評価セットの信号を調整します。 これはおそらく最も一般的なパターンであり、ウォーター クーラーの話でまさにそれが起こりました。評価を実行し、特定の質問タイプが一貫して失敗することに気づき、システム プロンプトまたは回復ロジックを調整して問題を修正します。次に、同じセットで再評価します。もちろん、スコアは向上します。驚くべき 100% スコアを達成することさえできるかもしれません。
- システムはすでに優秀なクエリを適切に処理しています。 同じ問題のより微妙なバージョン。評価セットを作成するときは、システムが良好に動作することがすでにわかっている例、特に途中で非公式にテストした例を含めたくなる傾向があります。時間の経過とともに、評価セットはシステムの強みに近づき、盲点から遠ざかっていきます。指標は素晴らしく見えますが、実際には、実際のパフォーマンスがどのようなものであるかは誰にもわかりません。
- インデックスを作成したのと同じドキュメントからテスト問題を作成します。 評価セット内の質問が、ナレッジ ベースにすでに存在するドキュメントを詳しく調べて作成されている場合、検索可能なことが既にわかっている内容によって暗黙的に形成されている可能性が高くなります。言い換えれば、質問は実際にはデータから独立したものではありませんでしたが、繰り返しになりますが、単に x と y の数値ではなく自然言語で質問と回答について話しているため、これを理解するのは特に困難です。
これらすべてのケースに対するシンプルだが困難な解決策は、古典的な機械学習ソリューションと同じです。つまり、現実的に実施されたテスト セットはできるだけ触らないようにし、システムの既知の動作とは独立してクエリを作成し、優れたメトリクスを懐疑的に扱います。小規模で慎重に準備され、頻繁に再利用される評価セットで見事に機能する RAG システムは、過去の試験問題を暗記したものの、見たことのない実際の最初の問題に対してまったく準備ができていない学生に似ています。
独自の RAG 評価設定を慎重に検討したい場合は、検討し、正直に自問する価値のある質問の短いリストを以下に示します。
- 評価セットを作成したとき、ナレッジ ベース内のドキュメントから独立して質問を作成しましたか? それとも最初にドキュメントを見て、すでに答えられることがわかっている質問を作成しましたか?
- アプリが繰り返し失敗するために、評価セットから質問を削除または変更したことがありますか?
- これまでにテストしたことのないクエリ、または再利用し続けている同じ固定セットのみでシステムがどのように実行されるかを大まかに知っていますか?
- 私の評価セットの中に、しばらくの間手付かずに無視されている部分はありますか?
最後の答えに答えなかったとしても、あなたはすでに今日のウォータークーラーの話のチームに加わっているかもしれません。 😉
実生活における過剰適合: グッドハートの法則
グッドハートの法則とは、1975 年に経済学者のチャールズ・グッドハートが提唱した、次のような格言です。
測定が目標になると、それはもはや良い測定ではなくなります。
このアイデアはもともと金融政策から生まれましたが、その一般化は経済学をはるかに超えており、KPI、予算、あらゆる種類の数値など、パフォーマンスを判断するために数値が使用されるほとんどすべての場所で使用されます。自動車セールスマンが毎月販売した車の数に応じて報酬を受け取り、その後、赤字でもさらに多くの車を売り始めると想像してください。病院は患者の入院期間を短縮しようとしているが、患者を早期に退院させすぎている。科学出版物に関しては、引用数などが影響します。
これらの例はすべて、まったく同じ基礎メカニズムで機能します。つまり、重要なことを追跡するために定量的な測定が導入されています。しばらくの間、測定と本物は密接に関係してきましたが、今では本物の進化を追跡するために測定の発展に頼ることができるようになりました。その後、人々 (またはシステム) は、本質的に重要なことではなく、測定に直接最適化を開始し、この 2 つは静かに乖離していきます。その後、同じように改善を表すことを目的とした根本的な重要なものが存在しないまま、尺度は改善し始めます。
特に AI では、この失敗モードは報酬ハッキングと呼ばれます。これは、AI システムが実際に望ましい結果に到達せずに、不適切に指定された報酬を最適化したときに発生します。同様に、古典的な ML では、トレーニング信号が真の基礎となるパターンを表現しなくなったときに、モデルで過学習が発生します。グッドハートの法則は、評価信号が本当に関心のあるものを表さなくなったときに、システムを設計する人間に起こります。
私の心の中で
特に RAG アプリケーションにおけるオーバーフィッティングに関して私が最も興味深いと思うのは、それが実際には技術的な問題ではないということです。それは主に、プロセスを理解し、それに従うかどうかの問題です。特に、従来の ML で使用するデータセットに似ていない RAG データセットの場合は、そのプロセスを無視してスコアを直接最適化する誘惑にかられます。
それでも、このパターンは機械学習や AI をはるかに超えたものに見えます。実生活でも機械学習でも、解毒剤は同じです。粘り強く、達成しようとしている本当のことを見失わないことです。 ML と AI では、評価中に高い評価を得ることだけでなく、モデルが運用環境に入り、現実世界のデータに直面したときに実際に機能し、意味のある結果を生み出すことが重要です。
ウォータークーラーの話に出てくるチームは何も悪意のあることをしているわけではありません。むしろ、彼らがやっているのは、評価結果に基づいて責任を持ってアプリを修正することのようです。そして、これが過剰適合を非常に危険にする理由です。それにもかかわらず、それは間違いではないようです。システムが現実世界と出会い、スコアの再生が停止すると、同じように見えるだけです。
読んでいただきありがとうございます！ ▪️
ここまで進んだなら、 ピアゴリズムが役に立つかもしれません – 私たちは、チームが組織の知識を 1 か所で安全に管理できるようにするプラットフォームを構築しています。
この投稿は気に入りましたか?参加してください 💌サブスタック そして💼リンクトイン
特に明記されていない限り、すべての画像は作者によるものです
Leave a Reply