ストーリー

コレクション設計

コレクション分割戦略

NetShop社の設計

コレクション設計:

netshop_knowledge（単一コレクション）
├── doc_type = "技術文書" でフィルタ
├── doc_type = "議事録" でフィルタ
└── doc_type = "FAQ" でフィルタ

理由:
- 38,000件は単一コレクションで十分な規模
- 横断検索のユースケースが多い
- メタデータフィルタでドキュメント種別を絞り込める

インデックス設計

HNSWパラメータ

パラメータ選定の目安:

データ件数: 〜100万件
├── m = 16, ef_construction = 128, ef = 128
├── 想定メモリ: ベクトル次元 × データ件数 × 4bytes × 1.5（オーバーヘッド）
└── 例: 1536次元 × 200,000チャンク × 4 × 1.5 ≒ 1.8GB

NetShop社の場合:
38,000件 × 平均5チャンク = 190,000チャンク
1536次元 × 190,000 × 4 × 1.5 ≒ 1.7GB → EC2 r6g.large（16GB RAM）で十分

距離メトリクスの選定

スキーマ設計

Qdrantのコレクション定義

コレクション設定:

{
  "collection_name": "netshop_knowledge",
  "vectors": {
    "size": 1536,           // text-embedding-3-small の次元数
    "distance": "Cosine"
  },
  "optimizers_config": {
    "indexing_threshold": 20000   // この件数を超えるとインデックスを最適化
  },
  "hnsw_config": {
    "m": 16,
    "ef_construct": 128
  }
}

ペイロード（メタデータ）のインデックス

メタデータインデックス設計:

フィルタに頻繁に使うフィールドにインデックスを作成:

1. doc_type（keyword）    → ドキュメント種別でのフィルタ
2. department（keyword）  → 部門でのフィルタ
3. updated_at（datetime） → 日付範囲でのフィルタ
4. tags（keyword[]）      → タグでのフィルタ
5. tech_stack（keyword[]）→ 技術スタックでのフィルタ

インデックスを作成しないフィールド:
- content（テキスト）     → 大きすぎるためインデックス不要
- summary（テキスト）     → 表示用、フィルタには使わない
- source_url（テキスト）  → フィルタには使わない

パフォーマンスチューニング

チューニングポイント

本番運用のベストプラクティス

「ベクトルDBは”設定して終わり”ではない。データ量の増加に伴ってパフォーマンス特性が変わる。定期的なチューニングレビューが必要だ」 — 田中VPoE

まとめ

チェックリスト

• コレクション分割戦略の判断基準を理解した
• HNSWパラメータの意味とトレードオフを理解した
• メタデータインデックスの設計原則を理解した
• パフォーマンスチューニングのポイントを理解した

次のステップへ

次は「ハイブリッド検索」を学びます。ベクトル検索とキーワード検索を組み合わせることで、検索精度を大幅に向上させる手法を理解しましょう。

推定読了時間: 30分