最初は、 https://github.com/blevesearch/bleve/releases 2.4 からvector serach が可能に backend は faiss っぽいなので、 kagome x blevesearch x ANN の構成で vector indexing, query のベクトル化もGo 言語かつ検索サーバーを運用しないで完結する構成による近似近傍探索をやろうと思っていた。。。が、文章をベクトル化するお手軽な方法(Python だとが Go で見つけられなかった。

同じモチベーションらしきGoライブラリ

今回の方法を模索してみた。

運用コストを低く抑えつつ全文検索機能を実現したい- SQLite3 で全文検索を実現する fts5 、ベクトル検索を実現する sqlite-vss でも書いたが、全文検索機能の運用は辛いことが多い。なので、

  • 検索対象のデータは頻繁に更新しなくても問題ない
    • ストリーミングでの更新(online indexing)はせずに、バッチ処理で完了
  • ドキュメント対象は大規模ではない
    • 状況にもよるが10万件以下が目安ではなかろうか

上記の条件では専用の全文検索サーバーを運用することなく実現できそうなアプローチがいろいろある。

実例では、APIサービスケンオールのアーキテクチャの内容がドンピシャだ

とうじこの取り組みを見たときに、なるほど! Online indexing が不要な状況もあるよな、頭いい!! と感動して Twitter で yomo さんと議論した思い出があります。

どうやら以前注目した asg017/sqlite-vss: A SQLite extension for efficient vector search, based on Faiss! のパッケージは問題を抱えていたらしく、それを解決するために同じ開発者によって asg017/sqlite-vec: Work-in-progress vector search SQLite extension that runs anywhere. が後継が作られたとのこと。

あと sqlite-vec からは WASMでも動くらしいので web サイト上で demo が動いていてすごい

I’m writing a new vector search SQLite Extension | Alex Garcia’s Blog

主要な改善点としては、

  • C++で書かれていたvss をCで書き直す
    • Mac, Linux だけだったのが、Linux, Mac, Windows とすべてのプラットフォームで省メモリで動く
  • faiss に依存していた近似近傍探索機能をスクラッチで実装している

だが、現状フルスキャンでの近傍探索であり、近似近傍探索ではない。 なん。。。だと。。。 将来的には近似近傍探索をサポートしたいらしいが、ドキュメント総数によってはそもそもフルスキャンしても問題ない規模が大半だろうし、 SQLite 内で完結して近傍探索できるだけでも嬉しいというケースはあるっちゃありそうではある?

ラズパイとか?ドキュメント全部メモリに載せても問題ない規模など

> Though initially, `sqlite-vec` will only support exhaustive full-scan vector search. There will be no "approximate nearest neighbors" (ANN) options. But I hope to add IVF + HNSW in the future!
 
> sqlite-vssの開発と採用には、次のような多くの障害がありました。
Linux + MacOSマシンでのみ機能しました(Windows、WASM、モバイルデバイスなどはなし)  
- すべてのベクトルをメモリ内に格納  
- トランザクション関連のさまざまなバグと問題  
- コンパイルが非常に難しく、時間がかかる  
- 一般的なベクトル演算がない(スカラー/バイナリ量子化)  
>これらはほとんどすべて、sqlite-vssがFaissに依存していたためです。 多くの時間とエネルギーがあれば、これらの問題のいくつかは解決できるかもしれませんが、その多くはFaissによってブロックされます。 translate by gemini1.5 Pro

Vector search in 7 different programming languages using SQL | Alex Garcia’s Blog で書かれていたサンプルコードを基に、手元のデータを対象にして実際にコードを書こうと思ってたんだが、ANNではなく、NNならやる意義もなさそうなので、ここで完!!

Yuichi Tateno (舘野 祐一) secondlife さんフィードバック at Discord

昨日はちょいと体調悪めで参加できませんでした、残念・・・! 記事面白いですね〜、最後のsqlite-vec の独自実装探索がANNじゃないというオチも! 計算機リソースにもよりますが、ドキュメント数が数千ぐらいなら全部探索しても現実的な速度なのかなーと思うので、たとえばライブラリのドキュメントやブログ記事といった限られたユースケースにピッタリマッチする場合もありそうですね〜