6.6 改進的基本策略

評估結果應該指向具體的修改，而不是直接換更大的模型。以下做法依照通常值得先嘗試的順序排列，從資料與檢索開始，再處理生成端。

改進的原則

一次只改一個地方

同時改了分塊、嵌入模型和提示詞，結果變好了，你不知道是哪一個起作用。每次只改一個，跑完整的測試集，比較前後。

用數字說話

改完要看指標有沒有進步，不是靠感覺。同時檢查有沒有把別的題目改壞（回歸測試，6.4）。

先處理最大的問題

看評估結果，哪一類錯誤最多，就先解決哪一類。

先便宜、簡單的

先調參數、改提示詞、整理資料，再考慮換模型、加新元件。

一、先從資料開始

很多問題的根源是資料本身。

• 清理資料：去掉雜訊、修正亂碼、處理表格（3.1）。
• 補足缺漏：使用者常問、但知識庫裡沒有的內容，補進去。
• 處理新舊版本：移除過期的文件，或標上日期。
• 整理結構：文件有清楚的標題和段落，檢索和分塊都比較容易做好。

二、分塊

• 調整大小和重疊：試幾個不同的設定，用 Hit Rate、MRR 比較。
• 換成內容感知的切法：依標題、段落切（3.4）。
• 把標題加進嵌入內容：這個做法我在 6.7 實測過，結果見下方。
• 補上相鄰的上下文：找到小塊後，把前後塊一起給模型。

三、檢索

調整 k 和門檻

• k 太小，可能漏掉；k 太大，雜訊多。看 Hit@k 的變化來決定。
• 門檻用測試集校準（5.6、6.7）。

查詢改寫

使用者的問法常常不適合直接檢索：太口語、太簡短、有指代（「那加班呢？」）。可以先用 LLM 把問題改寫成適合搜尋的形式：

• 補全指代，變成完整的獨立問題。
• 改成文件裡比較可能出現的說法（「在家上班」→「遠端工作」）。
• 一個問題拆成幾個子問題，分別檢索。

混合檢索

結合關鍵字檢索（例如 BM25）和向量檢索，再把結果合併。向量擅長語意，關鍵字擅長精確的字詞，兩者互補，對專有名詞、型號、代號特別有幫助。

重排序（rerank）

先用向量檢索撈出較多的候選（例如 20 筆），再用一個更精細、更準的重排序模型，重新依相關程度排序，取前幾名。

• 優點：常常能明顯改善「找到了，但排太後面」的問題。
• 缺點：多一個元件，增加延遲和成本。

換嵌入模型

如果整體都找不準，可能是模型不適合你的語言或領域。換之前，用測試集比較幾個候選模型（2.3）。換了之後所有向量都要重做。

加 metadata 過濾

縮小搜尋範圍，例如只搜尋特定部門、特定年度的文件。

四、提示詞與生成

• 把指示寫得更具體：明確規定資料沒有時怎麼回答、格式、長度。
• 提供範例：在提示詞裡放一兩個示範的問答。
• 調整資料的順序和數量：把最相關的放最前面，不要塞太多。
• 降低溫度：讓答案更穩定。
• 要求逐步推理：複雜的問題，可以讓模型先找出相關句子，再回答。
• 換更強的模型：最後才考慮，因為成本最高。

五、系統層面

• 快取：同樣的問題不用重複檢索和呼叫模型。
• 串流：讓使用者更早看到答案。
• 更新機制：資料變動後自動重建索引。
• 回饋迴路：收集使用者回饋，把失敗的案例加進測試集。

我做的小實驗：標題要不要放進嵌入

在 6.7 的 14 題測試集上，我比較了兩種建索引的方式：

	Hit@1	Hit@5	MRR
把標題加進內文再嵌入	0.86	1.00	0.889
只嵌入內文	0.79	0.93	0.824

加標題的版本比較好。但這個差距只有一題（Hit@1 的 12/14 對 11/14），測試集太小，不能說「加標題一定比較好」，只能說在這份資料上，它沒有變差，而且看起來有點幫助。要確認的話，需要更大的測試集。

我選擇保留這個做法，因為它的理由說得通（標題帶有主題資訊），而且成本幾乎是零。

改進的順序建議

1. 先把評估做起來，沒有量就沒有改進。
2. 檢查資料品質和分塊。
3. 調整 k、門檻、提示詞這些低成本的參數。
4. 檢索不夠準時，加入查詢改寫、混合檢索、重排序。
5. 最後才考慮換嵌入模型或生成模型。

不是每個專案都需要用到所有技巧。從最簡單的版本開始，用評估指出哪裡不夠好，再針對性地加。