RAGの計画：チャンク数・重複・ベクトル容量を見積もる
チャンク数とベクトル容量の見積もりは、検索できる知識集の計画に役立ちます。設定を比べて処理するテキスト量と生データ容量を把握し、代表的なサンプルで検索品質と実際のインデックス容量を確かめましょう。
重複にはコストと期待できる利点がある
分割すると小さい単位で処理できます。重複を設ければ境界付近の共通テキストを残せますが、その部分を再処理します。すべての文書や質問に最適な割合はありません。
固定幅ではなく段落や見出しの境界が適する資料もあります。チャンク数が多いほどよいと決めつけず、小さい資料集で代表的な質問を評価します。
参考資料: Microsoft — Chunking strategies and overlap trade-offs
計算機は1本の連続したトークン列を仮定する
ToolRoofは連続した資料全体、固定幅の窓、最後だけ短くなり得るチャンクをモデル化します。移動幅は窓幅から重複幅を引いた値なので、重複幅は窓幅より小さくする必要があります。
文書の境界は計算しません。短い100文書を個別に分割した結果は、合計トークンを1本の列として扱う場合と違うことがあります。文章をアップロードしたり埋め込みを生成したりせず、トークン数を入力して計算します。
生データ容量をデータベース容量と呼ばない
生の容量はベクトル数×次元数×1次元のバイト数です。検索インデックスには別の構造が加わり、文章、メタデータ、複製、更新の負荷まで含む値ではありません。
次元数や表現方式の変更は埋め込みモデルとデータベースに適合する必要があります。計算結果は検索精度、ホスティング料金、回答品質を証明しません。
例：2500トークンを4つの窓に分ける
2500トークン、窓幅800、重複幅200なら移動幅は600です。各長さは800、800、800、700で、処理する合計は3100、そのうち600は重複です。これは計算モデルであり、RAGを動作させた測定ではありません。
各チャンクが384次元、1次元4バイトのベクトルなら、4個で6144バイト、つまり6 KiBです。この例では重複を0にしても4チャンクですが、埋め込み入力は2500トークンになります。容量が同じでも検索品質が同等とは限りません。