Redisの新しい研究によると、より高い精度のためにRAG埋め込みモデルを微調整するエンタープライズチームは、意図せずに、そのパイプラインが依存している検索品質を低下させてしまう可能性があります。
論文「Training for Compositional Sensitivity Reduces Dense Retrieval Generalization」では、チームが合成的な感度（compositional sensitivity）のために埋め込みモデルを学習すると何が起きるかを検証しました。つまり、「ほぼ同じ見た目だが意味が異なる」文を見抜ける能力です——例えば「the dog bit the man（犬が男を噛んだ）」と「the man bit the dog（男が犬を噛んだ）」、あるいは否定の反転によって文の意味がまるごと逆転してしまうケースです。こうした学習は一貫して、密（dense）検索の汎化（generalization）を壊していました。汎化とは、モデルが特に学習していなかった幅広いトピックや領域に対して、どれだけ正しく情報を取得できるかを指します。性能低下は、小型モデルでは8〜9％、そしてチームがプロダクションで実際に使っている現在のミドルサイズの埋め込みモデルでは40％でした。
この結果は、エンタープライズのエージェント型AIパイプラインを構築するチームにとって、直接的な意味を持ちます。そこでは、検索品質が、エージェントの推論チェーンに流れ込むコンテキストを決定するからです。単一ステージのパイプラインで検索ミスが起きると、誤った答えが返ります。エージェント型パイプラインで同じ種類の誤りが起きると、その後段で誤った一連の行動がカスケード的に引き起こされることがあります。
RedisのAIリサーチリーダーであり、論文の著者の一人であるSrijith Rajamohanは、この発見が、埋め込みベースの検索が実際にどのように機能するのかに関する広く普及した前提に挑戦するものだと述べました。
「セマンティック検索やそれに類するセマンティック類似性を使うと、正しい意図が得られるはずだ、という一般的な考えがあります。でもそれは必ずしも正しくありません」とRajamohanはVentureBeat.に語りました。「近い、あるいは高いセマンティック類似性が、必ずしも正確な意図を意味するわけではありません。」
検索のトレードオフを生む幾何（ジオメトリ）
埋め込みモデルは、文全体を高次元空間の1点に圧縮し、検索時にクエリに最も近い点を見つけることで動作します。これは、幅広い話題のマッチングにはうまく機能します——似た主題に関する文書は互いに近い場所に集まります。問題は、単語がほぼ同じでも意味が逆になっている2つの文も、構造ではなく単語内容に基づいてモデルが動いてしまうため、同じように近い場所に現れてしまうことです。
研究が定量化したのはまさにそこです。チームが埋め込みモデルを微調整して、構造的に異なる文どうしを引き離す——つまり、文の意味を反転させる否定の反転（negation flip）は元のものとは同じではないのだ、と教える——ようにすると、モデルはそれまで幅広い話題の想起（topical recall）のために使っていた表現空間を使います。2つの目的は同じベクトルを奪い合います。
研究では、回帰（性能低下）が失敗タイプごとに一様ではないことも分かりました。否定（negation）や空間的な反転（spatial flip）の誤りは、構造化された学習によって目に見える改善が見られました。一方で、バインディングの誤り（binding errors）——例えば契約上の義務がどの当事者に課されるかのように、どの修飾語がどの単語に適用されるのかをモデルが取り違えるケース——はほとんど動きませんでした。エンタープライズのチームにとっては、精度の問題は「間違えると最も重大な結果になるまさにそのケース」で直しにくい、ということを意味します。
多くのチームがそれに気づけない理由は、微調整の指標が、学習しているタスクは測る一方で、無関係なトピックに対する一般的な検索で何が起きるかは測らないからです。学習中にはニアミスの拒否（near-miss rejection）で大きく改善したように見えても、静かに「雇われて担当させられた」より広い検索の仕事が悪化していることがあります。こうした回帰は、本番環境でしか表面化しません。
Rajamohanは、多くのチームが抱く直感——より大きな埋め込みモデルへ移行すること——は根本的なアーキテクチャの問題には対処しない、と述べました。
「これをスケールで解決することはできません」と彼は言いました。「追加の次元数や追加のパラメータで解決できるタイプの問題ではありません。」
標準的な代替案がすべて不十分な理由
検索の精度が失敗する自然な反応は、追加の手法を重ねることです。研究ではそれらをいくつか検証し、それぞれが異なる形で失敗することを見いだしました。
ハイブリッド検索。 埋め込みベースの検索とキーワード検索を組み合わせることは、精度のギャップを埋めるための標準的な実践になっています。ですがRajamohanは、この研究が特定した失敗モードはキーワード検索では捉えられないと述べました。問題は単語が欠けていることではなく、構造を読み誤っているからです。
「『Rome is closer than Paris』という文と、『Paris is closer than Rome』という別の文があり、埋め込み検索の後にテキスト検索を行うなら、その違いを見分けられないでしょう」と彼は言いました。「どちらの文にも同じ単語が存在します。」
MaxSimのリランキング。一部のチームは、単一の圧縮ベクトルに頼らず、個々のクエリ語を個々の文書語と比較することで、2段階目のスコア付け層を追加します。このアプローチはMaxSim、またはレイト・インタラクション（late interaction）として知られており、ColBERTのようなシステムで使われています。研究でも、関連性のベンチマーク指標の改善は見られました。ですが、それは構造的なニアミスを完全に拒否できませんでした。ニアミスに対して、ほぼ同一の類似度スコアを付与してしまったのです。
問題は、関連性（relevance）と同一性（identity）が別の目的だということです。MaxSimは前者のために最適化されており、後者には盲目です。MaxSimを追加してベンチマークが改善しているのを見れば、チームは自分たちが解こうとしている問題とは別の問題を解いてしまっている可能性があります。
クロスエンコーダ。 これらは、クエリと候補文書をモデルに同時に入力し、判断を下す前に「すべての単語対すべての単語」の比較を行わせることで機能します。この完全な比較が精度を高める一方で、プロダクション規模で回すにはコストが高すぎる原因にもなります。Rajamohanは、自分たちのチームがこれを調査したが、実際のクエリ量の下では研究室では動くものの壊れてしまう、と述べました。
文脈（コンテキスト）付きメモリ。 また「エージェント型メモリ（agentic memory）」とも呼ばれるこれらのシステムは、RAGの先へ進む道としてますます引用されるようになっていますが、Rajamohanは、その種のアーキテクチャへ移行しても構造的な検索問題は解消されない、と述べました。そうしたシステムでも、クエリ時の検索に依存しているため、同じ失敗モードが適用されます。主な違いは、レイテンシ要件がより緩いことではあっても、精度の修正ではありません。
研究が検証した2段階の修正
失敗したあらゆるアプローチに共通する糸は、同じです。つまり、想起（recall）と精度（precision）の両方を一度に扱おうとする単一のスコアリング機構が問題なのです。研究では別のアーキテクチャが検証されました——1つのベクトルで両方をやろうとするのをやめ、それぞれの仕事を専用の段階に割り当てる、というものです。
ステージ1：想起。 最初の段階は、今日の標準的な密検索とまったく同じように動作します。つまり、埋め込みモデルが文書をベクトルに圧縮し、クエリに最も近い一致を取得します。ここは何も変わりません。この段階の目標は、広い網で素早く強力な候補集合を持ち帰ることです。速度と幅が重要であり、完璧な精度はこの段階では必要ではありません。
ステージ2：精度。 修正の本体は第2段階にあります。候補を単一の類似度の数値でスコアリングするのではなく、学習された小型のTransformerモデルが、クエリと各候補をトークン単位で精査します——個々の単語を個々の単語と比較することで、否定の反転や役割の反転（role reversals）のような構造的な不一致を検出します。これが、単一ベクトル方式では実行できない検証ステップです。
結果。 エンドツーエンド学習のもとで、Transformerの検証器は、研究がテストした構造的ニアミス拒否のあらゆる他のアプローチを上回りました。単一ベクトルのシステムが取り逃した失敗モードを、確実に捉えられたのは唯一のアプローチでした。
トレードオフ。 検証ステージを追加するとレイテンシがかかります。このコストは、チームがどれほどの検証を実行するかに依存します。法務や会計アプリケーションのように精度に敏感なワークロードでは、すべてのクエリで完全な検証を行うのが妥当です。汎用的な検索では、より軽い検証で十分な場合があります。
この研究は、実際の本番環境での問題から発展しました。セマンティックキャッシュの仕組みを運用しているエンタープライズの顧客は、速いものの意味的には正しくない応答を受け取っていました。検索（リトリーバル）システムが、意味が異なる場合でも、似た響きのクエリを同一のものとして扱っていたのです。この二段階アーキテクチャはRedisが提案する解決策で、同社のLangCacheプロダクトへの取り込みはロードマップにはあるものの、まだ顧客には提供されていません。
エンタープライズチームにとってこれは何を意味するか
この研究は、エンタープライズチームに対して、検索（リトリーバル）パイプラインを最初から作り直すことを求めていません。しかし、ほとんどのチームがこれまで検討したことのない前提を徹底的にストレステストすることを求めています。具体的には、埋め込みモデルが実際に何をしているのか、どの指標が信頼に値するのか、そして本番環境で実際の精度ギャップがどこに存在するのかです。
調整する前に、そのトレードオフを認識する。 Rajamohan氏は、最初の実務的なステップは回帰（レグレッション）が存在することを理解することだと述べました。彼は、LLMベースの検索システムを3つの基準で評価します：正しさ（correctness）、網羅性（completeness）、有用性（usefulness）です。正しさの失敗は、他の2つへ直接連鎖します。つまり、関連性ベンチマークでは良いスコアを出すのに、構造的な「ほぼ一致（near-miss）」で失敗する検索システムは、本番投入の準備ができているという誤った感覚を生み出していることになります。
RAGは時代遅れではない——ただし、できないことを知っておくべきだ。 Rajamohan氏は、RAGが置き換えられたという主張に対して強く反論しました。「それは大きな単純化だ」と彼は言いました。「RAGは非常にシンプルなパイプラインで、ほとんど誰でも、ほとんど手間をかけずに本番化できる。」この研究は、アーキテクチャとしてのRAGに反対しているわけではありません。微調整された埋め込みモデルを用いた単段階のRAGパイプラインを、精度に敏感なワークロードに対して本番対応できるものだと決めつけることに反対しています。
解決策は現実的だが、ただでは済まない。 より高い精度が必要なチームに対して、Rajamohan氏は二段階アーキテクチャは実装上の決定的な負担ではないものの、検証段階を追加するとレイテンシが発生すると述べました。「それは緩和（ミティゲーション）の問題だ」と彼は言いました。「実際に解決できるような種類のものではない。」
