この記事で分かること／分からないこと
- 分かること: 追記・上書き・削除が索引に与える影響が、索引の種類によってどう違うか(公式ドキュメントで確認できた範囲)
- 分かること: 更新の多いデータで「作り直し」が運用の律速になる理由
- 分からないこと: 自社のデータで、どの頻度なら追記で済み、どこから作り直しが要るか(件数と索引パラメータに依存する)
- 分からないこと: 各サービスの内部の再構築タイミングの細部(公開されている範囲でしか書いていない)
編集部の自社RAG基盤は、根拠データの差分判定にchecksumを使い、変わった分だけ再生成する構成である(出所: /home/sol/convai-platform/docs/STORAGE_AND_BILLING.md、確認日2026-09-06)。ただしこれはベクトルDBの索引更新ではなく、確定配信用の索引の再生成の話であり、本稿で扱うベクトル索引の更新とは仕組みが異なる。ベクトルDBについては自社の実測を持っていない。
上書き(upsert)は追記より扱いが単純に見えて、索引側の負担は別
主要なベクトルDBは、同じIDのレコードを再投入すると上書きになる upsert の操作を提供している。Pineconeの公式ドキュメントには「Upsert records」として、密ベクトル・疎ベクトル・バッチでの upsert の手順がまとまっている(出所: https://docs.pinecone.io/guides/index-data/upsert-data 、確認日2026-09-06)。
アプリケーション側から見れば「同じIDで投げ直せば更新できる」で済むが、索引側では古いベクトルの扱いが残る。この点は次の pgvector の記述が分かりやすい。
更新が残す「死んだ行」が検索結果の件数を減らす
pgvectorのREADMEは、HNSW索引で取得できる結果の件数が ef_search(既定値40)に制限されること、そして死んだタプル(dead tuples)やクエリの絞り込み条件によって、結果がさらに少なくなりうることを明記している。対策として、必要に応じて索引を追加で走査する iterative index scans を有効にすることを挙げている(出所: https://raw.githubusercontent.com/pgvector/pgvector/master/README.md 、確認日2026-09-06)。
ここで重要なのは、更新や削除で残った死んだ行が、性能ではなく「返ってくる件数」に影響するという点である。更新の多いデータで「上位10件を頼んだのに7件しか返らない」という症状が出たら、索引の劣化ではなく死んだ行の蓄積を疑う必要がある。
索引の種類で、更新への強さが違う
同じREADMEは、IVFFlat索引について、リストに分割してその一部を探す方式であるため構築が速いこと、そして良い再現率を得るための鍵として、リスト数の設定と、探索するリスト数(probes)の設定を挙げている(同上)。IVFFlatは投入済みのデータを元にリストの中心を決めるため、データの分布が大きく変わる更新が続くと、リストの切り方が実態と合わなくなる。この場合は索引の作り直しが要る。
一方HNSWは構築が遅くメモリを多く使う代わりに、投入順に依存しにくい(同上の性質から)。更新が多くて作り直しを避けたいならHNSW、作り直しても構わないほど更新が少ないならIVFFlat、という分かれ方になる。件数の観点は規模で何が変わるかで扱った。
索引の設定は「全体で1つ」であることが多い
Qdrantの索引に関するドキュメントは、セグメントはそれぞれ独立して存在するが、索引自体のパラメータはコレクション全体に対して設定される、と述べている(出所: https://qdrant.tech/documentation/concepts/indexing/ 、確認日2026-09-06)。
これが更新頻度と関係するのは、「更新の多い部分と少ない部分で索引の設定を変えたい」という要求が通らない場合があるからである。更新の性質が異なるデータを1つのコレクションに入れると、どちらかに合わせた設定にならざるを得ない。更新の多いデータと少ないデータを分けて持つかどうかは、マルチテナントの分け方と同じ判断になる。
更新頻度から決めるときの順序
公式ドキュメントで確認できた範囲から、判断の順序は次のようになる。まず、更新が「追記だけ」か「上書き・削除を含む」かを分ける。追記だけなら索引の劣化は起きにくい。上書き・削除を含むなら、死んだ行の蓄積と、それが結果件数に与える影響を監視項目に入れる。次に、データの分布が変わる更新かどうかを見る。分布が変わるならIVFFlat系は作り直しが前提になる。最後に、更新の性質が違うデータを1つにまとめてよいかを判断する。
いずれも、どの頻度でどうなるかは自社のデータで測る必要がある。
よくある質問
Q1. 同じIDで投げ直せば更新できるのか
Pineconeなど主要なベクトルDBは upsert を提供しており、アプリケーション側からは同じIDで再投入すれば上書きになる。ただし索引側では古いデータの扱いが残る。pgvectorのREADMEが述べるように、死んだ行は検索結果の件数に影響しうる。
Q2. 更新が多いと検索が遅くなるのか
公式ドキュメントで確認できた範囲では、遅くなるより先に「返ってくる件数が減る」症状が出る。pgvectorは ef_search の既定値40に対して、死んだ行や絞り込み条件で結果がさらに減りうると明記し、iterative index scans を対策として挙げている。
Q3. 索引はどのくらいの頻度で作り直すべきか
一般化できない。IVFFlatはデータ分布に依存するため、分布が変わる更新が続くと作り直しが要る。HNSWは構築が遅い代わりに投入順に依存しにくい。頻度は自社のデータの更新の性質と件数で決まる。
Q4. 自社ではどう更新しているのか
編集部の自社RAG基盤は、根拠データの差分をchecksumで判定し、変わった分だけ再生成する構成である。ただしこれは確定配信用の索引の話で、ベクトル索引の更新ではない。ベクトルDBの更新運用について自社の実測は持っていない。
更新頻度は、選定の段階で見落とされやすく、運用に入ってから効いてくる。自社の更新パターンでどう構成すべきか相談したい方は、お問い合わせから編集部までご連絡いただきたい。
- ハブ記事: RAGサービス比較15選
- 関連記事: RAGのレイテンシをどこで測るか
- 関連記事: メタデータ絞り込みが要るか
- 関連記事: マルチテナントの分け方
- 関連記事: そもそもベクトルDBが要らない場合