- AI用語:Dense Retrieval
- 登録ID:G166
- AI用語の分類:生成AI・言語・検索・推論
ひとことで言うと:Dense Retrievalは、クエリと文書を多くの非ゼロ要素を持つdense vectorへ変換し、そのベクトル類似度を使って関連候補を取得する検索方式です。[1][2][3]
目次
Dense Retrievalとは
Dense Retrievalは、検索クエリと文書をdense vector(密ベクトル)で表現し、ベクトル空間上の近さを使って関連文書を取得する情報検索方式です。RAGやSemantic Searchの説明で頻繁に登場し、BM25などの語一致中心のSparse Retrievalと対比されます。
「dense」は、ベクトルの多くの次元が非ゼロ値を持つことを指します。数百〜数千程度の次元に、文章の特徴を連続値として分散して持たせる設計が一般的です。各次元を人間が「この次元は犬、この次元は法律」と直接解釈できるわけではありません。
仕組みの基本
典型的なDense Retrievalでは、文書側をEncoderでベクトル化してあらかじめ索引へ保存します。検索時にはクエリもEncoderでベクトル化し、Cosine SimilarityやDot Productなどで近い文書ベクトルを探します。
Dense Passage Retrieval(DPR)の代表的研究では、質問とパッセージを別々にエンコードするdual-encoder構成を使い、質問と関連パッセージのベクトルが近づくよう学習しています。この方式では、文書ベクトルを事前計算できるため、大規模検索で近傍探索を使いやすくなります。
Cross-Encoderのようにクエリと各文書を同時入力して精密に判定する方式と比べると、Dense Retrievalは初段検索として高速に多数候補を絞る用途に向きます。精度をさらに上げたい場合は、取得した上位候補をCross-Encoder等でRe-Rankingする二段構成がよく使われます。
なぜ語が一致しなくても探せるのか
Sparseな語一致検索では、クエリと文書が同じ語を共有していることが強い信号になります。Dense Retrievalでは、学習済みのEmbedding Modelがクエリと文書を連続ベクトルへ写像し、その距離で比較します。
たとえば「会社を辞めるときのPC返却」と「退職者は貸与端末を最終勤務日までに返す」という文章は、同じ単語が少なくても意味が近いと学習されていれば近傍に配置されます。
この特性は言い換え、自然文質問、多言語検索などで有利になることがあります。一方で、モデルが学習していない専門語や珍しい固有名詞、型番、正確な数値をうまく扱えない場合があります。
Sparse Retrievalとの境界
Sparse Retrievalでは、語彙に対応する高次元ベクトルの大部分がゼロで、BM25のような古典的手法では語の出現情報をもとに検索します。SPLADEのようにニューラルモデルでSparse表現を学習する方法もあります。
Dense RetrievalとSparse Retrievalの違いを「AI検索対従来検索」と理解するのは不正確です。Sparse Retrievalにも学習型がありますし、Dense Retrievalも単独で常に優れているわけではありません。
実務では、DenseとSparseを組み合わせるHybrid Searchが多く使われます。Dense側は意味的な言い換えを拾い、Sparse側は固有語や明示的な語一致を確保する、という補完関係を狙います。
Worked example
医療機器のマニュアル検索を考えます。ユーザーが「画面が固まったとき再起動してよいか」と質問し、マニュアルには「UIが応答しない場合は電源サイクルを実施する前に記録保存を確認する」と書かれているとします。
Dense Retrievalは「画面が固まる」と「UIが応答しない」、「再起動」と「電源サイクル」の意味的近さを捉えて候補を返せる可能性があります。
しかし製品型番MX-204Aだけが質問に含まれていた場合、その型番の一致はSparse Retrievalの方が確実かもしれません。さらに医療機器ではモデルが意味的に近い別機種の手順を返すと危険です。製品IDによるMetadata Filterや、後段の厳密なRe-Rankingが必要になります。
ANNとの関係
Dense Retrievalでは、文書数が大きいと全ベクトルとの類似度を毎回計算するのが高コストになります。そのためHNSWなどのApproximate Nearest Neighbor(ANN)検索を使うことがあります。
ANNは高速化のため探索を近似するので、検索アルゴリズム側のRecallも調整対象になります。Embedding Modelが良くても、ANN設定が極端に高速化寄りなら真に近い候補を落とすことがあります。
したがって、Dense Retrievalの性能を評価するときは、Embedding Modelの質とANN索引の設定を分けて考える必要があります。
学習時の負例が重要
Dense Retrieverは、関連文書を近づけ、非関連文書を遠ざけるよう学習することがあります。このとき、簡単すぎる負例だけで学習すると、本番で紛らわしい文書を区別できない可能性があります。
Hard Negativeと呼ばれる「一見関連しそうだが不正解の文書」を学習に含める方法は、検索モデルの識別能力を高めるために使われます。どのデータで学習したかによって、得意なドメインやクエリ形式が変わるため、一般ベンチマークだけで自社データの性能を保証できません。
Dense Retrievalの限界
Dense Retrievalは意味的な一致に強い一方、次のような点に注意が必要です。
- 型番、人名、コード、URL、法令番号など、文字列そのものが重要な検索。
- 否定や数量条件など、意味が近くても主張が逆になるケース。
- Embedding Modelの対象外言語や専門領域。
- 長い文書を一つのベクトルにして複数話題が混ざるケース。
- データ更新後に再Embeddingや再Indexingが必要な運用。
- 近傍検索が常に
k件返し、無関係な質問にも候補が出る問題。
これらはHybrid Search、Chunking、Metadata Filter、Re-Ranking、閾値設定などで補います。
次に起こりやすい誤解
よくあるのは、「Dense Retrievalは意味を理解するので、Keyword Searchより常に高精度」という誤解です。DPRのような研究でBM25を上回る結果が示された条件があっても、それを全ドメインへ一般化はできません。
また、「Dense RetrievalとVector Searchは完全に同義」と考えるのも少し粗い理解です。Dense Retrievalはdense representationを使った情報検索の設計を指し、Vector Searchはベクトル近傍探索というより一般的な処理です。Sparse vectorもVector Search基盤で扱える製品があります。
元文脈へ戻るためのチェックリスト
Dense Retrievalという語を見たら、次を確認します。
- query encoderとdocument encoderは同一か、別か。
- どのEmbedding Model/Retrieverを使うか。
- 学習データと対象ドメインは合っているか。
- Hard Negativeを含むどんな学習をしたか。
- 文書をどの単位でChunkingしているか。
- Similarity Metricは何か。
- exact kNNかANNか。ANNのRecall設定はどうか。
- Sparse RetrievalとのHybrid構成か。
- Re-Rankingを後段で行うか。
- 実データでRecall@k、MRR、nDCGなどを測っているか。
Dense Retrievalというラベルから推論できるのは、dense vectorの類似度を主要信号として候補を取得するということです。検索の正確さやRAG回答の信頼性は、モデル・データ・索引・後処理を含む全体構成を見て判断する必要があります。
Bi-Encoderの効率性
Dense RetrievalでBi-Encoderが広く使われる理由は、文書側ベクトルを事前計算できることです。文書が100万件あっても、検索のたびに100万文書をTransformerへ通す必要はありません。あらかじめEmbeddingを保存し、クエリだけを実行時にEncoderへ通して近傍探索します。
この設計は高いThroughputと低Latencyに向きますが、クエリと文書を別々に処理するため、両者の細かな語の相互作用を直接見る能力はCross-Encoderより制約されます。そのため「初段Dense Retrieval+後段Cross-Encoder Re-Ranking」という組み合わせが合理的になります。
モデルの説明で「dual encoder」「bi-encoder」「two-tower」といった語が出たら、別々に埋め込んで比較する構造を示している可能性があります。
In-batch NegativeとHard Negative
Dense Retrieverの学習では、正解query-documentペアだけでなく、どの文書を「間違い」として遠ざけるかが重要です。バッチ内の他文書をnegativeとして使うIn-batch Negativeや、BM25などが上位に出す紛らわしい非正解文書をHard Negativeとして使う方法があります。
Hard Negativeが有効なのは、モデルへ難しい境界を学ばせるためです。「東京の天気」と「量子力学」のような明らかに違うペアだけでは、実際の検索で迷う「国内出張規程」と「海外出張規程」を区別する能力が育ちにくいからです。
検索モデルの論文でtraining negativesの作り方が強調されるのは、このためです。
Domain Shift
学習データと本番データの分布が違うとDense Retrievalの性能が落ちることがあります。一般Web文書で学習したretrieverを、特殊な医療略語や企業内コードが多い文書へそのまま適用すると、重要な語を適切に表現できない可能性があります。
BM25は未知の固有語でも文字列として一致させられるため、domain shift時にDenseより頑健なケースがあります。逆に、専門用語の言い換えが多い領域ではDenseが有利かもしれません。
このためHybrid Searchは、平均性能だけでなく、未知語やdistribution shiftに対する保険として採用されることがあります。
Retrieval評価とEnd-to-End評価
Dense Retrieverの評価でRecall@20が高いからといって、RAG回答が正しいとは限りません。Recall@20は正解文書が上位20件へ入ったかを測るだけで、その20件からLLMが正解を選ぶかは別です。
逆に、Top-1精度が低くてもRe-Rankerが上位20件から正解を1位へ上げれば、最終システムは良い場合があります。検索層を評価するときは「first-stage recall」と「final ranking」と「answer quality」を分ける必要があります。
製品が「Dense Retrievalで精度95%」と説明していたら、何の指標を95%と呼んでいるかを確認します。Accuracy、Recall、Hit Rateなどでは意味が違います。
運用上の更新
文書が頻繁に更新される場合、Dense Retrievalでは新しい文書をEmbeddingし、indexへ追加する処理が必要です。Embedding Modelを変更した場合には、旧ベクトルと新ベクトルを混在させないため、全体再計算が必要になることがあります。
これはKeyword Searchで単語索引を更新する場合とは異なる運用コストです。モデルAPIの料金、Embedding batch処理、再indexing時間を含めて設計する必要があります。
関連するAI用語
- Hybrid Search
- Vector Search
- Embedding Model
- Sparse Retrieval
- Re-Ranking
注・出典
- ACL Anthology, Dense Passage Retrieval for Open-Domain Question Answering — dense representation、dual-encoder、BM25との比較というDense Retrievalの基礎 ↩
- Google Cloud, Get text embeddings — dense vectorが語の直接一致を越えた意味検索に使われること ↩
- Google Developers, Retrieval — query/item embeddingの近傍探索と大規模retrieval ↩
AI協働制作について
本記事は、著者が独自に設計した指示、参照資料、出典確認規則、著作権確認および監査工程を組み込んだChatGPT等の生成AIを、情報収集の補助、資料整理、構成検討、草稿作成、文章校正および監査補助に使用して制作しました。記事の対象範囲、情報源の採否、構成、解釈および最終表現は著者が判断し、最終稿を承認しています。著者は、本記事の正確性、独自性、引用、著作権処理および公開内容について責任を負います。制作工程の詳細は「AI協働制作方針」をご覧ください。 AI協働制作方針
