Qdrant：RAGのベクトルデータベース ローカル

#ベクトルデータベースは何に役立つのか

埋め込みモデルは、テキストを数値のリスト、すなわちベクトルに変換します。意味が近い2つのテキストは、近い2つのベクトルを生成します。質問に関連する文章を検索することは、質問のベクトルに最も近いベクトルを探すことに相当します。1,000件の文章であれば、全体に対する単純な計算で十分です。100万件になると、インデックス構造が必要になります。ベクトルデータベースの役割は、この構造を構築・維持し、ベクトルを1つずつ比較するのではなく、数ミリ秒で応答し、コーパスに新しいドキュメントが追加され続ける間も正確性を保つことです。

このステップが、その後のすべてを左右します。優れたモデルでも、適切でない文章の抜粋を受け取れば回答の質は下がり、検索の不備はどのようなプロンプトの指示でも補えません。そのため、長い間、交換可能なインフラの一要素として扱われてきたベクトルデータベースの選定にも、言語モデルそのものの選定と同じだけの注意を払う必要があります。

#Qdrantが提供する機能

このプロジェクトは、自らを「高性能で大規模に対応する」検索エンジン兼ベクトルデータベースと説明しており、幅広いフィルタリングに適した設計になっています。この点で、条件を付けずに最近傍を検索するだけのライブラリとは異なります。Rust で書かれており、開発者らは、それが高速性と高負荷時の信頼性を支える理由だと説明しています。運用上の堅牢性については、更新の確認応答が返されたデータの永続性を、停電時にも保証する先行書き込みログ（write-ahead logging）が文書化されています。また、本番環境のデプロイを監視し、デバッグするためのメトリクス、テレメトリ、監査ログについても記載されています。

独立して動作するサーバー

コンテナ、HTTPおよびgRPCのAPI、Python、Go、Rust、JavaScript/TypeScript、.NET、Javaの公式クライアントを備えています。アプリケーションとは独立して動作するため、アプリケーションを再起動しても、構築済みのインデックスが失われることはありません。

ペイロードによるフィルタリング

各ベクトルには、著者、日付、部署、文書の種類といったメタデータが付いています。should、must、must_notの条件句を使い、検索後ではなく検索中にこれらのメタデータで絞り込みます。ここが、企業で実用になる検索と単なるデモの違いです。

ベクトルの量子化

ベクトルを圧縮することで、メモリ使用量を大きく削減（スカラーで4倍、バイナリで最大32倍）できます。ただし、制御可能な精度の損失が生じ、それらは補償可能です。

スパースベクトルおよびマルチベクトル

従来の密ベクトルに加え、Qdrantは全文検索用のスパースベクトルと、複数の埋め込みを持つオブジェクトに対応しています。後者は、ColBERTのような遅延相互作用型モデルに役立ちます。

ハイブリッド検索

意味理解とキーワードによる精度の両方を利用するために、1つのクエリに複数のベクトルを組み合わせ、相互ランク融合（RRF）や分布によるスコア融合（DBSF）などの設定可能な戦略で結果を融合します。

スナップショットと復元

コレクションをバックアップし、別の場所で復元すること。再インデックス化にGPUで数時間かかるようになったときに、これが重要になります。

分散デプロイメント

シャーディングとレプリケーションによりコレクションを複数のノードに分散し、サービス中断なしでリサイズ可能。厳密にローカル用途を超えた場合に有用ですが、単一のマシンでは不足するようになった際にゼロから再構築せずにプロジェクトを拡大できることを知っておく価値があります。

#ローカルで起動する

最も手軽なのは公式コンテナを使い、再起動後もデータが保持されるようにボリュームを設定する方法です。組み込みのWebインターフェースは、プロジェクトが「データを視覚的に操作し、デプロイ環境の健全性を監視する手段」と説明しているもので、コードを1行も書かずにコレクションの探索、データの管理、REST APIへの問い合わせができます。回答の内容に問題があるときには、これが最適な診断ツールです。検索コードを読み直して推測するのではなく、実際に取得された内容を確認できます。

docker run -p 6333:6333 -p 6334:6334 \
  -v "$(pwd)/qdrant_storage:/qdrant/storage" \
  qdrant/qdrant

Pythonクライアントは、サーバーをまったく使わずに動作させることもできます。使い捨てのテストにはQdrantClient(":memory:")、永続的なローカルストレージにはQdrantClient(path="chemin/vers/db")を使います。プロトタイプや自動テストに便利で、接続設定の1行を変更するだけで、同じコードからサーバーを利用できるようになります。このプロジェクトは2026年から、もう一つの組み込み方法としてQdrant Edgeも文書化しています。これはリソースが限られたデバイス向けの軽量版で、クライアント・サーバー構成ではなく、アプリケーションのプロセス内で直接実行されます。フル機能のQdrantサーバーとの同期も可能です。

