RAGの精度は検索戦略で決まる|ハイブリッド検索が効く理由を検証する
なぜ今「検索戦略」なのか
RAGを導入したものの、思ったように精度が出ない。
そのような経験はないでしょうか。
Embeddingモデルを選定し、ベクトル検索を実装した。それでも「欲しいドキュメントが取れていない」「回答が噛み合わない」と感じるケースは少なくありません。
多くの場合、検索の設計を振り返るとEmbeddingによるベクトル検索だけで完結していることがあります。
これまで本連載では
- HyDEによる質問設計(検索前の改善)
- top-k調整とRerankによる検索後の最適化
- RAGASを用いた定量評価と改善サイクル
- 構造化チャンク設計
といった手法を通じて、RAG精度の向上を検証してきました。
しかし、それらを適用してもなお「そもそも検索段階で必要なドキュメントを拾えていない」という壁に直面することがあります。
この問題は、モデルや評価以前に検索戦略そのものの設計に原因があるケースが少なくありません。
そこで本記事では、ベクトル検索だけでは取りこぼしてしまう情報を補完する手法として、ハイブリッド検索に焦点を当てます。
「なぜハイブリッド検索が効くのか」
「どのようなケースで効果が現れるのか」
実データと検証結果をもとに、検索戦略の観点から整理していきます。
ハイブリッド検索とは何か
ハイブリッド検索とは、セマンティック検索(ベクトル検索)とキーワード検索を組み合わせた検索手法です。
「ベクトル検索」とは、OpenAIの「text-embedding-3-small」などのEmbeddingモデルを用いてテキストをベクトル化し、意味的に近いドキュメント同士をコサイン類似度などで検索する手法です。
一方で「キーワード検索」とは、BM25などの手法を用い、単語の一致や出現頻度をもとにドキュメントを検索する手法です。
これら2つの検索手法を組み合わせることで、意味的な類似性と語彙レベルの一致の両方を考慮した検索が可能となり、これをハイブリッド検索と呼びます。
なぜEmbedding検索だけでは不十分なのか
セマンティック検索では、意味合いが近い表現に対して検索が行えるため、表現揺れや言い換えに強く、類似する文章を柔軟に引き出すことができます。
一方で、固有名詞やドメイン固有語が含まれる文書を正確に検索したい場合、この特性が逆に弱点となることがあります。
例えば、特定のプロダクト名や社内システム名、型番、専門用語などは、Embedding空間上では十分な意味的特徴を持たず、一般的な概念に近づいてしまうことがあります。その結果、本来一致させたいキーワードを含む文書が検索結果から漏れたり、意味的には近いが実務上は不要な文書が混在するケースが発生します。
このように、意味的な類似性に強いセマンティック検索であっても、語彙レベルでの一致が重要な場面では、検索精度に限界が現れます。
ハイブリッド検索が効く理由
ハイブリッド検索が有効に機能する最大の理由は、単一の検索手法では取りこぼしてしまう情報を相互に補完できる点にあります。
セマンティック検索とキーワード検索を組み合わせることで、意味的に近い文書と、語彙レベルで一致する文書の両方を検索対象に含めることができ、結果として検索のRecallが改善されます。
具体的には、セマンティック検索では捉えにくい固有名詞やドメイン固有語を、キーワード検索によって補完することができます。一方で、キーワード検索では単語一致のみに依存するため文脈を考慮できませんが、そこにセマンティック検索を組み合わせることで、意味的に関連する文書も検索結果に含めることが可能になります。
このように両者を組み合わせることで、検索結果が相互補完の関係となり、質問に対して本来引きたい文書をより高い確率で取得できるようになります。
検証設計:今回は何を比較したのか
今回は「セマンティック検索のみ」「キーワード検索のみ」「ハイブリッド検索」の3パターンで比較検証します。
比較がフェアになるよう、対象ドキュメント・クエリ・Top-kなどの条件は揃えた上で、検索結果に「本来引きたい文書が含まれるか(Recall)」と「不要な文書が混ざりすぎないか(Precision)」の観点で確認します。
本章では、各検索手法の「得意・不得意」がどのようなクエリで現れるのかを確認します。
特に「固有名詞が強いクエリ」「抽象度の高いクエリ」に対して、BM25/セマンティック/ハイブリッドがどのような挙動を示すかに注目します。
検証用のデータ
docs = [
# RAG / 検索戦略の中核ドキュメント
"RAG(Retrieval-Augmented Generation)は、LLMの生成能力に外部知識検索を組み合わせる設計手法です。Retrieverで関連ドキュメントを取得し、その結果をコンテキストとしてLLMに渡すことで、事前学習に含まれない情報も扱えるようになります。",
"RAG設計では、RetrieverでRecallを重視し、RerankでPrecisionを高める役割分担が重要です。Embedding検索は意味的に近い候補を広く集め、Rerankによって最終的に必要な文書を上位に絞り込みます。",
"Embedding検索は意味的に近い文章を取得できますが、top-kを増やすほどノイズが増加します。そのため、RAGではEmbedding検索単体ではなく、後段でのRerankや評価が不可欠になります。",
# 固有名詞・語彙一致が重要なドキュメント
"社内RAG基盤「AtlasSearch」は、2024年10月にv2.3へアップデートされました。Retrieverにはtext-embedding-3-smallを使用し、BM25はParadeDB拡張を用いて構成されています。",
"FAQ検索システム「HelpNow」では、Retriever → Rerank → LLM の三段構成を採用しています。Embedding検索で候補を取得し、Rerankによって回答精度を向上させています。",
"AtlasSearchでは、Embedding検索のtop-kを50に設定し、Rerankで上位5件に絞り込む構成を採用しています。これによりRecallとPrecisionのバランスを取っています。",
# キーワード一致が効きやすいが意味は薄い文書
"text-embedding-3-smallはOpenAIが提供するEmbeddingモデルの一つで、高速かつ低コストでの検索が可能です。",
"BM25は単語の出現頻度と文書長を考慮したランキング手法で、キーワード検索の代表的なアルゴリズムです。",
# 意味的に近いが「引けてほしくない」ノイズ
"AIを活用したFAQシステムは、問い合わせ対応の自動化による業務効率化に寄与します。ユーザーの自己解決率を高めることが目的です。",
"SEOでは、検索ユーザーの意図を理解したコンテンツ設計が重要です。キーワード選定や内部リンク構造が評価に影響します。",
"機械学習モデルの評価指標には、PrecisionやRecall、F1スコアなどがあります。用途に応じた指標選定が重要です。",
"クラウド上でのデータ分析基盤構築では、スケーラビリティとコスト管理の両立が求められます。",
# 完全に無関係なノイズ
"社内の勤怠管理システムでは、打刻漏れ防止のためにリマインド通知が導入されています。"
]
※ 本コードは挙動比較を目的とした最小構成であり、 実運用では tokenizer・weight・top-k・Rerank を含めた調整が前提となります。
実際の検証のソース
import os
from typing import List
from langchain_core.documents import Document
from langchain_community.retrievers import BM25Retriever
from langchain_classic.retrievers import EnsembleRetriever
from langchain_community.vectorstores import Chroma
from langchain_openai import AzureOpenAIEmbeddings
from sudachipy import dictionary, tokenizer as sudachi_tokenizer
os.environ["AZURE_OPENAI_ENDPOINT"] = "your-endpoint"
os.environ["AZURE_OPENAI_API_KEY"] = "your-apikey"
embeddings = AzureOpenAIEmbeddings(
azure_deployment="text-embedding-3-small"
)
docs = [
"上記の別タブの「検証用データ」で記載"
]
documents = [
Document(page_content=text, metadata={"doc_id": i})
for i, text in enumerate(docs)
]
tokenizer_obj = dictionary.Dictionary().create()
mode = sudachi_tokenizer.Tokenizer.SplitMode.C
def tokenize_ja(text: str) -> List[str]:
return [m.surface() for m in tokenizer_obj.tokenize(text, mode)]
bm25 = BM25Retriever.from_documents(
documents,
preprocess_func=tokenize_ja
)
bm25.k = 5
vectorstore = Chroma.from_documents(
documents=documents,
embedding=embeddings,
collection_name="rag_search_strategy_demo",
)
semantic = vectorstore.as_retriever(search_kwargs={"k": 5})
hybrid = EnsembleRetriever(
retrievers=[bm25, semantic],
weights=[0.5, 0.5],
)
def show_hits(title: str, hits):
print(f"\n=== {title} ===")
for rank, d in enumerate(hits, 1):
doc_id = d.metadata.get("doc_id")
preview = d.page_content[:70].replace("\n", "")
print(f"{rank:02d}. doc_id={doc_id} | {preview}...")
queries = [
"AtlasSearchのRetriever構成は?",
"HelpNowの検索パイプラインを教えて",
"text-embedding-3-smallを使っているシステムは?",
"RAGでRecallとPrecisionを両立する設計は?",
"RAGの検索精度を改善する方法は?",
]
for q in queries:
print(f"\n\n######## QUERY: {q}")
show_hits("BM25", bm25.invoke(q))
show_hits("Semantic (Chroma)", semantic.invoke(q))
show_hits("Hybrid", hybrid.invoke(q))
検証結果の「AtlasSearchのRetriever構成は?」
######## QUERY: AtlasSearchのRetriever構成は?
=== BM25 ===
01. doc_id=3 | 社内RAG基盤「AtlasSearch」は、2024年10月にv2.3へアップデートされました。Retrieverにはtext-embedd...
02. doc_id=5 | AtlasSearchでは、Embedding検索のtop-kを50に設定し、Rerankで上位5件に絞り込む構成を採用しています。これによ...
03. doc_id=4 | FAQ検索システム「HelpNow」では、Retriever → Rerank → LLM の三段構成を採用しています。Embedding検...
04. doc_id=0 | RAG(Retrieval-Augmented Generation)は、LLMの生成能力に外部知識検索を組み合わせる設計手法です。Retr...
05. doc_id=11 | クラウド上でのデータ分析基盤構築では、スケーラビリティとコスト管理の両立が求められます。...
=== Semantic (Chroma) ===
01. doc_id=3 | 社内RAG基盤「AtlasSearch」は、2024年10月にv2.3へアップデートされました。Retrieverにはtext-embedd...
02. doc_id=5 | AtlasSearchでは、Embedding検索のtop-kを50に設定し、Rerankで上位5件に絞り込む構成を採用しています。これによ...
03. doc_id=4 | FAQ検索システム「HelpNow」では、Retriever → Rerank → LLM の三段構成を採用しています。Embedding検...
04. doc_id=1 | RAG設計では、RetrieverでRecallを重視し、RerankでPrecisionを高める役割分担が重要です。Embedding検索...
05. doc_id=0 | RAG(Retrieval-Augmented Generation)は、LLMの生成能力に外部知識検索を組み合わせる設計手法です。Retr...
=== Hybrid ===
01. doc_id=3 | 社内RAG基盤「AtlasSearch」は、2024年10月にv2.3へアップデートされました。Retrieverにはtext-embedd...
02. doc_id=5 | AtlasSearchでは、Embedding検索のtop-kを50に設定し、Rerankで上位5件に絞り込む構成を採用しています。これによ...
03. doc_id=4 | FAQ検索システム「HelpNow」では、Retriever → Rerank → LLM の三段構成を採用しています。Embedding検...
04. doc_id=0 | RAG(Retrieval-Augmented Generation)は、LLMの生成能力に外部知識検索を組み合わせる設計手法です。Retr...
05. doc_id=1 | RAG設計では、RetrieverでRecallを重視し、RerankでPrecisionを高める役割分担が重要です。Embedding検索...
06. doc_id=11 | クラウド上でのデータ分析基盤構築では、スケーラビリティとコスト管理の両立が求められます。...
→BM25で「AtlasSearch」の言葉がトップの1, 2で引けているのは、狙い通りになっていると思います。今回は「AtlasSearch」「Retriever」といった語が明確に含まれており、セマンティック検索でも文脈的に強い特徴量として作用した可能性があります。
検証結果の「HelpNowの検索パイプラインを教えて」
######## QUERY: HelpNowの検索パイプラインを教えて
=== BM25 ===
01. doc_id=4 | FAQ検索システム「HelpNow」では、Retriever → Rerank → LLM の三段構成を採用しています。Embedding検...
02. doc_id=5 | AtlasSearchでは、Embedding検索のtop-kを50に設定し、Rerankで上位5件に絞り込む構成を採用しています。これによ...
03. doc_id=7 | BM25は単語の出現頻度と文書長を考慮したランキング手法で、キーワード検索の代表的なアルゴリズムです。...
04. doc_id=2 | Embedding検索は意味的に近い文章を取得できますが、top-kを増やすほどノイズが増加します。そのため、RAGではEmbedding検...
05. doc_id=0 | RAG(Retrieval-Augmented Generation)は、LLMの生成能力に外部知識検索を組み合わせる設計手法です。Retr...
=== Semantic (Chroma) ===
01. doc_id=4 | FAQ検索システム「HelpNow」では、Retriever → Rerank → LLM の三段構成を採用しています。Embedding検...
02. doc_id=5 | AtlasSearchでは、Embedding検索のtop-kを50に設定し、Rerankで上位5件に絞り込む構成を採用しています。これによ...
03. doc_id=2 | Embedding検索は意味的に近い文章を取得できますが、top-kを増やすほどノイズが増加します。そのため、RAGではEmbedding検...
04. doc_id=3 | 社内RAG基盤「AtlasSearch」は、2024年10月にv2.3へアップデートされました。Retrieverにはtext-embedd...
05. doc_id=8 | AIを活用したFAQシステムは、問い合わせ対応の自動化による業務効率化に寄与します。ユーザーの自己解決率を高めることが目的です。...
=== Hybrid ===
01. doc_id=4 | FAQ検索システム「HelpNow」では、Retriever → Rerank → LLM の三段構成を採用しています。Embedding検...
02. doc_id=5 | AtlasSearchでは、Embedding検索のtop-kを50に設定し、Rerankで上位5件に絞り込む構成を採用しています。これによ...
03. doc_id=2 | Embedding検索は意味的に近い文章を取得できますが、top-kを増やすほどノイズが増加します。そのため、RAGではEmbedding検...
04. doc_id=7 | BM25は単語の出現頻度と文書長を考慮したランキング手法で、キーワード検索の代表的なアルゴリズムです。...
05. doc_id=3 | 社内RAG基盤「AtlasSearch」は、2024年10月にv2.3へアップデートされました。Retrieverにはtext-embedd...
06. doc_id=0 | RAG(Retrieval-Augmented Generation)は、LLMの生成能力に外部知識検索を組み合わせる設計手法です。Retr...
07. doc_id=8 | AIを活用したFAQシステムは、問い合わせ対応の自動化による業務効率化に寄与します。ユーザーの自己解決率を高めることが目的です。...
→今回もBM25・セマンティックの双方で正解文書が引けていますが、これはデータ規模が小さく、正解文書が明示的に含まれているためかと思われます。
検証結果の「text-embedding-3-smallを使っているシステムは?」
######## QUERY: text-embedding-3-smallを使っているシステムは?
=== BM25 ===
01. doc_id=6 | text-embedding-3-smallはOpenAIが提供するEmbeddingモデルの一つで、高速かつ低コストでの検索が可能です。...
02. doc_id=3 | 社内RAG基盤「AtlasSearch」は、2024年10月にv2.3へアップデートされました。Retrieverにはtext-embedd...
03. doc_id=5 | AtlasSearchでは、Embedding検索のtop-kを50に設定し、Rerankで上位5件に絞り込む構成を採用しています。これによ...
04. doc_id=2 | Embedding検索は意味的に近い文章を取得できますが、top-kを増やすほどノイズが増加します。そのため、RAGではEmbedding検...
05. doc_id=8 | AIを活用したFAQシステムは、問い合わせ対応の自動化による業務効率化に寄与します。ユーザーの自己解決率を高めることが目的です。...
=== Semantic (Chroma) ===
01. doc_id=6 | text-embedding-3-smallはOpenAIが提供するEmbeddingモデルの一つで、高速かつ低コストでの検索が可能です。...
02. doc_id=2 | Embedding検索は意味的に近い文章を取得できますが、top-kを増やすほどノイズが増加します。そのため、RAGではEmbedding検...
03. doc_id=3 | 社内RAG基盤「AtlasSearch」は、2024年10月にv2.3へアップデートされました。Retrieverにはtext-embedd...
04. doc_id=5 | AtlasSearchでは、Embedding検索のtop-kを50に設定し、Rerankで上位5件に絞り込む構成を採用しています。これによ...
05. doc_id=1 | RAG設計では、RetrieverでRecallを重視し、RerankでPrecisionを高める役割分担が重要です。Embedding検索...
=== Hybrid ===
01. doc_id=6 | text-embedding-3-smallはOpenAIが提供するEmbeddingモデルの一つで、高速かつ低コストでの検索が可能です。...
02. doc_id=3 | 社内RAG基盤「AtlasSearch」は、2024年10月にv2.3へアップデートされました。Retrieverにはtext-embedd...
03. doc_id=2 | Embedding検索は意味的に近い文章を取得できますが、top-kを増やすほどノイズが増加します。そのため、RAGではEmbedding検...
04. doc_id=5 | AtlasSearchでは、Embedding検索のtop-kを50に設定し、Rerankで上位5件に絞り込む構成を採用しています。これによ...
05. doc_id=8 | AIを活用したFAQシステムは、問い合わせ対応の自動化による業務効率化に寄与します。ユーザーの自己解決率を高めることが目的です。...
06. doc_id=1 | RAG設計では、RetrieverでRecallを重視し、RerankでPrecisionを高める役割分担が重要です。Embedding検索...
→今回は「doc_id=3」が最適解のケースです。BM25は珍しい名称である「text-embedding-3-small」の二つが引けているので、BM25としては悪くないと思っています。ただセマンティック側の検索精度が伸びなかったせいか、ハイブリッド検索でも最適の文書が引けていない状態になりました。
ここで精度改善を望むのであれば、埋め込みモデルの変更もしくは、Rerankの活用などで解決ができると思います。
検証結果の「RAGでRecallとPrecisionを両立する設計は?」
######## QUERY: RAGでRecallとPrecisionを両立する設計は?
=== BM25 ===
01. doc_id=1 | RAG設計では、RetrieverでRecallを重視し、RerankでPrecisionを高める役割分担が重要です。Embedding検索...
02. doc_id=11 | クラウド上でのデータ分析基盤構築では、スケーラビリティとコスト管理の両立が求められます。...
03. doc_id=5 | AtlasSearchでは、Embedding検索のtop-kを50に設定し、Rerankで上位5件に絞り込む構成を採用しています。これによ...
04. doc_id=0 | RAG(Retrieval-Augmented Generation)は、LLMの生成能力に外部知識検索を組み合わせる設計手法です。Retr...
05. doc_id=6 | text-embedding-3-smallはOpenAIが提供するEmbeddingモデルの一つで、高速かつ低コストでの検索が可能です。...
=== Semantic (Chroma) ===
01. doc_id=1 | RAG設計では、RetrieverでRecallを重視し、RerankでPrecisionを高める役割分担が重要です。Embedding検索...
02. doc_id=0 | RAG(Retrieval-Augmented Generation)は、LLMの生成能力に外部知識検索を組み合わせる設計手法です。Retr...
03. doc_id=10 | 機械学習モデルの評価指標には、PrecisionやRecall、F1スコアなどがあります。用途に応じた指標選定が重要です。...
04. doc_id=5 | AtlasSearchでは、Embedding検索のtop-kを50に設定し、Rerankで上位5件に絞り込む構成を採用しています。これによ...
05. doc_id=3 | 社内RAG基盤「AtlasSearch」は、2024年10月にv2.3へアップデートされました。Retrieverにはtext-embedd...
=== Hybrid ===
01. doc_id=1 | RAG設計では、RetrieverでRecallを重視し、RerankでPrecisionを高める役割分担が重要です。Embedding検索...
02. doc_id=0 | RAG(Retrieval-Augmented Generation)は、LLMの生成能力に外部知識検索を組み合わせる設計手法です。Retr...
03. doc_id=5 | AtlasSearchでは、Embedding検索のtop-kを50に設定し、Rerankで上位5件に絞り込む構成を採用しています。これによ...
04. doc_id=11 | クラウド上でのデータ分析基盤構築では、スケーラビリティとコスト管理の両立が求められます。...
05. doc_id=10 | 機械学習モデルの評価指標には、PrecisionやRecall、F1スコアなどがあります。用途に応じた指標選定が重要です。...
06. doc_id=6 | text-embedding-3-smallはOpenAIが提供するEmbeddingモデルの一つで、高速かつ低コストでの検索が可能です。...
07. doc_id=3 | 社内RAG基盤「AtlasSearch」は、2024年10月にv2.3へアップデートされました。Retrieverにはtext-embedd...
→こちらはキーワード、セマンティックどちらとも問題ありませんでした。
検証結果の「RAGの検索精度を改善する方法は?」
######## QUERY: RAGの検索精度を改善する方法は?
=== BM25 ===
01. doc_id=6 | text-embedding-3-smallはOpenAIが提供するEmbeddingモデルの一つで、高速かつ低コストでの検索が可能です。...
02. doc_id=4 | FAQ検索システム「HelpNow」では、Retriever → Rerank → LLM の三段構成を採用しています。Embedding検...
03. doc_id=2 | Embedding検索は意味的に近い文章を取得できますが、top-kを増やすほどノイズが増加します。そのため、RAGではEmbedding検...
04. doc_id=1 | RAG設計では、RetrieverでRecallを重視し、RerankでPrecisionを高める役割分担が重要です。Embedding検索...
05. doc_id=0 | RAG(Retrieval-Augmented Generation)は、LLMの生成能力に外部知識検索を組み合わせる設計手法です。Retr...
=== Semantic (Chroma) ===
01. doc_id=1 | RAG設計では、RetrieverでRecallを重視し、RerankでPrecisionを高める役割分担が重要です。Embedding検索...
02. doc_id=2 | Embedding検索は意味的に近い文章を取得できますが、top-kを増やすほどノイズが増加します。そのため、RAGではEmbedding検...
03. doc_id=3 | 社内RAG基盤「AtlasSearch」は、2024年10月にv2.3へアップデートされました。Retrieverにはtext-embedd...
04. doc_id=0 | RAG(Retrieval-Augmented Generation)は、LLMの生成能力に外部知識検索を組み合わせる設計手法です。Retr...
05. doc_id=4 | FAQ検索システム「HelpNow」では、Retriever → Rerank → LLM の三段構成を採用しています。Embedding検...
=== Hybrid ===
01. doc_id=1 | RAG設計では、RetrieverでRecallを重視し、RerankでPrecisionを高める役割分担が重要です。Embedding検索...
02. doc_id=2 | Embedding検索は意味的に近い文章を取得できますが、top-kを増やすほどノイズが増加します。そのため、RAGではEmbedding検...
03. doc_id=4 | FAQ検索システム「HelpNow」では、Retriever → Rerank → LLM の三段構成を採用しています。Embedding検...
04. doc_id=0 | RAG(Retrieval-Augmented Generation)は、LLMの生成能力に外部知識検索を組み合わせる設計手法です。Retr...
05. doc_id=6 | text-embedding-3-smallはOpenAIが提供するEmbeddingモデルの一つで、高速かつ低コストでの検索が可能です。...
06. doc_id=3 | 社内RAG基盤「AtlasSearch」は、2024年10月にv2.3へアップデートされました。Retrieverにはtext-embedd...
→こちらはキーワード検索の為、意味合い検索のような結果は当然得られていません。ただセマンティック側は見事に最適な1と2を引き、ハイブリッドでカバーし、最適な文書が得られるいい例でもあったと思います。
検証結果:どこで効き、どこで効かなかったか
今回の検証から、検索手法ごとの「得意・不得意」がいくつかのパターンで見えてきました。
キーワード検索(BM25)が有効だったケース
BM25は、AtlasSearchやHelpNowのように、固有名詞や明確な語彙を含むクエリに対して安定して文書を取得できていました。特に、文書内にクエリ語がそのまま含まれている場合、セマンティック検索よりも高い精度で上位に正解文書を配置できています。
セマンティック検索が有効だったケース
一方で、セマンティック検索は抽象度が高く、語彙が必ずしも一致しないクエリに対して強みを発揮していました。「RAGの検索精度を改善する方法は?」のような質問では、意味的に関連する文書を適切に上位に引き上げることができています。
セマンティック検索が十分に機能しなかったケース
今回の検証では、Embeddingモデルの表現力の影響により、一部のクエリではセマンティック検索が最適な文書を十分に引き出せないケースも見られました。このような場合、Embeddingモデルの変更や、Rerankによる後段での補正が有効な改善策となります。
ハイブリッド検索の位置づけ
ハイブリッド検索は、BM25とセマンティック検索の結果を統合することで、単一手法では取りこぼしやすい文書を補完できる点が強みです。今回の検証ではweightを0.5/0.5としましたが、意味的な類似性が重要なケースでは、セマンティック側に重みを寄せることで、より安定した検索結果が得られる可能性も感じられました。
設計視点:いつハイブリッド検索を使うべきか
向いているケース
ハイブリッド検索が向いているのは、固有名詞・製品名・社内用語・専門用語が頻繁に登場する情報検索システムです。これらの語は、Embeddingモデルの事前学習に十分含まれていない場合、セマンティック検索だけでは意味的特徴を捉えきれず、検索結果から漏れるケースが発生します。
このような場合、BM25などのキーワード検索を組み合わせることで、語彙レベルでの一致を補完でき、検索の安定性が向上します。
向いていないケース
一方で、高速なレスポンスが最優先されるシステムや、一般用語中心で構成されたFAQのような検索対象では、ハイブリッド検索による効果は限定的です。検索精度の改善幅に対して、処理コストや実装の複雑性が見合わない場合も多く、必ずしも導入する必要はありません。
PoC段階での導入判断基準
PoC段階では、まずセマンティック検索単体での挙動を確認することが重要です。
意味的には適切な文書が取得できている一方で、特定の専門用語や固有名詞を含むクエリで精度が不安定になる場合には、ハイブリッド検索の導入を検討する価値があります。
コスト・複雑性のトレードオフ
ハイブリッド検索は、Retrieverの構成や重み付けの調整など、システム全体の設計難易度を確実に引き上げます。
そのため、精度向上のメリットと、実装・運用コストのバランスを見極めた上で導入する必要があります。
これまでの記事との位置づけ
これまで本連載では、RAGの精度を段階的に改善するための設計ポイントを整理してきました。本記事はその中でも、「検索レイヤ」に焦点を当て、セマンティック検索だけでは拾いきれない情報をどのように補完するかを検証しています。
RAGは単一の手法で完結するものではなく、検索前・検索・検索後・評価といった複数のレイヤを組み合わせて設計することで、初めて安定した精度を実現できます。
| レイヤ | 記事 |
|---|---|
| 検索前 | 質問設計(HyDE) |
| 検索 | チャンク設計、ハイブリッド検索(本記事) |
| 検索後 | Rerank |
| 評価 | RAGAS |
本記事で扱ったハイブリッド検索は、検索戦略を見直す際の一つの選択肢にすぎませんが、固有名詞や専門用語が多いケースでは有効な手段となります。
まとめ:RAG精度改善は局所最適ではなく戦略
本記事では、RAGにおける検索戦略の一つとして、ハイブリッド検索がどのようなケースで有効に機能するのかを検証しました。ハイブリッド検索は万能な解決策ではありませんが、固有名詞や専門用語が多いデータを扱う場合には、セマンティック検索単体では補えない部分を補完できる手法です。
RAGの精度改善は、EmbeddingモデルやRetrieverの調整といった単一要素の最適化だけでは完結しません。検索前・検索・検索後・評価といった各レイヤを意識し、全体としてどの戦略を取るかを設計することが重要です。
本記事が、RAGの検索設計を見直す際の一つの判断材料になれば幸いです。
関連記事
ハイブリッド検索によって検索レイヤのRecallを改善できても、そもそも検索クエリ自体が曖昧なままでは、十分な効果は得られません。
検索前の段階でクエリの表現を最適化し、Embedding検索が本来の意図を捉えやすくするアプローチとして、HyDEによる質問設計については以下の記事で検証しています。
ハイブリッド検索によって候補文書のRecallを高めた後は、取得した文書をどのように絞り込むかが次の課題になります。
検索後のフェーズであるRerankによって、top-k検索結果をどのように再順位付けし、Precisionを高めていくかについては、以下の記事で詳しく検証しています。
Discussion