這支影片在講：別再把 RAG 的 chunk size 固定成一個數字

同一份語料、不同問題，可能需要完全相反的檢索窗口。Yuval Belfer 的主張是：chunk 大小不是 indexing 時能一次決定好的參數，而是由 query 決定的檢索策略。

01 / 問題

小塊找得到句子，讀不懂場景

問 Jerry 最愛的教堂，100-token chunk 可排第一；問誰是他的宿敵與「純粹的邪惡」，答案散在整段劇情，小塊反而失敗。

02 / 反轉

正確大小取決於尚未出現的 query

建索引時你能控制 window，卻不知道未來問題；真正知道問題的 retrieval 階段，窗口早已被固定。

03 / 解法

不猜一個尺寸，保留多種尺度

同一語料以多種 chunk size 建索引、全數查詢，改以文件層級合併排名，避免不同長度的 chunk 直接互比。

Signals

影片最關鍵的四個數字與轉折

Recall gap

20–40%

每題由 oracle 選最佳尺度，與任一固定 chunk size 的 recall 差距。

Indexes

6 種

實驗把資料集複製成六個不同窗口的索引，觀察尺度依 query 反轉。

Memory cost

2–5×

多尺度索引的誠實成本：更高記憶體占用。

Latency

近乎不增

講者表示此方法主要付出儲存，而非明顯額外查詢延遲。

Core story

固定 chunking 為何總會在某些問題上失手？

Chunking 是有損壓縮，不是中性的前處理

切得太小會切斷跨句、跨段的語意關係；切得太大則讓精確答案被大量背景淹沒。這不是調個最佳平均值就能消失的矛盾。

單一 index 把「不知道問題」鎖成不可逆決策

傳統流程必須先決定窗口再等待 query。當 query 需要的上下文長度不同時，固定索引只會讓一部分題目天然處於劣勢。

跨尺度結果不能直接比 chunk 分數

不同長度的 chunk 其分數意義不同。影片的做法是回到 whole document，讓候選結果可比較，再以 reciprocal rank fusion 合併各尺度排序。

Decision map

多尺度檢索的實作邏輯

1. 同份語料，保留多個窗口

不要先宣告唯一正確的 128、512 或 2k；以多個合適尺度建立索引，讓 query 有選擇權。

2. 每個尺度都提出候選

同一 query 對所有 index 查詢。這把「選窗口」從離線設定轉為線上集成。

3. 以文件而非 chunk 對齊

將每個尺度的命中回推至原文件，避免長短 chunk 的 similarity score 被誤當成同一把尺。

4. 用 RRF 融合名次

讓不同尺度各自的 rank 對最終結果投票；目的不是偏愛某一尺度，而是保住跨問題的穩定 recall。

Practical checklist

給 RAG 團隊的實務啟發

先量「每種 query」的 recall，而不是只看平均分數。將 lookup、摘要、跨段關係與模糊探索分開；平均指標很容易掩蓋某類 query 的系統性失敗。

把 chunk size 視為 retrieval policy，而非資料清理設定。若產品問題類型多變，單一窗口很可能是便利的預設，而非經驗證的最佳設計。

儲存預算與品質要一起算。多尺度索引以 2–5 倍記憶體交換 recall；先界定哪些資料與流量值得這筆成本。

評估文件層級的最終答案，不只看 chunk 命中。檢索的目標是把可回答問題的證據帶進 context；跨尺度融合要在此目標上驗收。

Source video

原影片與章節

0:00 為何 chunking · 4:17 有損壓縮 · 6:13 六種尺度 · 8:12 oracle 實驗 · 11:02 多尺度索引與 rank fusion · 15:24 成本　YouTube 原始影片