[Day 8] 提升 RAG 搜尋品質：Top-K、Chunk 調整與 Retrieval Precision

今天為什麼要做這件事

在 Day 7，我們替 RAG Assistant 加入引用功能，讓使用者可以知道回答參考了哪些文件

但引用來源存在，並不代表搜尋結果一定正確

即使 LLM 能夠正常生成回答，因為參考資料不相關，最終答案仍可能不正確

因此，RAG 系統除了需要具備回答與引用功能，也要重視：

搜尋結果是否真的與使用者問題相關

今天將針對 Retrieval 階段進行改善，透過 Top-K、Chunk Size、Chunk Overlap 與 Retrieval Precision，建立基本的搜尋品質測試

今天要解決什麼問題

今天的學習目標包含：

1. 了解 Top-K 對搜尋結果的影響
2. 調整 Chunk Size 與 Chunk Overlap
3. 建立判斷搜尋結果相關性的方式
4. 理解 Retrieval Precision 的基本概念
5. 建立簡單的 RAG 搜尋品質測試

今天的核心觀念是：

搜尋結果不只是「有沒有找到資料」
而是「找到的資料是否真的有用」

RAG 搜尋品質的重要性

RAG 的回答品質通常會受到多個階段影響：

如果 Retrieval 階段取得錯誤或不完整的資訊，後面的 LLM 就可能面臨：

• 缺少必要資訊
• 參考到不相關內容
• 混合不同文件的資訊
• 產生不正確的推論

因此，可以將問題拆成兩個區塊：

• 找到的內容是否相關
• LLM 是否正確使用相關內容

今天主要聚焦在 Retrieval。

Top-K 對搜尋結果的影響

什麼是 Top-K

Top-K 是指：

Vector Search 要回傳前 K 筆搜尋結果

代表希望取得前 3 筆搜尋結果

Top-K 太小的影響

優點：

• Context 較短
• API Token 使用量較少
• 回答速度可能較快
• 不相關內容較少

缺點：

• 可能遺漏重要資訊
• 只取得單一 Chunk
• 無法涵蓋分散在不同段落的答案

如果只取得其中一個 Chunk，可能無法完整回答支援的作業系統

Top-K 太大的影響

優點：

• 取得較多相關資訊
• 降低遺漏答案的機會
• 適合需要整合多段內容的問題

缺點：

• Context 變長
• 可能包含不相關資料
• 增加 Token 使用量
• LLM 可能受到雜訊干擾
• 回答速度與成本可能增加

因此，Top-K 並不是越大越好

Top-K 實驗

可以比較不同 Top-K 的結果：

• 是否取得最重要的資料
• 是否能涵蓋主要答案
• 是否增加補充資訊
• 是否出現不相關內容

實際應用中，可以根據測試結果選擇合適的 K 值，而不是固定認為某個數值適用於所有資料集

Chunk Size 與 Chunk Overlap

除了 Top-K，文件切塊方式也會影響搜尋品質

Chunk Size

Chunk Size 是指每個文字片段的大小

這裡的 chunk_size 是切塊大小設定

實際切分結果會受到文字內容、分隔符號與切分行為影響，因此不一定每個 Chunk 都剛好是 100 個字元

Chunk Size 太小

優點：

• 每個 Chunk 主題可能較集中
• 搜尋結果較精準
• Context 較容易控制

缺點：

• 內容可能不完整
• 一個完整概念可能被拆開
• 需要較多 Chunk 才能涵蓋答案

如果答案分散在不同 Chunk，單獨搜尋時可能無法取得完整資訊

Chunk Size 太大

優點：

• 可以保留較完整的上下文
• 降低重要資訊被拆開的機會
• 適合需要較長脈絡的文件

缺點：

• 可能包含不相關內容
• Embedding 的語意可能較分散
• 搜尋結果不夠精準
• Context 可能變得過長

Chunk Size 應根據文件型態、內容結構與查詢方式進行調整

Chunk Overlap

Chunk Overlap 是指相鄰 Chunk 之間重複保留的內容

