Milvus ハイブリッド検索入門｜RAG の精度を上げる実装ガイド 2026

はじめに — なぜ今 Milvus なのか

RAG（Retrieval-Augmented Generation）システムを構築していると、ある壁に必ずぶつかります。「型番や固有名詞を含む質問をすると、意味的には近いがまったく違うチャンクが返ってくる」という問題です。

たとえば「RTX 4090 の TDP を教えて」というクエリを Dense Vector 検索にかけると、セマンティックの近さから GPU 全般の話題が上位に来て、肝心の数値が拾えないことがあります。これはベクター検索の構造的な弱点であり、単純なアーキテクチャでは回避が困難です。

そこで注目されているのが ハイブリッド検索 であり、それをネイティブにサポートするベクターデータベース Milvus です。GitHub スター数 45,700 超（2026 年時点）を誇るオープンソースプロジェクトとして、LF AI & Data 傘下で活発に開発が続けられています。本記事では、Milvus を使ったハイブリッド検索の仕組みと実装方法を、段階的に理解を深めていきましょう。

ベクターデータベースと RAG の基礎

RAG パイプラインと検索品質の関係

RAG の流れは大まかに「チャンク分割 → 埋め込み生成 → ベクターDB に格納 → クエリで検索 → 上位チャンクを LLM に渡す」という構成です。このうち 検索フェーズの品質が最終回答品質を直接決定します。どれほど優秀な LLM を使っても、渡す情報が間違っていれば正しい回答は得られません。

ベクターデータベースの役割は、埋め込み（Embedding）空間上での近似最近傍探索（ANN: Approximate Nearest Neighbor）を高速に実行することです。リレーショナル DB は構造化データに強く、Elasticsearch などの全文検索エンジンはキーワードマッチに強い。ベクター DB はそのどちらでもなく、非構造化データの意味的な類似性を捉える 点で補完的な役割を担います。

2026 年の Milvus 3.0「Lake-Native」アーキテクチャ

Milvus 3.0 の最大の変化は「Lake-Native」アーキテクチャの採用です。Parquet・Lance・Iceberg などのデータレイク形式に格納されたデータに対して、コピー不要で直接インデックスを構築・検索 できるようになりました。

また Storage v3「Loon」エンジンにより、S3 互換オブジェクトストレージからの I/O が従来の Parquet 比で 135 分の 1 に削減されています。データ基盤とベクター検索が統合される流れは、2026 年のインフラ設計において見逃せないポイントです。

ハイブリッド検索の仕組み — RAG の新しい標準

3 つの検索レイヤー

Milvus がサポートするハイブリッド検索は、以下の 3 レイヤーで構成されます。

Dense Vector は文章全体の意味を圧縮した実数ベクトルです。「表現は違うが意味は同じ」という言い換えに強い反面、「RTX 4090」のような固有表現には弱い側面があります。

Sparse Embedding（SPLADE / BGE-M3） は、語の重要度を学習済みモデルで動的に決定する疎なベクトルです。BM25 との最大の違いは、事前学習によって「文脈上重要な語」を統計では捉えられない形で重み付けできる点です。ドメイン特化度が高く多言語対応も優れていますが、モデルの推論コストがかかります。

BM25（Best Match 25） は単語の出現頻度と文書頻度から関連度を計算する古典的なアルゴリズムです。実装コストが低く予測可能な挙動を示しますが、表記ゆれや言い換えには対応できません。

この 3 つが互いの弱点を補うことで、精度と堅牢性を両立した検索が実現します。

結果の統合 — RRF と Weighted Reranking

複数の検索結果をどう 1 つにまとめるかが、ハイブリッド検索の肝です。Milvus は 2 つの統合手法を提供しています。

• RRF（Reciprocal Rank Fusion）: 各検索結果の順位に基づいてスコアを算出し統合します。スコアのスケールが異なるシステムをそのまま組み合わせられるため、最初はこちらを選ぶとよいでしょう。
• Weighted Reranking: ドメイン知識に基づいて各レイヤーの重みを手動調整します。「このユースケースではキーワード一致の精度が特に重要」といった場合に有効です。

Milvus 3.0 で導入された SINDI（Sparse Index for Dense Interactions） アルゴリズムにより、スパース検索のスループットが従来比最大 10 倍 向上しています。BM25 と SPLADE が同一の最適化パスを共有するため、両方を組み合わせてもオーバーヘッドは最小限です。

実装編 — Milvus でハイブリッド検索を動かす

Milvus Lite で 5 分で始める

実際の開発現場では、まずローカル環境で動作を確認してから本番に移るのがベストプラクティスとして定着しています。Milvus Lite はその検証ステップを pip install だけで実現します。

pip install pymilvus[model]

追加のサーバー設定は不要で、Jupyter Notebook から直接実行できます。

スキーマ設計 — Dense と Sparse を同居させる

ハイブリッド検索を行うコレクションでは、Dense・Sparse の両フィールドを定義します。

from pymilvus import MilvusClient, DataType

client = MilvusClient("./milvus_demo.db")  # Lite モード

