昨天開始碰 RAG 之後，我先整理了一份小型的 QA Dataset，裡面放問題、預期找到的文件和預期答案，當時先沒有急著調任何參數，因為如果連一套固定的測試題目都沒有，每次改完之後其實很難知道結果是真的變好，還是剛好那幾題回答得比較順。

有了這份 Dataset，今天終於可以開始動 RAG 裡第一個很常看到的設定：Chunk。

我以前第一次做 RAG 時，對 Chunk 的理解其實很單純，就是文件太長不能整份塞進模型，所以先切成很多小段，再把這些小段丟進 Vector Database，使用者問問題時把最相關的幾段抓回來就好。

真正開始測才發現，「切成很多小段」這件事情本身就會直接影響後面的結果。

同一份文件可以有很多種切法

今天我先不碰 Embedding Model，也不改 Prompt，盡量把其他條件固定，只改 Chunk 的處理方式。

第一組最簡單，就是固定長度切，例如每一段大約固定幾百個字，實作很方便，也很容易控制每次送進模型的 Token 數量，可是它完全不知道文章原本在講什麼，因此一個完整概念可能剛好從中間被切斷。

第二組改成 Recursive Chunking，先從段落切，如果段落還是太長再繼續往句子或更小的單位處理，至少比單純按照字數硬切更接近原本文字結構。

第三組我想保留更多文件本來的段落與章節，例如同一個小標題底下的內容盡量放在一起，避免「問題在上一段，答案跑到下一個 Chunk」這種情況。

我沒有先假設第三種一定最好，因為這就是今天真正要測的事情。

先看有沒有撈到，再看回答好不好

以前測 RAG 時，我很容易直接問一句問題，看模型回答得像不像正確答案，如果答案不對就繼續改 Prompt，可是 Day 7 把 Retrieval 和 Generation 拆開之後，今天看結果的方式也變得比較清楚。

例如一題：

使用者忘記密碼時，系統會怎麼處理？

假設正確內容就在文件 A，我會先看 Retrieval 回來的 Top-5 裡面到底有沒有文件 A 的相關 Chunk。

有找到，但是最後答案錯了，那問題可能比較接近 Generation；如果連相關 Chunk 都沒有出現在結果裡，這時候一直改 Prompt 就沒什麼意義，因為模型從頭到尾都沒有拿到正確資料。

所以今天三組 Chunking 都用同一份問題測：

Fixed Size
Recursive
Section-aware

接著把 Retrieval 結果記下來，再比較最後的回答。

Chunk 太大，資料很多卻不一定比較好

我原本會直覺覺得 Chunk 大一點比較安全，至少比較不容易把上下文切掉。

可是 Chunk 變大之後，一次抓回來的內容也會變多，真正跟問題有關的可能只有其中一小段，其他文字全部一起進 Context，模型反而要從更多內容裡面找答案。

而且 Chunk 變大，Token Usage 跟著增加，假設一次 Retrieval 又拿五個 Chunk 回來，每一段都很長，最後送給模型的 Context 很快就會膨脹。

這時候就算 Accuracy 沒有下降，成本和 Latency 也可能變差。

切太小也有另一個問題

另一邊如果 Chunk 切得非常小，搜尋時可能很容易命中某個關鍵字，但原本完整的意思被拆散了。

例如文件原本寫：

申請人需於收到通知後七日內完成資料補件，
若逾期未完成，系統將自動取消本次申請。

假設剛好被切成兩段，Retriever 只抓到「七日內完成資料補件」，卻沒有把後面的逾期處理一起拿回來，那模型最後產生的答案就可能少掉最重要的條件。

所以今天做到後面，我發現 Chunk Size 不是單純找一個最大的數字或最小的數字，而是在資訊完整度、搜尋精準度和成本之間慢慢找平衡。

這次我開始把結果留下來

為了避免最後又變成「我覺得這組好像比較準」，我幫三組實驗留了一個簡單表格：

Chunk 方法 Recall@5 Answer Accuracy Avg. Token Latency
Fixed

Recursive

Section-aware

目前 Dataset 還不大，所以這些數字當然不能代表所有情況，但至少接下來我每改一次設定，都有一個固定的比較基準，不會今天拿 A 問題測 Fixed Size，明天又換 B 問題測 Semantic Chunking，最後根本不知道差異從哪裡來。

我以前真的太常憑感覺調 RAG

今天的實驗沒有什麼很華麗的功能，畫面上甚至看不出來系統有什麼變化，但這反而讓我更理解 AI Engineering 為什麼需要 Evaluation。

因為很多 AI 系統的改善，最後看起來都只是改一個參數。

Chunk Size = 500
Chunk Size = 800
Overlap = 100
Top-K = 5

如果沒有 Dataset 和指標，這些數字其實很容易變成「網路上的教學這樣寫，所以我也這樣設」，系統可以跑，可是沒有人知道這個設定到底適不適合自己的資料。

今天我先把 Chunking 固定下來，下一步還可以繼續拿同一份 Dataset 去測 Top-K、Embedding 或 Reranking，這樣每一次調整才真的能知道自己到底改了什麼。

Day 8 工程紀錄
今天測試：RAG Chunking
資料：同一份 QA Dataset
比較：

1. Fixed Size
2. Recursive
3. Section-aware

觀察：
Recall@K
Answer Accuracy
Token Usage
Latency

目前較適合的設定：＿＿＿＿

做到這裡，我現在比較不會再問「RAG 的 Chunk Size 應該設多少」，因為真正要回答的其實是，在我手上的文件、問題類型和使用情境裡，哪一種切法能讓正確資料比較穩定地被找到，同時又不必塞一大堆沒用的內容給模型。