RAG 變快了多少？先說清楚量的是哪一段。

「五秒內回答」聽起來是清楚的需求，直到開始量測：五秒是算到第一個字、第一段可讀內容，還是完整答案？從後端收到請求開始，還是從使用者按下送出開始？

在 RAG 的實作與驗收裡，我逐漸把每個效能數字都和它的起點、終點、樣本數綁在一起。否則同樣叫做「延遲」，比較的可能完全不是同一件事。

把等待時間分開記錄

如果前面還有意圖判斷、證據選材或生成後檢查，也應留下各階段時間。測速的目的，是找到等待發生在哪裡，並判斷修改後究竟改善了什麼。

單筆成功不能代表 P95

在一次 30 題生成批次中，後端首字 P95 為 1.361 秒；另一次真實瀏覽器測試，單筆首次顯示為 2.144 秒。

兩個數字都可以記錄，但它們的樣本與量測邊界不同。後者只有一筆，不能稱為瀏覽器 P95，也不能拿兩者相減就認定是固定的網路或前端成本。

同樣地，暖機後快速回應，沒有證明冷啟動也一樣快；單人查詢成功，沒有證明同時多人使用的延遲已經合格。

先確認評分標準本身可靠

第一輪檢索驗收中，有 9 題標準證據標註過窄或對錯片段。逐題回讀候選原文後，才修正評分依據。

這讓結果更接近真正的可回答性，但它是驗收標準的修正，不能被描述成演算法突然變強。若題目、語料快照或評分方法不同，也不該把不同輪次的分數拼成一條成長曲線。

我會把一般知識題、精確原文題與無答案題分開看。找到一段相似文字，並不保證它足以回答問題；遇到無依據的問題，能否停止補造，同樣是品質的一部分。

健康狀態與使用者驗收分開

服務回傳成功、模型能產生文字、工具能被發現，各自只能證明其中一個環節。完整驗收仍需要沿著真實入口，確認來源、回答、引用與畫面呈現。

我會依序保留以下證據：

1. 固定語料、題集與執行環境，讓前後結果可以比較。
2. 每題實際命中的來源，以及回答是否被原文支持。
3. 分段耗時與完整流程耗時，說清楚計時起訖。
4. 失敗案例與已知限制，避免只留下成功截圖。
5. 冷啟動、併發與不同入口等尚未驗證的項目。

我的報告方式

與其寫「系統已達五秒」，我更願意寫清楚：「這份題集的後端首字符合門檻；瀏覽器目前只有單筆紀錄，尚未完成分位數與併發驗收。」

這篇使用的是 2026 年 9 月特定測試的歷史數據；原始語料與逐題紀錄未公開，不代表目前服務承諾或通用效能基準。留下這些邊界，是為了讓下一次測試能接著做，也讓讀者知道哪些結論可以使用。

延伸閱讀：答案正確，還不夠：RAG 的來源驗收