Vector DBの会社で2年間働いて学んだこと

ベクターDBであるWeaviateで働きながら、実運用の経験から得た37の教訓を整理
↳ BM25、キーワード検索の有用性からベクター検索・埋め込み・ハイブリッド検索まで

1. BM25は検索における強力なベースライン

• 複雑なベクター検索よりも、まずはBM25などのシンプルなキーワード検索を適用して性能を確認し、その後段階的にベクター検索へ拡張するのが実践的

2. ベクター検索は近似的(Approximate)であり、正確(Exact)ではない

• 大規模データでは近傍探索(ANN)アルゴリズム(HNSW, IVF, ScaNN など)を使用して速度を高めるが、精度の一部を妥協する
• ベクターインデキシングは、ベクターDBの大規模な速度を保証する中核

3. ベクターDBは埋め込みだけを保存するわけではない

• 元データ(テキストなど)とメタデータも一緒に保存し、メタデータフィルタリング、キーワード検索、ハイブリッド検索などが可能

4. ベクターDBの主用途は生成AIではなく「検索」

• LLMにcontextを入れることも本質的には「検索」であり、ベクターDBとLLMは非常に相性のよい組み合わせ

5. 検索結果の件数は明示的に指定する必要がある

• limit または top_k パラメータを指定しないと、クエリに最も近いすべての結果がソートされて返される

6. 埋め込みの種類は多様

• Dense(密)ベクトルのほかにも、sparse(疎)、binary(二値)、multi-vector など多様な埋め込みベクトル形式が存在する

7. 埋め込みモデル選択のためのベンチマーク

• MTEB はさまざまな埋め込みタスク(分類、クラスタリング、検索など)を網羅
• 情報検索に特化したベンチマークは BEIR を参照

8. MTEBの大半のモデルは英語専用

• 多言語/非英語環境なら MMTEB ベンチマークの活用がおすすめ

9. 埋め込みの歴史: Static vs Contextual

• Word2Vec、GloVe などの静的埋め込みは単語ごとの固定表現
• BERT などのコンテキスト埋め込みは文脈に応じて動的にベクトルを生成
• 静的埋め込みはリソース制約のある環境で高速に参照できる

10. Sparse vectorとsparse embeddingの違い

• sparse vector: TF-IDF/BM25 などの統計ベース、またはニューラルネットベース(sparse embedding、SPLADE など)で生成
• すべての sparse embedding は sparse vector だが、その逆ではない

11. テキスト以外のさまざまなデータも埋め込み可能

• 画像、PDF(画像変換)、グラフなども埋め込んでマルチモーダルなベクター検索が可能

12. 埋め込みの次元数と保存コスト

• 次元数が増えるとストレージコストも増加
• 「チャットボット用」などの簡単な用途では高次元モデルが不要なこともある
• Matryoshka Representation Learning により低次元化も可能

13. “Chat with your docs” チュートリアルは生成AIのHello World

14. 埋め込みモデルは繰り返し呼び出す必要がある

• 文書取り込み(ingestion)時だけでなく、クエリ時、文書追加/修正時、埋め込みモデル変更時のたびに埋め込み・インデキシングが必要

15. ベクター類似度と実質的なrelevanceは異なることがある

• 類似した文(例: 「蛇口の直し方」vs「蛇口の購入先」)でも、実質的な関連性は低い場合がある

16. Cosine similarityとcosine distanceは異なる

• 類似度と距離は数学的に反比例の関係
• 同じベクトルなら類似度は1、距離は0

17. ベクトルを正規化するとcosine similarityとdot productは同一

• 正規化されたベクトルなら、計算上は dot product のほうが効率的

18. RAGのRは「vector search」ではなく「retrieval」

• RAGにおける retrieval の方法は多様(キーワード、ベクター、フィルタなど)

19. ベクター検索は検索ツールの一つにすぎない

• キーワード検索、フィルタリング、リランキングなどさまざまな方法との組み合わせ(ハイブリッド) が重要

20. キーワード/ベクター検索の適切な使い分け

• 意味的/同義語マッチングはベクター検索、正確なキーワードはキーワード検索、両方必要な場合はハイブリッド検索と alpha 重み調整を活用

21. ハイブリッド検索の意味

• 通常はキーワード+ベクターの組み合わせを指すが、メタデータなど他の検索方式との組み合わせもすべて「ハイブリッド」と呼ぶ

22. フィルタリングが常に速度を上げるとは限らない

• たとえば HNSW グラフの connectivity が壊れる可能性があり、事後フィルタリングでは結果がなくなることもある
• これに対する最適化手法はベクターDBごとに異なる

23. 2段階検索パイプラインの有用性

• 推薦システムだけでなく、RAG などでも1次候補群を抽出した後、2次の高性能リランキングで品質改善が可能

24. ベクター検索とリランキングの違い

• ベクター検索はDB全体から一部の結果を返し、リランキングは受け取った結果集合の順序を並べ替える

25. 埋め込むchunkサイズの選定は難しい

• 小さすぎるとコンテキストを失い、大きすぎると意味が薄まる
• mean pooling などで文書全体をベクトル化することもできるが、情報が希釈されることがある(すべての映画フレームを合成したポスターのたとえ)

26. ベクターインデキシングライブラリとベクターDBの違い

• どちらも高速だが、ベクターDBは耐久性、CRUD、フィルタ/ハイブリッドなどのデータ管理機能まで提供する

27. LLMのcontext拡張が進んでもRAGは進化し続ける

• 長いコンテキストのLLMが登場するたびに「RAGは死んだ」と議論されるが、実際には引き続き必要

28. ベクトル量子化で情報を97%削減しても検索は維持できる

• binary quantization などを使えば、ストレージを32分の1に削減可能(32-bit float→1-bit など)

29. ベクター検索はtypoにrobustではない

• 大規模テキストコーパスでも、すべてのtypoが反映されるわけではなく、一部の誤字しかカバーしない

30. 検索品質の評価指標は多様

• NDCG@k などのランキングベース指標のほか、Precision/Recall などのシンプルな指標も状況に応じて有効

31. Precision-Recall trade-off の実践例

• 結果を1件だけ返す(Precision ↑/Recall ↓)、全結果を返す(Recall ↑/Precision ↓) など、極端な事例で説明

32. 検索結果の順序を反映する指標

• Precision/Recall は順序を反映しないため、MRR@k, MAP@k, NDCG@k など順序考慮の指標が必要

33. トークナイザーの影響力

• BPE だけでなく、キーワード/ハイブリッド検索の品質にもトークナイザーが影響する

34. Out-of-domainとout-of-vocabularyは異なる

• OOV はスマートなトークナイザーで解決できるが、out-of-domain では埋め込み自体に意味がない

35. クエリ最適化の必要性

• キーワード検索と同様に、ベクター検索でもクエリ入力を最適化する習慣が必要

36. ベクター検索以後のパラダイム

• キーワード検索 → ベクター検索 → LLM reasoning ベースのリトリーバルへと進化

37. 情報検索(リトリーバル)は今もっとも「ホット」な分野

• LLMとともに、LLMに提供する「最適な情報」を見つけることが、最も中核的で重要な課題

[mhj5730]

ベクトル検索を扱いながらいろいろ考えてみた内容が多くて、いいですね。