エンベディングは総当たりで処理する

2000年代に組み込みCコードを書いていた頃、Raymond Chenが何気なく書いた「私のO(n)アルゴリズムはあなたのO(log n)アルゴリズムに勝る。学校で学んだことの多くがなぜ役に立たないのか」という言葉に私たちは飛びつきました。 ソートアルゴリズムには真実です。ベクトル検索にも真実です。 人々はベクトルデータベースが必要だと考えていますが、多くの場合、検索対象のドキュメントは100万件程度です。Numpyはfloat32の配列を非常に高速に総当たり検索できます。 Index Size Client Threads QPS Avg Latency 1000000 1 79.7 0.012s 1000000 10 170.5 0.058s 8841823 1 9.34 0.106s 8841823 10 18.34 0.106s これは文字通り、私のM4 MBPで実行されている384次元エンベディングに対する、このPythonコードの1行です。 # Dot product against all scores = self.doc_vectors @ query_vector.astype(np.float32, copy=False) 私は、ベクトルデータベースの複雑さを必要としない多くのチームと仕事をしています。彼らは約100万件のドキュメントを検索します。クエリトラフィックは少なく、エンベディングはすべて事前に書き込まれています。彼らは数百万ドルするベクトルデータベースを購入したり、それを操作するために6ヶ月を費やしたりする必要はありません。 nが十分に低い場合は、耐えられなくなるまでエンベディングを総当たりで処理してください。同僚の検索旅行者であるJo Kristian Bergumが言うように、「網羅的な検索がすべて必要なものかもしれない」のです。それを少し超えたら、データベースのことを考えてもいいかもしれません？あるいは、すべてをメモリにロードしてFAISSなどで済ませることもできます。 脚注として、これは単純なNumpy操作であり、おそらくもっと速くできるでしょう。Andreas Ericksonが言うように、スレッドがスキャン中に複数のクエリを受け取ることで、スループットを向上させることができます。そして、Numpyが行うことよりも、トップnヒープに収集するために検索中にさらに多くのことを行うことができます。 今後のイベント：ベクターウィーク ベクター検索、ハイブリッド検索、独自のベクターデータベースの構築に関する一連のイベントであるベクターウィークにぜひご参加ください。 Doug Turnbull Dougからのその他の情報 Twitter | LinkedIn | Newsletter | Bsky