RAGの予算を壊すのは、初期費用ではありません。「まず動くものを作って、あとで足そう」と考えた部分です。

そして厄介なことに、あとで足せるものと足せないものがあります。足せないほうを後回しにすると、作り直しになります。この記事では、その代表的な2つを書きます。費用の内訳はこちら、見積もりが当たらない理由はこちらにまとめました。

① 権限設計は、後から足せません

社内RAGで最初に飛ばされがちなのが権限です。「まず全社の文書で動かして、権限は次のフェーズで」という進め方をよく見ます。

これはほぼ確実に作り直しになります。

なぜ作り直しになるのか

権限は文書単位ではなく、チャンク単位で必要になるからです。

長い文書は分割してベクトル化します。このとき、1つの文書の中に権限の違う情報が同居していることがあります。

正しくやるには、権限が変わるところで分割の仕方そのものを変える必要があります。そして分割を変えれば、当然すべて再ベクトル化です。

その間、システムは使えません。本番稼働後にこれをやるのが、いちばん高くつきます。

設計の順番は決まっています

権限モデル → チャンク設計 → インデックス → 検索
この順番でしか作れない。

逆順にすると、後ろから前に戻ることになります。最初のスプリントで権限モデルだけは決めてください。これが、この記事でいちばん伝えたいことです。

② 埋め込みモデルを差し替える日は、必ず来ます

もうひとつが再インデックスです。こちらはいつか必ず発生するという性質のものです。

• より精度の高い日本語モデルが出た
• コストの安いものに寄せたい
• 次元数を落としてストレージを減らしたい

理由は何であれ、モデルを変えるということは、全チャンクを計算し直すということです。次元数が変われば保存する形も変わるので、既存のデータはそのまま使えません。

素直にやると、途中の検索結果が壊れます

既存のベクトルを上書きしながら変換すると、変換中は新旧のベクトルが混ざった状態になります。

この状態の検索結果には意味がありません。距離の尺度が違うものを、一列に並べて順位を付けているからです。

並存させて切り替えれば、止まりません

正しい手順はこうです。

1. 新しい置き場所を作る（既存のベクトルはそのまま残す）
2. 裏で少しずつ埋めていく。この間、検索は旧ベクトルで動き続ける
3. 埋め終わったら新しい側にインデックスを張る
4. 参照先を切り替える。設定ひとつで切り替わるようにしておく
5. 問題なければ旧側を削除する

最初からこの形にしておけば、差し替え時の追加費用はほぼ発生しません。逆に、上書き前提で作ってしまうと後から作り直しになります。実装の詳細はDjango × pgvector の記事に書きました。

逆に、後から足せるもの

全部を最初に作る必要はありません。後から足しても問題ないものもあります。

下の5つは、必要になってから作れば構いません。予算を絞るなら、削るのはこちら側です。

まとめ

• 予算を壊すのは初期費用ではなく、「あとで足そう」とした部分
• 権限は文書単位ではなくチャンク単位で必要になる。後から足すと分割からやり直し
• 再計算は数万件で数時間、数十万件で日単位。その間システムは止まる
• 設計は権限モデル → チャンク設計 → インデックス → 検索の順でしか作れない
• モデルの差し替えは必ず来る。並存させて切り替える形にしておけば、無停止で、しかも切り戻せる
• UI・口調・文書追加は後から足せる。予算を絞るならこちらを削る