#Pythonの最小限のコード

1. 01
   接続する

   from qdrant_client import QdrantClientでインポートし、続いてclient = QdrantClient(url="http://localhost:6333")で、上で起動したコンテナを接続先に指定します。
2. 02
   コレクションを作成

   client.create_collection(collection_name="docs", vectors_config=VectorParams(size=1024, distance=Distance.COSINE)) — サイズは、embeddingモデルの次元と正確に一致する必要があります。
3. 03
   ポイントを挿入する

   client.upsert(collection_name="docs", points=[PointStruct(id=1, vector=[...], payload={"service": "support"})]) は、各ベクトルに識別子とフィルタ可能メタデータを付与します。
4. 04
   問い合わせる

   client.query_points(collection_name="docs", query=vecteur_question, limit=5).points は、最も近い5つのパッセージをスコアとペイロード付きで返します。

#メタデータによるフィルタリング：軽視したことを後悔する機能

実際の利用では、コーパス全体を対象に質問することはほとんどありません。特定の部署の文書、特定の日付より後の文書、特定の種類の文書、あるいは質問したユーザーがアクセスできる文書を検索します。Qdrantはベクトル検索中にこれらの条件を適用します。キーワード一致、全文検索、数値範囲、地理的位置などの豊富なフィルター条件を、should、must、must_notという論理句で組み合わせられます。そのため、検索後にフィルタリングすると結果が何も残らない場合でも、常に適切な件数の関連する結果を得られます。

アクセス制御は、別途取り上げるべき重要な点です。複数の人が同じインデックスに問い合わせる場合、権限フィルターによって、閲覧権限のない文書をモデルがその人に引用して示すことを防ぎます。プロンプトの指示でこのフィルターを代替することはできません。また、アプリケーションコードではなくデータベース側にフィルターを実装すれば、同じコレクションへの新しいアクセスポイントでフィルターの再適用を忘れる事態を防げます。

#メモリに収める：ベクトルの量子化

文書化されている方法は、圧縮されたベクトルで検索し、その後、上位候補を元のベクトルで再評価（rescoring）して並べ替えるというものです。Qdrantには、このトレードオフを調整するためのオーバーサンプリング（oversampling）パラメータがあります。これを2.4に設定し、結果の上限を100件にすると、最終的な並べ替えの前に、量子化されたインデックスで240件の候補が選ばれます。メモリ使用量を4分の1以下に抑えながら、精度の大部分を維持できます。モデルも動かしているマシンでは、これはぜいたくではなく、必要な工夫です。公式ドキュメントでは、バイナリ量子化によって元のベクトルと比べて最大40倍の高速化が可能とされていますが、この数値を当然のものとして受け入れるのではなく、自分のデータセットで検証すべきです。また、プロジェクト側は、これらの圧縮オプションをディスク上の保存と組み合わせることで、メモリ使用量を最大97%削減できるとしています。この削減規模を見れば、量子化が細かな設定ではなく、中核的な機能として位置付けられている理由が分かります。

#Qdrantまたはその他の選択肢

考えるべきなのは「最も優れたベクトルデータベースはどれか」ではなく、「今、自分のプロジェクトに何が必要か」です。テストスクリプトなら、メモリ上で動作するライブラリだけで十分です。すでにPostgreSQLに問い合わせを行っている業務アプリケーションなら、サービスをもう1つ追加するより、PostgreSQLにベクトル拡張を追加するほうが得策です。Qdrantが適切な選択になるのは、次のような要件が複数重なる場合です。複数のアプリケーションでサービスを共有すること、メタデータによる細かなフィルタリング、増え続けるコーパスへの対応、そして永続化やスナップショットの仕組みを自分で実装し直したくないという希望です。最初のプロトタイプの段階で選択を固定せず、定期的に見直すことで、小規模なプロジェクトを過剰に複雑な構成にすることも、成長したプロジェクトに対して構成の規模が不足することも避けられます。

• データの取り込みから回答までを網羅するローカルRAG
• フランス語向けの埋め込みモデルを選択
• rerankerを追加して検索の関連性を向上させる
• pgvector：PostgreSQLだけで十分な場合
• QuelLLMのローカルRAGキット
• 出典：GitHub上のQdrant公式リポジトリ
• 出典：量子化に関する公式ドキュメント
• 出典：QdrantのPythonクイックスタート

#FAQ