schema = client.create_schema(auto_id=True, enable_dynamic_field=True)
schema.add_field("id", DataType.INT64, is_primary=True)
schema.add_field("text", DataType.VARCHAR, max_length=65535)
schema.add_field("dense_vector", DataType.FLOAT_VECTOR, dim=1024)
schema.add_field("sparse_vector", DataType.SPARSE_FLOAT_VECTOR)

# BM25 用の Function 定義
from pymilvus import Function, FunctionType
bm25_function = Function(
    name="text_bm25_emb",
    input_field_names=["text"],
    output_field_names=["sparse_vector"],
    function_type=FunctionType.BM25,
)
schema.add_function(bm25_function)

日本語テキストを扱う場合は、アナライザー設定でトークナイザーを適切に指定する必要があります。デフォルトの英語用トークナイザーでは日本語のトークン分割が機能しないため注意してください。

単一クエリでハイブリッド検索を実行する

AnnSearchRequest を複数定義し、hybrid_search に渡すのが Milvus のハイブリッド検索 API の基本形です。

from pymilvus import AnnSearchRequest, RRFRanker

# Dense 検索リクエスト
dense_req = AnnSearchRequest(
    data=[query_dense_vector],
    anns_field="dense_vector",
    param={"metric_type": "COSINE", "params": {"nprobe": 10}},
    limit=20,
)

# Sparse 検索リクエスト（BM25）
sparse_req = AnnSearchRequest(
    data=[query_sparse_vector],
    anns_field="sparse_vector",
    param={"metric_type": "IP"},
    limit=20,
)

# RRF で統合して上位 5 件取得
results = client.hybrid_search(
    collection_name="my_collection",
    reqs=[dense_req, sparse_req],
    ranker=RRFRanker(),
    limit=5,
    output_fields=["text"],
)

チューニングの観点では、各レイヤーの limit を最終取得件数より大きめ（2〜5 倍程度）に設定することで、RRF によるランク融合の精度が向上します。評価データセットを用意して Dense 単体との MRR（Mean Reciprocal Rank）を比較することが、実務的な改善指標として有効です。

GPU で加速する — NVIDIA CAGRA インデックス

Milvus が唯一ネイティブサポートする GPU インデックス

オープンソースのベクターデータベースの中で、NVIDIA CAGRA を本番レベルでネイティブサポートするのは Milvus だけ です。CAGRA はグラフベース ANN アルゴリズムを GPU に最適化した実装で、CPU ベースの HNSW と比べて劇的な性能向上をもたらします。

10M ベクター・次元数 1536 での比較値

GPU は必須なのか — 導入判断チェックリスト

技術的に正確な表現を心がけると、GPU が必須になるケースは限られています。以下の観点で判断してください。

• データ規模が 1,000 万ベクター超: インデックス再構築の時間コストが大きくなり、GPU の恩恵が顕在化します
• レイテンシ要件が 1ms 以下: CPU HNSW では物理的に届かない領域です
• インデックス再構築の頻度が高い: リアルタイムでデータが追加・更新されるユースケースでは GPU 時間の節約が大きい

逆に、数十万〜数百万ベクター規模で QPS が数百程度であれば、CPU HNSW で十分なケースがほとんどです。

Milvus 2.6.1 以降のハイブリッド GPU-CPU 設計では、GPU でグラフ構築・CPU でクエリ実行という分業が可能で、GPU リソースを常時占有しない効率的な運用モデルを実現しています。

Kubernetes で本番スケールさせる

Milvus Distributed のアーキテクチャ

Milvus Distributed は ステートレスマイクロサービス設計 を採用しており、個々のコンポーネントが独立してスケール可能です。計算とストレージを分離しているため、クエリノードを増やしてもストレージ側への影響がなく、柔軟なスケールアウトが実現できます。

数十億ベクター・数万 QPS 規模への拡張パスとして、コンポーネント別のスケール指針は以下の通りです。

• Query Node: クエリレイテンシ・QPS が律速になったら水平スケール
• Index Node: インデックス構築の速度が問題になったら増強（GPU ノードプールとの組み合わせが効果的）
• Data Node: データ投入スループットが足りない場合に追加

GPU ノードを Kubernetes クラスターに組み込む場合は、NVIDIA Device Plugin を導入し GPU ノードプールを分離することで、インデックス構築ジョブと検索ワークロードを独立してスケールできます。

運用監視では レイテンシ P99・リコール率・メモリ使用量 の 3 指標を基本とし、Milvus Operator または Helm によるデプロイ管理を選択してください。

LangChain / LlamaIndex との連携パターン

LangChain（langchain-milvus）

LangChain では BM25 Retriever と Milvus Vector Store を明示的に組み合わせるスタイルが主流です。EnsembleRetriever で重みを指定して統合できます。

from langchain_milvus import Milvus
from langchain_community.retrievers import BM25Retriever
from langchain.retrievers import EnsembleRetriever

milvus_retriever = Milvus(...).as_retriever(search_kwargs={"k": 10})
bm25_retriever = BM25Retriever.from_documents(docs)

hybrid_retriever = EnsembleRetriever(
    retrievers=[bm25_retriever, milvus_retriever],
    weights=[0.4, 0.6],
)