表示在切分時，盡量讓相鄰片段保留部分重疊內容

Overlap 的主要目的：

• 避免重要句子被切斷
• 保留前後文關係
• 降低答案資訊被分散的風險

但 Overlap 太大也可能造成：

• 重複儲存資料
• 搜尋結果重複
• Context 中出現相同內容
• 儲存空間與處理成本增加

如何評估搜尋結果是否相關

搜尋結果的相關性不能只看向量距離

因為：

數值上相似，不一定代表內容真的能回答問題

關鍵資訊檢查

確認搜尋結果是否包含問題所需的資訊

如果搜尋結果沒有包含必要資訊，就需要檢查：

• Chunk 是否切分不當
• Embedding 是否適合
• Top-K 是否太小
• 文件內容是否完整

比較不同參數

使用相同問題，比較不同設定下的搜尋結果：

Chunk Size = 100
Top-K = 2

觀察哪一組設定能取得更完整且相關的內容

Retrieval Precision 的基本概念

什麼是 Precision

在資訊檢索中，Precision 用來衡量：

搜尋回來的結果中，有多少比例是相關的

公式：

[
Precision = \frac{相關搜尋結果數量}{搜尋結果總數}
]

RAG 中的 Precision

假設使用者詢問：

安裝完成後需要做什麼？

回傳的 5 個結果中，只有 2 個被判斷為相關

Precision

需要注意：

• Precision 越高，代表回傳結果中相關資料比例越高
• Precision 高不代表沒有遺漏重要資料
• 只看 Precision 可能忽略召回率
• 評估結果需要搭配明確的標註標準

今天遇到的問題

問題一：Precision 高，但答案資訊不完整

如果只回傳一個非常相關的 Chunk，可能仍然缺少其他必要資訊

解決方向

• 同時觀察 Recall
• 增加適當的 Top-K
• 檢查答案是否需要多個 Chunk
• 使用問題類型決定搜尋策略

問題二：關鍵字測試無法判斷真正語意

搜尋結果可能沒有包含完全相同的關鍵字，但語意上仍然相關

雖然沒有完全出現相同的詞語，但語意上可能是相同意思

解決方向

• 使用人工標註
• 建立語意相似度評估
• 使用 LLM Judge 輔助評估
• 設計明確的評分標準

LLM Judge 也可能產生判斷錯誤，因此不應完全取代人工抽樣檢查

問題三：不同文件需要不同 Chunk 策略

不同類型的文件，其最佳切分方式可能不同

因此，不應該認為所有文件都使用相同的 Chunk Size 就能得到最佳結果

今天學到什麼

今天將焦點從「建立 RAG」轉向「評估 RAG」

重要學習內容包括：

1. Top-K 會影響搜尋結果的數量與內容
2. Chunk Size 會影響資訊完整性與搜尋精準度
3. Chunk Overlap 可以降低重要內容被切斷的機會
4. 搜尋結果需要經過相關性評估
5. Precision 可以衡量前 K 筆結果的相關比例
6. Precision 高不代表所有必要資訊都被找出來
7. 關鍵字測試適合入門，但不能完全代表語意相關性
8. 不同文件類型可能需要不同的切塊策略

今天最大的收穫是：

RAG 的品質不能只靠「看起來能回答」來判斷，而是需要透過測試與指標，確認搜尋到的資料真的與問題相關

目前仍然存在的限制：

• 尚未建立完整的 Retrieval 評估資料集
• 尚未處理混合式搜尋
• 尚未建立自動化評估報告

明天要做什麼

目前我們已經完成基本的 RAG 搜尋與品質測試

接下來可以進一步思考：

如果單純依靠向量搜尋，仍然找不到某些重要關鍵字或精確資訊，該怎麼改善

因此，Day 9 將會探討：

• Vector Search 與 Keyword Search 的差異
• Hybrid Search
• 語意搜尋與關鍵字搜尋的互補關係
• 如何整合不同搜尋結果
• 建立更可靠的文件檢索流程

從「確保取得的依據真的相關」，進一步走向「結合不同搜尋方式，提高資料檢索能力」