[Day 15] RAG Optimization 系統化改善，讓每次調參都有依據

前幾天，我們已經完成 RAG 的基本架構，也開始建立 Evaluation

到了 Day 14，我們已經找到問題，下一個問題就是：

「知道問題在哪裡之後，要怎麼改善」

例如 Retrieval Error 很高

我們可以調 Top-K 或 Chunk Size

但如果一次全部修改，最後即使分數提升了，也不知道：

到底是哪一個修改帶來改善

因此今天的核心不是「一直調參」，而是建立：

可重現、可比較、可驗證的 RAG Optimization 流程

RAG Optimization 到底在優化什麼

RAG Optimization 不只是調整 Model

整個 Pipeline 都可能是優化對象

第一個原則：不要盲目調參

盲目調參的情況會造成系統回應不可解釋

因此我們應該先從 Error Case 找到主要問題

再提出假設然後才修改

先建立 Baseline

在任何 Optimization 之前，先固定一個：

Baseline

這組結果就是之後所有實驗的比較基準

為什麼 Baseline 很重要

假設我們改完之後

看起來變好了

但如果沒有 Baseline，就不知道如何衡量

更重要的是，AI 系統通常存在 Trade-off

所以不能只看單一指標

建立 Multi-Metric

不同方向存在 Trade-off

因此實際工程上應該先定義哪些指標是主要目標/限制條件

這樣才能客觀比較

為什麼 Chunk Size 會影響 Retrieval

假設 Chunk Size 太小

可能造成資訊被切散

也可能造成 Chunk 包含太多無關內容

所以不存在：

「永遠最好的 Chunk Size」

而是要透過 Dataset 與實驗找出適合目前文件的設定

Chunk Overlap

Overlap 太小可能導致句子被切斷

而太大則可能造成重複內容增加

因此同樣需要透過實驗決定

Top-K

先前說明已經知道 Top-K 對 Retrieval 很重要

現在正式把它納入 Optimization

通常 K 越大，可以找到更多相關資訊

但同時 Context 變長

因此不能直接認為：

K 越大越好

Reranking

這裡的概念非常重要：

Retrieval 負責「找到」，Reranking 負責「排好」

今天學到什麼

如何找到適合自己 RAG 系統參數的方法

因為不存在所有 RAG 都適用的固定答案

真正可靠的方式是：

所以未來當有人問：

「你的 Top-K 為什麼設定成 5」

我們不應該只回答因為 5 比較好

而應該可以回答我們比較 K = 2、3、5、8

K = 5 取得較符合目前需求的結果

這才是真正具備工程依據的參數設定

代表我們開始從：

「把 AI 做出來」

進一步走向：

「用工程方法持續把 AI 做好」

當我們開始進行大量 Experiment 後，很快又會遇到下一個問題：

• 這次實驗結果為什麼比上次好
• 哪一個版本的 RAG 最好？

如果全部靠人工記錄，很快就會失控

因此下一步將進入：

Day 16：讓每次模型、參數與 Evaluation 結果都能被比較與追蹤