検索の索引には調整できる数値がいくつもあります。適当に決めても動くので、既定値のまま使われがちです。
12通りを実際に測ったところ、同じ再現率100%でも、設定によって速さが1.8倍と6.8倍に分かれました。同じ結果を返すのに、3.8倍の差があります。
12通りを実際に測りました。再現率100%を満たす設定の中でも、速さは1.8倍から6.8倍まで開きます。
インデックスチューニングで何がどれだけ変わるのかを、組み合わせを変えながら測りました。用意したのは64次元のベクトル20,000件です。
索引の構築も検索も本当に実行しています。全探索の上位10件を正解として、再現率と1回あたりの時間を数えました。時間は実行のたびにぶれるので、桁と比で読んでください。
登録 20,000件（64次元）・上位10件・問い合わせ 200回 全探索 1回あたり 5415 マイクロ秒 組の数 見る組 再現率 走査件数 1回あたり 全探索比 16組 1組 86.7% 1,372件 411 μs 13.2倍 16組 4組 100.0% 4,624件 1325 μs 4.1倍 16組 8組 100.0% 9,638件 3057 μs 1.8倍 16組 16組 100.0% 20,000件 6891 μs 0.8倍 64組 1組 34.1% 319件 104 μs 52.2倍 64組 4組 88.2% 1,261件 419 μs 12.9倍 64組 8組 100.0% 2,484件 801 μs 6.8倍 64組 16組 100.0% 4,897件 1681 μs 3.2倍 256組 1組 15.8% 94件 66 μs 82.3倍 256組 4組 46.5% 373件 154 μs 35.2倍 256組 8組 70.6% 742件 270 μs 20.1倍 256組 16組 96.0% 1,405件 505 μs 10.7倍
再現率100%の行だけを拾ってください。16組・8組で1.8倍、64組・8組で6.8倍。同じ結果を返すのに、3.8倍の差があります。
再現率100%とは、全探索と同じ10件を返したという意味です。利用者から見れば、どの設定でも結果は同じになります。
違うのは走査した件数です。16組・8組では9,638件、64組・8組では2,484件。細かく分けてあるほど、同じ再現率を少ない走査で達成できます。
ここが調整の難しいところです。細かく分けるほど速い、とは言えません。256組に分けても、1組しか見なければ再現率15.8%です。
分ける数を増やしたら、見る組の数も一緒に増やす必要があります。片方だけ動かすと、速いだけで当たらない設定ができます。
測った範囲では、64組・8組が最良でした。再現率100%で6.8倍速です。256組は16組見ても96.0%止まりで、100%には届いていません。
ただしこれはこのデータでの結果です。塊の数や次元が変われば、最良の組み合わせも動きます。
細かく分けるほど、同じ再現率を少ない走査で出せる。
The index options also have a significant impact on build time (use the defaults unless seeing low recall)原文pgvector/pgvector README この内容の有効期限2027-02-18
索引を作るときの設定と、引くときの設定の2種類です。作るときの設定は後から変えにくい点が違います。
インデックスチューニングは、検索の索引に付いている数値を、再現率と速さの釣り合いで決める作業です。
調整する数値は2種類に分かれます。索引を作るときに決まるものと、引くときに毎回決められるものです。
前の節でいえば、組の数が前者、見る組の数が後者にあたります。前者を変えるには索引を作り直す必要があります。
作るときの設定には、検索の速さとは別の代償が付きます。pgvectorでも、値を大きくすれば再現率は上がるが、索引を作る時間と書き込みの速さを犠牲にするとされています。
つまり作るときの設定を上げると、検索は良くなってもデータを入れるたびの処理が重くなります。書き込みが多い用途では、ここが効いてきます。
同じ文書には、索引の設定は作る時間にも大きく影響するので、再現率が低くない限り既定値を使うという案内もあります。
これは妥当な出発点です。ただし再現率が低いかどうかは、測らなければ分かりません。測り方はANN再現率の記事で扱っています。
測ってみて実際的だったのは、引くときの設定から先に動かすことでした。索引を作り直さずに試せるので、往復が速く回ります。それで足りなければ、作るときの設定に手を付けます。
A higher value of ef_construction provides better recall at the cost of index build time / insert speed.原文pgvector/pgvector README この内容の有効期限2027-02-18
片方のつまみだけを動かすことです。速くはなりますが、当たらなくなったことに気づけません。
インデックスチューニングでいちばん多い失敗は、速さだけを見て調整することです。再現率を見ていなければ、速い設定はいくらでも作れます。
前の節の表で最も速いのは、256組・1組だけ見る設定です。82.3倍速。ところが再現率は15.8%です。
この設定でも検索は10件返ります。エラーも出ません。速くなったという事実だけが手元に残ります。
実際の製品でも注意が要ります。pgvectorでは、見る組の数は既定で1組だと明記されています。
つまり組を細かく分ける設定にしたまま既定値で引くと、前の節の15.8%に近い状態になりえます。作るときの設定を変えたら、引くときの設定も見直す必要があります。
4番目を避けてください。速い順に見ると、再現率を確かめる前に「これでいい」と決めてしまいます。
速い設定はいくらでも作れる。当たっているかは別に測る。
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る