Hacker Newsが注目したACORN-1とRaBitQによるDuckDB vector search改善

Hacker Newsでは、非常に実務的な vector search の問題に切り込む DuckDBのcommunity extension project が取り上げられた。それは、HNSW index が候補を選んだ後にデータベースが WHERE 句を適用すると、有用性が落ちてしまう filtered nearest-neighbor query だ。リンク先の GitHub repository は duckdb-vss の fork で、SQL-native retrieval では graph traversal の後ではなく、その途中で filter を尊重する必要があると主張している。

この extension は ACORN-1 filtered search を追加し、predicate を HNSW traversal に押し込む。平たく言えば、「top 10 vectors inside category X」のような query が、件数の足りない歪んだ結果ではなく、その subset 内で本当の top 10 を返せるようになるということだ。README では selectivity strategy も説明されている。高 selectivity の query は標準の HNSW に残し、中程度の selectivity の query では ACORN-1 の two-hop expansion を使い、極端に選択性が高い query では brute-force exact scan にフォールバックする。この切り替えが production retrieval pipeline で重要なのは、filter が vector distance と同じくらい重要なことが多いからだ。

次の追加は RaBitQ quantization だ。プロジェクトは、index が vector を 1 bit per dimension で保存し、その後、最終ランキングのために元の F32 vector で候補を rescoring できると述べている。報告されている memory savings は、128 dimensions でおよそ 21x、768 dimensions で 30x に及び、benchmark table では oversampling と rescoring を有効にしたときの recall 改善が示されている。ユーザーがそれらの数値を中立的な評価ではなく repository benchmark として受け取るにしても、方向性は明確だ。すべてを専用の vector store にエクスポートするのではなく、vector compression と filtered search を analytical database の中へ持ち込むということだ。

Hacker Newsが注目したのは、これが retrieval-augmented system をシンプルなまま保てるか、それとも複数のインフラ層へ分裂させるかを左右する、まさにそうした plumbing だからだ。この project にはなお、RAM-resident index、FLOAT-only array、そして sequential scan にフォールバックする一部の query shape といった制約があるが、すでに多くの RAG team が直面した痛点を狙っている。

要点

• ACORN-1 は filter を HNSW traversal に押し込み、filtered query が上限件数どおりの結果を返せるようにする。
• RaBitQ は exact-distance rescoring を伴う強力な vector compression を追加する。
• この project は filter selectivity に応じて異なる search strategy を使い分ける。
• retrieval workload を DuckDB と SQL の内部に留めるべきだという根拠を強める。