2024-09ベクトル検索の改善
2024-09-23
kennさんの投稿を参考にして更新する
kenn 大掃除ついでに、ベクター検索DB @qdrant_engineの保存方法も大幅に見直し。ディスク使用量もメモリ使用量も1/10になった！ 次元数は1536 → 3072へと倍増したのだが、新モデルはマトリョーシカ方式で自由に次元数を減らすことができ、256まで減らしてもada超えの性能。
体感的にも多様体空間の利用効率が高まってる感覚はあり、これでサイズが1/6に。
マトリョーシカとは？
koheiichi マトリョシカ法は埋め込みベクトルを作る際、ベクトルの一部が元の入力全体を粗視化した情報を表現するようにすることでベクトルの長さを変えても(一部の成分をカットしても)表現が保たれるようにする手法。 新しいOpenAIの埋め込みモデルのベクトル長が可変なため、マトリョシカ法が使われているのでは？と予想されている。
https://gyazo.com/147cfea34aa4fde52f327bccc8fa5dab
kenn 次に、Qdrantのcollectionは1つ1つのオーバーヘッドが大きい（10MB程度？）ので、保存ベクター数が少ないと非効率になる。 同じ次元数とpayloadスキーマのベクターは全部1個のcollectionにまとめ、payload indexでテナントを分離してやると一気に空間効率が改善。
https://gyazo.com/d1be87420bddb38dc6c923199062b9df
kenn さらに、1536 → 256へと次元数が減ると、通信するJSONのサイズ（floatの1個あたり12文字として1000次元のベクトルあたり12KB）も劇的に減ります。高圧縮最強。 最終設定はこちらで共有しています。現時点ではコスパと性能の両面でベストだと思うので、ご参考までに！
>kenn Here's a config template for @qdrant_engine for the multi-tenant setup: - Create a single collection to store everything with the same vector dimensions, and filter by tenant ID at query time
- mmap() as many things as possible on disk to optimize memory usage
- defrag storage
https://pbs.twimg.com/media/GVUAUSwbAAAbOmU?format=jpg&name=medium#.png
ベクトルのサイズが1/6になるから、1つの文章から5つの派生形を作って積んでもコストが変わらない(ほんとか？)
今は一通りのチャンク化で載せることしかできない実装になってるから、まずは試行錯誤がやりやすい形にしたいな