この記事で分かること／分からないこと
- 分かること: 埋め込みを作り直さずに済ませる(差分判定・再利用)という考え方の整理
- 分かること: 差分判定が効きやすい条件と効きにくい条件
- 分かること: 自社の索引構造がこの考え方をどう反映しているか
- 分からないこと: 差分判定によって実際にどれだけ計算量や費用が減るかの実測値
- 分からないこと: チャンク分割の粒度をどこまで細かくすべきかの推奨値
埋め込みの作り直しが費用になる理由
RAGでは、対象文書をチャンクに分け、それぞれを埋め込みベクトルに変換して検索用の索引に格納する。対象文書が更新されるたびに全件を作り直せば、変わっていない大多数のチャンクまで毎回計算することになり、更新のたびに計算量が文書の総量に比例して発生する。埋め込みを作り直さずに済ませるとは、この「変わっていない部分まで毎回計算し直す」構造を避ける発想である。
差分判定という考え方
自社の索引構成では、原本とは別に比較用のchecksumを軽量な領域に持たせ、原本を毎回読みに行かなくても変更の有無を判定できるようにしている(出所: docs/STORAGE_AND_BILLING.md)。checksumが変わっていないチャンクは再計算対象から外し、変わった部分だけを作り直すことで、更新のたびに全件を作り直す構成を避けられる。ビルド時処理を「差分再生成」と呼ぶのもこの考え方に基づく。ただし本記事の時点で、差分判定によって計算量や費用がどれだけ減ったかの実測値は無い。
差分判定が効きやすい条件
対象文書の大部分が変わらず、一部だけが追加・更新される(追記型に近い)運用では効果が出やすい。checksumの判定粒度が文書全体ではなくチャンク単位まで細かければ、変更箇所以外を除外できる範囲が広がる。更新頻度が低い対象ほど、一度作った埋め込みを長く使い回せる。
差分判定が効きにくい条件
チャンクの分割方法(サイズや区切り方)自体を変更した場合は既存の埋め込みとの対応関係が崩れ、文書が変わっていなくても実質的に作り直しが必要になる。埋め込みモデルをバージョンアップした場合も、旧モデルの埋め込みベクトルは新モデルの出力空間と一致せず全件の再計算が避けられない。文書全体を1単位としてしか変更検知できない構成では、一部分の修正でも全体を作り直す対象になり、効果は薄くなる。
よくある質問
Q1. 埋め込みを作り直さずに済ませるとは、具体的に何をすることか
対象文書のうち変更されていない部分の埋め込みは再利用し、変更された部分だけを再計算することを指す。全件を毎回作り直す構成と対比される考え方である。
Q2. 差分判定はどのように行うのか
自社の構成では、原本とは別に比較用のchecksumを軽量な領域に持たせ、それを見て変更の有無を判定している。checksumが一致すれば埋め込みの再計算をスキップできる。
Q3. 差分判定が効きにくいのはどんな場合か
チャンクの分割方法を変更した場合や、埋め込みモデル自体をバージョンアップした場合は、既存の埋め込みとの対応関係が崩れるため全件の再計算が避けられない。
Q4. 差分判定によってどれだけ費用が減るのか
この記事の時点で実測値は無い。効果の大きさは対象文書の更新頻度やチャンクの粒度に依存するため、条件を明記した上で個別に確認する必要がある。
埋め込みと同じくビルド時の工夫に位置づけられる確定配信については確定配信という選択の記事、繰り返しの質問に対する別のアプローチであるキャッシュについてはキャッシュが効く条件の記事で扱っている。まとめて処理できる作業の切り分けはバッチで処理できる仕事とできない仕事の記事を参照してほしい。RAGの運用コスト設計について相談したい方は、お問い合わせから編集部までご連絡いただきたい。
- ハブ記事: RAGサービス比較15選
- 関連記事: RAGのレイテンシ計測
- 関連記事: 用途ごとにモデルを切り替える判断
- 関連記事: バッチで処理できる仕事とできない仕事