制御の細かさを重視する場合、各レイヤーの重みやプリプロセスを自由に調整できる LangChain が向いています。

LlamaIndex

LlamaIndex では HybridRetriever が BM25 と Dense を自動でブレンドし、Milvus ネイティブアダプターとのシームレスな連携が特徴です。コード量が少なく、素早くプロトタイプを立ち上げたい場合に適しています。

2026 年の Agentic RAG の文脈では、LangGraph や OpenAI Agents SDK との統合も進んでいます。ツール呼び出しの形でベクター検索を組み込む構成が増えており、いずれも Milvus との連携が実証されています。

Milvus Lite から本番環境への移行パス

Milvus 最大の強みのひとつが 統一 API です。ローカル検証から本番まで、コードをほぼ変えずに移行できます。

Milvus Lite（pip install / ローカル・Jupyter）
    ↓ 接続文字列の変更のみ
Milvus Standalone（Docker / 小〜中規模本番）
    ↓ 接続文字列の変更のみ
Milvus Distributed（Kubernetes / 大規模）
    ↓ バックアップツールで移行
Zilliz Cloud（フルマネージド）

Milvus Lite は検証・プロトタイピング専用で、本番スケールには対応していません。データ量が増えたら Milvus Standalone へ移行し、QPS や可用性要件が高まった段階で Milvus Distributed（Kubernetes）を検討する流れが現実的です。

Zilliz Cloud への移行は MilvusMigrationTool を使って実施できます。Elasticsearch や pgvector など他システムからの移行もサポートされており、既存のデータ基盤から段階的に移行する経路が整備されています。

セルフホスト vs マネージドの判断は、運用工数・コンプライアンス要件・コスト の 3 軸で行います。GPU ノードの管理や Kubernetes オペレーターのメンテナンスが負担になる場合は、Zilliz Cloud への移行を早めに検討するのが実際の開発現場では合理的な判断です。

よくある質問（FAQ）

Q. なぜハイブリッド検索が必要なのですか？ Dense Vector 単体では固有名詞・型番・略語などのキーワード完全一致に弱く、BM25 単体では言い換えや表記ゆれに脆弱です。両者を組み合わせることで、RAG の再現率と精度を同時に改善できます。

Q. SPLADE と BM25 はどう使い分けますか？ ドメイン特化データや多言語テキストには SPLADE が有効です。一方、実装コストを抑えたい場合やモデル推論リソースが限られている場合は BM25 が現実解になります。BGE-M3 は Dense と Sparse を 1 モデルで同時生成できるため、両方が必要な場合のコスト効率が高いです。

Q. GPU がないと Milvus は使えませんか？ GPU なしでも完全に動作します。CPU HNSW は十分な性能を持ち、数百万規模のベクターであれば実用的なレイテンシを達成できます。GPU は「必要になったら足す」という判断で問題ありません。

Q. Milvus Lite の制限は何ですか？ シングルプロセス動作のため、本番規模のスループットや高可用性には対応していません。あくまで検証・プロトタイピング専用と理解してください。

Q. 既存の Elasticsearch から移行できますか？ Zilliz Cloud の MilvusMigrationTool が Elasticsearch からの移行をサポートしています。ただし、全文検索の一部ユースケースは Milvus の BM25 レイヤーで代替できる一方、集計・ファセット検索などは別途検討が必要です。

Q. 日本語ドキュメントでもハイブリッド検索は有効ですか？ 有効ですが、BM25 のアナライザー設定で日本語対応のトークナイザーを指定する必要があります。BGE-M3 は日本語を含む多言語モデルとして実用的な精度を発揮するため、Dense + BGE-M3 Sparse の組み合わせが日本語 RAG のスタート地点として推奨されます。

まとめ — 明日から始めるための 3 ステップ

本記事の要点をおさらいします。

• ハイブリッド検索は 2026 年の RAG 標準パターン: Dense + Sparse + BM25 の 3 層を単一クエリで実行できる Milvus はその中心的な存在です
• Milvus は Lite → Distributed → Cloud まで同一コードで到達可能: 検証から本番まで API 互換性が保たれる設計は、長期的な技術投資として合理的です
• GPU（CAGRA）は「必要になったら足す」で良い: 先に機能を検証し、スケール要件が明確になった段階で GPU インフラを検討するのが現実的な進め方です

次のアクションとして、以下のステップを推奨します。

1. Milvus Lite をローカルに入れて自社データで試す — pip install pymilvus[model] で即日開始できます
2. Dense 単体とハイブリッドで検索品質を定量比較する — MRR や NDCG などの指標で改善幅を測定し、投資対効果を確認してください
3. スケール要件が見えた段階で Standalone / Distributed へ移行する — API 互換性が保たれるため、移行コストは最小限に抑えられます

段階的に理解を深めていきましょう。Milvus Lite での小さな実験から始めることが、本番品質の RAG システムへの最も確実な道筋です。

参考リンク

• Milvus GitHub リポジトリ
• Milvus 公式ドキュメント — Hybrid Search
• Zilliz Cloud — フルマネージド Milvus
• BGE-M3 モデル（HuggingFace）